7.1 Fundamentos del modelo de clases
El modelado de clases es un paradigma de la ingeniería de software que permite trabajar con objetos haciendo una analogía del mundo real. Este paradigma puede ser utilizado en la ingeniería de requerimientos para definir las clases que se utilizarán en un contexto específico del negocio y que darán solución a un problema. Para poder generar un modelo de clases primero debes revisar los siguientes conceptos:
Haz clic para conocer más detalle de cada concepto
7.2 Creación del modelo de clases
Para crear un modelo de clases se inicia con lo que Pressman (2010) denomina como análisis gramatical, es decir, a partir de la descripción de los escenarios de los casos de uso se irán subrayando los sustantivos que llegarán a ser clases. Una vez que se han detectado estos sustantivos se procede ubicarlos en una de las siguientes clasificaciones.
Taxonomía de clases
- Entidades externas: son cosas o sistemas ajenos que requieren información.
- Cosas: son entidades internas al sistema que intercambian información.
- Ocurrencias o eventos: permiten identificar acciones o cambios de estado de las cosas.
- Roles: son personas que realizan alguna función específica.
- Unidades organizacionales: áreas o departamentos de la organización que requieren o generan información.
- Lugares: espacios físicos donde se realizan actividades que generan información.
- Estructuras. herramientas o dispositivos que se utilizan como interfaz entre el sistema y las personas.
A modo de ilustración, es posible realizar un análisis gramatical revisando el siguiente texto. Los sustantivos aparecen en negrilla mientras los verbos aparecen en letra cursiva:
Una estación meteorológica es instalada en una zona abierta o bien en el techo de una casa. Contiene sensores atmosféricos que recopilan información del medio ambiente circundante cada 5 minutos. Esta información es enviada a un servidor que analiza cada parámetro y va generando un reporte que puede ser recuperado por el usuario desde una página Web.
Todos los sustantivos pueden ser transformados en una clase, mientras que los verbos son métodos relacionados con esas clases. Los atributos pueden ser obtenidos analizando cada una de las clases de tal manera que hacen única a la clase. Este análisis debe ser un proceso iterativo hasta que se hayan definido sus clases + métodos + atributos para después construir un diagrama de clases.
Construcción del diagrama de clases
El diagrama de clases se construye utilizando una caja rectangular divida en tres partes o compartimentos.
En la parte superior deberá aparecer una instancia de la clase, tratando que la etiqueta sea lo más corta posible.
En la parte central deberá aparecer el listado de atributos que describen a la clase.
En la última parte serán los métodos de la clase. Por convención se incluye al final un paréntesis, ya que la programación orientada a objetos, los métodos incluyen parámetros que se especifican dentro del paréntesis.
Diagrama de clase para la clase Sistema. Imagen tomada de Pressman, R. (2010). Ingeniería de Software. Un enfoque práctico (7ª ed.). México: McGraw Hill. Sólo para fines educativos.
En el ejemplo anterior Pressman (2010) propone una clase para un sistema de seguridad para una casa, que utiliza sensores de movimiento que al activarse a través de un panel maestro permiten monitorear zonas específicas de una casa. Cuando los sensores detectan movimiento activan una alarma audible y reportan el incidente a un centro de monitoreo vía una conexión telefónica. Cada incidente es registrado en un PC como un log de eventos.
En ocasiones por facilidad y con fines informativos, algunos diagramas solo dejan el nombre de la instancia de la clase y el resto lo dejan en blanco.
Las asociaciones entre clases se dibujan a través de una línea continua, de manera opcional se incluye una leyenda que explica la asociación sobre la línea.
Imagen tomada de http://elvex.ugr.es/decsai/java/pdf/3C-Relaciones.pdf Sólo para fines educativos.
La multiplicidad se incluye a cada extremos de la asociación:
Imagen tomada de http://elvex.ugr.es/decsai/java/pdf/3C-Relaciones.pdf Sólo para fines educativos.
La composición se dibuja incluyendo un rombo relleno, por ejemplo:
Imagen tomada de http://elvex.ugr.es/decsai/java/pdf/3C-Relaciones.pdf Sólo para fines educativos.
En la agregación se utiliza un rombo sin relleno. Por ejemplo, un polígono contiene al menos 3 puntos o vértices.
Imagen obtenida de http://webdelprofesor.ula.ve/ingenieria/hyelitza/materias/programacion2/oxo/ProfaYusneyi_Tema8_POOClasesyObjetos.pdf Sólo para fines educativos.
La herencia o relación jerárquica entre las clases se dibuja con una flecha sin relleno hacia la superclase. En este caso un coche pertenece a una superclase que es un vehículo terrestre, que a su vez pertenece otra superclase llamada vehículo.
Imagen tomada de http://elvex.ugr.es/decsai/java/pdf/3C-Relaciones.pdf Sólo para fines educativos.
7.3 Modelado CRC (Clase - Responsabilidad - Colaborador)
El modelo clase-responsabilidad-colaborador es una serie de tarjetas con información de las clases que fue propuesta por Kent Beck y Ward Ward Cunningham en 1989 con el propósito de generar un inventario de clases para facilitar la documentación de los requerimientos de un sistema.
Es posible que se modele a través de tarjetas físicas de 4 x 6 pulgadas o bien con tarjetas virtuales utilizando una plantilla. Estas tarjetas pueden ser revisadas por todo el equipo del proyecto.
Cada tarjeta se encuentra dividida en tres secciones:
Sección 1. Nombre de la clase
Sección 2. Responsabilidades de la clase
Sección 3. Colaboradores
Modelo de tarjeta CRC índice. Imagen obtenida de Pressman, R. (2010). Ingeniería de Software. Un enfoque práctico (7ª ed.). México: McGraw Hill. Sólo para fines educativos.
Clases
El concepto de clases sigue siendo el mismo y a la taxonomía se pueden agregar los siguientes conceptos:
- Clases de entidad: por lo general expresan cosas que son almacenadas en una base de datos.
- Clases de frontera: permiten expresar una interfaz de intercambio de información entre el usuario y el software.
- Clases de colaborador: son clases cuyo principal objetivo es la administración de otras clases. Este tipo de clases permite la creación, modificación o eliminación de clases entidad o frontera.
Responsabilidades
Las responsabilidades de las clases establecen las acciones más relevantes que puedes realizar con esa clase o el servicio que proveen para otras clases. Puede establecer lo que hacen o lo que conocen. Las responsabilidades describen la razón de ser de la clase.
A diferencia de los métodos del diagrama de clases, estas acciones contienen más información ya que pueden mezclar atributos y operaciones.
Como recomendación, una clase no debe tener más de 5 responsabilidades. Si se requieren describir más responsabilidades lo mejor sería dividir en dos tarjetas con clases más específicas.
Pressman (2010) nos ofrece las siguientes recomendaciones para asignar responsabilidades de clases:
- La inteligencia del sistema debe estar distribuida entre las clases para enfrentar mejor las necesidades del problema. En otras palabras lo que debe hacer el sistema debe estar expresado en clases.
- Cada responsabilidad debe enunciarse del modo más general posible.
- La información y el comportamiento relacionado con ella deben residir dentro de la misma clase.
- La información sobre una cosa debe localizarse en una sola clase y no distribuirse a través de muchas.
- Cuando sea apropiado las responsabilidades deben compartirse entre las clases relacionadas.
Colaborador
Las colaboraciones describen qué tipo de objetos o clases se les puede pedir ayuda para cumplir con una responsabilidad específica.
Por ejemplo, un ejercicio del modelo CRC aplicado a una biblioteca puede ser el siguiente. Observa que existen 4 tarjetas describiendo clases que servirán para un sistema de una biblioteca. Las tarjetas se relacionan entre sí describiendo diferentes acciones cuando se presta un libro.
Imagen obtenida de http://www.inf.ed.ac.uk/teaching/courses/seoc/2011_2012/notes/SEOC06_notes.pdf Sólo para fines educativos.
