IJC - IPM · Telecom and Informatics 1 INF5120 ”Modellbasert Systemutvikling” ”Modelbased...

Telecom and Informatics 1

INF5120

”Modellbasert Systemutvikling”

”Modelbased System development”

Lecture 14: 04.05.2015 Arne-Jørgen Berre

[email protected] or [email protected]

mailto:[email protected]

mailto:[email protected]


INF5120 - Lecture plan - 2015

1 (19/1): Introduction – MDA principles, class models, EA, BAE, SAE, MDE

2 (26/1): BAE-1: BM, VDML, BMC/VPC,– Strategyzer, Oblig 1&2 intro, establish groups

Guest lecture, Prof. Peter Lindgren, Aarhus University, Sensing Business Model

3: (2/2): MDE-1 Method Engineering, Essence, Process/Practices for BE and SE– Symphonical

Guest lecture, Bjørn Haugland, CEO, Symphonical, The Symphonical platform

4 (9/2): BAE-2: Service Design – AT ONE, Smaply, ExperienceFellow

5 (16/2): BAE-3: EA, BA, BPMN, VDML, Class/Term models- MagicDraw and Cameo Enterprise Guest lecture, Ragnhild Halvorsrud, SINTEF, Visual Service Design language

6 (23/2): BAE-4: Agile user stories and use cases – Symphonical/MD&Cameo

7 (2/3): BAE-5: User experience and Interaction/UI Design– Balsamiq and WebRatio installation

8 (9/3): SAE-1 IFML and Webratio and Mobile App development, Oblig 2 intro

9 (16/3): SAE-2 Domain/information modeling – more IFML – Server development, Oblig 1 delivery and presentations

Guest lecture, Vidar Mortensen/Assulv Tønnesland, SunSense, Evje, Norway

10(23/3): MDE-2 Metamodels, EMF, Oblig 2 discussion and Oblig 3 intro

EASTER

11(13/4): MDE-3 Graphical Editors – Sirius - Oblig 2 issues – and Oblig 3 Sirius demo

12(20/4): MDE-4 Model transformations

13(27/4): SAE-3 Service and system architecture modeling , Patterns, Non functional requirements - Oblig 2 delivery and presentations

14(4/5): SAE-4: EA modeling = BA + SA - Oblig 3 issues

15(11/5): MDE-5: DSL lexical example – ThingML, future MDE - Oblig 3 delivery and presentations Guest lecture, Franck Fleurey, SINTEF, ThingML DSL language

16(18/5): Conclusion – preparation for the exam with discussion of earlier exam sets


INF5120 - Obligs- 2015

1 (19/1): Introduction – Presentation of teaching assistants

2 (26/1): Strategyzer demo, Oblig 1&2 intro, establish groups

3: (2/2): Symphonical demo, Oblig 1 SenseIT text, finalise groups

4 (9/2): Smaply demo, Oblig 1 App demo, Group: Strategyzer BMC/VPC, Symphonical plan

5 (16/2): MagicDraw and Cameo Enterprise demo, Group: Smaply

6 (23/2): User stories/Use cases templates demo

7 (2/3): Symphonical/MD&Cameo, Group: MagicDraw BPMN process, UML class diagram

Group: User stories/Use cases templates'

8 (9/3): IFML and Webratio and Mobile App development demo, Oblig 2 intro, Group: Balsamiq

9 (16/3): Webratio II, Oblig 1 delivery discussion and presentations

10(23/3): EMF and Sirius demo

EASTER

11(13/4): Sirius demo

12(20/4): Oblig 2 support

13(27/4): Oblig 2 delivery and presentations

14(4/5): Oblig 3 issues and support

15(11/5): Oblig 3 delivery and presentations

16(18/5): Earlier exams

Telecom and Informatics

Content

Oblig 2 (comments) and 3 (questions)

Enterprise Architecture - MagicDraw

ISO RM/ODP

UPDM for MODAF/DODAF/(NAF)

EuroControl SJU

TOGAF

ArchiMate og Archi

INF5120: EA = BA (BMC, SD) + SA (IFML, UML)

Data Model Patterns

