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

arneb@ifi.uio.no or Arne.J.Berre@sintef.no

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

ArchiMate og Archi

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

Data Model Patterns

Ontologies – Linked Data RDF/OWL

SSN – Semantic Sensor Network Ontology

MagicDraw

Cameo Enterprise Architecture

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

Contextual

Conceptual

Logical

Physical

As Built

Functioning

Contextual

Conceptual

Logical

Physical

As Built

Functioning

Based on work by

John A. Zachman

VA Enterprise

Architecture

DATAWhat

FUNCTIONHow

NETWORKWhere

PEOPLEWho

TIMEWhen

MOTIVATIONWhy

DATAWhat

FUNCTIONHow

NETWORKWhere

PEOPLEWho

TIMEWhen

MOTIVATIONWhy

(CONTEXTUAL)

Planner

ENTERPRISE

(CONCEPTUAL)

SYSTEM MODEL

(LOGICAL)

Designer

TECHNOLOGY

(PHYSICAL)

Builder

DETAILED

REPRESENTATIONS

(OUT-OF-CONTEXT)

Sub-Contractor

FUNCTIONING

ENTERPRISE

(CONTEXTUAL)

Planner

ENTERPRISE

(CONCEPTUAL)

SYSTEM MODEL

(LOGICAL)

Designer

TECHNOLOGY

(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

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

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

End = Structural Assertion

Means = Action Assertion

Physical Data

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

Design

End = Condition

Means = Action

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

Design

End = Sub-Condition

Means = Step

Function

Proc =

Netw ork

Node =

Link =

Organization

People =

Work =

Schedule

Time =

Cycle =

Strategy

Means =

Based on work by

John A. Zachman

VA Enterprise

Architecture

DATAWhat

FUNCTIONHow

NETWORKWhere

PEOPLEWho

TIMEWhen

MOTIVATIONWhy

DATAWhat

FUNCTIONHow

NETWORKWhere

PEOPLEWho

TIMEWhen

MOTIVATIONWhy

(CONTEXTUAL)

Planner

ENTERPRISE

(CONCEPTUAL)

SYSTEM MODEL

(LOGICAL)

Designer

TECHNOLOGY

(PHYSICAL)

Builder

DETAILED

REPRESENTATIONS

(OUT-OF-CONTEXT)

Sub-Contractor

FUNCTIONING

ENTERPRISE

(CONTEXTUAL)

Planner

ENTERPRISE

(CONCEPTUAL)

SYSTEM MODEL

(LOGICAL)

Designer

TECHNOLOGY

(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

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

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

End = Structural Assertion

Means = Action Assertion

Physical Data

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

Design

End = Condition

Means = Action

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

Design

End = Sub-Condition

Means = Step

Function

Proc =

Netw ork

Node =

Link =

Organization

People =

Work =

Schedule

Time =

Cycle =

Strategy

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),

Service modeling and Service oriented views

Tool support , Metamodels and UML profiles – No Magic,

Magic Draw

Many Architectural Frameworks ….

ARIS ZACHMAN GERAM

EN/ISO 19439

EKA - POPS EKA - POPS EKA - POPS

Athena OEA

TOGAF 9 (The Open Group)

ISO RM/ODP (ISO 10746)

Why and When: Historical Development of AF’s.

Architectur

Framework

Architectur

Framework

Scope of UPDM 1.0

Approved Sept 2008

Meta-Model (M3)

expressed using

UML Notation

Scope of UPDM 2.0

Started Sept 2009

TOGAF1 - … TOGAF9

MACCIS

Norway

Towards a Unified Architecture

Framework

Three Views in

DOD Architecture Framework and C4ISR-AF

DODAF 2.0 - viewpoints

EAEA – European Air Traffic

Management Enterprise Architecture

IEEE 1471, ISO 42010

Zachman with OMG standards

(What)

Function

Network

(Where)

People

(When)

Motivation

(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

IMM (CWM)

Business Process

BPMN, CMPM

Business Logistics

System

BPMN, CMPM

Workflow Model

OSM, BPMN,

Master Schedule

BPMN, CMPM,

Business

Logical Data Model

IMM (CWM), UML

Application

Architecture

SoaML, UML

Distributed

System Architecture

SoaML, UML

Human Interface

Architecture

BPMN, CMPM

Process Structure

BPMN, CMPM,

Business Rule

Physical Data Model

IMM (CWM), UMLSystem Design

SoaML, UML

Technology

Architecture

SoaML, UML

Presentation

Architecture

Control Structure

BPMN, CMPM,

Design

Data Definition

IMM (CWM), UMLProgram

Network

Architecture

Security

Architecture

Timing

Definition

Operation

(Instances)Data Function Network Organization Schedule Strategy

OMG standards coverage

(What)

Function

Network

(Where)

People

(When)

Motivation

(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

Business

Logistics

System

Workflow

Master

Schedule

Business

Logical Data ModelApplication

Architecture

Distributed

System

Architecture

Interface

Architecture

Process

Structure

Business Rule

Physical Data Model System DesignTechnology

Architecture

Presentation

Architecture

Control

Structure

Design

Data Definition ProgramNetwork

Architecture

Security

Architecture

Timing

Definition

Operation

(Instances)Data Function Network Organization Schedule Strategy

VDM OSMSBVR

UMLIMM

UPDM coverage

(What)

Function

Network

(Where) People

(When)

(Contexts)

Business

(Concepts)

System

(Logic)

Technology

(Physics)

Component (Assemblies)

Operation

(Instances)

Motivation

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)

CaseMgmt

UML 2.0

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

Canada/Australia

OMG, INCOSE

XMI, UML, SysML

UPMS, BMM

End Users

Aerospace

Commercial

Tool Vendors

Software

Systems

Enterprise

UPDM Domain Meta Model

UPDM Profile Meta Model

UPDM Profile

Library

UML4SysML SysML

NAF Meta Model CADM 1.5

DoDAF 2.0 Ontology

SysML Extensions

SoaML, BMM,

SBVr Extensions

<<import/merge>>

MODAF Meta Model

DoDAF 1.5 Concepts

SF List

CONOPS

Products -- Reports -- Simulations

UPDM - – Unified Model for DODAF

and MODAF

Enterprise Architecture

Modeling with UPDM

Introduction

Enterprise Architecture modeling

No rocket science!

It's a standard!

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

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

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

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)

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

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

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

«PerformerRole»

MN : Monitoring

«PerformerRole»

PiD : Person in Distress

«PerformerRole»

PoS : Place of SafetySN

«PerformerRole»

RN : Rescue

TCNSAC

«PerformerRole»

SAR AC : SAR Asset ControlTCN

«PerformerRole»

SN : Search

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»

«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

«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

«MaterielRole»

receiver

transmitter

«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

«MaterielRole»

Digital Service : Link 16

tdmTransmitter

tdmReceiver

trkOut

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)

