Ya disculparán esta temporada tan alejado de ustedes, pero me encuentro inmerso en los exámenes de septiembre. Sí, ya sé que suena ridículo, se trata de la famosa adaptación al calendario europeo… estoy con el tiempo justo, así que les dejaré a ustedes la valoración sobre la conveniencia o no de tal calendario…

Volveré el sábado 15, tengo que hacer un último esfuerzo durante esta semana, como comprenderán. Les adelanto que habrá novedades muy interesantes durante este verano, espero que estén aquí para vivir juntos todos estos cambios que se avecinan.

?nimo y suerte a quienes estén inmersos en exámenes, oposiciones o sencillamente en el mar :-)

Finalizamos ya la serie más leída y menos comentada de la breve historia de SF. En realidad la cosa daba para algo más, pero quizás quien escribe esto ha cometido el error de adentrarse en un terreno demasiado enredado, por lo que vamos a efectuar un parto por cesárea, para terminar la serie sin más complicaciones. Bien, en las anteriores entregas hemos visto cómo recoger los requisitos de nuestra aplicación y hemos dado el salto hacia un análisis orientado a objetos del problema que nos ocupa (sumar dos números).

Ahora nos queda concretar todo eso: el diseño. Es la parte más crítica, pero si se ha realizado un buen análisis no debería suponernos mucho esfuerzo. En principio tendremos que concretar el modelo estático y adaptarlo a la implementación que vayamos a realizar. Posteriormente, haremos lo propio con el modelo de interacción. Lo único que va a cambiar aquí van a ser los nombres de los diagramas, las clases y las operaciones… podemos verlo como un refinamiento del trabajo anterior.

No estaría mal rellenar algunas plantillas con las operaciones que realizarán las clases de la aplicación, para tener una visión más ordenada de los algoritmos. También es el momento de diseñar el modelo de datos y prever si necesitaremos aplicar algún objeto adicional para manejar una base de datos. Una vez tengamos terminado el diseño, podremos pasar a la fase de implementación, donde codificaremos el programa en cuestión. En realidad eso ya es lo de menos, con el gigantesco estudio previo que hemos realizado será cuestión de un par de minutos.

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 :-)

Les propongo un viaje. En muchas ocasiones he comentado la importancia de contar en la informática con principios sólidos de ingeniería, pero esta afirmación es terriblemente abstracta, y he pensado (¡sí!) que tal vez sea conveniente concretarla… La rama de la informática que se encarga de estos asuntos se conoce como «Ingeniería del Software», y para que se hagan una idea de su magnitud, en algunos países es una carrera aparte de la Ingeniería Informática convencional…

Todos usamos programas informáticos, pero realmente pocos usuarios son conscientes de los complicados procesos de diseño que rigen el desarrollo de aplicaciones. Y, ¿qué mejor forma que aprenderlo a través de un ejemplo?

A lo largo de las siguientes entregas vamos a ir viendo cómo se construye desde cero, y haciendo las cosas bien, un programa que sume dos números que el usuario le proporcione. Es decir, el usuario le dirá algo así como «5 + 5», y él responderá «10». Hacer un análisis tan complejo para una aplicación tan sencilla es como matar moscas con bombas de hidrógeno, pero es la forma perfecta de comprender los procesos ingenieriles en la informática.

Y de paso, ayudaremos a alguien que llegó a SF hace no mucho tiempo en busca de un programa para sumar dos números orientado a objetos… :-P

Lo primero que necesitamos es un «proceso», que viene a ser una metodología (abusando del lenguaje) o unos pasos que vamos a seguir para llevar a cabo nuestro programa. Hay varios modelos de proceso, y normalmente las organizaciones tienen «su proceso» y lo utilizan siempre, para seguir siempre unos pasos sistemáticos en la construcción de su software. Vamos a emplear una adaptación del llamado Proceso Unificado (UP), que es el más utilizado en los últimos tiempos y que propone una serie de pasos que seguiremos hasta lograr nuestro programa que sea capaz de sumar dos números.

El primer paso es evaluar los requisitos y los objetivos. Para eso se suelen rellenar unas plantillas, con la idea de mantener un listado coherente y organizado de lo que queremos (el «qué»). En este caso, podría ser: «Objetivo del programa: Sumar dos números»

