« May 2007 | Main | July 2007 »

June 29, 2007

Software Factory: Business Semantics based Meta-Models

Software, these days, are so much like the people who build them – disparate, hard to change, easy to break, and an inexplicable dire need to interact with one another. No man is an island, and so are software systems.

In the present day service oriented world, the most vital aspect of effective software systems is the way it solves business problems by a smart integration of business and the technology components comprising the problem. A seamless interaction between business processes and technology, thereby bridging the gap between fast changing businesses and the upcoming technologies becomes the key driving force for getting the best out of your IT investments.

Meta-Models can have two possible classifications. One driven by Business Semantics and the other based on Behavior. This idea just discussed becomes the fundamental for segregating Meta-Models based on Business Semantics as below.

1. Business Oriented Meta-Model
2. Technology Oriented Meta-Model
3. Collaborative Meta-Model

A Business Oriented Meta-Model primarily concerns itself with representation of business activities, processes, workflows and business rules. Like the Restaurant model example in the previous posts a Business Oriented Meta Model will have concepts such as Menu, Recipe, Caterer, Buffet and Happy Hours.

A Technology Oriented Meta-Model concerns itself with the representation of technology components that would be used to realize the business model (created using  Business Oriented Meta-Models). For example, a Technology Oriented Meta-Model for a WCF based implementation will have concepts such as Service Interface, Service Proxy, Data Contract, Business Contract, Entity Translator, etc.

The Collaborative Meta-Model maps the business models and the technology models with a comprehensive representation that defines the complete schema of the Software Factory representation of the system being developed. For example, to combine the Restaurant Business Model with the WCF Technology Model, the Collaborative Meta-Model could be a software architecture model with concepts such as a UILink that connects Menu with Service Proxy and Data Contract to represent a scenario where a “Web Page shows the Menu items and interacts with the Service Proxy by passing values using the Data Contract”. This connection in turn generates source code and artifacts by creating an aspx page, with code for connecting UI to the Service Proxy via the Data Contract.

Thus we see that the Collaborative Meta-Model plays the key role of being the mediator controlling the interaction of Business and Technology models to represent the Business Semantics and realize the goal of the software system.

In the next post I’ll discuss the classification of Meta-Model based on Behavior.

June 15, 2007

Software Factory: The ABC of DSM

Domain-Specific Modeling (DSM) does to present day programming languages, what the present day programming languages did to Assemblers – hide the nonsense.

If using plain English-like statements to write programs came as a revolution in the last generation, then drawing figures to represent our programming problems is the call of next generation. 

At its core, a DSM Language lets you draw models which use a pre-defined vocabulary called a meta-model. In other words, a Meta-Model is a model that is used to define the actual model. And this model is at many levels of abstraction above the conventional modeling languages like UML, because the symbols in a domain-specific model map to actual entities of your business domain. For example, a Meta-Model for a Restaurant-Management Software will have concepts like Menu, Recipe, Caterer, Buffet, Happy Hour etc, and the model would contain symbols representing each of these concepts.

A business user then draws a model by using these symbols, and applies the rules of his business domain. Each symbol is typically worth several lines of code. The Factory experts also make Code Generation and Transformation tools specific to the Restaurant-Management domain. These tools operate directly on the models created by the business user to generate source code and other artifacts as required by the software  system. The resultant is a highly efficient code and artifacts because this code generation has been automated by the experts and hence is of much better quality than what a developer codes.

Typically developers take over at this point to add all the other stuff required for the particular restaurant to make the software a comprehensive solution. Note that every restaurant has concepts like Menu, Recipe, Caterer, Buffet and Happy Hour – which means, the same Factory and the corresponding tools can be used to create software for any restaurant in the world. Once the base software has been laid down by the factory, the developers can take over to tweak and add details to make it customized for their restaurant.

The "one size fits all" philosophy of UML – where all you think is classes and objects – is highly inefficient, as the models are completely disconnected and lack any semantics of the business domain. Whereas in the DSM world, the business semantics become the prime driver to define meta-models, create models out of them, and generate software artifacts.

In the next post, I'll discuss the concepts underlying a Meta-Model.

June 8, 2007

Software Factory: Adopting DSM for High Evolvement Systems

How you wish you could write a software and say – "Write it, Shut it, Forget it"? If only businesses were so simple and straightforward, and everybody in the world understood everybody else every time of the year. Sigh! There is no dearth of dreams.

Coming back to reality, fuzzy or frequently changing requirements are one of the biggest problems dealing with software systems. Today's requirements are tomorrow's legacy (whether you like it or not), and so on. And keeping your software systems on its toes has, historically, been a pain. The idea of Software Factories draws its nucleus from Domain Specific Modeling, and tries to address this to a very significant extent.

Modeling, at its very core, defines a way for the business users to define what his business is all about, and the mechanisms working together with it – Code Generation, Transformations et.al. – make sure the model is parsed and emitted out as appropriate source code and other artifacts that fuel the software system being developed. In a traditional world, a change in requirement would have to be understood through non-intelligent models, and then understood by a bunch of smart people from IT, and establish processes around this so that they flow down as precisely as possible to the developers.

And History and experience tells us, that even in its most precise form the change in business requirements is never conveyed as-is to the developers, thanks to the eternal troubles of human mind and the limitation of verbal and inter-personal communication. With DSM, this trouble is partially taken over by the mechanism itself.

So the business user makes changes to the model; and because the models are tightly coupled with the domain specific Transformation Mechanisms, they immediately churn out code and artifacts that adhere to the new model to hitherto impossible levels of precision. The developer can take over from here and add customizations and other business logic to the generated artifacts to fine tune them to best suit the software's needs.

The mechanism just described addresses the needs of fuzzy and changing requirements to a great extent, because the generated source code is a direct representation of the changed model, and the transformation logic used to churn out the code is also specific to the domain. And thereby ensuring much lesser pain and loads of reduction in time spent on understanding, translating, coding and validating the requirements.

In the next few posts, I'll discuss the theories, concepts and practices of Domain Specific Modeling.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter