Hacia Embedded World 2021: episodio 4

Nota del editor: En el primer blog de esta serie de cinco blogs previos al Episodio 1 de Embedded World 2021, se presentó una descripción general de lo que es Embedded World. En el Episodio 2 , Randall repasó su conocimiento del lenguaje de programación C. El Episodio 3 se centró en cómo usar la programación orientada a objetos puede reducir la complejidad. En esta entrega, en el Episodio 4, se muestra cómo la medida fundamental de un buen diseño es su capacidad de reconfigurarse a medida que cambian los requisitos sin tener que volver a implementar los componentes básicos. En el blog final, Episodio 5, se cuestiona el espacio en constante expansión que requieren los sistemas operativos y se aborda la descomposición del sistema antes de la presentación principal de Randall en Embedded World 2021.

Hasta ahora, he cubierto cómo evolucionó el software para convertirse en lo que es hoy, orientado a objetos, y describí cómo la orientación a objetos tiene una analogía con la electrónica. Pensar con un estado de ánimo orientado a objetos proporciona una forma de crear modelos sustitutos de cosas del mundo real (es decir, objetos). También hablé sobre los atributos de la programación orientada a objetos (OOP) y cómo evaluar la calidad de tales modelos, pero no he hablado sobre cómo establecer esos modelos. Esto tiene que ver con cómo descomponer un sistema en módulos útiles y componentes básicos. Esta es un área de la metodología de diseño sobre la que se escribió a principios de la década de 1970 y algunas de esas lecciones están resurgiendo hoy.

La forma más popular de particionar un sistema es seguramente por función. Consiste en detallar todas las funciones necesarias en un sistema como componentes básicos y asignar desarrolladores para implementar esos bloques. Resulta que esta no es la mejor manera de diseñar un sistema. Tiene muchas dificultades que dan como resultado inflexibilidad y trabajo adicional para los desarrolladores. Un sistema diseñado por descomposición funcional funciona, pero hay una mejor manera. Es cierto que el otro camino es más difícil de empezar y es complicado de entender. Lleva más tiempo desde el principio, pero después el desarrollo se logra con más fluidez y da como resultado un sistema que se adapta más fácilmente a los cambios.

