ESWP3 - Embedded Software Principles, Procedures and Patterns¶

This project is about summarizing, referencing, structuring and relating principles, procedures (as sequences of patterns in a pattern language) and patterns in the context of embedded software engineering.

As “(P)atterns are only meaningful as part of a Pattern Language(.)” (Bergin 2013, pos. 74) this project tries also to “make” relations between different pattern languages and the higher-level principles “visible”.

MAY I HAVE YOUR ATTENTION PLEASE:

1) I setup a new website which lists and references resources to learn about embedded system development on http://awesome-embedded-systems.org. Feel free to visit and contribute to the project on GitHub by clicking on the “Fork me on GitHub” in the upper right corner of the main page.

2) I am playing around with some generic principle, pattern language and pattern mining project in my spare time here https://github.com/fkromer/p3 . Feel free to contribute and to join the journey of making pattern management public and as easy as possible.

Contents:

Principles¶

Categorization of principles¶

Many principles which has been discovered in the context of software development have a much broader scope. The following categorization tries to address this fact:

general

As little as possible, as much as needed

divide and conquer

Don’t repeat yourself (DRY)

Keep it simple, studid (KISS)

programming

object-oriented programming

SOLID (no principle, but a well-known mnemonic acronym for 5 basic principles)

Single responsibility principle (SRP)

Open/Closed principle (OCP)

Liskov substitution principle (LSP)

Interface segregation principle (ISP)

Dependency inversion principle (DIP)

All principles in alphabetic order¶

Balancing feedback loops lead to stability¶

Balancing feedback loops are equilibriating or goal-seeking structures in systems and are both sources of stability and sources of resistance to change (Mae 2008, p. 30 & p. 189).

category: systems

Change¶

Situations do exist in a static manner only for limited time frames. Change is regular and has to be considered everywhere. When a change occurs and you are forced to handle it the following adaption phase consumes energy. To keep the energy to be invested as minimal as possible prepare for change whenever possible.

Collaboration¶

Resulting context:
Context:	A problem influences at least one individual.
Problem:	The problem complexity or the work that has to be done to overcome the problem requires a lot of energy invest for the individual or can not be solved by an individual at all.
Solution:	Individuals which are influenced by the problem solve the problem together in a cooperative manner. Individuals which are not affected by the problem may contribute to the problem solving as well.
	The directly affected individual has to invest less energy to solve the problem or the problem is solveable in general. The individuals which are not influeced by the problem benefit from the collective somehow. There energy invest is less than their benefit from the collective. To manage the collaboration of the individuals additional communication of the individuals is required. The problem can be divided into managable subproblems by applying the principle “divide and conquer” (context domain, time domain, etc.).

Dependency inversion (DIP)¶

In contrast to the general dependency relation (high level abstraction may not dependent on low level details) regarding the modules interface low level modules may not depend on high level modules. As a result both should depend only on abstration.

Divide and conquer¶

This general principle eases the solution finding to a problem by breaking it apart. This can be in a variaty of dimension (context, spartial, time, etc.).

Don’t repeat yourself (DRY)¶

DRY is an acronym for “don’t repeat yourself”. The principle is related to the Single Responsibility principle.

Dynamic Equilibrium¶

If the sum of outflows equals the sum of inflows, the stock level will not change - it will be held in dynamic equilibrium (Mae 2008, p. 188).

category: systems

Effectiveness¶

Resulting context:
Context:	someone else (or yourself) discovers that the achieved result is not as high as the target was defined to be
Problem:	either the result is too low or the target definition to high
Forces:	circumstances definition of the target (attributes ~ SpecificMeasurableAchievableRelevantTimely)
Solution:	analyze the impact of the circumstances analyze the quality of the target definition if the circumstances and the target definition do have an impact that excuses the decreased/low effectiveness: explain which circumstances are relevant or which target definition attributes are relevant and why they do impact the effectiveness if the circumstances and the target definition do not have an impact that excuses the decreased/low effectiveness: - analyze if you “Do the right things.”: no: change your methodology! yes: you can try to compensate the lack of effectivness by increasing the efficiency
	you have to argue either way try to increase the efficiency applying the pattern efficiency

Efficiency¶

Resulting context:
Context:	you did have already applied effectivness (Do never apply efficiency before effectivness!!!) someone else (or yourself) figures out that the output in a given time and under unchanged circumstances is not as high as it could be related to a comparable “standard”
Problem:	either the result is too low or the effort too high
Forces:	circumstances
Solution:	analyze the impact of the circumstances if the circumstances do have an impact which excuses the decreased/low efficiency: explain which circumstances are relevant and why they do impact the efficiency if the circumstances do not have an impact which excuses the decreased/low efficiency: “Do the things right.” (Do not mix this with effectivness.)
	you do have to argue either way to do the things right: - you need to invest energy initially - you might need to invest energy continuoulsy - your efficiency is increased

Feedback loops are causal connections between stocks¶

A feedback loop is a closed chain of causal connections from a stock, through a set of decisions or rules or physical laws or actions that are dependent on the level on the stock, and back again through a flow to change the stock (Mae 2008, p. 27 & p. 189).

category: systems

Inflows rise stock¶

If the sum of inflows exceeds the sum of outflows, the stock level will rise (Mae 2008, p. 188).

category: systems

Interconnections Operate Through Information¶

Many of the interconnections in systems operate through the flow of information (Mea 2008, p. 188).

category: systems

Keep it simple, stupid (KISS)¶

Synomyms:	YAGNI (acronym for “You aren’t gonna need it”)

KISS is an acronym for “keep it simple, stupid”. This principle may not be missinterpreted in the context of software design: It does not mean not to design at all but to evolve the design dependend on the current requirements (As little as possible, as much as required).

ï»¿.. _magic_triangle:

Magic Triangle (Project Management Triangle)¶

Projects are constraint by three (plus one) attributes: - cost - scope / features - schedule - (quality)

The attributes cost, scope and schedule represent the corners of the triangle. The attribute quality represents the area which is span by the triangle.

Problem:

expecting a constant quality, one of the other attributes can not be changed without affecting the others (e.g. scope increases/decreases -> cost or schedule increases/decreases)

Resulting context:

expecting a constant quality the following combinations are possible: - Fast and Much (not Cheap) - Fast and Cheap (not Much) - Much and Cheap (not Fast)
... or if quality is included in scope/features the following combinations are possible: - Fast and Good (not Cheap) - Fast and Cheap (not Good) - Good and Cheap (not Fast)

More than its parts¶

A system is more than the sum of its parts. (Mea 2008, p. 188)

category: systems

Open/closed principle (OCP)¶

“Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification” (Bertrand 1988)

Outflows degrade stock¶

If the sum of outflows exceeds the sum of inflows, the stock level will fall (Mae 2008, p. 188).

category: systems

ï»¿.. _pareto:

Pareto¶

80 % of the result are achieved with 20 % of the effort. The remaining 20 % of the result require the remaining 80 % effort.

Purpose Detemines Behaviour¶

The least obvious part of the system, its function and purpose, is often the most crucial determination of the system’s behaviour (Mea 2008, p. 188).

category: systems

Redundancy¶

Context:

You depend on a subject with critical functionality whose absence or malfunction would lead to not managable problem in the overall system.

Problem:

The absence or malfunction of the subject leads to a malfunction of the overall system.

Solution:

“Use” more than one copy of the subject and implement a mechanism which allows to switch from one/all to one/the remaining subjects in case of the malfunction of one/many subject(s).

Use cases:

employees with key skills/in key positions
safety/availability critical software and systems

Resulting context:

The malfunction or absence of up to n-1 of the n copies of the subject do not result in a malfunction of the overall system. The probability of the system failing (probability of all redundant copies failing) \(p_{system}\) is \(p_{system} = \prod \limits_{i=1}^{n}p_{i}\) with \(n\) number of subjects and \(p_{i}\) probability of subject i failing.

Reinforcing feedback loops lead to growth or collapse¶

Reinforcing feedback loops are self-enhancing, leading to exponential growth or to runaway collapse over time (Mae 2008, p. 32 & p. 189).

category: systems

Separation of concerns (SOC)¶

This principle is related to the structural architectural and design patterns.

Single responsibility principle (SRP)¶

The “single responsibility” principle is the most granular form of the “separation of concerns” principle.

Stock acts as delay¶

Stocks act as delays or buffers or shock absorbers in systems (Mae 2008, p. 23 & p. 189).

category: systems

Stock decouples flows¶

Stocks allow inflows and outflows to be de-coupled and independent (Mae 2008, p. 24 & p. 188).

category: systems

Stock memorizes changing flows¶

A stock is the memory of the history of changing flows within the system (Mae 2008, p. 188).

category: systems

Structure Is Source Of Behavior¶

System structure is the source of system behavior. System behavior reveals itself as a series of events over time. (Mea 2008, p.188)

category: systems

Procedures (Pattern Languages)¶

Procedures are meant to be pattern languages. They shall point out how to apply several patterns of different levels of scope to solve a high-level problem in a sequential manner considering the balancing of forces which are influenced.

Categorization of pattern languages¶

The most obvious categorization scheme for pattern lanugages is related to the scope of optimization (~ pattern categories):

human relation pattern languages
build pattern languages
requirement pattern languages
design pattern languages
unit test pattern languages
tool pattern languages

All pattern languages in alphabetic order¶

Pattern Extraction Pattern Language¶

Before learning about specific patterns it makes sense to learn about how to extract patterns because “(w)riting patterns in your own field can change the way you think about that field(.)” and “(i)t can make you a better practititioner.” (Bergin 2013, pos. 74)

Following the basic, high abstraction procedure:

Identify the potential subject matter (Bergin 2013, pos. 107).

a: What structure needs to be created?

b: What problem need to be solved? E.g. problems during adding features to an existing software project occured. You want to build a better software design. Your subject is design patterns.

c: If you do not have ideas about a and b you (i) do not have enough expertise or (ii) you do not have access to it. If (i) is true take your time and try it again. If (ii) collect data beeing able to describe the best known solution related to the pattern.

Identify the format of the pattern description dependent on the subject matter (Bergin 2013, pos. 119).

a: Represent explicit meta-data as sections. E.g. name, context, problem, solution, implementation examples, etc. are common in technical subject matters.

a: Represent implicit meta-data as hints within sections. E.g. hints can crosslink different patterns even over subject matter boundaries which arehard to document in a structural manner. Think of object-oriented principles as patterns and a concret “implementation” with a design pattern.

b: Represent implicit meta-data typologically and structure the text regarding the explicit meata-data. E.g. The text is structured as paragraphs according to the explicit meta-data. Bold or italic text formatting makes implicit meta-data “visible”.

Define the sequencial structure how the meta-data is arranged. The relation between the meta-data should be as obvious as possible. E.g. the forces should follow the problem (Bergin 2013, pos. 185).

Optional, when pattern in relation to a pattern language: Identify the format of the pattern language. “The pattern language is (at least) a collection of patterns that work together and admit “sequences” of patterns that solve problems larger than those of the individual patterns.” (Bergin 2013, pos. 133)

Identify the forces which shall be resolved.

Priorice the forces which shall be resolved.

Identify patterns which address the problem to be solved considering the prioriticed forces. Begin with “large scale” patterns, end with “small scale” patterns. The resulting context after appliying a pattern has to fit the context before applying the next pattern.

Choose a representation which eases to get the “big picture”. The “big picture” can be communicated much easier with graphics.

Identify the content of the meta-data.

Identify the context. The context has to be about the situation “when” you consider using this pattern (Bergin 2013, pos. 164).

Identify the problem. The problem has to require action to be answered, should be recurring and should be expressed in a single sentence. Explanatory material should be avoided. Prefer a “stating” over “asking” formulation.

Identify forces. Think about “why” this solution is choosen. The solution should balance all forces which “(...) push in all directions and with different levels of intensity (...)” (Bergin 2013, pos. 208). Forces are important because it helps you to choose between different patterns, pattern variantions, implementation alternatives, etc. addressing the same context and overall resulting context related to the problem but with different weighting and consideration of the single forces. With forces the solution may be validated. E.g. quality attributes like scalability, complexity, maintainability, testability, etc. are forces which have to be balanced by a design pattern.

Identify a solution or solution alternatives. The “what” should be formulated as a single sentence.

Iterate over the extraction process. An example of this iterative process with different pattern versions and a discussion about each can be found in (Bergin 2013, pos. 410). More examples can be found (Bergin 2013, pos. 667).

Design Pattern Languages¶

All design pattern languages in alphabetic order¶

Build Automation Pattern Language¶

Configuration¶

Resulting context:
Context:	The behaviour of the application has to be defined equal in many use cases. and needs to be stored consistent.
Problem:	If CLIs do provide many arguments one gets confused very fast (the “cognitive limit of humans” is known to be 7 contexts). The principle of single responsibility is violated, because the application is stored in the calling scipts instead in relation to the application itself. The maintainanance effort of scripts which call these CLIs increase.
Forces:	configuration complexity overall IT infrastrutcure (“communication” with other applications over the configuration files)
Solution:	Store the configuration in a separate file.
	The behaviour of the script may be defined in a flexible manner. In many cases it is required to keep the application and specific configuration settings consistent over time. You may apply the versioning pattern to ease the consistent versioning of the application and its configuration(s).

File Handling¶

Path Handling¶

Embedded Unit Test Automation Pattern Language¶

The graphical representation of an Embedded Unit Test Automatio Language.

Unit Test Automation Framework Setup Pattern Language¶

The graphical representation of a Unit Test Automation Framework Pattern Language.

