University POLITEHNICA of Bucharest

Information Management and Security Master

OMGS MODEL-DRIVEN ARCHITECTURE (MDA)

INTEGRATED DEFINITION LANGUAGE (IDEF)

Students: Coordinator:
Anghel George Dr. Eng. Moisescu Mihnea
Bratu Marian
Popa Bogdan
 2

OMGs Model-Driven Architecture (MDA)

 3

Introduction
Historicallysoftware design and
development efforts face numerous
challenges, beginning from the early
stages of requirements gathering and
continuing on through the entire
Software Development Life Cycle.

Model-Driven Architecture is a
major initiative by the OMG(Object
Management Group).
 4

Who?
The OMG is an international, open membership, not-for-profit consortium,
founded in 1989.

OMG standards are driven by academic institurion, vendors, end-users and

government agencies.

The mission of the OMG is to develop technology standards that provide real-
world value for thousands of vertical industries.(1)
 5

When?

In 2001 the OMG adopted the Model Driven Architecture as an approach for
using models in software development. (2)

1989: OMG 1995: 1997: 2003:

was founded CORBA 2 UML 1 UML 2

1990: 1996: 2001:

CORBA 1 Vertical MDA
specs
 6

Why?
There will not be consensus on hardware platforms
There will not be consensus on operating systems
There will not be consensus on network protocols
There will not be consensus on programming languages

There must be consensus on interfaces

and interoperability: BASED ON MODELS
 7

Why?

OMG(Object Management Group) was formed as a standards

organisation to help reduce complexity, lower costs and hasten the
introduction of new software applications. OMG is accomplishing this
goal by MDA.(2)

The MDA will help you integrate the mix you have today, and give you
an architecture to support the unexpected
 8

Utility

One fundamental aspect of MDA is its

ability to address the complete
development lifecycle, covering
analysis and design, programming,
testing, component assembly as well
as deployment and maintenance.(2)

As illustrated in the diagram, MDA

encompass a full range of services.
 9

OMGs modelling standards

It builds upon the Object Management Groups modelling standards

the Unified Modeling Language(UML)

the Meta Object Facility(MOF)
the Common Warehouse Meta-model(CWM)
 10

Layers

MDA comprises three

abstraction levels with
mappings between them:(3)

Computation Independent
Model (CIM)
The Platform-Independent
Model
Platform-Specific Model
 11

Computation Independent Model

CIM
Computation Independent Model modelled the requirements for the system.
CIM described the situation in which the system will be used.
The model is called a domain model or a business model.
It hides much or all information about the use of automated data processing
systems.(3)
 12

The Platform-Independent
Model PIM
It is used to describe the operation of a system while hiding the details
necessary for a particular platform
PIM shows that part of the complete specification that does not change from
one platform to another.(3)
 13

Platform-Specific Model PSM

PSM combines the specifications in the PIM with the details that specify how
that system uses a particular type of platform
Platform-specific models are indispensable for the actual implementation of a
system.(3)

Platform-
Independent
Model

CORBA
Model XML/SOAP Other
Java/EJB
Model Model
Model
 14

Specifications: MOF
MDA is about expressing data and process precisely using formal
languages.
How do we keep up with evolving languages or new languages?
How do we transform models from one language to another?
Solution: Meta Object Facility
 15

Example

IDM Course
 16

Case Study: Credit Suisse

Description: worldwide leading provider of financial services

Current architecture: Multi Channel Platform (MCP) => architecture concept

that differentiates application from business layers.

MCP uses facades = are interfaces that offer methods related to a specific
scope of functions within a domain (created manually)

Facades
can be used as services for Java applications,
facilitate reuse of business logic
enable improvement of quality standards

The IT Architecture Professionals

http://www.omg.org/mda/products_success.htm
 17

Case Study: Credit Suisse

The IT Architecture Professionals

http://www.omg.org/mda/products_success.htm
 18

Case Study: Credit Suisse

Objective: reduce the expenses involved with facade development and
automate the process while maintaining the high quality standards by using
MDA and the tool ArcStyler.

ArcStyler :

one of the leading software development tools for MDA.

enables the design, modeling, generation, deployment and management of high-

quality, industrial strength applications of any size for architectures based on
Java/J2EE and .NET as well as custom infrastructures and existing legacy
platforms.

uses cartridges (templates) to generate the application code from UML models for
specific technology platforms => great flexibility
The IT Architecture Professionals
http://www.omg.org/mda/products_success.htm
 19

