actifsource

BinaryTrees For Rescue

2010-08-25T17:18:00.010+02:00

When ArrayLists become big reverse lookups like indexOf, lastIndexOf, contains and the modifications methods can slow down your program. When order is not important, you might use a HashMap. In some other cases you have a constant key-value, that can be use in a TreeMap. If you need to have to update the index however there is no real alternative. What I'm missing in the java collections is a balanced tree, allowing me to traverse it's structure. The NavigableSet-Interface available since Java 6 only allows to traverse the elements. There are no methods to access the tree-structure. I wonder why the tree used in TreeMap wasn't made available in a separate Red-Black-Tree class.

As mentioned before trees can be very useful when search through big datasets. Imagine you have a texteditor with more than 10000 lines of text and you need a mapping from lineNumber to line and line to lineNumber. One possibility is to put all lines as keys in a map and use the index as a value, but than you have to update the map every time, you insert a new line. Using a tree, you can insert the lines at a certain position and put the treenode instead of the index into the map. Now you can lookup up the treenode for a line. Calculating the index of a treenode is not difficult:

To speed up the calculation you can cache the node-count of each subtree in the corresponding rootnode and only recalculate it, when a subtree node changes. This way a lookup of a treenode by it's current index or calculating the a treenode index should be very fast enough.

The calculation of the index can be easy adapted to similar cases. For example if you have a texteditor supporting different line heights, calculating the y-Offset of a single line is expensive. Calculating the y-offset of a line requires to sum up all height of the previous lines. Having all lines in an Arraylist means to iterate through the hole list beginning from the first line. You may think about caching the line-offset in a treemap, but than you have to clear all entries after the modified line. In worst case if the first line changes, the while cache is invalid. With a tree, you can store the sum of heights in the treenodes. If the height of one line changes, you only have to recalculate the value of parent nodes. Caluating the y-Offset is now much cheaper, just sum up the height of the lines in all left-children and the height of the line stored in the node, when following a right-child. The only difference to the index calculation is that, that a treenode adds the height instead of the constant node count 1 when including it's own value.

Comparing the speed of an arraylist with the speed of the tree, isn't an easy task. There are many things to consider:

a) if the dataset is rarely modified and the dataset isn't to big, a map can be used to improve the reverse lookup
b) the speed for an indexOf/lastIndexOf/contains lookup an the arraylist strongly depends on the speed of the equals and hashcode method. For example for integers this is very fast.
c) the number of different elements, if you have only 10 different elements in the list and they are random, the results of indexOf/lastIndexOf/contains will need much less comparisons
d) a tree needs more memory
e) for looking up an element by an index there is nothing faster than an array and same applies for creating complete copies it.

I think the main reason for not including a balanced binary tree in the java collection as a separate class, is that the arraylist in most cases is fast enough. Wether to use a tree, hashmap, arraylist or linkedlist dependends on what you want to do. There is no golden hammer, that solves all your problems.

DCI and actifsource

2010-08-08T16:12:00.010+02:00

In my last post I introduced the modified DCI meta model. Let's have a look at a simple example.

The use case we would like to implement is to transfer money from a money source to a money sink. MoneySource and MoneySink are specific roles, played by an appropriate bank account.

The example is built up on the following entities:

UseCase: TransferMoney
From a users point of view the use case is the most important artifact in the code. That's because the use case contains business relevant code.

The following UseCase shall transfer money from a MoneySource to a MoneySink. Furthermore the amount of money shall be passed to the use case as an argument.

Role: MoneySource and MoneySink
Let's have a closer look at the roles needed. The MoneySource has an interaction balance() to ask for the current balance. Furthermore the role supports withdraw() to withdraw an amount.

Note that we specify that this role might be played by an InvestmentAccount or a SavingsAccount.

MoneySink on the other hand side supports the interaction deposit() to deposit an amount.

Note that this role might be played only by the SavingsAccount.

Data: InvestmentAccount and SavingsAccount
The InvestmentAccount shall have a Balance member to store the actual balance. Furthermore the method withdraw() supports withdrawal. Therefore it might play the MoneySource role.

The SavingsAccount supports withdrawal and deposit. Therefore it might play the MoneySink or MoneySource role.

Context: TransferMoneyContext
The context now puts it all together. Every context has to specify exactly one UseCase. In the following example we choose the TransferMoney UseCase.

Since the UseCase TransferMoney declares the usage of the Roles MoneySource and MoneySink actifsource asks us to provide the data which can play the roles.

Using content assist to selected the data object for the MoneySource role we can choose between the InvestmentAccount and the SavingsAccount. As we have seen before both accounts have a withdraw member and are therefore able to play the MoneySource role. For this example lets choose the InvestmentAccount.

Last but not least we have to specify the data for the MoneySink role. Using content assist on the data field only allows the SavingsAccount. Thats because only the SavingsAccount allows to deposit an amount.

The TransferMoneyContext has been declared for the UseCase TransferMoney. Since TransferMoney stated to work with the Roles MoneySource and MoneySink we have to provide Data which can play this roles.

Thanks to the strong actifsource type system it becomes possible that the content assist allows only Data which can play the role needed.

The DCI Meta Model

2010-08-08T15:44:00.004+02:00

In my previous blog I promised to work out a meta model to realize the DCI architecture. As explained before I've made a slight modification: a UseCase is modeled as its own entity.

UseCase
A UseCase is business relevant code which needs different actors (data objects playing roles) to work on.

Context
The context manages the UseCase an the data objects which are able to play the roles needed.

Role
A role is an interface which can have 1..N interaction (an interaction is realized as an abstract method on the role interface).

Every role might be realized for any suitable data object. A role realization for a specific data object is called Adapter.

RoleData
Setting up a context it must be determined which data object plays the roles needed.

Data
Data objects contain members and method. Members are simple data fields an result in an appropriate getter function. The method can be freely chosen and realize a more sophisticated access to the members.

The DCI Architecture

2010-08-08T15:21:00.003+02:00

In his new book "Lean Architecture: for Agile Software Development" James O. Coplien shows up with a new programming paradigm: The DCI Architecture.

Before reading this blog I suggest to have a look a the DCI vision document:
http://www.artima.com/articles/dci_vision.html

Let me try to explain DCI in a nutshell.

The idea of DCI is to separate data from business code for better readability while the business code is directly expressed as use case.

DCI stands for Data, Context and Interaction.

Data
Data means POD (plain old data) objects without any business relevant methods.

Context
A context is a place to retrieve and/or setup a necessary data.

Interaction
An interaction is a complex function applied on the data of the context.

Implementing DCI
Implementing DCI is not an easy task since traits are needed. Coplien shows a C++ implementation using template traits as known from the STL. Nevertheless the DCI architecture asks for tool support.

The modified DCI Architecture
My goal is to realize the DCI architecture using actifsource. Therefore an appropriate meta-model is needed.

I decided to keep the DCI idea but modify the model a little bit.

My idea: a UseCase needs 1..N actors (Role) to be implemented. Every role is realized on a POD (plain old data) object.

A context is needed to setup a UseCase and all Data objects which can play the roles needed.

Since a role can be played by any suitable data it seems quite natural that we have to provide kind of an adapter for every Role/Data relationship.

Because I'd like to realize DCI with the actifsource code generator setting up the adapters is no big deal. Instead of hand coding adapters are generated as needed.

Advanced usage of Visitor-Pattern

2010-07-19T15:41:00.013+02:00

Have you ever used the Visitor Pattern to resolve the specific type of a collection of objects? What you usually do is defining a common interface and add an accept()-method taking the visitor interface and in the implementation invoke the visit()-method from the visitor.

Here is an example for following hierarchy

The INodeElement might look like this:

and the IHeadElement linke this

Later on, in your implementation code you can use the visitor to lookup the concrete type

As you can see there is no typecast needed, so you never get a ClassCastException. However if you look at the example, one major drawback of the visitor pattern is that if the hierarchy is not matching exactly, you have a bunch of empty methods. These methods can lead to confusion and doing nothing or throwing an exception isn't much better than a ClassCastException.

If you have the control over the source, you can easily introduce a new more specific type in your hierarchy to workaround this.

Now you can tag the child elements (in this case we have only one)

and the return type of the list can be changed to a more specific one

Using the new more specific visitor, there are no more unnecessary methods

Problem solved? Yes, if you have the freedom to modify each element for tagging it, when ever you create a child list. Otherwise you should look for a better solution.

Think a short time about, what you really want to do. You want to restrict the list to adding elements only of specific types and allow to query them later, while making sure that no type is forgotten when the code changes. Another possibility to add a visitor is to wrap the list element. To do so, remove the IHeadElementChild interface and the corresponding accept-method from the ITitelElement. Now add an implemention for the IHeadElementChild interface. Create factory method for each element allow in the childlist.

In the implementation of the IHeadElement always add the wrapper to the list, everything else can be left as it is. Now you are completely independent of the class hierarchy. Note that this solution will also work with classes provided by foreign frameworks.

If you already used actifsource to describe and generate your class hierarchy, you can leave the whole work to the generator and gain the advantage of more type-safety and less casts.

Modeling Software Architecture

2010-07-05T10:56:00.011+02:00

In my last blog On the semantics of explicit dependency relations I explained the concept of explicit dependency relations between domain-specific components. The big advantage shows up when modeling on an architectural level.

A complex system is divided in layers/tiers and packages to manage code artifacts. This technical architecture provides an overview on the implementation.

On the other hand we find the business architecture where packages, areas, functionality, epics, etc. are used to structure domain objects.

On the semantics of projects and packages
Both the technical and the business architecture have one thing in common: they are structured not only with packages but also with projects. Modern IDE's as Eclipse, MS Visual Studio or InteliJ's Idea animate developers to separate different concerns in different projects.

All artifacts of a software system are structured using projects and packages.

But architecture lays above projects. Architecture describes how a system is divided into projects. This fact leads to the problem, that architecture can never be described by its projects alone.

It seems that describing architecture needs kind of an Über-Project which contains the overview how projects are interrelated. This overview shows packages and their dependencies as shown in my blog before.

There has to be an overview how projects are interrelated. This overview is the most important artifact to understand the technical architecture or business architecture.

