Who Defines a Language?

Anyone can define a language, but for the purposes of discussion, we can divide them into five groups:

  • Standards bodies

  • Tool vendors

  • Methodology definers

  • MDA architects

  • Developers

Standards bodies, such as the OMG, define languages so that their other standards can have increased usage. An example is the UML profile for CORBA, which describes how to use a subsetted and extended UML that can be transformed into CORBA implementations. (In addition to common platforms such as CORBA, domain-specific task forces also meet within the context of standards bodies to establish a common vocabulary or a common language.) When there's a standard language, users don't need to work this out for themselves each time, and tool vendors can build tools that implement the mappings. The presence of a defined language creates a market, which in turn encourages vendors to build tools, which brings in more users, which increases the size of the market. The result is a virtuous circle that makes the standard that started it all the more useful.

Tool vendors also define languages for much the same reasons. In this case, the existence of a language legitimizes the tooling and brings in customers. Vendors may also need to define a language to exploit certain features of some infrastructure for a customer (for example, if a customer is using a nonstandard object request broker [ORB], or to make use of certain features of the toolset).

Methodology definers define languages because they just can't help themselves. Executable UML, for example, defines a tractable subset of UML, which then becomes the basis for defining a process for effectively building models that developers can apply. Again, the existence of a standard language increases the "reach" of the methodology, which in turn encourages the support of tool vendors another virtuous circle.

MDA architects who introduce a framework or who want the developers to target a certain proprietary component architecture also often need to invent a language. While not being "standard," such a language helps the developers create the particular system more efficiently. By linking the language to more abstract and standardized languages using mapping functions, the resulting specifications benefit from the general MDA advantages such as portability, which is valuable if you move away from the proprietary frameworks or architectures in the future.

When there's no readily available language, developers may choose to build one. This should be a rare occurrence, because language definition is a time-consuming and abstract task. For a developer defining a language, this means that the effort must pay off and not just be an intellectual exercise. And yes, overall savings can be achieved by the hacking folks coming up with a language and corresponding mapping functions.

The definition of the language does not need to be made explicit, though there are obvious advantages to so doing. Standards bodies have to make the language definition explicit because that is their product, which then raises a question: What's in a language?

MDA Distilled. Principles of Model-Driven Architecture
MDA Distilled. Principles of Model-Driven Architecture
ISBN: B00866PUN2
Year: 2003
Pages: 134

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net