SCALARE Concept of Operations

This is a summary of SCALARE’s pattern library and consultation features. For further reading, see Noll, Richardson, Beecham, “Patternizing GSD Research: Maintainable Decision Support for Global Software Development”.

Overview

SCALARE Approach

SCALARE Approach

SCALARE’s knowledge base comprises patterns, that specify practices or other recommendations that practitioners can implement, and research notes, that provide additional information to elaborate on what is presented in patterns. Both patterns and research notes are based on Lero research, and are stored in a wiki (of which this page is a part).

Concept of Operations

Practioners access SCALARE’s knowledge base either by browsing pages in the SCALARE wiki, or by consulting the SCALARE advisor.

SCALARE Advisor Concept of Operations

SCALARE Advisor Concept of Operations

The SCALARE advisor provides a consultation interface that presents a questions about a software development project; the answers provided by the practitioner are used by SCALARE’s inference engine to select relevant patterns from the knowledge base.

Patterns

In general, a pattern is a structured document comprising a set of pre-defined sections; this means all patterns in a given pattern language have the same general structure, making it easy for readers to find information. Originally conceived by Christopher Alexander and colleagues as a means to document and discuss building architecture design solutions[@Alexander_1977_Pattern], patterns have become popular among software developers[@Gamma_1995_Design], and the concept has been extended to organizational patterns[@Coplien_2004_Organizational}]and process patterns[@Ambler_1998_Process], and scenario building patterns[@Monasor_2013_Towards].

Ambler defines a process pattern as “… a pattern which describes a proven, successful approach and/or series of actions for developing software.” Ambler’s process patterns have the following sections: Name, Intent, Type, Initial Context, Solution, Resulting Context, Related Patterns, and Known Uses/Examples[@Ambler_2014_Process]. The “Initial Context” describes the context to which the pattern applies, and the “Resulting Context” describes how the Initial Context looks after the pattern’s Solution is applied.

This approach has two advantages: patterns present solutions in a concise format that is familiar to practitioners, and patterns are straightforward to create from existing research results.

Process Patterns

Process patterns document solutions to software process issues, or practices that should be implemented to achieve specific process goals. For aSPIRE, process patterns are the result of distilling empirical software engineering research into concise descriptions of a problem or goal and its solution.

Pattern Components

A process pattern comprises the following main components:

  1. Pattern name.

    A pattern’s name is important because it can convey the purpose of the pattern and the actions or practices it recommends; the collection of pattern names forms a pattern “language” that can be used to discuss design solutiions[@Alexander_1977_Pattern].

  2. Problem or goal.

    This section provides a short description of the problem to be solved, or the threat to project success to be averted, if the pattern’s recommended actions are implemented.

  3. Background.

    This section puts the pattern’s problem, and the solution, in context to clarify when the pattern applies.

  4. Solution.

    This section is a short (three to five) list of specific actions to take to solve the pattern’s problem.

  5. Related patterns.

    Some patterns have strong relationships with other patterns; this section captures these relationships.

  6. References.

    The foundation of the aSPIRE approach is that recommendations should be empirically grounded; the References section provides links to the research literature from which the pattern is derived.

Triggers

The real value of a library of patterns is the ability to select those patterns that are relevant to a specific project’s context. Each pattern, therefore, needs a rule or trigger that defines when aSPIRE should recommend the pattern.

Triggers are expressed using aSPIRE’s rule definition syntax (see below), and must be written by a knowledge engineer. This is not as significant as it might appear, because they are easily derived from the pattern’s problem or goal statement.

Rules

Some facts are asserted directly by aSPIRE’s consultation interface. Other facts must be inferred from the project’s context. These inferences are specified by rules that govern the inferences made by aSPIRE’s inference engine.

Rules comprise a name, conditions, and actions. The conditions comprise one or more predicates (expressed in Prolog syntax) that must all be true for the condition to be true. If the condition is true, then the actions are evaluated; actions assert new facts or recommendations.

    rule name: [
      condition, condition2, ...
    ] ==> [
      action, action1, ...
    ].

The first line in the example above defines the rule’s name; following that, the clauses between [ and ] on line two specify the conditions that must be true in order for the rule’s inference to happen; the predicates between [ and ] following

Pattern triggers are specified using the same syntax.

Writing Patterns

aSPIRE’s patterns are written in Markdown format. Markdown is a lightweight markup language designed by John Gruber. Markdown has become popular among programmers, and is, for example, the format for writing README files on GitHub. There are now so many variants of Markdown that a project has been started to create a standard Markdown specification called CommonMark.

The particular variant of Markdown used by aSPIRE is referred to as Pandoc markdown; it has many extensions beyond Gruber’s original specification, including tables. aSPIRE’s wiki is derived from gitit which uses Pandoc as its markup language. There is a gitit demonstration site that allows creating and editing pages; this is an easy way to experiment with Pandoc.

Important: Patterns must be added to aSPIRE’s Pattern directory to be accessible to the consultation mechanism and pattern browser. Use the “Create” link in the left sidebar to create a Pattern.

Pattern Format

As described above, aSPIRE patterns have a standard format. This is realized in Pandoc like this:

