Mostrando entradas con la etiqueta CRC. Mostrar todas las entradas
Mostrando entradas con la etiqueta CRC. Mostrar todas las entradas

miércoles, 22 de mayo de 2013

Análisis orientado a objetos (AOO) IV


Definición de estructuras y jerarquías

Una vez generado el modelo CRC hay que centrarse en la estructura de las clases con su correspondiente jerarquía. Se usa para ello la notación UML para representar gráficamente la jerarquía entre las clases obtenidas del modelo CRC. La flecha representa la dependencia jerárquica. La jerarquía mostrada se ha extraído de las tarjetas CRC generadas anteriormente.

             modelo de clases orientado a objetos

Definición de Subsistemas

Un modelo de análisis puede tener cientos de clases, en este caso resulta útil dividir ciertos grupos de clases en subsistemas. Para ello se eligen grupos de clases con un conjunto de responsabilidades similares. En realidad consisten en un escalón más en la abstracción para hacer más manejables grandes proyectos. En UML los subsistemas se llaman paquetes. Un subsistema tratado en su conjunto también contiene un conjunto de responsabilidades y posee sus propios colaboradores externos. En el sistema CRC se puede incluir un índice que defina el subsistema al que pertenece cada tarjeta, añadiendo también las responsabilidades a cumplir (contratos) y otros subsistemas si los hay. Por ejemplo el sistema creado anteriormente para una biblioteca se puede representar en UML como un rectángulo con dos líneas debajo para representar un subsistema de un conjunto más amplio, por ejemplo como perteneciente a una gran empresa.

              Análisis orientado a objetos, subsistemas

El modelo Objeto-Relación

El siguiente paso al CRC es definir las clases colaboradoras que ayudan a realizar cada responsabilidad de una clase dada. Este paso establecerá las conexiones entre las diferentes clases. Existe una relación, asociación o conexión entre dos clases cualesquiera que estén conectadas. La relación más común de todas en la binaria que se da entre dos clases, esta es direccional, es decir tiene una parte cliente y otra servidora.
Las relaciones se pueden derivar analizando los verbos de los enunciados. Se aíslan verbos que sugieren:

- localizaciones físicas (cerca de, contenido en)

- comunicaciones (obtenido de, transmite)

- propiedad (se compone, incorporado por)

- cumple una condición (coordina, controla, dirige)

Una vez definidas las relaciones se conectan los objetos a través de relaciones con nombres y especificando la cardinalidad.

Para obtener el modelo se usan las tarjetas CRC, Si existe alguna relación se dibujan los objetos conectados por líneas, para evitar ambigüedades se pune una punta de flecha apuntando del cliente al servidor. Finalmente se evalúa la cardinalidad de cada extremo.
El esquema en UML quedaría de este estilo.

          Análisis orientado a objetos. Esquema UML



lunes, 13 de mayo de 2013

Análisis orientado a objetos (AOO) III. Caso práctivo de modelado CRC


Se trata de modelar un sistema de biblioteca con los siguientes requisitos:

Crear una aplicación para gestionar una biblioteca, la aplicación incluirá las búsquedas y préstamo de material bibliográfico, libros, revistas, documentos, etc.

Los socios podrán consultar el material bibliográfico.

Cada socio puede tener prestado un número máximo de elementos, 2 libros, 3 revistas y 4 documentos y cada tipo de material tiene un periodo de préstamo diferente. Libros 15 días, revistas 7 días, Documentos tres días.

Si se devuelve un elemento después de su fecha habrá una multa que también dependerá del tipo de objeto y de los días de demora.

Resolución

En nuestra búsqueda identificamos los nombres (Objetos) y los verbos (Responsabilidades)

Podemos crear la tarjeta CSocio que contendrá los datos del socio (nombre, dirección, teléfono, etc) con las responsabilidades de saber que elementos tiene prestados y por cuanto tiempo.

También parece obvia la tarjeta CMaterial que contendrá los datos del material (ISBN, Título, autor, etc ) y las responsabilidades de conocer las fechas de préstamo y devolución y la multa en caso de demora. Como estas responsabilidades dependerán del tipo de material se puede crear la tarjeta CLibro, CRevista y CDocumento como tarjetas hijas de CMaterial. Finalmente se puede crear un tarjeta que englobe todo CBiblioteca que tenga por funciones prestar y recibir material, visualizarlo, saber si está prestado o no.

El primer diagrama CRC podría ser de este estilo:

                      diagrama CRC

La clase CBiblioteca se conecta a la Base de Datos (esto puede requerir otra clase) para obtener y actualizar información relativa al material y a los préstamos. Dicha clase colabora con CSocio para obtener el material que presta o desea consultar el socio y con CMaterial para obtener la información relativa a este.

La clase CSocio contiene los datos del socio, del material que tiene prestado y las multas que se han aplicado al socio.

La clase CMaterial tiene información relativa a las fechas que presta el material y calcula las multas, de ella derivan tres clases específicas CLibro, CRevista y CDocumento que tienen la responsabilidad de calcular la multa correspondiente. Dicho cálculo es específico para cada tipo de material (polimorfismo), el resto de datos comunes se almacenan en la clase base CMaterial. Siguiendo estas tarjetas se valida y mejora el sistema de clases, creando nuevas clases responsabilidades y colaboraciones hasta llegar al diseño definitivo.