The tricky thing: The overview provides an entry point whereat the details are managed in the projects. But nevertheless this architectural project should contain all the information to get a complete overview. This includes also detail information contained in the particular projects.

Let's assume that all green packages are modeled in the architecture overview while the red packages are realized as projects.

The architectural overview seems to define packages which contain other packages
At a certain level the architectural overview seems to reference packages from other projects to illustrate the dependencies

Packages as resources
In the current version of actifsource packages are reflected as file system folders. But it seems obvious that packages are much more then folders.

Package-structures have a project-specific meta model
Packages declare dependencies to other packages (according the meta model)
Package structures may be distributed over several projects (package references)
Packages can be mapped to file system folders

Packages are resources that contain other resources. Modeling packages as folders is just one way. Packages might also be modeled in the architectural overview without a folder representation. And package hierarchy structures are not limited to one project but distributed over many projects.

In one of my next articles I try to examine the technicalities.

On the semantics of explicit dependency relations

2010-07-03T11:16:00.009+02:00

Meta-modeling leads to components built along the own-relations (compositions) and to component-interdependencies along structural use-relations.

Component interdependencies might appear deeply nested in the component. Remember that component comes from the Latin word "componere" which means being composed. The following example shows a use-relation between A.B and X.Y.

Just looking at the components without knowing the internals we can say that there is an implicit dependency between the two components A and X.

If we could make this dependency relation explicit there would be a way to constrain the A.B-X.Y relations on higher level.

This possibility would allow you to control the component-interdependencies - even if they are nested deeply in the component structure.

Technical Architecture

You may argue that component are not complex enough to control their use-relation by an explicit dependency. But imagine a software architecture which is based on layers and packages:

All packages and subpackages are somehow related to each other. Since the above diagram shows the technical architecture of our system the artifacts placed in the packages are templates (when generating) or simply code.

Just imagine you could explicitly define the dependencies between the packages. And now imagine that every template inter-dependency (one generic class using other generic classes) is checked immediately by the actifsource real-time validator.

Providing such a system your technical architecture would be documented soundly. And moreover actifsource would ensure that your code follows perfectly along the architecture.

Business Architecture

Another very interesting application of dependency relations is found when designing the business architecture. Coping with a complex business domain the relating business objects have to be structured to keep the overview.

Grouping domain-objects in packages and defining dependencies between the packages allows you to control use-relations between components from a higher level.

Providing such a system would allow you to group domain objects together for a perfect overview. Moreover actifsource would ensure that any relationship between components follows the well defined business architecture.

Conclusion

Modeling explicit dependencies allows you to control use-relations from a higher view. This view is what we usually call the architecture overview. actifsource could not only provide sound documentation of the architecture (technical and business) but also ensure at real-time that no artifact breaks the dependency rules.

The secret to this functionality lies in typed folders as Micha described in his blog Grouping Is Domain Specific Too. In one of my next blogs I try to workout the tricky details.

Writing C# using actifsource and eclipse

2010-07-02T16:45:00.021+02:00

When people from the dotNet world hear about actifsource running on eclipse, they always ask us if it is possible to generate c# code for example. Today I want to show you how to create a c# application in eclipse using the emonic plugin.

First you have to install some prerequisites:

nant - which is used to build the c# projects
mono or Microsoft .NET Framwork - providing the tools and resources to run and build c#-projects

After you have installed them you need to setup emonic:

I only installed the "Eclipse Mono Integration", the debugger doesn't want to install at the moment and the other features are not required for this demo. When you have finished the installation, you first need to setup .NET preferences. Select the nant-binary-file:

and afterwards add a .NET-Framework Implementation. For example I used mono and chose the following settings:

Now create an actifsource projects for your meta model and the actifsource templates. I used the actifsource core model as meta model and wrote a simple data class template. The template is nothing special, but instead of writing java code, I wrote c# code:

Note that I have created a separate actifsource project for the actifsource template and generation specific resources. With our multi model concept, there is no need to modify your meta model project, just create an extension project. Since the actifsource project containing the template is a Java Project and mixing Java Code with C# Code is not recommended, switch to .NET-Perspective and create a separate .NET-Project.

I used "Mono 2.0" as target, you may use another target framework. This setting is important, since generics for example are not available in "Mono 1.0".

For generating the data classes I first need some actifsource classes. I just reused one of my last examples and put it into a newly created asrc folder in the dotNet project.

Now there are only a few steps to do, add a project dependency to the template-project and define the target folder.

The c# files will be generated immediately after pressing "ok". In emonic to make them compile, you have to right click on them and add each file to the build.

When doing this the first time, you need to set a build target:

Finally I added a small demo application which creates two instances of the class "Person", fills them and queries the data for writing it to the console.

To run the application one needs to right-click on the exe-file and select run .NET-Application.

That's it. If you don't want to add each file, you need to edit the build script and make use of wildcards. One drawback using wildcards is that the emonic builder doesn't seem to detect file changes for these resources.

Structural vs. Functional use-Relations

2010-07-02T16:27:00.011+02:00

In my last blog I talked about the semantics of permanent use-relations. In the meantime Micha had the idea not to differ between permanent and temporary relations but between structural and functional relations.

The idea remain the same. Some use-relations are important for the overall component structure and some are not. Let's have a look at some examples.

First of all, let's have a look at the following structure. Component owns Command owns Argument. But the Argument itself has a use-Relations to type. Imagine a function declaration f(int a, float b) where the argument a has a type int and b has type float. The relation of a method argument to its type is simply functional an will never appear as a relation in an UML diagram.

The second example show a meta-model which declares that components may extend/subclass other components. This relationship is clearly structural because it's important from the component's view. Just imagine the specialization relation in a UML diagram.

Quite special on the above relation is the fact that it's never necessary to name the role of the extends relation more specifically. Extends remains extends no matter what is extended.

The next example shows a meta-model for a component which has a collaboration relation to other components. The difference to the above design is that the collaboration relation has a role which has further information (i.e. at least a name.) For that reason the role has to be designed as an own class on the meta level called Collaborator in the subsequent example.

Let me give a résumé: First of all we distinguish structural and functional use-relation. As a rule of thumb only structural use-relations matters for the overall component structure.

Taking a closer look at structural use-relations one notice that there are relations with and without roles. If no role is needed the design is simple as seen above. If A extends B the extends relation between A and B needs no further information.

But if we do need to distinguish roles for a structural use-relation this role has to be modeled in a separate class providing at least a name. In the example below component A uses B1 as xAxis and B2 as yAxis. Note that xAxis and yAxis are instances of Collaborator.

It's quite interesting that the class Collaborator of the meta-model is visualized as a role in the instance-model. Since the decision if a structural use-relation needs a role or not is taken by the designer, we have to distinguish 3 different modes for use-relations:

functional use-relation
structural use-relation without a role
structural use-relation with a role

If we specify the use-relation mode on the use relation it becomes possible to visualize components and their interdependencies soundly.

To conclude this blog let's think if this concept might work for a generic diagram editor which can visualize meta-model and model at the same time. For this reason let's have a look at the following simplified UML meta-model (which can be seen as meta-meta-model for our example).

The type-relation from Argument to Class is a functional use-relation
The extends relation from class to class is a structural use-relation without a role
The type-relation from Member to Class is a structural use-relation with a role (Member play the role)

At the moment it seems to me that our concept can be applied to all types of models. And this would be greatly simplify the development of the diagram editor.

On the semantics of permanent use-relations

2010-06-27T10:50:00.005+02:00

3 weeks ago I have written a blog with the Title Domain-Specific Presentation is Component Visualization. The idea was to provide a domain-specific component visualization which is aware of the different types of components and their relations.

Since then I've asked myself if there isn't any UML-way to visualize domain-specific components. I know how this sounds like: UML is generic by its very nature but not domain-specific. But let's give it a try anyway.

Before starting I have have to explain one thing first: actifsource distinguish only between two types of relations: the own-relation and the use-relation. The own-relation defines a strong coupling. If A owns B, B must not exist without A. The use-relation on the other hand doesn't imply any life-time semantics.

As I explained in my blog Software Architecture and Components, domain-specific components are defined implicitly around the own-relations of their meta-model.

Looking at the UML Component Diagram we find out that relations between components are realized as delegation connectors which connects a port to an element of the component.

And now the interesting question: does every use-relation between components lead to a port?

To answer this question, lets have a look at the meta-model of a UML class. A class can be seen as a component as well, composing

a name attribute
member variables
member functions

Lets have a closer look at member variables which can express to different relations:

own relation
use relation

Unfortunately, using 3rd GL's the semantic isn't always that clear. Programming in C++ I use pointers to imply use-relations and references or value-objects to imply own-relations whenever possible.

Before continuing the discussion, let's have a look at member functions. Functions consist of named and typed arguments. The types are modeled as a use-relation to other existing types.

So, what is the difference between the use-relation of member-variables to other types and the use-relation of typed arguments of a member function?

The use-relations of member-variables define the permanent relations between components while the use-relations of typed arguments of a function definition simply simply define a temporary relation.

Obviously we have to distinguish between two different of use-relations:

use-relations which define permanent relations between components
use-relations which define temporary relations between components

For a valuable component relation overview we are interested only in permanent relations between components which leads to the following definition:

Permanent use-relations shall be shown as ports in a component diagram.

In my next blog I try to explain how composite structures shall be visualized using the UML Composite Structure Diagram combined with the idea of ports for permanent use-relations.

Be careful when using access modifier

2010-06-25T14:39:00.013+02:00

When working with frameworks provided by others, I sometimes get a little bit frustrated. Using the "normal" features provided by a framework in general is no problem. But when I have to access more information and go deeper into the code, I often find package-private and private modifiers protecting the code I like to reuse. Most often the problem is not at the method level, the method needed to call is public. In many cases even the constructor of the class is public, the problem begins with the arguments of the constructor or the method.

Oft one of the arguments is a class declared package-private or is public but has a package-private constructor. This forces me to search for a factory-method, which is often hidden deep by other such constructs. Meaning the code is strongly coupled to the framework.

Here is a small example:

I hate such code, especially if there is no special reason why the factory has a package-private constructor. Maybe there is an misunderstanding between information hiding and class design.

