RDD (Responsability Drive Design)/ CRC (Class Responsability Collaboration)

1. RDD/CRC Javier Garzás jgarzas@altransdb.com jgarzas@acm.org

2. Situación • Se pretende dotar al alumno de los conocimientos base para la aplicación del método RDD (Responsability Drive Design)/ CRC (Class Responsability Collaboration) • Todo lo que se muestra es un extracto que resume, acota y simplifica el “Designing Object - Oriented Software” by R. Wirfst - Brock texto originario del método y que todo alumno deberá usar para completar estos apuntes

3. Situación • Se debe tener presente que el método es quizá el único que refleja un verdadero análisis OO y que es antesala de muchas metodologías OO • En definitiva, RDD/CRC es de conocimiento obligado para el Analista de sistemas OO

4. 1.- Identificación de las Clases • Parte esencial del método • Su meta es encontrar las clases del dominio del problema • Es necesario basarse en heurísticas • Se parte de una descripción textual del problema, la especificación de requisitos software (ERS)

5. 1.- Identificación de las Clases 1.1 Extraer TODOS los sustantivos y frases nominales “Generalmente” estos corresponden a clases (lo veremos después). Es recomendable anotar todo en una gran superficie. 1.2 Modelar objetos físicos p.e: teclado. Un problema a parte es si el objeto físico pertenece a nuestro dominio. 1.3 Modelar entidades Conceptuales De entre los sustantivos extraídos (aun siendo todos conceptualmente correctos, como mar) se eliminan los que no pertenecen esencialmente al dominio. Eliminar los que dan forma a la narración, pero... ¡considerar siempre el escenario de trabajo!

6. 1.- Identificación de las Clases 1.4 Una palabra para una misma cosa Entre los sustantivos aparecen repeticiones de conceptos que en el dominio significan una misma cosa o referirán a una misma clase. Elegir un único nombre, generalmente este será uno de las repeticiones. 1.5 Tratar los adjetivos Pueden aparecer dos sustantivos acompañados por distintos adjetivos... determinar si son distintos o refieren a otro sustantivo totalmente distinto. 1.6 Tratar las frases sin sujeto explícito (de pasivo a activo) Es difícil determinar el sujeto (y, por tanto, el sustantivo) de frases pasivas como “se actualizará el sistema”. Por tanto, pasar las frases a activo.

7. 1.- Identificación de las Clases 1.7 Modelar las categorías Agrupar clases candidatas entorno a categorías bien definidas, la categoría formará una nueva clase candidata. 1.8 Modelar las interfaces del sistema Modelar clases, expresadas o no en los requisitos, referentes a entidades frontera con otros sistemas (también los usuarios). 1.9 Modelar valores de atributos No se trata de modelar atributos que definen estado sino de observar posibles características diferenciales del sistema

8. 2.- Obtener Clases Abstractas 2.1 Agrupar y nombrar clases relacionadas Agrupar clases candidatas entorno a categorías bien definidas, la categoría formará una nueva clase candidata. 2.2 Descubrir clases no visibles Las clases agrupantes, por lo general, no aparecen en la especificación del problema. De igual forma, al hallar superclases, podemos encontrar clases intermedias para las jerarquías.

9. 3.- Identificar las Responsabilidades • La responsabilidad es el conocimiento que el objeto debe mantener y las acciones que puede realizar... en esencia la responsabilidad equivale a los servicios. • No olvidar que Wirfs - Brock manifiesta siempre una filosofía cliente servidor

10. 3.- Identificar las Responsabilidades 3.1 Verbos, frases y acciones verbales Operar de la misma forma que cuando se identificaron todos los sustantivos (1.1) pero ahora con verbos y frases verbales. Se anotarán en una superficie y aún no se asignarán a clases. 3.2 Anotar la información a manipular por clases y Objetos Las clases, por su naturaleza, determinan algún tipo de información a mantener (p.e la clase perro debe conocer su nombre, si, si, el perro es responsable de conocer su nombre) 3.3 Deambular por el sistema a través de subescenarios 3.4 Derivar responsabilidades del nombre de la clase 3.5 Derivar responsabilidades de los propósitos de las clases 3.6 Comparar los roles de las clases detectando nuevas clases

11. 3.- Identificar las Responsabilidades 3.7 Examinar las relaciones entre clases El objetivo es descubrir así nuevas clase, aplicar: Es_un / Es_como_un y Es_parte_de.

12. 4.- Asignación de responsabilidades • Se trata de, utilizando las responsabilidades ya encontradas en la fase anterior, asignarlas a las clases adecuadas. • Es muy importante decidir correctamente la clase a la que se asigna una responsabilidad. • El acometer de forma erróneamente esta fase puede derivar en un sistema no OO o carente de sus ventajas

13. 4.- Asignación de responsabilidades 4.1 Distribuir uniformemente la inteligencia del sistema Ninguna clase debe soportar un exceso responsabilidad. Evitar “clases principales” Recordar que, si existe desproporción... hay algo que falla 4.2 Establecer responsabilidades generales Al determinar una responsabilidad para una clase debe observarse si esta puede ser asumida por alguna superclase. 4.3 Mantener unidos comportamientos con su información Si un objeto es responsable de mantener una información es lógico pensar que las responsabilidades relacionadas con dicha información sean también asignadas a la misma clase 4.4 Mantener la información sobre una cosa en un solo sitio 4.5 Compartir responsabilidades complejas en otras menores y repartirlas, si es conveniente, por otras clases.

14. 5.- Identificación de colaboraciones • Se Requerimientos de clientes a servidores para cumplir una responsabilidad del cliente • Cumplir una responsabilidad puede necesitar de las responsabilidades de otras clases y esto se expresa mediante una colaboración • Claro está que no todas las responsabilidades necesitan de una colaboración para desarrollarse. • Las responsabilidades son “servidores”.

15. 5.- Identificación de colaboraciones 5.1 Examinar relaciones entre clases ¿Tiene conocimiento de? ¿Es parte de? ¿depende de? ¿es capaz de cumplir sola con la responsabilidad? ¿qué otra clase puede necesitar la responsabilidad? …

16. 6.- Identificación de jerarquías • Evolucionar el modelo de relaciones estáticas • Establecer la reutilización de módulos • Establecer el soporte polimórfico

17. 6.- Identificación de jerarquías 6.1 Modelar jerarquías con Es_Un 6.2 Identificar clases abstractas y concretas Abstracta: no instancias… no objetos… sus objetos no tendrían sentido en el dominio 6.3 Factorizar responsabilidades tan profundamente como sea posible 6.4 Usar gráficos de Venn y árboles 6.5 Eliminar clases que no añadan funcionalidad al sistema 6.6 Evitar que clases abstractas deriven de clases concretas

18. Desiderata Identificación de contratos Identificación de subsistemas Protocolos … La anterior enumeración, incompleta, refuerza la idea de apoyar los apuntes con el libro originario que los basa