Fact #1 : ABSE stands for “Atom-Based Software Engineering”, and introduces the “Atom” concept
ABSE is a form of Model-Driven Developent (MDD). It’s a software development methodology that reflects what software development is all about: problem decomposition.
ABSE introduces a fundamental change to all current software development approaches: it shifts the focus away from the computer’s code and into your own ideas and concepts.
ABSE relies on metadata and transformation code that are grouped together to form what is called an Atom. These Atoms are organized onto a tree to form a model of the artifact you want to build. A library of ready-made Atoms will help you reuse all your knowledge in a quick and thoughtful manner.
You’ll use ABSE to model and generate complete applications, but you can also build just a portion of an application. You can also generate text or data files in any format, web sites, or any combination of these.
Fact #2 : ABSE is both a Model-Driven Development methodology and a Code Generation framework
ABSE is a model-driven software development approach: you create models that you can apply later to specific features of the system you are developing. These models capture your knowledge in an automation framework that makes it easy to generate artifacts (code or any other type of file) an unlimited number of times.
ABSE models have associated templates and/or automation that will make it easy to build large projects from smaller parts, and thanks to the code generation framework it provides, you can easily generate hundreds of manageable lines of code in a few clicks.
Fact #3 : ABSE is easy: Away from UML/MDA complexity and closer to programmer’s pragmatic thinking
Most of those software architects that had their contact with OMG’s standards, namely the Unified Modeling Language (UML), Model-Driven Architecture (MDA) and the Meta-Object Facility (MOF), know that these technologies, although mature and capable, are overly complex, and take months, if not years, to get a hold on them. Many past attempts at using MDA have failed and many developers got suspicious about every other form of modeling.
“UML has become complex and clumsy”, said Ivar Jacobson, one of UML’s inventors. Other industry analysts like Scott Ambler think that MDA/UML/MOF are complex and not a viable future option(external link).
ABSE can show developers that software modeling can be agile and pragmatic after all.
ABSE features a very simple and pragmatic approach: You can build metamodels (Atom Templates) that you can immediately use in your projects.
Atom Templates are made up of parameters that you can add according to your needs. Then you can add code snippets and, if you want a more advanced behavior, add some generation code. So, an Atom Template can be as simple as a code snippet with parameter substitution, and as complete as a full-fledged mini-program. Whatever your needs are, Atom Templates can be configured to generate your own code (no canned third-party code) and then grow with you if your development activity gets more elaborate.
This is the typical ABSE modeling workflow with AtomWeaver (an ABSE IDE):
1 – Create Atom Template
2 – Define parameters
3 – Add code snippets if necessary
4 – Use/reuse by instantiating that Atom Template on your project
5 – Generate code
6 – Change parameters, refactor, create, instantiate Atom Templates
7 – Generate code
8 – Profit!
How much easier can model-driven development get?
Fact #4 : ABSE puts a strong focus on reuse: Create once, reuse and save time over and over
ABSE is heavily focused on reuse. Anything you want to build on an ABSE Project Model you will have to create first on an Atom Library. This looks like an additional cost over traditional programming at first, but you’ll notice the productivity improvement as you quickly and efficiently reuse all your accumulated code and knowledge.
An Atom Template is in fact a pure reusable piece of knowledge that you can combine into larger components and systems to obtain your desired runnable code and data. When you use or reuse one Atom Template, it becomes an Atom Instance in an ABSE Tree:
Once you create an Atom Template, you can reuse it many times over. Each time you instantiate an Atom Template you:
- Save time because the code that the Template generates is already done.
- Increase quality because the code that the Template generates has (probably) been tried and tested.
Since Atoms also feature construction constraints, the Atom Library can teach, guide, or otherwise force developers to follow an established architecture. Description and other Atom Parameters that the repository creators might wish to add will guide the developer in the model discovery process.
Fact #5 : ABSE supports the complete application life-cycle (ALM), from concept to maintenance
ABSE is an encompassing methodology because it can support you on every task of the software system’s lifecycle.
Application Lifecycle Management (ALM) is normally performed by specialized integrator software that orchestrates the multiple phases in the life of a software product. These products are needed because the methodologies in use do not cover the whole development spectrum.
ABSE materializes itself in the form of a tree. A tree of Atom Instances, in fact. An ABSE project can have an unlimited number of these trees. And one Atom Instance in one tree can reference another Atom in another tree. Specific trees have specific objectives: You can create an ABSE tree for requirements capture, another for your software application, another for issue tracking, another for end-user documentation, and so on.
For instance, an Atom implementing a certain program feature can be linked to its corresponding requirement Atom; The same feature Atom may generate a piece of end-user documentation by automatically adding an Atom on the documentation tree.
You are not forced, however, to have separate trees for different tasks. You can mix all tasks into a single tree: For instance, your feature Atom may generate the end-user documentation itself, and you can add bug report Atoms directly underneath its corresponding feature.
ABSE is flexible enough so that you can continue to use your preferred work methods, but it will add organization and automation, resulting in better quality in less time.
Fact #6 : ABSE is universal: You can target and mix programming languages, architectures and platforms
ABSE is not targeted at any specific programming language or hardware platform. In fact, you can target multiple platforms and generate any programming language you want.
Since ABSE’s first principle is simply concept association, you can join disparate language and hardware targets in a single Atom Template.
For example, you can model a RIA architecture where you can generate, from any single Atom, web pages (HTML), design (CSS), definitions (XML) and code (JavaScript, ASP.NET, others).
While this might seem a source of confusion that might occur by mixing languages and platforms, ABSE has separation mechanisms that keep your projects from getting messed-up: Atom Libraries, Atom composition and Atom Template inheritance.
Atom Libraries allow you to keep languages, platforms, architectures or domains separated in their own libraries. You then use the ability of an Atom Template inherit another one, even on a different library. This way you can “refurbish” an existing template into doing something that is new or complementary. This mechanism works like object inheritance in OOP.
Opposed to inheritance, you have Atom composition: You can build a new Atom Template by joining other Atoms together, allowing you effectively perform multi-targetting and still keeping a very good separation of concerns.
Fact #7 : ABSE allows generation of any kind of file. Generate code, webpages, documents, data files
ABSE, apart from from being a model-driven software engineering method, also lays the foundation for a code generation framework: Atom Templates, ABSE’s metamodels, can hold several “code generation programs”, also known as “transformation code”.
You can command any Atom Template to generate free-form textual output. Therefore, you can generate any kind of text file, in any format you need. You can generate, among others:
- Source code files
- Project files, build scripts
- Web pages
- XML, XSLT files
- CSV files, tabular data
- Configuration files
- Documentation
- Zip files and other binary files (through the execution of an external command)
- (Your specific file type here)
Remember that thanks to Atom Templates’ composition capabilities, you can generate multiple files, of different types, from a single Atom.
Fact #8 : ABSE mimics the associativity paradigm of our brains: Build models the way you decompose problems
Everyday we solve problems. In fact software development is all about solving problems. You usually decompose requirements into smaller requirements, and therefore, problems into smaller problems. Then, you find a small solution for each of those small problems. This is how we do it, as far as theory goes.
Conversely, we can build larger solutions by combining smaller solutions together in an orchestrated way. If we do this on a permanent basis in real life and especially in software development, wasn’t it good if we could use this approach at the modeling level?
So when we are developing, we are constantly splitting problems into smaller problems, or composing solutions into larger solutions. Your permanent questions will always revolve around something like “How is this done?” (problem decomposition), or “What is this made up of?” (solution composition).
When you model through ABSE, you must answer these questions when you are building Atom Templates, and then again when you build your project model.
For instance, when meta-modeling a class, be it in C++, C# or Java, you ask yourself “How are classes defined?”. “They are defined through attributes and methods”, you answer. So, you create an Atom Template to model classes, another Atom Template to model attributes, and another to model methods. Then, by using Atom Constraints, you define how these “pieces” go together.
In another example, when you want to support the notion of “Customer” in an online ordering system, you will ask yourself: “How is a customer implemented (on the system)?”. You may answer: “It’s implemented through a table in the database, a personalization web page, and an order tacking system, (etc).”. So, you model your customer by instantiating the “database table”, “web page” template, and “tracking system” Atom Templates. In their turn, these templates have been probably composed of other even smaller “solutions”, or Atom Instances.
So, when modeling you constantly break-up problems and compose solutions, and that intrinsic human behavior can be directly modeled using ABSE, making it one of its strongest arguments.
Fact #9 : ABSE supports all software engineering methods: CBD, FDD, AOP, DSM, TDD, even line-by-line coding
A model is a rather abstraction-level-free concept: Apart from the usual concept of model, many also consider source code as a model that is translated into assembly code, and assembly code is the model of machine execution.
ABSE lays the foundations of a distinct form of model: brain logic. With this simple, but powerful approach, ABSE can build all your software engineering models. This is why ABSE can support all software engineering methodologies.
If you want to implement Component-Based Development (CBD), you can directly use Atom Templates since they are comparable to components, after all. Also, all your component interfaces, messaging and data ports can be specified, modeled and enforced.
If you consider an Atom Template as a feature, you can then implement Feature-Driven Development (FDD). An Atom Template can be composed of other discrete components, snippets, models or sub-features.
Since code generation with ABSE is not sequential, you can easily weave aspects to your application classes or features, which makes Aspect-Oriented Programming (AOP) an intrinsic characteristic of the whole ABSE approach.
If you want to work at a higher abstraction level, in the problem domain, you can implement Domain-Specific Modeling (DSM). For instance, you can model your solution domain Atom Libraries first, and then reuse Atoms on those libraries in higher-level, problem domain libraries. These will be the meta-models of your domain-specific concepts.
In a Test-Driven Development (TDD) setup, you usually build a test first and then you build the corresponding feature that passes that test. With ABSE you can implement and enforce specific test procedures.
If do not want to implement any specific software engineering approach, you can still develop you application using the traditional line-oriented, file-based development by just implementing very simple models of your files and object.
And of course, you can mix any and all of the above approaches with your own…
Fact #10 : ABSE’s flexible meta-metamodel allows you to model any concept at any abstraction level
ABSE is abstraction-level independent. You can create a metamodel of a code snippet (a few lines of code) but also a model of a complete application feature (thousands of lines of code).
ABSE’s meta-metamodel, the “Atom”, was built to be generic. The “Atom” is just a description, and a set of rules about how Atom Templates can be built, inherited and composed, and how these Atom Templates can finally be instantiated into meaningful parts of your final system.
Because ABSE’s meta-metamodel is very simple and flexible, you can model, and then generate, virtually anything. This flexibility also allows ABSE to be able to model the entire application’s lifecyle: requirements, documentation, design, code, test, deployment, issue management, all can be modeled through an ABSE tree and specially crafted Atom Templates.
Fact #11 : ABSE is domain-agnostic: From games to automotive, from web to embedded, ABSE models can handle it
ABSE was created with the goal of laying out a foundation and support for all the processes involved in software engineering, as well as supporting all domains. So, ABSE is domain agnostic by design.
ABSE is a methodology that supports the generic human problem-solving process, with a strong support for the software engineering discipline. This genericity gives developers the power to translate any of his/her specific views of any given domain into actionable, configurable metamodels.
ABSE has built-in genericity. The developer adds specificity.
Any imaginable domain can be modeled with ABSE. ABSE’s genericity may however come with a cost: there could be approaches that are more suitable to model a specific domain than ABSE. However, today we see that domains cross over all the time. For instance:
- Automotive has built-in entertainment (a problem domain cross-over)
- Entertainment devices have web access (a problem-solution domain cross-over)
- Web apps use databases (a solution domain cross-over)
So, in a world where domains mix and cooperate most of the time, a development approach that supports any domain stands a better chance of evolution and long-term stability.
Fact #12 : ABSE models are refactorable, from simple text transformation, up to full domain-specific modeling
Refactoring in a traditional programming approach is the process of changing a program’s code without changing its functional behavior. Through this practice you obtain improved code readability and reduce complexity, improving at the same time the maintainability of the source code through a more expressive architecture.
Like in traditional programming, you can refactor your ABSE models. And the same benefits apply. You can start with solution domain Atoms, like print, database, math, etc, which you will use to model your application at a lower level of abstraction. Then, you can progressively group these Atoms together to form higher level constructs, in intermediate domains, and finally at your problem domain.
This refactoring capability of ABSE makes it rather easy to start modeling with almost no upfront investment in the preparation of metamodel libraries, which is a big advantage over other model-driven development approaches. Many organizations dismiss model-driven development because of the perceived up-front investment to be made before something comes out of a model. That is not the case with ABSE.
One simple example is when you have a new piece of code. Because it is new, you just create a custom-code Atom to include it in the project. However, as repeated usage of that code segment is detected, it can be turned into a specific domain Atom.
Another example is when a pattern of Atoms is consistently used many times: This pattern will be regrouped as a new Atom Template (a new meta-model) which can then have its own parameters and construction constraints, probably turning those low-level, solution-domain Atoms into one high-level, domain-specific Atom.
Fact #13 : ABSE models directly support and manage both generated code and custom code
ABSE models support the notion of a “custom code block”. Code blocks are first-class parameters: You can supply a piece of custom code as a parameter to an Atom Instance. It’s then up to the meta-model (Atom Template) to decide what to do with that piece of custom code. Usually it is simply placed in a specific section on a generated file, but the meta-model can do additional processing on that block.
Management of custom code blocks by the meta-models themselves avoids these common problems found when mixing generated and custom code:
Generated code overwrites your additions
Regeneration deletes your custom code
Problems distinguishing generated from custom code
Last-minute, problematic hacks on generated code
One example:
To define a custom code area on an Atom Template:
param_area("init_code","Custom initialization code","")
To apply custom code along with generated code:
cursor("initialization_code")
code("$init_code")
Fact #14 : ABSE models can handle simple programs, as well as multi-million line systems
An ABSE model is represented by a tree and not by a graph. While a tree can also be considered a graph, it is a specific type of graph that can be represented through a graphical UI on all current computer systems. Graphs are prettier to the eye but have severe layout and space requirements when large feature densities are reached: If want to have a global view of the project, you have to give up on the details. On the other hand, if you want to see some details, you have to give up the global view.
An ABSE tree can have millions of Atoms and still be manageable. Why? Because a tree is a fractal object: Successive details can be uncovered by successively opening deeper branches. Conversely, you can progressively encapsulate smaller details by successively closing tree branches. You can be looking at different levels of the tree but still seeing just the right amount of detail for the task in hand.
For very large models, an ABSE Tree can be partially loaded, thus allowing for manipulation on systems with limited resources.
Fact #15 : ABSE models are collaborative: Multiple developers can concurrently work on an ABSE model
One of the big problems of graph models is the difficulty of breaking them up semantically or even graphically: how can we break a graph in its meaningful parts. This is an essential task for collaborative work on models that are graphical in nature, like UML.
Due to its granular nature, an ABSE model is made of discrete elements, the Atoms, which together make up branches. These branches make up the ABSE Tree. Additionally ABSE Atoms and the branches they make up are clearly identified in respect to their specific and semantic application. This makes collaboration on an ABSE Tree a natural task because it is easy to select Atoms or branches.
Because an ABSE Tree can be be concurrently manipulated, two or more developers can work on the same ABSE model. The result is a system that can work at the meta-level, without sacrificing all the flexibility that we find today in source-based collaborative and version control systems. Individual atoms or tree branches can be checked-in or out, versioned and conditionally enabled/disabled.
ABSE can go even firther: Through an ABSE-supporting tool (like AtomWeaver), other important aspects of the software development process can be supported. For instance, workflows can be applied. These workflows can be modeled through an ABSE model!
Fact #16 : ABSE can connect all stakeholders in a software project
ABSE models are not just suitable for code generation. For instance, you can build models for requirements capture.
Because business stakeholders, those with domain knowledge but lacking programming skills, don’t speak your language and can’t use your development skills, you can make it easier for them to give you the information you need.
You can build Atom Templates for requirements capture. And because Atom editors work like forms, it’s easier for business stakeholders to express their needs by feeding information directly into your model, in a way that is also suitable for your development workflow.
In addition, complete requirements management and tracking can be achieved because you can reference or include requirements Atoms under your system features.
Likewise, you can define Atoms for issue tracking, testing, deployment, documentation,…
Fact #17 : ABSE captures, shares, and reuses knowledge in a team environment
ABSE is highly focused on knowledge capture and reuse: It converts your development knowledge into a systematic, but easy, modeling process.
When you create an Atom Template in an Atom Library, that Template will contain a piece of your knowledge that can then be reused many times over. Your individual expertise can be shared with the whole team, effectively creating a collective intelligence environment.
Anyone on the team can contribute his know-how to the central Atom repository. The collected knowledge can then be applied and reused by everyone, reducing all that time spent while looking for answers to a problem that was already solved by another team member.
Architectural uniformity can be achieved because architects can set how applications are specified, built and implemented. Less-skilled developers can work like the experts because non-trivial information like best-practices and architectural constraints can easily be captured through Atom Templates. Through the use of Atom constraints and Template Parameters, less-skilled developers can be guided by the system to build correct models.
Fact #18 : ABSE increases your productivity: The more Atoms you reuse, the faster you get
An Atom Template is a reusable asset. It’s a piece of your development knowledge that you know will be used many times over, or at least several times.
It is a fact that metamodeling takes some additional time over traditional programming. The first time you model a feature, it will take longer than just coding it directly. However, the second time you need the same feature, it is much faster to reuse the metamodel than doing it again. This is specially true if the code is not constant, that is, it contains parts that may change according to context.
Using metamodels (Atom Templates in the case of ABSE) brings several added benefits that influence productivity, like:
- Quickly reusing existing knowledge (code or other artifacts)
- Reusing tried and tested code instead of doing it again (and risk introducing new bugs)
- Enforcing best practices and architectures
- Guidance through Model constraints guide newbies and avoid architecture fragility
Effective reuse is the holy grail of software development ROI. Each time you successfully reuse your knowledge, you are doing more with less, and that’s the way to go if we want to tackle the ever-increasing need for software with a finite work force.
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”
Fact #19 : ABSE increases code quality by promoting reuse of tried and tested code and architectures
Developers are re-inventing the wheel all the time. Every time that “wheel” is re-invented, the potential for errors increase. Developers are not machines, and therefore they get better, but not perfect, over time.
So, even if you are very experienced at some languages, architectures or platforms, a bug is always at the distance of a copy/paste, or a colleague/email/website interruption.
It would be much better if you had a way to automate your knowledge. Common code generators and snippet managers are not enough due to their narrow application scenarios. With ABSE you can create a model of your thinking method. And if you model it right, you get it right every time.
If you find a bug in your models (Atom Instances), you will correct the metamodel (Atom Template) and this way you ensure that this bug will never occur again. This is a huge advantage in an industry riddled with bugs and inaccuracies.
Another aspect is the difference between good and great programmers. Some influential people say a great programmer can be 10 to 100 times better than an ordinary one. Why not leverage that power to all members of the team? ABSE can help novice or average developers create code as good as the rock star programmers on the team.
Fact #20 : ABSE reduces maintenance costs: More generated code, less custom code to maintain
Code generation has one immediate advantage: the generated code is maintenance-free. However, the code generator needs its own maintenance. ABSE divides your code generators in the shape of many fragments, called Atom Templates (metamodels in a MDSD context). This is extremely helpful because you can easily separate the multiple concerns of your architecture (as Aspect-Oriented Programming promotes) into dedicated units that are easy to identify and maintain.
Custom, one-off code probably should not be modeled, as there will be no immediate added benefit, but repeatable, reusable code can help you greatly reduce the costs associated with code testing and maintenance.
As many say, any new line of code you introduce in your program becomes a liability in the future, so you should avoid adding what you don’t need. And if you need it, you should automate it through Atom Templates, so that you only need to maintain code in one place: At the Atom Template. Then, regenerating code from your model automatically applies changes to all instances of that particular Template.
As you create more and more Atom Templates, and you models become tighter, the percentage of custom code will reduce with a direct consequence on the reduction of maintenance costs.
Also, ABSE allows for a different, more logical organization of your project, making it easier to find and work on your application features, increasing your productivity and ultimately, the quality of the code you produce.
Fact #21 : ABSE lets you create applications through building blocks, much like Lego
Most of us developers have dreamed of building software applications by just snapping small parts together, just like the Lego bricks we all have played with in our childhood.
However, albeit constantly sought for, this goal has never been quite reached. The extremely broad application of software engineering (almost everything in our lives today) makes it quite difficult to create infinite possibilities from components that have a finite, small number of “connections” or options.
But with the emergence of domain-specific modeling, we can narrow those “infinite possibilities” into a manageable “large quantity” of possibilities, making it possible now to model a system that is complex, but within a known domain, using those aforementioned building blocks.
ABSE innovates on this front: Atom Templates (ABSE’s metamodels) can be made of other Atom Templates, creating larger components. And through Atom dependency constraints, you can define to which other “blocks” can a “block” snap to. These constraints implement model construction guidance.
ABSE can be a pure “snap together” modeling system. It does have its costs, naturally. Metamodels conforming to your domain have to be built and tested. But when you have a well-developed metamodel schema in place, building applications with ABSE will be “a snap”!
Fact #22 : ABSE allows requirements and feature traceability through Atom composition and link parameters
Requirements traceability is concerned with documenting the life of a requirement and to provide bi-directional traceability between various associated requirements. It enables users to find the origin of each requirement and track every change which was made to this requirement.
The same is valid for features. When we implement a certain system feature, it is important to know, at any project stage, what was coded to support such feature. The opposite is also important: to know to which feature a specific portion of code belongs to. Feature traceability is essential to reduce the software evolution effort.
Two ABSE features provide good support for traceability: Atom composition, and link parameters.
Composition is the act of building a larger object (or system) from smaller parts. You can compose larger Atom Templates by reusing a putting other Atom Templates together in an orchestrated way. When you compose an Atom Template, you are automatically creating a forward-trace and back-trace mechanism.
Also, because ABSE models are trees, a given tree branch can be considered, if you have chosen to model it that way, a feature of the larger system. Therefore, ABSE tree branches provide automatic tracing mechanisms.
Link parameters are Atom Template parameters whose values are actually references to other Atoms. For instance, if you have a requirements Atom, you can, when you implement the corresponding system feature, have a link back to the original requirement. This gives you two possibilities: to know to which requirement a system feature is fulfilling and, conversely, know which system parts are fulfilling that particular requirement. For example, if you have a change in one of the system’s requirements, you know immediately which system parts are affected by that change.
