Nosololinux

Dos reflexiones muy interesantes en torno a lo mismo: la primera sobre los programas que se toman demasiadas confianzas…

Con esta moda, uno va a instalarse los drivers de una WebCam y termina con la barra de Yahoo Search, con el iTunes, con el QuickTimes, con el Skype… todo de una sola tacada… y un PC que antes tardaba en arrancar un minuto, ahora tarda tres minutos.

Y la segunda, sobre el concepto de “siguiente siguiente siguiente” y sus problemas:

Es la cultura del no leer la que tenemos que combatir. Pero no solo en los asistentes de los programas de informática, sino en muchas otras situaciones: cuando alguien va a pedir un crédito, cuando alguien va a votar, cuando alguien va a comprarse un PC, cuando alguien va a comprarse un coche, cuando alguien va a tomarse un medicamento, cuando alguien va a contratar una línea telefónica… la gente se ha acostumbrado a firmar cosas sin leer.

Leídas en Al otro lado del mostrador.

Ando bastante ocupado últimamente, así que sigo con las citas, que muchas veces dicen más que un artículo de folios y folios… por cierto, ésta es mía (ha sido un ataque de ego tan típico del mundo blogueril)

No tengo nada contra las herramientas llamadas de propósito general, más allá de que existe un defecto inherente a este concepto: tarde o temprano el propósito general y el tuyo serán diferentes, y entonces tendrás un grave problema.

- Pau, Hablando sobre los editores genéricos de interfaces para Java, 2006

Vamos muy mal de tiempo. Hay que entregar un proyecto en quince días y el equipo está muy presionado, y es muy posible que el desarrollo no se concluya en el plazo previsto…

Los directivos no quieren correr el riesgo de perder a un cliente importante, e insisten en que el producto quede listo en el plazo previsto. Lo que no saben, o si lo saben no les importa, es que ese plazo era imposible de cumplir desde un primer momento… una vez más, las fechas las fijó un gestor en vez de un informático.

Los jefes se han reunido y han acordado que lo mejor es contratar a más personal para que se integre en el equipo… “si en vez de trabajar cinco personas, trabajan diez, lógicamente el proyecto se terminará en la mitad del tiempo previsto”. El equipo directivo sonríe satisfecho y cinco nuevos trabajadores se incorporan al equipo.

Dos semanas después, se cumple el plazo y el proyecto no está terminado… los directivos, confundidos, piden explicaciones al equipo técnico, que les dice que lejos de hacerles avanzar más rápido, las nuevas incorporaciones les hicieron ir aún más lentos…

¿Qué ha pasado?

Los directivos olvidaron que más personal no implica una mayor velocidad en el desarrollo, y han caído en la trampa conocida en la ingeniería del software como “La horda mongoliana”, que se resumen en “si no da tiempo, contrata a más gente”. Es posible que a primera vista esa forma de pensar parezca lógica, pero cuando uno lo piensa se da cuenta del grave error que supone.

Imaginemos que tenemos que construir un muro de ladrillo de un metro de alto y disponemos de dos albañiles que tardarán, pongamos, un día en terminarlo. Nadie nos garantiza que 24 albañiles lo construirán en una hora… de hecho es posible que tarden hasta más del día inicial, porque tendrían que coordinarse muy bien para alcanzar cierto rendimiento.

El ejemplo del muro nos desvela uno de los dos fenómenos que intervienen en el problema de la horda mongoliana: más medios son más difíciles de coordinar. El otro fenómeno que concurre es muy interesante, y consiste en que las personas tardamos en rendir al 100% al incorporarnos a un equipo: tenemos que aprender cómo se trabaja en la empresa, ponernos al día de los procedimientos, entender lo que se está desarrollando y en menor medida, necesitamos tomar un poco de relación con nuestros compañeros.

Para evitar caer en estos fallos tan lamentables como frecuentes es necesario escuchar al equipo de desarrollo antes de fijar los plazos de entrega, y dentro de unos límites, llegar a un consenso con los trabajadores. Si la presión es grande, puede ser mejor idea incrementar la jornada de los técnicos y pagarles las horas extra (lo cual a veces no interesa, pero esa es otra historia).

Si no queda más remedio que contratar a personal ajeno, es donde nos ayudará el contar con procesos sistemáticos de ingeniería que nos permitirán que el nuevo equipo se adapte con rapidez al desarrollo existente.

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.

Si yo tuviera que vender mi gato (al menos a un informático) no diría que es amable y autosuficiente y que se alimenta de ratones: más bien argüiría que está orientado-a-objetos”

Roger King

La programación orientada a objetos (POO) es la tecnología emergente más importante en cuanto a desarrollo de aplicaciones. Supone una auténtica revolución en la forma de plantear la construcción de aplicaciones desde un punto de vista ingenieril y aporta infinidad de ventajas sobre los esquemas estructurados tradicionales.

Es algo muy complicado de explicar a quien tenga la fortuna de no haber tenido que desarrollar un programa… sólo me resultaba simpática la cita, por la obsesión que tenemos los aspirantes a ingeniero con la orientación a objetos.

Si a alguien le intriga mucho el tema, puedo tratar de explicarlo, pero no prometo milagros. El inicio de semana está siendo verdaderamente duro, sean tan indulgentes como hasta ahora… :-P