In cases where the code doesn't access any data from the framework there is no need to make the constructor package-private. It doesn't matter, if there is a second factory used by someone else. If you really need to have to use package-private, please make use of interfaces. This way it remains still possible to reuse the class by creating a new factory implementation:

I always wonder how the test code for such strong coupled code looks like. If you use interfaces unit testing is an easy task. You might use a mock framework like easymock. Using interfaces your class can be tested independent from the factory implementation and without creating an instance of the framework class.

For easier testing and better reusability, I suggest to use public-interfaces for a reasonable decoupling whenever possible.

Abolish the Mutants! .. or do we need Setable and Mapable Interfaces?

2010-06-24T11:37:00.005+02:00

No, this is not about a well-known film series. This is about software development! Forgive me for the lurid title :-)

Some weeks ago I was writing about an unexpected behaviour when you use Map.Entry objects in HashSets. The problem was emerging because the code assumed an object to be immutable that was not. More generally, we can ask: What elements can we put into a Set or use as the key of a Map?

In the javadoc to java.util.Map we find following warning:

Note: great care must be exercised if mutable objects are used as map
keys. The behavior of a map is not specified if the value of an object is
changed in a manner that affects equals comparisons while the
object is a key in the map.

Unfortunately, we usually do not immediately see wheter an object can be changed in such a way or not and therefore are clueless whether we are allowed to use it as the key of a mapping. We need to check the implementation of the class and possible sub-classes. If we are dealing with an interface we would have to check all implementations which is an impossible task as new implementations might be added in the future.

The inventors of the java collection library could have diminished this problem by introducing an interface Setable resp. Mapable which mark whether a class is designed for being put into a set resp. for being the key in a map. Map and Set could then allow only objects implementing these interfaces. However, these interface names are rather cumbersome and as they choose not to do this, we need to find another way of dealing with this issue.

Universum java est omnis divisa in partes tres

If we look at the universe of all java objects we can group them into three distinct sets:

Immutable objects
Entities
Neither 1 nor 2

Immutable objects are objects which never change their internal state. They are created fully-initialized, their hash code never changes and the equality relation formed by their equals method remains the same in their full livetime. They are perfect set members and hash keys!

Entities can change their internal state over time but they have a constant identity-giving property. Every java class which does not override equals and hashCode from java.lang.Object fullfills this requirement: It's identity is given by it's address in memory (which is only accessable to the jvm but nonetheless it is consistently defined). In other cases, the entity's identity is given by some id which might be a final long field or some special guid. The equals and hashCode methods must then be defined on this id only and not on any other fields. This makes entities suitable for sets and maps.

The remaining objects which are neither immutable nor entities can change their identity over time. I will therefore call them mutants for now. We should use them in sets and maps only if we can somehow guarantee that they will never mutate (change their identity) the entire time while they are used in the sets or maps!

Avoid Mutants!

Unfortunately, there are many mutants hiding in the java libraries:

java.util.List and all its implementations
java.util.Set and all its implementations
java.util.Map and all its implementations
java.util.BitSet
java.util.Date
...

So, what can you do if you want to use a list of elements safely as key to a map, for example?

public class Registry {

  private Map<List<String>, String> map = new HashMap<List<String>, String>();

  public void put(List<String> strings, String value) {

    // oops, unsafe! 

    map.put(strings, value);

}

}

The list of strings is a potential mutant!

   public void put(List<String> strings, String value) {

    //  oops, still unsafe! 

     map.put(Collections.unmodifiableList(strings), value);

}

Wrapping the mutant into an unmodifiable list will still not work as the caller of the method still has a reference to the list and can therefore modify it!

   public void put(List<String> strings, String value) {

     map.put(createImmutableCopy(strings), value);

}

  private List<String> createImmutableCopy(List<String> strings) {

    return Collections.unmodifiableList(new ArrayList<String>(strings)); 

}

We need to both copy the list and put it into a unmodifiable wrapper! Now we can guarantee that this list will never change again because there are no references to the wrapped ArrayList except by the Collections.UnmodifiableList wrapper which guards it from modifications. Note that we have this guarantee only because we know that the list is an direct result from our helper function. If we pass the list to some other method it will have to be treated as potential mutant there again...

As you see, mutants cause a lot of trouble and work to ensure they do not change their identity again. Therefore my demand is cleary: Do not write any mutant classes! By cleverly compositing immutable classes and entitiy classes you can always avoid the danger-bringing mutants.

Generating an internal DSL from an external DSL

2010-06-18T17:30:00.001+02:00

We have learned that when we create sound explicit intension revealing APIs the number of WTFs per minute is reduced and the programmer's developer life is a bit easier.

Further we can introduce a steep learning curve and make less faults due to accidental missusage of the API.

Making internal DSLs formulated in our general purpose programming language is one way to aproach this but writing an internal DSL is not an easy task and violates the KISS principle.

But since you want to make the life of our developers a bit easier and even more fun it makes sense to create such an internal DSL where the developer can declaratively describe what is needed from the API.


actualValue = ... // this value should be detected by the framework
Detector detector = actualValueFramework.bind(new DetectorModule {
 @Override
 public void configure(DetectorExpressionBuilder detector) {
  detector.detect()
   .withEvent().change()
   .andInterval().humanVisual()
   .andPersistency().disc();
 }
}).to(actualValue);

Listing 1

My prefered internal DSL style in Java is shown in listing 1 and is known as Method Chaining.

With code completion from the IDE this is very neat since the proposed possibilities from the completion express the further declaration steps. The developer can explore the API without any prior knowledge of its usage.

So this way I can achieve the goals mentioned above. Exploring is fun. Code completion while exploring makes it easy. Finding words from the problem domain makes it intension revealing.

But how can I make my own life easier and even more fun?

I have learned that the internal DSLs in Java can have a generic domain model, a meta-model. There is always a variation-point and its variations. Variations can be defined using polymorphism. A generic domain model must therefore give me the ability to express my API this way.

In the example above I have an Domain-Event that can be either Change, reach an Upper or Lower Limit. Then there is an interval that can be a millisecond, humanVisual oder oneMinute. The persistency can be disc or memory.

Event, interval and persistency are the variation-points where as change, upper, lower, millisecond, humanVisual, oneMinute, disc and memory are variations.

Using actifSource I created an external DSL that lets me express this variability in a generic domain model and write a code generator that generates ExpressionBuilders from the specific domain model.

Now it is no more hard to write such type of internal DSL where your specific domain model can be expressed in a declarative descriptive way.

How is it done using actifSource?

On the generic domain model class ExpressionBuilder is defined one property called operation and one called expression.

The property operation is from type Operation and expression is from type Class.

Operation is a NamedResource and here the operation name is used as a starting point of the expression. As in listing 1 the detector.detect() method. The Class contains a Class Instance having defined its own properties. Each property's Range is from an abstract class.

The Class is the variation-point where as the Class Instance is the variation.


public PersistencyExpression withPersistency(){
 return new PersistencyExpression();
}

Listing 2

The generator reads each property and defines a with-Method as shown in Listing 2 for
i.e. the Persistency variation-point.

Further the generator generates an ExpressionBuilder by looking up all instances of the type defined as Range on the property and creates methods.


public class PersistencyExpression{
 public AndProperties memory(){
  persistency = new Memory();
  return new AndProperties();
 }  
 public AndProperties disc(){
  persistency = new Disc();
  return new AndProperties();
 }  
}

Listing 3

The end declaration of the internal DSL expression is also generated as shown in listing 4.


public Detector build(){
 DetectorImpl build = new DetectorImpl();
 
 if(persistency!=null){
  build.setPersistency(persistency);
 }
 if(interval!=null){
  build.setInterval(interval);
 }
 if(range!=null){
  build.setRange(range);
 }
 if(event!=null){
  build.setEvent(event);
 }
 
 return build;
}

Listing 4


public class ActualValueFrameworkImpl ...
   public BindTo bind(final DetectorModule detectorModule) {
      return new BindTo(){

         @Override
         public Disposable to(final ActualValue actualValue) {
            DetectorExpressionBuilder detect = new DetectorExpressionBuilder();
            detectorModule.configure(detect);
            return detect.build();
   }
  };
 }
 ...
}

Listing 5

Now the framework method looks like listing 5.

If this is a proper usage of modeling or not... it does make my life easier an I can generate several internal DSLs using this aproach and have nothing else to do as to declaratively define it and press generate.

Happy modeling, Nils

Plugin Dependency Management outside Eclipse

2010-06-18T14:40:00.006+02:00

Today I searched for a solution to simplify using the actifsource ant task. Until now, all actifsource scopes (either an eclipse project or a bundle) have to be defined using a special actifsource ant-task, which takes a classpath. When making heavy usage of bundles, these classpaths can really become long and updating them by hand is not very convenient.

One idea I had to improve this is to define the plugin-directory directly and only point to the required bundles by their symbolic names. To do this we need to load the plugin outside of eclipse. The first place to start was to have a deeper look into equinox and see if there is a way to simply load all plugins and use them to load the required classes. At the moment we don't need to activate the bundles.

Sadly the equinox framework seems to strongly rely on some properties and requires the existence configuration files on the files ystem. Reusing the implementations like BaseAdaptor, Framework, HookRegistry and BaseStorage isn't really an option since they are strongly bound together. Some of the classes have only package private constructors, others have public constructors but taking one of the private classes as parameter. Time to search another solution. OSGi is an open standard and every implementation should be able to load the bundles.

The solution I found, was Apache Felix. It was said to be easy in setup and when I tried an example I was really glad to find out that this is true.

The following code allows me to load a bundle located in the plugin directory:

Felix felix = new Felix(Collections.emptyMap());
try {
felix.start();
} catch (BundleException e) {
e.printStackTrace();
return;
}
File bundleDir = new File("C:\\eclipseLocation\\plugins");
Bundle bundle = felix.getBundleContext().installBundle("locationId", new FileInputStream(new File(bundleDir, "bundle.jar")));

This is really short. Using this approach to load all bundles from the bundle-Directory would allow us to search for the bundles by their symbolic name and directly refer to them. No more classpath setup in every ant-file. Maybe we could also load some extension point definitions and and simplify the whole registration of generator tasks.

