MBSE Training Presentation10 - eaasos.infoeaasos.info/Content/Downloads/MBSE Training Presentation10.pdf · :: 3 -6:: «block» Viewpoint Element «block» Architectural Framework

:: 3 - 1 ::

MBSE FESTIVAL

A Model-based Approach to

Architectural Frameworks

Simon Perry

Copyright © 2015

:: 3 - 2 ::

Overview

1. Introduction

2. The Framework for Architectural Frameworks

(FAF)

3. The FAF in Use

4. Conclusions

5. References & Further Reading

6. Questions

Copyright © 2015 2

1. Introduction - What Are AFs and

Why Are They Important?

• Architectures are now seen as essential to any systems engineering undertaking

– Core element of any model-based systems engineering (MBSE) approach

• An architecture should cover both the structural and behavioural aspects of the system

– Often only structure considered

• An architecture must be seen and treated as an evolving artefact

– Too often created (at great expense) and then forgotten

• Architectures should be based on an architectural framework (AF)

Copyright © 2015 3

:: 3 - 3 ::

What Are AFs and Why Are They

Important?

• An AF defines:– Viewpoints of a system that any architecture based on

the AF can contain

– Consistency rules between the viewpoints

• The use of an AF helps to ensure a consistent approach to the production of an architecture– Views that can be produced are defined

– Engineers know what is expected of them and

– Helps ensure that the architecture is fit for purpose by ensuring that all the concerns that the architecture must address are covered

Copyright © 2015 4

The Problem with the Existing

Approach To AFs• Many AFs exist

– MODAF, DoDAF, NAF

– TRAK

– Zachman etc.

• Many organisations will adopt one of these AFs for the development of their system architecture

• Unfortunately, this is often done without first assessing the stakeholder concerns that the architecture is to address against the viewpoints defined in the chosen AF

• Results in the adoption of an unsuitable AF that unnecessarily constrains or twists the resulting architecture

Copyright © 2015 5

:: 3 - 4 ::

The Problem with the Existing

Approach To AFs• For example, consider MODAF

– Created to assist the MOD in acquisition of systems

– BUT often used by suppliers when creating architectures internally (i.e. for their own internal system development work)

• Often done without any consideration as to whether MODAF defines viewpoints that address the concerns that their architecture must capture

• Results in architectures that are:– Very good examples of MODAF architectures

– Not fit for purpose as system engineering architectures

• If the stakeholder concerns are considered by an organisation, then the conclusion may be that a bespoke AF is needed

Copyright © 2015 6

2. The Framework for Architectural

Frameworks (FAF)

• The FAF was developed to improve the definition of Architectural Frameworks (AFs)

• The FAF is designed to force anyone defining an AF to consider the following six questions:– What is the purpose of the AF?

– What domain concepts must the AF support?

– What viewpoints are required?

– What is the purpose of each viewpoint?

– What is the definition of each viewpoint in terms of the identified domain concepts?

– What rules constrain the use of the AF?

Copyright © 2015 7

:: 3 - 5 ::

The Framework for Architectural

Frameworks (FAF)• The FAF addresses the six questions through an MBSE approach

based 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

• Consists of:

– An ontology

– Six viewpoints

– Supporting processes

• The FAF is defined using the FAF

• Can also be used to define so-called enabling patterns

Copyright © 2015 8

The FAF Ontology

Copyright © 2015 9

«block»

Viewpoint Element

«block»

Architectural Framework

«block»


Concern

«block»

Architecture

«block»

Ontology

«block»

Ontology Element

«block»

Perspectiv e

«block»

Standard

«block»

View

«block»

View Element

«block»

Viewpoint

«block»

Viewpoint Concern

«block»

Rule

{via}

«block»

System

1..*

constrains

1

1

is related to

1..*

1..*

11

com

plie

s w

ith

0..*

1

i s related to

1..*

1..*

1

1

collects together

1..*

