Monthly Archives: March 2003

software

mda – model driven architecture

Leave a comment

I explore Model Driven Architecture (MDA). This approach uses modeling for programming. Models drive the generation of code according to patterns.

We tend to write a lot of similar code over and over. If you have ever written code to persist a Java object into a relational database table, you know what I mean. It is similar for every object. Although the characters you type are different, there is a definite pattern, and you know deep down that an intelligent person should not have to endure such tedium day in and day out. The same goes for a lot of user interface code, like data entry forms. The same code gets written again and again; only the names are different.

I believe very strongly that model driven architecture is the way of the future for software development. Objects led to interfaces. Then, collaborations. Then, patterns and pattern languages (families of patterns). Model driven architecture is a natural extension of this trend. After identifying a pattern language, it should be possible to instantiate those patterns (write a software program) by expressing that intent through modeling. Modeling in the abstract sense is the act of capturing concepts in a notation.

I consider programming in Java to be a form of modeling. A programming language is not a very compact modeling language. Programming languages are designed to have a lot of redundancy to allow for error checking. Patterns in the code also indicate a lot of information that could be expressed in a more compact form. I view MDA as expressing software concepts in a very compact form (the model).

I think we need an example. I could write a program to represent pictures formed from geometric shapes. The software itself would probably require thousands of lines of code to perform the editing, rendering, and other functions. However, the application is really only dealing with a few basic concepts: ellipses, polygons, line segments, and a few others.

It should be possible to model each shape with a minimum number of parameters; e.g., an ellipse would be modeled by three points. In this manner, we could express any diagram understood by this application very compactly in a modeling language that captures the parameterization of shapes.

Now, let’s take that graphics package and reuse it as the foundation for constructing an application that renders telecommunications networks. This application deals with concepts like location, network elements, ports, and connections. Each concept is rendered with symbols, which are merely recurring patterns of our familiar geometric shapes.

The parameterization of shapes is no longer the most appropriate modeling language for capturing the essential concepts of this application. A more compact representation can be achieve by parameterizing the concepts that are directly understood by the application. This is the essence of model driven architecture.

Not everyone views MDA as I do. Actually, I have yet to encounter anyone who has expressed it as simply as that. Most proponents of MDA ramble on about UML and MOF and platform independence and all kinds of other non-essential mumbo jumbo. The key idea that is lost among the OMG UML/MOF folks is the notion of unit economy in the theory of concepts; that is the need to represent concepts in the most compact form. This is necessary within the mind, and this need is reflected in language.

UML makes perfect sense as a language for representing analysis and designs for software development. However, when one is looking to model concepts within any other context, the absurd verbosity and complexity exhibited by UML/MOF make as much sense as using geometric shapes as the modeling language for telecommunications networks.

innovation

collaboration – a business idea

Leave a comment

business idea for enterprise collaboration

(Continued from 2002-07-08.) One of the biggest impediments to productivity is the lack of tools to facilitate collaboration. This was not as noticeable, when workers tended to be collocated with those they needed to collaborate. Physical collocation makes less sense today, when globalization requires companies to be distributed throughout the world.

Expertise is becoming so specialized that it is impossible to develop a broad range of skills in house and locally, so this creates a need to outsource and recruit teleworkers. Email, telephony, instant messaging, and intranet Web sites only go so far to facilitate communication with these remote sites. These technologies need to be integrated into business processes to facilitate wide scale real-time collaboration.

In a software development organization, there are very specific requirements that are unmet by today’s information technology. Software development tools tend to focus either on the relationship between individuals and code artifacts (e.g., integrated development environment) or the relationship between the code artifacts and the quality assurance processes for the software product (e.g., software configuration management). Over the past decade there has been a greater focus on analysis and design tools (e.g., UML modeling). However, modeling is a very small part of analysis and design. The majority of analysis involves the capture of requirements and use cases in the form of natural language (e.g., English) descriptions. This is a very iterative and interactive process among experts and analysts, and the information flows into design. Design is a very creative process among analysts, architects, and programmers in various areas of expertise (e.g., user interface, application server, database). The collaboration tools support for analysis and design are wholly inadequate today.

The software development community needs a Web based collaboration system for analysis and design. In the analysis space, Rational Requisite Web almost completely misses the mark for a requirements database. In the design space, there is nothing to facilitate the whiteboard-style interactions that are necessary during the creative process. Such interactions work toward evaluating design options and formally capturing the final design decisions. UML modeling is merely a visualization technique. UML diagrams are not in a format that is appropriate for communication between all stakeholders. Ultimately documents must be produced for the software architecture and the design of each subsystem. Collaboration tools are required for producing these artifacts as a team.

I have looked at using a Wiki to facilitate collaborative content creation. This is not a bad mechanism for authoring, reviewing, and revising content. However, it is wholly inadequate for taking that content and producing documents for publishing. Moreover, a Wiki alone is insufficient for handling all the various kinds of content that is needed for analysis and design (e.g., models, diagrams, code, user interface prototypes), and for managing the workflow.

I believe that this is a tremendous business opportunity. There is clearly a need for this kind of collaboration tool for software development. One can imagine this need extending into other engineering activities, and perhaps even into other disciplines (e.g., sales and marketing) within the enterprise. This is likely a $100M idea with a market window that is likely to remain open for quite some time. If I had the guts, I would probably pursue this one as my baby. I’ve got the perfect skillset and experience to make this happen.