Case Study: Credit Suisse

Steps:

1. Test if deployment of MDA for MCP was possible and feasible => positive results
2. Explore MCP facade creation in a pilot project named SecureMail.
3. SecureMail had to accomplish two essential tasks:
a) Creation and adaptation of generators to support the model-based and generative
development approach
b) Facade model creation and automatic java source code generation
4. Build cartridge for transforming the PIM to a PSM
5. Build a model2code Java cartridge for generating Java code for the facades
6. Segment the generation procedure into two steps:
a) A model-to-model transformation (M2M) is used to convert the facade model into a detailed
technical model including all classes, attributes, methods and interfaces.
b) Using model-to-code transformation (M2C) this detailed design is converted into Java
source code

The IT Architecture Professionals

http://www.omg.org/mda/products_success.htm
 20

Case Study: Credit Suisse

Benefits:

Greater transparency regarding implementation of requirements in the code enables

significant reduction of project risk and an improved visibility of the project status.

New employees only have to get aquainted with the modeling style, resulting in
reduced project risk and increased flexibility

Faster implementation of changes to the framework.

Efforts during implementation were significantly reduced between 33% to 55%.

Return on Investment (ROI): ROI studies exploring the use of MDA and ArcStyler for
implementing facades have shown that the investment in Model Driven Architecture
and ArcStyler pays off in less than 12 months.

The IT Architecture Professionals

http://www.omg.org/mda/products_success.htm
 21

MDA Benefits
Reduces complexity, development time and cost

Increases stability and lifetime

Provides a smooth integration of emerging technologies

Facilitates reuse of applications, code, training and people

Technology-independent representation of the business

Scalability, robustness & security via generated code

Increased ROI

MDA Model Driven Architecture

by Olivier Riboux
 22

MDA Risks
Model-driven tools issues:
Magnify the mistakes made in the problem definition
Create an additional semantic level to be maintained
Distort the image of what the program is really like
Complicate the maintenance process by creating redundant descriptions which have
to be maintained in parallel

Production and testing is a multi step process with CASE, first you do the design,
then the program generation, then the compilation, then a link edit, and then you
test. If an error occurs, it occurs in the program and not in the design. To correct it,
you have to start over again from the top
(Adam Rin - leading analyst on application development strategies)

The Drawbacks of Model driven Software

Evolution contribution by Harry Sneed
 23

Modeling architecture
comparison
MBE: programmers manually write the code (no automatic code-generation
involved and no explicit definition of any platform-specific model)

MDE: encompasses other model-

based tasks, such as the model-
based evolution the system or the
model-driven revers engineering of
a legacy system

MDD: the implementation is

(semi)automatically generated from
the models

MDA: particular vision of MDD that

relies on the use of OMG standards

Clarifying concepts: MBE vs MDE vs MDD vs

MDA http://sumo.ly/ETiM via @softmodeling
 24

Conclusions
If a UML design can really replace the programming code then it becomes just another
programming language.

The issue is whether it is easier to change the design documents or the programming
language

This depends on the nature of the problem and the people trying to solve it.
If they are more comfortable with diagrams, they can use diagrams.
If they are more comfortable with text, they should write text.

Diagrams are not always the best means of modelling a solution.

A solution can also be described in words.

Important: one model is enough either the code or the diagrams.

They should be reproducible from one another.

The Drawbacks of Model driven Software

Evolution contribution by Harry Sneed
 25

Integrated Definition Language (IDEF)

 26

Introduction

Who? When? IDEF was initiated in the 1970s at the US Air Force Materials
Laboratory. It originally stood for ICAM Definition (Integrated Computer-Aided
Manufacturing), and was later renamed (1999) as Integration DEFinition

Why? The goal of newly developed IDEF techniques is to enable experts to

comprehend problems from different views and levels of abstraction.
 27

Utility
IDEF is used in several areas such as Business Process Engineering (BPE) and
Reengineering (BPR), software process definition and improvement, and even in the
software development and maintenance arenas.

BPE and BPR are active and dynamic fields where organizations are trying to stay
competitive by increasing quality and improving productivity. This is done by
understanding current processes in order to improve them.

The Air Force Software Technology Support Center's (STSC) is using IDEF0 in
operational settings and support services.

The IDEF methodology can be employed in training as well as in operational settings.

The STSC uses IDEF0 in a variety of workshops that provide basic IDEF0 modeling
skills.

