PDF de programación - Desarrollar software es una tarea complicada

Desarrollo de Software

Desarrollar software es una tarea

complicada



Desarrollo de Software - Problema



Desarrollo de Software - Conclusión



Desarrollo de Software – Soluciones mágicas y únicas

No existen las balas de plata excepto para

 Los gerentes no técnicos

 Los desarrolladores iniciados (poco conocimiento y escasa experiencia)



Desarrollo de Software – El problema es la complejidad



Desarrollo de Software - Complejidad

La complejidad se compone de
Complejidad = Compl_Solucion + Compl_Problema
Mecanismos para atacarla
Abstracción: eliminación de la irrelevante y amplificación de lo esencial
Agrupamiento y ocultamiento: ignorar los detalles y evitar verlos
Restricción: simplicidad en el enfoque
Visibilidad: desacoplamiento



Desarrollo de Software - Complejidad

La complejidad no está en la solución, está en el problema.
Las soluciones son mayoritariamente simples, llegar a ellas es en todos los

casos difícil (complicado).

Para resolver el problema es necesario entenderlo antes de pensar en una

solución.

Lo importante es ponerse en condiciones de concebir, construir y probar una

solución sin refinamientos pero que resuelva el problema.

Lo importante está en la esencia del problema y no en lo accidental de la

solución.

Los conceptos del dominio no alcanzan, son necesarias sus relaciones y lo

emergente de sus interaciones.



Desarrollo de Software - Complejidad

Mecanismos para atacar la complejidad
 Descomposición→ Descubrir
 Abstracción → Pensar
 Establecer jerarquías → Inventar



Interpretación – “Ajedrez”, Jorge Luis Borges

En su grave rincón, los jugadores

Tenue rey, sesgo alfil, encarnizada

rigen las lentas piezas. El tablero

reina, torre directa y peón ladino

los demora hasta el alba en su severo

sobre lo negro y blanco del camino

ámbito en que se odian dos colores.

buscan y libran su batalla armada.

Adentro irradian mágicos rigores

No saben que la mano señalada

las formas: torre homérica, ligero

del jugador gobierna su destino,

caballo, armada reina, rey postrero,

no saben que un rigor adamantino

oblicuo alfil y peones agresores.

sujeta su albedrío y su jornada.

Cuando los jugadores se hayan ido,

También el jugador es prisionero

cuando el tiempo los haya consumido,

(la sentencia es de Omar) de otro tablero

ciertamente no habrá cesado el rito.

de negras noches y de blancos días.

En el Oriente se encendió esta guerra

Dios mueve al jugador, y éste, la pieza.

cuyo anfiteatro es hoy toda la Tierra.

¿Qué Dios detrás de Dios la trama empieza

Como el otro, este juego es infinito.



de polvo y tiempo y sueño y agonía?

Interpretación– “Ajedrez”, Jorge Luis Borges



Interpretación = Comprensión

Problema a resolver: desarrollar un
Software para controlar el
Funcionamiento de la cafetera



Interpretación = Comprensión



Interpretación = Comprensión

/* Coffee Maker Low Level Hardware Interface */

enum WarmerPlateStatus { potNotEmpty, potEmpty, warmerEmpty };

enum WarmerPlateStatus GetWarmerPlateStatus ();

enum BoilerStatus { boilerEmpty, boilerNotEmpty };

enum BoilerStatus GetBoilerStatus ();

enum BrewButtonStatus { brewButtonPushed, brewButtonNotPushed };

enum BrewButtonStatus GetBrewButtonStatus ();

enum BoilerState { boilerOn, boilerOff };

void SetBoilerState (enum BoilerHeaterState s);

enum WarmerState { warmerOn, warmerOff };

void SetWarmerState (enum WarmerState s);

enum IndicatorState { indicatorOn, indicatorOff };

void SetIndicatorState (enum IndicatorState s);



Interpretación = Comprensión



Interpretación = Comprensión



Interpretación = Comprensión



Interpretación = Comprensión

Patrones de Colaboración



Interpretación = Comprensión



Interpretación = Comprensión



Interpretación = Comprensión

Para que utilizar objetos si se hará uso directo del API desde estos objetos,
podría programarse en C directamente.

Cambia el hardware, cambiará todo el software.

Un enfoque diferente se logra abstrayendose de los sensores, calentadores
y valvulas; pensando cuáles son las cuestiones esenciales. Una posibilidad
es centrarse en los mecanismos que hacen al funcionamiento:

El agua a presión es pulverizada a través del café (Sprayer) que una vez
condensada es mantenida caliente en el recipiente (Warmer) y todo el
proceso es disparado e informado a través de la interfaz de usuario (UI).

Estas entidades son independientes del botón, let, boiler, los sensores y el
calentador, de modo que si cambia el hardware éstas no cambiarán,
cambiarán las entidades que implementen el manejo del nuevo hardware.
Para analizar ésto nos ayudamos con los Patrones de Colaboración.



Sobrediseño = trabajo inútil



Sobrediseño = trabajo inútil

El esfuerzo invertido en el desarrollo que no responde a los

requerimientos no es apreciado (valorado) por ningún usuario ni
utilizado por ningún componente. Recién cuando ese diseño es
usado por otro componente es que se aprovechan las bondades
de su existencia.

Conclusión: no diseñar componentes de software con propiedades
que no serán percibidas ya que constituyen trabajo adicional que
no será valorado.



Conclusión clase nro. 1

Deberíamos desterrar la tentación de

enfocarnos en la solución para
asegurarnos de entender primero el
problema, ya que allí radica la
complejidad de nuestros desarrollos.



Referencias



Referencias