Lo cual formalizado con una plantilla quedaría:

Estas plantillas constituyen un avance muy interesante, que debemos a dos autores españoles: Amador Durán y Beatriz Bernárdez, de la Universidad de Sevilla, que las describen en su Metodología para la Elicitación de Requisitos de Sistemas Software. Por algún misterioso motivo, son habitualmente denominadas «plantillas de Durán y Bernárdez». Qué cosas.

Para establecer las funciones que debe proporcionar la aplicación debemos elaborar generalmente un modelo de casos de uso, que es un resumen de «lo que se podrá hacer» con nuestro programa. Así, un cajero automático tendría estos casos de uso «sacar dinero», «ingresar dinero», «consultar saldo», y los que se nos ocurran.

Los casos de uso representan posibles escenarios de uso del programa, y contribuyen a concentrar el esfuerzo en torno a las funciones exactas del programa, al tiempo que facilitan establecer los requisitos que debe reunir nuestra aplicación. Para nuestro caso, sólo hay un caso de uso (que traducción más horrible, por cierto) que sería “sumar dos números?.

Respecto a los sistemas existen lo que llamamos actores. Los actores representan entidades que interactúan con el sistema. Por ejemplo, en el cajero un actor sería el cliente. En nuestro caso, sólo vamos a tener un actor: el usuario que proporcione dos números para que sean sumados. Lo vamos a llamar «usuario» a secas. Y para él vamos a rellenar también una plantilla como la que sigue:

Una vez hemos definido los actores y los casos de uso, podemos dibujar un diagrama de casos de uso, que sería una cosa así:

Tal vez les parezca algo ridículo, pero eso es porque no han visto un diagrama con cincuenta casos de usos, con relaciones de extensión, inclusión… en cualquier caso, y por muy complejo que sea un diagrama de casos de uso, siempre simplificará en gran medida la especificación de los requisitos del sistema que diseñemos.

Ahora se trata de concretar qué hacen los casos de uso. Aquí hay que ser bastante sistemático, pero el trabajo que realicemos ahora redundará en una mejora de la implementación posterior. Como sólo tenemos uno, nos quedará una bonita plantilla como ésta:

El «modelo de casos de uso» resultante del diagrama y la descripción de los escenarios da lugar a una descripción exacta y concisa de los requisitos de nuestra aplicación. Ya sabemos qué queremos hacer. En las siguientes entregas veremos cómo lo hacemos.

The most likely way for the world to be destroyed, most experts agree, is by accident. That’s where we come in; we’re computer professionals. We cause accidents.

Nathaniel Borenstein

Lo cual traducido (muy libremente) al castellano, viene a ser:

La mayoría de los expertos coinciden en que la forma más probable de que el mundo sea destruído es debido a un accidente. Aquí es donde entramos nosotros: somos profesionales de la informática. Causamos accidentes.

Hay miles de ejemplos de historias catastróficas en las que, por desgracia, los informáticos estamos involucrados de alguna manera. Programas que dejan de funcionar, fallos de sistemas críticos que se cobran vidas humanas… La frase es divertida, pero encierra la dramática realidad de que los defectos en la ingeniería del software son tan peligrosos como en cualquier otra disciplina: no debemos pasarlos por alto ni restarles importancia.

Es preciso crear una conciencia social sobre la importancia de aplicar procesos sólidos de ingeniería en informática. De la misma manera que nadie le pide a su cuñado albañil que construya la casa para sus hijos, nadie debería sentirse seguro utilizando una aplicación construída por un conocido o «uno que sabe mucho». De los programas informáticos dependen vidas y recursos humanos en muchos casos…

No se puede construir un edificio sin el título de Arquitecto. Pero parece ser que se pueden diseñar aplicaciones sin el título de Ingeniero. Un día nada funciona y nos preguntamos por qué, y nos creemos eso de que los programas están condenados a fallar, que la informática es imperfecta… y un sinfín de excusas a las que nos han acostumbrado.

Los edificios también se caerían si fueran construidos por aficionados al modelismo.