Papers de Sistemas

Página 1

Diseño y tecnología Hay algunas ideas instaladas tanto en el mercado laboral como en el ámbito académico, las vamos a anotar en el pizarrón:

"Se puede diseñar la funcionalidad sin conocer la tecnología"

"Si estoy diseñando y tiro una línea de código, dejé de diseñar"

"Diseñar implica saber UML / saber Enterprise Architect / hacer cajitas".

“Se puede programar sin necesidad de diseñar”

Nuestro pensamiento es que

cuando no bajamos a detalle,

cuando ignoramos cuestiones esenciales de la tecnología (arquitectura, paradigmas y lenguajes a desarrollar, etc.),

cuando nos queremos abstraer de la programación y la consideramos una tarea menor, "operativa", donde no se piensa

estamos "generando una deuda", porque si diseñar es tomar decisiones, descartar decisiones técnicas produce un diseño pobre. Y decimos que diseñar no es hacer diagramas, hacer diagramas es documentar las decisiones que tomé en otro momento. Si no hice el diagrama no quiere decir que no diseñé, en todo caso quiere decir que no está documentado, esa es otra discusión.

Por otra parte, cuando pensamos que el diseño implica detallar cada una de las decisiones, posiblemente nos estemos obligando a tomar esas decisiones en forma prematura, donde no siempre tenemos toda la información o el contexto para definir apropiadamente los componentes. Más adelante trabajaremos en este aspecto.

Página 2

Diseño de sistemas y diseño de software Preguntamos a la clase: ¿cómo se relacionan entre sí el diseño de sistemas y el diseño de software? ¿qué abarca cada concepto?

El diseño de software está englobado en el diseño de sistemas, que tiene características más generales. Podemos diseñar:

el sistema electoral que determina el ganador de una elección, un sistema de inscripción a la facultad, un sistema que entrega documentos de identidad a los ciudadanos,

sistemas de control: ascensores, puentes, cámaras de vigilancia, dispensers, brazos robóticos, etc.

y el software que puede hacer de soporte tecnológico a casi todos los sistemas que mencionamos anteriormente.

El diseño de software es particularmente interesante por sus características no tangibles. Por eso la mayoría de los ejemplos de las clases siguientes van a estar enfocados en resolver necesidades de productos de software.

Página 3

Buscamos abrir el juego, nada más, ver qué significa para cada uno: "pensar una solución", "resolver un problema", "decidir".

Detenerse a pensar un poco qué es diseñar nos ayuda a entender el scope de la materia: lo que es esencial y lo que es tangencial.

Tiramos finalmente una definición para orientar lo que buscamos: "diseñar es tomar decisiones sobre los componentes de un sistema", en particular

encontrar cuáles son esos componentes

qué responsabilidad tiene cada componente (qué va a hacer, qué no puede resolver, qué va a necesitar que otro le resuelva)

cómo se relaciona cada componente con los demás para formar un sistema

repasamos la definición de un sistema como "conjunto de partes que se relacionan para lograr un objetivo común".

Y separando el pizarrón en cuatro partes, vemos que:

en el paradigma de objetos, los componentes son... objetos (a bajo nivel, marcamos los componentes con círculos), las responsabilidades están definidas por la interfaz del objeto. Recordamos interfaz vs. implementación; interfaz es lo que le puedo pedir a un objeto que haga (mensaje), la implementación es cómo lo termina resolviendo (método). ¿Cómo se relacionan los objetos? Claro, enviándose mensajes. Pero para eso se tienen que conocer. ¿Y cómo los conozco? Mediante una referencia temporal (variable local, parámetro) o más permanente (variables de instancia o de clase, más allá de las variables globales que no nos interesa tratar).