Building block evolution

Service categories

ArchiMate

http://www.archimatetool.com/

Business Product View

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

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

Other relations: grouping

junction

specialisation*

Notations

Notations & Relations

Observations and Measurements

Observations and Measurements ISO19156

The basic O&M observation event

concepts

W3C SSN-XG ontology

observations of

this type

where it is

What it

measures

SSN-XG ontologies

SSN-XG annotations

W3C – Semantic Sensor Network Ontology

O&M vs SSN

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

Documents

”Modellbasert Systemutvikling” ”Modelbased System development”€¦ · ”Modellbasert Systemutvikling” ”Modelbased System development” Lecture 13: 23.04.2012 Arne-Jørgen

Teknologi for et bedre samfunn 1 INF5120 Modellbasert systemutvikling 14 th of March 2011 Marika Lüders, forsker ved SINTEF IKT / marika.luders@sintef.no

INF5120 – Modellbasert Systemutvikling · Telecom and Informatics 4 Rational for introducing usability IBM gained a 400% increase in online sales (and an 84% decrease in help button

INF5120 ”Modellbasert Systemutvikling” …€Modellbasert Systemutvikling” ”Modelbased System development” ... UML 2.0 – what is new in version 2 ... – “Service Analysis

Telecom and Informatics 1 INF5120 ”Modellbasert Systemutvikling” ”Modelbased System development” Lecture 6: 20.02.2012 Arne-Jørgen Berre arneb@ifi.uio.noarneb@ifi.uio.no

”Modellbasert Systemutvikling” ”Modelbased System development” · BPMN model Services Two pages Retrieval of session data (CurrentUser) Review Page • Lists of (prefered)

INF5120 – Modellbasert Systemutvikling · Recurrence Teaching (e.g ... The Liskov Substitution Principle ... forward the operation to its children (and/or perform additional work

Model-Driven Specification of Interoperable Service ... · 1 ICT 1 INF5120 ”Modellbasert Systemutvikling” ”Modelbased System development” Lecture 5: 21.02.2011 SIE I: Service

INF5120 ”Modellbasert Systemutvikling” ”Modelbased System ... · n SAE-3 (Lecture 10, April 4 th): BPMN and WebRatio BPM platform/Magicdraw BPMN n Oblig2: Sirius DSL Editor

INF5120 ”Modellbasert Systemutvikling” ”Modelbased …...INF5120 ”Modellbasert Systemutvikling” ”Modelbased System development” Forelesning 27.01.2005 Arne-Jørgen Berre

ICT INF5120 Modellbasert Systemutvikling F08: Service Modeling and SOA and Service Design - GRASP Patterns, Design Patterns, SOA Patterns and Refactoring

”Modellbasert Systemutvikling” ”Modelbased System development” · UML Composite Diagrams Composite Diagrams A composite structure diagram is a diagram that shows the internal

ICT 1 INF5120 Modellbasert systemutvikling Web Services XML Schema WSDL BPEL Forelesning 26.03.2007 Roy Grønmo roy.gronmo@sintef.no

Content · 1 ICT 1 INF5120 ”Modellbasert Systemutvikling” ”Modelbased System development” Lecture 2: 28.01.2008 Arne-Jørgen Berre ICT Content Lectures and exercices …

INF5120 – Modellbasert Systemutvikling€¦ · 4/3/2011 1 INF5120 – Modellbasert Systemutvikling F10-2: Architectural Patterns, Design Patterns and Refactoring L t 28 03 2011

INF5120 ”Modellbasert Systemutvikling” ”Modelbased System ......1-16/1: Introduction to INF5120 2-23/1: Modeling structure and behaviour (UML and UML 2.0 and metamodeling) -

Telecom and Informatics INF5120 Modellbasert Systemutvikling F13: Model Driven Semantic interoperability – with Semantic web, Ontologies and Semantic SOA

GUIDE 04.05.2015, Page-1

INF5120 ”Modellbasert Systemutvikling” ”Modelbased System

INF5120 ”Modellbasert Systemutvikling” ”Modelbased System … · INF5120 Model based System Development 24.01.2011 4 Telecom and Informatics OBLIGS: –“MDE tools in practice”