Hacia Embedded World 2021: Episodio 3

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, Randy repasó su lenguaje de programación C. Este blog, el episodio 3, se centra en cómo usar la programación orientada a objetos puede reducir la complejidad. El episodio 4 muestra cómo 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. En el blog final, el 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.

Continuando con el mes pasado, la razón por la que me centro en la complejidad es porque creo que nuestra industria necesita reducirla. La complejidad a la que me refiero es la complejidad requerida para utilizar un dispositivo eléctrico (cuando digo eléctrico, me refiero principalmente a electrónico). Supongo que la complejidad dentro de los dispositivos seguirá aumentando. Cómo organizar esta complejidad será el tema de mi próxima publicación.

Como mencioné en mi primera publicación, la inscripción en ingeniería eléctrica (EE) está rezagada en otras disciplinas de ingeniería. A pesar de esto, estoy seguro de que nuestro futuro tendrá más dispositivos eléctricos que menos. Además, creo que estos dispositivos abarcarán una gama más amplia de aplicaciones que la que existe en la actualidad. Puedo señalar el movimiento del hacedor como evidencia de esto.

Existe un gran interés en los dispositivos eléctricos y, aparentemente, no parece haber fin en el tipo de cosas que la gente está haciendo. El interés es alto entre las personas que no han recibido capacitación formal en ingeniería eléctrica. A partir de la semana 46 de 2020, los siguientes sitios web, en conjunto, atraen a millones de visitantes únicos cada mes: maker.io, MikroE, Adafruit, Seeed, SparkFun, y otros (consulte la Figura 1 a continuación). Eso es mucho interés en la electrónica.

Figura 1: Visitantes únicos mensuales a sitios web que atienden a personas interesadas en la electrónica

De hecho, creo que hay un mercado de dispositivos eléctricos más grande que el que las ingenierías eléctricas pueden satisfacer. Si bien los ingenieros eléctricos están capacitados para manejar, o al menos saben cómo abordar, los niveles más altos de complejidad, creo que nuestra oportunidad es permitir que las personas menos capacitadas desarrollen dispositivos eléctricos. En pocas palabras, creo que si los ingenieros eléctricos pueden hacer que los dispositivos y subsistemas electrónicos sean más fáciles de usar, habilitaremos mercados más grandes.

Terminé el mes pasado en programación orientada a objetos (POO). Se puede argumentar que la POO aumenta la complejidad porque se deben dominar muchos más conceptos. Abordaré esos conceptos más adelante, pero no he señalado hasta ahora cómo la POO reduce la complejidad para reutilizar la funcionalidad y lo haré a modo de ejemplo.

Mi yerno tiene un título en administración de empresas, pero ahora está inscrito en un programa de posgrado en tecnología de la información. Compartió una de sus asignaciones recientes conmigo. Tuvo que implementar un videojuego de acción en 3D de su propia creación.

Tuvo éxito a pesar de que no tiene educación ni experiencia de ningún tipo en gráficos 3D ni en programación en tiempo real. Usó la plataforma Unity para implementar su juego como lo aconsejó su profesor. Entonces, si bien comencé con la complejidad, ahora estoy en el tema de la reutilización.

Uno de mis libros favoritos se llama Fundamentals of Object Oriented Design in UML (Fundamentos del diseño orientado a objetos en UML), de Meilir Page-Jones. Compré este libro después de hacer una buena cantidad de POO, pero sabía que era un mediocre. Quería mejorar.

