En la entrega anterior ya dejamos medianamente esclarecido qué es lo que queremos que haga nuestro programa (los requisitos). Ahora vamos a empezar a pensar en cómo lo haremos… A quienes todo esto les suene demasiado raro, les sugiero que no se líen con los detalles y se queden con la idea: construir software es más sistemático y complicado de lo que puede parecer a primera vista. ¿Por qué tanto artítulo entonces? Porque estamos intentando demostrarlo :-P

Ya se han acabado las plantillas y los dibujos de muñequitos interactuando con el sistema abstracto, ahora se trata de concretar cómo será internamente ese sistema. Dijimos por encima que íbamos a utilizar una adaptación del Proceso Unificado, lo cual significa, en el fondo, que utilizaremos una tecnología orientada a objetos.

Aun no le he dedicado ningún artítulo en profundidad al tema, pero tendré que terminar intentando explicar qué es eso de la orientación a objetos. Como idea rápida, hay que pensar que los programas son tradicionalmente concebidos como series de instrucciones que se ejecutan en orden, aunque hay un enfoque alternativo: podemos construir el software pensando en «entidades» que interactúan entre sí para lograr un objetivo común (en nuestro caso, sumar dos números). Al primer enfoque se le conoce como «programación estructurada» y al segundo «programación orientada a objetos», aunque pueden combinarse ambos en el mismo programa, para desesperación de mis amados puristas :-P

Volvamos a nuestro programa. Una entidad que suma dos números puede concebirse como una «calculadora», por lo que ya tenemos nuestro objeto principal. Una vez hayamos descubierto todas las «entidades», elaboraremos un diagrama de clases, que podría quedar así:

Es decir, tendremos una entidad llamada «Calculadora» con la operación de sumar dos números. Generalmente, un diagrama de este tipo contiene varias decenas de clases con relaciones entre ellas, atributos y demás, recuerde que se trata de un ejemplo reducido y debilitado… Me estoy dando cuenta de lo complejo que puede resultar comprender todos estos conceptos a alguien ajeno al mundillo, pero el fracaso no es una opción, habrá que seguir adelante hasta terminar el trabajo :-)Esta parte del análisis es conocida como «modelo estático», porque resume las entidades del programa sin reparar en cómo se comunican. Para esto último tenemos el «modelo dinámico», o «modelo de interacción», que vamos a realizar basándonos en diagramas de secuencia. Estos diagramas nos ayudan a ver cómo el usuario potencial de nuestra calculadora se comunicará con ella a lo largo del tiempo.

Lo que este diagrama indica es que el Usuario creará el objeto Calculadora, le pedirá que sume los dos números, el sistema lo hará y devolverá la suma al usuario. Posteriormente, el usuario cerrará la calculadora.

Ya tenemos una idea de cómo vamos a realizar la suma. En el siguiente paso refinaremos este modelo de análisis, dando lugar al «modelo de diseño», y ya verán cómo no va a costarnos mucho. Una vez lo tengamos, terminar nuestro programa será como construir un edificio con unos buenos planos: sólo hará falta poner ladrillos. En nuestro caso, nos pondremos a teclear :-)