Ontologies – Linked Data RDF/OWL

SSN – Semantic Sensor Network Ontology

4


MagicDraw

Cameo Enterprise Architecture

5


Zachman Framework

Row 1 – Scope

External Requirements and Drivers

Business Function Modeling

Row 2 – Enterprise Model

Business Process Models

Row 3 – System Model

Logical Models

Requirements Definition

Row 4 – Technology Model

Physical Models

Solution Definition and Development

Row 5 – As Built

As Built

Deployment

Row 6 – Functioning Enterprise

Functioning Enterprise

Evaluation

1

2

3

4

5

6

Contextual

Conceptual

Logical

Physical

As Built

Functioning

Contextual

Conceptual

Logical

Physical

As Built

Functioning

Why

Why

Who

Who

When

When

Where

Where

What

What

How

How


Based on work by

John A. Zachman

VA Enterprise

Architecture

DATAWhat

FUNCTIONHow

NETWORKWhere

PEOPLEWho

TIMEWhen

MOTIVATIONWhy

DATAWhat

FUNCTIONHow

NETWORKWhere

PEOPLEWho

TIMEWhen

MOTIVATIONWhy

SCOPE

(CONTEXTUAL)

Planner

ENTERPRISE

MODEL

(CONCEPTUAL)

Owner

SYSTEM MODEL

(LOGICAL)

Designer

TECHNOLOGY

MODEL

(PHYSICAL)

Builder

DETAILED

REPRESENTATIONS

(OUT-OF-CONTEXT)

Sub-Contractor

FUNCTIONING

ENTERPRISE

SCOPE

(CONTEXTUAL)

Planner

ENTERPRISE

MODEL

(CONCEPTUAL)

Owner

SYSTEM MODEL

(LOGICAL)

Designer

TECHNOLOGY

MODEL

(PHYSICAL)

Builder

DETAILED

REPRESENTATIONS

(OUT-OF-CONTEXT)

Sub-Contractor

FUNCTIONING

ENTERPRISE

Things Important

to the Business

Entity = Class of

Business Thing

Processes

Performed

Function = Class of

Business Process

Semantic Model

Ent = Business Entity

Rel = Business Relationship

Business Process

Model

Proc = Business Process

I/O = Business Resources

Business Logistics

System

Node = Business Location

Link = Business Linkage

Work Flow Model

People = Organization Unit

Work = Work Product

Master Schedule

Time = Business Event

Cycle = Business Cycle

Business Plan

End = Business Objectiv e

Means = Business Strategy

Important

Organizations

People = Major

Organizations

Business

locations

Node = Major

Business Locations

Ev ents Significant

to the Business

Time = Major

Business Event

Business Goals

and Strategy

Ends/Means =

Major Business Goals

Logical Data

Model

Ent = Data Entity

Rel = Data Relationship

Application

Architecture

Proc = Application Function

I/O = User Views

Distributed System

Architecture

Node = IS Function

Link = Line Characteristics

Human Interface

Architecture

People = Role

Work = Deliv erable

Processing

Structure

Time = System Event

Cycle = Processing Cycle

Business Rule

Model

End = Structural Assertion

Means = Action Assertion

Physical Data

Model

Ent = Segment/Table

Rel = Pointer/Key

System

Design

Proc = Computer Function

I/O = Data Elements/Sets

Technology

Architecture

Node = Hardware/Softw are

Link = Line Specifications

Presentation

Architecture

People = User

Work = Screen Format

Control

Structure

Time = Ex ecute

Cycle = Component Cycle

Rule

Design

End = Condition

Means = Action

Data

Definition

Ent = Field

Rel = Address

Program

Proc = Language Statement

I/O = Control Block

Netw ork

Architecture

Node = Addresses

Link = Protocols

Security

Architecture

People = Identity

Work = Job

Timing

Definition

Time = Interrupt

Cycle = Machine Cycle

Rule

Design

End = Sub-Condition

Means = Step

Data

Ent =

Rel =

Function

Proc =

I/O =

Netw ork

Node =

Link =

Organization

People =

Work =

Schedule

Time =

Cycle =

Strategy

End =

Means =

Based on work by

