En route vers Embedded World 2021 : épisode 3

Note de l'éditeur : Dans l'Épisode 1 de cette série de cinq blogs précédant le salon Embedded World 2021, nous avons présenté cet événement. Dans l'Épisode 2, Randy s'est replongé dans le langage de programmation C. Cet Épisode 3 explique comment l'utilisation de la programmation orientée objets peut réduire la complexité. L'Épisode 4 se concentre sur la mesure fondamentale de toute bonne conception, à savoir sa capacité à être reconfigurée à mesure que les exigences changent, et ce, sans avoir à réimplémenter les blocs fonctionnels. Dans le dernier article, l'Épisode 5, l'espace toujours plus important requis par les systèmes d'exploitation est remis en cause et la décomposition du système est brièvement abordée avant l'allocution d'ouverture de Randall au salon Embedded World 2021.

Dans la continuité de ce que j'évoquais le mois dernier, selon moi, la complexité de notre industrie doit être réduite. Je fais référence ici à la complexité requise pour utiliser un dispositif électrique (et par électrique, j'entends principalement électronique). Je présume que la complexité des dispositifs va continuer de croître. Ma prochaine publication portera sur la façon d'organiser cette complexité.

Comme je l'évoquais dans mon premier article, les effectifs en électrotechnique sont à la traîne par rapport à d'autres disciplines d'ingénierie. Malgré cela, je sais que la tendance n'ira pas vers la réduction des dispositifs électriques, bien au contraire. Et, selon moi, ces dispositifs couvriront un éventail d'applications encore plus large qu'aujourd'hui. Le Maker Movement en est la preuve.

L'intérêt pour les dispositifs électriques est vif et il ne semble y avoir aucune limite à ce qui est créé. Cet intérêt est grand parmi les personnes n'ayant pas reçu initialement de formation en électrotechnique. Depuis la semaine 46 de 2020, les sites Web suivants attirent ensemble des millions de visiteurs uniques chaque mois : maker.io, MikroE, Adafruit, Seeed, SparkFun et d'autres (voir la Figure 1 ci-dessous). Cela démontre un fort intérêt pour l'électronique.

Figure 1 : Proportion mensuelle de visiteurs uniques consultant des sites Web d'électronique

En fait, je pense que le marché des dispositifs électriques est plus vaste que ce à quoi les ingénieurs électriciens peuvent répondre eux-mêmes. Alors que les ingénieurs électriciens sont formés pour gérer (ou, du moins, savoir comment gérer) les niveaux de complexité les plus élevés, il me semble que nous gagnerions à permettre à des personnes moins bien formées de développer des dispositifs électriques. Pour moi, si les ingénieurs électriciens sont capables de créer des dispositifs et des sous-systèmes électroniques plus simples à utiliser, nous ouvrons la voie à des marchés plus importants.

Le mois dernier, j'ai terminé mon article en évoquant la programmation orientée objets (OOP). On peut soutenir que la programmation orientée objets accroît la complexité, car elle suppose de maîtriser de nombreux autres concepts. J'aborderai ces concepts plus tard, mais je n'ai pas encore indiqué comment la programmation orientée objets réduit la complexité de réutilisation d'une fonctionnalité. Je vais donc le faire au moyen d'un exemple.

Mon gendre a un diplôme de commerce, mais il est maintenant inscrit dans un programme post-universitaire d'informatique. Il m'a montré l'un de ses devoirs récemment. Il devait implémenter son propre jeu vidéo d'action en 3D.

Il s'est bien débrouillé malgré son absence de formation et d'expérience en graphisme 3D ou en programmation en temps réel. Il a utilisé la plateforme Unity pour implémenter son jeu comme lui avait conseillé son professeur. Alors que j'avais commencé sur la complexité, j'en suis maintenant au thème de la réutilisation.

Le livre Fundamentals of Object Oriented Design in UML (Fondamentaux de la conception orientée objets en UML) de Meilir Page-Jones est l'un de mes préférés. Je l'ai acheté après avoir fait pas mal de projets OOP, tout en sachant que je n'étais qu'un amateur. Je voulais m'améliorer.

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

Pour mon plus grand plaisir, Meilir Page-Jones y explique les concepts de la programmation orientée objets avec une analogie de circuits intégrés. Il indique qu'il a tiré cette perspective d'un livre de 1986 de Brad Cox intitulé Object-Oriented Programming: An Evolutionary Approach (Programmation orientée objets : une approche évolutive). Meilir Page-Jones cite également Merrill Skolnik, qui a écrit Introduction to Radar Systems (Introduction aux systèmes radars), ouvrage dans lequel il indique que le génie électronique peut être catégorisé selon : (1) les composants, (2) les techniques et (3) les systèmes. Merrill Skolnik poursuit en expliquant que les composants sont les blocs fonctionnels de base qui sont combinés, grâce aux techniques appropriées, pour produire un système. Meilir Page-Jones suggère de remplacer « électronique » par « logiciel » et « composants » par « classes », pour obtenir une perspective utile des systèmes logiciels.

