It's about integrating mobile, cloud, and social networking into RM-ODP (experimental).

1. Extension
Mechanism
for
Integra3ng
New
Technology
Elements
into
Viewpoint
based
Enterprise
Architecture
Framework
Akira
Tanaka,
view5
LLC

2. 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

3. 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.

4. 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.

5. 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

6. 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

7. 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

8. SOFTWARE
MODELING

9. 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.

10. 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

11. 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

12. 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).

13. UML
Package
Merge
(merged
package)
(receiving
package)
(resul3ng
package)
NOTE:
Research
Paper
–
“Modeling
UML
2
Package
Merge
with
Alloy”

14. 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

15. UML
Profile
Standard
examples
Source
OMG
:
hop://www.omg.org/spec/

16. 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

17. Integra3ng
UML
Profiles
• Since
UML
Profile
is
represented
as
a
package
with
stereotype
«profile»,
package
merge
can
also
be
applied
(in
theory).

18. ENTERPRISE
ARCHITECTURE
DoDAF
RM-­‐ODP

19. Reference
Model
for
Open
Distributed
Processing
• RM-­‐ODP
defines
founda3onal
concepts,
viewpoint
languages,
correspondences
etc.

20. RM-­‐ODP
Meta-­‐Model
NOTE:
Par3al
diagram
from
standard’s
working
model

21. RM-­‐ODP
Profile
NOTE:
Par3al
profile
data

22. EXAMPLE
NEW
TECHNOLOGIES
Social
Networking
NoSQL

23. 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

24. 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

25. Mobile
&
Cloud
extensions
i.e.
all
other
concepts
are
s3ll
available
for
mobile
and
cloud
system
specifica3ons.
Par3al
enterprise
language
means
e.g.

26. 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

27. Social
Network
extension
means
e.g.
Par3al
enterprise
language

28. UML
Profile
Integra3on
• Mobile
and
Cloud
– By
modifying
exis3ng
UML
Profile
for
RM-­‐ODP

29. 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.

30. Sample
Diagram
Fragment
Enterprise
Viewpoint

31. Sample
Diagram
Fragment
Informa3on
Viewpoint
«merge»
Cloud-­‐aware
and
social-­‐aware
object
types
can
be
added
to
exis3ng
informa3on
model.

32. Sample
Diagram
Fragment
Computa3onal
Viewpoint
Mobile-­‐aware
objects
and
cloud-­‐aware
object
can
be
added
to
exis3ng
model
(needs
re-­‐wiring
etc.)

33. Sample
Diagram
Fragment
Engineering
Viewpoint
Cloud-­‐aware
channel
can
be
introduced
to
exis3ng
engineering
model.

34. Sample
Diagram
Fragment
Technology
Viewpoint
Mobile
Object/
Phone
can
be
added
to
exis3ng
model

35. 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).

36. 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).

37. 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

38. 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.

39. 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.

40. 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.