---
format: markdown
toc: no
categories: Pattern ALPS/OPS/PAISEAN/SPRTMDRC
title: 
type: Pattern
lifecyclePhase: Startup, Requirements, Architecture, Implementation, Testing, Deployment, Maintenance, All
domain: Medical, Finance, Safety, Telecoms, Automotive, e-commerce, NA
intervention: {Organization, Management, Governance {Decision_Structures, Controls, Metrics}, Process, Infrastructure {Communication, SCCS, Knowledge_
Management}, Product {Architecture, Language}
mandatory: no
researchArea: Agile, Co-located, GSD, InnerSource, Lean, MultiNationals, OpenSource, PlanDriven, SMEs, VSEs, Any
evidenceType: 
evidenceSource: 
evidenceStrength: 
project: ALPS/OPS/PAISEAN/SPRTMDRC
author: 
conditions: 
summary: 
...
# Problem

# Analysis

# Solution

## Impact Metrics

## Document Templates

# Related Patterns

# References

The header block (between --- and ... specifies Pattern meta-data; in particular, the condition field specifies the pattern’s trigger. The title field is the pattern name; other fields appear in the “Pattern Attributes” box when the page is displayed. As aSPIRE can be applied to other domains outside of software engineering, the specific meta-data fields may change to suit the domain; in any case, every page needs a toc (always “no), categories (always includes”Pattern“), title, type (always”Pattern“), and condition. The author field should also be included as well to credit the author of the pattern.

References to other Patterns are written using Pandoc’s link syntax:

[link name](page-name)

The naming convention for patterns is to use verb-object phrases such as “Appoint Deputy Architect”; words in the page name should be separated by ’_’, with the first word capitalized, as in

Appoint_deputy_architect.page

So, a reference link to this page would be

[Appoint Deputy Architect](Appoint_deputy_architect)

Links to pages do not need the .page extension; links to other kinds of files should have the extension. Links to external documents need a full URL in the link target.

At present, references need to be included at the bottom of the page. Eventually, we will add bibliography and citation capabilities.

Here’s an example of a pattern:

---
format: markdown
toc: no
categories: Pattern ALPS/OPS/PAISEAN/SPRTMDRC
title: Architecture Consistency Maintenance
type: Pattern
lifecyclePhase: Startup, Requirements, Architecture, Implementation, Testing, Deployment, Maintenance, All
domain: any
intervention: Architecture
mandatory: no
researchArea: Architecture
evidenceType: Case study, Small-scale experimental study
evidenceSource: IBM, 6 post-grads/professional software developers
evidenceStrength: Anecdotal
project: ARC
author: Jim Buckley
conditions: lifecycle_phase > 2
risks: 
role:
tool: 
requires:
provides: 
result:
references:
summary: This pattern addresses the situation where an organization wants to keep its code-base consistent with its designed architecture.
...
# Problem

This pattern addresses the situation where an organization wants to maintain consistency between a system's 
source code (its "as-implemented" architecture) and its as-designed architecture. It is widely reported that the 
as-implemented architecture of a software system drifts with respect to its as-designed architecture over time. 
If this consistency is not preserved, the non-functional attributes that the architect was originally trying to instill 
through the as-designed architecture may not be realized in the as-implemented architecture.  

# Analysis

Real world time pressures can result in programmers diverging from the as-designed architecture. Likewise
programmers' lack of knowledge of the as-designed architecture may also cause divergence. Additionally, 
programmers may have additional insights, based on implementing the system that the original architect 
may not have considered and so they (the programmers) may proactively chose to deviate from the as-designed 
architecture to improve the system. In this latter case, the problem is that the architect is not aware of the newly 
introduced divergence. 

# Solution

The approach/solution is best illustrated by the demo of the JITTAC tool that has been generated as part of this 
research work. The demonstration is available as a [video-clip](http://lero.ie/project/arc). Specifically this pattern 
is addressed by starting from 2 minutes 47 seconds into the video clip, but it is probably useful to view the whole 
video clip for context. Specifically the solution is for: 

1. The architect to create an explicit representation of the architecture
2. The architect to map the source code entities onto the nodes of that architecture
3. The architect to address the inconsistencies that become apparent between the code 
    the as-implemented architecture) and the as-designed architecture (as per the Architecture 
   Establishment pattern)
4. The programmers, when coding on the system would then be alerted through margin warnings
   or intellisence/auto-complete as to their introducing inconsistencies between the as-designed 
   architecture and the as-implemented architecture (in real time)
5. If they persist with the introduction of inconsistencies (assuming a valid rationale) they will be 
    prompted to declare that inconsistency through an email facility to the system architect.  

## Impact Metrics

The case study was qualitative, consisting of quotations from architects and observations of them 
using our tool/approach. The experimental study used metrics like  'time to remove inconsistency' 
during a small software-evolution task,

## Document Templates

# Related Patterns

[Architecture Establishment](Architecture_establishment): A pre-requisite pattern

# References

#. Rosik, J., LeGear, A, Buckley, J. Babar, M.A., Connolly, D., (2011) Assessing Architectural 
Drift in Commercial Software Development: a case study.  SPE 41(1): 63-86.
#. Rosik J., Buckley J., and Babar M.A, (2009) "Design Requirements for an Architecture Consistency Tool" 
Proceedings of the 21st Working Conference of the Psychology of Programmers' Interest Group, pp. 109-124.
#. Buckley J., Mooney S., Rosik J., and Ali N.. (2013) "JITTAC: A Just-In-Time Tool for Architectural Consistency"  
Proceedings of ICSE, pp 1291-1294
#. Ali N., Rosik J., and Buckley J.. (2012) "Characterizing Real-Time Reflexion-based Architecture Recovery in Practice" 
Quality of Software Architecture,  pp 61-70