John A. Zachman

VA Enterprise

Architecture

DATAWhat

FUNCTIONHow

NETWORKWhere

PEOPLEWho

TIMEWhen

MOTIVATIONWhy

DATAWhat

FUNCTIONHow

NETWORKWhere

PEOPLEWho

TIMEWhen

MOTIVATIONWhy

SCOPE

(CONTEXTUAL)

Planner

ENTERPRISE

MODEL

(CONCEPTUAL)

Owner

SYSTEM MODEL

(LOGICAL)

Designer

TECHNOLOGY

MODEL

(PHYSICAL)

Builder

DETAILED

REPRESENTATIONS

(OUT-OF-CONTEXT)

Sub-Contractor

FUNCTIONING

ENTERPRISE

SCOPE

(CONTEXTUAL)

Planner

ENTERPRISE

MODEL

(CONCEPTUAL)

Owner

SYSTEM MODEL

(LOGICAL)

Designer

TECHNOLOGY

MODEL

(PHYSICAL)

Builder

DETAILED

REPRESENTATIONS

(OUT-OF-CONTEXT)

Sub-Contractor

FUNCTIONING

ENTERPRISE

Things Important

to the Business

Entity = Class of

Business Thing

Processes

Performed

Function = Class of

Business Process

Semantic Model

Ent = Business Entity

Rel = Business Relationship

Business Process

Model

Proc = Business Process

I/O = Business Resources

Business Logistics

System

Node = Business Location

Link = Business Linkage

Work Flow Model

People = Organization Unit

Work = Work Product

Master Schedule

Time = Business Event

Cycle = Business Cycle

Business Plan

End = Business Objectiv e

Means = Business Strategy

Important

Organizations

People = Major

Organizations

Business

locations

Node = Major

Business Locations

Ev ents Significant

to the Business

Time = Major

Business Event

Business Goals

and Strategy

Ends/Means =

Major Business Goals

Logical Data

Model

Ent = Data Entity

Rel = Data Relationship

Application

Architecture

Proc = Application Function

I/O = User Views

Distributed System

Architecture

Node = IS Function

Link = Line Characteristics

Human Interface

Architecture

People = Role

Work = Deliv erable

Processing

Structure

Time = System Event

Cycle = Processing Cycle

Business Rule

Model

End = Structural Assertion

Means = Action Assertion

Physical Data

Model

Ent = Segment/Table

Rel = Pointer/Key

System

Design

Proc = Computer Function

I/O = Data Elements/Sets

Technology

Architecture

Node = Hardware/Softw are

Link = Line Specifications

Presentation

Architecture

People = User

Work = Screen Format

Control

Structure

Time = Ex ecute

Cycle = Component Cycle

Rule

Design

End = Condition

Means = Action

Data

Definition

Ent = Field

Rel = Address

Program

Proc = Language Statement

I/O = Control Block

Netw ork

Architecture

Node = Addresses

Link = Protocols

Security

Architecture

People = Identity

Work = Job

Timing

Definition

Time = Interrupt

Cycle = Machine Cycle

Rule

Design

End = Sub-Condition

Means = Step

Data

Ent =

Rel =

Function

Proc =

I/O =

Netw ork

Node =

Link =

Organization

People =

Work =

Schedule

Time =

Cycle =

Strategy

End =

Means =

Zachman Framework – for Enterprise

Architecture (IBM, 1987)


Content

EA and the Zachman Framework

