ABSE and AtomWeaver

A Quantum Leap in Software Development

PART I

About Software Development

A critical look into software development

Software, Everywhere

From wrist watches to the Space Shuttle,

software is everywhere

Every day, millions of lines of code are written

by thousands of software developers around the world

Our society becomes more dependent on software

every passing day
Increasing Software Complexity

Every system, every application, in every version,

in any domain, gets more complex at each iteraction

Evolution in lines of code on typical systems

70's 90's 2010

Cell Phone - 100.000 10.000.000

High-End Car 100.000 1.000.000 100.000.000

(GM/IBM Estimates)

Word Processor - 78.000 2.000.000+

(Word 4.0 DOS)

Operating System 10.000 4.500.000 50.000.000+

(Unix v1) (Windows NT 3.1) (Windows Vista)
Increasing Software Demand

Demand for software is skyrocketing

More and more “traditional” tasks are being

assisted or replaced by software

Today, most consumer devices have some sort

of software running inside. A growing trend.

Disposable computing is not far away...

Increasing Challenges

Software makers need to address the evolution in:

- Compliance regulations (HL7, Sarbanes-Oxley, HIPPA)

- Multi-core & Multi-threading

- Development paradigms (SOA, Web 2.0, SaaS, cloud computing)

And at the same time face:

- Decreasing time-to-market

- Decreasing budgets
Software development
is an
ever-growing
challenge...

What
have we done
so far
to address this?
The “Software Crisis”

“The major cause of the software crisis

is that the machines have become
several orders of magnitude more
powerful! To put it quite bluntly: as long
as there were no machines,
programming was no problem at all;
when we had a few weak computers,
programming became a mild problem,
and now we have gigantic computers,
programming has become an equally
gigantic problem.”

Edsger Dijkstra, 1972

This was written almost four decades ago,

but looks as it could have been written today.
The “Software Crisis”
Consecutive revolutions are being achieved in many domains
thanks to computer software.

Increasing Increasing Increasing

Demand Complexity Challenges

Software Crisis

Same Same Same

Workforce Methods Tools

However, software engineering is not seeing the same evolution

rate as in the domains it addresses.
Problem : Slow tool evolution

In the seventies,
people developed software line-by-line, file-by-file

Four decades later,

most people still develop software line-by-line, file-by-file

While there has been some evolution in development methods

and tools, most are essentially based on flat source files.
Problem : Same old methods

Waterfall
First described in 1970, is still the most widespread development organizational method.
“The waterfall model is argued by many to be a bad idea in practice, mainly because of their belief that it is impossible,
for any non-trivial project, to get one phase of a software product's lifecycle perfected before moving on to the next
phases and learning from them.”

http://en.wikipedia.org/wiki/Waterfall_model

One-Off Development
Every developed application is unique, started from scratch

“The assumption of one-off development is so deeply ingrained in this industry that most of us are not conscious of either
the practice or the alternatives. Even XP* and UP** assume that every product will be designed and developed
independently from first principles to accommodate its unique requirements, and neither of them provides guidance for
supplying or consuming reusable assets.”

Jack Greenfield, Keith Short – Software Factories

*XP = Extreme Programming

**UP = Unified Process
Problem : Feature Traceability
The traceability problem occurs when the solution features that implement a problem
feature cannot be easily identified.

This makes it hard to identify all of the things that need to change in the
implementation, and to ensure that all of the changes are made consistently, when
the requirements change.

Failing to trace all elements

that belong to a given feature Which
leads to bugs, inconsistencies,
? Data
and excess time. Feature

It's a (too) common scenario.

Source
Specification
Code
Failed Promises

In the recent past, several “promises” have emerged,

claiming to be the silver bullet to the software crisis.

But many have failed, or simply did not deliver.

Let us have a look into the most important ones:

(Quoting the opinion of others)
#1 : UML – Unified Modeling Language

“UML is applying an abstraction at the wrong end of the problem. It is

primarily used to sketch object models for inferior languages. As such,
it tends to explode into incomprehensible patterns of accidental
complexity in order to accommodate the various “design patterns”
that are used work around the lack of essential language features.

Because the UML models cannot be compiled, executed, or

interpreted, they are reduced to the level of mere documentation. As
such, it is generally not even worth keeping in sync– the manual
round trip from the code to the model and back is just too expensive
for something that adds no more value to a project than an elaborate
code comment.”
From lispy.wordpress.com

