Saturday, March 29, 2008

Textual DSLs and diagrams

While it seems fairly trivial to generate the graphical representation of a model built using a textual DSL, many people (including me, until now) do these two steps (modeling and diagramming) separately. Perhaps they don't know about tools that can greatly simplify this task like Graphwiz. It is really a very nice tool. Using a simple textual DSL provided by the tool for diagramming, wide range of graphs can be generated, even very complex ones. Lets see a concrete example:

digraph Components {
Container [shape="box"];
Component [shape="box"];
Port [shape="box"];
Service [shape="box"];
RequiredService [shape="box"];
ProvidedService [shape="box"];
Interface [shape="box"];
Container -> Component [label="manages", headlabel="*", arrowhead="open"];
Component -> Port [label="has", headlabel="*", arrowhead="open"];
Component -> ProvidedService [label="provides", headlabel="*", arrowhead="open"];
Component -> RequiredService [label="requires", headlabel="*", arrowhead="open"];
ProvidedService -> Service [arrowhead="empty"];
RequiredService -> Service [arrowhead="empty"];
Port -> RequiredService [label="points to", headlabel="*", arrowhead="open"];
Service -> Interface [label="defined by", arrowhead="open"];

and here is the generated diagram.
So my point is, that (with minor modifications on the templates used for code generation) nice diagrams can be generated; there is no need to use a separate diagramming tool for these kind of tasks.

Thursday, March 27, 2008

Components and Java classes

People often misuse words that have a well-defined meaning. This is the case with the word "component" which is often used as a synonym for a Java class. In reality, these artifacts are very different. Component is an architectural concept whereas the Java class is an implementation artifact that can be part of the programming model, but might not be used in the conceptual architecture. Moreover, the Java language has no notion of component, so components can poorly be represented using only the elements of the language, without annotations or external configuration (but remember, these are not part of the language, only extensions to it).
Let me explain that briefly. Components should express their inter-dependencies, so every component has to declare its provided interface and required interface (these are not Java interfaces, only architectural level concepts).
In Java, a class can declare its provided interfaces (these are the implemented interfaces), but can't declare its required interfaces explicitly, since there is no language element for it. Only implicit declaration is possible, but it may not be enough if we want to express component dependencies in the programming model.

Thursday, March 20, 2008


The 6th JUM meeting has been held yesterday. There were two presentation about appservers and Flex, and I gave a talk about Java component models. I talked briefly about the basics (component, component model, component framework, Dependency Injection, Dependency Lookup) and about some concrete component models and frameworks (SCA, Spring, OSGi, Guice, JSR277) and their interoperability (Spring-DM, Guice-OSGi, Guice-Spring). Here are the slides (only in Hungarian).

Wednesday, March 12, 2008

Dumb value objects

What sometimes really bothers me is that many programmers overuse value objects. They do it despite the fact that this concept is over-simplified for many tasks. And they even implement the accessors as dumb wrappers around the values, leave the checking of values for the callers, which is mostly a silly thing.
My point is that we should talk more about this kind of design. My 10 cents:
  • Read about domain objects and try to understand the concept. It's easy.
  • If you need value objects, implement their accessors in a way to check the accessed values and throw exceptions (in Java, I prefer runtime exceptions such as IllegalArgumentException or IllegalStateException) if the pre-defined constraints are not satisfied.
  • Think about concepts at higher abstraction level than data (objects, components etc), before you implement things.

Friday, March 7, 2008

Podcast about software components

The guys at Software Engineering Radio have recorded a very good podcast about software components and component-based architectures. It's worth to listen to.

Saturday, March 1, 2008

Architecture, again

Last time I blogged about architectural diagrams. Now, a very good article appeared on InfoQ from Markus Völter. In the article he is focusing on the creation of a language used to describe a conceptual architecture and provides an overview about DSLs.