On the Road to Embedded World 2021: Episode 3

Editor’s Note: In the first blog in this series of five blogs leading up to Embedded World 2021, Episode 1, an overview of what Embedded World is was presented. In Episode 2, Randy brushed up on his C programming language. This blog, Episode 3, will focus on how using Object-Oriented Programming can reduce complexity. Episode 4 shows how the fundamental measure of good design is its ability to be reconfigured as requirements change without having to reimplement the building blocks. In the final blog, Episode 5, the ever expanding space required by operating systems is questioned and system decomposition is touched upon prior to Randall’s keynote presentation at Embedded World 2021.

Carrying on from last month, the reason I am focused on complexity is because I believe our industry needs to reduce it. The complexity I refer to is the complexity required to use an electrical device (when I say electrical, I am mainly referring to electronic). I presume the complexity within devices will continue to increase. How to organize this complexity will be the subject of my next post.

As I mentioned in my first post, electrical engineering (EE) enrollment lags other engineering disciplines. In spite of this, I am certain our future will have more electrical devices in it than fewer. Further, I believe these devices will span a larger range of applications than exists today. I can point to the maker movement as evidence of this.

There is huge interest in electrical devices and seemingly no end to the type of things people are making. Interest is high among people who have not been formally trained in electrical engineering. As of week 46 in 2020, the following websites, in aggregate, attract millions of unique visitors each month: maker.io, MikroE, Adafruit, Seeed, SparkFun, and others (see Figure 1 below). That’s a lot of interest in electronics.

Figure 1: Monthly Unique Visitors to websites catering to people interested in electronics

In fact, I believe there is a larger market for electrical devices than EEs can fulfill themselves. Whereas the EEs are trained to handle, or at least know how to approach, the highest levels of complexity, I believe our opportunity is to enable less well-trained people to develop electrical devices.  Simply put, I reason that if EEs can make electronic devices and subsystems simpler to use, we enable larger markets.

I ended last month on Object-Oriented Programming (OOP).  It can be argued that OOP increases complexity in that so many more concepts must be mastered. I will cover those concepts later, but I haven’t pointed out until now how OOP reduces the complexity to reuse functionality and I will do so by way of an example.

My son-in-law has a business degree but is now enrolled in a post-graduate program in information technology. He shared one of his recent assignments with me. He had to implement a 3D video action game of his own creation.

He was successful even though he has no education nor experience of any kind in 3D graphics or real-time programming. He used the Unity platform to implement his game as advised by his professor. So, whereas I started on complexity, I am now on the topic of reuse.

A favorite book of mine is called Fundamentals of Object Oriented Design in UML by Meilir Page-Jones.  I bought this book after doing a fair amount of OOP but I knew I was a hack. I wanted to improve.

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

To my delight, Page-Jones explained OOP concepts with an integrated circuits analogy. Page-Jones said he got this perspective from Brad Cox’s 1986 book called Object-Oriented Programming: An Evolutionary Approach. Page-Jones also cites Merrill Skolnik who wrote Introduction to Radar Systems and, in it, pointed out that “electronic engineering may be categorized according to: (1) components, (2) techniques, and (3) systems.” Skolnik went on to explain that “components are the basic building blocks that are combined, using proper techniques, to yield a system.” Page-Jones suggested replacing “electronic” with “software” and “components” with “classes” and we have a useful perspective on software systems.

Page-Jones goes on to explain that the choice of worthwhile components to include in an electrical system depends on the EEs ability to identify useful abstractions. He claims that engineers had decades to discover the useful patterns needed in an electronic system before the first integrated circuit was created. He used this point to help the OOP developer learn that he or she must identify “sound, robust, handy” classes. He says the techniques that Skolnik cites are useless unless those components can be connected together, in Skolnik’s case, with printed circuit boards.

So, with integrated circuits and object-oriented programming, I wish to point out that they are essentially different implementations of the same concepts. I grant you that software engineering appears to be much looser than hardware engineering. It seems anyone nowadays is able to implement software. However, it is not so true that software is easily “connected.”

Jan Decaluwe, creator of MyHDL, said in his blog post that in the context of digital design using hardware description languages (HDLs), describing arithmetic in Verilog or VHDL is anything but simple and is in fact complicated and confusing. I say whether we are talking about programmable logic or software systems, we must do a better job with our software design if we are to reach larger markets.

So, to wrap up this month’s post, I will note the concepts required of “good” OOP design. The most common concepts are those of cohesion and coupling. Cohesion is the relatedness of the parts of an encapsulated unit whether it is a software class, a digital module, or an integrated circuit. High cohesion is better than low cohesion because it makes systems easier to comprehend, to test, to maintain, and more. Coupling is the connectivity or dependence of one software or hardware element on another. Low coupling is better than high coupling because changes can be made to one element with minimal effect on the other.

Page-Jones coined the term “connascence” to describe a hazard of coupling. Per Page-Jones, connascence is rooted in Latin to mean “having been born together.” He adds that this means to have “intertwined destinies in life.” His formal definition of connascence is shown below.

Connascence between two software [or hardware] elements A and B means either

• that you can postulate some change to A that would require B to be changed (or at least carefully checked) in order to preserve overall correctness, or
• that you can postulate some change that would require both A and B to be changed together in order to preserve overall correctness.

Note the bracketed words in the above definition are mine. He goes on to explain over ten varieties of connascence. One form of connascence is depending on the order of arguments in a function call. If the order is changed, all dependent functions must also be changed. Note that he also explains the concept of contranascence where maintaining difference is important. Contranascence especially applies in the case of OOP inheritance where objects are instances of the same type but must be distinct from one another.

In addition to cohesion, coupling, and connascence, there are other concepts helpful to understand what is good OOP design. I list them here for your reference:

• Encapsulation
• Information/implementation hiding
• State retention
• Object identity
• Messages
• Classes
• Inheritance
• Polymorphism
• Genericity

These topics are well covered in Page-Jones’ book mentioned above and other OOP texts.

Okay, I’ve gotten complex with the topic of complexity. There are many facets to consider but, most fundamentally, our objective is to develop useful black boxes that can be used by anyone to make new electrical devices. The boxes are black because we do not want to or need to expose whatever lies within them. We want their interfaces to be as simple as possible and not care about their inner complexity.

We may now know something about how to assess the goodness of what we seek but I’ve not shared how to actually decompose systems and subsystems into reusable components or modules. This will be the topic of my next blog.