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.

Modelado de Clases-Responsabilidades-Colaboraciones

Sirve para identificar las clases candidatas y mostrar sus responsabilidades y colaboraciones, este modelo se suele llamar modelo CRC. Consiste en un medio sencillo para identificar las clases relevantes.

El método consiste en definir unas tarjetas (pueden ser reales o ficticias), en las que cada tarjeta representa una clase, las responsabilidades serán los atributos y operaciones de la clase y los colaboradores que serán las otras clases que interaccionan.

Clases

Como ya se indicó anteriormente las clases salen del análisis sintáctico de los requisitos de la aplicación, tomando los nombres como potenciales objetos pero hay una serie de requisitos para que un nombre sea incluido en un sistema como un objeto.

El objeto será útil si la información sobre él debe guardarse para que funcione el sistema, debe tener un conjunto de operaciones que permitan cambiar los valores de sus atributos y que estos sean múltiples, si sólo tiene un atributo acabará siendo el mismo un atributo de otro objeto. Las entidades externas con información imprescindible para el sistema también acabarán siendo incluidas como objetos. Además tanto los atributos como las operaciones deben ser aplicables a todas las ocurrencias del objeto. Todo esto lo podemos resumir en la siguiente lista:

-       Información relevante

-       Operaciones necesarias y comunes

-       Atributos múltiples y comunes

-       Entidades externas esenciales

Para incluir en el modelo una clase, esta debe satisfacer los requisitos enumerados anteriormente.

Conviene también hacer una clasificación de las clases, sobre todo si el problema es complejo y las clases candidatas son muchas. Podemos clasificarlas por diferentes características:

-      Existencia física. ¿representa algo real o un concepto abstracto?

-      Herencia. ¿Hereda o es heredada de otras clases? ¿es atómica (ninguna de las dos anteriores)?   

-      Control.  ¿controla su propia secuencia o es controlada por recursos externos?

-     Temporalidad ¿Es temporal (mientras el programa está en ejecución) o se almacena en Base de datos?

                     

Responsabilidades

Las responsabilidades consisten en los atributos y las operaciones de cada clase, las operaciones salen de los verbos del enunciado. A continuación se expone el método para decidir que verbos incluir como operaciones y cuáles no.

-          Distribución homogénea de responsabilidades. Que todas las clases tengan un conjunto similar de operaciones y no hay clases muy cargadas y otras que apenas hacen nada. Si encontramos con una clase con muchas responsabilidades tendremos que pensar en dividirla en varias clases. No obstante no se debe distribuir información de un objeto en varias clases. Una clase debe asumir responsabilidad de almacenar y manipular un tipo específico de información (objeto).

-    Las responsabilidades deben ser genéricas, y por tanto aparecer en la parte más alta de la jerarquía para aprovechar el polimorfismo.

-          Los datos y los procesos que los manipulan deben de contenerse en una misma clase.

-         Hay muchos casos en los que una gran variedad de objetos diferentes  tiene el mismo comportamiento al mismo tiempo, En este caso se debe compartir la responsabilidad entre clases relacionadas.

Las responsabilidades sólo determinan las acciones que tiene que llevarse a cabo, pero no especifican cómo.

Colaboraciones

Una clase puede manipular sus propios datos o los de otra clase (colaboración), modelo cliente-servidor. Un objeto colabora con otro si para ejecutar una responsabilidad (cliente) necesita enviar  un mensaje a otro objeto (servidor). Las colaboraciones identifican relaciones entre las clases, varias clases colaborando forman un subsistema.

Para identificar las colaboraciones hay que preguntarse si una clase puede satisfacer por completo cada responsabilidad o necesita recurrir a otras clases, en este caso surge una colaboración. A continuación se exponen las formas de identificar las colaboraciones.

-         La relación es-parte-de, se da en todas las clases que forman parte de una clase agregada (herencia).

-         La relación tiene-conocimiento-sobre, cuando una clase requiere información sobre otra.

-        La relación depende-de, es cuando dos clases tienen una dependencia y esta no se ajusta a ninguno de los dos requisitos anteriores

Es importante tener en cuenta que  la validación del diseño de colaboraciones se debe llevar a cabo con objetos y no con clases, porque puede haber varias instancias de una clase.

El nombre de la clase colaboradora se escribe en la tarjeta índice CRC al lado de la responsabilidad que ha generado dicha colaboración. La tarjeta índice contiene una lista de responsabilidades y sus colaboraciones correspondientes.