Il poursuit en expliquant que le choix des composants utiles à inclure dans un système électrique dépend de la capacité des ingénieurs électriciens à identifier des abstractions utiles. Il affirme que les ingénieurs ont eu des décennies pour découvrir les schémas utiles requis dans un système électronique avant la création du premier circuit intégré. Il utilise cet argument pour aider les développeurs OOP à comprendre comment identifier les classes « saines, robustes et pratiques ». Il dit que les techniques citées par Merrill Skolnik sont inutiles, sauf si ces composants peuvent être connectés ensemble, dans son cas, avec des cartes à circuit imprimé.

J'essaie donc de souligner que les circuits intégrés et la programmation orientée objets sont essentiellement des implémentations différentes des mêmes concepts. Je vous accorde que l'ingénierie logicielle semble bien plus souple que l'ingénierie matérielle. On dirait que tout le monde de nos jours est capable d'implémenter des logiciels. Cependant, il n'est pas si juste de dire que les logiciels sont facilement « connectés ».

Jan Decaluwe, créateur de MyHDL, a indiqué dans un article de blog que, dans le contexte de la conception numérique utilisant des langages de description de matériel (HDL), décrire l'arithmétique dans Verilog ou VHDL est compliqué et déroutant. Selon moi, qu'il s'agisse de logique programmable ou de systèmes logiciels, nous devons mieux travailler la conception logicielle si nous voulons atteindre des marchés plus importants.

Donc, pour résumer l'article de ce mois-ci, laissez-moi vous indiquer les concepts requis pour une « bonne » conception OOP. Les concepts les plus courants sont ceux de la cohésion et du couplage. La cohésion est le lien entre les composants d'une unité encapsulée, qu'il s'agisse d'une classe logicielle, d'un module numérique ou d'un circuit intégré. Mieux vaut avoir une cohésion élevée, car elle rend les systèmes plus faciles à comprendre, à tester, à entretenir, etc. Le couplage est la connectivité ou la dépendance d'un élément logiciel ou matériel à un autre. Mieux vaut avoir un couplage faible, car des changements peuvent être effectués sur un élément avec un effet minimal sur un autre.

Meilir Page-Jones a inventé le terme de « connascence » pour décrire un danger lié au couplage. Selon lui, « connascence » vient du latin et signifie « être né ensemble ». Il ajoute que cela signifie avoir des « destins entremêlés ». Sa définition formelle de connascence est indiquée ci-dessous.

La connascence entre deux éléments logiciels [ou matériels] A et B signifie :

• Que vous pouvez supposer qu'un changement apporté à A nécessiterait que B soit modifié (ou au moins vérifié soigneusement) afin de préserver l'exactitude globale, ou
• Que vous pouvez supposer qu'un changement nécessiterait que A et B soient tous les deux modifiés afin de préserver l'exactitude globale.

Notez que les mots entre parenthèses dans la définition ci-dessus sont les miens. Il continue en expliquant plus de dix variétés de connascence. Une forme de connascence dépend de l'ordre des arguments dans un appel de fonction. Si l'ordre est modifié, toutes les fonctions dépendantes doivent l'être également. Notez qu'il explique aussi le concept de « contranascence » où le maintien de la différence est important. La contranascence s'applique particulièrement dans le cas de l'héritage OOP où les objets sont des instances du même type, mais doivent être distincts les uns des autres.

Outre la cohésion, le couplage et la connascence, d'autres concepts sont utiles pour comprendre ce qu'est une bonne conception OOP. Je les énumère ici à titre de référence :

• Encapsulation
• Masquage d'informations/d'implémentation
• Conservation de l'état
• Identité d'objet
• Messages
• Classes
• Héritage
• Polymorphisme
• Généricité

Ces sujets sont bien couverts dans le livre de Meilir Page-Jones mentionné ci-dessus et dans d'autres textes relatifs à la programmation orientée objets.

Voilà, j'ai réussi à complexifier le thème de la complexité. Il y a de nombreux aspects à prendre en compte, mais notre objectif est surtout de développer des boîtes noires utiles pouvant être utilisées par toute personne souhaitant créer de nouveaux dispositifs électriques. Ces boîtes sont noires, car nous n'avons pas besoin d'exposer ce qu'elles contiennent et nous ne voulons d'ailleurs pas le faire. Nous tenons à ce que leur interface soit la plus simple possible sans nous préoccuper de leur complexité interne.

Nous savons peut-être maintenant comment évaluer la qualité de ce que nous recherchons, mais je ne vous ai pas encore expliqué comment décomposer les systèmes et les sous-systèmes en composants ou modules réutilisables. Ce sera le thème de mon prochain article.