David L. Parnas, fuente: Wikipedia (https://en.wikipedia.org/wiki/David_Parnas)

David Parnas, de la Universidad Carnegie-Mellon, escribió varios artículos sobre diseño de sistemas y modularidad en 1971. Estos artículos ayudaron a establecer las nociones de acoplamiento y cohesión que mencioné en mi blog anterior. Uno de esos artículos se llamó "Aspectos de distribución de información de la metodología de diseño", escrito en febrero de 1971. Este es un artículo breve, pero describe muy a fondo qué es una metodología de diseño. Dijo: "El progreso en un diseño está marcado por decisiones que eliminan algunas posibilidades para la estructura del sistema". Dice que, habiendo eliminado las posibilidades, se establece una justificación para las decisiones posteriores y proporciona ejemplos que respaldan su afirmación. Cada una de estas metodologías crea convergencia hacia una solución.

Identificó tres enfoques:

1. Obtener consideraciones externas “buenas”.

2. Reducir el intervalo de tiempo entre el inicio y la finalización de un proyecto.

3. Obtener un sistema de fácil cambio.

El enfoque 1 se relaciona con un enfoque "de arriba hacia abajo". El enfoque 2 da como resultado que se tomen decisiones sobre la modularización que pueden no considerar el impacto total en la usabilidad final del producto, pero hace que los desarrolladores se desarrollen antes. El enfoque 3 identifica los factores que tienen menos probabilidades de cambiar, con el resultado de que primero se utiliza la información más general.

Sostiene que un enfoque de arriba hacia abajo puede dar como resultado sistemas que son más difíciles de cambiar más adelante simplemente porque el criterio de decisión favorece más los factores externos que los que efectúan el cambio. Cierra esta sección de su artículo diciendo que el orden de las decisiones tomadas en estos enfoques es inconsistente y, por lo tanto, se hace imposible satisfacerlas todas simultáneamente. Esta posición se retoma en su próximo artículo, que presentaré, pero primero quiero concluir mis comentarios sobre este primer artículo suyo.

Encuentro interesantes sus descripciones de buenos programadores. Él dice: "¡Un buen programador hace uso de la información útil que se le proporciona!". Continúa diciendo que un buen programador será inteligente y puede usar información que no está documentada y hacer esto significa que un cambio en un bloque requiere cambios en otros. Esta es la idea de connascencia que mencioné en mi último artículo y es inconsistente con el enfoque 3. El resultado de este primer artículo es que ocultar la información es bueno; esto significa que los diseñadores de sistemas deben compartir la información de diseño sobre la base de "lo que se necesita saber", como dijo Parnas.

Parnas pasó a escribir un artículo posterior titulado "El criterio que se utilizará en la descomposición de sistemas en módulos" en agosto de 1971. Este artículo recibió mucha notoriedad y está disfrutando un poco de renacimiento. Es en este artículo donde defiende el diseño de sistemas basados en la probabilidad de cambio, es decir, el enfoque 3 de su artículo anterior.

Su objetivo era mejorar la flexibilidad y comprensibilidad del sistema al mismo tiempo que reducía su tiempo total de desarrollo e ilustra el éxito con ejemplos. Al modularizar el código sobre la base de mantener oculta la información, se está modularizando un sistema sobre la base de la gestión del cambio. Los cambios se aíslan en menos módulos, lo que significa que es más fácil realizar cambios y reconfiguraciones del sistema cuando cambian los requisitos. Ya sea que se utilice descomposición funcional o de cambios, un sistema puede funcionar, pero, al garantizar una alta cohesión sobre la base de mantener oculta la información, un sistema se vuelve más flexible, completo y se desarrolla más rápidamente.

Considere el caso en el que un elemento conocido de una estructura determinada se almacena en la memoria. Si un sistema se descompone funcionalmente, algunos o todos los módulos pueden operar en él. Si se cambia la estructura, todos los módulos que accedan deben cambiar. Sin embargo, si esa estructura fue administrada por un módulo responsable de proporcionar acceso, la estructura podría cambiarse sin tener que cambiar todos los módulos que necesiten acceder a ella. El punto es que el diseñador identifica lo que es probable que cambie desde el principio en esta metodología. Cada metodología produce la misma funcionalidad, pero es la modularidad lo que difiere. Parnas cree que la modularidad basada en el cambio revela mejor las decisiones de diseño que una basada en la función y, por lo tanto, hace que un sistema sea más comprensible.

La modularización basada en mantener oculta la información no está exenta de peligros. Parnas señala que los sistemas diseñados de esta manera pueden ser ineficientes, pero argumenta que se vuelve más importante ocultar información a medida que el sistema crece. Hablaré de los peligros en mi última publicación el próximo mes.

Fundamentalmente, para mejorar la reutilización de la funcionalidad, la interfaz de esa funcionalidad debe revelar la menor cantidad de información posible. Como dijo Einstein, "Todo debería ser lo más simple posible, pero no más simple". En nuestro caso, debemos reemplazar "todo" por "la interfaz". Esta tarea es adecuada para el ingeniero integrado. El ingeniero integrado está capacitado en muchas técnicas, lo que le da la capacidad de trabajar en cualquier nivel de un diseño en comparación con alguien que no está calificado. Los diseños del ingeniero deben ser tan simples de usar como sea posible si van a ser utilizados por el mayor número de usuarios (es decir, clientes).

Fuente: https://rightingsoftware.org/

Como mencioné anteriormente, el trabajo de Parnas está disfrutando un poco de renacimiento. Invito a cualquiera que quiera obtener más información a leer los artículos de Parnas junto con un libro titulado “Righting Software”, de Juval Löwy.

Löwy le da crédito a Parnas por su enfoque, que consiste en diseñar un sistema descomponiéndolo considerando la volatilidad de los cambios potenciales y encapsular esos cambios potenciales dentro de los componentes básicos. El comportamiento requerido del sistema se implementa luego como una interacción entre esos componentes básicos. Un diseño exitoso es aquel con el conjunto más pequeño de componentes básicos que satisfacen todos los casos de uso. Esto es fácil decirlo.

Löwy dice que usted crea este conjunto conociendo los casos de uso principales. Agrega que casi nunca hay muchos de estos, como 1 a 3, con el resultado de que generalmente hay menos de una docena de componentes resultantes. La cantidad de composiciones e interacciones de 12 elementos es enorme. Pienso en la variedad de canciones que se pueden hacer a partir de 12 notas en un instrumento musical. Está la secuencia de las notas y la sincronización de ellas, así que creo que tiene razón.

Continúa diciendo que un ser humano de hace 200,000 años no tenía un caso de uso diferente al que tenemos hoy. Ese caso de uso es sobrevivir, sin embargo, la arquitectura que lo permitió mediante la caza y la recolección es la misma arquitectura (es decir, utiliza los mismos componentes) que permite a un ingeniero de software ganarse la vida hoy. Sostiene que un elefante y un ratón tienen la misma arquitectura, pero es su diseño detallado lo que es diferente. Es un argumento convincente.

Por lo tanto, la medida fundamental de un buen diseño es su capacidad para reconfigurarse a medida que cambian los requisitos sin tener que volver a implementar los componentes básicos. La descomposición exitosa satisface todos los requisitos: pasado, futuro, conocido y desconocido. Esto es algo pesado y vale la pena estudiarlo.

En mi última publicación, como mencioné, describiré un problema que hemos creado ya que permitimos que más personas usen la funcionalidad que hemos desarrollado, pero argumentaré que es el costo que pagamos por mercados más amplios.