Infosys | Microsoft

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.

Posted by Kishore Gopalan at 11:30 AM | Permalink | Comments (0) | TrackBacks (0)

The official name of Orcas is Visual Studio 2008. The .NET Framework with this release is .NET Framework 3.5

Multi-targeting support

 In previous releases, VS only supported a specific version of .NET Framework. Eg: VS 2005 supported .NET 2.0, All this is going to change with VS 2008. VS 2008 is planning to support "Multi-targeting" - which will allow Visual Studio to target multiple versions of .NET Framework.

When we create a new project or open an existing project we can specify which version of Framework we want to work and IDE will enable appropriate features and compilers. One thing to note is the VS 2008 multi-targeting support only works with .NET 2.0, .NET 3.0 and .NET 3.5 - and not against older versions of the Framework.

Javascript Intellisense

In previous versions of Visual Studio, writing Javascript code has been a pain without much intellisense support from the IDE. VS 2008 addresses this pain point with great support for Javascript intellisense. This feature will really make Javascript developers happy.

Scott has a nice blog on this topic.

Posted by Sriram Balaji at 09:18 AM | Permalink | Comments (1) | TrackBacks (0)

Life is all about using the right punctuations in your language. Between "Spare him, not kill him" and "Spare him not, kill him" there's as much difference as between life and death, albeit the same bunch of words.

It's the grammar which matters in your language. Adopt the right rules of grammar to convey the right message, or you’ll end up trying to teach stone-age men to read Shakespeare.

In its simplest form, a Meta-Model is the grammar that defines your business. Like any kid who can speak perfect English, a Meta-Model can be defined by anyone who knows the grammar of their business – typically any business user. A Meta-Model is a model to define the model. A Meta-Model definition tool (like the one provided by Microsoft DSL Tool kit) lets you define the rules of the business.

Consider the business of a restaurant with concepts such as – Menu, Recipe, Caterer, Buffet and Happy Hours. The Factory architect works with the business domain expert to define the Meta-Model.

The ideal Meta-Model  consists of Shapes that represent each of the domain concepts, Connectors that define all possible relationships between those concepts ("a specific Menu always relates to Happy-Hours"), Business Rules to be enforced over these concepts ("Happy-Hours is always between 12 noon and 5 PM"), specific Attributes of each of the concepts ("the Buffet has a pre-defined choice of soups"), Actions to be taken during or after the creation of an instance of a model (events, generation of artifacts).

So it’s like everything your mother tongue is composed of. Except that it speaks the language of business. The Factory architect defines all these elements comprising the language of his business and deploys them, so that the business user can use them to draw models representing business processes and other domain specific activities.

Creating an appropriate Meta-Model is the fundamental of effective Domain-Specific Modeling strategy. Like a good compiler optimizes your source code in the best possible way, a good Meta-Model mixes the scope and scale of business in the right proportion to let the business create highly Self-Explanatory models.

A Self-Explanatory model is one which is readily understandable by a human reader, and is also easy enough for the code (or artifact) generation tools to parse and generate usable and extendable artifacts from the model.

In the next post, I'll discuss the different types of Meta-Models.

Posted by Kishore Gopalan at 12:58 PM | Permalink | Comments (0) | TrackBacks (0)

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.

Posted by Kishore Gopalan at 03:50 AM | Permalink | Comments (2) | TrackBacks (0)

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.

Posted by Kishore Gopalan at 03:42 AM | Permalink | Comments (2) | TrackBacks (0)

If a picture is worth a thousand words, a model is worth a thousand lines of code. No, seriously. Despite the insistence on loosely couple architectures et. al., the complexity of the system and hence its underlying code has, historically, been the least receptive to changes.

With Domain Specific Modeling, this pain can be addresses to a large extent. DSM raises the level of abstraction using concepts related to a given business or application domain. The domain experts create a vocabulary consisting of the key concepts of the problem space, business activities, processes etc. Just like any spoken language the vocabulary defines the rules and semantics that govern that particular business. In addition to the business concepts, the vocabulary is typically extended to cover the related technology pieces that would eventually realize the goals of the problem space.

In the DSM parlance, this vocabulary is called a Meta-Model. Once a meta-model has been defined for the given problem space, the Business worker uses it to create actual models. Sophisticated code generation mechanisms which operate on the meta-model can be built to convert the models defined by the business worker into their corresponding code artifacts. DSM, thus, acts as an intermediate, bridging the gap between modeling and coding. 

In typical cases, a number of models based on one or more meta-models reference each other to generate semantically valid code. In a non-DSM world, any significant change in the business process or the problem space would have an enormous impact on the written code. The first point of pain would be to make your developer understand the new changes and sit back and pray to your favorite Gods that he has actually understood them the right way. If he really did understand, the impact ranges from regression analysis, design changes, rewriting of test scripts to validating the changed application to its new requirements. If he didn’t, well, go back and pray again.

This complexity that underlies conventional mechanisms are overcome in the DSM scheme of things. In this case, a change in the problem space or requirements, would require the business user to modify the models and the references between them to reflect the new requirements. As the code generation mechanism understands the semantics of the model, it can automatically generate new code or update the existing code to reflect the new changes.

Thereby the time and effort you spend on impact analysis, coding and re-coding, and testing the changes are reduced to a considerable extent. The coupling and cohesion metrics of your code are controlled, standardized (and possibly benchmarked) as the code is generated based on known semantics of the meta-model. The meta-model itself can be refined to keep the complexity under control.

As the application evolves, and more models are added and more code is generated, similar mechanisms are adopted to ensure the overall complexity of the code is kept under a constant check. The idea of Software Factories can also be extended for enhancement of existing complex systems, which in turn results in maintaining the overall complexity of the system in a manageable state.

In the next post, I’ll discuss the role of DSM in managing a High Evolvement system.

Posted by Kishore Gopalan at 03:59 AM | Permalink | Comments (0) | TrackBacks (0)