Where we are coming from – Part III

15th April, 2007 - Posted by rafael.chaves - 4 Comments

(This is the third and last installment in this series. If you haven’t done it yet, read the first and second installments before you proceed)

Let’s start by recalling the main points we wanted to make in the previous posts. In summary, we should strive for addressing concerns as independently as possible (points #1 and #2), and that depending on the dimension (point #3) the concern lives in we should deploy the most appropriate languages and skills for the job (point #4 and #5). The benefits are countless across many areas such as productivity, handling of changes in requirements, reuse, and work specialization. But how to achieve that?

Libra comes to the rescue

Corcova Libra (codename) is our yet to be released tool that supports our vision of how software development should be done. Libra artifacts are models and templates. Problem domain concerns are addressed in a platform-independent way in the form of executable UML models. Implementation-technology concerns are addressed in templates using one of the supported template languages.

Since the platform-independent models are fully complete (from the point of view of business requirements), they can be tried, tested and debugged, even before a target platform is chosen. And when the implementation-aware templates are applied to the platform-independent models, the result is platform-specific code that fully addresses all concerns, be them in the problem-domain or implementation technology dimension.

Libra is not the first product to follow this approach, but is the first that aims to bring the benefits of executable models and full code generation to the masses of application developers.

This is the last post of a series that aimed at explaining what problem we set out to fix. We hope you enjoyed it. We sure were vague on technical details, which we plan to unveil as we release the first publicly available version. If you want to know about any news on the development of Libra, this is the place to watch. If you don’t like to use feed readers, you can also send us an e-mail, and we will let you know whenever a new post is available (we promise not to spam you, and you can opt-out at any time).

Read More

Where we are coming from – Part II

7th April, 2007 - Posted by rafael.chaves - 2 Comments

(This is the second installment in a series of posts that explains what we think is wrong with the current state of affairs in the mainstream business application development industry, and how we plan to fix it. If you haven’t done it yet, read the first post first)

We finished the first post of this series by stating it was essential to acknowledge the fact that concerns belong to one of two primary dimensions, namely the problem domain dimension or the implementation technology dimension.

The reason for that is that these dimensions impose a set of common characteristics shared by all concerns they are home to. That suggests that we should need different tools when addressing concerns in different dimensions.

Point #4: when addressing a concern, we should use tools that are appropriate for concerns in its dimension.

But is that true? And what are tools appropriate for concerns in the problem domain dimension, or for concerns in the technology dimension? To answer these questions, we need to look deeper to understand the differences between the two primary dimensions.

  • change rate: concerns in the problem domain dimension change as often as the business requirements change, and that depends on the application and the problem domain. Concerns in the implementation technology dimension change only when a new target platform is to be supported, or a new kind of implementation artifact must be created, or a new implementation strategy (for the technology in use) is chosen. Comparatively, concerns in this dimension are more stable than concerns in the problem domain dimension.
  • abstraction level: since concerns in the problem domain dimension can be addressed in a way that is completely independent from implementation details, they can be dealt with at a high abstraction level. Conversely, concerns in the implementation technology dimension are closely tied to the implementation platform and thus have a lower level of abstraction. Trying to address concerns on those two dimensions using the same abstraction level (for instance, by using the same programming language) is less than optimal, and it is bound to favor one dimension at expense of the other (think of an accounting application in C or an operating system in COBOL).
  • reusability: artifacts created to address concerns in the problem domain dimension are reusable across target platforms and implementation strategies. Artifacts addressing implementation-related concerns are reusable across problem domains. Thus, the languages and methods for addressing concerns in the problem domain dimension should be technology obsolescence-proof, whereas languages and methods for addressing implementation technology concerns are free to harness the power of the technologies they are related to, while remaining agnostic to problem domains.
  • skills required: developers addressing implementation technology concerns must be deeply familiar with the target platform and must know the best practices for the particular set of technologies chosen, no knowledge of the problem domain being required. On the other hand, people addressing concerns in the problem domain dimension must have good analysis skills and understand the problem domain they are working on – little to no knowledge of the implementation platform is required. They are not exempt though of having good object orientation design skills and a decent proficiency on specifying algorithms using imperative programming. It is seldom the case that a person that is knowledgeable on the problem domain is also an expert at some target platform, so being able to address concerns in different dimensions in a compartmentalized way opens great opportunities for work specialization.

Point #5: Concerns in the problem domain and implementation technology dimensions differ in many fundamental aspects, and thus you need different languages, methods and skills to address them.

It should be needless to say that this is the model of software development in what we believe. Languages and methods with the appropriate abstraction level for higher expressiveness and power. Problem domain related artifacts that are obsolescence-proof. Reuse nirvana by completely separating concerns across dimensions. Optimal productivity and job satisfaction through specialization of work across concern dimensions.

All this will be possible only if you can truly address problem domain and implementation related concerns completely independently from one another.

We are building the tools that will allow you to do that. Want to know how? Stay tuned for the next installment in this series of posts. Want to see it with your own eyes and help us make a great product? Send us an e-mail, introduce yourself and tell us how you would like to help.

Read More