1..*

conforms to

1

1..*

uses elements from

1

1..*

1

1collects together

1..*

1..*is derived from

1..*

1

rep

resen

ts n

ee

d f

or

1..*

1..*

1

1

pro

vid

es p

rove

nan

ce f

or

1..*

1

describes structure of

1

1..*

vi sualises

1

1

is related to

1..*

1..*

corresponds to

1

1..*

represents need for

1

1

1

1

is related to

0..*

1..*

1

1..*

describes

1..*

:: 3 - 6 ::

«block»

Viewpoint Element

«block»


«block»


Concern

«block»

Architecture

«block»

Ontology

«block»

Ontology Element

«block»

Perspective

«block»

Standard

«block»

View

«block»

View Element

«block»

Viewpoint

«block»

Viewpoint Concern

«block»

Rule

{via}

«block»

System

1..*

constrains

1

1

is related to

1..*

1..*

11

co

mp

lies w

ith

0..*

1

is related to

1..*

1..*

1

1

col l ects together

1..*

1..*

conforms to

1

1..*

uses el ements from

1

1..*

1

1col l ects together

1..*

1..*is derived from

1..*

1

rep

rese

nts

ne

ed

fo

r

1..*

1..*

1

1

pro

vid

es p

rove

na

nce

fo

r

1..*

1

describes structure of

1

1..*

visual ises

1

1

is rel ated to

1..*

1..*

corresponds to

1

1..*

represents need for

1

1

1

1

is related to

0..*

1..*

1

1..*

describes

1..*

The FAF Viewpoints – Ontology Areas

Copyright © 2015 10

ODV

VRV

RDV

The FAF Viewpoints• AF Context Viewpoint (AFCV)

– What is the purpose of the AF?• Defines the context for the AF

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

• Ontology Definition Viewpoint (ODV)– What domain concepts must the AF support?

• 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)– What viewpoints are required?

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

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


:: 3 - 7 ::

The FAF Viewpoints continued• Viewpoint Context Viewpoint (VCV)

– What is the purpose of each viewpoint?• 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)– What is the definition of each viewpoint in terms of the

identified domain concepts?• Defines a particular Viewpoint

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

• Rules Definition Viewpoint (RDV)– What rules constrain the use of the AF?

• Defines the various rules that constrain the AF


The FAF Viewpoints


«Perspective»

Architectural Perspectiv e

«block,viewpoint»

AF Context Viewpoint

«block,viewpoint»

Ontology Definition Viewpoint

«block,viewpoint»

Viewpoint Relationships Viewpoint

«block,viewpoint»

Rules Definition Viewpoint

«block,viewpoint»

Viewpoint Context Viewpoint

«block,viewpoint»

Viewpoint Definition Viewpoint

{The Rules Defini tion Viewpoint is

related to ALL the other Viewpoints

and defines the Rules that constrain

the Architectural Framework.

Relationships to other Viewpoints are

omitted from this diagram for clarity.}

1..*

is derived from

1

1

is derived from

1

1..*

defines viewpoints using

elements from

1

1

is derived from

1

1

defines viewpoint to meet needs from

1 1

defines relationships between viewpoints defined in

1

:: 3 - 8 ::

Realising the FAF with SysML

Viewpoint SysML Diagram Used

AF Context Viewpoint (AFCV) Use Case Diagram

Ontology Definition Viewpoint (ODV) Block Definition Diagram

Viewpoint Relationships Viewpoint (VRV) Block Definition Diagram [1]

Viewpoint Context Viewpoint (VCV) Use Case Diagram

Viewpoint Definition Viewpoint (VDV) Block Definition Diagram

Rules Definition Viewpoint (RDV) Block Definition Diagram [2]

[1] Use packages to show Perspectives[2] Although a simple text “diagram” could be used, the use of blocks gives us

something in the model that can be the source or target of traceability


«Perspective»


«block,viewpoint»


