Why Build a Language?


In the normal course of development, you don't always need to build a language explicitly, though you do it implicitly all the time. When you use a subset of the UML for "analysis" and a larger subset for "design," and when you specify what the elements of these subsets actually mean, you have, in fact, defined two new languages, each with a different purpose. It's common to add various adornments to express concepts that don't exist in UML, and to the extent that these things have formal meanings, you have extended the language as well.

In order for the UML to offer support for multiple methodologies, the UML specification says little about how the elements of UML fit together. Consequently, developers or definers of methodologies must determine how to use the various components. You might, for example, decide to use an activity diagram to show how various use cases link together, or build state machine diagrams only for classes and objects. The result of stating such a set of conventions defines one member of the UML "family of languages."

There are two major reasons to define a language within the UML family (as opposed to simply using one without saying what it is). The first is communication among team members. For example, some folks on the team might think that persistence is of huge importance to a banking application ("Account balances aren't transient!"), while others might argue that persistence is a design issue. There needs to be agreement on whether to include persistence in a certain model, and on many other issues like it. Similarly, if you decide to add a tag named {persistent} (as opposed to {persistence} or {database} or whatever) within implementation models, you have implied a meaning for that term.

All of these decisions could be enforced by a Notation Police, but this approach is notoriously acrimonious and ineffective. It's better to define the rules in a more formal way, which brings us to our second major reason for defining a UML language: communication with machines. Defining languages formally allows for transformations between models expressed in those languages.



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

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