“UML has become complex and clumsy. For 80% of all software only 20% of UML
is needed. However, it is not easy to find the subset of UML which we would call
the Essential UML”.
Ivar Jacobson, Co-Inventor of UML, June 2009
#2 : MDA – Model-Driven Architecture

“At its most basic, MDA involves transforming one UML model into another UML model, possibly
several times and possibly automatically [...]. The MDA approach leads to the same results as
wizards: lots of code (and models) that you didn’t write yourself but that you are expected to
maintain. The MDA idea gets even worse when you consider round-tripping—would you like to
update the manually made changes to the code and lower level models back to all the higher-level
models?”
Kelly / Tolvanen – Metacase

“MDA is limited to the effectiveness of the UML as a language for model driven development,
a task it was not designed to support.”
Jack Greenfield - Microsoft

“Unfortunately, early enthusiasm for Model Driven Architecture (MDA) has dissipated to the
point that many people are openly skeptical of the value of any model-driven approach.”
From “MDA Redux”, by Alan Brown, published by IEEE Computer Society
#3 : DSLs - Domain-Specific Languages

“[...] the Tower Of Babel* effect that results from having so many languages that a person needs to
be familiar with (if not master) in order to get common jobs done.”

“... nothing is better than having your own Little Language to do a specific job. It allows for concise
expression of solutions to specific problems. But a problem arises when The Next Guy comes along
and has to learn the concepts behind the language, the motivations for particular elements of it,
the syntax, etc.”

“Writing a decent DSL is hard. Very limited, very simple DSL's can be adequately produced by a
competent programmer with expertise in the problem domain - DSL's that can be described on a
page or two, and are tailored to a specific application/environment. These language are seldom
usable outside the very limited context.”

“But writing a good DSL that is robust and reusable beyond a limited context, is a lot of work. It
requires persons with both domain expertise and language design expertise (not necessarily the
same person) to pull off. A truly reusable DSL will require reasonable documentation, otherwise it
won't survive the departure of its designers. And, it will eventually require a good set of tools -
debugging environments and the like - for it to become worthwhile.”

Taken from http://c2.com/cgi/wiki?DomainSpecificLanguage * http://c2.com/cgi/wiki?TowerOfBabel

Gaining Momentum : MDSD and DSM
Unlike MDA, MDSD (Model-Driven Software Development) and
DSM (Domain-Specific Modeling) follow a more pragmatic, less
formal approach to software modeling. That makes these
approaches more accessible to the mere developer.

“Forrester expects model-driven development (MDD) to play a key role in the future of software
development; it is a promising technique for helping application development managers address
growing business complexity and demand.”
Diego Lo Giudice – Forrester Research

Domain-Specific Modeling raises the level of abstraction

beyond programming by specifying the solution directly using
domain concepts. The final products are generated
from these high-level specifications, because both the model
and generators fit the requirements of only one company and
domain. Your experts define them, your developers use them.
PART II

ABSE - Overview

How can ABSE address today's software development problems

Quick Facts

ABSE

- Stands for “Atom-Based Software Engineering”

- Is a generative approach (generates code from models) to

MDSD (Model-Driven Software Development) and DSM (Domain-
Specific Modeling)

- Relies on tree-based models

AtomWeaver

- Is a cross-platform Integrated Development Environment (IDE)

- Implements and extends ABSE

The ABSE Tree

A software engineering project is made up of “Atoms”, organized

as a tree. That tree is the Project Model.

A tree conveys association, mimicking

the associative human brain, therefore
being able to represent and decompose
any problem or data structure.

The tree is ABSE's supporting paradigm,

allowing the model to “think” like us.

< A partial view of AtomWeaver's ABSE model

Models in ABSE

An ABSE model, like in other MDSD methodologies, is abstracted

at multiple levels:

Atom ABSE's single meta-metamodel

1

*
Atom Template Metamodels
1

*
Atom Instance Models
1

*
Text / Data Generated artifacts
Atom Types

There are only three types of Atoms:

Atom Template → The metamodels (building blocks) of any ABSE model

Atom Instance → The actual models that make up a project model

Atom Organizer → Organizes library contents into meaningful structures

Atom Libraries

An Atom Library contains Atom Templates, possibly structured in a

meaningful way through Atom Organizers.

Any ABSE model must be built from

