The beauty of inherited code

Ah... the beauty of inherited code. And of course I am not talking about class inheritance and nice OO practices, I am talking about someone else’s code, someone else’s work —does it deserve to be called work? Certainly not work of art!— that falls into our hands to amuse us, to awaken us from our daily routines, to make us indulge in the satisfaction of feeling that we "know better", or is it to torment us? That piece of beauty is there, in front of our eyes, to be fixed, debugged, extended or, even worse, perpetuated.

Read more…

UML as a sketch, blueprint and programming language

While reading the first chapter of UML Distilled by Martin Fowler, I found that I didn’t know how UML could be used beyond the simple class diagrams that help us organizing our code. Although it may seem a little far-fetched, it is interesting to know that UML can also be used as a programming language.

Fowler describes three different modes in which UML can be used: sketch, blueprint and programming language.

Sketches are informal diagrams used to communicate ideas, explore alternatives or design in a collaborative manner. They are usually focused on some aspect of the system and are not intended to show every detail of it. Sketch is the most common use of the UML, and it is certainly the way I always use it.

Blueprints’ purpose, on the other hand, is to describe a system in detail. In the case of forward engineering, the details of the blueprint should be enough for a programmer to code the system. In the case of reverse engineering, the diagrams show all the details of a system in order to understand it better or to provide views of the code in a graphical form.

The UML can also be used as a programming language. When used in this form, the whole system is specified in the UML, the diagrams are the code, and they are compiled directly into executable binaries. There are some projects and books about that: Executable UML and the MDA (Model Driven Architecture).

The effectiveness of each way depends on what we are trying to achieve by using UML. In the early stages of development, using UML as a sketch is highly effective and can be used as a collaborative tool where the developers can brainstorm about the system design. In this case, it wouldn’t be effective trying to think about every detail of the model and generate a blueprint, because the system hasn’t been fully designed yet. After the system design is more stable, UML can be used as a blueprint, and developers can follow it to produce code. Using simple sketches wouldn’t be enough for them, because it would require them to fill in the blanks. This may produce incompatibilities between interfaces or other problems because every developer may interpret the model differently.

Effectiveness of using UML as a programming language would highly depend on the generating and diagramming tools used. If no tools are available to do the job, or diagramming in such detail is cumbersome, then it is not effective. Fowler believes that productivity of UML as a programming language today is not better than productivity of using any other language, thus it will be difficult for UML to go mainstream. He also believes that highly detailed blueprints are not effective because they are difficult to do and it would slow development. I still believe blueprints are good tools because they remove uncertainties for the developer, but I have to agree that even for senior designers it is difficult to delineate every detail of the model.

Even if making perfect blueprints is not possible, I would like to see more tools for forward engineering ColdFusion code. Maybe that would be my next project!

Why use a framework

While working with the C2 architecture I realized the real purpose of using a framework. By definition, a framework is "a structure for supporting or enclosing something else". That is, a structure that allows us to do things such as using messages as communication between components (as in C2) or implementing implicit invocation (as in MachII) when the underlying language does not provide native facilities for that.

It is not only to be able to rapidly develop an application. Rather, it is to be able to use an architectural style to inherit all its advantages: modularity, anticipation of change, abstraction, low coupling, and high cohesion (all the properties that styles aim at). That, in turn, allows us to develop more quickly because the style put us constraints and we have some predefined configurations of component arrangement. We also achieve faster development by means of using proven patterns and reusing components. We could achieve the same results by applying other styles (as long as the language allows us) and skipping the framework.

So why use a framework? Because I am lazy and I don't want to have to think so much about how to realize a style or pattern. And by using a framework correctly, I get a free ride to a well organized application and I can focus on other things.

Working with the C2 architecture

I have been working on a little project where it was required to use the C2 architecture. If you've never heard of this architectural style, you are in the great majority. It was developed by the Institute for Software Research at the University of California, Irvine.

It is event-based or better "component and message"-based. Components communicate using messages sent through a connector. What is interesting about it is that it differentiates between type of messages as "Notifications" and "Requests". Notifications are sent "down" and the component has no expectation that some other component is listening whereas Requests are sent "up" and the component sending them makes the assumption that the service will be provided by some other component above it (but it doesn't care who).

Read more…