The IDEF Process Modeling Methodology, Robert P. Hanrahan,

Software Technology Support Center
 28

Utility

The IDEF Process Modeling Methodology, Robert P. Hanrahan,

Software Technology Support Center
 29

Utility
The IDEF languages have been developed to answer three main
requirements in business modelling:
capture what is known about the real world and the relationships
between people, events, etc.
capture existing and future information management requirements
supporting methods for design of systems answering the needs
previously identified

*IDEF3 and IDEF5 address the first of these needs

*IDEF0 and IDEF1 answer the second need
*IDEF1X, IDEF2 and IDEF4 were aimed at satisfying the third need

The IDEF Process Modeling Methodology, Robert P. Hanrahan,

Software Technology Support Center
 30

IDEF Weaknesses

There is a tendency of IDEF models to be interpreted as representing a

sequence of activities, even though it is not intended to be used for modeling
activity sequences.

In cases where activity sequences are not included in the model, readers of
the model may be tempted to add such an interpretation.

The abstraction away from timing, sequencing, and decision logic allows
concision in an IDEF model. However, such abstraction also contributes to
comprehension difficulties among readers outside the domain.

Strengths and Weaknesses of IDEF

http://www.idef.com/idefo-function_modeling_method/
 31

IDEF Weaknesses

IDEF0 models separate functions from organizations, but do not support the
specification of a process, nor capture time-ordered constraints between
activities

IDEF1 cannot be directly used in the implementation phase.

IDEF1X is a good tool for the basis of database design, but does not follow
the rules of good graphical design its symbols do not cleanly map o the
concepts they are supposed to model

Strengths and Weaknesses of IDEF

http://www.idef.com/idefo-function_modeling_method/
 32

Example - IDEF0

The IDEF Process Modeling Methodology, Robert P. Hanrahan,

Software Technology Support Center
 33

Example - IDEF1

The IDEF Process Modeling Methodology, Robert P. Hanrahan,

Software Technology Support Center
 34

Example - IDEF1X

The IDEF Process Modeling Methodology, Robert P. Hanrahan,

Software Technology Support Center
 35

Example - IDEF3

The IDEF Process Modeling Methodology, Robert P. Hanrahan,

Software Technology Support Center
 36

IDEF vs UML - Comparison

Both IDEF and UML approaches may be used to model almost any useful view of a
business.

IDEF language family has around 30 years of development and a few US governmental
bodies behind it, and UML is a 'young' modelling language compared to IDEF, aimed
mostly towards software development.

UML can only be effectively used when complemented by design patterns and specific
extensions that allow to effectively capture de business processes

Strong software support there exists, which integrates IDEF methods, and enables
connection of IDEF methods with other tools, such as software for simulation of
business processes, or software for activity based management of costs

The IDEF Process Modeling Methodology, Robert P. Hanrahan,

Software Technology Support Center
 37

Conclusions
One notation is insufficient to adequately describe the views, in terms of activities, data,
controls, and sequencing, required to adequately define a process.

The suite of IDEF notations has developed into a methodology designed to provide the
multitude of viewpoints required to adequately describe business area processes and
software lifecycle processes and activities.

For business process modelers, the IDEF methodology offers a well-defined and
rigorous approach to capture and understand the organization's operations and its
information architecture. This provides a foundation for process reengineering and
process improvement.

It is safe to say that the IDEF process modeling method is useful as a complementary
view of the process(es) and dimensions of the software development lifecycle activities
being employed

The IDEF Process Modeling Methodology, Robert P. Hanrahan,

Software Technology Support Center
 38

References
1. http://www.omg.org/mda/

2.Frank Truyen,The Basics of Model Driven Architecture,

http://lsi.ugr.es/~mcapel/docencia/TAMSCT/Cephas_MDA_Fast_Guide.pdf
3.Mark Lankhorst, Enterprise Architecture at Work

Clarifying concepts: MBE vs MDE vs MDD vs MDA https://modeling-languages.com/clarifying-concepts-mbe-vs-

mde-vs-mdd-vs-mda/

MDA Model Driven Architecture, Olivier Riboux

Model Driven Architecture, Fred Waskiewicz

IDM Course

The IDEF Process Modeling Methodology,

http://www.sba.oakland.edu/faculty/mathieson/mis524/resources/readings/idef/idef.html

Integrated DEFinition Methods (IDEF) http://www.idef.com/idefo-function_modeling_method/