ABSE and AtomWeaver

A Quantum Leap in Software Development

About Software Development

A critical look into software development

PART I

Software, Everywhere

From wrist watches to the Space Shuttle,software is everywhere

Every day, millions of lines of code are writtenby thousands of software developers around the world

Our society becomes more dependent on softwareevery passing day

Increasing Software Complexity

70's 90's 2010Cell Phone - 100.000 10.000.000

High-End Car 100.000 1.000.000 100.000.000(GM/IBM Estimates)

Word Processor - 78.000(Word 4.0 DOS)

2.000.000+

Operating System 10.000(Unix v1)

4.500.000(Windows NT 3.1)

50.000.000+(Windows Vista)

Evolution in lines of code on typical systems

Every system, every application, in every version,in any domain, gets more complex at each iteraction

Increasing Software Demand

Demand for software is skyrocketing

More and more “traditional” tasks are beingassisted or replaced by software

Today, most consumer devices have some sortof software running inside. A growing trend.

Disposable computing is not far away...

Increasing Challenges

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

- Multi-core & Multi-threading

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

Software makers need to address the evolution in:

And at the same time face:

- Decreasing time-to-market

- Decreasing budgets

Software developmentis an

ever-growingchallenge...

Whathave we done

so farto address this?

“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

The “Software Crisis”

This was written almost four decades ago,but looks as it could have been written today.

The “Software Crisis”

Software Crisis

SameWorkforce

IncreasingDemand

IncreasingComplexity

IncreasingChallenges

SameMethods

SameTools

Consecutive revolutions are being achieved in many domainsthanks to computer software.

However, software engineering is not seeing the same evolutionrate 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 methodsand tools, most are essentially based on flat source files.

Problem : Same old methods

WaterfallFirst 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 nextphases and learning from them.”

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

One-Off DevelopmentEvery 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 eitherthe practice or the alternatives. Even XP* and UP** assume that every product will be designed and developedindependently from first principles to accommodate its unique requirements, and neither of them provides guidance forsupplying 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 elementsthat belong to a given featureleads to bugs, inconsistencies,and excess time.

It's a (too) common scenario.

Which

?Feature

Specification SourceCode

Data

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)

Failed Promises

#1 : UML – Unified Modeling Language

“UML has become complex and clumsy. For 80% of all software only 20% of UMLis needed. However, it is not easy to find the subset of UML which we would callthe Essential UML”.Ivar Jacobson, Co-Inventor of UML, June 2009

“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

#2 : MDA – Model-Driven Architecture

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

“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 thepoint 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

Kelly / Tolvanen – Metacase

#3 : DSLs - Domain-Specific Languages

“[...] the Tower Of Babel* effect that results from having so many languages that a person needs tobe 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 conciseexpression of solutions to specific problems. But a problem arises when The Next Guy comes alongand 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

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

Gaining Momentum : MDSD and DSM

Diego Lo Giudice – Forrester Research

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.

Domain-Specific Modeling raises the level of abstraction beyond programming by specifying the solution directly using domain concepts. The final products are generatedfrom 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

- 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

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

- Implements and extends ABSE

ABSE

AtomWeaver

A software engineering project is made up of “Atoms”, organized as a tree. That tree is the Project Model.

The ABSE Tree

< A partial view of AtomWeaver's ABSE model

A tree conveys association, mimickingthe associative human brain, thereforebeing able to represent and decomposeany problem or data structure.

The tree is ABSE's supporting paradigm,allowing the model to “think” like us.

Atom

Atom Template

Atom Instance

ABSE's single meta-metamodel

Metamodels

Models in ABSE

An ABSE model, like in other MDSD methodologies, is abstractedat multiple levels:

1

*

1

Models*

Text / Data Generated artifacts

1

*

Atom Types

There are only three types of Atoms:

Atom Organizer → Organizes library contents into meaningful structures

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

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

Atom Libraries

An Atom Library contains Atom Templates, possibly structured in ameaningful way through Atom Organizers.

Any ABSE model must be built fromone or more libraries as it canonly contain Atom Instances. Root Lib

Language Lib