Fuente: Amazon (https://www.amazon.com/gp/product/020169946X/ref=dbs a def rwt bibl vppi i0)

Para mi deleite, Page-Jones explicó los conceptos de programación orientada a objetos con una analogía de circuitos integrados. Page-Jones dijo que obtuvo esta perspectiva del libro de Brad Cox de 1986 llamado Object-Oriented Programming: An Evolutionary Approach (Programación orientada a objetos: Un enfoque evolutivo). Page-Jones también cita a Merrill Skolnik, quien escribió Introduction to Radar Systems (Introducción a los sistemas de radar) y, en ella, señaló que “la ingeniería electrónica se puede clasificar de acuerdo con: (1) componentes, (2) técnicas y (3) sistemas". Skolnik continuó explicando que "los componentes son los elementos básicos que se combinan, utilizando técnicas adecuadas, para producir un sistema". Page-Jones sugirió reemplazar “electrónico” por “software” y “componentes” por “clases” y tenemos una perspectiva útil sobre los sistemas de software.

Page-Jones continúa explicando que la elección de componentes útiles para incluir en un sistema eléctrico depende de la capacidad de los ingenieros eléctricos para identificar abstracciones útiles. Afirma que los ingenieros tuvieron décadas para descubrir los patrones útiles necesarios en un sistema electrónico antes de que se creara el primer circuito integrado. Usó este punto para ayudar al desarrollador de POO a aprender que él o ella deben identificar clases “sólidas, firmes y prácticas”. Dice que las técnicas que cita Skolnik son inútiles, a menos que esos componentes puedan conectarse entre sí, en el caso de Skolnik, con placas de circuito impreso.

Entonces, con los circuitos integrados y la programación orientada a objetos, quisiera señalar que son implementaciones esencialmente diferentes de los mismos conceptos. Reconozco que la ingeniería de software parece ser mucho más flexible que la ingeniería de hardware. Parece que hoy en día cualquiera puede implementar software. Sin embargo, no es tan cierto que el software se "conecte" fácilmente.

Jan Decaluwe, creador de MyHDL, dijo en la publicación de blog que en el contexto del diseño digital que usa lenguajes de descripción de hardware (HDL), describir la aritmética en Verilog o VHDL es cualquier cosa menos simple y, de hecho, es complicado y confuso. Digo, ya sea que estemos hablando de lógica programable o de sistemas de software, debemos hacer un mejor trabajo con nuestro diseño de software si queremos llegar a mercados más grandes.

Entonces, para terminar la publicación de este mes, señalaré los conceptos requeridos para un diseño de POO "bueno". Los conceptos más comunes son los de cohesión y acoplamiento. La cohesión es la relación de las partes de una unidad encapsulada, ya sea una clase de software, un módulo digital o un circuito integrado. Una cohesión alta es mejor que una cohesión baja porque hace que los sistemas sean más fáciles de comprender, probar, mantener y más. El acoplamiento es la conectividad o dependencia de un elemento de software o hardware de otro. El acoplamiento bajo es mejor que el acoplamiento alto porque se pueden realizar cambios en un elemento con un efecto mínimo en el otro.

Page-Jones acuñó el término “connascencia” (“connascence”) para describir un peligro de acoplamiento. Según Page-Jones, “connascencia” tiene sus raíces en latín y significa "haber nacido juntos". Agrega que esto significa tener "destinos entrelazados en la vida". Su definición formal de connascencia se muestra a continuación.

La connascencia entre dos elementos de software (o hardware) A y B significa

• que puede postular algún cambio en A que requeriría que se cambiara B (o que, al menos, se verificara cuidadosamente) para preservar la corrección general, o
• que puede postular algún cambio que requiera que tanto A como B se cambien juntos para preservar la corrección general.

Tenga en cuenta que las palabras entre paréntesis en la definición anterior son mías. Continúa explicando más de diez variedades de connascencia. Una forma de connascencia depende del orden de los argumentos en una llamada de función. Si se cambia el orden, también se deben cambiar todas las funciones dependientes. Tenga en cuenta que también explica el concepto de connascencia donde es importante mantener la diferencia. La contraconnascencia (contranascence) se aplica especialmente en el caso de la herencia de POO, donde los objetos son instancias del mismo tipo, pero deben ser distintos entre sí.

Además de la cohesión, el acoplamiento y la connascencia, existen otros conceptos útiles para comprender qué es un buen diseño de POO. Los enumero aquí para su referencia:

• Encapsulamiento
• Ocultación de información/implementación
• Retención de estado
• Identidad de objeto
• Mensajes
• Clases
• Herencia
• Polimorfismo
• Genérico

Estos temas están bien abordados en el libro de Page-Jones mencionado anteriormente y otros textos de programación orientada a objetos.

Bien, me he vuelto complejo con el tema de la complejidad. Hay muchas facetas para considerar, pero, fundamentalmente, nuestro objetivo es desarrollar cajas negras útiles que puedan ser utilizadas por cualquier persona para fabricar nuevos dispositivos eléctricos. Las cajas son negras porque no queremos ni necesitamos exponer lo que hay dentro de ellas. Queremos que sus interfaces sean lo más simples posible y que no se preocupen por su complejidad interna.

Es posible que ahora sepamos algo sobre cómo evaluar lo bueno de lo que buscamos, pero no he compartido cómo descomponer realmente sistemas y subsistemas en componentes o módulos reutilizables. Este será el tema de mi próximo blog.