Your first step is to create an Atom Library. In this Library you will place your reusable assets that are related to the Library's domain, language, platform or target.
You create the C++ Library to keep all reusable assets belonging to the C++ domain. You do this on AtomWeaver's Library module that manages all Atom Libraries in your project. |
 |
An Atom Template will make up one reusable asset. There is no rule or limit to what this Template represents. You can create an empty Atom Template and then fill it with the necessary attributes, parameters and code.
Atom Template <=> reusable asset <=> metamodel
You create your first reusable asset, the cpp_class Atom template, inheriting from root_default (the default inheritance). |
 |
An Atom Template is made of seven Sections. Each Section besides having a well-defined purpose, is in fact a Lua mini-program that will be executed by the modeler and the code generator.
The Admin Section contains non-executable definitions of your asset. These definitions will help AtomWeaver create and present this asset on your model and other interactive tasks.
Using simple API calls from ABSE's framework, you define cpp_class's attributes, namely its presentation (icon, label), construction constraints (under), and variability (param_text, param_link). |
 |
The Form Section defines an editor for all Instances of this Atom Template.
Here, you instruct AtomWeaver how to create an editor for cpp_class Instances. In this case, you group all its parameters into the "Class" group. |
 |
The Create Section, like an object constructor, is executed whenever an Instance is created on the model. The code on the Base Template is also executed.
You define that when a cpp_class is instantiated in your models, it will be listed in the "class" Atom List. This will help you find C++ classes in your models.
Because cpp_class inherits root_default, its Create Section is also called. |
 |
The Pre Section is the first of the three code generation steps. During this step you prepare the code generation operation by defining additional variables or composing code areas.
To prepare code generation, you create two variables named "headerfile" and "codefile" to help identify the files where you will place the generated code. |
 |
The Exec Section is the second and main code generation step. It's in this Section that most code generation takes place.
Here you code cpp_class's generator. You first prepare the inheritance part of the class declaration by setting a temporary variable. You'll embed that variable in the C++ code you are going to generate.
Then, you generate the class's declaration code using a Lua multi-line string as argument to the code() command. In this C++ code there are embedded variables and embedded section definitions.
Here you took an existing piece of code, surrounded it by code([[ ]]) and then you identified what would change. In this case, the class's name and inhertance is what would change in this code snippet. Therefore, you created the class_name and base_class variables on the Template to support its variability.
There are also other commands you can use to generate code: line() and block(). |
 |
In an analogy to a human developer, the AtomWeaver generator uses a cursor to write on files. You can move this cursor around generated files using the cursor command.
If you move the cursor into a non-existing file, it is automatically created.
The cursor command lets you place the Generation Cursor where you want the next generated code to be placed. Here, you command the generator to move its cursor to the beginning of the file indicated by the "headerfile" variable. |
 |
You can split files into sections, making it easy to group and access specific portions of your generated code.
You set three sections in the class's header file so that you can later insert class members and functions on the declaration code.
For instance, the
cursor("public_class_member_functions","$headerfile")
command would take the Generation Cursor to the place where public member function declarations should be added. |
 |
The Post Section is the last and optional code generation step. The Post step is useful if you need to generate code that depends on or needs to be inserted into already generated code.
You don't need any post-generation actions for this asset. |
 |
The Functions Section define additional capabilities to your Atom Templates. You can define Atom Behaviours or other Lua functions that can be directly called by this or other Atoms.
No additional functions are needed for the cpp_class Atom Template. |
 |
As soon as you have defined a reusable asset, you can immediately use it in your model.
You created an Instance of cpp_class in your model, whose name you set to SimpleServer. |
 |
Unless your reusable asset has no parameters, a form is automatically created for every Atom Instance in your model. This form lets you input the necessary variability values. These values will be fed to its Template when generating code.
The automatically generated cpp_class editor is a form that lets you see and change the variables of the Instance you just created. Instead of a constant string, you can use an expression as input for any variable.
The execution condition shown at the top allows you to conditionally include this Atom in the generation process. With it you can create variations of your product or even a software product line. |
 |
Developing through models is also an iterative process. You can generate code as soon as you have something in your model. Check you generated code and immediately see what needs to be added or changed.
You have just ordered AtomWeaver to execute your model to obtain the generated code. The Files module will contain your generation results.
As you can see, you already have a simple reusable asset that can generate useful code for you. |
 |
You will soon start enhancing your metamodels with additional features.
Here you created another Atom Template, to specify functions inside a C++ class. By adding the
under("cpp_class")
command, you explicitly specify that class functions can only be defined inside a class. This simple construction constraint mechanism will make sure you build correct models and at the same time show you what you can add at a specific node of your model tree.
The new asset is available as soon as you define it. |
 |
You can immediately test and use your new additions. Construction constraints make sure original design intentions are met, and and the same time guiding the developer on how to build a valid model.
You are specifying a member function on the SimpleServer class. You gave it a name, a return type and determined how it is accessed. These variables were defined by you on the cpp_class_function Template. |
 |
You can check and improve the code generation process in a very iterative and quick process.
You have ordered AtomWeaver to generate from your model again. This time you see the addition of the StartSession method declaration. |
 |
Model scaffolding is also possible. You can build a mock-up of your model with the minimum necessary information, and then complete it afterwards when possible.
Using the root_nested_code Atom Template available on the Root Library, you have created a mock-up of your StartSession function. You have specified its workflow but no code yet. This is an easy way to build prototypes, outline your code and mix generated and custom code seamlessly. |
 |
Asset reuse can also happen inside reusable assets! By doing this you can build larger pre-made models, increasing productivity and overall code quality. This is called Template Composition.
You have created an Instance of cpp_class_function under the cpp_class Template. You are specifying that every class has an Initialize() function.
You have just applied composition to build a larger Template. In practice, every time you create an Instance of cpp_class, all pre-defined Instances under it will be duplicated on your model. This further automates your development. |
 |
Because AtomWeaver implements a live ABSE model, any changes you make to your Atom Templates are immediately reflected on the model. You can immediately update your generated code as soon as you make a change to your reusable assets or model.
The changes you made to the cpp_class Atom Template are immediately reflected on your model: SimpleServer now has an Initialize() method. |
 |
The new composite Atom Template will now work as a single entity, automatically creating all Atom Instances in its structure.
You created a new C++ class on your model, BetterServer. Because it is an Instance of cpp_class, the Initialize() method is automatically created.
These Atom Instances are shown in green because they are "Auto-Generated Instance Slaves". These Atoms are duplications of their "Masters" (residing at the Template) and therefore are read-only and undeletable. Changes to these Atoms can only be made at the Template. |
 |
You can build an Atom Template by making it inherit from an existing Template. The Derived Template will automatically inherit most of the Base Template's behavior, so you'll only have to add what's new or different.
You have created a new Atom Template called cpp_enhanced_class that is a different kind of class. Because it shares many similarities with a regular C++ class, you decided to make it inherit from cpp_class.
cpp_enhanced_class takes most of its Base Templates (cpp_class, that inherits from root_default) including parameters and Auto-Generated Atoms.
You also added another function called AdditionalOperations. |
 |
Derived Templates will also inherit their Base Template's Auto-Generated Instances, helping you build larger reusable assets with minimal effort.
You created an enhanced C++ class named ConnectionHandler. As you can see, this Instance has automatically acquired all Auto-Generated Atoms from its Template which on its turn have already acquired additional Instances from its inheritance chain.
You start to imagine what you can automate by creating larger Atoms that combine several others. |
 |
