Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
Telecom and Informatics 1
INF5120
”Modellbasert Systemutvikling”
”Modelbased System development”
Lecture 14: 04.05.2015 Arne-Jørgen Berre
Telecom and Informatics 2
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
Telecom and Informatics 3
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
Telecom and Informatics
MagicDraw
Cameo Enterprise Architecture
5
Telecom and Informatics 6
Telecom and Informatics 7
Telecom and Informatics 8
Telecom and Informatics 9
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
Telecom and Informatics 10
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)
Telecom and Informatics
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
Telecom and Informatics 12
Many Architectural Frameworks ….
ARIS ZACHMAN GERAM
EN/ISO 19439
NIST
EKA - POPS EKA - POPS EKA - POPS
Athena OEA
Telecom and Informatics
TOGAF 9 (The Open Group)
13
Telecom and Informatics 14
Telecom and Informatics
ISO RM/ODP (ISO 10746)
Telecom and Informatics
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
Telecom and Informatics
Towards a Unified Architecture
Framework
17
Telecom and Informatics 18
Three Views in
DOD Architecture Framework and C4ISR-AF
Telecom and Informatics
DODAF 2.0 - viewpoints
19
Telecom and Informatics
EAEA – European Air Traffic
Management Enterprise Architecture
20
Telecom and Informatics
IEEE 1471, ISO 42010
21
Telecom and Informatics
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
Telecom and Informatics
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
Telecom and Informatics
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
Telecom and Informatics
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
Telecom and Informatics
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
Telecom and Informatics
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
Telecom and Informatics
UPDM - – Unified Model for DODAF
and MODAF
28
Telecom and Informatics
UPDM
29
Telecom and Informatics 30
Telecom and Informatics 31
Telecom and Informatics
Enterprise Architecture
Modeling with UPDM
Telecom and Informatics
Introduction
Enterprise Architecture modeling
No rocket science!
It's a standard!
UPDM:
Unified Profile for MODAF and DoDAF
Telecom and Informatics
What is Enterprise Architecture?
Telecom and Informatics
Enterprise Architecture
Business, partners, customers
Application ecosystem
System of system architecture
The world
Not: application or device
Telecom and Informatics
UML EA Framework
Semantic classification
Extra rules for construction
Additional data
Traceability between views
Telecom and Informatics
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
Telecom and Informatics
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
Telecom and Informatics
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
Telecom and Informatics
Structure
Telecom and Informatics
Simple Example
Two things (very simple model)
Presentation not in build order
Key elements of UPDM used
Telecom and Informatics
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
Telecom and Informatics
OV-1 Thing Concept
Telecom and Informatics
Thing HLOC
Telecom and Informatics
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
Telecom and Informatics
Thing World
Telecom and Informatics
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
Telecom and Informatics
More Things
Telecom and Informatics
Whole/Part Hierarchy
Composite can show detailed communication paths
Further details added via ports
Same thing as Internal Block Diagram
Telecom and Informatics
Part Design Method
Telecom and Informatics
Operational Exchanges
Telecom and Informatics
The World
Telecom and Informatics
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
Telecom and Informatics
OV-3 Operational Resource Flow
Matrix
Telecom and Informatics
All Exchanges
Telecom and Informatics
Organization Chart (OV-4)
Organization Structure
Roles in organization
Example or actual organizations
Part of the system architecture
Telecom and Informatics
OV-4 Organizational Chart Typical
Telecom and Informatics
Operational Activity Decomposition
Tree
Hierarchy of Operational Activities
Relationship of activities to sub-activities
Reuse of activities
Related resources
Telecom and Informatics
Decomposition of Activity
Telecom and Informatics
Other Information
Telecom and Informatics
Operational Activity Flow
Behavior definition
Use of other activities (calls)
Logic/constraints of behavior
Swimlanes for orchestration across performers
(see Interaction Overview)
Telecom and Informatics
Send
Telecom and Informatics
Receive
Telecom and Informatics
Interaction Overview
Telecom and Informatics
OV-5b Overview
Telecom and Informatics
OV-6a Operational Rules
Constraints of the architecture
What the architecture must do
UML Constrains used throughout the
architecture
Includes agreements, guidance, policy etc.
Telecom and Informatics
OV-6a Operational Rules
Telecom and Informatics
OV-6b Operational State
Valid states of performers
Owned by the subject performer
UML State machine
Telecom and Informatics
Thing Two
Telecom and Informatics
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
Telecom and Informatics
Thing World
Telecom and Informatics
Capability Related
Telecom and Informatics
CV-3 Capability Phasing
Telecom and Informatics
CV-4 Capability Dependencies
Telecom and Informatics
CV-6 Capability to Operational
Activity Mapping
Telecom and Informatics
Systems Interface Description
Shows how systems communicate
Can include humans and organizations
Physical manifestation of the Operational
Resource Flow
Telecom and Informatics
Widgets
Telecom and Informatics
Implementation Matrix
Telecom and Informatics
SV-2 Widget Network
Telecom and Informatics
SV-3 System to System Matrix
Telecom and Informatics
SV-4a
Telecom and Informatics
System Overview
Telecom and Informatics
SV-5a Operational Activity to
System Funtion Traceability Matrix
Telecom and Informatics
System Resource Matrix
Telecom and Informatics
SV-7 Typical Measures
Telecom and Informatics
SV-8 Evoloution of Widgets
Telecom and Informatics
Services View
Telecom and Informatics
Service Context
Telecom and Informatics
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
Telecom and Informatics
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
Telecom and Informatics
OV-1: Operational Context Graphic
Telecom and Informatics
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
DS2 : distressSignal
TI : trackInfoRqst : request
Ctrl : controlTsk : tasking
DS1 : distressSignal
Tsk : tasking
Ctrl : control
Telecom and Informatics
OV-5 Activity Diagram OV-5 [Architectural Description] Operational Activities
«Performer»«block»
Search
«Performer»«block»
Rescue
«Activity(Operational)»
Search
«StandardOperationalActivity»
Find Victim
«Activity(Operational)»
Send Warning Order
«StandardOperationalActivity»
Monitor Health
«Activity(Operational)»
Receive Distress Signal
«Activity(Operational)»
Rescue
«Activity(Operational)»
Receive Distress Signal
«StandardOperationalActivity»
Recover Victim
«StandardOperationalActivity»
Provide Medical Assistance
«ActivityPerformedByPerformer»
«ActivityPerformedByPerformer»
«ActivityPerformedByPerformer» «ActivityPerformedByPerformer»
«ActivityPerformedByPerformer»«ActivityPerformedByPerformer»
«ActivityPerformedByPerformer» «ActivityPerformedByPerformer»
«ActivityPerformedByPerformer»
Telecom and Informatics
OV-5 Activity Diagram
Telecom and Informatics
SV-1: Resource Interaction Specification
SV-1 [System] Maritime Rescue Unit v1«SystemRole»
MRT : Maritime Rescue Team
«OrganizationRole»
Driver : MRT Boat Driver
«OrganizationRole»
Searcher : MRT SearcherMed
«OrganizationRole»
Radio Operator : MRT Communicator
«OrganizationRole»
Rescue Swimmer : MRT Swimmer
«OrganizationRole»
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
«DataExchange»«ItemFlow»
RI : radioInstruction
«DataExchange»«ItemFlow»
LPI : lifePreserverInstruction
«DataExchange»«ItemFlow»
AI : aircraftInstruction
«DataExchange»«ItemFlow»
Telecom and Informatics
SV-2: Resource Interaction Specification
SV-2 [System] Maritime Rescue Architecture v1
«SystemRole»
Yacht : Boat
«MaterielRole»
Distress Beacon : Lighting Device
dsOut
«MaterielRole»
Radio : Communication Device
receiver
transmitter
Src
Rsc
«SystemRole»
Rescue Unit : Maritime Rescue Unit v1
«SystemRole»
MR Aircraft : Aircraft
«MaterielRole»
Radio : Communication Device
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
Telecom and Informatics
SysML Example: Requirements Traceability
Telecom and Informatics
Associated
Analysis Tools
Telecom and Informatics
Related Elements
Traceability Matrix
Dependency Matrix
Related elements display
Show relationships
Show ports
Show internal structure
Telecom and Informatics
TOGAF 9 (The Open Group)
100
Telecom and Informatics
Open
Group
ADM
101
Telecom and Informatics 102
Telecom and Informatics
Building block evolution
103
Telecom and Informatics
Service categories
104
Telecom and Informatics
ArchiMate
105
Telecom and Informatics
Archi
106
http://www.archimatetool.com/
Telecom and Informatics 107
Telecom and Informatics
Business Product View
108
Telecom and Informatics
ArchiMate
Authors : eSchoolink Group - ITNLU
Telecom and Informatics
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
Telecom and Informatics
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.
Telecom and Informatics
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.
Telecom and Informatics
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.
Telecom and Informatics
Telecom and Informatics
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.
Telecom and Informatics
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.
Telecom and Informatics
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
Telecom and Informatics
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.
Telecom and Informatics
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.
Telecom and Informatics
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.
Telecom and Informatics
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.
Telecom and Informatics
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.
Telecom and Informatics
Layers
Telecom and Informatics
Layers , domains
Telecom and Informatics
Layers , domains
Telecom and Informatics
Overview of the ArchiMate concepts and main relationships.
Telecom and Informatics
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.
Telecom and Informatics
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.
Telecom and Informatics
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.
Telecom and Informatics
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*
Telecom and Informatics
Notations
Telecom and Informatics
Notations & Relations
Telecom and Informatics
Demo
Telecom and Informatics
Demo
Telecom and Informatics
Demo
Telecom and Informatics
Demo
Telecom and Informatics
Demo
Telecom and Informatics
Telecom and Informatics
Telecom and Informatics
Observations and Measurements
140
Telecom and Informatics
Observations and Measurements ISO19156
141
Telecom and Informatics
The basic O&M observation event
concepts
142
Telecom and Informatics 143
Telecom and Informatics
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
Telecom and Informatics
O&M vs SSN
145