Extension Mechanism for Integrating New Technology Elements into Viewpoint based Enterprise...
-
Upload
akira-tanaka -
Category
Technology
-
view
170 -
download
0
description
Transcript of Extension Mechanism for Integrating New Technology Elements into Viewpoint based Enterprise...
Extension Mechanism for Integra3ng New Technology Elements into
Viewpoint based Enterprise Architecture Framework
Akira Tanaka, view5 LLC
Agenda • Background (context and issues)
– Modeling SoJware – Enterprise Architecture – New technologies
• Flexible Enterprise Architecture against new technologies – Proposed Mechanism: Meta-‐modeling and Profiling with Package
Merge – Use Cases
• Discussion • Conclusion
Background (1 of 3) • Architecture for SoJware Systems
– Iden3fies components, their behavior, and rela3onships among them for specific domain • Examples: MVC, Client/Server, Three Tier, SOA …
• Enterprise Architecture – Architecture for Enterprise Compu3ng Systems
• Combina3on of business and IT architectures for business execu3ons • Examples: Zachman, TOGAF, FEA, DoDAF, MODAF, and RM-‐ODP
– A way of organizing system specifica3ons from mul3ple viewpoints or perspec3ves, some3mes used to contrast as-‐is and to-‐be specifica3ons and develop to-‐be system from as-‐is system
– Issues: • Enterprise Compu3ng Systems (instances) evolve over 3me to become more
and more complex and difficult to understand. • A gap between architecture and its implementa3on widens unless there is an
effort for synchroniza3on in place.
Background (2 of 3) • New Technologies
– May arrive at any moment • Hard to predict what comes and when it comes
– May have impact upon enterprise • Organiza3on structure, informa3on structure, human behavior, and IT
pla_orms • System management and Security aspects
– Examples • Mobile Compu3ng (Smart Phone and Tablet) • Social Networking • Cloud Compu3ng • NoSQL • E-‐Books • Big Data • E-‐health (new external domain) … etc.
Background (3 of 3) • SoJware Modeling
– Raising the level of abstrac3ons by suppressing unnecessary details • Programming Languages:
– Machine language -‐> Assembler, C, C++, LISP, COBOL, Pascal, Smalltalk, Java, JavaScript, Ruby, …
• Libraries, Components, Frameworks, … • SoJware Modeling
– Modeling “SoJware” • Formal Specifica3ons (preciseness) and Valida3ons • Model Driven SoJware Development/Engineering
– MOF, UML(Class, Ac3vity, etc.), BPMN, … – Model Transforma3ons and Code Genera3on
– Issues • Choosing appropriate or suitable level of abstrac3on • Synchroniza3on between model and code
Problem Statements and Proposed Approach
• For “enterprise compu3ng” domain, there is no widely accepted way for developing flexible or “designed/ready-‐for-‐change” enterprise systems. – Addi3ons of new technology elements should not be a problem. It should also
enable smooth migra3on.
• Proposed approach: Use Modeling and Enterprise Architecture – Design and develop at higher level of abstrac3on
• Make best use of Modeling technologies including UML and its extension mechanism
• Make Models flexible and easy to integrate • Choose/Use enterprise applica3on framework to achieve/keep consistency
Choices made for this work • Choice of Modeling Language
– UML is the most widely used modeling language and interna3onal standard • MOF: A subset of UML Class Diagram is used as nota3on. • Others: Graphical/Textual DSLs, Tool specific nota3ons, etc.
• Choice of Enterprise Architecture Framework – RM-‐ODP is, at this moment, the only open one (standard
specifica3ons and UML Profile are freely available on-‐line) • Zachman Framework: Not open • TOGAF: Semi open (consor3um backed) • FEA, DoDAF, and MODAF: Openly published but government owned
• Choice of example technologies for discussion – Mobile Compu3ng, Cloud Compu3ng, and Social Networking
SOFTWARE MODELING
Meta-‐models • Meta-‐model is a model, [for specific domain,] [consis/ng of
iden/fied concepts, rela/onships among them, and constraints on them,] for defining models [of that domain]. – E.g. UML specifica3on includes meta-‐model of UML itself, expressed
using subset of UML Class Diagram.
• In our work, we needed meta-‐models for RM-‐ODP and for New Technologies – RM-‐ODP’s meta-‐model is in RM-‐ODP standard. – Searched exis3ng work and developed simple Meta-‐models for
example technologies.
Layers of Models
Meta-‐meta model
Metamodel
Model
Instance or Object Model
Instance of
conform to
conform to
MOF (CMOF, EMOF/ecore)
e.g. UML, SOA, BPMN, …
e.g. UML models, SOA models, BPMN models, …
M3
M2
M1
M0
Meta-‐models (in general)
Enterprise Architecture Domain
Meta-‐Models for Technologies type #1
Meta-‐models for Enterprise Architecture
Type #1: Completely independent of Enterprise Architecture Type #2: With some overlap with Enterprise Architecture Type #3: Specializing a part of Enterprise Architecture
Overlapping meta-‐models
Meta-‐Models for Technologies type #2
Meta-‐Models for Technologies type #3
UML
Integra3ng Meta-‐models • At the highest level, package merge is used to achieve the
flexible extensions (used in UML specifica3on to define UML Meta-‐model).
UML Package Merge (merged package)
(receiving package) (resul3ng package)
NOTE: Research Paper – “Modeling UML 2 Package Merge with Alloy”
UML Profile • Standard Extension mechanism for UML
– Many UML Profile standards exist today • Workflow for developing and using UML Profile
– Define Meta-‐model for target domain – Define mapping of meta-‐model elements onto UML by extending
meta-‐classes and by defining stereotypes, tag-‐defini3ons, and constraints
– Implement UML Profile (stereotypes and others) within your UML tool – Create UML models and apply defined UML Profile
• UML Profile for – RM-‐ODP: exists as a standard – New Technologies: can be developed based on their meta-‐models
UML Profile Standard examples
Source OMG : hop://www.omg.org/spec/
UML and UML Profiles (in general)
Enterprise Architecture Domain
UML Profiles for Technologies type #1
UML Profiles for Enterprise Architecture
Type #1: Completely independent of Enterprise Architecture Type #2: With some overlap with Enterprise Architecture Type #3: Specializing a part of Enterprise Architecture
Overlapping UML Profiles
UML Profiles for Technologies type #2
UML Profiles for Technologies type #3
Integra3ng UML Profiles • Since UML Profile is represented as a package with stereotype
«profile», package merge can also be applied (in theory).
ENTERPRISE ARCHITECTURE
DoDAF
RM-‐ODP
Reference Model for Open Distributed Processing
• RM-‐ODP defines founda3onal concepts, viewpoint languages, correspondences etc.
RM-‐ODP Meta-‐Model
NOTE: Par3al diagram from standard’s working model
RM-‐ODP Profile
NOTE: Par3al profile data
EXAMPLE NEW TECHNOLOGIES
Social Netw
orking
NoSQL
Mobile Compu3ng Meta-‐Model
Class
Node «stereotype» Place
Device Execu3onEnvironment
Associa3on
«stereotype» NodeLoca3on
Dependency
Deployment
DeploymentTarget
«stereotype» AllowedDeployment
«stereotype» CurrentDeployment
1 +loca3on
+loca3on
Node «stereotype» Place
+loca3on +nestedNode
+nestedNode
+nestedNode
A UML Profile to Model Mobile Systems V. Grassi, R. Mirandola, A. Sabeoa «UML» 2004 – The Unified Modeling Language
Source:
UML Meta-‐model element
Introduced element
NIST’s Cloud Taxonomy
hop://collaborate.nist.gov/twiki-‐cloud-‐compu3ng/pub/CloudCompu3ng/ReferenceArchitectureTaxonomy/RA_Cloud_Taxonomy_Version_1.pdf
Source (also a part of NIST Cloud Compu3ng Reference Architecture):
Important aspects from cloud consumer’s point of view
Mobile & Cloud extensions
i.e. all other concepts are s3ll available for mobile and cloud system specifica3ons.
Par3al enterprise language
means e.g.
Social Network Meta-‐Model Simplified version of Facebook meta-‐model published on the web (hop://commons.wikimedia.org/wiki/File:Metamodel_of_Facebook.jpg)
Source: “Represen3ng Social Structures in UML,” by H. Van Dyke Parunak and James J. Odell
Social Network extension
means e.g.
Par3al enterprise language
UML Profile Integra3on
• Mobile and Cloud – By modifying exis3ng UML Profile for RM-‐ODP
UML Profile Integra3on
• Social Networking – By modifying exis3ng UML Profile for RM-‐ODP
Rela3vely small number of modifica3ons is due to the fact that RM-‐ODP, one of Enterprise Architecture Framework, has already captured some core concepts even applicable for new technologies.
Sample Diagram Fragment Enterprise Viewpoint
Sample Diagram Fragment Informa3on Viewpoint
«merge»
Cloud-‐aware and social-‐aware object types can be added to exis3ng informa3on model.
Sample Diagram Fragment Computa3onal Viewpoint
Mobile-‐aware objects and cloud-‐aware object can be added to exis3ng model (needs re-‐wiring etc.)
Sample Diagram Fragment Engineering Viewpoint
Cloud-‐aware channel can be introduced to exis3ng engineering model.
Sample Diagram Fragment Technology Viewpoint
Mobile Object/Phone can be added to exis3ng model
Sample Diagram Fragment Correspondence
• Correspondence is to ensure the rela3onship of the elements in two different views. – Examples
• Order Processing (Enterprise) should be processed by PurchaseManager on the cloud (Engineering).
• GUI_Employee (Engineering) should be supported by MobilePhoneApp (Technology).
Summary of our proposed Extension Mechanism
• Basic steps – Choose the main domain and narrow down by selec3ng usable specifica3ons
• Enterprise Architecture -‐> RM-‐ODP (could be other one)
– Move to Meta-‐Modeling space, analyze the target domain to capture all the core concepts (e.g. for New Technologies)
– Associate those concepts to exis3ng RM-‐ODP concepts (package merge). – Move to UML Profile defini3on space – Modify exis3ng Profile elements to reflect new meta-‐model elements, or add
new elements if no relevant profile element existed (package merge).
Discussion (1 of 3) • What’s the point of having flexible EA?
– Enterprise systems are developed to execute day-‐to-‐day opera3ons, and therefore should be very stable. Is proposed mechanism good enough to make this “ready-‐for-‐change”? • Three use cases have shown it is applicable. • More complex cases should be studied in future, especially around conflict
resolu3ons.
– To plan and execute at higher level of abstrac3on on top of stable founda3on or EA is logical and beneficial to stakeholders. • Especially true for complex systems like enterprise systems
– Further work • Conflict resolu3ons at meta-‐model level and at profile level
Discussion (2 of 3) • Next step?
– UML models are not just drawings. They should be used as input to Model Driven SoJware Development (MDSD). • Use of (meta-‐)modeling is
– a good prac3ce, if it helps increase stability, flexibility and produc3vity. – an overhead, if output is not effec3vely used/consumed
• Model-‐based Enterprise Architecture
– Processing models • Structural aspect of system specifica3ons can be transformed into code with
model-‐to-‐text transforma3on template and engine. • Behavioral aspect of system specifica3ons are not ready for model transforma3on
into code. Ac3vity-‐based models (e.g. Ac3vity and BPMN) do not standardize ac3ons and their granularity (Further work).
– Prac3cal tools for UML modeling and model processing • Open source tools such as eclipse Papyrus, EMF, GMF, Acceleo, and Xtext/Xtend
may have a place in the tool chain.
Discussion (3 of 3) • Interoperability among Enterprise Architecture Frameworks
– The explained mechanism is applicable to other EA Framework, provided that • they have good documenta3on (for understanding) • they have Meta-‐Model (preferably published one) • they have UML Profile (can be defined based on above)
– Even done so, interoperability requires common language, otherwise more than necessary transforma3ons will be needed.
– As of today, RM-‐ODP is well suited as common language, since it is a standard, document is published, and meta-‐model and UML Profile data are also published for other framework players to use.
– Further work • Discussion with open source enterprise architecture tools, e.g. Essen3al, may be the next step for common language.
Conclusion • The three example use cases have shown that proposed
mechanism is applicable to enterprise compu3ng domain. – Meta-‐modeling and UML Profiling is a good tool for architectural modeling. – Integra3on should be done with Package Merge, which will help future
automa3on. • Meta-‐models and UML Profiles can be selec3vely used like library. Real tool
support is expected.
– Output UML model should be used as an input to MDSD process. – Behavioral modeling based on Ac3vity or Business Process is important and
for further study. – Tooling is important and integra3on of open source tools is promising toward
this direc3on. – This proposed mechanism could be applied to other domain than enterprise
compu3ng.