1 Copyright © 2014 Atego. Patterns INCOSE MBSE WG – 2014-02-27Simon A. Perry - Atego.

1Copyright © 2014 Atego.Copyright © 2014 Atego.

PatternsINCOSE MBSE WG – 2014-02-27 Simon A. Perry - Atego

2Copyright © 2014 Atego.

1. Overview

1. What are patterns?

2. An approach to documenting patterns

3. Candidate patterns

4. Summary

5. References

6. Questions


1. What are patterns?

“A pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice".

- Christopher Alexander, ‘A Pattern Language’, 1977

Original ideas from (building) architecture but adopted by software engineering OO community

- Made more widely known through “Gang of Four Book” (1995)

Ideas spread to analysis and data modelling through books by Fowler (1997) and Day (1996)

Now being adopted in the wider systems engineering community


Architectural vs. Enabling Patterns

On the COMPASS project (http://www.compass-research.eu) we use the terms architectural pattern and enabling pattern

Architectural patterns- Describe specific system architectures, in terms of both structure and

behaviour, which address particular needs of the system

Enabling patterns- Specific constructs of modelling elements whose combination and subsequent

use enables a number of systems engineering applications

- E.g. one used for the definition of interfaces or one used to ensure traceability throughout a model of a system

See COMPASS Deliverable D22.3 ‘Report on Modelling Patterns for SoS Architectures’- Available from http://www.compass-research.eu/deliverables.html


2. An approach to documenting patterns

When defining patterns it is important to use a consistent model-based approach

One such approach is based on around the ideas of ontology, viewpoints and framework

Ontology- Define concepts and relationships between them

Viewpoints and Framework- Define viewpoints organised into a framework

- Viewpoints can only use concepts from the ontology

Originally developed by Brownsword, Holt and Perry (2011)- Further refined by Holt & Perry (2013) (the Framework for Architectural

Frameworks – FAF)

- Adopted in the COMPASS project (FAF adopted into COMPASS as the CAFF)


The COMPASS Architectural Framework Framework (CAFF)

The CAFF was initially developed to improve the definition of Architectural Frameworks (AFs)

- Applicable to the definition of patterns

Consists of:

- An ontology

- Six viewpoints

- Supporting processes

Described in COMPASS Deliverable D21.2 ‘Initial Report on Guidelines for Architectural Level SoS Modelling’

- Available from http://www.compass-research.eu/deliverables.html


The CAFF Ontology

1..*

1

1..*

1

1..*

1

1 1..*

1..*

1

*

1

1

1..*

1 1..*

1 1..*

1

1..*

1

1..*

1..*

1..*

1 1..*

1..*

1

11..*

1..*

1

1

1

111

1..*

1..*

1

1..*

1

1

1

1..*

1..*

*

1

ODV [Package] Ontology Definition View [AFs & Architectures]

«block»Viewpoint

«block»Ontology

«block»Viewpoint Element

«block»Ontology Element

«block»Architectural Framework

Concern

«block»Viewpoint Concern

«block»Architectural Framework

«block»View

«block»View Element

«block»Perspective

«block»Architecture

«block»System

«block»Standard

«block»Rule

1..*

1

1..*

1

1..*

1

1 1..*

corresponds to

1..*

1

*

1

is related to

1

1..*

is related to

1 1..*

visualises

1 1..*uses elements from

1

1..*

represents need for

1

1..*represents need for

1..*

1..*

is derived from

1 1..*

conforms to

1..*

1

is related to

11..*

is related to

1..*

1

1

1

11 describes structure of1

1..*

constrains

1..*

1

collects together

1..*

1

collects together

1

1 describes

1..*

1..*

provides provenance for

*

1

complies with

{via}


The CAFF Viewpoints

AF Context Viewpoint (AFCV)

- Defines the context for the AF

- Represents the AF concerns in context, establishing why the AF is needed

Ontology Definition Viewpoint (ODV)

- Defines the ontology for the AF

- Derived from the AF Context Viewpoint & and defines concepts that can appear on a Viewpoint

Viewpoint Relationships Viewpoint (VRV)

- Shows the relationships between the Viewpoints that make up an AF

- Groups them into perspectives. It is derived from the Ontology Definition Viewpoint


The CAFF Viewpoints continued

Viewpoint Context Viewpoint (VCV)

- Defines the context for a particular Viewpoint

- Represents the Viewpoint concerns in context for a particular Viewpoint, establishing why the Viewpoint is needed. It is derived from the AF Context Viewpoint

Viewpoint Definition Viewpoint (VDV)

- Defines a particular Viewpoint

- Shows the Viewpoint Elements (and hence the Ontology Elements) that appear on the Viewpoint

Rules Definition Viewpoint (RDV)

- Defines the various rules that constrain the AF


The CAFF Viewpoints

1

1..*

11

1

1..*

1 1

1 11

1

VRV [Package] Viewpoint Relationships View [AF & Architectures Perspective]

AF & Architectures Perspective

«block»AF Context Viewpoint

«block»Ontology Definition

Viewpoint

«block»Viewpoint Relationships

Viewpoint

«block»Viewpoint Context

Viewpoint

«block»Viewpoint Definition

Viewpoint

«block»Rules Definition

Viewpoint



Viewpoint


Viewpoint


Viewpoint


Viewpoint


Viewpoint

1

1..*

defines viewpoint using elements from

11

defines viewpoint to meet needs from

1

1..*

is derived from

1 1

defines relationships between viewpoints defined in

1 1

is derived from1

1

is derived from {The Rules Definition Viewpoint is related to ALL the other Viewpoints and defines the Rules that constrain the Architectural Framework. Relationships to the other Viewpoints are omitted from this diagram for clarity.}


The CAFF Viewpoints – an example of use for the Traceability Pattern

1

1..*

11

1

1..*

1 1

1 11

1





Viewpoint


Viewpoint


Viewpoint


Viewpoint


Viewpoint



Viewpoint


Viewpoint


Viewpoint


Viewpoint


Viewpoint

1

1..*


11


1

1..*

is derived from

1 1


1 1

is derived from1

1


AFCV Pattern Aims - Traceability

Traceability Pattern Context

SystemsEngineer

SystemsEngineering

Manager

Establishtraceability

Define allowedtraceability

Define types oftraces allowed

Define types ofelements that canbe traced to/from

Support impactanalysis

Support traceabilitythrougjhout model

«include»

«include»

«include»

«include»

«include»«constrain»

«constrain»



1

1..*

11

1

1..*

1 1

1 11

1





Viewpoint


Viewpoint


Viewpoint


Viewpoint


Viewpoint



Viewpoint


Viewpoint


Viewpoint


Viewpoint


Viewpoint

1

1..*


11


1

1..*

is derived from

1 1


1 1

is derived from1

1


1 1

*

1 1

*1 1

1 11 1

ODV Concepts - Traceability

Traceable Element{Abstract}

View Element

Traceability Relationship

View

Relationship Type

Viewpoint ElementViewpoint

Traceable Type{Abstract}

1 1

defines the type of

*

1

is traceable to

1

*

can be traced to

1 1

defines the type of

1 1defines the type of

1 1

defines the type of



1

1..*

11

1

1..*

1 1

1 11

1





Viewpoint


Viewpoint


Viewpoint


Viewpoint


Viewpoint



Viewpoint


Viewpoint


Viewpoint


Viewpoint


Viewpoint

1

1..*


11


1

1..*

is derived from

1 1


1 1

is derived from1

1


1..*

1..*

1..* 1..* *

1..*

VRV Framework - Traceability

Relationship IdentificationViewpoint

Traceability Viewpoint

Traceability IdentificationViewpoint

Impact Viewpoint

1..*

1..* identifies relationships used on

1..* 1..*

identifies elements and relationships used on

*

1..*

shows traceability tree from



1

1..*

11

1

1..*

1 1

1 11

1





Viewpoint


Viewpoint


Viewpoint


Viewpoint


Viewpoint



Viewpoint


Viewpoint


Viewpoint


Viewpoint


Viewpoint

1

1..*


11


1

1..*

is derived from

1 1


1 1

is derived from1

1


RDV Rules - Traceability

«Rule»

Rule TextAs a minimum one Traceability Identification Viewpoint, one Relationship Identification Viewpoint and one Traceability Viewpoint must be produced.

Rule TR1«Rule»

Rule TextAll Traceability Relationships must be defined as Relationship Types on a Relationship Identification Viewpoint.

Rule TR2

«Rule»

Rule TextAll Traceable Elements must be defined as Traceable Types on a Traceability Identification Viewpoint.

Rule TR3«Rule»

Rule TextThe permitted Relationship Types that can occur between each pair of Traceable Types must be defined on a Traceability Identification Viewpoint.

Rule TR4

«Rule»

Rule TextIf a Traceable Type, T1, has a defined Relationship Type, R1, to another Traceable Type, T2, then every Traceable Element defined by Traceable Type T1 must have a corresponding Traceability Relationship of type R1 to another Traceable Element defined by Traceable Type T2.

Rule TR5



1

1..*

11

1

1..*

1 1

1 11

1





Viewpoint


Viewpoint


Viewpoint


Viewpoint


Viewpoint



Viewpoint


Viewpoint


Viewpoint


Viewpoint


Viewpoint

1

1..*


11


1

1..*

is derived from

1 1


1 1

is derived from1

1


VCV Viewpoint Aims - Relationship Identification Viewpoint

Relationship Identification Viewpoint Context

SystemsEngineer

Establishtraceability

Define allowedtraceability

Define types oftraces allowed

«include»

«include»



1

1..*

11

1

1..*

1 1

1 11

1





Viewpoint


Viewpoint


Viewpoint


Viewpoint


Viewpoint



Viewpoint


Viewpoint


Viewpoint


Viewpoint


Viewpoint

1

1..*


11


1

1..*

is derived from

1 1


1 1

is derived from1

1


1..*

VDV Framework - Relationship Identification Viewpoint

Relationship Identification Viewpoint

Relationship Type

1..*


3. Candidate patterns

Defined by Atego- Interface Definition

- Traceability

- Testing

- Life Cycle

- Epoch

In development by Atego- Connection

- Context

- Description

What others are of interest?- Patterns workshop next session


4. Summary

Patterns are now seen as a useful and powerful tool in model-based systems engineering

Patterns (and their extensions, Architectural Frameworks) need to be described in a consistent fashion

Work has been undertaken (and is continuing) on the COMPASS project in the collection and definition of appropriate architectural and enabling patterns

The COMPASS Architectural Framework Framework, though initially developed to help in the consistent definition of AFs can also be used in the definition of patterns


5. References

Alexander, C.S., Ishikawa, M., Silverstein, M., Jacobson, M., Fiksdahl-

Ling, I. & Angel, S. ‘A Pattern Language’. New York: Oxford University

Press; 1977

Gamma, E., Helm, R., Johnson, R. & Vlissides, J. ‘Design Patterns –

Elements of Reusable Object Oriented Software.’ Boston, MA: Addison-

Wesley; 1995

Hay, D. ‘Data Model Patterns: Conventions of Thought’. New York: Dorset

House; 1996

Fowler, M. ‘Analysis Patterns: Reusable Object Models’. Boston, MA:

Addison-Wesley; 1997


References continued

COMPASS. ‘D22.3 – Report on Modelling Patterns for SoS Architectures’;

COMPASS Project; 2013

COMPASS. ‘D21.2 – Initial Report on Guidelines for Architectural Level

SoS Modelling’. COMPASS Project; 2013

Holt, J, Perry, S & Brownsword, M. ‘Model-Based Requirements

Engineering’. IET Publishing, 2011

Holt, J & Perry, S. ‘SysML for Systems Engineering; 2nd Edition: A model-

based approach’. London: IET Publishing; 2013


6. Questions

1 Copyright © 2014 Atego. Patterns INCOSE MBSE WG – 2014-02-27Simon A. Perry - Atego.

Documents

Transcript of 1 Copyright © 2014 Atego. Patterns INCOSE MBSE WG – 2014-02-27Simon A. Perry - Atego.