one or more libraries as it can
only contain Atom Instances. Root Lib

Language Lib
Solution
Domain
Libraries can use or extend Platform Lib
other libraries.

Domain Lib

We can raise the abstraction Problem

Domain
level everytime we extend
Domain
a library. Components
Lib
Atom Libraries

The Atom Libraries are the driving force behind ABSE.

A good library can help you save many development hours,

and even more test hours.

The vision behind Software Product Lines (SPL) is that once the
company's domain is converted into models, they can be
reused and combined to create similar, but different, systems.

ABSE and its libraries help SPL's become a reality.

Libraries can be exchanged between systems through

ALX (AtomWeaver Library Exchange) files.
ABSE is Universal

It can support and combine all forms of software engineering,

including:

●
Traditional file-oriented methods Root Lib

Literate Programming

Higher Abstraction
●
Language Lib

●
Aspect-Oriented Programming
Platform Lib

●
Component-Based Development

● Feature-Driven Development Domain Lib

●
Domain-Specific Modeling

● Software Product Lines Domain

Components
● Software Factories Lib
ABSE is Universal

This is possible because ABSE...

●
… is not targeted to a specific language, architecture, or platform

●
… allows generation of any kind of text or data

● … has a very flexible meta-metamodel

●
… uses association as its paradigm, the basis of human thinking
ABSE is Domain-Agnostic

ABSE can be applied to virtually any domain.

Internet

Horizontal (solution domain) libraries can be

extended with vertical (problem domain)
Healthcare
libraries to achieve reductions in time-to-
market and savings on development and
testing efforts.

Science

Atoms can represent and generate code for

specific aspects of the target domain.

Embedded Devices

Aerospace Enterprise Defense Systems Automotive Entertainment Engineering

 ABSE is Language-Independent

Being largely based on text generation,

ABSE can generate all kinds of textual
output, from plain text files to complete
software systems.

A single ABSE project can target multiple

languages and file types.

FortranHaskellEiffelC#PhytonSQLJavaABAPErlangScalaSmalltalkVHDLPrologC++
AdaPascalPHPLispRubyJavaScriptDelphiSASCOBOLCamlTclDVisualBasicCGroovyML
ABSE is Refactorable
Line-Oriented

ABSE metamodels can evolve with your skill.

Objects

You can start doing just some text

transformation, grow up by refactoring Patterns
Metamodels into common patterns.

You can continue right up to full Components

Domain-Specific Modeling and
Software Product Lines.

Each time you derive an Atom Template into Domain-Specific

another Template, you increase the

abstraction level.
Software Factory
ABSE is Easy

You don't need to be a rocket scientist to apply in an effective way.

ABSE is accessible to the "mere developer mortal".

An ABSE project is like a large mechanism

that can built from smaller, pre-built or
custom parts.

The ABSE approach is more pragmatic and simpler than other

DSL/model-driven tools or technologies like oAW, OMG's
MDA/MOF/XMI, Eclipse EMF/GMF, Microsoft OSLO/M, Xtext.
ABSE is Complete
source_file.h

ABSE meta-metamodel
designed to support 100% atom_concept_a Generated code

code generation from the

model. Custom
code
Generated

Model Transformation
code

Generated code

No round-trip necessary. Custom

code
Custom code

The mix of custom and source_file.cpp

generated code is directly atom_concept_b
supported by the meta- Custom
code
metamodel. Generated
code

Custom Custom code

code
No worries about
Generated code
overwritten custom code, Generated code
no management issues.
ABSE is Manageable

An ABSE model can grow to

generate multi-million line
applications, and still be easy
to manage.

That's because ABSE is based on

a tree and not on a graph:

Tree branches easily encapsulate

other branches.

A complex application using a graph

ABSE is Comprehensive
The complete ALM (Application Lifecycle Management)
cycle can be supported.

An ABSE tree is not exclusive to software implementation:

it can also represent processes, documentation, SCM, etc.

Documentation Project Bugs & Support

ABSE is Collaborative

Due to its granular nature,

an ABSE model can be Instance A

concurrently manipulated. Instance B

Two or more developers can
work on the same ABSE model. Instance C

Instance D

Instance E
And through a supporting tool
(like AtomWeaver), workflows Instance F

can be applied. Individual atoms Instance G

or tree branches can be

checked-in or out, versioned and
conditionally enabled/disabled.
PART III