Unit Test Framework Tool Evaluation¶

Python Distribution Language¶

Application Distribution¶

Forces:	python experience of users

Server Side Distribution¶

Resulting context:
Context:	all potential users of the application have access to the global source control system
Solution:	store release versions of the project directory
	clients can download application from source control clean dependency encapsulation increases stability (virtual environment) overhead due to application specific virtual environment managed (activation/deactivation before/after each execution)

Python Exception Handling Language¶

(Philipps 2010, section 4 Expecting the Unexpected)

Exception¶

Resulting context:
Context:	develop new application maintenance of legacy application with bad debug-ability maintenance of legacy application with bad logging capabilities maintenance of legacy library/framework with bad useability
Problem:	communication of unusual circumstances/error conditions propagation of error conditions handling of error conditions without using input parameter checks
Solution:	create instances of exception classes in exception conditions
	increased debug-ability increased logging capabilities increased useability of libraries/frameworks for client programmers insignificant overhead

Built-in Exception Class Selection¶

Resulting context:
Context:	problem condition in a function/method needs to be raised with an exception
Problem:	there do exist excptions in the python standard library ... but it is not
	communicate the exception context no implementation and test overhead features for customized info available (~ exception class)

Customized Exception Class¶

Resulting context:
Context:	problem condition in a function/method needs to be raised with an exception
Problem:	no built-in exception suits the the exception context/condition
Solution:	create customized error class which inherit from Exception or BaseException
	increased readablility of error info

Self-Explaining Exception Class¶

Implementation Example:
Problem:	built-in exceptions do not suite the exception context
Solution:	create error class which inherit from Exception or BaseException just “pass” (in class body)
	Exception class which just “pass” to communicate inalid withdrawals in a banking application (Philipps 2010, section Definig our own extensions).
Resulting context:
	exception context is made obvious by exception class name no implementation and test overhead

Enhanced Exception Class¶

Resulting context:
Problem:	need to pass additional information in form of values instead of string
Solution:	create class with attributes which are set e.g. with __init__(self, <attributes>)
	increased cross-class/module communication capabilities client code may acces exception class attributes -> enhanced exception guided flow control

Intelligent Exception Class¶

Implementation Example:
Context:	problem condition in a function/method needs to be raised with an exception
Problem:	exception output may/needs to be derived from “input” values
	Exception class with __init__ overriding (balance, amount) “intelligently” derived attribute (overage) from it (Philipps 2010, section Definig our own extensions).
Resulting context:
	self-explaining exception name increased maintainability (just assignment of values instead of “info” string)

Exception Guided Flow Control¶

Implementation example:
Context:	you raise one or more exceptions in server code client code needs to act dependent on exception occured
Problem:	flow control of application needs to address raised exceptions
Solution:	use the
	Exception communication and exception guided flow control of classes addressing authentication and authorization of an web application (Philipps 2010, section Case study/page 112).
Resulting Context:
	no need to explicitly check input parameters inter-class communication of exception related information

Python Import Pattern Language¶

Import Pattern¶

Resulting Context:
Context:	need for funtionality which is already available as class, method or function defined in another module
Problem:	do not re-invent the wheel
Solution:	import at the beginning of the client file
	imported functionality may be used client code with more or less maintainability

Explicite Single Class Import¶

Resulting Context:
Context:	you need the funtionality of one class defined in another module
Solution:	import with from <module> import <class> access with <instance> = <class>() (Phillips 2010, section Modules and packages/page 43)
	good maintainability (you may locate the class in the other class) editor code completion is available naming conflicts can occur (-> use Explicit Renaming Single Class Import instead)

Explicite Renaming Single Class Import¶

Resulting Context:
Context:	you need funtionality of one class whose name is already used in your code
Solution:	import with from <module> import <class> as <renamed class> (Phillips 2010, section Modules and packages/page 44) access with <instance> = <renamed class>()
	no naming conflicts of imported classes

Explicite Multi Class Import¶

Resulting Context:
Context:	you need functionality of multiple classes from one module
Problem:	importing with “Single Multi Class Import” may blow up the file if imports are not sorted it is not obvious which classes are imported from which module
Solution:	import with from <module> import <class 1>, <class 2>, <class ...> access with <instance 1> = <class 1>()
	increased maintainability: obvious which classes are imported from the module naming conflicts of imported classes may occur (-> “Explicit Renaming Multi Class Import”)

Explicite Module Import¶

Resulting Context:
Context:	you need the functionality of the majority of the classes/functions in a module
Solution:	import with import <module> access with instance = <module>.<class>()
	good maintain: obvious where the classes come from better read-ability than “Explicite Multi Class Import” you will probably import something implicitly which you do not need

Python in-source code documentation pattern language¶

Automated command line interface documentation¶

