Feeds:
Posts
Comments

Posts Tagged ‘Software Engineering’

Things have been a little quiet lately in blog-world as I have been incubating an open source model driven project – watch this space. This has been motivated after taking a look at AndroMDA. Although AndroMDA is excellent I have a number of quibbles. Some of these aren’t unique just to AndroMDA.

  1. Lack of ‘eating your own dog food’. If an MDA tool is worth its salt, surely it must be capable of being used to generate itself from a model. None of the tools that I have seen contain a UML model that describes the software that can be used to generate itself. Obviously there needs to be a bootstrapping process, but once the kernel of the tool is written it can be used to further refine and develop the tool.

    It would be a pretty good acid test, since it would prove that the tool is sophisticated and pragmatic enough to develop a moderately complex application. It addition it would be put through its paces as the model for the application would go through multiple edit, generate and test cycles. (Oh did I mention Agile-MDA? MDA doesn’t preclude being used within an agile development project. I’ll expand upon Agile-MDA in a future blog entry if there is interest.).

  2. AndroMDA makes use of stereotypes to help drive the code generation process. For example the classes within a model being used to represent entities, those classes that are to be made persistent, are flagged with the «entity» stereotype. This helps direct the code generator to create the appropriate persistent code. To this end, the model must include the AndroMDA profile containing the valid AndroMDA stereotypes.

    Although the use of stereotypes provides expressiveness, it does mean that there is a deviation between the classes represented in the model and classes that get generated as code. The MDA purists would argue that this level of abstraction and transformation is acceptable.

    I personally prefer adopted a WYSIWIG (what you see is what you get) approach, where the model is a pretty faithful representation of the classes that will be generated. For example it is possible to model the frameworks and APIs that will be exploited by the implementation model. I argue that by modelling the frameworks and APIs you get a better insight into the structure of that which is being extended and used. In this way you can see clearly the relationship between the classes in your model and those of the frameworks that you’ll exploit.

  3. I’m not a fan of using inheritance to separate generated code and developer written code. We all realise that to be pragmatic, that developers will need to write code in addition to that which is generated. UML (+OCL) isn’t practical for detailed program description.
    Tools like AndroMDA allow developer written code to be contained in an ‘implementation’ class that inherits from a generated class. The generated class can be changed and regenerated, without loosing the developer written code in the inherited implementations class.

    Simple Inheritance
    However this creates an artificial separation between the generated and user written code. If I wish to sub-class the generated class, I can, but I will loose the extensions in the developer written implementation class. There are techniques for getting around this, but this is an extra burden which most developers cannot be bothered with.

    The answer I feel is not to use sub-classing, but to allow developer written code and generated code to be contained within the same class. The tool should be able to merge user written code with generated code so that no developer written code is lost. This is also in line with my previous point, that the model represents more closely what is being generated.

  4. Support of OO concepts. Most tools like AndorMDA can generate simple attributes and accessors (getters/setters). For example if I have a Customer class and an attribute called ‘id’ of type long, this will be faithfully generated. However when we start to use more complex modelling constructs such as a 1 to many association between classes or qualified associations these tools do not provide much assistance.

    Customer and Product
    For instance if the afore mentioned Customer class is associated with a Product class via a 1 to many association as shown, most tools will for create something like the following when generating code for Java,

    public Vector products = new Vector();

    Sometimes it may be declared private and a pair of accessors to the products variable will be provided. However in both cases, the implementation generated does not enforce encapsulation, something as all good OO practitioners we know is a good thing and would want.

    What would be better, would be for the collection to be encapsulated and for the following kind of interface with corresponding implementation to be generated,

    public void addProduct( Product aProduct );
    public void removeProduct( Product aProduct );
    public Iterator getProductsIterator();

    And perhaps optionally,

    public int getProductsSize();
    public Product getProductAt( int index );

    Notice that we don’t break encapsulation. We can add and remove Products to the Customer, and we also provide mechanisms for iterating over the Products associated with the Customer.

    In an ideal world we would also like qualified UML associations to also be supported. These are very useful for representing key, value pairs between classes.

    With this, a lot of boilerplate code can be generated removing the burden from the developer and enabling then to concentrate on creating the unique business logic.

Read Full Post »

A few years ago I started the Angry Architect blog.  Since then I have calmed down a little and having been unable to recovery my account password, I have decided to start afresh.

In this blog we’ll explore my personal journey through the world of software.  I feel as an industry we are heading off in the wrong direction.  We are no better at creating software than we were when I started twenty years ago.  We as an industry fail to learn and improve.  Software is hard to create, it is often delivered late and when it does arrive it fails to meet expectations.  Even one of the most successfully software companies in the world, with all its vast resources, is unable to produce software on time and to budget.  (Microsoft delays Vista ).

In these credit crunch times I hope that the industry is forced to change.  The answer I feel isn’t off-shoring software development, as that just moves the problem somewhere else and only delays the day when companies will have to address the underlying software economic issues.  It isn’t following the latest fad such as agile development, appealing as this seems, as this isn’t providing the step change needed in producing software.

Software is incredibly labour intensive.  We are still in the Middle Ages as a discipline.   We rely on all too primitive tools and the herculean efforts of individual coders.  We think that by building better IDEs with IntelliSense, auto-completion and refactoring editors that this is the answer.  Unfortunately I think that this is not the case as we are still scratching away at code.  Painful as it seems, we need to break away from this paradigm and raise ourselves up to a higher level of abstraction.

We attempt to call software development an engineering discipline however I see very little engineering being done in software today.  If we compare ourselves to architecture, electronics and product engineering, we see the habitual use of blueprints, circuit diagrams and design schematics.  These are used to explore solutions, reason about and predict the characteristics of implementations before they are built.  Building engineers are able to test the load-baring characteristic of a bridge before it is built for instance.  By comparison we are unable to do this for software.

Unfortunately I don’t personally have the answer, I wish I did.  However I would like in this blog to touch upon some themes, technologies and approaches that I think point the way in which we should be heading if we are to put software engineering back into software development.

Read Full Post »