GWT And Data Persistence

2010-06-15T11:49:00.000+02:00

After trying out the tutorials from the Google Web Toolkit I created some small application where I needed to persist some data on the server. I was searching how to do this for quite some while so I thought it would be a nice idea to share what I found out about it. Basically, you can store data easily using Java Data Objects (JDO) but there are some things that you have to pay attention to.

JDO uses annotations to mark the fields and classes that are persistable:

@PersistenceCapable
public class Book extends Entity {

  @Persistent
  private java.lang.String title;
    
  @Persistent
  private java.lang.String iSBN;

  @Persistent
  private double price;
    
  @Persistent
  private java.lang.String description;

   // ...

}

When you are working with GWT you usually implement services on the Server. This is done by extending RemoteServiceServlet and implementing your service interface. That is the place where I wanted to persist the data which gets changed by service calls. To do this, you need a so-called PersistenceManager. I wrote a helper class which contains a singleton access to a PersistenceManagerFactory:

public final class PMF {

private static final PersistenceManagerFactory pmfInstance =
JDOHelper.getPersistenceManagerFactory("transactions-optional");

private PMF() {}

public static PersistenceManagerFactory get() {
return pmfInstance;
}

}

Now, creating a new book and making it persistent is as easy as this:

@Override
public Book createBook() {
    Book newBook = new Book();
    PersistenceManager pm = PMF.get().getPersistenceManager();
    try {
      pm.makePersistent(newBook);
    } finally {
      pm.close();
     }
    return newBook;
}

Access to existing data is done using JDOQL and not much harder:

public List getBooks() {
  PersistenceManager pm = PMF.get().getPersistenceManager();

  try {
    Query query = pm.newQuery(Book.class);
    List results = (List) query.execute();
    return new ArrayList(results);

  } finally {

    pm.close();

}
}

This gives a list of all existing books.

I got into problem when I tried to use iheritence with my JDO data classes. All my data classes inherit from the following class Entity:

@PersistenceCapable
@Inheritance(strategy = InheritanceStrategy.SUBCLASS_TABLE)
public abstract class Entity {

    @PrimaryKey
    @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
    private Long fKey;

    protected Entity() {
        this(null);
    }

    protected Entity(Long key) {
        fKey = key;
    }

    public long getKey() {
        return fKey;
    }

    @Override
    public int hashCode() {
        if (fKey == null) return 0;
        return fKey.hashCode();
    }

    @Override
    public boolean equals(Object obj) {
       // ...
    }

}

The important piece here is @Inheritance(strategy = InheritanceStrategy.SUBCLASS_TABLE). This defines how the objects are stored in the tables. As the default store strategy is not implemented by google it is very important to specify this explicitly!

If you want to use the data classes as arguments to the service call you need to give them a no-arg constructor (which is allowed to be private) and make sure that they inhert from IsSerializable:

/**
   * Creates a new {@link Book} with all fields set to default.
   */
public Book() {
    title = "";

    iSBN = "";

    price = 0.0;

    description = "";
  }

Implementing Apache Axis Webservices based on POJOs

2010-06-11T14:41:00.008+02:00

In my last post I came up with the idea of generating a Webservice using dataclass generated from an actifsource model.

Have you ever wrote a wsdl from scratch? If you are used to the wsdl-schema, it seams to be really easy, even for beginners. Later on when you write the server-side implementation, you will soon find out that you always have to look out for inconsistencies. When you are done and start implementing the client-side, this task become more difficult, it's the third place where to keep consistency.

