Con esta lista refinada se analizan los grupos de clases para agruparlas en relaciones jerárquicas con eventuales clases abstractas y de describe el propósito de cada clase y el rol que juegan cada una de ellas en el sistema.

Responsabilidades

Asignar las responsabilidades a las clases. Se decide que conocen y que hacen las instancias de cada clase. Las responsabilidades de un objeto son:

• El conocimiento que el objeto mantiene
• Las acciones que realiza.

Las responsabilidades de un objeto son los servicios que provee. Cuando un objeto cumple una petición realizada por otro objeto juega el rol de servidor. Un contrato entre dos clases representa una lista de servicios que una instancia solicita a otra de otra clase.

Como identificar responsabilidades

A través de la especificación se listan los verbos y se determina si representan acciones que algún objeto debe ejecutar.

A partir de las clases encontradas y sus nombres, lo cual sugiere una responsabilidad al menos y esta deriva en otras y así sucesivamente.

También pueden analizarse las relaciones "es_tipo_de", "es_análoga_a" y "es_parte_de" para identificar superclases y/o subclases que determinen responsabilidades.

Colaboraciones

Un objeto cumple una responsabilidad o solo requiere asistencia de otros objetos:

Con esto se identifica para cada contrato cuales son las clases que juegan el rol de cliente y cuales las de servidor. Analizando colaboraciones se pueden detectar responsabilidades mal asignadas en la etapa previa.

Para determinar las colaboraciones se examina cada responsabilidad de cada clase preguntando:

• ¿La clase es capaz de cumplir sola esta responsabilidad?
• En caso de no ser capaz, ¿qué necesita?
• Lo que necesita, ¿se qué clases lo necesita?

Similarmente para cada clase:

• Esta clase, ¿qué hace y que conoce?
• ¿qué clases necesitan su resultado o su información?
• Si una clase no tiene interacciones con otra u otras deberá descartarse como clase.

Ahora se tienen tarjetas descriptoras de las clases donde figuran sus subclases y responsabilidades. Y además para cada responsabilidades se registra las clases servidoras para cumplimentarla, lo que especifica las colaboraciones.

FASE ANALITICA

Herencia

1- Construir grafos de jerarquía.

2- Identificar las clases abstractas y clases concretas.

3- Dibujar diagramas de Venn representando las responsabilidades compartidas entre las clases. Esto es útil para descubrir superclases abstractas y para analizar si eran correctas las jerarquías existentes.

4- Construir jerarquías de clases usando las siguientes guías:

• Modelar la jerarquía "es_tipo_de" o "es_un".
• Factorizar responsabilidades tan arriba en la jerarquía como sea posible. Si se descubren responsabilidades comunes en un grupo de clases y no existe una superclase, crearla para que contenga esa responsabilidad.
• Asegurarse que las clases abstractas no heredan de clases concretas. Si esto ocurre crear una superclase abstracta que sostenga a la concreta y a la abstracta en cuestión.
• Eliminar clases que no agregan funcionalidad. No aquellas que hereden y no tengan responsabilidades propias.

5- Construir los contratos definidos por cada clase para deducir los servicios provistos por cada una:

• Agrupar las responsabilidades que son usadas por los mismos clientes
• Maximizar la cohesión de clases, lo que minimiza el número de contratos para facilitar la creación de subclases.
• Minimizar el número de contratos por clase para hacer el diseño más comprensible.
  

Subsistemas

Se pueden encontrar piezas que tiene integridad lógica y que pueden descomponerse en partes más pequeñas. Un subsistema es un conjunto de clases (y posiblemente de otros subsistemas) colaborando con el fin de cumplir un conjunto de responsabilidades.

Se trata de simplificar el diseño de la comunicación entre objetos. Existen dos herramientas que ayudan a este propósito:

• Grafo de Colaboraciones: mostrando colaboraciones entre clases y subsistemas.
• Tarjeta de Subsistema: describiendo el propio subsistema.

Entonces:

• Dibujar el grafo de colaboraciones
• Identificar subsistemas:

- Las clases en un subsistema deben colaborar para soportar un pequeño número de responsabilidades fuertemente unido.

- Las clases en un subsistema deben ser independientes.

Simplificar las colaboraciones entre y dentro de los subsistemas. Minimizando las colaboraciones de una clase, los cambios en el sistema tienen menos probabilidad de afectarla.

Un subsistema bien diseñado tiene pocas clases o subsistemas que soportan sus contratos.

Protocolos

• Construir protocolos para cada clase (la marca específica de los métodos que implementará)
• Usar un nombre sencillo para el método para cada operación conceptual.
• Explicitar la jerarquía para responsabilidades o protocolos heredados.

Por otro lado es buena práctica en un diseño considerar los siguientes puntos:

• Eliminar casos de análisis
  
  anObject class = thisClass ifTrue: [ anObject foo]
  "thatClass" ifFalse:[ anObject fee[.
  Este tipo de código va encontra del polimorfismo. Evitarlo!:
  thisClass ---thatClass
  answer -----answer
  ^self foo ----^self fee
  y el método anterior sería:
  anObject answer.
• Reducir tamaño de los métodos
• Reducir número de argumentos
  (media docena ya es demasiado)
• Profundidar jerarquías
  No tiene sentido una clase padre de 20 subclases, por ejemplo.
• Clase tope que sea abstracta
• Minimizar el acceso a las variables internas del objeto
  Ya que con esto se está "abriendo" al propio objeto.