¿Qué es(tá mal en) el software?
El software se está comiendo el mundo. Muchas veces quienes trabajamos y amamos el software no nos detenemos a reflexionar de qué se trata.
Esta es la primera de una serie de artículos donde intentaremos abordar de manera minimalista problemas de diseño de software actuales en la industria.
En la universidad y la industria nos enseñan la siguiente definición sobre software:
El software es un conjunto de Instrucciones que con ciertos datos de entrada genera datos de salida.
Si miramos la Wikipedia entenderemos que esta es precisamente la definición de programa:
Un programa informático o programa de computadora es una secuencia de instrucciones, escritas para realizar una tarea específica en una computadora
Hace ya muchas décadas comprendimos que el software es mucho más que un programa. Pese a ello, seguimos sin tener buenas definiciones acerca de qué es realmente el software.
Nuevamente según la Wikipedia:
Se conoce como software al soporte lógico de un sistema informático, que comprende el conjunto de los componentes lógicos necesarios que hacen posible la realización de tareas específicas, en contraposición a los componentes físicos que son llamados hardware.
O sea la definición es por complemento (todo lo que no es hardware) o por omisión física (todo lo que no se puede patear y solo se puede maldecir).
Estas definiciones nos alejan del único propósito que tenemos siempre que construimos software que es:
modelar algo que ocurre en una realidad posible
Todo esto nos hace olvidar los orígenes de los lenguajes de programación modernos como Simula. (El primer lenguaje de programación orientado a objetos y el primero en incluir clasificación). En dicho lenguaje quedaba claro desde el nombre que el objetivo de la construcción del software era precisamente construir un simulador. Este es el caso de la mayoría de los usos de software informático en la actualidad.
Por lo tanto, y volviendo a los orígenes podemos definir al software como la construcción de un:
(M)odelo (A)bstracto (P)arcial y (P)rogramable (E)xplicando la (R)ealidad.
¿Por qué es un Modelo ?
Porque es el resultado de la observación de cierto aspecto de la realidad bajo un determinado lente y una perspectiva particular con un determinado paradigma.
No es la verdad revelada. Es la mejor concepción posible en un determinado momento con los conocimientos presentes. Desde la época de Platón los seres humanos intentamos construir buenos modelos de la realidad.
¿Por qué es un Abstracto?
Porque sólo podemos entenderlo y observarlo con instrumentos como una caja negra basándonos en su comportamiento ante nuestros estímulos.
Al igual que el gato de Schroedinger no podemos saber en qué estado está sin perturbarlo con nuestros instrumentos de medición.
La técnica de casos de uso es una excelente herramienta para describir un modelo de manera declarativa.
¿Por qué es Parcial?
Como cualquier modelo científico haremos un recorte parcial de la realidad que nos interesa para el problema que estamos modelando tomando ciertas simplificaciones sobre aspectos que no nos interesan a fin de aislar el problema.
¿Por qué es Programable?
Porque tiene que ejecutarse en algún tipo de simulador que reproduzca las condiciones deseadas. Puede ser un modelo de Turing (las computadoras comerciales actuales), una computadora cuántica, o cualquier tipo de simulador que pueda ir acompañando la evolución de dicho modelo.
¿Por qué es Explicativo?
El modelo tiene que ser suficientemente declarativo para poder observar su evolución permitiéndonos razonar y predecir comportamientos en la realidad que estamos modelando.
¿Por qué es sobre un problema de la Realidad?
Porque tiene que tener un propósito de reproducir condiciones que se dan en un ambiente observable que podamos observar e intentar simular.
Punto de partida
A partir de la definición axiomática presentada en este artículos, iremos derivando principios, heurísticas y reglas para construir excelentes modelos de software.
A la técnica que acabamos de describir la llamaremos MAPPER o biyección de manera indistinta.
Conclusiones
Una vez definido qué es concretamente el software podemos empezar a inferir buenas prácticas de modelado y diseño que iremos publicando y agregando a este artículo.
Parte del objetivo de esta serie de artículos es generar espacios de debate y discusión sobre diseño de software.
Esperamos comentarios y sugerencias sobre este artículo.
Este artículo también está disponible en inglés Aquí