Resulting context:
Context:	develop an application with command line interface maintain an application with command line interface in-source code documentation is generated with sphinx-doc in-source code documentation may be generated with sphinx-doc
Problem:	manual documentation tend to be outdated
Solution:	[sphinxcontrib.autoprogram](https://pythonhosted.org/sphinxcontrib-autoprogram/)
	CLI documenation is updated with every sphinx-doc

Automated RESTful HTTP API documenation¶

Context:	develop an application with RESTful HTTP application interface maintain an application with RESTful HTTP application interface in-source code documentation is generated with sphinx-doc in-source code documentation may be generated with sphinx-doc
Problem:	manual documentation tend to be outdated
Solution:	[sphinxcontrib.httpdomain](https://pythonhosted.org/sphinxcontrib-httpdomain/) for flask app use [sphinxcontrib.autohttp.flask](https://pythonhosted.org/sphinxcontrib-httpdomain/#module-sphinxcontrib.autohttp.flask) for bottle app use [sphinxcontrib.autohttp.bottle](https://pythonhosted.org/sphinxcontrib-httpdomain/#module-sphinxcontrib.autohttp.bottle) for tornado app use [sphinxcontrib.autohttp.tornado](https://pythonhosted.org/sphinxcontrib-httpdomain/#module-sphinxcontrib.autohttp.tornado)

UML diagram documentation pattern¶

Problem:

documentation of UML diagrams tend to be outdated with external tools

Forces:

generation type

automated generation from source code (usually just possible for structural diagrams)

generation from extension tool syntax

supported UML diagram types
dependencies to other python modules
dependencies to external tools

Automated UML diagram generation pattern¶

Implementation example:
	Generation of UML diagrams with the module pyreverse https://pypi.python.org/pypi/sphinx-pyreverse
Resulting context:
	You will have up-to-date documentation of UML diagrams whenever the sphinx-doc build is run.

Automated database model diagram generation pattern¶

Implementation example:
	Generation of database model diagram with the module sadisplay https://bitbucket.org/estin/sadisplay/wiki/Home
Resulting context:
	You will have up-to-date documentation of database model diagrams whenever the sphinx-doc build is run.

Inline UML diagram generation pattern¶

Implementation examples:
Forces:	experience of developers (with tool specific UML description syntax)
Solution:	Write the dagrams in tool specific syntax and let sphinx-doc render the output.
	Diagrams (sequence diagram, usecase diagram, class diagram, activity diagram, component diagram, state diagram, deployment diagram, object diagram, wireframe graphical interface = documentation of GUI elements) generated from PlantUML syntax with module sphinxcontrib-plantuml [https://pypi.python.org/pypi/sphinxcontrib-plantuml]. Diagrams from yuml syntax with module sphinxcontrib-yuml [https://pypi.python.org/pypi/sphinxcontrib-yuml]. Diagrams (block, sequence, activity, network) from blockdiag [http://blockdiag.com/en/#] syntax with modules blockdiag,seqdiag, actdiag, nwdiag.
Resulting context:
	no need for managing external files easy diffs of versions UML diagrams could outdate, but risk is not as high as with UML diagram file embedding pattern

UML diagram file embedding pattern¶

Implementation example:
Solution:	Embed external files of diagrams and let sphinx-doc render the output.
	Embedding of MS visio diagram files into the sphinx-doc documentation with module sphinxcontrib-visio [https://pypi.python.org/pypi/sphinxcontrib-visio] Embedding of TeX figures with the module sphinxcontrib-texfigure [https://pypi.python.org/pypi/sphinxcontrib-texfigure].
Resulting context:
	external files need to be managed (file names, locations, etc.)

Python Package Selection Pattern Language¶

Common Package Selection¶

Resulting context:
Context:	You whant to add functionality to a python application and the probability is high that someone else already implemented the same functionality.
Problem:	Implementing the functionality is often like reinventing the wheel because someone else already implemented the functionality and deployed it as a python module which may be imported into your project. If you whant to implement it stable regarding future maintenance and imrovement you need to invest a lot of time = money (CI environment for deployment, testing with different).
Forces:	supported Python versions supported dependent-on Python package supported dependent-on Python package versions # dependent on packages (critical if major python version changes) # packages of dependent on packages (critical if python version changes) application developer/maintainer experience with Python module experience of developers/maintainers package “source” quality (official repository?) maintainance quality (updates/time, # contributors to the project, downloads/time, issues/time, response time to issues, age of the project)
Solution:	search modules in “trusted sources” [e.g. https://pypi.python.org]
	if suiteable package found: be happy :) if no suiteable package found at all you need to implement it: “private” project “public”/open source project (github.com, bitbucket.com, ...) if familiar package found you may extend it: “private” extended project: “fork” it and add features do not push to public contribute to public project: same advantages like implementing it

Behavior Test Package Selection¶

Resulting Context:
Context:	You begin a new project or you need to add behavior/acceptance related tests for an already existing legacy project.
Problem:	BDD environment is critical for high quality python development
Forces:	build environment integration/plugins feature definition syntax step definition syntax
Solution:	Evaluate the currently available python modules regarding the forces. lettuce (Python 2 only) behave (Python 2 and 3, nose integration)
	run behavior/acceptance tests on projects per cli prerequisite for continuos deployment/CI environment

Unit Test Package Selection¶

Solution:	unittest (standard library package) nose (many plugins) pytest

Static Code Analysis Package Selection¶

Resulting context:
Context:	high reliability application application in the context of safety critical systems (build process) library implementation
Problem:	ensuring code quality manually without tool support is impossible static code quality may influence the reliability (which may not always been tested using unit test, integration test and acceptance test tools) static code quality influences design related quality attributes like maintainability, etc. (non-functional requirements)
Forces:	code analysis features file based configuration (for separate versioning ~ configuration management) programming “errors” code style (PEP8) integration with existing develop infrastructure (ADEs, IDEs, ...) integration with existing CI infrastructure (integration of report output into documentation or agile “dashboard”)
Solution:	Evaluate the currently available python modules regarding the forces. pylint (wide range of checks) [http://www.pylint.org/] PyFlakes (limited checks, no style checking, all python versions supported) [https://pypi.python.org/pypi/pyflakes] PyChecker (outdated!) [https://pypi.python.org/pypi/PyChecker] pep8 (only style guide) [https://pypi.python.org/pypi/pep8] mccabe (only McCabe complexity metric) [https://pypi.python.org/pypi/mccabe]
	run static code analysis on projects per cli prerequisite to integrate static analysis into CI environment

Build Package Selection¶

Resulting context:
Context:	You are setting up a new project or you already begun a new project. Having already a project you either do not have a build concept or you are unsatisfied with your current concept. You have already applied the “Python Module Selection Pattern”.
Problem:	If the build process of the python application is not automated you will miss important steps required to ensure a high quality deployment for sure.
Forces:	build features
Solution:	Evaluate the currently available python modules regarding the forces. The following modules are adressing relevant functionalities: paver (build/distribute/deploy) [http://pythonhosted.org/Paver/] Invoke (build/distribute/deploy) [http://www.pyinvoke.org/] SCons (build) [http://www.scons.org/]
	You can easily build, distribute and deploy your application running tasks (equal to make targets). Using one or several modules you are able to implement continuous integration up to continuous deployment.

Distribution Package Selection¶

Forces:	distribute features
Implementation:	distutils

Deploy Package Selection¶

Forces:

deploy features

ssh handling

Solution:

Fabric (Python 2.5-2.7 only) [http://www.fabfile.org/]

Version Compatibility Package Selection¶

Resulting context:
Context:
Forces:	compatibility ensured for object model!? compatibility ensured for syntax!?
	high probability for good support of different major python versions (e.g. Python 2.x and Python 3.x) encapsulated differentiations between implementations for different python versions (see “Single responsibility principle”) major dependence on version compatibility package in use

Command Line Interface Package Selection¶

Resulting context:
Context:	develop application whose functionality shall be accesible over a command line interface
Solution:	standard library module argparse
	easy creation of command line interface

Unittest Pattern Languages¶

All unittest pattern languages in alphabetic order¶

Safety Embedded C Unittest Pattern Language¶

The graphical representation of an Embedded C Unittest Pattern Language.

Python Unit Test Pattern Language¶

Patterns¶

This project is solution-oriented. Therefor no antipatterns or “smells” can be found explicitly. References to them are stated implicitly in the explicit meta-data Problem of specifc patterns instead.

Human Relation Patterns¶

The understanding and handling of human relations is definitely the most underestimated skill in all fields of live including the business of software engineering. ”...(a)About 85 percent...” of the financial success of people working in the field of engineering ”...is due to skill in human engineering...” (Carnegie 2010, chapter “How this book was written and why”).

This does not only concern people in management but also everyone in your company. You can even get the most for the people around you and yourself regarding everyone’s feeling and satisfaction in your private environment. Due to this fact this chapter is placed right at the beginning of the content.

Categorization of human relation patterns¶

Human relations patterns may be categorized accoring to the scheme of Carnegie (pattern names have been extracted partly as made-up words from corresponing chapters):

Fundamental Techniques in Handling People

Non-criticizer

Honest appreciator

Arouse in the other person an eager want.

Make people like you

Listener

Personal asker

Importantizer

Name remember

Smiler

Smart talker

Win people to your way of thinking

Appeal to the nobler motives.

Idea sympathetizer

Friendly starter

Dramatizer

“Yes” initiator

Fast admiter

Monolog moderator

Idea allocator

Respecter

Argument avoider

Smart looser

Point of view changer

Change people

Reserved asker

Begin with praise and honest appreciation. (Carnegie 2010, chapter “If you must find fault, this is the way to begin”)

Call attention to people’s mistakes indirectly.

Give the other person a fine reputation to live up to.

Talk about your own mistakes before criticizing the other person.

Let the other person save face.

Make the other person happy about doing the thing you suggest.

Praise the slightest improvement and praise every improvement. Be “hearty in your approbation and lavish in your praise.”

Use encouragement. Make the fault seem easy to correct.

All human relation patterns in alphabetic order¶

Argument avoider¶

The only way to get the best of an argument is to avoid it (Carnegie 2010, chapter “You can’t win an argument”)

Arouse in the other person an eager want.¶

(Carnegie 2010, chapter “He who can do this has the whole world with him. He Who cannot walks a lonely way”)

Don’t criticize, condemn or complain.¶

(Carnegie 2010, chapter “If you want to gather honey, don’t kick over the beehive”)

Dramatizer¶

Dramatize your ideas.

Fast admiter¶

If you are wrong, admit it quickly and emphatically (Carnegie 2010, chapter “If you are wrong, admit it”).

Friendly starter¶

Begin in a friendly way (Carnegie 2010, chapter “A drop of honey”).

Honest appreciator¶

Give honest and sincere appreciation (Carnegie 2010, chapter “The big secret of dealing with people”).

Idea allocator¶

Let the other person feel that the idea is his or hers (Carnegie 2010, chapter “How to get cooperation”).

Idea sympathetizer¶

Be sympathetic with the other person’s ideas and desires.

Importantizer¶

Make the other person feel important - and do it sincerely (Carnegie 2010, chapter “How to make people like you instantly”).

Listener¶

Be a good listener. Encourage others to talk about themselves (Carnegie 2010, chapter “An easy way to become a good conversationalist”).

Monolog moderator¶

Let the other person do a great deal of the talking (Carnegie 2010, chapter “The safety valve in handling complaints”)

Name rememberer¶

Remember that a person’s name is to that person the sweetest and most important sound in any language (Carnegie 2010, chapter “If you don’t do that you are headed for trouble”).

Non-criticizer¶

Donâ€™t criticize, condemn or complain (Carnegie 2010, chapter “If you want to gather honey, don’t kick over the beehive”)

Personal asker¶

Become genuinely interested in other people (Carnegie 2010, chapter “Do this and you’ll be welcome anywhere”).

Point of view changer¶

Try honestly to see things from the other person’s point of view.

Reserved asker¶

Ask questions instead of giving direct orders.

Respecter¶

Show respect to the other person’s opinions. Never say, “You’re wrong.” (Carnegie 2010, chapter “A sure way of making enemies - and how to avoid it”).

Smart looser¶

Throw down a challenge.

Smart talker¶

Talk in terms of the other person’s interests (Carnegie 2010, chapter “How to interest people”).

Smiler¶

Just smile (Carnegie 2010, chapter “A simple way to make a good first impression”).

“Yes” initiator¶

Get the other person saying “yes, yes” immediately (Carnegie 2010, chapter “The secret of socrates”).

Build Patterns¶

Categorization of build patterns¶

Build patterns may be categorized according to the following scheme (Osherove 2015).

Separation of concerns

Build Script Injection

Fill In The Blanks

Productivity

Accumulative Builds

Gated Commit

Incremental Feedback Loops

Pipeline Disintegration

Shipping Skeleton

Maintainability

Base Parameter

Extract Script

Fishbone Build Structure

Location Agnostic Script

Team Collaboration

Dependency Stash

Public API Hook

Tipping Point

Version by Snapshots Dependencies

Stakeholder

Deploy by Proxy

Parallel Fire-hose

Branching
Scalability

Fan Out Agents

Split to Parallel

Trustworthy

Binary Result

Irrelevant Build

Big Ball of Mud

All build patterns in alphabetic order¶

Accumulative Builds¶

The single responsibility principle applied to build scipts by using artifacts (results) of scripts as input for dependent scripts to decrease build time (Osherove 2015, chapter 7 “Accumulative Builds”).

CI Server Feature Requirements: artifacts

Build Script Injection¶

Separation of the knowledge about the build process and the source file structure by “injection” of the info into the root directory of the source control repository (Osherove 2015, chapter 3 “Pattern: Build Script Injection”).

Deploy robot¶

This most high-level build pattern sets the founation for the automation of the deployment process.

Resulting context:
Context:	Actually the project deliveries (software, documentation, etc.) are deployed manually. The start of a new project is right ahead an many with the same or a slightly different development toolchain will follow.
Problem:	In last projects the deployment of the software, documents, etc. took to much time an slowed down the development process.
Solution:	Automatize as much process steps as possible with a build environment.
Forces:	operating system compatibility tool compatibility developer prouctivity build server maintainance time to market
	The basis for automating process steps has been set. Time has to be invested to set up the build environment. But in this an all following projects the project team will be much more productive and the time to market will be decreased. The Is it automatable pattern could be applied next to identify what process steps may be automated.

Extract Script¶

Refactoring of duplicated script code into separate scripts with parameter or environment variable dependency which are called in the main script (Osherove 2015, chapter 13 “Extract Script”).

Fill In The Blanks¶

Parametrization of script knowledge about IT infrastructure, deployment, variants, etc. within build scripts (Osherove 2015, chapter 4 “Build Pattern: Fill In The Blanks”).

Gated Commit¶

The CI server performs a pre-build of the developers code requested to be checked in on the master branch and does only check in the code into source control if all tests pass (Osherove 2015, chapter 9 “Pattern: Gated Commit”).

Is it automatable¶

Context:	An automatic deployment environment shall be set up.
Problem:	It is not obvious what process steps may be automated.
Forces:	process steps manual signing (aka “i’am that incredible important and am not worried about slowing down the whole deployment process”) authority of roles envolved into the ooverall process implementation effort maintainance effort
Solution:	Ientify what deployment deliveries need to get reviewed manually. Identify what deployment documents need to get signed manually.

Location Agnostic Script¶

Ensuring that all information about server directories is available for the build script (Osherove 2015, chapter 12 “Build Pattern: Location Agnostic Script”).

Parallel Fire-hose¶

Bridging the physical connection between staging environment (server) an production environment (server) with an isolated deploy server in a demilitarized zone (Osherove 2015, chapter 21 “Pattern: Parallel Fire-hose”).

Pipeline Disintegration¶

A build process is set up in parallel to an existing build process to add additional features but not interfering the existing pipeline (Osherove 2015, chapter 6 “Pattern: Pipeline Disintegration”).

Public API Hook¶

Separation of API and logic of sw component to decoupe the dependency between sw components (Osherove 2015, chapter 19 “Pattern: Public API Hook”).

Shipping Skeletton¶

(Osherove 2015, chapter 5 “Pattern: Shipping Skeleton”)

Version by Snapshot Dependencies¶

Ensure that the build of a software component is only triggered if all builds of software components it depends on are build as “passed” (Osherove 2015, chapter 17 “Pattern: Version by Snapshot Dependencies”).

Requirement Patterns¶

Categorization of requirement patterns¶

Software requirement patterns may be categorized related to the context and/or according to software quality attributes as follows (Withall 2007):

Fundamental Requirement Patterns

Inter-System Interface Requirement Pattern

Inter-System Interaction Requirement Pattern

Technology Requirement Pattern

Comply-with-Standard Requirement Pattern

Refer-to-Requirements Requirement Pattern

Documentation Requirement Pattern

Information Requirement Patterns

Data Type Requirement Pattern

Data Structure Requirement Pattern

ID Requirement Pattern

Calculation Formula Requirement Pattern

Data Longevity Requirement Pattern

Data Archiving Requirement Pattern

Living Entity Requirement Pattern

Transaction Requirement Pattern

Chronicle Requirement Pattern

Information Storage Infrastructure

User Function Requirement Patterns

Inquiry Requirement Pattern

Report Requirement Pattern

Accesibility Requirement Pattern

User Interface Infrastructure

Reporting Infrastructure

Performance Requirement Patterns

Response Time Requirement Pattern

Throughput Requirement Pattern

Dynamic Capacity Requirement Pattern

Static Capacity Requirement Pattern

Availability Requirement Pattern

Flexibility Requirement Patterns

Scalability Requirement Pattern

Extendability Requirement Pattern

Unparochialness Requirement Pattern

Multiness Requirement Pattern

Multi-Lingual Requirement Pattern

Installability Requirement Pattern

Access Control Requirement Patterns

User Registration Requirement Pattern

User Authentification Requirement Pattern

User Authorization Requirement Pattern

Specific Authorization Requirement Pattern

Configurable Authorization Requirement Pattern

Approval Requirement Pattern

Commercial Requirement Patterns

Multi-Organization Unit Requirement Pattern

Fee/Tax Requirement Pattern

About the pattern meta-data¶

Some literature uses explicit meta-data Basic details, Applicability, Discussion, Content, Template(s), Example(s), Extra requirements, Consideration for development and Considerations for testing specific to requirement patterns (Withall 2007, chapter “The Anatomy of a Requirement Pattern”). Basic details include the Related patterns, patter classification and other information.

However this project uses the common explicit meta-data Context, Problem, Solution and Resulting context recommended for patterns in general by Bergin 2007. The meta-data (Basic details/)Related patterns mentioned before is “extracted”. Applicability is merged into Context, Discussion (How to write? Consider what?) and Content (What to state?) and Considerations for developement (How to implement?) into Solution. The meta-data Consideration for testing and Extra requirements (What are higher-level patterns? What lower-level patterns do follow?) into Resulting context. The meta-data Template(s) (How to implement?) is merged into Example(s).

Resulting context:
Context:	Describes the situation before applying the pattern.
Problem:	Describes the problem which leads to the Context.
Solution:	Describes how the Problem can be addressed.
	Describes the situation after applying the Solution.
Example(s):	Describes exemplary “implementations”.

All requirement patterns in alphabetic order¶

Chronicle¶

Specifies the requirement for recording a type of event in the life of the system (Withall 2007, chapter “7.4 Chronicle Requirement Pattern”).

Configuration¶

Specifies the requirement for parameter values which control the system behavior (Withall 2007, chapter “7.3 Configuration Requirement Pattern”).

Inquiry¶

Specifies a requirement for displaying static information on a screen to a user (Withall 2007, chapter “8.1 Inquiry Requirement Pattern”).

Inter-System Interface¶

Living entity¶

Specifies the requirement for an entity for which information is stored and which has a lifespan (creation, modification, optional termination) (Withall 2007, chapter “7.1 Living Entity Requirement Pattern”).

Standardized Textual Specification Pattern¶

Resulting context:
Context:	The only test case related to a textual documented requirement failed but it is not possible to identify the root cause.
Problem:	The requirement is not “traceable” because it includes several other requirements implicitly.
Solution:	Indentify the included atomic requirements. You must be able to formulate every requirement with a standardized textual description. Change the existing test case and add new test cases for the new requirements.
	The existing requirement and the new ones are traceable.

Standardized Textual User Story¶

Implementation example:
Context:	A textual representatioon of a user story does not point out the important issues “who”, “what” and “why”.
Solution:	Formulate the user story in standardized grammar format.
	“As a <role>, I want <goal/desire> so that <benefit>. ... As a Database Administrator, I should be able to revert a selected number of database updates so that the desired version of the database is restored.”(ISTQB Agile Tester Lesson 1 of 3, section “Format for creation of User Stories”/pos. 240).
Resulting context:
	It is more obvious who (role) is interested in the user story, what (goal) the user story shall address and why (benefit) it makes sense to be addressed.

Formal Review Pattern¶

Resulting context:
Context:	You try to extract a test case from a requirement but you do not understand the functionality despite you are experienced.
Problem:	The formulation of the
Solution:	Perform a manual review that verifies that a single requirement is unambiguous and specifies importance. In addition it verifies that the requirement characteristics pointed at with the “Standarized Textual Description Pattern” (unitary, complete, non-conjugated, verifiable) are satisfied.
	The

Safety/availablitiy-critical Formal Review Pattern¶

If the context is safety/availability-critical the person who performs the review has to be different from the person who wrote the requirement.

Transaction¶

Specifies the requirement for a type of event in the lifetime of an entity and or a function for entering such a transaction (Withall 2007, chapter “7.2 Transaction Requirement Pattern”).

Design Patterns¶

Categorization of “design” patterns¶

An obvious categorization scheme is accoring to the level of abstraction (Buschmann et al. 2001, chapter “The classification schema”).

Architectural
Design
Idioms

The literature adds further categorizations according to the patterns scope of influence regarding the level of abstraction (Gamma et al.). These schemas apply to the already mentioned architectural and/or design patterns.

subsystem and component patterns
class patterns
object patterns

Patterns may also be categorized according to their intend of optimization (Gamma et al. 1998).

creational

Abstract Factory

Builder

Factory Method

Prototype

Singleton

structural

Adapter

Bridge

Composite

Decorator

Facade

Flyweight

Proxy

behavioral

Chain of Responsibility

Command

Interpreter

Iterator

Mediator

Memento

Observer

State

Strategy

Template Method

Visitor

Threads may be added as scope of influence to the categorization of behavioral patterns (Douglass 2011, 2002).

threads (Douglass 2011, 2002)

It is possible to add the problem category as another dimension for categorization which applies to all level of abstractions like (Buschann et al. 2001, chapter “The classification schema”) :

From Mud to Structure
Distributed Systems
Interactive Systems
Adaptable Systems
Strucutral Decomposition
Organization of work
Access Control
Management
Communication
Ressource Handling

In the context of concurrency and networking the following schema related to the problem category may be applied (Schmidt et al. 2000, chapter “6.4 Pattern Languages vs. Pattern Systems”):

Base-line Architecture

Architectural

Broker

Layers

Microkernel

Communication

Architectural

Pipes and Filters

Design

Abstract Session

Command Processor

Forwarder-Receiver

Observer

Remote Operation

Serializer

Initialization

Design

Activator

Client-Dispatcher-Server

Evictor

Locator

Object Lifetime Manager

Service Access and Configuration

Architecural

Interceptor

Design

Component Configurator

Extension Interface

Half Object plus Protocol

Manager-Agent

Proxy

Event Handling

Architectural

Proactor

Reactor

Design

Acceptor-Connector

Asynchronous Completion Token

Event Notification

Observer

Publisher-Subscriber

Synchronization

Architectural

Object Synchronizer

Design

Balking

Code Locking

Data Locking

Guarded Suspension

Double-Checked Locking Optimization

Reader/Writer Locking

Specific Notification

Strategized Locking

Thread-Safe Interface

(Idioms)

(Scoped Locking)

Concurrency

Architectural

Half-Sync/Half-Async Producer-Consumer

Leader/Followers

Design

Active Object

Master-Slave

Monitor Object

Producer-Consumer Scheduler

Two-phase Termination

Thread-Specific Storage

Categorization related to the problem category specific to “(...) a number of subject areas of particular interest to embedded C developers(.)” (Douglass 2011, p. 78) may be applied as follows:

Design Patterns for Accessing Hardware

Hardware Proxy

Hardware Adapter

Mediator

Observer

Debouncing

Interrupt

Polling

Design Patterns for Embedding Concurrency and Resource Management

Scheduling

Cyclic Executive

Static Priority

Task Coordination Patterns

Critical Region

Guarded Call

Queuing

Rendevouz

Deadlock Avoidance Patterns

Simultaneous Locking

Ordered Locking

Design Patterns for State Machines

Single Event Receptor

Multiple Event Receptor

State Table

State

AND-States

Decomposed AND-States

Safety and Reliability Patterns

One’s Complement

CRC

Smart Data

Channel

Protected Single Channel

Dual Channel

Categorization related to the problem category in the architectural abstraction layer of embedded software (Douglass 2002) may be applied as follows:

Subsystem and Component Architecture Patterns

Layered Pattern

Five-Layer Architecture Pattern

Microkernel Architecture Pattern

Channel Architecture Pattern

Recursive Containment Pattern

Hierarchical Control Pattern

Virtual Machine Pattern

Component-Based Architecture

ROOM Pattern

Concurrency Patterns

Concurrency Pattern

Message Queuing Pattern

Interrupt Pattern

Guarded Call Pattern

Rendezvous Pattern

Cyclic Executive Pattern

Round Robin Pattern

Static Priority Pattern

Dynamic Priority Pattern

Memory Patterns

Memory Management Patterns

Static Allocation Pattern

Pool Allocation Pattern

Fixed Sized Buffer Pattern

Smart Pointer Pattern

Garbage Collection Pattern

Garbage Compactor Pattern

Resource Patterns

Critical Section Pattern

Priority Inheritance Pattern

Highest Locker Pattern

Priority Ceiling Pattern

Simultaneous Locking Pattern

Ordered Locking Pattern

Distribution Patterns

Shared Memory Pattern

Remote Method Call Pattern

Observer Pattern

Data Bus Pattern

Proxy Pattern

Broker Pattern

Safety and Reliability Patterns

Protected Single Channel Pattern

Homogeneous Redundancy Pattern

Triple Modular Redundancy Pattern

Heterogeneous Redundancy Pattern

Monitor-Actuator Pattern

Sanity Check Pattern

Watchdog Pattern

Safety Executive Pattern

Classification of idiomatic patterns¶

Idiomatic patterns may be classified according to their scope of optimization (Peterson 2010):

robustness

Array size by division

Compound types with {0}

Constants to the left

Sizeof to variables

expressiveness

Assertion context

Magic numbers as variables

Named parameters

Add the name space

Pattern Selection Procedure¶

The literature states the following schema to choose an appropriate pattern (Buschmann et al. 2001, chapter “5.3 Pattern Selection”):

Specify the problem
Select the pattern category
Select the problem category
Compare the problem descriptions
Compare benefits and liabilities
Select the variant
Select an alternative problem category

About the pattern meta-data¶

Implementation example:
Advantages:	In comparison with related patterns (e.g. Cyclic Executive Pattern vs. Static Priority Pattern).
Disadvantages:	In comparison with related patterns (e.g. Cyclic Executive Pattern vs. Static Priority Pattern).
	The implementation examples are not limited to the “embedded” domain. It is a good practice to transfer the examples to specific problems in other domains of software engineering.
Pattern dependences:
	If the pattern or a specific implementation variant requires the usage of another pattern.

All design patterns in alphabetic order¶

Abstract Factory Pattern¶

Creates families of related objects without depending on their specific classes.

Adapter Pattern¶

Makes two incompatible interfaces compatible.

Resulting context:
Context:	need for functionality which could be achieved by modifying or slightly extending preexisting code
Problem:	modifying preexinsting code is not efficient or if provided by a third partiy not possible adding “translating” code where ever the existing code is used adds code dublication which violates the DRY principle (with all its disadvantages -> increased risks for implementation errors, decreased maintainability, etc.)
Solution:	use a component (not neccessarily a class e.g. in strucutral languages) which “translates” between preexisting components the adapter compontent needs to implement the expected interface and maps the existing interface to it
	preexisting code can be used with a new interface implement the required functionality with less resources consumption (manpower, time, money)

Add the namespace¶

Idiomatic pattern emulates the programming feature “namespace” in languages not offering this feature.

Resulting context:
Context:	It is not obvious to what modules the functions in use belong to.
Problem:	Some programming languages lack the support for name spaces. This makes the programms harder maintain.
Forces:	maintainability redability
Solution:	Add a short version of the package/module/etc. name as prefix to its API funtions.
Example in C:	Add the name of the module (.c file) as prefix to its API funtions.
	The maintainability of the modules is increased. The trade-off is that the names are longer an the code where the functions are used harder to read.

Automated Administration Pattern¶

How can common administrative tasks be carried out consistently and automatically in response to pre-defined events?

(Erl 2015, p. 310)

Automatically Defined Perimeter Pattern¶

How can a perimeter be protected that is dynamic and extends from on-premise to multi-vendor cloud resources?

(Erl 2015, p. 425)

Bare-Metal Provisioning Pattern¶

How can operating systems be remotely deployed on bare-metal servers?

(Erl 2015, p. 305)

Broad Access Pattern¶

How can cloud services be made accessible to a diverse range of cloud service consumers?

(Erl 2015, p. 93)

Builder Pattern¶

Composition of a complex object consisting of different parts step by step.

Burst In Pattern¶

Compound pattern that establishes a system that retracts IT resources from an environment that has reached a low level of utilization.

(Erl 2015, p. 499)

Centralized Remote Administration Pattern¶

How can diverse administrative tasks and controls be consolidated for central remote access by cloud consumers?

(Erl 2015, p. 315)

Cloud Authentication Gateway Pattern¶

How can cloud-based IT resources be made accessible to cloud service consumers with diverse protocol requirements?

(Erl 2015, p. 430)

Cloud Authentication Pattern¶

Compound pattern which implements a security management system.

(Erl 2015, p. 505)

Cloud Data Breach Protection Pattern¶

How can organizations provide protection against data breaches for cloud data?

(Erl 2015)

Cloud Denial-of-Service Protection Pattern¶

How can cloud services be protected against denial-of-service attacks?

(Erl 2015)

Cloud Key Management Pattern¶

How can encryption keys be effectively managed for a cloud environment?

(Erl 2015)

Cloud Resource Access Pattern¶

How can cloud consumer attributes be made available to determine cloud resource access control in multiple proprietary clouds?

(Erl 2015)

Cloud Storage Data at Rest Encryption Pattern¶

How can cloud providers securely store cloud consumer data on cloud storage devices?

(Erl 2015)

Cloud Storage Data Lifecycle Management Pattern¶

How can data be stored and managed in a cloud environment based on a defined lifecycle?

(Erl 2015)

Cloud Storage Data Management Pattern¶

How can cloud consumers directly interact with data stored on a cloud storage device or provide access to other cloud consumers with appropriate permission levels?

(Erl 2015)

Cloud Storage Data Placement Compliance Check Pattern¶

How can cloud consumers ensure data is stored on a cloud storage device is physically located in a region that meets required compliance policies?

(Erl 2015)

Cloud Storage Device Masking Pattern¶

How can data stored on a cloud storage device be isolated to specific consumers?

(Erl 2015)

Cloud Storage Device Path Masking Pattern¶

How can data stored on a cloud storage device be isolated to specific consumers via certain pathways?

(Erl 2015)

Cloud Storage Device Performance Enforcement Pattern¶

How can data with different performance characteristics be stored on a cloud storage device compliant with the performance requirements of each dataset?

(Erl 2015)

Cloud Traffic Hijacking Protection Pattern¶

How can cloud communication be protected from traffic hijacking?

(Erl 2015)

Cloud VM Platform Encryption Pattern¶

How can VM backups, snapshots, and live migration be secured?

(Erl 2015)

Configuration File¶

Context:

The configuration of an application needs to be stored persistent.

Problem:

It is not obvious how to store the configuration.

Forces:

readability
editability
configuration data

data types (strings, integers, floating-point numbers, code)

data format (values, lists, objects)

Solution:

Store the configuration in a data file.

Resulting Context:

The configuration is stored persistent in a maintainable manner.

Constants to the left¶

Problem:	Instead of comparing variables against a value it may be assigned to the variable.
Solution:	The value to be compared against can be placed to the left of the comparison. The compiler does the verification and warns you if applicable.

Container Pattern¶

Abstracts away data structuring from application domain classes.

Implementation example:
	C++ - The Standard Template Library (STL) as part of the ANSI C++ provides many container and iterators.
Model example:	Generic model example with client (user of parts), iterator (mediates access to parts, inserts/delets parts), container (manages part collection, provides access operations) and two parts (data) (Douglass 1998, p. 271).

CRC Pattern¶

Adds a cyclic redundancy check to identify when bits of the data have been corrupted in vivo (Powell 2011, page 359).

Related patterns:
Use cases:	big memory segments complex data structures communication messaging in-memory error detection for harsh EMI environments in-memory error detection for mission-critical data
	One’s Complement Pattern
Implementation Alternatives in C:
	table-driven algorithm -> fast, bigger memory consumption (Powell 2011, page 369) polynominal calculation -> slower, smaller memory consumption (Powell 2011, page 369)
Implementation exmaple:
	C - Safety-relevant patient data (some structures) is linked to an alarm mechanism which triggers data specific alarm handlers if the data is identified as corrupted after setting or getting a data set (Douglass 2011, p. 369).

Critical Region Pattern¶

Serializing access from tasks on resources to prevent data corruption by disabling task switching.

Implementation example:
Advantages:	easy
Disadvantages:	high priority tasks which do not necessarily use the “critical” resource are blocked
	C - A task which manages a robot arm includes the movement of the robot arm as critical region (Douglass 2011, chapter 4.4.8).

Cyclic Executive Pattern¶

Minimalistic thread scheduling for hardware with limited resources (memory).

Use Cases:	The literature states the following use cases for this pattern (Douglass 2002, p. 156).

small systems
avionics flight systems

aircraft applications

spacecraft applications

Implementaion example:
Advantages:	simple
Disadvantages:	bad responsiveness to incoming events
	C - Gas flow application with 3 threads (updating the display, controlling a valve, measure gas flow) accessing the same data (configured gas flow, measured gas flow) of a data server (Douglass 2011, chapter 4.2.9).

Diagnostic Logger¶

Resulting Context:
Intend:	Separates logging from the rest of the application.
Context:
Problem:
Forces:	diagnostic messages must be accesible for whole application consistent look and feel easy to use specification of message destination order of messages specific (context) information retain information from one error to the next
Solution:	diagnostic logger (implemented as singleton) object handles logging handle different output types (cli, file) to subclasses

References:

Diverse Redundancy Pattern¶

Increase system reliability by providing several (2+n) redundant, but not identical channels.

Model example:	Generic 2 channel example in the context of safety-critical embedded systems with textual explanation (Douglass 1998, p. 230).

Dynamic Priority Pattern¶

Task scheduling by assignment and update of task priorities during runtime.

Implementaion example:
Advantages:	urgency (Douglass 2002, p.170)
Disadvantages:	criticality (Douglass 2002, p.170)
	C - Three threads (data acquisition, filtering, display) share the same two data sets (raw, processed) (Douglass 2002, chapter 5.10.8).

Dynamic Scalability Pattern¶

How can IT resources be scaled automatically in response to fluctuating demand?

(Erl 2015, p. 26)

Facade Pattern¶

Factory Method Pattern¶

Defines an interface for creating an instance of an object but lets the class which implements the interface decide which class to instantiate.

Guarded Call Pattern¶

Implementaion example:
Advantages:	better responsiveness (compared to Queueing Pattern) does not interfere with the execution of higher priority tasks that don’t need access to the resource (compared to Critical Region Pattern)
Disadvantages:	if not combined with other patterns the naive implementation/use can result in unbounded priority inversion
	C - The attitude and position sensors of an aircraft (data servers) are accessed by a attitude control, a data displayer and a position control (data clients) (Douglass 2011, chapter 4.5.8).

GUI-wrapped Configuration¶

An idiomatic variation of the wrapper pattern which uses a gui as wrapper for the textual application configuration for more safe and user friendly configuration.

Context:	You have an application which uses one or several textual configuration mechanisms.
Problem:	Textual configurations are often missused by the user. It is possible to inform the user about the error but the response is not immediate and the actual reason for the error not obvious.
Solution:	Use a graphical user interface to wrap the configuration. Analyze the textual entries entered, inform about errors and give advice for correct usage to the user immediatelly. If the entries are correct override the configuration with the new values.

Homogeneous Redundancy Pattern¶

Increase system reliability by providing several (2+n) redundant and identical channels.

Model example:	Generic 2 channel example in the context of safety-critical embedded systems with class diagram and sequence diagram (Douglass 1998, p. 229).

Identify By Version Pattern¶

Resulting context:
Context:	begin develop an application begin develop a library
Problem:	the version of an application is critical for client systems
Solution:	print the version over the cli ... or make it visible to users over a GUI tab e.g. application/help/about
	the version of the application may be checked by client systems the version of the application may be observed by users
Implementation example:
	Python - Print the version of an application over its command line interface (Lott 2014, section “–version display and exit”).

INI Configuration File Pattern¶

Idiomatic pattern to store configuration data of an application in an .ini file.

Resulting Context:
Context:	You need to configure an application with data in simple data types and simple data format on a windows operating system.
Problem:	See parent design pattern, Configuration File
Forces:	See parent design pattern, Configuration File
Solution:	Use the .ini configuration file format to store the configuration.
	The configuration is stored in a format which is easy to read. Due to the similarity with the windows .ini file format the interoperability with this operating system is good.
Example in Python:
	Use the python standard library module configparser to manage .ini like configuration files.

Iterator Pattern¶

Implementation Alternatives in Python:
	package itertools from the python library class with __iter__() and next() method (compare iter() method of library classes) generator function that returns sequence of returns instead of single valueyields

Layer Pattern¶

Organizes the software components in a hierarchical manner based on their level of abstraction.

5-Layer Architecture¶

A variant of the Layer Pattern with 5 components common for embedded and real-time systems (Douglass 2002, chapter 4.2) is separated into:

Application,
User Interface,
Communication,
Abstract OS,
Abstract HW.

The communication is not uni-directional as usual for the “strict” Layer Pattern.

Model example:	C - An ECG monitor is composed of the software components ECG, Alarm, Trend, Data Transport, User Interface (5-tier Pattern) whose communication is not unidirectional “from top to bottom” (Douglass 2002, chapter 4.1.8).
Model example:	C - A ventilator consists of the Ventilator Application, the Graphical User Interface, Communication (CAN, Corba), the RTOS vxWorks and the ventilator hardware abstraction (Douglass 2002, chapter 4.2.8).

Magic numbers as variables¶

Problem:	Magic numbers are bad.
Solution:	Instead of using #defines the handling of magic numbers may increased further by defining constant variables. The tradeoff is memory size against code maintainability.

Mediator Pattern¶

Centralization of the coordination of other components.

Implementation example:
	C - Manager (mediator) for the coordination of the subcomponents (rotating joints, sliding joints, etc.) of a robot arm in C (Douglass 2011).
Implementation example:
	C++ - Management of the update of Dialog elements (button, list box, entry field) in a graphical user interface (Gamma et al. 1995, chapter “Mediator”).

Model-View-Controller Pattern¶

Separates the application (or part of it) into the parts model (data and logic), view (HMI) and controller (links the model and the view).

Multiple Event Receptor Pattern¶

Handling of synchonous events from a single event server using an event receptor for each event (multiple event receptor finite state machine).

Implementation example:
	C - Tokenizer for floating point number strings implemented as synchronous state machine with events (digit, white space, dot, end of string) triggered by the client (Douglass 2011, chapter 5.4.8).

Namend parameters¶

Problem:	C does not support named parameters as language feature.
Solution:	It is possible to emulate this feature by assigning a value to a variable while handed over as function parameter. The readabiliby of the code is increased.

Observer Pattern¶

Notification of clients about the status of a data server.

Implementation example:
	C - Gas data (server) of a gas sensor is observed by a display, gas mixer and a safety monitor (clients) in C (Douglass 2011, chapter 3.5.8).
Implementation example:
	C++ - System time (server) is observed by a digital and an analog clock (clients) in C++ (Gamma et al. 1995, chapter “Observer”).

One’s Complement Pattern¶

Adds a bitwise inverted copy of primitive data elements to identify when data is corrupted in vivo (Powell 2011, page 359).

Implementation Alternatives in C:
Use Cases:	small safety/availability-critical data structures simple safety/availability-critical data structures primitive safety/availability-critical data types static variables in safety/availability-critical functions
	~ operator for primitive data types + iteration over all primitive data types (Powell 2011, page 363) macro encapsulated conversion operation for primitive data types + iteration over all primitive data types
Implementation Alternatives in Python:
	conversion of class data: @property decorator to use setter/getter methods like class properties -> good: same access syntax like attributes conversion of class data: explicit private setter/getter methods -> bad: other access syntax than attributes
Implementation Examples:
	C - The safety-relevant aircraft attitude (roll, yaw, pitch) is linked to an alarm mechanism which triggers an alarm handler (~ whole attitude data) if one of the data elements is identified as corrupted after getting the data set (Douglass 2011, p. 364)

Ordered Locking Pattern¶

Prevention of resource-based deadlock by forcing ordered locking of resources.

Implementation strageties:
	This pattern is implemented with one type of resource ID assignment (dynamic or design-time) and one or both types of resource access (dyadic or monadic).

Dynamic resource ID assignment means that IDs are dynamically assigned to resources during runtime.

Design-time resource ID assignment means that IDs are assigned to resources during compile-time.

Dyadic access means that the resource client does explicitly need to lock and unlock the resource.

Monadic access means that the resource client does not need to unlock the resource (implicitly locked and unlocked).

Implementation example:
Advantages:	easy (resource ID assignment: dynamic) difficult for big systems (resource ID assignment: design-time) flexible (access: dyadic)
Disadvantages:	unsafe (resource ID assignment: dynamic) safe (resource ID assignment: design-time) unflexible (access: monadic)
	C - The attitude, velocity and position sensors of an aircraft (data servers) are accessed by a kinematic and a route planing control (data clients) (Douglass 2011, chapter 4.9.8).

Pipes and Filters Pattern¶

Pre Buffered Logging¶

An idiomatic pattern which buffers information which has been logged before the actual log location and configuration is known.

Context:	You have an application which has to log info right from the beginning of the application. The location and configuration of the log shall be configurable application with a configuration which is read right at application startup.
Problem:	There may not be logged info before the location and configuration of the logger is known by the application.
Solution:	Create a logger right at the beginning of the application. Log into there until the logger location and configuration is known by the application. “Override” the pre buffer logger, log into there from now on and merge the pre buffered logs into the final log.

Prototype Pattern¶

Creation of an exact copy of an object.

Proxy Pattern¶

Standardization of component interface for better maintainability.

Implementation example:
	C++ - An interface for graphical objects (proxy) may be used by the application (client) to access the implementation of a image class (Gamma et al. 1995, chapter “Proxy”).

Hardware Proxy¶

In the driver layer or HAL the access on hardware is encapsulated in a component.

Implementation example:
	C - A motor (hardware) is accessed over an interface independent of the hardware-interface providing the control of speed and direction and monitoring the status (hardware proxy). The hardware is accessed per 16-bit wide memory-mapped interface (Douglass 2011, chapter 3.2.8).

Remote Proxy¶

In distributed systems software may access neighbor systems as remote “device”.

Security Proxy¶

In security applications it may be required to hold all component data within the application in encrypted status. The data representation/format may not be encapsulated within the proxy as usual then.

Python abstract base class pattern¶

Context:	You are going to implement a python library which will be used by other developers frequently.
Problem:	application classes which do not exactly implement a predefined API chrash applications which use these API application classes need to be implement according to pythons built-in features to beeing able to integrate seamlessly with python
Solution:	define abstract superclasses (parent classes) whose API have to be implemented by application classes (child classes) >=python2.6: use the module collections.abc from the python standard library <=python2.5 [https://dbader.org/blog/abstract-base-classes-in-python] class Base: def foo(self): raise NotImplementedError() def bar(self): raise NotImplementedError() class Concrete(Base): def foo(self): return “foo() called” # Oh no, we forgot to override bar(). # def bar(self): # return “bar() called” >>> c = Concrete() >>> c.foo() 'foo() called' >>> c.bar() NotImplementedError >>> b = Base() >>> b.foo() NotImplementedError

Round Robin Pattern¶

Implementation example:
	C - Two tasks (monitor, display) are scheduled with time-controlled preemption (Douglass 2002, chapter 5.8.8).

Safe OOP emulation¶

Implementation example in C:
Context:	Complex safety/availability-critical software for hardware with limited stack/heap shall be written in a structural programming language shall be run on hardware with limited stack/heap
Problem:	A programming language with object oriented features would ease the development, maintainability of the software.
Solution:	Implement the OO features you need in the language in use.
	The standard library functions (malloc(), free()) which could be used to implement OOP are know to be not “safe”. In addition this standard library functions have been implmented in the “personal computer” context and do not consider the fragmentation of memory which can lead to a crash of the software. Implement own versions of the functions (malloc(), free()) with safety/availability
Resulting context:
	Basic OOP capabilities (create, modify, destroy instance of an object) can be used and speed-up development.

Safety Executive Pattern¶

Centralized coordination of safety monitoring and system recovery from faults.

Other names:	Safety Kernel Pattern
Model example:	Generic example of a safety object (safety policies and measures), watchdog (observe subsystem response), 2 subsystems and a fail-safe channel (fault recovery) in the context of safety-critical embedded systems with class diagram and sequence diagram (Douglass 1998, p. 235).

Single Event Receptor Pattern¶

Handling of asynchronous or synchonous events from a single event server using one event receptor for all events (single event receptor finite state machine).

Pattern dependences:
	Asynchronous version -> Queueing Pattern Synchronous version -> Guarded Call Pattern
Implementation examples:
	C - Tokenizer for strings holding floating point numbers implemented as asynchronous and as synchronous event handling state machine in C (Douglass 2011, chapter 5.3.8).

Singleton Pattern¶

Ensures that only one instance of a class may be created.

Sizeof to variables¶

Problem:	During the memory assignment of variables the data type of the variable has to correspond to the datatype handed over to the function sizeof(). During code evolution it may occur that not both sides of the assignment are kept redundant.
Solution:	Use the variable itself instead of the data type of the variable as parameter for sizeof().

Smart Data Pattern¶

Idiomatic pattern implements self-checking data types to satisfy defensive programming. Adds behavior to the data to ensure that the data’s preconditions and constraints are adhered to (Douglas 2011, page 359).

Implementation alternatives in C:
Context:	Requirements state there shall be implemented “safe” module or class data. Or the software does not behave as expected during unit testing and the lack of requirements mentioned before has been identified as the root cause.
Use cases:	safety/availability-critical data
	functions included from a util module to implement checks #defines included from a util module to implement checks smart data classe per data type (Douglas 2011, chapter “6.4.3 Pattern Structure”)
Forces:	performance memory usage heap usage testability debugability useability reusability
Examples in C:	Self-checking patient data (when initialized and set) encapsulates a smart integer data type (weight, age, heart rate, etc.) and a smart enumeration data type (patient condition visualization). If a data range is violated the corresponding error handler is called (Douglas 2011, chapter “6.4.8 Examples”)
Resulting context:
	The unit tests addressing defensive programming issues related to the data PASS.

Smart Pointer Pattern¶

Eliminate/mitigate problems introduced by the manual use of raw C/C++ pointers.

Model example:	Generic example of a client (user of the smart pointer), smart pointer (valid initialization, memory deallocation, refuse access to deleted pointer location) and server (data source) with class diagram, sequence diagram and textual explanation (Douglass 1998, p. 271).

State Pattern¶

Static Priority Pattern¶

Task scheduling using priorities.

Implementation example:
Advantages:	simplicity (Douglass 2002, p. 163) stability in sense of predictability of failing tasks in an overload situation (Douglass 2002, p. 164) optimality, you can’t do better with other scheduling strategies (Douglass 2002, p. 164) scale-ability for large amounts of tasks (Douglass 2002, p. 163) analyze-ability for schedule-ability e.g. with the standard rate monotonic analysis methods (Douglass 2011, p. 170) responsiveness to urgent asynchronous events (Douglass 2002, p. 163)
Disadvantages:	naive implementation with blocking resource sharing can lead to unbounded priority inversion (Douglass 2011, p. 170)
Model example:	C - Three threads (data acquisition, filtering, display) share the same two data sets (raw, processed) (Douglass 2002, chapter 5.9.8).
	C - The motor position sensing, the display of info and the motor control encapsulated in tasks of a RTOS (Douglass 2011, chapter 4.3.8).

Transaction Pattern¶

Ensures reliable communication over an unreliable communication channel.

Model example: Generic example of a source (message source), sender (marshals, creates/destroys, send transactions), send transaction (tracks # ALO or EO message transmits and retry period), message (metadata and data), receiver (demarshals, creates/destroys receive transactions), receive transaction (tracks # EO message receives, TimeToLive handling) and target (message destination) with class diagram, sequence diagram for an EO transaction and textual explanation (Douglass 1998, p. 265). (BTW: AMO messages do not require the creation of send and receive transactions.)

Watchdog Pattern¶

Ensure hard-real time conform functionality of the system.

Model example:	Generic example of a watchdog observing a channel in the context of safety-critical embedded systems with class diagram and sequence diagram (Douglass 1998, p. 233).

Unit Test Patterns¶

If and how the patterns may be applied in your actual situation strongly depend on the unit test tool which is used. In the context of safety-critical software it is common to use full-feature unit test tools. In this case you do not have to worry about a lot of the problems which are addressed by some unit test pattern categories related to “manage the test harness yourself” test frameworks (e.g. xUnit Basics Patterns, Test Organization Patterns). As “non-open-source” unit test tools in C/C++ implement the “Test Automation Framework” unit test pattern some Unit Test Patterns could be already implemented by the tool:

Assertion Method

Automated Teardown

Chained Tests

Configurable Test Double

Creation Method

Data-Driven Test

Delegated Setup

Delta Assertion

Implicit Setup

Implicit Teardown

In-line Setup

In-line Teardown

Prebuilt Fixture

Scripted Test

Standard Fixture

Test Discovery

Test Double

Test Runner

Test Selection

Testcase Object

Unfinished Test Assertion

The basics for the functionality of the following patterns are implemented by most “non-open source” unit test tools for C but some implementation work is left to the tester:

Behavior Verification

Derived Value

Fake Object

However it may be hard or even possible that some patterns can not be implemented with full-fledged test frameworks due to their architecture:

Lazy Setup

Minimal Fixture

Mock Object

Testcase Class (~ C++)

Testcase Class per Class (~ C++)

Testcase Class per Feature (~ C++)

Testcase Class per Fixture (~ C++)

Testcase Superclass (~ C++)

In the safety/availability-critical contexts some patterns are not appliable because the production code may be not modified before, during or after test execution:

Test Hook

Beside of this “i do not have to care about the pattern implementation” it is important to know the patterns to get an idea about the tool in use can be used as efficient as possible. However some pattern categories may be relevant independent of the tool in use and the business domain (e.g. Value Patterns).

Categorization of unit test patterns¶

According to the problem context one can categorize unit test patterns like follows (Meszaros 2007, chapter “Contents”).

Test Strategy Patterns

recorded test

scripted test

data-driven test

test automation framework

minimal fixture

standard fixture

fresh fixture

shared fixture

back dooor manipulation

layer test

xUnit Basics Patterns

test method

four-phase test

assertion method

assertion message

testcase class

test runner

testcase object

test suite object

test discovery

test enumeration

test selection

Fixture Setup Patterns

in-line setup

delegated setup

creation method

implicit setup

prebuilt fixture

lazy setup

suite fixture setup

setup decorator

chained tests

Result Verification Patterns

State verification

Behaviour verification

custom assertion

delta assertion

guard assertion

unfinished test assertion

Fixture Teardown Patterns

garbage-collected teardown

automated teardown

in-line teardown

implicit teardown

Test Double Patterns

test double

test stub

test spy

mock object

fake object

configurable test double

hard-coded test double

test-specific subclass

Test Organization Patterns

named test suite

test utility method

parameterized test

testcase class per class

testcase class per feature

testcase superclass

Database Patterns

database sandbox

stored procedure test

table truncation teardown

transaction rollback teardown

Design-For-Testability Patterns

dependency injection

dependency lookup

humble object

test hook

Value Patterns

Literal Value

Derived Value

Generated Value

Dummy Object

Value Patterns may be categorized further regarding the unit test context:

whitebox patterns

Has it been called

Has it not been called

blackbox patterns

In/out range check

Inverse data structures

About the meta-data¶

Equivalent to other (code) smells indicating bad practice there also some smells aka “Unit Test Antipatterns” related to unit tests (Meszaros 2007, chapter “Contents”). Whenever one of the following smell occurs the design of the unit test should be refactored.

Code Smells

obscure test

conditional test logic

hard-to-test code

test code duplication

test logic in production

Behavior Smells

assertion roulette

erratic test

fragile test

frequent debugging

manual intervention

slow tests

project smells

buggy tests

developers not writing tests

high test maintenance cost

production bugs

However because this project is solution-oriented and not problem-oriented this antipatterns will only be referenced as implicit meta-data in the Problem section.

All unit test patterns in alphabetic order¶

Cause-Effect Graphing¶

Low level “helper pattern” to make

Classification-tree method¶

High level informal test design pattern for systematic definition of blackbox tests.

Resulting Context:
Context:	There is no good test basis (specifications, etc.) available to define blackbox test cases but the tester has some or good (dependent on the quality of the test basis) knowledge of the system under test.
Problem:	It is required to verify if a function/method has been called.
Solution:	Apply the classification-tree method (CTM). The CTM includes the application of the equivalence partitioning pattern to define the aspect related classes of input values.
Model example:	Test cases for software which controls the speed of a car dependent on different aspects of the input domain (own speed difference “shall” and “is”, actual speed, car ahead?, speed difference to car ahead, distance to car ahead) are designed (Broekman and Notenboom, section “11.5 Classification-tree method”).
	Blackbox test cases are designed in a strucutured manner with a wide variaty of possible # of test cases (minimal ~ # lowest level aspects, maximal ~ # of all possible combinations of aspect value classes).

Database ORM relation test pattern¶

Implementation example in Python:
	The relation of a object relational mapped class (with module sqlalchemy) to a SQLite datase is tested (Lott 2013, pos. 9917).

Equivalence Partitioning¶

Execution time test pattern¶

Implementation example in Python:
	Test of method/function execution time (python standard library modules unittest, timeit) (Lott 2013, pos. 10096)

Function wrapped macro pattern¶

Context:	You need to implement time critical functionality or functionality related to hardware access in safety-critical software.
Forces:	complexity of functionality where does the funtionality need to be called? execution time stack consumption
Problem:	In some situations (e.g. time critical functionality) it is required to implement functionality as defines/macros which are “resolved” (inserted as “string”) at compile time. If macros are called directly from within the UUTs this lead to trouble during whitebox unit testing: To beeing able to access every function path it is required to manipulate the macros “output” (return, manipulation of global data, e.g.). In other cases it is required to spy the macros input parameters. In all cases for every combination of the macro “manipulation” there needs to be compiled a different test harness which increases the unit test maintenance effort.

Solution:: Implement a function for every macro as wrapper.

Resulting context:
	additional function call increases stack usage (slightly) additional function call increases execution time (influence ~ complexity of macro functionality) macro needs to be tested

Has it been called¶

Idiomatic pattern to verifiy that a function/method has been called.

Problem:	It is required to verify if a function/method has been called.
Use cases:	Common functionality verification error handling functions in safety-critical software
Solution:	(a) If the function has no parameters a help variable of the test harness may be used and be modified in the stubbed function. (b) If the function has input parameters they can be defined as expected values.

Has it not been called¶

Idiomatic pattern to verifiy that a function/method has not been called.

Problem:	It is required to verify that a function/method has not been called.
Use Cases:	common functionality verification error handling functions (macros are also very common in C) in safety-critical software
Solution:	Compare the solution of “Has it been called”.

In/out range check¶

Problem:

The API of a function/method shall be verified.

Solution:

Define the following input values for every input parameter:

minimal value (related to intended parameter range) - 1

mid value (related to intended parameter range)

maximal value (related to intended parameter range) + 1

To every combination of parameter input values a (a) return value or (b) output parameter is expected to have an expected value.

Consider that some programming languages support more than one return parameter (e.g. Python).

Inverse data structures¶

Idiomatic unit test pattern to verify redundant data structures holding inverse values.

Problem: Redundant data structures (variables, structures, etc.) holding bit-inverted values during runtime are required in safety-critical contexts. It is also required to check the correctness of this data strucutures periodically and to call an error handling if the redundance is violated. The related if-else structures decrease the code coverage if not considered.

Solution: Define inverted values as input value for the checking functions dependent on the data type of the variable. The value range of unsigned data types is 0..(2*n)-1 with n = # bits. So the bit-interted value of an e.g. 8-bit unsigned integer (0..255) of 1 is 254. The range of signed data types with two’s complement representation is -2*(n-1)..0..2*(n-1)-1 wit n = # bits. So the bit-inverted value of an e.g. 8-bit signed integer (-128,..,-1,0,+1,..,127) of 5 is -6.

Memory Corrupting Output Buffer¶

Idiomatic pattern which tries to corrupt the memory through the output parameter of a function/method (Greening 2011, p. 40).

Resulting context:
Context:	You have to write a unit test for a function/method with an output parameter pointing to buffer.
Problem:	You do not know how to test if the memory in front of the buffer is corrupted after the function is called.
Solution:	Write a unit test which sets the start element of the buffer to element[1] and make the buffer one element larger. After calling the function the element[0] has to contain the same data.
	You know if the functions output parameter does corrupt the memory in front of the parameter.

Mock¶

Hardware Mock¶

Emulatate the bevahior of hardware in software.

Resulting context:
Context:	A driver function which shall be unit tested accesses real hardware during its execution.
Problem:	The execution of the unit test depends on the availability/existence of hardware.
Solution:	Emulate the behavior of the hardware in software.
	The unit test of the driver function is decoupled from the actual hardware. The unit test may be executed before actual hardware is available/existend for testing.
Implementation example:
	C - Link-time mock of a flash driver with the mock object extension “CppUMock” of the unit test framework “CppUTest” (Greening 2011, section “10.1 Flash Driver”). C - Fake-stub of the processor I/O registers of a LED driver in the unit test framework “CppUTest” (Greening 2011, p. 58).

Spy¶

Observe the behaviour of a CUT.

Resulting context:
Context:	The behavior of a CUT shall be observed over time.
	Events related to the CUT may be observed over time.
Implementation examples:
	C - Spy observes the print output of a circular buffer [Greening 2011, section “9.4 Verifying Output with a Spy”]

State Transition Testing¶

High level pattern for systematic derivation of test cases for state based behavior (unit/component/system).

Resulting Context:
Context:	A function or a collection of functions which has not been generated automatically with a model-driven approach (assuming a high code generation quality STT would not detect any faults) has state-based behavior. The behavior is represented as table, activity chart or state chart in the test basis.
Problem:	19 faults categories exist in the context of state based behavior in total. 15 of them may be detected with state transition testing when designed with care. The remaining (Broekman and Notenboom 2003, section “11.2.1 Fault Categories”) It is not obvious how to derivate test cases to detect for
Solution:	compose the state-event table compose the transition tree compose test script legal test cases compose test script illegal test cases compose the test script guards
Model example:	Test cases for the state chart of a video cassette recorder are derived (Broekman and Notenboom 2003, section “11.2.2.2 Composing the state-event table”).
	15 of the 19 fault categories related to state-based behavior can be detected (state without incoming transition, missing inital state, additional state, missing state, ). Applying STT leads to a high test effort. In the model example above from 5 states with 18 state transitions 62 test cases in 14 test paths are derived. Apply statistical usage testing to detect faults of category “incorrect implementation of guard”. Apply error guessing to detect faults of category “reaction takes place to an undefined event (trap door)”.

Assertion Message

We include a descriptive string argument in each call to an Assertion Method (Meszaros 2007, page 370).

Assertion Method

We call a utility method to evaluate whether an expected outcome has been achieved (Meszaros 2007, page 362).

Automated Teardown

We keep track of all resources that are created in a test and automatically destroy/free them during teardown (Meszaros 2007, page 503).

Back Door Manipulation

We set up the test fi xture or verify the outcome by going through a back door (such as direct database access) (Meszaros 2007, page 327).

Behavior Verification

We capture the indirect outputs of the system under test (SUT) as they occur and compare them to the expected behavior (Meszaros 2007, page 468).

Chained Tests

We let the other tests in a test suite set up the test fixture (Meszaros 2007, page 454).

Configurable Test Double

We configure a reusable Test Double with the values to be returned or verified during the fixture setup phase of a test (Meszaros 2007, page 558).

Creation Method

We set up the test fi xture by calling methods that hide the mechanics of building ready-to-use objects behind Intent-Revealing Names (Meszaros 2007, page 415).

Custom Assertion

We create a purpose-built Assertion Method that compares only those attributes of the object that define test-specific equality (Meszaros 2007, page 474).

Data-Driven Test

We store all the information needed for each test in a data file and write an interpreter that reads the file and executes the tests (Meszaros 2007, page 288).

Database Sandbox

We provide a separate test database for each developer or tester (Meszaros 2007, page 650).

Delegated Setup

Each test creates its own Fresh Fixture by calling Creation Methods from within the Test Methods (Meszaros 2007, page 411).

Delta Assertion

We specify assertions based on differences between the pre- and post-exercise state of the SUT (Meszaros 2007, page 485).

Dependency Injection

The client provides the depended-on object to the SUT (Meszaros 2007, page 678).

Dependency Lookup

The SUT asks another object to return the depended-on object before it uses it (Meszaros 2007, page 686).

Derived Value

We use expressions to calculate values that can be derived from other values (Meszaros 2007, page 718).

Dummy Object

We pass an object that has no implementation as an argument of a method called on the SUT (Meszaros 2007, page 728).

Fake Object

We replace a component that the SUT depends on with a much lighter-weight implementation (Meszaros 2007, page 551).

Four-Phase Test

We structure each test with four distinct parts executed in sequence (Meszaros 2007, page 358).

Fresh Fixture

Each test constructs its own brand-new test fixture for its own private use (Meszaros 2007, page 311).

Garbage-Collected Teardown

We let the garbage collection mechanism provided by the programming language clean up after our test (Meszaros 2007, page 500).

Generated Value

We generate a suitable value each time the test is run (Meszaros 2007, page 723).

Guard Assertion

We replace an if statement in a test with an assertion that fails the test if not satisfied (Meszaros 2007, page 490).

Hard-Coded Test Double

We build the Test Double by hard-coding the return values and/or expected calls (Meszaros 2007, page 568).

Humble Object

We extract the logic into a separate, easy-to-test component that is decoupled from its environment (Meszaros 2007, page 695).

Implicit Setup

We build the test fixture common to several tests in the setUp method (Meszaros 2007, page 424).

Implicit Teardown

The Test Automation Framework calls our clean up logic in the tearDown method after every Test Method (Meszaros 2007, page 516).

In-line Setup

Each Test Method creates its own Fresh Fixture by calling the appropriate constructor methods to build exactly the test fixture it requires (Meszaros 2007, page 408).

In-line Teardown

We include teardown logic at the end of the Test Method immediately after the result verification (Meszaros 2007, page 509).

Layer Test

We can write separate tests for each layer of the layered architecture (Meszaros 2007, page 337).

Lazy Setup

We use Lazy Initialization of the fi xture to create it in the first test that needs it (Meszaros 2007, page 435).

Literal Value

We use literal constants for object attributes and assertions (Meszaros 2007, page 714).

Minimal Fixture

We use the smallest and simplest fi xture possible for each test (Meszaros 2007, page 302).

Mock Object

We replace an object the SUT depends on with a test-specific object that verifies it is being used correctly by the SUT (Meszaros 2007, page 544).

Named Test Suite

We define a test suite, suitably named, that contains a set of tests that we wish to be able to run as a group (Meszaros 2007, page 592).

Parameterized Test

We pass the information needed to do fixture setup and result verification to a utility method that implements the entire test life cycle (Meszaros 2007, page 607).

Prebuilt Fixture

We build the Shared Fixture separately from running the tests: (Meszaros 2007, page 429).

Recorded Test

We automate tests by recording interactions with the application and playing them back using a test tool (Meszaros 2007, page 278).

Scripted Test

We automate the tests by writing test programs by hand (Meszaros 2007, page 285).

Setup Decorator

We wrap the test suite with a Decorator that sets up the shared test fixture before running the tests and tears it down after all the tests are done (Meszaros 2007, page 447).

Shared Fixture

We reuse the same instance of the test fixture across many tests (Meszaros 2007, page 317).

Standard Fixture

We reuse the same design of the test fi xture across many tests (Meszaros 2007, page 305).

State Verification

We inspect the state of the SUT after it has been exercised and compare it to the expected state (Meszaros 2007, page 462).

Stored Procedure Test

We write Fully Automated Tests for each stored procedure (Meszaros 2007, page 654).

Suite Fixture Setup

We build/destroy the shared fi xture in special methods called by the Test Automation Framework before/after the fi rst/last Test Method is called (Meszaros 2007, page 441).

Table Truncation Teardown

We truncate the tables modifi ed during the test to tear down the fi xture (Meszaros 2007, page 661).

Test Automation Framework

We use a framework that provides all the mechanisms needed to run the test logic so the test writer needs to provide only the test-specifi c logic (Meszaros 2007, page 298).

Test Discovery

The Test Automation Framework discovers all the tests that belong to the test suite automatically (Meszaros 2007, page 393).

Test Double

We replace a component on which the SUT depends with a “test-specific equivalent” (Meszaros 2007, page 522).

Test Enumeration

The test automater manually writes the code that enumerates all tests that belong to the test suite (Meszaros 2007, page 399).

Test Helper

We defi ne a helper class to hold any Test Utility Methods we want to reuse in several tests (Meszaros 2007, page 643).

Test Hook

We modify the SUT to behave differently during the test (Meszaros 2007, page 709).

Test Method

We encode each test as a single Test Method on some class (Meszaros 2007, page 348).

Test Runner

We define an application that instantiates a Test Suite Object and executes all the Testcase Objects it contains (Meszaros 2007, page 377).

Test Selection

The Test Automation Framework selects the Test Methods to be run at runtime based on attributes of the tests (Meszaros 2007, page 403).

Test Spy

We use a Test Double to capture the indirect output calls made to another component by the SUT for later verification by the test (Meszaros 2007, page 538).

Test Stub

We replace a real object with a test-specifi c object that feeds the desired indirect inputs into the SUT (Meszaros 2007, page 529).

Test Suite Object

We defi ne a collection class that implements the standard test interface and use it to run a set of related Testcase Objects (Meszaros 2007, page 387).

Test Utility Method

We encapsulate the test logic we want to reuse behind a suitably named utility method (Meszaros 2007, page 599).

Test-Specific Subclass

We add methods that expose the state or behavior needed by the test to a subclass of the SUT (Meszaros 2007, page 579).

Testcase Class

We group a set of related Test Methods on a single Testcase Class (Meszaros 2007, page 373).

Testcase Class per Class

We put all the Test Methods for one SUT class onto a single Testcase Class (Meszaros 2007, page 617).

Testcase Class per Feature

We group the Test Methods onto Testcase Classes based on which testable feature of the SUT they exercise (Meszaros 2007, page 624).

Testcase Class per Fixture

We organize Test Methods into Testcase Classes based on commonality of the test fixture (Meszaros 2007, page 631).

Testcase Object

We create a Command object for each test and call the run method when we wish to execute it (Meszaros 2007, page 382).

Testcase Superclass

We inherit reusable test-specific logic from an abstract Testcase Superclass (Meszaros 2007, page 638).

Transaction Rollback Teardown

We roll back the uncommitted test transaction as part of the teardown (Meszaros 2007, page 668).

Unfinished Test Assertion

We ensure that incomplete tests fail by executing an assertion that is guaranteed to fail (Meszaros 2007, page 494).

Tool evaluation patterns¶

Unit/Integration Test Tool¶

Classification of Unit/Integration Test Tool Capabilities¶

infrastructure integration (bi-directional!!!)

requirement management system interface

continuous integration server interface

test case model

data driven test driver implementation

manual test driver implementation

test generation
- generate from headers
test maintainance
test execution

run on host

run on target

test case separation support

supported compilers

supported RTOS

test types

code coverage

statement

branch

basic path

combinations of the others

blackbox testing

whitebox testing

stubbing of private functions

access to private variables, etc.

result generation

content

data formats

All tool selection patterns in alphabetic order¶

Dependency Structure Matrix¶

Examples for C/C++:
Category:	architecture development environment (ADE)
Context:	you are interested in invalid dependencies in source code
Problem:	looking at source code using an editor or IDEs gives you just a limited view about the overall code structure -> it is hard to understand the overall functionality of source code -> invalid dependencies may not be found methodological
Solution:	use a tool which provides this functionality write your own tool
	Lattix (depends on Scitools Understand for C++) CppDepend
Resulting context:
	you have an overview over inter-module dependencies violations geometric

Globetrotters¶

Resulting context:
Context:	You want to version your work and do not have an internet/network connection to your company neccessarily.
Problem:	You would like to version your work on the local file system for better productivity and more confidence about the quality of your work.
Forces:	data consistency useability maintainability data security: less risc for lost “versions”, risk of mistaces during merging
Tool example:	Git
Solution:	Use a decentralized versioning tool which allows to create versionized repositories on the local file system which can be merged into a/the companies versioning tool repository (remote repository).
	You can version your work on the local file system and you are a more confident about the quality of your work. The data consistency is not worse than without a local versioning tool. The useability is more complex due to the communication between local and remote repository. The maintainability is more complex because of the need for merging but the ability to version speeds-up development. The data security is worse due to the risk of mistaces during merging but a lot better because less risk of versions (information in a repo does not get lost, local file system copies get lost regularly).

Levelized Strucuture Map (LSM)¶

Examples for C/C++:
Context:	maintaining legacy code of a big project start implementing code for a new project
Problem:	software tends to violate design principles relating code structure not considering design the code maintainability decreases impact analysis (after code changes) is often difficult
Forces:	source code size (the higher, the worse) release cycle frequency (the faster, the worse)
Solution:	use a tool which offers a LSM view of source code verify the LSM continuously in parallel to the code implementation
	Structure101 Studio (depends on Scitools Understand) Coverity Code Advisor (depends on analysis pack “Coverity Architecture Analysis”) Scitools Understand
Resulting Context:
	easier to understand very big code base identify cyclic dependencies easier to perform impact/dependency analysis ~ code changes continuous use increases the code maintainability continuos use decreased influence of the release cycle frequency on the design quality good/maintainable design may be achieved without design documents which is the precondition to succeed in agile processes as the value depends on continuous investigation you whant to integrate it into the source code editor or CI process (e.g. Structure101 Build + Structure101 WebApp)

System patterns¶

All system patterns in alphabetic order¶

Drift To Low Performance Handling Pattern¶

Category:	system trap handling pattern
Problem:	Allowing performance standards to be influenced by past performance, especially if there is a negative bias in perceiving past performance, sets up a reinforcing feedback loop of eroding goals that sets a system drifting toward low performance.
Situation:	Keep performance standards absolute. Even better, let standards be enhanced by the best actual performance instead of being discouraged by the worst. Set up a drift toward high performance!

(Mea 2008, p. 121 & p. 192)

Escalation Handling Pattern¶

Category:	system trap handling pattern
Problem:	When the state of one stock is determined by trying to surpass the state of another stock - and vice versa - then there is a reinforcing feedback loop carrying the system into an arms race, a wealth race, a smear campaign, escalating loudness, escalating violence. The escalation is exponential and can lead to extremes surprisingly quickly. If nothing is done, the spiral will be stopped by someone’s collapse - because exponential growth cannot go on forever.
Situation:	The best way out of this trap is to avoid getting in it. If caught in an escalating system, one can refuse to compete (unilaterally disarm), thereby interrupting the reinforcing loop. Or one can negotiate a new system with balancing feedback loops to control the escalation.

(Mea 2008, p. 124 & p. 192)

Expose Your Mental Models To The Light Of The Day Pattern¶

Category:

living in systems pattern

Solution:

expose your assumptions about the system visible to others and yourself (self-reflection!)

need to be complete

need to add up

need to be consistent

invite others to challenge your assumptions
invite others to add their assumptions to yours
collect as many assumptions as possible
consider all to be plausible until you are evident to rule some out

(Mea 2008, p. 172 & p. 194)

Get The Beat Of The System Pattern¶

Category:

living in systems pattern

Solution:

learn the systems history (graph of data over time)
watch the system how it behaves

no static, but dynamic analysis (not only “What’s wrong?”, but “How did we get there?”)

no events, but behavior over different time periods

watch what really happens instead of listening to peoples’ theories of what happens

be aware of “predict, control, or impose your will” mode solutions

analyze variable interconnections over different time periods
interact with the system on the basis of the past and ongoing analyzation

(Mea 2008, p. 170 & p. 194)

Honor, Respect And Distribute Information Pattern¶

Category:	living in systems pattern
Problem:	Delayed, biased, scattered or missing information can make feedback loops malfunction. Most what goes wrong in systems goes wrong because of biased, late or missing information.
Solution:	“Thou shalt not distort, delay or withhold information.”

(Mea 2008, p. 173 & p. 194)

Policy Resistance Handling Pattern¶

Category:	system trap handling pattern
Problem:	When various actors try to pull a system state toward various goals, the result can be policy resistance. Any new policy, especially if it’s effective, just pulls the system state farther from the goals of other actors and produces additional resistance, with a result that no one likes, but that everyone expends considerable effort in maintaining.
Solution:	Let go. Bring in all the actors and use the energy formerly expended on resistance to seek out mutually satisfactory ways for all goal to be realized - or redefinitions of larger and more important goals that everyone can pull toward together.

(Mea 2008, p. 112 & p. 191)

Rule Beating Handling Pattern¶

Category:	system trap handling pattern
Problem:	Rules to govern a system can lead to rule-beating - perverse behavior that gives the appearance of obeying the rules or achieving the goals, but that actually distorts the system.
Situation:	Design, or redesign, rules to release creativity not in the direction of beating the rules, but in the direction of achieving the purpose of the rules.

(Mea 2008, p. 136 & p. 192)

Seeking The Wrong Goal Handling Pattern¶

Category:	system trap handling pattern
Problem:	The system behavior is particularly sensitive to the goals of feedback loops. If the goals - the indicators of satisfaction of the rules - are defined inaccurately or incompletely, the system may obediently work to produce a result that is not really intended or wanted.
Situation:	Specify inidicators and goals that reflect the real welfare of the system. Be especially careful not to confuse effort with result or you will end up with a system that is producing effort, not result.

(Mea 2008, p. 121 & p. 192)

Shifting The Burden To The Intervenor Handling Pattern¶

Category:	system trap handling pattern
Problem:	Shifting the burden, dependence, and addition arise when a solution to a systemic problem reduces (or disguises) the symptoms, but does nothing to solve the underlying problem. Whether it is a substance that dulls one’s perception or a policy that hides the underlying trouble, the drug of choice interferes ith the actions that could solve the real problem. If the intervention designed to correct the problem causes the self-maintaining capacity of the original system to atrophy or erode, then a destructive reinforcing feedback loop is set in motion. The system deteriorates; more and more of the solution is then required. The system will become more and more dependent on the intervention and less and less able to maintain its own desired state.
Situation:	Again, the best way out of this trap is to avoid getting in. Beware of symptom-relieving or signal-denying policies or practices that don’t really address the problem. Take the focus off short-term relief and put it on long-term restructuring. If you are the intervenor, work in such a way as to restore or enhance the system’s own ability to solve its problem, then remove yourself. If you are the the one with an unsupportable dependency, build your system’s own capabilities back up before removing the intervention. Do it right away. The longer you wait, the harder the withdrawal process will be.

(Mea 2008, p. 131 & p. 193)

Success To The Successful Handling Pattern¶

Category:	system trap handling pattern
Problem:	If the winners of a competition are systematically rewarded with the means to in again, a reinforcing feedback loop is created by which, if it is allowed to proceed unihibited, the winners eventually take all, while the losers are eliminated.
Solution:	Diversification, which allows those who are losing the competition to get out of that game and start another one; strict limitation on the fraction of the pie any one winner may win (antitrust laws); policies that level the playing field, removing some of the advantage of the strongest players or increasing the advantage of the weakest; policies that devise rewards for success that do not bias the next round of competition.

(Mea 2008, p. 126 & p. 192)

Tragedy Of The Commons Handling Pattern¶

Category:	system trap handling pattern
Problem:	When there is a commonly shared resoure, every user benefits directly from its use, but shares the costs of its abuse with everyone else. Therefore, there is very weak feedback from the condition of the resource to the decisions of the resource users. The consequence is overuse of the resource, eroding it until it becomes unavailable to anyone.
Solution:	Educate and exhort the users, so they understand the consequences of abusing the resource. And also restore or strengthen the missing feedback link, either by privatizing the resource so each user feels the direct consequences of its abuse or (since many resources cannot be privatized) by regulating the access of all users to the resource.

(Mea 2008, p. 116 & p. 191)

About the meta-data¶

All patterns do have meta-data in common: the name. It is very important for remembering and for communicating the ideas of the patterns. It should be as short as possible but without neglecting expressivness and uniqueness.

Bibliography¶

Author(s):	family name, first name
Title:	title: optional subtitle
Edition:	“agile” means that no specific version or edition of the book exists. The book is generated automatically in a lean process.

Author(s)	Title	Publisher	Edition	Year
Alexander, Christopher	A Pattern Language: Towns, Buildings, Construction	Oxford University Press		1978
Bergin, Joseph	Writing Patterns: software, organizational, pedagogical	Slant Flying Press	agile	2013
Broekman, Bart und Notenboom, Edwin	Testing Embedded Software	Addison-Wesley	1st	2003
Buschmann, Frank et al.	Pattern-Oriented Software Architecture (Vol. 1): A System of Patterns	John Wiley & Sons Ltd.	7th	2001
Carnegie, Dale	How to Win Friends & Influence People	Simon and Schuster	20th	2010
Crispin, Lisa and Gregory, Janet	Agile Testing: A Practical Guide For Testers and Agile Teams	Addison-Wesley	9th	2013
Douglass, Bruce Powel	Real-Time UML: Developing Efficient Objects for Embedded Systems	Addison-Wesley	1th	1998
Douglass, Bruce Powel	Real-Time Design Patterns: Robust Scalable Architecture for Real-Time Systems	Elsevier	1th	2002
Douglass, Bruce Powel	Design Patterns for Embedded Systems in C: An Embedded Software Engineering Toolkit	Elsevier	1th	2011
Erl, Thomas et al.	Cloud Computing Design Patterns	Prentice Hall	1th	2015
Fowler, Martin et al.	Refactoring: Improving the Design of Existing Code	Addison-Wesley		1999
Gamma, Erich et al.	Design Patterns: Elements of Reusable Object-Oriented Software	Addison-Wesley	1th	1998
Greening, James W.	Test-Driven Development for Embedded C	Pragmatic Bookshelf		2011
Gregory, Janet and Crispin, Lisa	More Agile Testing: Learning Journeys For The Whole Team	Addison-Wesley	1th	2015
Harrison, Neil	Pattern Languages of Program Design 4	Addison-Wesley Longman		1999
Humble, Jez and Farley, David	Continous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation	Addison-Wesley		2011
Kasampalis, Sakis	Mastering Python Design Patterns	Packt Publishing Ltd.	1st	2015
Leitner, Helmut	Pattern Theory: Introduction and Perspectives on the Tracks of Christopher Alexander	CreateSpace Independent	1st	2015
Lerche-Jensen, Steen	ISTQB Agile Tester: Agile testing lesson 1 of 3	Amazon Wispernet	agile	2014
Lerche-Jensen, Steen	ISTQB Agile Tester: Agile testing lesson 2 of 3	Amazon Wispernet	agile	2014
Lerche-Jensen, Steen	ISTQB Agile Tester: Agile testing lesson 3 of 3	Amazon Wispernet	agile	2014
Lott, Steven F.	Mastering Object Oriented Python	Packt Publishing Ltd.	1st	2014
Martin, Robert C. et al.	Pattern Languages of Program Design 3	Addison Wesley		1997
Mayer, Bertrand	Object-Oriented Software Construction	Prentice Hall		1988
Manolescu, Dragos et al.	Pattern Languages of Program Design 5	Addison Wesley		2006
Meadows, Donella H.	Thinking in Systems: A Primer	Chelsea Green Publ.	1st	2008
Meszaros, Gerard	xUnit Test Patterns : Refactoring Test Code	Addison-Wesley	1st	2007
Osherove, Roy	Beautiful Builds: Growing Readable, Maintainable Automated Build Processes	Team Agile Publishing	1st	2015
Phillips, Dusty	Python 3 Object Oriented Programming: Harness the power of Python 3 objects	Packt Publishing Ltd.	1st	2010
Coplien, J. and Schmidt, D.	Pattern Languages of Program Design 1	Addison-Wesley Longman		1995
Schmidt, Douglas et al.	Pattern Oriented Software Architecture (Vol. 2): Patterns for Concurrent and Networked Objects	John Wiley & Sons, Inc.		2000
Tornhill, Adam	Patterns in C	Leanpub	agile	2015
Tropashko, Vadim	SQL Design Patterns: The Expert Guide to SQL Programming			2014
Vlissides, John M. et al.	Pattern Languages of Program Design 2	Addison Wesley		2006
Withall, Stephen	Software Requirement Patterns	Microsoft Press		2007
Zlobin, Gennadiy	Learning Python Design Patterns	Packt Publishing Ltd.	1st	2013

Contribution¶

There are many ways how you can contribute to the project.

“It is all about structure and vision.”¶

Why principles, pattern languages and patterns?¶

Lets start with the most general definition of the term “pattern language”:

“A pattern language is (at least) a collection of patterns that work together and admit “sequences” of patterns that solve problems larger than those of the individual patterns. (Bergin 2013, section “Format of a Pattern Language”)”

This means that pattern languages are a general and universal principle or methodology for problem solving. There does not only exist one single problem but many others in our daily life. But the probability that someone else has to handle ir (as the problem is reoccuring there is a need for a pattern or language) or already has handled the problem is high. Therefore there must exist one pattern language or one pattern to address every problem of these.

A language suggests a sequential application of patterns dependent on

the situation before applying a pattern
the problem before applying a pattern and
the forces which influence which pattern of alternatives are influenced by

addresses from large-scale to small-scale patterns.

not like other knowledge management systems (like https://www.wikipedia.org/)

despite of fact that wikis do relay on the same theory

focus on problem, not on content

focus on problem related referencing, not on content related referencing

structuring of single patterns

situation, problem, solution, resulting situation

conformance with problem solution methodology

effective

In many cases patterns are pattern lanugages itself. The identification of “Child Patterns” and its meta-data may evolve a pattern to a pattern language.

Principles have to be considered as forces for patterns.

Pattern languages and patterns are part of the “pattern theory” (Leitner 2015, section “The concept of the pattern”) developed by the architect, systems theorist and philosopher Christopher Alexander. The pattern languages and patterns are very practical. The basic concepts of the pattern theory are not. However my interpretation of the relation between pattern languages and patterns with these basic concepts is to live a more relaxed life and beeing able to spend more and enjoyable time with the people i love. This makes the pattern theory as a whole very practicable for me.

A “real world” example¶

Pattern languages and patterns are everyhwere. In most cases we apply patterns intuitively without thinking about it. While applying it we benefit from our experiences or information we read about a topic before. However we do not use all the power patterns provide if selecting and thinking about it explicitely.

The following pattern languages shall point out the existence and benefit from it in daily life. The basic meta-data for patterns are used: context, problem, forces, solution and resulting context. To point out that pattern languages must not include only other patterns the example proposes another (lower level) pattern language in addition to a pattern. This makes the challenge with pattern lanuages and patterns obvious: it is not challenging to collect and summarize patterns, but it may become very complex to structure several of them in a pattern language. Even if the pattern languages scope is just for a very limited context (see e.g. Unit Test Automation Pattern Language).

Grocery Shopping Pattern Language¶

Resulting context:
Context:	You need to buy some grocery.
Problem:	You do not know how to structure your shopping tour to get all grocery “as effective” as possible.
Forces:	time you can spend time you want spend actual time -> time frame the shop is open your mood (stress, relaxed)
Solution:	Depending on what “effective” means for you in this situation you cand apply on of the following patterns in the context of buying grocery. If you have much time, the store has open long enough, you want to spend much time effective means fast: Fast Shopper Pattern Anti-Cyclic Shopper Pattern Bulls-Eye Shopper Pattern Scanning Shopper Pattern effective means relaxed: Vacation Shopper Pattern
	You have bought all grocery you required. Depending on the applyed pattern you eather

Fast Shopper Pattern¶

Resulting context:
Context:	You have little time and you may not spend more time than available.
Problem:	You run out of time while shopping and you do not get all grocery you need.
Solution:	Get your grocery as fast as possible.
	You can apply either the “Bulls-Eye Shopper Pattern” or the “Scanning Shopper Pattern”.

Anti-Cyclic Shopper Pattern¶

Resulting context:
Context:	You are not forced to go shopping in a predefined time frame.
Solution:	Go shopping when nobody else does.
	You are more relaxed because you avoid “running the gauntlet” (other shoppers). You do not spend time in the waiting line for paying.

Bulls-Eye Shopper Pattern¶

Resulting context:
Context:	You do know the store floor plan (e.g. from previous shopping tours) OR the grocery store areas are labeled (e.g. “cereals”).
Solution:	Think about where the grocery is located. Think about a sequence of grocery which leads to an as short as possible walking route. Go straight to the areas where your grocery is located by walking along your shopping tour specific walking pattern.
	You got your grocery as fast as possible. The probability to miss grocery is little. (Really!? Or is it better to use the “Grocery Delivery Pattern” instead!?)

Scanning Shopper Pattern¶

Resulting context:
Context:	You do not know the store floor plan (e.g. from previous shopping tours) AND the grocery store areas are not labeled (e.g. “cereals”).
Solution:	Get an overview of the store floor plan. Walk along an as short as possible walking path (e.g. row-wise from right to left). Scan all the grocery. Get the grocery if you find
	You get the grocery nearly as fast as with the “Bulls-Eye Shopper Pattern”. But you probably do not get all grocery because the store does not offer all of it.

Vacation Grocery Shopper Pattern¶

Resulting context:
Context:	You are on vacation and have much time.
Solution:	Get the grocery as relaxed as possible: do not hurry, ignore people which apply the “Fast Shopper Pattern” or the “Bulls-Eye Shopper Pattern”.
	You spend more time than required to get your grocery. But you are relaxed. Because you had a lot of time think about what you want you will have bought all the grocery required for sure.

The project history¶

From 2008 on the launcher of this website began to gain practical experience in the context of Embedded Software Development. The first notes have been created then and have been structured and maintained on local filesystems. From 2012 to 2014 the content has been published as ebook on the lean publishing platform https://leanpub.com/.

From the very first the idea has been to share knowledge in an interactive, structured, maintainable and sustainable manner. The first interactive version of the content arose on a local testserver as WordPress implementation and has been launched on “non-public” webhosting in 2014. Its public lauch on http://eswkms.org followed immediatelly. In February 2015 the ESWKMS has been migrated to TYPO3 to optimize issues regarding user management, versioning and publication management.

After over 6 months of experimenting with TYPO3 as full-featured content management system (CMS) its disadvantages (e.g. maintainance cost, complexity for users, etc.) outweighed its advantages (e.g. content management mechanisms, file management, etc.). To ensure best community interaction and a broad user community the ESWKMS has been migrated to https://github.org for project contribution in September 2015.

To make the project as valuable as possible the structuring of the content and the content itself has been optimized related to “pattern languages” and “patterns”. To reflect the evolution of the project regarding the content and its intend the project has been renamed from ESWKMS (Embedded Software Knowledge Management System) to ESWP3 (Embedded Software Principles, Procedures and Patterns). The content is published with readthedocs.org on http://eswp3.org. Feel free to contribute on https://github.com/fkromer/eswp3.