This week I started to explore how to generate an Apache axis webservice (http://ws.apache.org/axis/) with actifsource. First I looked at the eclipse web tool platform project (wtp), for common users point of views, it seems to be really straight forward. If the server-side project and the environment is set up correctly, the service classes are updated on the fly via hot code replacement and there is also the possibility to run the tomcat webserver in debug mode. In debug mode you can use breakpoints the same way in every other jdt project. That's fine.

One big disadvantage I found, was the way how dependencies are managed. There is an additional entry for the j2ee-dependencies in the preferences. This means you have to be careful where to set the dependencies, because only dependencies defined here, are automatically uploaded to the webserver.

If your project is also an osgi-bundle, then these dependencies are ignored. This is a thing you have to take care about, but it not really is a problem, since the server-side implementation should be in it's own project anyway. So what was really annoying? The wtp toolkit changed all projects , I added to the j2ee-dependencies. Now, I had dependencies to the eclipse builder of the wst-project in all library-projects I referred to. As that wasn't enough, the classpath was modified, to include the Apache Tomcat 6 Libraries.

The result is that when we are looking at the dependencies we now have to deliver all the tomcat libraries. Each developer working with these libraries has to install the eclipse wst, otherwise he gets an eclipse problem marker and the project won't compile. The solution I found, was to create a jar-file for each library directly in the webservice project. This means I have to keep them up to date by myself and they are duplicate for each webservice using them.

The alternative to this is either to find another toolkit, which behaves different or to create an actifsource solution. The actifsource solution should be able to create the dataclasses, the server-side implementation with protected regions and the client implementation directly from the model. Both the server implementation and the client implementation should have the same service interface. To be independent from the underlying webservice framework it should use a generic ServiceException instead, i.e. an AxisFault. The server implementation should be automatically packed in a service archive (.aar/.war) together with the required libraries. At the end it would be fine, if it also offers the possibility for automatic uploading to the webservice.

For this task I reuse the templates for the genericapp dataclasses and modified the model from service tutorial to fit my needs. I searched for a possibility to auto-generate the wsdl from the server implementation. Reusing the implementations from the wst-plugins was a good option, but failed by lack of information and doesn't seem to be easy and may be impossible.

Looking at the apache axis website I saw that they already used axis v2 and that there is no need to provide the wsdl in the ".aar" webservice archive. There is no longer the need for a deploy.wsdd and undeploy.wsdd, instead one has to put an "services.xml" to the META-INF directory of the webarchive. This file is really simple, it only needs the service name and some default handlers:

Since I want to use the actifsource namespace, I also defined the package-namespace mapping and a generated wsdl. One pitfall was generating a custom wsdl; it must be located in the META-INF directory (not in the wsld-directory as in axis 1) and in wsdl2 format, otherwise it will be ignored. Creating the server-side implementation including the templates costs me about four days. But not for writing the templates and the actifsource model. I spent most of the time reading documentation and discovering how the thing work in axis2. Thinking back, how to define the namespace-mapping and why my custom wsdl was ignored, was the hardest thing. Tcpmon was a really good helper. So basically, the main time I spent in learning how axis2 works.

The client implementation was much easier and compared to axis 1 which generates four classes for the implementation, in axis 2 there is only one implementation class needed and the interface definition can be shared between server and client.

Now after a week of work, I have a working generic app which has two part. A dataclass project, which defines the metamodel for the dataclasses and the service interfaces. And an axis-service-project to generate the axis-client and server implementation. Here is an example how the project dependencies in a simple setup will look like.

Note that the only actifsource model the user has to create is the dataclass. I think it is a good idea to provide a project generation buildconfig, which allows the creation of the target projects for client, server and dataclasses including an initial setup.

Casting in Java Leads to DRY Violations

2010-06-11T14:35:00.001+02:00

The Don't Repeat Yourself principle states that you should not have any duplication in your code. Code duplication makes the code harder to maintain. In Java, one finds often code like this:

  String extractValue(IType parameter) {

    if (parameter instanceof ILiteralType) {

      ILiteralType literalType = (ILiteralType)parameter;
      return literlType.getValue();     
    }
    return null;

}

Of course, it is best to avoid casting completely. However, in some cases this is not possible. When casting, the code must first check if an object is an instance of the desired type using the instanceof operator. If the test succeeds, the object can be casted to the type. The problem is that you have to specify the type twice which is a repetition and therefore violates DRY. Whenever you change the type in the instanceof expression you need to change the cast in sync. Failing to do so will result in an error that occurs only at run time.

One can circumvent this problem by using a little static helper function (we have put it in a class named ObjectUtil):

public static T castOrNull(Object o, Class clazz) {
if (!clazz.isInstance(o)) return null;
return clazz.cast(o);
}

With the help of this function the code above becomes:

  String extractValue(IType parameter) { 

    ILiteralType literalType =
          ObjectUtil.castOrNull(parameter, ILiteralType.class);
    if (literaType == null) {
      return null;
    }

    return literalType.getValue();

}

Now, the type is specified only once as argument to the castOrNull method.

(The attentive reader will object that ILiteralType is still specified twice, once as argument to castOrNull and once when defining the variable literalType. So effectively, we have only two occurrences instead of three in the original code. However, an inconsistency of the two remaining occurrences will be detected by the compiler and is therefore far fewer problematic!)

Domain-Specific Presentation is Component Visualization

2010-06-08T18:14:00.003+02:00

Some time ago I was asked if actifsource provides a domain-specific presentation of domain-models. I had to answer this question with no. But what's the problem with a domain-specific presentation?

As I stated in this blog before, components are the building blocks of architecture. A component (derived from latin "componens") is something that is composed of different parts by its very nature.

Using different UML classes to visualize components is kind of silly, because the single parts of a component are structured hierarchically. This means, that visualizing component instances of the same type is given by concept.

But how to specify a component visualization concept? The problem is to cope with the multiplicity of relations between the component parts. Being able to visualize a to-many relation r between to elements A and B means that the visualization concept has to cope with any number of B instances aggregated in A.

To implement a generic graphical editor where you can design a component visualization concept which handles the presentation of to-many relation is quite a challenge.

I will try to sketch a possible solution in one of my next blogs.

If a bug exists long enough it becomes a feature..

2010-06-07T11:28:00.000+02:00

Consider the following code which uses a java.util.TreeSet:

1 TreeSet set = new TreeSet();

2 set.add(null);

3 set.remove(null);

Does it work? Does it throw a NullPointerException? If we look at the javadoc of the TreeSet.add method we read:

* @throws NullPointerException if the specified element is null
* and this set uses natural ordering, or its comparator
* does not permit null elements

As we create the TreeSet using the default constructor it uses the natural ordering and we would expect a NullPointerException on line 2. However, the NullPointerException happens only on line 3. Even though this is a clear bug which got reported already for java 1.3 (issue 5045147) it is still present in Java 6. Sun decided that there is too much code that would break if they fixed the bug that adding null to an empty TreeSet is allowed. One might ask what quality such code has..

Set-Operations

2010-06-04T16:09:00.016+02:00

When writing templates it's sometime useful to merge the result of two or more selector expressions and iterate of it. In the older versions there was only one possibility to achieve this, writing your own Java template function. With the new version of actifsource we added three keywords to the selector line syntax. Since the selector line doesn't contain any source code, we don't break the rule of avoiding to mixture of source code and template code.

The three keywords are "union", "intersect", "except". All three are binary operations operating on lists. Additional to the keywords we allow to use round brackets for changing the evaluation order.

The union keyword

The union keywords merges the result of two selector expressions (m1 union m2) by creating a new list containing all elements of m1 and m2. Since we operate on lists this will preserve the order and allows for duplicate elements. As a result we get one big list first containing all element of the result from m1 followed by all element of the result from m2.

For example [1, 2, 3, 5, 4] union [2, 4, 3] will result in [1, 2, 3, 5, 4, 2, 4, 3].

The intersect keyword

The intersect keyword merges the result of two selector (m1 intersect m2) so that all occurrences of an element in m1 that exceed the occurrence of that element in m2 are removed from m1. This keeps the order as in m1 except for the elements removed.

For example [1, 2, 3, 5, 2] intersect [1, 3, 3, 2] will result in [1, 2, 3].

The except keyword

The except keywords merges the result of two selector expressions (m1 except m2) by removing all element of m2 from the result of m1. Since we operate on lists this will preserve the order and elements contained multiple times in the result of m1 will only removed as often they are contained in m2.

For example [1, 2, 3, 5, 2, 4] except [2, 4, 6, 3] will result in [1, 5, 2].

For what can it be used?

When traversing the hierarchy or collecting referenced objects it's often recommended to exclude the own element.

As an example I built a simple model with persons. All person can have friends. If you want to collect the friends of all friends, except the person itself and the friends that are known directly, you can use the following expression:

Or you can collect all friends and include person itself:

With the set operation there are much less situations where you have to write template functions, which makes writing templates much faster and easier.

Software Modernization through Componentization

2010-06-03T10:14:00.003+02:00

As David L. Parnas in his article Software Aging stated:

Programs, like people, get old. We can't prevent aging, but we can understand its causes, take steps to limit its effects, temporarily reverse some of the damage it has caused, and prepare for the day when the Software is no longer viable.

But how to cope with a legacy system? Is it even possible to renovate such a legacy system and if so, how?

Legacy System are hard to maintain because the systems structure tends to degrade over the years. Furthermore, legacy systems support functions as the structuring element. Today, systems are structured along components which contain functions.

So what's the idea behind Software Modernization through Componentization? The idea is to analyze existing functions of your legacy system and group them together to components. This task is called Componentization.

After the Componentization you need to analyze the worked out components. Are there any similarities in the component structures and the relationship between components? Any findings of this component analysis process will help you to define the formal component concept.

Once found an adequate formal component concept of your legacy system, you are able to manage your components. Doing so allows you to generate component interfaces.

These component interfaces allow you to define clear relations between components. They also make it easy to setup new functionality as managing components through a web gui (web enbaling) or providing access through services (SOA enabling).

The Java Collection Framework and Immutability

2010-05-31T16:50:00.015+02:00

... or a story of things that can change unexpectedly

Have a look at following implementation. Does it what it claims to do?

/**
   * Selects and returns those entries of the map whose keys are even.
   * @return a set of all entries in the map with even keys
   */
public static Set<Entry<Integer, String>> extractEvenKeys(Map<Integer, String> map) {
    Set<Entry<Integer, String>> result = new HashSet<Entry<Integer, String>>();

    for(Entry<Integer, String> entry: map.entrySet()) {
      if (isEven(entry.getKey())) {
        result.add(entry);
      }
    }

    return result;
}

private static boolean isEven(int number) {
    return (number & 1) == 0;
}

The code iterates over all entries of the map and puts the entries into a result set. Does it always work? Let's test it:

public static void test() {
    Map<Integer, String> map = new HashMap<Integer, String>();
    for(int i=0; i<10; ++i) {
      map.put(i, String.valueOf(i));
    }
    Set<Entry<Integer, String>> even = extractEvenKeys(map);
    System.out.println(even.size());
    for(Entry<Integer,String> entry: even) {
      System.out.print("["+entry.getKey()+","+entry.getValue()+"] ");
    }
}

This gives the following output:
[14,14] [12,12] [8,8] [6,6] [4,4] [2,2] [0,0] [10,10] [18,18] [16,16]

We get all ten entries with even keys so the output is correct. The entries have no particular ordering but we did not say anything about this so this is okay. We used a java.util.HashMap for the test but this should work with every correct implementation of the java.util.Map interface, right? So let's try some other maps:

java.util.LinkedHashMap:
[14,14] [12,12] [8,8] [6,6] [4,4] [2,2] [0,0] [10,10] [18,18] [16,16]

java.util.TreeMap:

  [14,14] [12,12] [8,8] [6,6] [4,4] [2,2] [0,0] [10,10] [18,18] [16,16]

java.util.concurrent.ConcurrentHashMap:

  [4,4] [14,14] [2,2] [8,8] [0,0] [6,6] [12,12] [10,10] [16,16] [18,18] 

java.util.IdentityHashMap:

[9,9] [9,9] [9,9] [9,9] [9,9] [9,9] [9,9] [9,9] [9,9] [9,9]

Oops! Something went terribly wrong with the IdentityHashMap! We got a Set that contains ten times the same entry, and it is actually an entry with an odd key! Is the implementation of java.util.HashSet wrong? After all, a set should never contain an element more than once! Or do we have do blame something else?

What went wrong?

Well, as it turns out, we trapped into a documentation hole of the Java Collection Framework. If we look at the Entry interface contained in java.util.Map we see a comment that these Entry objects are only valid as long as the map remains unmodified. What is missing, however, is a documentation how the entry objects can change over time:

Are Entry objects immutable? No, they have a setValue method so they cannot be.
Do Entry objects remain unchanged as long the Map they belong to remains unchanged? We could think so, but unfortunatley not.
Does Entry.getKey() change while iterating over the entries? Unfortunately, not even this is specified, so an implementation is free to choose!

As it turns out, when iterating over the entries of an IdentityHashMap, the same entry object is always returned on Iterator.next(), just the getKey() and getValue() returns a different key and value for each iteration. This also means that equals() and hashCode() of the entry object change and the disaster is complete when we try to put the entries into a HashSet: We end up with a set that has ten times the same entry object (remember the same object is returned for each iteration) and after iterating, the key and value of the entry are those of the last iteration!

All this happend because we misleadingly assumed that the entries' keys would not change. There is a bug report which complains about the behaviour of the IdentityHashMap's entry set. Note that there is the same issue with java.util.EnumMap.

Let's fix it

We cannot change the contract of the interface. So, we have to work around in our implementation. To make our code work with all implementations of java.util.Map we have to drop the assumption of immutable entry keys and create new Entry objects for the result set:

public static Set<Entry<Integer,String>> extractEvenKeys(Map map) {

     Set<Entry<Integer,String>> result 
            = new HashSet <Entry<Integer,String>>();

    for(Entry<Integer,String> entry: map.entrySet()) {

      if (isEven(entry.getKey())) {

        result.add(new ImmutableEntry<Integer,String>(
            entry.getKey(), entry.getValue()));

}

}

    return result;

}

whereas we need a custom implementation of Map.Entry which we now clearly mark as immutable:

@Immutable
public class ImmutableEntry implements Map.Entry<K,V&gt {

    private final K key;
    private final V value;

    public ImmutableEntry(K key, V value) {
      this.key = key;
      this.value = value;
    }

    @Override
    public K getKey() {
      return key;
    }

    @Override
    public V getValue() {
      return value;
    }

    @Override
    public V setValue(V value) {
      throw new UnsupportedOperationException();
    }

    @Override
    public int hashCode() {
      return ((key == null) ? 0 : key.hashCode()) ^
             ((value == null) ? 0 : value.hashCode());
    }

    @Override
    public boolean equals(Object obj) {
      if (this == obj) return true;
      if (!(obj instanceof Map.Entry<?,?>)) return false;
      Map.Entry<?,?> other = (Map.Entry<?,?>)obj;
      if (key == null) {
        if (other.getKey() != null) return false;
      } else if (!key.equals(other.getKey())) return false;
      if (value == null) {
        if (other.getValue() != null) return false;
      } else if (!value.equals(other.getValue())) return false;
      return true;
    }

}

Note that I took care to fullfill the contract of the equals and hashcode methods as specified in Map.Entry.

A final remark

The hashCode method of the entry takes the XOR of the key's and value's hashcode (as required by the documentation of the interface). This can have some serious side effect too: If you -- for whatever reason -- put entries into a map with equal key and value, this means that all these entries will have hashcode zero! Putting these entries into a HashSet will kill your performance as the map degrades to a linked list due to the collisions!

Generic Applications

2010-05-28T13:34:00.015+02:00

This week I started to implement a new actifsource feature. A repository for generic actifsource applications. The idea behind this is to provide an easy way to distribute models, frameworks and templates solving common tasks. We decided to provide a special import wizard, which downloads and installs the application. One challenge was to manage the installation of required features and plugins. Our applications may require findbugs or other third party tools.

To solve this issue I decided to manage the information about the features and the updateSiteURIs along which some other information in the repository. This way the wizard can check the current feature list, add missing updateSites und the required dependencies. Since svn does a good job in managing source code, I decided to use the eclipse team project set to manage the download and import of the projects into the workspace.

Since we need a way to define and store additional dependency information, I defined a small actifsource model. One big advantage over using a textfile are the resource formfieldeditor and the actifsource validation, which shows you where the application definition is incomplete.

After this I had to think about from where the generic app import will obtain the data. I decided to implement this as a service. If the service is encapsulated properly the importer doesn't have to care about where the information comes from. Both service data classes, the service interface and the service implementation stub can be generated by actifsource templates. It is also possible to write the wsdl. I first started using the eclipse j2ee wizards, but very soon I found out that it is not very convenient doing the updates by hand. I'm sure this is a good case for a generic application.

Providing templates for building simple java beans (value objects) out of the class defined in actifsource, would be easy. I talked about this in my last post. Using a similar model as shown in the Simple Service Tutorial combined with an enhanced version of the DataClass-Templates will do the job:

The actifsource class

The new template

The generated java bean for the use for data transfer

As you can see we often need some kind of data classes in a specific format. It's also possible to generate the service calls and everything else including the setup code of the service client and server. I think this would be really a useful application for the actifsource generic application store, generating the transfer classes for your simple model. I say simple model, because if you have a more complex environment, you probably won't have a 1:1 relationship between your model classes and the data classes. In this case you will most likely write your own templates doing the transformation/mapping between model and code.

Grouping Is Domain Specific Too

2010-05-27T17:29:00.003+02:00

Complex domains have large models...

As an advanced user of domain-driven modeling you may have experienced that you find yourself soon dealing with a huge set of domain-specific elements: A description of a complex domain can need hundreds of elements. Having all these elements as a flat list is no longer convenient. Fortunately, actifsource lets you group your elements -- which are simply called Resources in actifsource -- into so-called Packages (similar to Java packages).

Packages enable a simple hierarchical structuring and are currently the all-embracing grouping element:

A Package can contain Resources
A Package can contain nested Packages

In the domain meta-model we use Packages to group our Classes. Packages do a perfect job there. However, when the task is to group the domain elements themselves, we found that packages have a problem: The are not domain-specific! Instead of Packages, it would be desirable to have domain-specific grouping elements... 'FunctionalAreas', 'Epics', 'EntitySpaces' are possible names. But this name is always specific to the domain so we cannot choose it universally!

... and need to be grouped domain-specifically!

So, after some discussion, we came to the following idea to solve the problems mentioned above: We need to have a way to define grouping elements on the domain meta-level! All the grouping concepts have something in common:

A grouping element can contain nested grouping elements of some grouping types
A grouping element can define dependencies to other grouping elements

Inside Eclipse, the groupings would still be displayed as folders containing elements. But you could fully customise the folders (icons, decorations, ..). Further, the folder would be validated to contain only the correct element types and the dependencies could be used to narrow the scope of references: Resources contained in a grouping are only allowed to have references to other Resources which are in the scope defined by the dependencies on the grouping!

So, the current concept of Packages containing Classes would be only a realization of the more general grouping concept!

Generating for multiple layers

2010-05-21T09:42:00.014+02:00

You often need the same structures in different places. You have a data-layer where you need data classes to hold the data, you need a network layer for transportation and you also might have a GUI to display your data. Depending on what you do, you may need to decorate the data with additional information or change its representation. One problem with this is that a new feature must be implemented on all layers to fully support it. With actifsource you can make sure that a feature is handled on all layers and no task gets forgotten. Simply create templates for each layer. Today I want to give you a small example how actifsource can help.

Lets look at the data layer. I generate really simple data classes, they have a getter, setter and field for the value/reference. For this example I don't care about change notification or null checking:

As an example I defined a data class Person in actifsource:

The template that generates the java class using some helper functions "toJavaType" to translate the actifsource types to java:

For the second layer I generate a simple viewer for each data structure. There is no need to define additional information in the model, I just use the same data. For simplicity I don't care about the type of the properties and create a text field for each one. In a real world example you might create components instead of frames and create specific controls for each attribute/relation type.

The following two screenshots show the viewer template and the output for person:

In the viewer template I also added a main-method and the createExampleValue-method with a protected region to create an example value to display. The running example looks like this:

Now I have two layers that will updated every time when I change the model. It is ensured that there is always both a text field in the view and a data field in the data class. Think about a third layer: a network layer with the serialization code is stored or different output format implementations. You even might have implementations or clients/servers in different programming languages (c++, c#, java). In all cases actifsource takes care about consistency, no more trouble due to missing fields or different order in the serialization/deserialization code between the different implementations.

Generating HashMaps for Primitives

2010-05-20T15:44:00.002+02:00

Since long, I have wondered whether it would make a big difference in Java if you use a custom hash map implementation for primitives instead of using e.g. java.util.HashMap with boxed values. However, as there are 7 primitives (byte, char, short, int, long, float, double) this would mean that there are potentially 49 hash map implementations to be written.

In the process of testing the upcoming release of actifsource, I used actifsource templates to generate the implementations so that I had to write a single generic implementation only (similar to a c++ or c# template). While not being a typical use case for model- or domain-driven engineering (the model is trivial, the domain is pure technical) it was an interesing test. Unlike the HashMap form java.util, my generated versions store directly primitives instead of boxed objects. I was particular curious what impact this had on the memory footprint and the performance.

The Model

As I did not want to measure difference in the hashing algorithm I started with the HashMap implementation. This meant copy and pasting the code of java.util.HashMap into an empty template. But first, I created this simple model:
A hash map has a key type and a value type which is an enum of the primitive types. For compatibility with the maps from Java i generated an interface which is similar to these maps, just with primitves in the method signature:

Next, in the implementation, I replaced all reference to the generic types K and V by the type from the hash map class, i.e. the expression HashMap.valuetype.name and HashMap.keytype.name. The other thing that I had to change was the handling of null keys and values. As primitives cannot be null the code for handling null could be removed. This also means, that the value 0 gets returned instead of null when a get is made for an non-existing key. Compare the implementations from java.util.HashMap with the implementation in the actifsource template:

The algorithm itself remained the same. To calculate the hash value I could no longer relay on Object.hashCode() as the primitives are no objects. Instead, I created a utility class HashUtil which contains an overloaded function hashCode for each primitive type.

Performance Results

To benchmark the implementation, I filled a map int -> float with 1'000'000 random key/value pairs (put), replaced the value for all the keys once (update), asked once for each key (get) and finally removed all keys (remove). This was repeated 15 times with the first 5 repetitions used as warm-up and taking the average timing over the remaining 10 repetitions. All figures are in milliseconds. I also measured the size of the memory retained by the maps.

Java HashMap:

put 793
update 428
get 409
remove 432

retained size: 108MB (113bytes per entry)

Generated Int2FloatHashMap:

put 352
update 175
get 87
remove 174

retained size: 54.1MB (56.7bytes per entry)

As you can see the generated hash map performed notably better with the get being more than 4 times faster in average! Also, only half as much memory is used.

Software Architecture and Components

2010-05-18T16:30:00.007+02:00

Len Bass defines Software Architecture as follows:

Len Bass: Software Architecture in Practice (2003)

The Software architecture of a program or computing System is the structure or structures of the System, which comprise Software components, the externally visible properties of those components and the relationships among them.

Does this help? Maybe... The above definition tells us, that the architecture of a software system comprises components. Obviously the next question is: what are components?

The word component itself is derived from the latin word componens which means something that is composed of several parts. But composed of what parts?

Using object-oriented technologies it seems obvious that components implement a specific interface. So far so good. But what about building a component? Is there a building plan or a specification to see how to create a new component?

In our opinion, the structure of a component is something domain specific. Usually, a complex software system consists of several different component types. A Service Oriented Architecture may specify components of type Service and components of type BusinessObject and the relationship between these components.

No matter how many Services or BusinessObjects our system will be built of, the conceptual component architecture shows us how components are structured and interconnected.

As you can imagine, building up new components is following specific rules. Since components are spread over several tiers in complex software systems, we do have to implement several aspects per component: GUI, persistency, business logic, etc.

Imagine a system where you could define your conceptual component architecture. And imagine a system, where you could specify specific components according the conceptual component architecture.

actifsource allows you to specify your domain-specific conceptual component architecture. Doing so, specific components may be entered along your concept.

Every element is fully type checked at real time. And of source there is a type-sensitive content assist.

But the most thrilling thing comes now: Since we know exactly how a component is structured, we can provide generic code to build up any specific component.

Due to our specification a Service always comprises ServiceCalls, while a ServiceCall comprises Parameters. Knowing these conceptual facts, we can write a class for every Service, which contains a method for every ServiceCall.

But instead of writing a method for every ServiceCall manually we let our computer do the tedious work.

The next picture shows the actifsource template editor. The orange bar on the left hand side indicates the repetition for every specific ServiceCall.

Conclusion
A software system consist of components. Defining the conceptual structure of these components and their relationship allows us to enter well defined and specific components. These component might be checked among their concept.

Since components are well defined, generic code might be written only once for every component type.

Limitations
Note that the above is only true for the structural aspects of a component. Specific algorithms have to be still coded manually. But 3rd GL like Java, C++, etc. are doing a great job for this kind of work.

In our experience, a complex software system contains up to 70% of structural component code which can be generated.

Feature Code, Infrastructure Code and Refactoring

2010-05-11T09:40:00.006+02:00

Designing a complex software system means beeing prepared for implementing new features over time. For this reason, the software architecture should describe, how to implement new features.

The conceptual part of a software architecture contains instructions how to setup the infrastructure code needed to embedded feature code into your existing software.

Facts on infrastructure code:

Built along a concept
Mostly created by copy/paste/modify of similar infrastructure code
70% of a complex software system is infrastructure code
Refactoring of a software system means adopting infrastructure code

Refactoring of a software means changing the structure of the system without changing it's functional behavior.

Wikipedia defines refactoring as follows:

Code refactoring is the process of changing a computer program's source code without modifying its external functional behavior in order to improve some of the nonfunctional attributes of the software. Advantages include improved code readability and reduced complexity to improve the maintainability of the source code, as well as a more expressive internal architecture or object model to improve extensibility.

-- http://en.wikipedia.org/wiki/Refactoring

A refactoring just improves the structures of your software system.

Because a refactoring does not change the functional behavior, a refactoring does never add business value to a software system.

A refactoring affects infrastructure code, as we stated before.

Generating the infrastructure code makes it possible to automate the refactoring of a complex software system.

Actifsource allows you to formalize the conceptual parts of your software architecture and generate all infrastructure code. This allows to generate up to 70% of a complex software system. It allows also to refactor the generated infrastructure code of your software system automatically.

Stop writing infrastructure code - focus on feature code.

Generating Wizard Classes

2010-05-07T11:07:00.011+02:00

Today I give you a short insight into the wizard template. I don’t want to show every detail, but you should see what’s possible. For this blog I assume you already tried our tutorials and you know how to create and register a template.

Let’s build a simple WizardTemplate, to generate the main class for each wizard.

As you can see this empty template has an error at the filename line. This indicates that we have to define a filename otherwise we won’t get any output.
On the filename we put the WizardClass-Instance-Package and the Name. Since packages are separated by a dot, I used the builtin function “package2subdirectory” to replace the dots by slashes.

Now let’s generate the signature. Each wizard class should derive from a GeneratedWizard class, which contains non generated methods use by all wizards. I also added a wizardInterface–method to get the eclipse Wizard-Interface (INewWizard, IImportWizard, IExportWizard) from the model.

This will generate a class for each wizard having the wizards name, extends the class GeneratedWizard and implements a specific Wizard-Interface. At the moment this won’t compile, since there is implementation of the abstract methods. Let’s add some more code.
Pressing “ALT+Insert” allows me to add a new linecontext. I want to have a field for each wizardpage, I added a selector to iterate overall pages of the current wizard:

If you ever wrote a wizard, you know pages are registered by the addPages-Method. The generator should create it and add a line for each wizard page. Since there might some setup code to create the pages, I want a creation method for each page:

For the creation method I add a third context iterating over the pages. Using separate contexts I keep all fields and creation methods together. You might choice another way to group the methods based on your companies coding guidelines:

I added a protected contexts for the constructor call, so it's possible to change the generated code to pass additional parameters later. The code in the resulting protected region won't be touched by future generator runs. Finally I added a add-Method to register the page:

Look at the reference to the wizard field, it's the same text. To see that the fieldName is ment, I extract a function using the quick assist (Ctrl+1):

Via copy paste I replaced all other occurencies:

Using more information from the model, I get some thing like this:

As you can see the template is still readable and there are nothing special with one exception, our links to the model. No for-each loops and template keywords between the code.

The same can be done for each wizard page:

The fieldeditor are registered automatically, so you don't have to write the fields, initialize them and finally create each fieldeditor. The logic for creating the GUI-Controls is in the GeneratedWizardPage-SuperClass, it just call the createControl-method on each registed fieldeditor when eclipse request the page control creation.
You might have discovered the line calling the "depencencySetterName", this line creates the binding between the fieldeditors. As I mentioned in the last blogs the binding is used for the package-fieldeditor to only show the packages in resourcefolder selected by the resourcefolder-fieldeditor. This is really smart, you cannot forget to set the bindings, since the model forces you to do define them and the generator does the rest.

I hope this short insight into the templates help you to understand how actifsource can improve your work.

Conceptual and Non-Conceptual Parts of Software-Architecture

2010-05-05T11:08:00.007+02:00

What is Software-Architecture? Do you have a widely accepted definition? Aksing 10 different people for a definition, you might get 12 different answers.

In my opinion, Software Architecture can be described as followed:

The software architecture is a directive for the effective and efficient building, understanding and expanding of a software system.

-- Reto Carrara

Ok, that's nothing new so far. So let's talk on the nature of an architecture. A software architecture is a directive or kind of a building plan for a software system. There will be decisions on the choosen n-tier model or the third party libs we plan to use. All this information can be implemented 1:1 in code and is therefore non-conceptual!

But a software architecture describes also, how features of a domain shall be implemented. This kind of information is conceptual!

Defining a Service Oriented Architecture for example, you can be sure, there is a concept in your architecture, how to define new Services. Specifying a Architecture for Complex Event Processing there will be EventHandlers, Events and EventSources.

This conceptual information is one of the most important of our architecture. It tells the developers how to embed new features in the existing structure of the software system.

The concept how to embed new features in your software helps also, to understand the structure of a complex software systems in the maintenance phase.

Having a concept how to build new features for a complex software system is most important. Only a system that is built on a clear concept can be understood and maintained over time.

So, what's the problem?

If one thing is certain in our job: things change - always! Even your basic requirements are subject to change, if your market asks for it.

One of the most basic and most important requirements is therefore:

Software Requirement 1:
Design for Requirements Change!

As we have seen: implementing concepts is most important to read and understand our code later on.

But there is a crux:

Concepts that are implemented many times by their very nature. But concepts that are implemented many times are very hard to change, because every implementation has to be adapted.

So, we need to have concepts to understand the structure of our software system. But implementing concepts prevent us from changing them. Seems to be an unsolvable problem!

Not so, if we implement all concepts automatically by generating the code needed.

actifsource allows you to formalize the conceptual parts of your software architecture to generate the structural feature code. Doing so, concept changes can be done easily just by regenerating existing implementations.

In our experience, structural feature code is about 60-70% of the code of a complex software system.

Imagine to focus on features, not structural code.

New Wizards needed more details - The model

2010-04-30T08:05:00.031+02:00

Last week I talked a little bit about generating wizards with actifsource. I further talked about the model and what things the actifsource code generator will do for you. This week I want to go in some more details and tell you how I started using a Code Generator for implementing the wizards.

The idea of generating the wizards came up, when Micha had to create new wizards and looked into the other implementations to see how the wizard pages where built there. Since all the wizards where completely handwritten, there was nothing but the coding conventions that restricted us in implementing them. As a result, each wizard does its job a little bit different.

How is this possible? If you think about your own code you will find out quickly, that if you have to implement the same stuff a half year later or give it to a colleague, it will result in slightly different code. A reason for that is, that writing code always depends on the experience of the developer, which grows over the years. It comes the time where code style and coding conventions will be changed, but no one will go through the old code to update.

What can we do against this? One thing is discipline in following company guidelines. But who really remembers all the rules? Some rules are not even written down in a document. Here is where actifsource templates can help. A template defines the structure and limits needed to ensure that things look the same way and ensure that changes will be made in all implementation at the same time.

Okay, let's start. We have the code mess, we want to get rid of. First, you have to find a meta-model, that is common for all wizards, but still different when writing the wizard classes. All wizards have a title, a description and pages. The title and description is always set in the constructor. Each page must be accessible by the finish-method, thus we need to declare a field of the concrete type for each wizard page. These are things normally done by hand. The information will be stored in the model and the translation of the code structure in the templates.

After collecting the information, I started creating a new actifsource resource folder in the existing wizard project and creates an actifsource class named "Wizard":

The second class I needed was the "WizardPage":

The wizard page, again has a title, a description and an inputfield. The inputfield are the different control to be filled out by the user. There are some more classes but I think you can see where this goes. I don't define the field and methods to be generated in the model, I created a simple description of a wizard.

The data for each wizard is also stored in the model, for this I created a model instance of the wizard class:

As you can see this is a really minimalistic model. That is one of the benefits of using actifsource, the model can change over the time as needed. Actifsource supports iterative and incremential development.

By the way setting of the dependency between the resourcefolder and packagename is forced by a decorating property. If you are interested how they work, checkout our State Machine Tutorial.

The next time I will tell you about how the GUI code is generated by using actifsource templates.

Mapping from Ecore to the Actifsource Core - Part 2

2010-04-29T14:53:00.004+02:00

Last week, I wrote about the similarities of ecore and the actifsource core. This time, I want to tell you about the differences and why they exist.

Elements Missing in Actifsource

Some things that are present in ecore do not have a correspondence in the actifsource core:

Operations
Information which is used only for the serialization of data: volatile, transient, id, resolveProxies, instanceClassName
Factories
Annotations
Derived References and Attributes

Why were these things left out in the actifsource core? You will understand this when we look at the purposes of the two meta-models. Quoting from the EMF homepage:

"EMF provides tools and runtime support to produce a set of Java classes for the model, a set of adapter classes that enable viewing and command-based editing of the model, and a basic editor."

So, an ecore model must hold all information to generate a set of java classes which allow reading and writing the model including notifications and serialization. In actifsource however, you model your domain using domain classes. These domain classes do not directly map to Java classes for editing and serializing the model! Instead, instantiation and editing of your model is done in actifsource itself using the Resource Editor. Therefore, we do not want any information for mapping to a Java representation in the core itself!

If you want to map your domain classes to Java (or C, C++, Ruby, Scala..) you make use of Generic Code Templates. Like that, you have full control about every single character of the generated code! This explains why there is no need to have Operations, Factories and mapping information in the actifsource core model.

Annotations

Annotations are a way to attach additional information to any ecore element. There is currently no such thing in actifsource. However, it is possible to create an extension of the actifsource core model and define so-called Decorators which add additional information to the elements (actually, any model, not just the core can be extended in this way!). This has the advantage that the for additional information a meta-model can be defined such that they are fully typed as well. Ecore annotations on the other hand are just maps with key-value pairs of strings.

Derived Attibutes and References

Derived features do not add more information to the model but calculate something based on the ordinary attributes and references. For example, the eAllAtributes Reference collects all attributes on a class inculding those defined on its super-classes. Such funtionallity does not really describe the structure of the model but are just helpers. Actifsource has a similar concept: Functions. However, these functions are only used when writing code templates. They allow you to define and use what would be a derived feature in ecore for the purpose of code generation. Each function is associated to a function space which is usually the template. Like that, these functions do not clutter the domain model.

Additional Elements in Actifsource

Some elment of actifsource cannot be mapped to anything in ecore:

Aspects

Some elements of actifsource can implement a so-called Aspect. Each aspect has an interface which defines its purpose. Aspects allow to associate elements with functionality (usually implemented as Java class) which is needed for displaying, validating or editing models. For example, there are aspects which further restrict the range of a Relation, validate additinal contraints or add entries to the content-assist in the resource editor.

Sub-Relations

Sub-relations restrict a relation which is defined in a base class. Instances of the sub-class can then only realise the restricted association. Surprisingly, you can find such a constellation in the ecore model:

ETypedElement has the relation eType with target EClassifier
EAttribute inherits the eType relation
EAttribute has the (derived) relation eAttributeType with target EDataType

Now, the eType of an EAttribute should never map to something that is not an EDataType! This means that the eAttributeType relation is actually a sub-relation of eType! Sadly, this information is missing in ecore!

Decocrating Relations

Deocrating relations can be used to define Homomorphisms in your model. I might write about this another time. If you do not want to wait, check out the Statemachine Tutorial where you can find an example of a decorating relation.

On Symbolic Integration

2010-04-27T09:15:00.011+02:00

Writing Code in a GPL (General Purpose Language), elements are referenced by name. Say we do have a Class UserService. If I'd like to instantiate an Object of type UserService, I have to write something like:

UserService userService = new UserService();

Renaming the Class UserService enforces me to rename:

All references in the code
All comment where UserService occurs
UML Diagrams
User Documentation
SW Architecture
...

As Martin Fowler states in his groundbreaking Article Language Workbenches: The Killer-App for Domain Specific Languages?:

"The second big plus of a language workbench is that you get symbolic integration. The ability to take an excel-like formula language, and just plug it into your own specialized language is pretty nifty. As is the ability to change symbols in one language and have those changes ripple through the whole system, which is a plausible thing to consider with a language workbench (I'm not sure if any of them can do that yet.)"

-- Martin Fowler

Starting actifsource 5 years ago, we agreed that names can be changed anytime. This tasks becomes even more complex if you want to change names on a conceptual level. Imagine to build up a Service Infrastructure. It seems obvious that our Software Architecture describes how to implement Services.

As it almost ever happens, requirements may change due to market demands. Let's say that the Service Concept shall be broaden to a general Component Concept and therefore Services shall be renamed to Component.

If you have done this before in a Larger Scale Software Project, you will agree that renaming conceptual elements is a very hard task. This is because a conceptual name is used widely by its very nature.

For this reason, we decided that we will never reference any element by its name but by a GUID:

"A globally unique identifier or GUID (pronounced /ˈɡuːɪd/ or /ˈɡwɪd/) is a special type of identifier used in software applications to provide a unique reference number. The value is represented as a 32 character hexadecimal character string, such as {21EC2020-3AEA-1069-A2DD-08002B30309D} and usually stored as a 128 bit integer."

-- wikipedia

Using GUIDs instead of names will do the trick: Using actifsource, you are able to rename any element easily. No matter if it has a conceptual or a specific nature.

Technically, a name is just an attribute, which is identified by its GUID. Renaming an actifsource Resource just means to notify all listeners.

To change names easily, make sure that you always reference you Domain Model using the actifsource Content Assist to insert a Model Reference (blue underlined). Even when writing comments.

Designing Large Scale Software Systems for Change

2010-04-23T14:18:00.008+02:00

Today's software systems are of a complexity we can hardly manage. Even harder than just maintaining a system is adopting the system to new market needs. Changing an existing system is nearly impossible. Let's explore why.

One of the most important thing for designing a large scale software system is an up-to-date overview of all Business Objects an their relations. For an even deeper understanding, Business Objects need to be categorized by Business Classes. Designing a Service Oriented Architecture, Business Classes and their relationship might be as follows:

Using conventional programming technique, we have to implement the Business Object using classes. Say we do have 10 different services, we do need at least 10 different classes representing these services.

Anytime a new service is implemented as a class, the Service Concept gets cemented a little more. Having implemented dozens of services, nobody can even think of touching the underlying concept.

The problem seems to be easy to understand:

Every concept is a directive how to build some things
Changing the concept enforces the change of every built thing

Having built lots of things already, changing the concept will get more and more expensive.
The basic idea of actifsource is very simple:

Implement every concept only once

At a first glance, this sounds impossible. But we can achieve this by providing one generic implementation. The tedious work of implementing the concept over and over again can be let to your computer. That's what machine can do best!

Every implementation of a concept has to be done only once as a generic implementation
Specific implementations can now be generated
Changing the concepts only leads to the change of one single implementation
Therefore changing concepts becomes cheap

New wizards needed

2010-04-23T09:22:00.006+02:00

This week I created two new wizards for importing and exporting the ecore model. If you ever created an eclipse jface wizard you know there are a lot of things to do.

- Create the wizard class
- Create the wizard page and add them to the wizard
- Initialize the values of the wizard and it’s pages depending on selection
- Implement the code to update status message
- Defining when a page is complete
- Place the wizard page control
- Connect the page controls that depends on each other
- Remembering and Storing the settings from last wizard usages
- Setting the initial focus control
- Defining the perform finish code

Since these tasks are always the same for all wizards we decided to use our actifsource templates to generate the wizard classes. You may notice that some of the tasks above may be done by super classes. For example we can setup the layout manager, define the page complete state and collect the status messages from the page control interfaces. We also may set the focus to the control containing first undefined value. But all these tasks don’t require the concrete types of the values. When we come to the initialization, finish and settings management code, we have to start writing a concrete subclass for this wizard and these are the classes we generate. The templates automatically create the fields for accessing the concrete wizard pages, allowing access to the specific getters and setters not on the page interfaces. I also defined the dependencies of page controls in the model. This way the code for connecting the controls with each other is created by the generator. Code that has to be handwritten is placed in protected regions. It’s the code for initializing, storing the settings, updating the status message and performing the finish action, but this time I don’t have to create the things like field for accessing the wizard page and the initialization method for each page. I’m more or less forced to put the code in the right places. The structure of each wizard implementation is kept clean.

Now all we have to do is to create a wizard instance in the model and define the pages with their control and connect them. Afterwards the generator creates the whole skeleton and we simply have to fill out the gaps. If we decide to rename a wizard all class-, field- and method names coming from the model are changed by the generator.

Look at the model:

I defined a Wizard-Class which contains WizardPages containing inputfields (package-selection, filename-selection, etc.). Each inputfield has a name and uses a fieldeditor (page controls) that may define other fieldeditor as dependency. When the fieldeditor has a dependency you must define a dependency from that to an inputfield to another inputfield using the required fieldeditor. For example I can create a package-field which is restricted based on the selected a resource folder. After defining some name, titles and page descriptions I’m ready to go. Further work that may be done is writing templates for the fieldeditors.

Finally this is one of the generated wizards, each row label, textField and button is a fieldeditor (page control).

Mapping from Ecore to the Actifsource Core (and back)

2010-04-22T14:31:00.001+02:00

As I am currently implementing the import of models created with the Eclipse Modeling Framework (EMF) into actifsource I had to think about the mapping from ecore to the actifsource core (the mapping needs to be bidirectional such that actifsource models can be exported to ecore as well) . If you are already acquainted with modeling using EMF this blog posting should help you getting started modeling with actifsource very quickly.

As both ecore and actifsource core are self-describing meta-meta models it is not surprising that in their heart they are very similar. But the naming is a bit different:

ecore name	actifsource name
EPackage	Package
EObject	Resource
ENamedElement	NamedResource
EClass	Class
EStructuralFeature	Property
EAttribute	Attribute
EReference	Relation
EDataType	Literal
EEnum	Enum
EEnumLiteral	EnumValue

Visually compared:

As a first difference you can see that the actifsource diagram contains dotted relations between elements which correspond to an instance relation. Have you ever tried to change the type of an elment in the ecore model editor after you created it? It is not possible because the fact that one elment is a type of another comes implicitly into the ecore model.

In actifsource however, the fact that one Resource is an instance of some other is modeled by the typeOf Relation. Therefore, types of Resources can be changed as easily as any other property of the model. (The typeOf Relation is part of the Class Resource and therefore every Resource has it. That's where the self-describing plays an important role -- which can be rather confusing at first but you do not have to fully understand this to successfully model with actifsource!)

You might wonder why we did not just use ecore instead of the actifsource core when they look so similar. In the next blog posting I will analyze the differences of ecore and the actifsource core which will show you that the origin of the cores are fundamentally different.

Common Classes vs. Domain Specific Classes

2010-04-22T13:34:00.013+02:00

Right now, I have had an interesting phone call with a potential customer. Quite important to mention - my conversational partner has lots of experience using code generators.

After a 10 minute talk, it came to my mind, that we are talking about different things. My conversational partner has the idea, that generators are transforming Common Classes from a graphical representation to a textual code representation.

Common Classes mean classes as we now them from object-oriented languages or UML. In a nutshell, such classes do have a class name, a base class, members variables and member functions.

If we have to represent a Domain-Object, let's say a Service-Object, all the properties of this Service have to be expressed by member variables and member functions. When working with Common Classes, it makes no difference whether we implement some service calls or functions to set up the service environment.

class MyUserService implements IService
{
// Service Calls
public boolean registerUser(int id, String name) {...}
public boolean deregisterUser(int id) {...}
public User getUser(int id) {...}

// Service Environment
public boolean setUserRegistry(UserRegistry userRegistry);
public boolean resetUserRegistry();
}

Using Domain Specific Classes on the other hand side, we can distinguish between functions concerning Service Call and Service Environment.

Since we are not working with Common Classes, we first have to design our Domain Specific Classes. Means, we have to specify the Attributes (i.e. class name) and the relation between these classes. In actifsource, we do this task in a diagram editor using an UML-like syntax.

Since we do have an exact Specification of our Domain Specific Classes, the Domain Objects are no longer of type Class, but type of the domain-specific class Service.

As shown above, we can now create dozens of specific services of type Service. As you know from your experience, every specific service has a similar implementation.

By example, we write a class for every service. Furthermore, we write a function for every service call. Subsequent, we do have do write a typed parameter for every service call argument.

Today, this tedious and error prone work is done for every service over and over again. But how would it be, if we could state our intension just by writing template code? Template code which doesn't depend on Common Classes - but which refers to Domain Specific Classes!

The idea behind actifsource is writing templates, bases on Domain Specific Classes, rather than Common Classes! Doing so gives you the possibility to write templates as easy as you write code.

Working with Domain Specific Classes allows you to access all the attributes of your domain in the templates which is rather easier than coping with Common Classes!

New actifsource Blog

2010-04-21T14:25:00.002+02:00

actifsource is a state-of-the-art code-generator-workbench that tightly integrates into the popular Eclipse IDE.

In this blog we write about our everyday life as developers. Follow us to see actifsource grow daily and let us know about new features you need. Get involved: share your thoughts and discuss the merits of model driven software development.

Check http://www.actifsource.com