Enterprise Architecture Modelling

From Training Material
Revision as of 17:46, 7 February 2016 by Ahnboyoung (talk | contribs) (→‎Visualization vs Model。)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
title
Enterprise Architecture Modelling
author
Bernard Szlachta (bs@NobleProg.co.uk)

Modelling Activities。

Process can contain following steps:

  • Design
    • Common language spanning all domain
    • Best practices
    • Revision control
  • Communication
    • Shared model
    • Publishing
    • Comments and discussion (wiki, forum, etc...)
  • Realisation
    • Keep in sync
    • Link between software and design (url, mda, etc..)
  • Change
    • Tools for assessing the impact of change

Views Alignment。

  • Solved by mapping
  • Can be extremely hard between different languages (e.g. BPMN+UML)
  • Matrix allow to consider all possible connections

Example of a capability to operational activities mapping.png

Views Alignment。

Running example NCV-6.png

Viewpoints and Visualisation。

  • No stakeholder (except enterprise architects) is usually interested in the whole architecture
  • Stakeholders need specific views of the architecture
View (IEEE)
work product expressing the architecture of a system 
from the perspective of specific system concerns
  • The view a stakeholder wants derives from the goal and their current knowledge and their domain
  • Specification of a view is expressed by means of a viewpoint
Viewpoint is defiend as (IEEE):
work product establishing the conventions
for the construction, interpretation and use
of architecture views to frame specific system concerns


Viewpoints and Visualisation。

  • In Nato Architecture Framework, a viewpoint is referred to as sub-view
  • View is what you see, viewpoint is from where you are looking
  • A view contains a subset of elements of the model
  • Ideally a change in one view result in a change in a model which in turn should update other views
  • Present in NAF in Sparx Enterprise Architect

Architecture Concept。

Abstraction

  • Generalization
  • Striping out structural or behavioural aspects

Architecture Model

  • Model abstracts from reality
  • The elements which choose to depict depends on the goal
  • Model of London Tube for a commuter will be different form a model for Engineers and drivers
  • We create models in order to:
    • understand reality
    • predict the future
    • design a new product/service (i.e. modify reality)

Model Elements and Modelling Concepts

  • Modelling Concepts described by a framework do not have any concrete elements
  • They are usually described in Ontologies and patterns
  • Examples:
    • using SOA instead of batch processing
    • always use asynchronous calls

Visualization vs Model。

  • Model usually is not visual (XML)
  • Graphs, charts and pictures are not the model, they are just the visualization of the model
  • Model itself is also refereed to as the content

Model and visualization.png

Visualization vs Model。

One Model Element - Two Shapes

One Model Element Two Representation.png

Visualization vs Model。

Semantics

  • Two shapes in the examples above mean one thing i.e. the actor
  • This common meaning is called semantics
  • Semantics refers to the effect of the thing itself rather than its shape
  • In Human Languages, the semantics refers to the meaning as oppose to syntax

Semantic model vs Symbolic model

  • Symbolic model, refers to concrete objects of the reality (UML objects)
  • Semantic model, an abstractions, an interpretation of a symbolic model (UML classes)

Ontologies。

http://www.mod.uk/NR/rdonlyres/FD9A4CC8-7F27-4042-BF23-69F9EC4978A4/0/20090203_Ontologies_and_their_Use_MODAF_V1_0_U.pdf