{"id":3476,"date":"2026-01-30T05:46:00","date_gmt":"2026-01-30T04:46:00","guid":{"rendered":"https:\/\/kunden.weissblaumedia.de\/microconsult\/2024\/03\/14\/tb_embedded-software-manager-pattern-1\/"},"modified":"2026-06-17T13:14:31","modified_gmt":"2026-06-17T11:14:31","slug":"tb_embedded-software-manager-pattern-1","status":"publish","type":"post","link":"https:\/\/www.microconsult.de\/en\/tb_embedded-software-manager-pattern-1\/","title":{"rendered":"Embedded Software Manager Pattern \u2013 Part 1: Establishing core tasks in a scalable way within the software"},"content":{"rendered":"

Embedded software must coordinate various central tasks across the entire software. The classic example is initialization, which must occur at all levels of the software. Upon closer examination, many more of these software-wide actions can be identified, depending on the product. In Part 1 of this article, we introduce the Manager Pattern for coordinating these tasks within the software.<\/strong><\/p>\n

The Manager Pattern is highly scalable and therefore applicable to very simple software as well as the most complex architectures. The pattern is independent of the programming language and supports both procedural and object-oriented software development. To fully understand this series of articles, knowledge of... UML<\/a> as well as procedural and object-oriented programming in C and C++<\/a> advantageous.<\/p>\n

Central task in the software<\/h4>\n

For the instantiation and initialization of objects in software, design patterns such as "Abstract Factory" and "Builder" have already been published as "creational patterns" by Erich Gama et al. Furthermore, in Internet<\/a> the \u201eManager Design Pattern\u201c, also known as \u201eManager-Managed Design Pattern\u201c or \u201eManaged Object Design Pattern\u201c.<\/p>\n

The Embedded Software Manager pattern presented here is responsible for all tasks distributed within the software that require central coordination. The number and variety of tasks depend on the system\/software requirements that the product must meet. The following tasks are considered:<\/p>\n

\"\"<\/p>\n

Table 1: Tasks and function calls<\/em><\/p>\n

Principle of the Embedded Software Manager Pattern<\/h4>\n

In very simple software, the Manager pattern consists of just a SoftwareManager class or module that performs the aforementioned tasks. As the software architecture grows, the architectural elements (AEs) at each architecture level (architectureLevel = x) receive their own AEnManagers, which handle the tasks decentrally for their respective architectural element.<\/p>\n

\"\"<\/p>\n

Figure 1: Principle of the Manager Pattern<\/em><\/p>\n

The various architectural elements are named < > Typifiable (e.g., software layer, software subsystem). At deeper architectural hierarchies, individual type names are often no longer identifiable. For this reason, the architectural hierarchies are not labeled with type names here; instead, the architecture level is specified.<\/p>\n

Therefore, the Manager Pattern is applicable to architectures with any hierarchical or flat growth pattern. The managers are capable of communicating with each other.<\/p>\n

Scalability of the Embedded Software Manager Pattern<\/h4>\n

An architectural element AE1.1 can theoretically contain an unlimited number of 0\u2026z further architectural elements at the same level, which in turn are equipped with managers.<\/p>\n

\"\"<\/p>\n

Figure 2: Manager Pattern with multiple architectural elements on the same level<\/em><\/p>\n

The number of hierarchy levels for architectural elements is theoretically unlimited, from 1\u2026x or 1\u2026y. Different numbers of hierarchy levels are possible depending on the architectural branch.<\/p>\n

\"\"<\/p>\n

Figure 3: Manager Pattern with different architectural element hierarchy levels<\/em><\/p>\n

Regardless of the UML notation, the architectural levels and the number of architectural elements in each level can be very well represented in a tree diagram. The branch nodes represent the manager classes\/modules.<\/p>\n

\"\"<\/p>\n

Figure 4: Tree diagram of the architectural levels<\/em><\/p>\n

The lowest architecture level, 0, is assigned to main(), while level 1 is reserved for the higher-level SoftwareManager. The actual architecture levels 2\u2026x, with their respective AEnManagers, begin after this.<\/p>\n

In the Part 2 of this article<\/a> We will introduce the managers and their functionalities in detail.<\/p>\n

Gain the right knowledge about how to apply the Embedded Software Manager Pattern in your software architectures and software design.<\/strong> MicroConsult offers you professional services in this area. Training and coaching<\/a> all about the topics Analysis, design and architecture<\/a> and much more.<\/p>\n

Further information<\/h3>\n

Part 2 of the article<\/a><\/strong><\/p>\n

MicroConsult expertise in embedded software development<\/strong><\/a><\/p>\n

MicroConsult training on the topic:<\/strong><\/p>\n