Platform Lib

Domain Lib

DomainComponents

Lib

Libraries can use or extendother libraries.

ProblemDomain

SolutionDomain

We can raise the abstractionlevel everytime we extenda library.

The Atom Libraries are the driving force behind ABSE.

A good library can help you save many development hours,and even more test hours.

Atom Libraries

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

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

Libraries can be exchanged between systems throughALX (AtomWeaver Library Exchange) files.

ABSE is Universal

It can support and combine all forms of software engineering, including:

● Traditional file-oriented methods● Literate Programming

● Aspect-Oriented Programming

● Component-Based Development

● Feature-Driven Development● Domain-Specific Modeling

● Software Product Lines● Software Factories

Root Lib

Language Lib

Platform Lib

Domain Lib

DomainComponents

Lib

Hig

her

Ab

str

acti

on

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

Enterprise Defense Systems AutomotiveAerospace

ABSE can be applied to virtually any domain.

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

Atoms can represent and generate code forspecific aspects of the target domain.

Entertainment Engineering

Embedded Devices

Science

Healthcare

Internet

ABSE is Language-Independent

FortranHaskellEiffelC#PhytonSQLJavaABAPErlangScalaSmalltalkVHDLPrologC++ AdaPascalPHPLispRubyJavaScriptDelphiSASCOBOLCamlTclDVisualBasicCGroovyML

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.

ABSE is Refactorable

ABSE metamodels can evolve with your skill.

You can start doing just some texttransformation, grow up by refactoringMetamodels into common patterns.

You can continue right up to fullDomain-Specific Modeling andSoftware Product Lines.

Each time you derive an Atom Template into another Template, you increase the abstraction level.

Line-Oriented

Patterns

Components

Domain-Specific

Software Factory

Objects

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 mechanismthat can built from smaller, pre-built orcustom 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

ABSE meta-metamodel designed to support 100% code generation from the model.

No round-trip necessary.

The mix of custom and generated code is directly supported by the meta-metamodel.

No worries about overwritten custom code, no management issues.

atom_concept_a

Customcode

Generated code

Custom code

atom_concept_b

Customcode

Generatedcode

Generated code

source_file.h

source_file.cpp

Customcode

Generated code

Custom code

Generatedcode

Customcode

Generated code

Mod

el Tra

nsfo

rmati

on

ABSE is Manageable

An ABSE model can grow togenerate multi-million lineapplications, and still be easyto manage.

That's because ABSE is based ona tree and not on a graph:

Tree branches easily encapsulateother 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 beconcurrently manipulated.Two or more developers canwork on the same ABSE model.

And through a supporting tool(like AtomWeaver), workflowscan be applied. Individual atomsor tree branches can bechecked-in or out, versioned andconditionally enabled/disabled.

Instance A

Instance B

Instance C

Instance D

Instance E

Instance F

Instance G

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 worktogether 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 developmentknowledge 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

- 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 canbe reduced or even completely eliminated by using amodel-driven approach like ABSE.

Some tasks under manual coding simply cannot scale:

ABSE Increases Productivity

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

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

The team's productivity potential increases whenever it addsanother metamodel (Atom Template) to the ABSE library.Working on a higher abstraction level boosts your productivity.

ABSE Increases Quality of Code

The code produced by the ABSE metamodelscan (and should) be tried and tested code.

By reducing the amount of custom code usedin the model, overall code quality increases.

It is known that more time is spent debuggingcode than actually writing it.

Critical Innovation : Software Reuse

“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”

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.

ABSE Promotes Reuse

ABSE's meta-metamodel allows Atom Templates to be aggregators,so you can turn any part of your project into a new template forfuture reuse.

Project A

Instance A

Instance B

Instance C

Library A

Instance A

Instance B

Instance C

Template 1

Project B

Instance D

Instance 1

Instance E

Instance F

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.

Reuse“Templatization”

In the same way, ABSE lets you turn recurring patterns intotemplates, reducing project complexity and maintenance costs.

ABSE Reduces Maintenance Costs

Manual Code

Atom Library

Manual Code

Atom Library

Manual Code

Manual Code

