A kingdom of coders or why is it so difficult to reuse quality software

November 14, 2007

I have read a lot of talks recently about APIs. Google APIs, Facebook APIs, OpenSocial APIs, APIs for making coffee and strawberry jam and so on. As a computer scientist I resent the fact that all those efforts are still made on a very primitive level. None of the new or old software industry bulldozers are trying to making it easy for developers. Not true. They are trying, but with the wrong ideas.

For the past years I have been involved in building an inference engine for putting together a set of reusable components for automated reasoning services (commonly known as artificial intelligence). This is part of my PhD thesis that I am hoping to finish next semester. Many inference engines already exist, however the idea of our research group (it´s very much a collective effort that I am part of) was to try a radically model-driven approach. This means, instead of diving from the very beginning into Java or C++ complexity, we took our time to think the architecture of our inference engine as a set of well-defined components that any engineer could look at and within a few minutes understand the services that such component provides.

Yeah, I know. Software engineering bla bla bla. Well, that was exactly what I thought in the beginning. But let me tell you what really happened: after 3 years reading lots of math and logical stuff I finally was ready to project a few components that realize the set of services we were interested in. Although I was dying to implement them right away in Java I took the time to do two things: I figured out the basic functionality I wanted to together with the data structures, then using only UML class/component diagrams I model each basic functionality. And then I used an old software engineering idea, design by contract, to link together the components services (actually methods) through pre- and post-conditions.

I used a new standard from the Object Modeling Group (OMG) called the Object Constraint Language (OCL) to specify the stuff. Mind you, you could use Java as well or any of these new Java flavors to write these constraints. What happened next was that I found out that by using only OCL I could fully express not only the structure of my data but also the behaviour of each component. So as it turned out I did not have a dead model, that would be forgotten as soon as I started my Java implementation. I had a complete system that lacked only the tools to be executed (e.g. a transformation from OCL to Java or to C++).

Then back to my point in this posting: why Google, Microsoft, Yahoo, Salesforce (ok maybe their new platform has some of the things I am talking about here) do not try this leap? I was browsing the other day the OpenSocial API from Google and it really sucks all those hundreds of lines of code. Why is it so hard to present a graphical model of the stuff with nice well-defined interfaces that we just could browse, drag and drop and build the applications much easier? After all, it´s almost a bunch of SQL queries and read/write operations.

It´s a kingdom of coders out there. That´s why. And for some strange, unconscious or conscious reason, those guys are not letting go off their kingdom. Once we have Component-based systems on the web, not only techies will build software. I bet almost everybody that has an engineering background or even is good at logics and math will do. So is this the real motivation of everybody in the software industry to postpone model-driven development or am I just being paranoid?


4 Responses to “A kingdom of coders or why is it so difficult to reuse quality software”

  1. marcos said

    are you looking for this: http://www.popfly.ms ?

    by the way…

    1) graphical notations and web based components are two different and orthogonal concerns. We already have web components: web services, all these api’s are components based on web services.

    2) graphical models can also become really cumbersome when it comes to *real* models, with thousands of entities and relationships. and it’s even worse when you try to model behavior with graphical languages… :S

    but you can still use OCL (textual language) to do 90% of the work and be a ‘coder’ again 😉

    3) when you say “it really sucks all those hundreds of lines of code”, you forget that each of that line of code plays a role on the program and gives the user an option, if you simplify the interfaces making the user just need to say “connect(A,B)”… google would receive thousands of emails saying the user A has a system X.Y.Z that doesn’t work the way the “connect(A,B)” expects…

    this is the price to pay for the current systems complexity… but if expect everyone to buy computers, operating systems, servers and so on from the same manufacturers… to use the same browsers, and to have the same needs… :S

    4) IMHO using MDA we have two options: a) build our models using very “abstract” languages (UML), that are so complex that no human being was able to finish its specification or b) use very restricted languages, that are thus not suitable for general purpose programming and cannot be widely adopted.

    ps: i’m a coder

  2. Some initiatives regarding the subject already exist, such as Microsoft’s Popfly and Domain-Specific Language (DSL) Tools. Have you ever tried them?

    — AFurtado
    game (development) + software (engineering) + other

  3. vitorino said

    Andre, yes I´ve checked popfly a while ago, though I think it provides much less than I was talking about here: I mean fully deployed systems from models, not just web mash-ups. DSLs are equivalent to UML Profiles so it is in the direction of abstracting primitive functionalities and leveraging models, though they do not prescribe a component-based architecture. However my point is: why these tools do not get enough attention from big software companies and the developers community? Why aren´t there any MDA .Net studio for example?

  4. vitorino said

    Marcos, partly you are right, an API is almost a component, the only part that in my view is still missing is a formalization of its interface (such as, Container.getMyFriends(country) post: result = self.friends->select(f | f.country=country), meaning in natural language get all my friends from a given country).

    Graphical models do not need to be cumbersome and complex. There are plenty of ways to view a large graphic. Take for example Google maps 😉 it has zoom in and zoom out facilities in case you want to see the whole continent, the whole country, the region or just a few streets. So I am sure this kind of thing could also be succesfully applied to Component Models visualization.

    I agree that UML is very complex (not that current Java.docs are any less), but a nice subset of the language such as component and class diagrams plus OCL or any other language to specify pre- and post-conditions and activity diagrams (if needed) would be a great advance to all that verbose Java script.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: