Formal Descriptions of Sustainable Software Design Patterns
Use and operation of software has significant effects on environment and society. Despite this, design and implementation of green and sustainable software turn out to be difficult tasks. Practical guidelines and hints to assist software architects and programmers in their everyday-business are still rare. Thus the question arises whether there are reusable solutions or solution components in the form of so-called "design patterns" leading to sustainable software implementations.
This experimental GitHub repository contains a collection of sustainable software design pattern descriptions. Strictly speaking, pattern candidates are given, since pattern characteristics are not yet evident. Notwithstanding, in order to support software developers, there is the demand to continue the search for more applicable pattern candidates ("pattern mining") and to set up a design knowledge repository comprising of pattern collections. You are very welcome to join our activities!
We tried to describe the patterns formally. By now, algebraic specification techniques have been used. Of course, other approaches might be suitable and considered in the future, e.g. predicative specifications such as supported by the Object Constraint Language (OCL), just to mention one of many languages. From a technical point of view, formal pattern descriptions are embedded into an XML-based overarching pattern language here, namely the "pattern language modelling language" (PLML). - Please note that this is all is work-in-progress and that your participation is appreciated.
- Fincher, S. (2006): PLML: Pattern Language Markup Language. Canterbury, UK: University of Kent.
- Planet (Pattern LAnguage NETwork)
Note: Many of the listed pattern candidates are ultimately pure efficiency pattern (providing a weak degree of sustainability only). However, in case they are directly related to energy and resource conservation, they have been included in this candidate collection.
This is an important approach to avoid hardware obsolescence effects caused by the software. Unfortunately, detailed software design patterns to achieve this goal are not given yet inside this experimental repository. But see BackwardCompatibility.xml for some more comments about this. However, a first formal description will be added soon to this experimental repository...
Often software includes unnecessary resource-wasting additional functions that do not improve the purpose of the application. (This includes, for example, unwanted advertising or unwanted logging of information.) Since this is a "anti-pattern", we did not document it here.
See BufferedDataflow.xml.
Alias for "Don't Stream Twice".
The Call-by-Need strategy is also known as Lazy Evaluation, see "Lazy Evaluation".
(This prominent stability pattern represents the huge group of patterns from another domains that deserve further examination with respect to sustainability issues.)
This pattern deals with the notification of software users about the resource consumption caused by the used software. See Roher & Richardson (2013) for a description of this requirement pattern (the reference is available in the corresponding PLML document CommunicateResourceConsumption.xml.
This describes the basic approach to neutralize resource consumption by suitable compensation measures. See Compensate.xml.
The idea is to provide "information leaflets" providing artifact information about sustainability-relevant issues such as energy comsumption, hardware requirements etc. See ComponentLeaflets.xml.
Principally, this reflects the "Design for Replaceability" idea. See ComponentReplaceability.xml.
See DocumentRuntimeBehavior.xml
See DontStreamTwice.xml (avoid unnecessary data transfers resp. Internet traffic).
Here an alias for "Outsource General Computations". See OutsourceGeneralComputations.xml.
Here an alias for "Switch Off Unneeded Processes". See SwitchOffUnneededProcesses.xml.
See Emulator.xml.
We are not sure whether this really is a pattern - maybe this is rather a guideline. A description has not been added to this repository.
We are not sure whether this really is a pattern (a matter of granularity...). However, a description has not been added yet.
This requirement pattern suggests offering the software user some form of incentive to encourage her/him to reduce resource consumption. This pattern has been named "Incentivizing Minimal Resource Consumption" by Roher & Richardson (2013). (The reference is available in the corresponding PLML document Incentive.xml.
Lazy evaluation is a strategy which delays the evaluation of expressions given in computer programs until its value is needed and which also avoids repeated evaluations ("sharing"). Lazy evaluation can lead to a reduction in a program's memory footprint. Additionaly, the sharing mechanism can reduce the running time of certain functions. Often, lazy evaluation is combined with memoization, see "Memoization pattern".
This is a pattern that often is used in combination with the "lazy evaluation" mechanism (see "Lazy Evaluation"). For a brief description, see Memoization.xml.
Here an alias for "Buffered Dataflow". See BufferedDataflow.xml.
It is a prominent anti-pattern or simple a "bad habit" of some developers not to care about algorithmic efficency. Since this does not give a pattern directly, if hasnt't been documented here. But see the pattern "Document run-time behavior", which addresses this aspect.
It is said, the open source philosophy and the practices behind open source development contribute to software with a higher degree of sustainabilty. Certainly this deserves further examination! However, the "repairability" aspect that is described here (see OpenSource.xml) gives just one facet of the idea behind open source.
See OutsourceGeneralComputations.xml.
See PostponeIntoGreenPhase.xml.
Alias for "Sustainability Awareness".
See ReactiveResponse.xml.
Alias for "Compensate".
Removability of software and data that is no longer needed should be supported explictly. See Uninstall.xml.
Here just used as an alias for "Open Source".
Here an alias for "Switch Off Unneeded Processes". See SwitchOffUnneededProcesses.xml.
See "Lazy Evaluation".
Alias for "Standby Operation".
See Standby.xml.
Alias for "Standby Operation".
See SustainabilityAwareness.xml. - We are not sure whether this strategic approach really is a pattern. However, interaction between human stakeholders and the software plays an important role here. Thus this socio-technical system view has been added as candidate to the repository. (A formal description will be added.)
Alias for "Component Leaflets".
Here an alias for "Component Replaceability".
See SwitchOffUnneededProcesses.xml.
This requirement pattern suggests to explicitly track the resource consumption of a software user. This pattern has been recommended by Roher & Richardson (2013). The reference is available in the corresponding PLML document TrackResourceConsumption.xml.
See Uninstall.xml.
Alias for "Emulator". See Emulator.xml.
What are your ideas?
To execute the pattern descriptions given in CafeOBJ syntax (recognizable by the
language attribute inside the PLML-based descriptions:
<formalization language="CafeOBJ" ...>), you have to install CafeOBJ on your
computer, which is freely available here.
In the CafeOBJ console, just change to the folder holding the pattern descriptions and load the desired .cafe files. Example:
CafeOBJ> cd /projects/suspatterns/descriptions
/projects/suspatterns/descriptions
CafeOBJ> in Compensate.cafe
processing input : /projects/suspatterns/descriptions/Compensate.cafe
-- reading in file : susConcepts
...
-- opening module Compensate done.
...
-- reduce in %Compensate : (compensated(emission(consume(S)),Us)):Bool
(true):Bool
(0.0000 sec for parse, 0.0000 sec for 10 rewrites + 13 matches)
CafeOBJ>
The goal to get a more sustainable system is achieved here, since the goal term is
reduced to true.
Contact: Benno Schmidt, Geovisualization Lab, Bochum University of Applied Sciences, Am Hochschulcampus 1, D-44801 Bochum.