Embed Size (px)
Citation preview
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
rigen las lentas piezas. El tablero
los demora hasta el alba en su severo
ámbito en que se odian dos colores.
Adentro irradian mágicos rigores
las formas: torre homérica, ligero
caballo, armada reina, rey postrero,
oblicuo alfil y peones agresores.
Cuando los jugadores se hayan ido,
cuando el tiempo los haya consumido,
ciertamente no habrá cesado el rito.
En el Oriente se encendió esta guerra
cuyo anfiteatro es hoy toda la Tierra.
Como el otro, este juego es infinito.
Tenue rey, sesgo alfil, encarnizada
reina, torre directa y peón ladino
sobre lo negro y blanco del camino
buscan y libran su batalla armada.
No saben que la mano señalada
del jugador gobierna su destino,
no saben que un rigor adamantino
sujeta su albedrío y su jornada.
También el jugador es prisionero
(la sentencia es de Omar) de otro tablero
de negras noches y de blancos días.
Dios mueve al jugador, y éste, la pieza.
¿Qué Dios detrás de Dios la trama empieza
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
