Curso básico de análisis orientado a objetos (AOO)

Con la última entrada se completa un curso básico de Análisis Orientado a Objetos.

El curso queda del siguiente modo:

Introducción y análisis del dominio

Casos de Uso, Modelado CRC

Modelado CRC caso práctico

Estructura y Jerarquias, modelo Objeto-Relacción

Modelo Objeto-Comportamiento

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.

             

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.

              

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 orientado a objetos (AOO) II

El proceso de AOO

Para comenzar a analizar un proyecto no comenzaremos intentando ver que objetos tendrá la aplicación sino más bien si interaccionará con personas o con máquinas, como será esta interacción, si pertenece a un conjunto más amplio de programas o si se coordinará con otras aplicaciones. A continuación se exponen una serie de técnicas para recopilar datos para definir un modelo de análisis.

Casos de uso

Es una visión del sistema desde el punto de vista del usuario define el sistema con un escenario de uso habitual de interacción del sistema con el usuario final. Esta visión debe quedar definida de forma clara y sin ambigüedades y será un excelente modelo de creación de requisitos y de validación de pruebas. El resultado final es un diagrama de casos de uso de UML que puede representarse en diferentes niveles de abstracción.