www.computer.org/software
Worst Practices for Domain-Specific Modeling
Vol. 26, No. 4 July/August 2009
This material is presented to ensure timely dissemination of scholarly and technical work. Copyright and all rights therein are retained by authors or by other copyright holders. All persons copying this information are expected to adhere to the terms and constraints invoked by each author’s copyright. In most cases, these works may not be reposted without the explicit permission of the copyright holder.
Copyright By PowCoder代写 加微信 powcoder
© 2009 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.
For more information, please see www.ieee.org/web/publications/rights/index.html.
domain-specific modeling
Worst Practices for Domain- Specific Modeling
and , MetaCase
In computing’s early days, language creation was a common activity, but by the millennium’s end it was relegated to a few gurus. Early articles1 citing “1,700 spe- cial programming languages” or hundreds of modeling languages were smoth- ered by the ubiquity of languages such as Java and UML. The current decade has seen a resurgence of interest in domain-specific languages, particularly domain- specific modeling (DSM) languages. The reasons for this renewed growth include the availability of tools to create and work with such languages, and the frequency of cases
Little guidance exists on creating domain- specific modeling languages. Learning what not to do— including how to deal with common pitfalls and recognizing troublesome areas—can help.
22 IEEE SoftwarE
Published by the IEEE Computer Society
0740-7459/09/$25.00 © 2009 IEEE
in which productivity increased by a factor of 5–10 with the introduction of DSM.2
All too often, however, language developers have had to fly by the seats of their pants because little material is available to teach them how to create a good language. Although industrial books offer solid background on why we need such lan- guages,3,4 and academic research offers theories and analysis of them,5–7 both fields mostly omit instruction on how to actually build them.
There are a few good guides to creating a DSM language, including articles8,9 and a recent book.2 Still, many readers are left feeling uncer- tain, and many languages repeat basic mistakes. Perhaps in language creation, as in music, it’s easier to teach what not to do and thus help even first-timers create something acceptable. At the least, knowing what to avoid can be a valuable addition to a set of best practices, enabling lan- guage developers to recognize troublesome situ- ations early and thus save themselves from later
rework. Here, we outline the common pitfalls, focusing on language creation and use; length re- strictions prevent us covering generators or wider organizational issues.
Method Overview
We’ve identified several worst practices during our experience over the years. To refine our categories, we analyzed 76 DSM cases. This sample is rela- tively broad, spanning 15 years, four continents, several tools, around 100 language creators, and projects having from three to more than 300 mod- elers. Among the problem domains are automo- tive, avionics, mobile, medical, consumer electron- ics, enterprise systems, system integration, and server configuration. Solution domains include as- sembler, Basic, C, C++, C#, Java, JavaScript, shell scripts, Python, Prolog, Matlab, SQL, and various XML schemas. That said, the sample does con- tain a preponderance of cases in Europe or involv- ing MetaEdit+, which is somewhat excused by the
fact that these conditions probably accounted for the majority of DSM cases worldwide.
We present the worst practices here in the or- der you’d encounter them over the life of a project: the initial starting conditions; the domain concept sources; the resulting language; the language’s no- tation; and the language’s use. We also list the per- centage of cases in which we observed the prac- tice. Because a single case might exhibit zero or many worst practices, percentages might not sum to 100 percent. Finally, we changed some details in example diagrams to protect the identities and rights of those involved.
Initial Conditions
Even before language creation begins, wrong at- titudes and decisions can have a serious effect on later success.
only Gurus allowed
Believing that only gurus can build languages (4 percent) or that “I’m smart and don’t need help” (12 percent)
Decades of experience with theoretical funda- mentals, software systems, and language creation might be helpful when developing general-purpose languages. However, such a background isn’t the key success factor when developing DSM languages. Because DSM languages try to solve fewer problems than general-purpose languages, they’re typically simpler to create. They’re not, however, simplistic; they require in-depth understanding and experience with the problem domain. So, appropriate domain expertise is more important than knowledge of lan- guage theory.
The other extreme to avoid is trying to do every- thing yourself, ignoring other people’s expertise on how to make good languages. Although it’s good for organizations to view their own resources as the key element for developing their DSM language, ex- cessive complacence and a “not invented here” at- titude can prove counterproductive. The cruel truth is that, without help, everyone’s first language— like everyone’s first program—is unlikely to be a masterpiece.
Lack of Domain Understanding
Insufficiently understanding the problem domain (17 percent) or the solution domain (5 percent)
Creating a DSM language requires a good un- derstanding of the problem domain. Normally, this shouldn’t be a problem, but occasionally companies make the mistake of delegating the task to a sum- mer intern, or seasoned developers take it on and fail to lift their noses above the level of the code.
The language must also set a reasonable boundary around the kinds of applications to be built, sparing at least a thought for future expansion.
Other possible problems when assembling do- main concepts into a language include a lack of con- ceptual or abstract thinking skills or a lack of ex- perience in building nontrivial systems. Such skills can come from fields other than programming. However, programming is perhaps the best teacher because it offers a good vocabulary for principles such as DRY (don’t repeat yourself; that is, avoid duplicating code or data) and modularization (aim for high cohesion and low coupling between sys- tem parts). These principles are at least as necessary when building a language as they are when building an application.
Although creating a DSM language should fo- cus on the problem domain, inexperience in the so- lution domain can cause problems later. The best DSM language creator is an experienced developer who focuses only on the problem domain, but lets his solution domain experience inform his choices among otherwise equally viable solutions.
analysis Paralysis
Wanting the language to be theoretically complete, with its implementation assured (8 percent)
The motivation for this kind of mistake is rather obvious: fear. For most of us humans, it’s rational to be cautious when entering unfamiliar territory, such as creating a language for the first time. Another form of this problem is a desire to solve every pos- sible problem: that is, a tool isn’t useful unless you can use it for everything.
DSM isn’t about achieving perfection, just some- thing that works in practice. It will always be possi- ble to imagine a case that the language can’t handle. The important questions are how often such cases occur in practice, and how well the language deals with common cases. To avoid analysis paralysis, concentrate on the core cases and build a prototype language for them.
The Source for Language Concepts
The first step in building a DSM language is identi- fying its concepts. The problem domain is the ideal source; relying too much on secondary sources is a recipe for trouble.
UML: New wine in old wineskins
Extending a large, general-purpose modeling lan- guage (5 percent)
Although it’s obviously tempting to build on an established language’s constructs and semantics, such languages are typically too generic and broad
Because DSM
languages try to solve fewer problems than general- purpose languages, they’re typically simpler
to create.
July/August 2009 IEEE SoftwarE 23
Figure 1. Focusing on framework code. Overemphasizing the target framework or component library can result in low-level details and unnecessary duplication.
for any specific domain. Stripping off parts of the original language and adding new concepts and semantics is often more work than simply start- ing from scratch. That said, it’s obviously good to reuse the basic ideas and concepts of established languages, such as states, data flow, control flow, and inheritance.
In theory, the opposite is also possible: an exist- ing language might be too small or narrow. In prac- tice, however, this seems uncommon and is easier to correct by extending the existing concepts.
3GL: Visual Programming
Duplicating the concepts and semantics of tradi- tional programming languages (7 percent)
Although incorporating programming language concepts such as choices or loops in DSM languages can be useful, you shouldn’t let them become the core concepts at the expense of those in the problem domain. The peril in this case is to end up with ge- neric visual programming instead of DSM, leading to a language with a poor level of abstraction. Vi-
sual programming languages of this type often have lower expressive power and are more difficult to use than the manual code they’re designed to replace.
Code: the Library Is the Language
Focusing the language on the current code’s techni- cal details (32 percent)
Although you should derive the modeling lan- guage concepts primarily from the problem do- main, some solution domain influence is accept- able. However, if the language overemphasizes the target framework or component library, it can drag the abstraction level down toward the code level, preventing retargeting to other platforms. This directly opposes DSM’s idea of achieving the best possible level of abstraction for software de- velopment. Solution-domain-based languages of- ten expose the implementation details and repeti- tion common in code. Figure 1 shows an example of both: each object pair in the middle could be replaced by a single object, with the implementa- tion details abstracted out.
This was the most common worst practice in our sample, which is hardly surprising when you consider the domain framework’s role. At the beginning of a language development project, a framework often represents the solution domain’s best existing abstraction; it’s also well under- stood by the domain experts and familiar to the programmers. Given this, a framework is a plau- sible candidate for the language concepts, but it’s typically best to return instead to the source: the problem domain itself.
tool: If You Have a Hammer …
Letting the tool’s technical limitations dictate lan- guage development (14 percent)
Ensuring good tool support for a language is an important aspect of its development, but focus- ing on tool issues or getting trapped into seeing the world through the tool’s limitations is a mis- take. Different DSM tools have different empha- ses, and not all tools support all parts of DSM equally well. Using a poorly suited or weak tool can lead you to make decisions on the basis of what the tool supports, rather than what’s needed for the problem domain or the modelers. Figure 2a shows an example where a tool led even an ex- perienced developer to create a language for menu structures that’s hard to read and use; Figure 2b would be clearer. Also, practices you learn as workarounds for weaknesses in one tool can all too easily be carried over when you work with an- other tool that’s stronger in that area.
Similarly, people often get carried away with a
24 IEEE SoftwarE
www.computer.org/software
tool’s new or cool features at the expense of getting the language’s substance right. A sound foundation has more effect on a language’s usefulness and suc- cess than do the latest bells and whistles. Also, don’t feel obliged to use all tool features: just because a tool supports something doesn’t necessarily mean it’s a good idea.
The Resulting Language
Building a language is a balancing act between a number of forces, both technical and psychological.
too Generic/too Specific
Creating a language with a few generic concepts (21 percent) or too many specific concepts (8 per- cent), or a language that can create only a few mod- els (7 percent)
Finding the proper generic-specific balance is a key success factor in DSM development—and is thus a rather common place to make mistakes. Developers often create a language that’s too ge- neric for its domain, with concepts and seman- tics that are either too few, too generic, or both. In Figure 3, for example, adding the concepts of “lights” and “heating” would improve the lan- guage. A good benchmark here is to see whether you can use your language to model in domains other than your target problem domain. If so, your language is probably too generic.
The other extreme is a language with too many concepts, which are probably too narrow semantically or overlap. This creates problems during language deployment and use; overly com- plex languages are difficult to learn, master, and maintain.
An interesting variant on the theme of generic- ity is a language that enables users to create only a few potential models. DSM solutions are mass- production environments first and foremost; if us- ers can’t create many applications, building the language might be a waste of effort.
Misplaced Emphasis
Too strongly emphasizing a particular domain fea- ture (12 percent)
By definition, DSM languages should have a strong emphasis on the domain concepts. Un- fortunately, language developers can stretch this good practice too far by focusing on a particular feature or concept at the expense of others. This is especially troublesome if that concept has little or no value for the DSM solution. Typically, such a situation arises when you let too many stake- holders influence the language development. It’s good to listen to different voices to understand the
Figure 2. Tool choice and outcomes. (a) A tool focused on strong containment leads to an odd, labor-intensive model structure. (b) Replacing the visual containment with relationships makes the menu structure clearer.
domain and the prospective language usage, but you should always retain a clear vision of the lan- guage’s “big picture” and objectives.
Similarly, some developers might be tempted to put every domain element into the language,
July/August 2009 IEEE SoftwarE 25
Figure 3. Insufficient concepts. This language has too few concepts, and they’re too generic for this domain. Adding explicit concepts for “lights” and “heating” would improve the language considerably.
forgetting the importance of deciding what not to incorporate. Many DSM cases are essentially soft- ware product lines, and their languages should model variability—you can omit any commonali- ties among all products, handling them instead in the generators or domain framework.4
Sacred at Birth
Viewing the initial language version as unalterable (12 percent)
This rather common mistake occurs for several reasons. Most of us don’t like the idea of “build one to throw away” and are thus reluctant to discard or radically modify our first draft. People often view language creation as a waterfall process, neglect- ing its iterative nature and the need for prototyping. This mistake can also result from spacing develop- ment milestones too far apart. In this case, language creators often invest too much effort into a develop- ment step without testing the language in real life, which makes it difficult to step back if needed. Tool support plays an important role here: inflexible tools often lead to extra work in rebuilding models when the modeling language changes.
Language evolution is inevitable, and modifying a language is easier when only a few people know it and only a few models exist. The language is also less proven at this stage, so there will be more flaws and more room for improvement.
Language Notation
A poorly chosen concrete syntax will drive us- ers away, stopping them from using even the most wonderful language.
Predetermined Paradigm
Choosing the wrong representational paradigm on the basis of a blinkered view (7 percent)
Many people approach DSM with a fixed idea of how to represent systems, such as through text or graphical diagrams. Although 75 percent of the general population reportedly prefer visual rather than textual representations,10 a higher proportion of developers might be predisposed to choose text given its traditional prevalence in programming. Choosing either representation purely on the basis of prejudice is bad, as is ignoring other possibilities such as matrices, tables, forms, or trees. The correct representational paradigm depends on the audience, the data’s structure, and how users will work with the data. Making the wrong choice can significantly increase the cost of creating, reading, and maintain- ing the models.
This error is almost certainly underreported in our sample because, of the available tools, Meta- Edit+ supports the widest variety of representational paradigms. Also, developers who prefer text might have self-selected themselves out of the sample by using a simpler, purely textual editor.
Simplistic Symbols
Using symbols that are too simple or similar (25 percent) or downright ugly (5 percent)
One of the most common failure areas is in the language’s notation—its symbols or icons. Unlike more abstract or general-purpose languages, DSM languages can often find familiar, intuitive represen- tations directly from the problem domain. All too often, however, the symbols for different language concepts are just boxes with the concepts’ names as labels. People recognize things by their shapes, not by labels (if you doubt this, stick the label “lemon” on a banana and see how people react). Also, sym- bols differing in color alone are suboptimal: the brain views color change primarily as a different ver- sion of the same thing, not as a completely different thing. Figure 4 shows an example of both mistakes.
has shown that the best sym- bols are pictograms, not simpler geometric shapes or more complex bitmap or photographic represen- tations.11 Although our sample contained no cases with overly complex bitmap symbols, you should avoid these as well—bitmaps scale poorly (particu- larly with aspect-ratio changes) and have little room for text or other contents.
26 IEEE SoftwarE
www.computer.org/software
Symbols have an aesthetic role, and few people are fortunate enough to have both the abstract thinking that language design requires and the artistic skills needed to create great symbols. Not surprisingly, the few truly ugly languages in our sample encountered significant opposition from users. Take such opposition seriously: find some- one with decent graphic design skills to improve your symbols.
Language Use
All too often, language creators forget that lan- guages are made to be used and to serve their users. Percentages here are only of those languages that have already seen significant use by people other than their creators.
Ignoring the Use Process
Failing to consider the language’s real-life usage (42 percent)
It’s notoriously hard to predict how people will use a new system
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com