«block,viewpoint»


«block,viewpoint»


«block,viewpoint»


«block,viewpoint»


«block,viewpoint»








1..*

is derived from

1

1

is derived from

1

1..*


elements from

1

1

is derived from

1

1


1 1


1

3. The FAF in Use – ACRE


MBSE Champion

Requirement Engineer

Tester

Standard

Requirement Manager

Customer

Support capture of

needs

Support capture of

requirements

Support capture of

capabil ities Support capture of

goals

Must be model-based Comply with standards

Identify source of

needs

Ensure consistent style

Define validation

approach

Consider needs in

context

Identify contexts

AF Framework Context

«constrain»

«incl ude»

«incl ude»«include»

«constrain»

«constrain»

«constrain»

:: 3 - 9 ::

«Perspective»


«block,viewpoint»


«block,viewpoint»


«block,viewpoint»


«block,viewpoint»


«block,viewpoint»


«block,viewpoint»








1..*

is derived from

1

1

is derived from

1

1..*


elements from

1

1

is derived from

1

1


1 1


1

The FAF in Use – ACRE


«block»

Rule

«block»

Context

«block»

Use Case

«block»

System Context

«block»

Concern

«block»

Need

{abstract}

«block»

Source Element

«block»

Need Description

«block»

Scenario

«block»

Capability

«block»

Goal

«block»

Requirement

«block»

Stakeholder

Context

«block»

Proj ect Context

«block»

Organisational

Context

«block»

Semi-formal

Scenario

«block»

Formal Scenario

«block»

Process Context

«block»

Stakeholder Role

1..*

constrains

1..*

1

describes

1

1..*

val idates

1..*

1

is related to

0..*

1..* yields an

observable resul t

to

1..*

1..*

is needed to del iver 1

1

is related to

0..*

1..*

is el ici ted from

1..*

{incomplete}

1..* meets

1..*

1..*

describes the context of

1..*

«Perspective»


«block,viewpoint»


«block,viewpoint»


«block,viewpoint»


«block,viewpoint»


«block,viewpoint»


«block,viewpoint»








1..*

is derived from

1

1

is derived from

1

1..*


elements from

1

1

is derived from

1

1


1 1


1

«Perspective»

Requirements Perspective

«block,viewpoint»

Source Element

Viewpoint

«block,viewpoint»

Requirement Context

Viewpoint

«block,viewpoint»

Requirement Description

Viewpoint

«block,viewpoint»

Validation Viewpoint

«block,viewpoint»

Definition Rule Set

Viewpoint

«block,viewpoint»

Context Definition

Viewpoint

1..*

identifies sources of needs on

1..*1

defines context for

1

1..*

validates use case on

1

1..*

defines needs in context from

1..*

1..*

defines constraints on descriptions of needs on

1..*



:: 3 - 10 ::

«Perspective»


«block,viewpoint»


«block,viewpoint»


«block,viewpoint»


«block,viewpoint»


«block,viewpoint»


«block,viewpoint»








1..*

is derived from

1

1

is derived from

1

1..*


elements from

1

1

is derived from

1

1


1 1


1



«block,rule»

ACRE01

notes

Each Source Element in the Source

Element View must be traceable to one

or more Need Description in the

Requirement Description View.

«block,rule»

ACRE02

notes

Each Need Description in the

Requirement Description View must be

traceable to one or more Source

Element in the Source Element View.

«block,rule»

ACRE03

notes

Rules, when they exist, must apply to a

Need Description.

«block,rule»

ACRE04

notes

Each Stakeholder Role on a

Requirement Context View must be

related to at least one Use Case or

other Stakeholder Role.

«block,rule»

ACRE05

notes

Each Need Description must be related

to at least one Use Case.

«block,rule»

ACRE06

notes

The Need Description Views must relate

to a Requirement Context View.

«block,rule»

ACRE07

notes

Each Need Description must have a full

set of attributes defined.