ABSE in the Enterprise

How can ABSE improve software engineering

ABSE Can Bridge All Stakeholders

By making available the appropriate Templates to each stakeholder,

domain experts, designers, developers and testers can work
together on the same ABSE model.

● Domain experts can specify

●
Designers can design & re-arrange
●
Developers can build
● Testers can debug & test
ABSE Captures & Shares Knowledge

The company's domain knowledge and the team's development

knowledge can be captured into ABSE metamodels.

Benefits:

- Individual expertise can be shared with the whole team

- Less skilled developers can work like the experts

- Architectural uniformity can be achieved

- Best practices are easily disseminated and enforced

ABSE Increases Productivity

Some tasks under manual coding simply cannot scale:

- Repetitive patterns
- Repetitive coding
- Repetitive changes
- Interfacing code/specification
- Unit test preparation
- Debug/log/trace code

These and many other boring and error-prone tasks can

be reduced or even completely eliminated by using a
model-driven approach like ABSE.
ABSE Increases Productivity

The team's productivity potential increases whenever it adds

another metamodel (Atom Template) to the ABSE library.
Working on a higher abstraction level boosts your productivity.

Each time an ABSE metamodel is instantiated, time is saved.

Each time an ABSE metamodel is extended, more time is saved.

ABSE Increases Quality of Code

It is known that more time is spent debugging

code than actually writing it.

The code produced by the ABSE metamodels

can (and should) be tried and tested code.

By reducing the amount of custom code used

in the model, overall code quality increases.
Critical Innovation : Software Reuse

Systematic software reuse is a promising means to reduce

development cycle time and cost, improve software quality, and
leverage existing effort by constructing and applying multi-use
assets like architectures, patterns, components, and
frameworks.

“To realize a return on the investments we make in developing the solutions, we must reuse them
enough to more than recover the cost of their development, either directly through cost reductions,
or indirectly, through time to market reductions and quality improvements.”
Jack Greenfield et al - “Software Factories”
ABSE Promotes Reuse
The most common type of reuse is the reuse of software components, but
other artifacts produced during the software development process can also
be reused: system architectures, analysis models, design models, design
patterns, database schemas, web services, etc.

ABSE's meta-metamodel allows Atom Templates to be aggregators,

so you can turn any part of your project into a new template for
future reuse.

Instance A Template 1 Instance D

Instance B Instance A Instance 1

Instance C Instance B Instance E

“Templatization” Reuse
Instance C Instance F

Project A Library A Project B

In the same way, ABSE lets you turn recurring patterns into
templates, reducing project complexity and maintenance costs.
ABSE Reduces Maintenance Costs
With ABSE you'll have
less code to maintain.
Traditional Approach ABSE Approach
That's because you
only have to maintain Manual Code
one instance of your
code. All other
instances of that code
are automatically Manual Code

Codebase Size
updated.
Generated
And since manual code Manual Code Code

is natively supported,
Manual Code
there's no need to Generated
Code
waste time maintaining
protected regions,
code guards and other
trickery, just to Atom Library
maintain the integrity Atom Library

between manual and

generated code.
PART IV

ABSE - Technical Overview

A closer look into ABSE and how it works

