В рамках C/C++/Embedded місяця у GlobalLogic нещодавно відбувся Online TechTalk "Patterns in Embedded SW Design"
Спікер розібрав паттерни на кісточки: від поняття до практичного використання з прикладом проєктного коду.
У доповіді спеціаліст розглянув:
- Поняття патернів у програмному забезпеченні з акцентом на Embedded розробку.
- Основні переваги використання патернів.
- Класифікацію патернів для Embedded напрямку, деякі з них було розглянуто.
- Було наведено приклад використання на прикладі проєктного коду.
Деталі та відео заходу: https://bit.ly/3DaKx7t
5. 5
Confidential
Generic understandings of “Patterns”
a software design pattern is a general, reusable
solution to a commonly occurring problem
within a given context in software design.
It is not a finished design that can be
transformed directly into source or machine
code. Rather, it is a description or template for
how to solve a problem that can be used in
many different situations. Design patterns are
formalized best practices that the programmer
can use to solve common problems when
designing an application or system.
What is Patterns?
6. 6
Confidential
Generic understandings of “Patterns”
• Intent of the pattern briefly describes both the
problem and the solution.
• Motivation further explains the problem and
the solution the pattern makes possible.
• Structure of classes shows each part of the
pattern and how they are related.
• Code example in one of the popular
programming languages makes it easier to
grasp the idea behind the pattern.
Some pattern catalogs list other useful details,
such as applicability of the pattern,
implementation steps and relations with other
patterns.
What does the pattern consist of?
Intent Motivation
Structure
Code Example
7. 7
Confidential
Generic understandings of “Patterns”
• The concept of patterns was first described by Christopher
Alexander in 1977 A Pattern Language: Towns, Buildings,
Construction. The book describes a “language” for designing the urban
environment. The units of this language are patterns. They may
describe how high windows should be, how many levels a building
should have, how large green areas in a neighborhood are supposed
to be, and so on.
• Erich Gamma, John Vlissides, Ralph Johnson, and Richard Helm. In
1994, they published Design Patterns: Elements of Reusable Object-
Oriented Software, in which they applied the concept of design
patterns to programming. The book featured 23 patterns solving
various problems of design and became a best-seller very quickly. Due
to its lengthy name, people started to call it “the book by the gang of
four” which was soon shortened to simply “the GoF book”.
Some Historical notes :)
8. 8
Confidential
Generic understandings of “Patterns”
• “Each pattern describes a problem which
occurs over and over again … and then
describes the core of the solution to that
problem, in such a way that you can use this
solution a million times over, without doing it
the same way twice.”
• – Christopher Alexander
• At the core […] is the idea people should
design their homes, streets, and communities.
This idea […] comes from the observation
most of the wonderful places of the world were
not made by architects, but by the people.
• — Christopher Alexander et al., A Pattern Language,
front bookflap
Nature and Abstraction
13. 13
Confidential
Patterns benefits and concerns
• Design patterns use object-oriented and implement SOLID Principals.
• Make your lives easy - make possible you to get benefit from the experience of your predecessors
those have worked on the same type of project .True in backward direction.
• Make development fast and easily documented.
• Reusability and extensibility of the already developed applications.
• Design patterns are more sophisticated and advance approaches than basic data structures such as
arrays, linked lists, and binary trees.
• All design patterns use self-descriptive naming conventions and a design pattern based name of
program objects captures a basic idea about the working and use of that particular object.
• Design pattern utilize descriptive words such as proxy, adapter, iterator, visitor, and command in the
name of the objects.
• Design patterns improve software development process.
Benefits
14. 14
Confidential
Patterns benefits and concerns
• Patterns do not lead to direct code reuse.
• Patterns are deceptively simple.
• Teams may suffer from patterns overload.
• Integrating patterns into a software development process is a human-intensive activity.
• Design patterns could been oversold.
• Some design patterns are unnecessarily difficult to learn
• Design pattern classifications are not yet useful for practitioners
Disadvantages
15. 15
Confidential
Patterns benefits and concerns
• Unjustified use
• If all you have is a hammer, everything looks like a nail.
• This is the problem that haunts many novices who have just familiarized themselves with patterns.
Having learned about patterns, they try to apply them everywhere, even in situations where simpler
code would do just fine.
• Inefficient solutions
• Patterns try to systematize approaches that are already widely used. This unification is viewed by
many as a dogma and they implement patterns “to the point”, without adapting them to the context of
their project.
Disadvantages
17. 17
Confidential
Classification of embedded patterns
• Creational patterns provide object creation
mechanisms that increase flexibility and reuse
of existing code.
• Structural patterns explain how to assemble
objects and classes into larger structures,
while keeping the structures flexible and
efficient.
• Behavioral patterns take care of effective
communication and the assignment of
responsibilities between objects.
• Architectural patterns take care of generic
project/solution organization.
Classification of Patterns
20. 20
Confidential
Classification of embedded patterns
Specific of knowledge set required for
Embedded engineers; diverse environment on
different projects like BM, RTOS, Linux; safety
standards and recommendations like MISRA or
AutoSAR – dictate limitation, but nobody does
not keep us from exploitation of patterns
approach.
Software design patterns for Object oriented
languages bring us flexibility of High
abstractions aproaches, but core goal of
patterns – re-usage of solutions, but not limit us
how to do that and what particular patterns to
use.
Why Embedded Patterns specific
21. 21
Confidential
Classification of embedded patterns
• Object design patterns – Half Call, Manager,
Resource manager, Message factory and Message
interface, Publish-subscriber
• State Design Patterns- Hierarchical State
Machine, State machine, Collector state, Parallel wait
state, Serial wait state
• Hardware Design Patterns – Serial port, High
speed Serial Port, Hardware, Synchronize
• Protocol Design Patterns – Transmit protocol
Handler, Receive protocol Handler, Protocol Packer,
Protocol layer, Protocol stack
• Architecture Design Patterns – Processor, Future
Coordination, Task, Resource Allocation, Timer
management
• Implementation Patterns – C++ header file
include, STL
Embedded Specific Patterns Types
Object Design Patterns
State Design Patterns
Hardware Design Patterns
Protocol Design Patterns
Architecture Design Patterns
Implementation Patterns
23. 23
Confidential
Commonly used patterns
• In conventional state machine design, all states are
considered at the same level. The design does not
capture the commonality that exists among states.
In real life, many states handle most messages in
similar fashion and differ only in handling of few key
messages. Even when the actual handling differs,
there is still some commonality. Hierarchical state
machine design captures the commonality by
organizing the states as a hierarchy. The states at
the higher level in hierarchy perform the common
message handling, while the lower level states
inherit the commonality from higher level ones and
perform the state specific functions.
Hierarchical State Machine
State Design Patterns
Hierarchical State Machine
State Machine Inheritance
Collector State Pattern
Parallel Wait State Pattern
Serial Wait State Pattern
26. 26
Confidential
Commonly used patterns
• State Machine inheritance provides a powerful way
of teaching new tricks to an old state machine.
Consider a IncomingCall and OutgoingCall objects in
a call processing implementation. A lot of functionality
between the two call types is shared. This common
functionality could be implemented in a common Call
object. IncomingCall and OutgoingCall can inherit
from the Call object. The inheritance tree can be
refined by defining call objects based on the
signaling type. This would result in objects like
IncomingCall, OutgoingCall etc.
State Machine Inheritance
State Design Patterns
Hierarchical State Machine
State Machine Inheritance
Collector State Pattern
Parallel Wait State Pattern
Serial Wait State Pattern
27. 27
Confidential
Commonly used patterns
• The structure of this design pattern largely depends
upon the register programming model of the device
being programmed. In most cases, this design
pattern would be implemented as a single class
representing the device. In case of complex devices,
the device might be modeled as a main device class
and other subclasses modeling different parts of the
device.
• Hardware design pattern also known as:
Device
Hardware Interface
Peripheral Interface
Peripheral
Hardware Design Pattern
Hardware Design Patterns
Serial Port Design Pattern
HS Serial Port Design Pattern
Hardware Design Pattern
Synchronize Pattern
28. 28
Confidential
Commonly used patterns
• Different layers of the protocol are structured
(network layer, data-link layer, Physical layer).
Communication between layers takes place using
standard interfaces defined by the Protocol Layer
base class. All implementations of the protocol layer
inherit from this class. The inheriting layer classes
should implement the standard interfaces. The
standard interfaces are:
• Transmit is invoked by the upper layer to transfer a
packet to the lower layer.
• Handle Receive is invoked by the lower layer to
transfer a packet to the upper layer.
Protocol Layer
Protocol Design Patterns
Transmit Protocol Handler
Receive Protocol Handler
Protocol Packet
Protocol Layer
Protocol Stack
The lowest-level patterns are known as idioms - they typically describe how to implement specific aspects of components or the relationship between them, within the framework of just one programming language (e.g. writing an infinite loop). Another way to think of idioms is as the competent or elegant use of a programming language. If you master French vocabulary but still construct phrases in an English style, you won’t be using the language optimally. The same logic applies if you’re working with C++ and Python. Programming idiomatically is key to making code more readable and accessible to others.
At the other end of the spectrum are architectural patterns, which guide the development of an entire application. Again, the basic purpose is the same: to reuse and adapt basic design patterns - or in this case a sequence of them - that have been proven to work rather than try to reinvent the wheel every time you start a new software project. The term is sometimes used interchangeably with ‘architecture style’, and while there are overlaps, the key difference is that a pattern aims to solve a recurring problem (a style doesn’t necessarily need to solve anything). Common examples of architectural patterns include Microkernel, Microservices, Layered, and Space-Based Architecture (SBA). As we have previously written here, decisions over software architecture are typically made at the start of a project and influence everything from performance to security and scalability. Understanding which architectural patterns are best-suited to a certain business requirement - as well as how to apply and customize them for the specific situation at hand - is therefore crucial to successful software development.
The lowest-level patterns are known as idioms - they typically describe how to implement specific aspects of components or the relationship between them, within the framework of just one programming language (e.g. writing an infinite loop). Another way to think of idioms is as the competent or elegant use of a programming language. If you master French vocabulary but still construct phrases in an English style, you won’t be using the language optimally. The same logic applies if you’re working with C++ and Python. Programming idiomatically is key to making code more readable and accessible to others.
At the other end of the spectrum are architectural patterns, which guide the development of an entire application. Again, the basic purpose is the same: to reuse and adapt basic design patterns - or in this case a sequence of them - that have been proven to work rather than try to reinvent the wheel every time you start a new software project. The term is sometimes used interchangeably with ‘architecture style’, and while there are overlaps, the key difference is that a pattern aims to solve a recurring problem (a style doesn’t necessarily need to solve anything). Common examples of architectural patterns include Microkernel, Microservices, Layered, and Space-Based Architecture (SBA). As we have previously written here, decisions over software architecture are typically made at the start of a project and influence everything from performance to security and scalability. Understanding which architectural patterns are best-suited to a certain business requirement - as well as how to apply and customize them for the specific situation at hand - is therefore crucial to successful software development.
The lowest-level patterns are known as idioms - they typically describe how to implement specific aspects of components or the relationship between them, within the framework of just one programming language (e.g. writing an infinite loop). Another way to think of idioms is as the competent or elegant use of a programming language. If you master French vocabulary but still construct phrases in an English style, you won’t be using the language optimally. The same logic applies if you’re working with C++ and Python. Programming idiomatically is key to making code more readable and accessible to others.
At the other end of the spectrum are architectural patterns, which guide the development of an entire application. Again, the basic purpose is the same: to reuse and adapt basic design patterns - or in this case a sequence of them - that have been proven to work rather than try to reinvent the wheel every time you start a new software project. The term is sometimes used interchangeably with ‘architecture style’, and while there are overlaps, the key difference is that a pattern aims to solve a recurring problem (a style doesn’t necessarily need to solve anything). Common examples of architectural patterns include Microkernel, Microservices, Layered, and Space-Based Architecture (SBA). As we have previously written here, decisions over software architecture are typically made at the start of a project and influence everything from performance to security and scalability. Understanding which architectural patterns are best-suited to a certain business requirement - as well as how to apply and customize them for the specific situation at hand - is therefore crucial to successful software development.
The lowest-level patterns are known as idioms - they typically describe how to implement specific aspects of components or the relationship between them, within the framework of just one programming language (e.g. writing an infinite loop). Another way to think of idioms is as the competent or elegant use of a programming language. If you master French vocabulary but still construct phrases in an English style, you won’t be using the language optimally. The same logic applies if you’re working with C++ and Python. Programming idiomatically is key to making code more readable and accessible to others.
At the other end of the spectrum are architectural patterns, which guide the development of an entire application. Again, the basic purpose is the same: to reuse and adapt basic design patterns - or in this case a sequence of them - that have been proven to work rather than try to reinvent the wheel every time you start a new software project. The term is sometimes used interchangeably with ‘architecture style’, and while there are overlaps, the key difference is that a pattern aims to solve a recurring problem (a style doesn’t necessarily need to solve anything). Common examples of architectural patterns include Microkernel, Microservices, Layered, and Space-Based Architecture (SBA). As we have previously written here, decisions over software architecture are typically made at the start of a project and influence everything from performance to security and scalability. Understanding which architectural patterns are best-suited to a certain business requirement - as well as how to apply and customize them for the specific situation at hand - is therefore crucial to successful software development.
The lowest-level patterns are known as idioms - they typically describe how to implement specific aspects of components or the relationship between them, within the framework of just one programming language (e.g. writing an infinite loop). Another way to think of idioms is as the competent or elegant use of a programming language. If you master French vocabulary but still construct phrases in an English style, you won’t be using the language optimally. The same logic applies if you’re working with C++ and Python. Programming idiomatically is key to making code more readable and accessible to others.
At the other end of the spectrum are architectural patterns, which guide the development of an entire application. Again, the basic purpose is the same: to reuse and adapt basic design patterns - or in this case a sequence of them - that have been proven to work rather than try to reinvent the wheel every time you start a new software project. The term is sometimes used interchangeably with ‘architecture style’, and while there are overlaps, the key difference is that a pattern aims to solve a recurring problem (a style doesn’t necessarily need to solve anything). Common examples of architectural patterns include Microkernel, Microservices, Layered, and Space-Based Architecture (SBA). As we have previously written here, decisions over software architecture are typically made at the start of a project and influence everything from performance to security and scalability. Understanding which architectural patterns are best-suited to a certain business requirement - as well as how to apply and customize them for the specific situation at hand - is therefore crucial to successful software development.