A continuación tomaremos cada uno de los métodos de inferencia presentados, y mostraremos en qué momentos del diseño podemos encontrarnos con cada uno de ellos. Tal como en el proceso científico, estos mecanismos no se dan compartimentados. Aunque los presentemos como momentos separados, todos los métodos de inferencia actúan engarzadamente para llevar adelante la construcción del sistema.
Previamente debemos aclarar que el diseñador de un sistema recibe un conjunto de documentos realizados por los analistas. Esta documentación refleja en un lenguaje no formal los requerimientos de construcción del “sistema virtual” realizados por el experto, es decir, aquella o aquellas personas que conocen el “sistema real” y que transmiten su conocimiento para simular en un ambiente virtual el mundo real o imaginario que ellos conocen.
a) Deducción
Probablemente sea el menos constructivo pero a su vez el proceso más utilizado en el diseño. Cuando creo un objeto de una clase, al pertenecer dicho objeto a la clase, puedo deducir cuáles son las propiedades y mensajes a los cuales responde el objeto. Es decir, la definición de la clase es la Regla de mi proceso de inferencia, el objeto que yo creé es el Caso, y los rasgos son las propiedades y comportamiento que el objeto me ofrecerá. Veamos un ejemplo: tenemos la clase Alumno, que tiene las propiedades apellido, nombre, dirección, teléfono, notas, presentismo, etc; además le puedo enviar el mensaje nota informándole en qué materia se sacó la nota, cuándo y cuál es la nota. Cuando creamos un objeto de esa clase, sabemos que el objeto tiene las propiedades y responde a los mensajes que su clase tiene definidos. Aún más, si modificamos la definición de la clase, automáticamente todos los objetos creados de la clase sufrirán la misma modificación.
b) Inducción
Cuando el diseñador realiza la primera aproximación con la documentación del análisis, comienza por la búsqueda de los objetos que dicha documentación describe. En su lectura, encuentra que cada objeto presenta ciertas propiedades y comportamientos, y que muchos de ellos los comparten. Por ejemplo, en la descripción del análisis de un sistema de administración de alumnos de una facultad, encontramos un alumno que se inscribe a un determinado tipo de curso. En otro momento de la descripción encontramos a otro alumno que paga su cuota. De esta manera comienzo a concluir que hay un conjunto de objetos que comparten ciertos atributos y que responden a los mismos mensajes: he descubierto una Clase. Esta clase no presenta todas las características de los objetos del mundo real; sólo modelará aquellas que sean de incumbencia para el sistema que se está construyendo.
En este caso, hemos realizado un proceso inductivo. A partir de los diferentes Casos (los objetos que describe el análisis) y de los rasgos que cada objeto ha presentado, construimos la Regla, es decir, nuestra Clase.
c) Analogía
Los dos procesos anteriores serían imposibles si partimos de la nada. Así como un arquitecto no construye una casa a partir de arena y piedra, los diseñadores no construyen desde clases atómicas. Siempre que el diseñador lee la documentación del análisis, tiene en su mente el bagaje de las lecturas previas y de los diseños anteriormente realizados. Es más, todos los ambientes de programación orientada a objetos, ofrecen al diseñador un conjunto muy importante de clases ya creadas e implementadas, las cuales puede utilizar para heredar o para componer. Los procesos de herencia y de composición mismos se presentan como una analogía a lo ya construido.
Por ejemplo, cuando nos encontramos con la necesidad de manipular un conjunto de objetos, sabemos que en las clases ya implementadas tenemos algunas de ellas que nos permiten trabajar con colecciones: colecciones indexadas y no indexadas, bolsas, conjuntos, colecciones con índices de dos dimensiones, etc. A partir de este conocimiento, decidiré si utilizo directamente alguna de ellas, si creo una subclase de una de dichas clases modificando y especificando su comportamiento, o si me conviene realizar una clase completamente desde cero (lo cual es muy poco común).
d) Abducción
Como postula Aníbal Bar en2, la abducción en muchos casos tiene un fuerte vínculo con la analogía. Cuando en el diseño de objetos, nos encontramos con algunos objetos que presentan determinadas características y comportamientos, y conociendo las clases preexistentes que me proporciona el ambiente, es habitual que utilicemos la abducción. Es decir, a partir de ciertos rasgos del objeto, y la definición de una determinada clase (Regla), suponemos que ese objeto pertenece a la clase (Caso) y por lo tanto, automáticamente el objeto se enriquece con las demás propiedades y comportamiento de la clase. Puede ocurrir que en ese momento nos demos cuenta de que otras características de la clase no coinciden con las características del objeto, con lo cual la hipótesis abductiva queda descartada. Como vemos, este proceso está íntimamente vinculado con el mecanismo de la analogía.
Esta es una breve analogía entre los métodos de inferencia y el proceso de diseño de software orientado a objetos. Pero no es en el único modo en el que ambos procesos se relacionan. A continuación presentaremos otras similitudes entre ellos.