«block,rule»

ACRE08

notes

Each Rule must apply to at least one

Need Description attribute or the Need

Description itself.

«block,rule»

ACRE09

notes

Each Need Description may be

constrained by zero or more Rules.

«Perspective»


«block,viewpoint»


«block,viewpoint»


«block,viewpoint»


«block,viewpoint»


«block,viewpoint»


«block,viewpoint»








1..*

is derived from

1

1

is derived from

1

1..*


elements from

1

1

is derived from

1

1


1 1


1



Requirement Defini tion Viewpoint

Support capture of

needs

Requirement Engineer

Support capture of

requirements

Support capture of

capabilities

Support capture of

goals

Must be model-based

MBSE Champion

«constrain»

:: 3 - 11 ::

«Perspective»


«block,viewpoint»


«block,viewpoint»


«block,viewpoint»


«block,viewpoint»


«block,viewpoint»


«block,viewpoint»








1..*

is derived from

1

1

is derived from

1

1..*


elements from

1

1

is derived from

1

1


1 1


1



«block,viewpoint»

Requirement

Description Viewpoint

«block»

Need Description

1

is related to

0..*

1..*

1

The FAF in Use

• Automotive

• Home entertainment

• Rail

• Fault modelling

• Research

• Enabling patterns


:: 3 - 12 ::

4. Conclusions

• When creating a system architecture, the use

of an AF can help ensure

– Consistency of approach

– Coverage of the correct architectural concerns

• Choice of AF must be made to ensure that

concerns can be addressed by an architecture

based on the AF

– Not always the case

– This may require the creation of a bespoke AF


Conclusions

• An MBSE approach to definition of an AF allows the AF to be created using the same tools and techniques as are used in an MBSE approach to the definition of the system

• The FAF provides such an approach to the definition of AFs

• FAF Used successfully by Scarecrow and other organisations in the definition of AFs in a range of application domains including:

– Automotive

– Home entertainment

– Fault-modelling

– Rail

– Research

• FAF is being used by Scarecrow & INCOSE MBSE Working Group in ongoing work on the definition of enabling patterns for system engineering.


:: 3 - 13 ::

5. References & Further Information

• The key references used in this work are:– Dickerson, C.E. & Mavris, D.N. ‘Architecture and

Principles of Systems Engineering’. CRC Press, 2009

– INCOSE. ‘Systems Engineering Handbook - A Guide For System Life Cycle Processes And Activities’. Version 3.2.2, INCOSE; 2011

– ISO/IEC. ‘ISO/IEC 15288:2008 Systems and software engineering – System life cycle processes’. 2nd Edn, International Organisation for Standardisation; 2008

– ISO/IEC. ‘ISO/IEC 42010:2011 Systems and software engineering — Architecture description’. International Organisation for Standardisation; 2011


References & Further Information

• The key references used in this work are:

– The Ministry of Defence Architectural Framework, 2010: http://www.mod.uk/DefenceInternet/AboutDefence/WhatWeDo/InformationManagement/MODAF/ (Accessed November 2012)

– Stevens, R., Brook, P., Jackson, K. & Arnold, S. ‘Systems Engineering – coping with complexity’. London: Prentice Hall Europe; 1998

– Zachman, J.A. ‘Concise Definition of the Zachman Framework’. Zachman International; 2008. Available from http://www.zachman.com/about-the-zachman-framework; Accessed November 2012

– Holt, J, Perry, S & Brownsword, M. ‘Model-Based Requirements Engineering’. IET Publishing, 2011


:: 3 - 14 ::

6. Questions


Contact us….


www.scarecrowconsultants.co.uk

Follow us on LinkedIn: Scarecrow Consultants

Documents

MBSE Training Presentation10 - eaasos.infoeaasos.info/Content/Downloads/MBSE Training Presentation10.pdf · :: 3 -6:: «block» Viewpoint Element «block» Architectural Framework