Traditional Approach ABSE Approach

Cod

eb

ase S

ize

With ABSE you'll have less code to maintain.

That's because you only have to maintain one instance of your code. All other instances of that code are automatically updated.

And since manual code is natively supported, there's no need to waste time maintaining protected regions, code guards and other trickery, just to maintain the integrity between manual and generated code.

GeneratedCode

GeneratedCode

PART IV

ABSE - Technical Overview

A closer look into ABSE and how it works

The Atom (ABSE's Meta-metamodel)

Atom Template

Custom Areas

ParametersAdmin

Base Template

Derived Template

TransformationCode

Atom Instance

Variables

The Atom can be instantiated into Atom Templates.

Atom Templates derive from other templates.

All Atom Templates derive from root_default, theonly pre-existing Atom Template in ABSE.

Atom Templates can be instantiated into Atom Instances.

Custom Code

root_default An Atom can also be compared to an object in an object-oriented programming language.

Form FunctionsCreationCondition

Relocation

Instantiation

Composition

Atom Template

Custom Areas

ParametersAdmin

TransformationCode

Form Functions

The Atom Admin Section

The Admin Section of an AtomTemplate determines how its instancesare presented and how they behaveon the Model Tree.

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

Custom Areas

ParametersAdmin

TransformationCode

Form Functions

Each Atom Template has a dedicatedEditor.

The Form Section lets you define howthe editor presents the Atom TemplateParameters and how you can set thecorresponding Instance Variables.

The Form Section also inherits from its base templates.

The Atom Functions Section(and Behaviors)

Atom Template

Custom Areas

ParametersAdmin

TransformationCode

Form Functions

This section lets you define extra atomFunctions.

The most common use is to defineAtom Behaviors.

An Atom Behavior is a powerful generalization technique: It allowsthe atom to respond to a specific, globally-defined query.

Any atom can request processing from another atom withoutactually knowing its type, allowing unlimited future extensions.

The Atom Transformation Code

Atom Template

Custom Areas

ParametersAdmin

TransformationCode

Form Functions

The transformation code allows anyatom to perform actions based on itsinput parameters.

Most common task is to generatecode, but other tasks like modifyingother atoms and OS calls are alsopossible.

Create Code

Pre Code

Exec Code

Post Code

The Atom's transformation code issegmented into the following steps:

The Atom's Custom Code

Atom Template

Custom Areas

ParametersAdmin

TransformationCode

Form Functions

To support 100% code generation fromthe model, and to avoid synchronizationproblems between generated andcustom code, ABSE allows you to defineone or more custom code areas on anAtom Instance.

java_function

custom_code

source_file.java

int Function(){generated code;generated code;

generated code;}

custom_code

parameter

parameter

Atom Instance

Variables

Custom Code

CreationCondition

Relocation

The Instance's Creation Condition

The inclusion of each Atom Instanceon the project can be subject to anexpression that dictates whether thatAtom is executed or not.

If the evaluated condition is false, theAtom becomes invisible to the project.

This brings more flexibility to thegeneration process and allows templatesto include/exclude some of their auto-generated atoms based on user-suppliedvalues.

Atom Instance

Variables

Custom Code

CreationCondition

Relocation

Instance Relocation

Atom Instances that are auto-generated byan Atom Template can then be relocated toanother position on the model tree.

The relocated atom may be again movedby the user, if it is not blocked.

For instance, user interface programmers may create atoms thatwill automatically create the interface visual elements's atoms.

Designers can then manipulate and edit those atoms to achievethe desired application visuals.

ABSE Strength #1 : Inheritance

Like classes in several programming languages, Atom Templates can be derived into more complex and specialized Templates.

This allows you tobuild metamodelsthat share commonconcepts.

cpp_class

gui_dialog ext_data_object

db_persistent_object

root_default

The derived template will inherit allproperties 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: http://en.wikipedia.org/wiki/Object_composition

Composited (composed) objects are often referred to as having a "has a" relationship. A real-world example of composition may be seen in an automobile: the objects wheel, steering wheel, seat, gearbox and engine may have no functionality by themselves, but an object called automobile containing all of those objects would serve a higher function, greater than the sum of its parts.

ext_powered_class

cpp_member

cpp_member

cpp_method

cpp_argument

cpp_return_value

Actual metamodels from AtomWeaver project

Inheritance & Composition Combined

You can see here how a metamodel of a C++ class, composed of two Atom Instances, is derived into an “extended class” with added features. Then a C++ Component metamodel is defined byinheriting Extended Classand adding data andconfigurationfeatures...

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.

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

Inheritance & Composition Combined

Atom Templates = Software Components

Metamodels

ABSE lets you build applications like Legotm. A simple, yet effectiveconstraint system drives you on the component discovery andconstruction process.

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,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:

Executio

n S

eq

uence

Create Code

Pre Code

Exec Code

Post Code

Variable Transmission

Atom cpp_class

Defines: class_name,inheritance

Can access: ...

Atom cpp_function

Defines: func_nameCan access: class_name,

inheritance

Atom cpp_argument

Defines: arg_name,arg_type

Can access: class_name,Inheritance, func_name

Atom cpp_member

Defines: member_name,member_type

Can access: class_name,inheritance

Variables are set on Atom Instances, and each variable corresponds to an Atom Template parameter.

Any variable from an Atom is automatically available to all branch children.

This way, any Atom can work “in context” with its ancestors.

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 afairly sophisticated application can be easily built using amodel-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

AtomWeaver implements and extends ABSEinto a complete, agile, dynamic IDE.

Introducing AtomWeaver

AtomWeaver prototype – AtomWeaver's own ABSE model loaded

Introducing AtomWeaver

Due to ABSE's genericity,AtomWeaver works on anydevelopment 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 vendorfaces a long list of otherperipheral, but equallyimportant 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 centralpoint 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 optionalmodules. Each module contains a different aspect of the project.

Future AtomWeaver versions will allow the creation of other,custom-defined modules through its API.

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

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 totransform ABSE models into final source code.

Lua is a lightweight, reflective, imperative and functionalprogramming language, designed to be a scripting language.

Several benchmarks show Lua as the fastest interpreted scriptinglanguage available.

This is specially important to code generation where millions oflines of transformation code are typically needed on a large project.

AtomWeaver Extends ABSE

AtomWeaver adds tools and commands to ABSE's basic featuresetto improve the developer's experience and productivity, including :

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

● Atom Lists : Lets you categorize atoms and build lists accordingto 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:

- Individuals- MicroISVs- Small projects- Isolated generation tasks

For:

- Collaborative projects- SME's- Large corporations- 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

Prices not definitive, subject to changeOptional support and/or maintenance not included

Solo Edition Team Edition

USD $499Regular

USD $199Early Adopter Campaign

USD $999Regular, Per Seat

USD $499Early Adopter Campaign

Per Seat

AtomWeaver's next major features

The following major features are plannedfor 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 thatwill 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 qualitycode 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 usersare 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 automaticallyloads them to the local copy of the project

Team Edition Feature:Developer Role Management

The structure of a development team is mimicked in theAtomWeaver environment

Each user must log in to work on a project

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

Each role can have different privileges regarding code accessor 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 byAtomWeaver

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

Atoms can be selected & associated to these activities

AtomWeaver release timeline*

2010 2011 2012

*Timings subject to change

Sep.2010 : AtomWeaver Solo v1.0 CTP

Apr.2011 : AtomWeaver Team v1.0 CTP

Sep.2011 : AtomWeaver Solo v2.0

Dec.2011 : AtomWeaver Team v2.0

May.2011 : AtomWeaver Solo v3.0

AtomWeaver Competitors

Code Generation is a high-growth market segment: Thereare currently dozens of competitors.

However, most of these products are specific to agiven domain, platform, or function.

None of the other existing products todayis able to offer a technologicalinnovation that can be recognized asa true software developmentbreakthrough asABSE & AtomWeaverdo.

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

www.ruicurado.com

www.atomweaver.com

www.abse.info

community.atomweaver.com

ABSE and AtomWeaver

Thank you for your interest in

www.isomeris.com