The Atom (ABSE's Meta-metamodel)

The Atom can be root_default An Atom can also

instantiated into be compared to an
Atom Templates. object in an object-
oriented
programming
Base Template language.
Atom Templates
derive from other
templates.

Atom Template Instantiation Atom Instance

All Atom Templates Composition
derive from Admin Parameters Variables
root_default, the Creation
only pre-existing Form Functions
Condition
Atom Template in Transformation
Custom Areas Custom Code
ABSE. Code

Relocation

Atom Templates can

be instantiated into Derived Template
Atom Instances.
The Atom Admin Section
Atom Template
The Admin Section of an Atom
Template determines how its instances Admin Parameters
are presented and how they behave
Form Functions
on the Model Tree.
Transformation
Custom Areas
Code

On the Admin Section you can define:

- Icon and Label to be shown on the model

- Construction constraints
- Atom parameters
- Other discovery and construction helpers

The Admin Section also inherits from its base templates.

The Atom Form Section
Atom Template
Each Atom Template has a dedicated
Editor. Admin Parameters

Form Functions

Transformation
Custom Areas
Code

The Form Section lets you define how

the editor presents the Atom Template
Parameters and how you can set the
corresponding Instance Variables.

The Form Section also inherits from its base templates.

The Atom Functions Section
(and Behaviors)
Atom Template
This section lets you define extra atom Admin Parameters
Functions.
Form Functions

Transformation
Custom Areas
The most common use is to define Code

Atom Behaviors.

An Atom Behavior is a powerful generalization technique: It allows

the atom to respond to a specific, globally-defined query.

Any atom can request processing from another atom without

actually knowing its type, allowing unlimited future extensions.
The Atom Transformation Code

The transformation code allows any Atom Template

atom to perform actions based on its
input parameters. Admin Parameters

Form Functions
Most common task is to generate
Transformation
code, but other tasks like modifying Code
Custom Areas
other atoms and OS calls are also
possible.

The Atom's transformation code is

segmented into the following steps:

Create Pre Exec Post

Code Code Code Code
The Atom's Custom Code

To support 100% code generation from Atom Template

the model, and to avoid synchronization
Admin Parameters
problems between generated and
custom code, ABSE allows you to define Form Functions
one or more custom code areas on an
Transformation
Atom Instance. Code
Custom Areas

java_function source_file.java

int Function()
parameter {
generated code;
generated code;
parameter

custom_code custom_code

generated code;
}
The Instance's Creation Condition
Atom Instance
The inclusion of each Atom Instance Variables
on the project can be subject to an
Creation
expression that dictates whether that Condition
Atom is executed or not.
Custom Code

If the evaluated condition is false, the Relocation

Atom becomes invisible to the project.

This brings more flexibility to the

generation process and allows templates
to include/exclude some of their auto-
generated atoms based on user-supplied
values.
Instance Relocation

Atom Instances that are auto-generated by Atom Instance

an Atom Template can then be relocated to
Variables
another position on the model tree.
Creation
Condition
The relocated atom may be again moved
Custom Code
by the user, if it is not blocked.
Relocation

For instance, user interface programmers may create atoms that

will automatically create the interface visual elements's atoms.

Designers can then manipulate and edit those atoms to achieve

the desired application visuals.
ABSE Strength #1 : Inheritance

Like classes in several programming

languages, Atom Templates can be
derived into more complex and root_default
specialized Templates.

cpp_class

This allows you to

build metamodels
that share common
concepts. gui_dialog ext_data_object

db_persistent_object
The derived template will inherit all
properties and code from its base template.
ABSE Strength #2 : Composition

Atoms can be combined to build larger structures.

Atom Instances are combined to build the Project Model.

Atom Templates can be composed of several other Templates which,

on their turn, can also be composed of other Templates.

From Wikipedia: ext_powered_class

http://en.wikipedia.org/wiki/Obje
ct_composition

Composited (composed) objects are

often referred to as having a "has a" cpp_member cpp_method
relationship. A real-world example of
composition may be seen in an
automobile: the objects wheel, cpp_member cpp_argument
steering wheel, seat, gearbox and
engine may have no functionality by
themselves, but an object called cpp_return_value
automobile containing all of those
objects would serve a higher
function, greater than the sum of its
parts.
Inheritance & Composition Combined
You can see here how a metamodel of Actual metamodels from AtomWeaver project

a C++ class, composed of two Atom

Instances, is derived into an
“extended class” with added
features. Then a C++ Component
metamodel is defined by
inheriting Extended Class
and adding data and
configuration
features...
Inheritance & Composition Combined

Then a Persistent
Component
metamodel was
created by inheriting
a C++ Component
model and adding
specific DB features.

The same was done

to create a Database
Document
metamodel.
Inheritance & Composition Combined

You can implicitly generate dozens

or even hundreds of atoms just by
adding a single atom instance to
the project.

If each of those atoms generates

just a few lines of code...

Imagine how much code that can

be generated at once!

Now imagine that the generated

code is mature, tested, quality
code...
Atom Templates = Software Components

ABSE lets you build applications like Lego . A simple, yet effective
tm

constraint system drives you on the component discovery and

construction process.

Metamodels Constraints Correct Models

+ =
ABSE is an Executable Model

Every Atom on the ABSE Tree has its own transformation code
(acquired from its template).

To generate code, the Model Tree

recursively executes its atoms,
Execution Sequence
which is equivalent to say that all
atoms are executed from top to
bottom.

The tree is executed four times,

and on each iteraction one of the
following Atom Template sections
is executed:

Create Pre Exec Post

Code Code Code Code
Variable Transmission

Atom cpp_class
Defines: class_name, Variables are set on Atom
inheritance
Can access: ... Instances, and each variable
corresponds to an Atom
Template parameter.
Atom cpp_function
Defines: func_name
Can access: class_name,
inheritance Any variable from an Atom
is automatically available to
Atom cpp_argument all branch children.
Defines: arg_name,
arg_type
Can access: class_name,
Inheritance, func_name
This way, any Atom can
work “in context” with its
Atom cpp_member
ancestors.
Defines: member_name,
member_type
Can access: class_name,
inheritance
PART V

AtomWeaver

An ABSE Integrated Development Environment

AtomWeaver is an ABSE Model

AtomWeaver is being developed through an ABSE Model.

AtomWeaver is ABSE's proof-of-concept, showing that a

fairly sophisticated application can be easily built using a
model-driven approach like ABSE.

Some statistics:
(Current version of AtomWeaver Prototype)

- 38000 Total Atoms

- 7800 User-Created Atoms
- 30200 Auto-Generated Atoms

- 334 Atom Templates in Library

- 2456 Atom Instances in Model

- 174756 Lines of Generated (+ Manual) Code

- 701 Generated Files
Introducing AtomWeaver

AtomWeaver implements and extends ABSE

into a complete, agile, dynamic IDE.

AtomWeaver prototype – AtomWeaver's own ABSE model loaded

Introducing AtomWeaver

Due to ABSE's genericity,

AtomWeaver works on any
development environment,
Integrated with any tool chain

AtomWeaver is presently the market's only plug-and-play MDSD system

No other present system lets you start creating models in a few minutes
AtomWeaver : The Universal Generator
Besides pure programming,
the modern software vendor
faces a long list of other
peripheral, but equally
important activities:
- Requirement management
- Research
- Change management
- Building
- Testing
- Version control
- Issue management
- Internal/customer reporting
- End-user documentation
- Code revisions
- Installer packaging
- Application resources
- Databases
- ...
Why use separate tools?
AtomWeaver can be the central
point of all development activities.
Using AtomWeaver's modeling and
generation capabilities, it's
surprisingly easy to:
- Build your own bug tracker
- Implement code coverage
- Automate documentation
- Build synch'ed intranets/websites
- Create configurations/build files
- Package resources
- Automatically build tests
- Embed debug/trace code
- Refactor features/architecture
AtomWeaver Modules

AtomWeaver is composed of several mandatory and optional

modules. Each module contains a different aspect of the project.

Library, Model, Files and Log are the mandatory modules. All
others are optional.

Future AtomWeaver versions will allow the creation of other,

custom-defined modules through its API.
AtomWeaver Modules

Documentation → For development support documentation, drafts, etc.

Library → Contains all libraries loaded into the project

Model → Holds the project's main model

Files → Lists and manages all generated artifacts

Issues → Manages SCM operations (bug tracking as the most common)

Help → Builds and concentrates all end-user documentation

Log → Registers all that is happening in AtomWeaver

AtomWeaver's Model Transformation DSL: Lua

Instead of using an exotic, custom DSL, AtomWeaver uses Lua to

transform ABSE models into final source code.

Lua is a lightweight, reflective, imperative and functional

programming language, designed to be a scripting language.

Several benchmarks show Lua as the fastest interpreted scripting

language available.

This is specially important to code generation where millions of

lines of transformation code are typically needed on a large project.
AtomWeaver Extends ABSE

AtomWeaver adds tools and commands to ABSE's basic featureset

to improve the developer's experience and productivity, including :

●
Atom Dictionary : Lets you reference any project Atom by
its associated name.

●
Atom Lists : Lets you categorize atoms and build lists according
to your pre-defined criteria.

● Counters : Lets you use unique values project-wide.

AtomWeaver editions

Two editions of AtomWeaver are planned:

Solo Edition Team Edition

For: For:

- Individuals - Collaborative projects

- MicroISVs - SME's
- Small projects - Large corporations
- Isolated generation tasks - Research institutes
AtomWeaver 1.0 feature matrix

Feature Solo Edition Team Edition

Code Generator, Interpreter, Rules Engine X X

IDE X X

Library Repository X X

File-based Database Storage (SQLite) X

Server-based Database Storage (MS SQL Server) X

ALM (Application LifeCycle Management) Support X X

Model Versioning X

Developer Roles X

Concurrent Model Edition X

Workflows & Tasks X

AtomWeaver estimated prices

Solo Edition Team Edition

USD $499 USD $999

Regular Regular, Per Seat

USD $199 USD $499

Early Adopter Campaign Early Adopter Campaign
Per Seat

Prices not definitive, subject to change

Optional support and/or maintenance not included
AtomWeaver's next major features

The following major features are planned

for versions 2 & 3 of AtomWeaver

Flexible Diagramming Generic GUI Mockups Scripting API

Any kind of diagram can be
created, following rules
defined in Atom Templates
and in the Library. Hybrid
diagram/tree development
will be possible.
Mockups for any system will
be possible using ABSE's
generic constraint system.
Programmers can program
while designers can design
and rearrange.
AtomWeaver will be
scriptable, opening the door
to user-defined ABSE
models, extensions, custom
actions on atoms, and third-
party add-ons.
The Library Exchange

AtomWeaver will have its dedicated Library Exchange site that

will concentrate all publicly available Atom Libraries:

- Free Libraries
- Commercial Libraries

These libraries can be supplied by:

- Individual users
- Commercial vendors
- Isomeris

By using ready-made libraries, you save time and get quality

code and models from the domain experts.
Team Edition Feature:
Concurrent Model Edition

The project is stored on a central database

Developers can load a copy of the project into their workstations

An Atom or a branch can be checked-out for edition. Other users

are denied write access to that atom or branch

After check-in, changes are incorporated into the central database

AtomWeaver regularly checks for new updates and automatically

loads them to the local copy of the project
Team Edition Feature:
Developer Role Management

The structure of a development team is mimicked in the

AtomWeaver environment

Each user must log in to work on a project

The two main roles are Architects and Developers. Other roles
can be created

Each role can have different privileges regarding code access

or changes

Developer roles are also useful for workflows

Team Edition Feature:
Model Versioning

Like in a source control system, atoms can be versioned

Branches/forks can be made

Past project snapshots can be obtained

Atoms can be reverted to a previous version

Different versions of atoms or branches can be diff'ed

Team Edition Feature:
Workflows and Tasks

The development process can be pro-actively managed by

AtomWeaver

All processes are defined by the organization through Atoms,

stored as libraries

Workflows, tasks and memos can be issued.

Activities like testing, change requests, code reviews, etc. can

be implemented

Atoms can be selected & associated to these activities

AtomWeaver release timeline*

Apr.2011 : AtomWeaver Team v1.0 CTP

Dec.2011 : AtomWeaver Team v2.0

2010 2011 2012

Sep.2011 : AtomWeaver Solo v2.0

Sep.2010 : AtomWeaver Solo v1.0 CTP May.2011 : AtomWeaver Solo v3.0

*Timings subject to change

AtomWeaver Competitors

Code Generation is a high-growth market segment: There

are currently dozens of competitors.

However, most of these products are specific to a

given domain, platform, or function.

None of the other existing products today

is able to offer a technological
innovation that can be recognized as
a true software development
breakthrough as
ABSE & AtomWeaver
do.
PART VI

Summary

Summing up ABSE & AtomWeaver

ABSE aims to lead the MDSD movement

MDSD is recognized as the next revolution in the Software

Engineering industry, and is gaining momentum among larger
organizations.

However, complexity in its various implementations prevents it

from gaining mainstream adoption.

ABSE aims to lead MDSD adoption by:

- Defining a very light meta-metamodel

- Having a small set of rules
- Being flexible (can mix custom and generated code)
- Having a reference implementation (AtomWeaver)
AtomWeaver aims to compete with other
high-end IDE's

MS Visual Studio and Eclipse are the major players in the

general-purpose software IDE segment

AtomWeaver can differentiate itself by:

- Its unique development approach (ABSE)

- A high adaptability to very specific industries and domains
- Having lower licensing costs
Reality Check !

ABSE still in its infancy

AtomWeaver is still just a bare-bones IDE

Developer mindset inertia is a respectful opponent

ABSE & AtomWeaver on the Internet

www.twitter.com/atomweaver

community.atomweaver.com

www.abse.info

www.atomweaver.com

www.ruicurado.com
 Thank you for your interest in

ABSE and AtomWeaver

www.isomeris.com