Architectural Frameworks - (IEEE/ 1471/ISO 42010, ADL,

UML 2.x, TOGAF, UPDM

UPDM (DODAF/MODAF, NAF),

NIEM

TOGAF

Service modeling and Service oriented views

Tool support , Metamodels and UML profiles – No Magic,

Magic Draw

11


Many Architectural Frameworks ….

ARIS ZACHMAN GERAM

EN/ISO 19439

NIST

EKA - POPS EKA - POPS EKA - POPS

Athena OEA


TOGAF 9 (The Open Group)

13


ISO RM/ODP (ISO 10746)


Why and When: Historical Development of AF’s.

C4ISR

Architectur

e

Framework

v1.0

C4ISR

Architectur

e

Framework

v2.0

DoDAF

v1.0

MODAF

v1.0

1996

1997

2003

2005

DoDAF

v1.5

2007

MODAF

v1.1

2007

NAF

v1.0

2005

Scope of UPDM 1.0

Approved Sept 2008

MODAF

Meta-Model (M3)

expressed using

UML Notation

MODAF

v1.2

2008

NAF

v3.1

2007

DoDAF

V2.0

2009

DNDAF

v1.7

2008

Scope of UPDM 2.0

Started Sept 2009

TOGAF1 - … TOGAF9

MACCIS

Norway


Towards a Unified Architecture

Framework

17


Three Views in

DOD Architecture Framework and C4ISR-AF


DODAF 2.0 - viewpoints

19


EAEA – European Air Traffic

Management Enterprise Architecture

20


IEEE 1471, ISO 42010

21


Zachman with OMG standards

22

Data

(What)

Function

(How)

Network

(Where)

People

(Who)

Time

(When)

Motivation

(Why)

Scope

(Contexts)

Business

(Concepts)

System

(Logic)

Technology

(Physics)

Component

(Assemblies)

List of things important

to business

SBVR

List of processes that

the business performs

VDM

List of locations which

the business operates

VDM

List of organizations

important to the business

OSM

List of events/cycles

important to the business

DTFV

List of business

goals/strategies

BMM

Semantic Model

ODM,

IMM (CWM)

Business Process

Model

BPMN, CMPM

Business Logistics

System

BPMN, CMPM

Workflow Model

OSM, BPMN,

CMPM

Master Schedule

BPMN, CMPM,

DTFV

Business

Plan

SBVR

Logical Data Model

ODM,

IMM (CWM), UML

Application

Architecture

SoaML, UML

Distributed

System Architecture

SoaML, UML

Human Interface

Architecture

BPMN, CMPM

Process Structure

BPMN, CMPM,

DTFV

Business Rule

Model

SBVR

Physical Data Model

IMM (CWM), UMLSystem Design

SoaML, UML

Technology

Architecture

SoaML, UML

Presentation

Architecture

Control Structure

BPMN, CMPM,

DTFV

Rule

Design

SBVR

Data Definition

IMM (CWM), UMLProgram

UML

Network

Architecture

UML

Security

Architecture

Timing

Definition

DTFV

Rule

Definition

SBVR

Operation

(Instances)Data Function Network Organization Schedule Strategy


OMG standards coverage

23

Data

(What)

Function

(How)

Network

(Where)

People

(Who)

Time

(When)

Motivation

(Why)

Scope

(Contexts)

Business

(Concepts)

System

(Logic)

Technology

(Physics)

Component

(Assemblies)

List of things

important

to business

List of processes

that the business

performs

List of locations

which the business

operates

List of organizations

important to the

business

List of events/cycles

important to the

business

List of business

goals/strategies

Semantic Model

Business

Process

Model

Business

Logistics

System

Workflow

Model

Master

Schedule

Business

Plan

Logical Data ModelApplication

Architecture

Distributed

System

Architecture

Human

Interface

Architecture

Process

Structure

Business Rule

Model

Physical Data Model System DesignTechnology

Architecture

Presentation

Architecture

Control

Structure

Rule

Design

Data Definition ProgramNetwork

Architecture

Security

Architecture

Timing

Definition

Rule

Definition

Operation

(Instances)Data Function Network Organization Schedule Strategy

BMM

SBVR

VDM OSMSBVR

DTFV

BPMN

UMLIMM

(CWM)

CMPM

SoaML

ODM


UPDM coverage

24

Data

(What)

Function

(How)

Network

(Where) People

(Who)

Time

(When)

Scope

(Contexts)

Business

(Concepts)

System

(Logic)

Technology

(Physics)

Component (Assemblies)

Operation

(Instances)

Motivation

(Why)

BPMN

SoaML

UPDM


Model Based Systems

Engineering and Interoperability

Business Architecture

(SysML Context + BPMN

2.0/BMM)

System & IT Service oriented

Architecture

(UML&SysML/SoaML)

Enterprise Architecture (EA) for

Systems of Systems

(UPDM)

Mo

delD

riven

Arc

hit

ec

ture

(M

DA

,Oslo

)

Inte

rop

era

bilit

y

Arc

hit

ec

ture

(M

DI)

BMM

BPMN

VDM

CaseMgmt

OSM

SBVR

UML 2.0

SoaML

SysML


UPDM 1.0 is a standardized way of expressing DoDAF 1.5 and MODAF 1.2 artefacts using UML and SysML UPDM is NOT a new Architectural Framework

UPDM is not a methodology or a process

UPDM 2.0 is scheduled to address DoDAF 2.0, MODAF 1.2, NAF 3.x, and DNDAF 1.7

UPDM 1.0 was developed by members of the OMG with help from industry and government domain experts.

UPDM 1.0 has been implemented by multiple tool vendors. Tools supporting UPDM 1.0 are available now.

What is UPDM? - Summary


UPDM: UML Profile for

DoDAF and MODAF Context

Stakeholders

US DoD

UK MOD

NATO

Canada/Australia

OMG, INCOSE

OMG

XMI, UML, SysML

BPMN

UPMS, BMM

End Users

Aerospace

Commercial

Tool Vendors

Software

Systems

Enterprise

UPDM Domain Meta Model

UPDM Profile Meta Model

UPDM Profile

&

Library

UML4SysML SysML

Exte

rnal

Refe

ren

ces

Tra

nsfo

rmati

on

s

CADM

IDEF

XMI

AP233

BPMN

SoaML

NAF Meta Model CADM 1.5

DoDAF 2.0 Ontology

UML

SysML Extensions

SoaML, BMM,

SBVr Extensions

<<import/merge>>

MODAF Meta Model

DoDAF 1.5 Concepts

SSDD

UJTL

etc.

CDD

SF List

CONOPS

Products -- Reports -- Simulations

BMM


UPDM - – Unified Model for DODAF

and MODAF

28


UPDM

29


Enterprise Architecture

Modeling with UPDM


Introduction

Enterprise Architecture modeling

No rocket science!

It's a standard!

UPDM:

Unified Profile for MODAF and DoDAF


What is Enterprise Architecture?


Enterprise Architecture

Business, partners, customers

Application ecosystem

System of system architecture

The world

Not: application or device


UML EA Framework

Semantic classification

Extra rules for construction

Additional data

Traceability between views


UPDM

Unified Profile for DoDAF and MODAF (UPDM)

Developed by OMG with DoD support

Created by multiple vendors, governments,

customers

Implements architecture for DoD, MOD, and others


UPDM 2.0 Standard

Approved by the OMG September, 2011 with DoD/MOD support

Implements DoDAF 2.0 guidance and traced to DM2 metamodel

as a UML extension

Submitted to DISR as Emerging September, 2011 (in registry 14

November 2011)

Beta from existing UPDM vendors

UPDM 1.0 to 2.0 conversion available now


Advantages of UPDM

Leverages existing UML tools and capabilities

Automated completeness/correctness of models

Supported by multiple vendors in consistent form

Customizable via standard-based

methods/interoperability

Supports executable architecture via executable UML


Structure


Simple Example

Two things (very simple model)

Presentation not in build order

Key elements of UPDM used


High Level Operational Concept

Elevator Speech of the architecture

Summarizes the key concepts of the

architecture

Picture, not a model

Usually one diagram per project, but there may

be many if required.

HLOC can be composite diagram


OV-1 Thing Concept


Thing HLOC


Operational Resource Flow (OV-2)

Documents logical view of performers and logical data

interactions

Summarizes the architecture's business viewpoint

Business, not the implementation of the business

Also used to build OV-3 (Operational Exchange Matrix)

and others


Thing World


A Sign of Things to Come

Key concept: Integrated model

Not just pretty pictures

Trace to other concepts

Show what you need to communicate

Goal: Executable


More Things


Whole/Part Hierarchy

Composite can show detailed communication paths

Further details added via ports

Same thing as Internal Block Diagram


Part Design Method


Operational Exchanges


The World


Operational Resource Flow Matrix

(OV-3)

Report of operational exchanges

Business-level Interface Exchange Requirement

(IER)

Performance and Information Assurance

parameters

Shows who, what, how


OV-3 Operational Resource Flow

Matrix


All Exchanges


Organization Chart (OV-4)

Organization Structure

Roles in organization

Example or actual organizations

Part of the system architecture


OV-4 Organizational Chart Typical


Operational Activity Decomposition

Tree

Hierarchy of Operational Activities

Relationship of activities to sub-activities

Reuse of activities

Related resources


Decomposition of Activity


Other Information


Operational Activity Flow

Behavior definition

Use of other activities (calls)

Logic/constraints of behavior

Swimlanes for orchestration across performers

(see Interaction Overview)


Send


Receive


Interaction Overview


OV-5b Overview


OV-6a Operational Rules

Constraints of the architecture

What the architecture must do

UML Constrains used throughout the

architecture

Includes agreements, guidance, policy etc.


OV-6a Operational Rules


OV-6b Operational State

Valid states of performers

Owned by the subject performer

UML State machine


Thing Two


OV-6c Operational Event Trace

Validates operational use of architecture

Roles are instances of performers

Can use methods on performers for further detail

Flows can be displayed from OV-2

Usually owned by a contextual performer


Thing World


Capability Related


CV-3 Capability Phasing


CV-4 Capability Dependencies


CV-6 Capability to Operational

Activity Mapping


Systems Interface Description

Shows how systems communicate

Can include humans and organizations

Physical manifestation of the Operational

Resource Flow


Widgets


Implementation Matrix


SV-2 Widget Network


SV-3 System to System Matrix


SV-4a


System Overview


SV-5a Operational Activity to

System Funtion Traceability Matrix


System Resource Matrix


SV-7 Typical Measures


SV-8 Evoloution of Widgets


Services View


Service Context


UPDM IN PRACTICAL USE

Relevant approach for Enterprise Architecture

Agile: Iterative model development

Accepted and promoted by the DoD

Reporting and traceability

Integrated architecture and development

Useful tool for capturing customer requirements


OV-1a: Operational Context Graphic

OV-1a [High Level Operational Concept] Maritime Rescue

Monitor Unit : Monitor

Rescue Helo : Aircraft

Yacht : Boat

Naval Ship : BoatRescue Boat : Boat

C2 Center : Control Center

distressSignal

trackInfo

trackInfo

assistance

control

control control

trackInfo


OV-1: Operational Context Graphic


OV-2 Operational Nodes

OV-2 [Node] Search and Rescue (With Ports)

«PerformerRole»

TC2N : Tactical C2MNSAC

RN

SN

«PerformerRole»

MN : Monitoring

PID

TCN

«PerformerRole»

PiD : Person in Distress

SN1

SN2RN

«PerformerRole»

PoS : Place of SafetySN

«PerformerRole»

RN : Rescue

TCNSAC

SN

PID

«PerformerRole»

SAR AC : SAR Asset ControlTCN

RNSN

«PerformerRole»

SN : Search

POS

PID

SAC

TCN

RN

Stat : status

DS3 : distressSignal

WO : warningOrder


TI : trackInfoRqst : request

Ctrl : controlTsk : tasking


Tsk : tasking

Ctrl : control


OV-5 Activity Diagram OV-5 [Architectural Description] Operational Activities

«Performer»«block»

Search

«Performer»«block»

Rescue

«Activity(Operational)»

Search

«StandardOperationalActivity»

Find Victim


Send Warning Order


Monitor Health


Receive Distress Signal


Rescue


Receive Distress Signal


Recover Victim


Provide Medical Assistance

«ActivityPerformedByPerformer»


«ActivityPerformedByPerformer» «ActivityPerformedByPerformer»

«ActivityPerformedByPerformer»«ActivityPerformedByPerformer»

«ActivityPerformedByPerformer» «ActivityPerformedByPerformer»



OV-5 Activity Diagram


SV-1: Resource Interaction Specification

SV-1 [System] Maritime Rescue Unit v1«SystemRole»

MRT : Maritime Rescue Team

«OrganizationRole»

Driver : MRT Boat Driver


Searcher : MRT SearcherMed


Radio Operator : MRT Communicator


Rescue Swimmer : MRT Swimmer


Pilot : MRT Helicopter Pilot

«SystemRole»

MR Aircraft : AircraftAir

«SystemRole»

Beacon : Lighting DeviceMon

«SystemRole»

Radio : Communication Device

Comm

«SystemRole»

MR Boat : Boat

«SystemRole»

Life Preserver : Life Saving Device

BI : boatInstruction

«DataExchange»«ItemFlow»

BCI : beaconInstruction


RI : radioInstruction


LPI : lifePreserverInstruction


AI : aircraftInstruction



SV-2: Resource Interaction Specification

SV-2 [System] Maritime Rescue Architecture v1

«SystemRole»

Yacht : Boat

«MaterielRole»

Distress Beacon : Lighting Device

dsOut

«MaterielRole»


receiver

transmitter

Src

Rsc

«SystemRole»

Rescue Unit : Maritime Rescue Unit v1

«SystemRole»

MR Aircraft : Aircraft

«MaterielRole»


transmitter

receiver

«MaterielRole»

Monitor : ESM System

dsIn trkIn

«MaterielRole»

Digital Service : Link 16

tdmReceiver

tdmTransmitter

trkOut

«SystemRole»

MR Boat : Boat

«MaterielRole»

Monitor : ESM SystemdsIn

trkIn

«MaterielRole»

Digital Service : Link 16

tdmTransmitter

tdmReceiver

trkOut

Src

Rsc

RI1 : radioInstruction

RI2 : radioInstruction

DS : distressSignal

TD1 : TDM

TD2 : TDM

TRK1 : track

DS : distressSignal

TRK2 : track


SysML Example: Requirements Traceability


Associated

Analysis Tools


Related Elements

Traceability Matrix

Dependency Matrix

Related elements display

Show relationships

Show ports

Show internal structure


TOGAF 9 (The Open Group)

100


Open

Group

ADM

101


Building block evolution

103


Service categories

104


ArchiMate

105


Archi

106

http://www.archimatetool.com/


Business Product View

108


ArchiMate

Authors : eSchoolink Group - ITNLU


Contents

1. What’s ArchiMate ?

2. Why ArchiMate ?

3. Main Benefits of ArchiMate

4. Layers of ArchiMate

5. ArchiMate vs UML

6. Notations of ArchiMate

7. Demo


What is ArchiMate?

ArchiMate is a modelling technique ("language") for describing enterprise architectures.

It presents a clear set of concepts within and relationships between architecture domains, and offers a simple and uniform structure for describing the contents of these domains.

ArchiMate distinguishes itself from other languages such as Unified Modeling Language (UML) and Business Process Modeling Notation (BPMN) by its well defined metamodel, and wider enterprise modelling scope.


What is ArchiMate?

ArchiMate offers a common language for describing

the construction and operation of business processes,

organizational structures, information flows, IT

systems, and technical infrastructure.

This insight helps the different stakeholders to design,

assess, and communicate the consequences of

decisions and changes within and between these

business domains.


What is ArchiMate?

An architecture framework is used to structure the

concepts and relationships of the ArchiMate language

It divides the enterprise architecture in to a business,

application and technology layer. In each layer, three

aspects are considered: active elements that exhibit

behavior (e.g. Process and Function), an internal

structure and elements that define use or

communicate information.


Why ArchiMate?

Enterprise architecture is an important instrument to address this company-wide integration.

It is a coherent whole of principles, methods and models that are used in the design and realization of the enterprise's organizational structure, business processes, information systems, and IT infrastructure.


Why ArchiMate?

A good architecture practice enables an organization

to align business and IT operations with its strategy,

quickly respond to changes in the environment, and

make optimal use of technological opportunities.

The development and maintenance of architectures

will lead to efficiency, cost reduction and flexibility.


Why ArchiMate?

Within companies various domain architectures can

be found, like organization, business process,

application, information, and technical architectures.

Each architecture domain has its own concepts for

the modelling and visualization of its internal

coherence. These specific models and visualizations

simplify communication, discussion and analysis

within the domain


Why ArchiMate?

However, the relations between the concepts in these

different domains are in many cases unclear.

Moreover, these domains often partially overlap but

use different notions to express the same ideas,

sometimes even with-out the people involved knowing

this.

The resulting ambiguities and confusion stand in the

way of the flexibly and efficiently operating

organizations we envisage.


Why ArchiMate?

ArchiMate wants to do away with these ambiguities. It presents a unified way of modelling enterprise architectures, integrating the various domains and describing them in an easily readable way

ArchiMate is of course not an isolated development. The relationships with existing methods and techniques, like modelling languages such as UML and BPMN, and methods and frameworks like TOGAF and Zachman, are well-described.


Main Benefits of ArchiMate

1. It is an international, vendor-independent standard of The Open Group, liberating you from the lock-in of vendor-specific tools and frameworks. There is active support from the ArchiMate Forum of The Open Group.

2. Its well-founded concepts and models provide precision. It helps you get away from the 'fuzzy pictures' image of architecture.

3. It is a lean and simple language. It contains just enough concepts for modeling enterprise architecture and is not bloated to include everything possible. Its uniform structure makes it easy to learn and apply.


Main Benefits of ArchiMate

4. It has clear links to existing approaches for specific architecture areas such as software or business processes. Several concepts in ArchiMate have deliberately been borrowed from other languages such as UML or BPMN, to provide an easy bridge.

5. It does not prescribe a way of working, but it is easily combined with existing methods such as TOGAF.

6. It has been tried and tested by many different user organizations and is supported by numerous consultancies and software tools.


Layers

A layered view provides a natural way to look at service-oriented

models. The higher layers use services that are provided by the

lower layers. ArchiMate distinguishes three main layers:

The Business layer offers products and services to external

customers, which are realized in the organization by business

processes performed by business actors and roles.

The Application layer supports the business layer with

application services which are realized by (software)

application components.

The Technology layer offers infrastructural services (e.g.,

processing, storage and communication services) needed to

run applications, realized by computer and communication

hardware and system software.


Layers


Layers , domains


Overview of the ArchiMate concepts and main relationships.


ArchiMate vs UML

ArchiMate

ArchiMate was created to

model the architecture of an

enterprise (all of the

systems in an organization).

ArchiMate models the

business, information

system (application and

data), and technology

architectures of the

environment, including how

these architectures are

inter-related.

UML UML still functions best as

a way to document the

architecture of a single

system

UML provides 13 diagram

types, providing flexibility

to describe many different

types of systems.


ArchiMate vs UML

Archimate started with an understanding that these problems relate to one another; that the entire complex and difficult business of understanding IT requires a rich inter-relationship of completely different domains, from business motivation to business process to managed services to systems to infrastructure.

Thus Archimate goes where UML doesn’t: it defines a metamodel that allows these relationships to be constructed, and constrained, and communicated. The constraints allow analysis, traceability, governance, and consistency. UML is unconstrained between model types. Archimate is not.


Notations

Every concept and relation should have a precise graphical notation, with a sufficient resemblance the ‘standard’ ArchiMate notation. The notation in the Visio stencils can be used as a guideline

Optionally, multiple notations may exist for a single concept.

It should be possible to denote composition, aggregation and assignment both with their ‘line’ notation and with nesting.


Relations

The following relation types should be supported: Structural relations:

composition*

aggregation

assignment

used by

realisation

access

association

Dynamic relations: triggering

flow

Other relations: grouping

junction

specialisation*


Notations


Notations & Relations


Demo


Observations and Measurements

140


Observations and Measurements ISO19156

141


The basic O&M observation event

concepts

142


144

144

W3C SSN-XG ontology

makes

observations of

this type

where it is

What it

measures

units

SSN-XG ontologies

SSN-XG annotations

W3C – Semantic Sensor Network Ontology


O&M vs SSN

145

IJC - IPM · Telecom and Informatics 1 INF5120 ”Modellbasert Systemutvikling” ”Modelbased...

Documents

Transcript of IJC - IPM · Telecom and Informatics 1 INF5120 ”Modellbasert Systemutvikling” ”Modelbased...