See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/220091931

ModelTalk: When Everything Is a Domain-Specific Language

Article in IEEE Software · July 2009

DOI: 10.1109/MS.2009.97 · Source: DBLP

CITATIONS READS

24 572

4 authors, including:

Atzmon Hen-tov David H Lorenz

Aternity The Open University of Israel
13 PUBLICATIONS 51 CITATIONS 93 PUBLICATIONS 1,256 CITATIONS

SEE PROFILE SEE PROFILE

Lior Schachter
The Open University of Israel
7 PUBLICATIONS 50 CITATIONS

SEE PROFILE

All content following this page was uploaded by Atzmon Hen-tov on 23 February 2014.

The user has requested enhancement of the downloaded file.

focus
domain-specific modeling

ModelTalk:
When Everything
Is a Domain-Specific Language
Atzmon Hen-Tov, Assaf Pinhasi, and Lior Schachter, Pontis

David H. Lorenz, Open University of Israel

L
arge-scale, complex, back-end business applications such as telecommunications
ModelTalk, a model-
software constitute a highly competitive and demanding market. These appli-
driven software
cations feature deep integration with other business and operational support
development systems. They must be tailored for each customer, and the customized systems
framework, supports must meet strict extrafunctional requirements, commonly called “telco’s five 9s” (99.999
the creation of percent availability). All this, combined with the need for an agile development process
product lines by with a short time to market, presents a software development and business challenge.
using domain- One way to cope with this challenge is to con- claratively implement concrete requirements.
specific languages struct a software product line.1 You establish an When considering broad adoption of DSLs in
initial collection of rich, generic, reusable software the development organization, you should antici-
pervasively at components. These shared assets of the product pate and carefully plan for increased DSL usage.
the core of the line are then methodically assembled, custom- You wouldn’t want to end up with numerous,
development process. ized, and fine-tuned for each production system. disconnected DSLs, requiring your developers
But you must also have a reliable, concise customi- to master many concrete syntaxes, development
zation process to go with your product line. Such styles, and tools. That might lead to a great cogni-
a process is necessary for performing pervasive tive burden, ironically inhibiting the same agility
modifications to the shared assets quickly without you were trying to achieve by establishing a DSL-
compromising their robustness. based development process in the first place.
Model-driven development (MDD) is often the Once you transition to DSL successfully and
development process of choice.2 This is where do- manage DSL scalability wisely, you’ll discover that
main-specific languages (DSLs) enter the picture.3 much of your software development effort has suc-
DSLs possess two, highly desirable characteris- cessfully shifted from writing imperative code to
tics. First, they facilitate variability management writing declarative composition and customization
in MDD by providing the means for express- scripts. This is the case with ModelTalk, a DSL au-
ing customization concisely and often declara- thoring and execution framework.4
tively. They also support a producer-consumer
development process, in which one group of devel- Approach
opers defines a DSL around components and con- The ModelTalk motto is “Everything is a DSL.”
cerns, while other developers use that DSL to de- DSLs can be extended and composed. They’re

0 74 0 -74 5 9 / 0 9 / $ 2 5 . 0 0 © 2 0 0 9 I E E E July/August 2009 I E E E S o f t w a r e  39

 form, and Business—contain shared assets. At the
Particular assets (15 final products) top layer (Customization), where final products are
Customization assembled and customized, 83 percent of the code
83.34%
is written in DSLs and just 17 percent in Java. The
relatively large amount of DSL code (approximately
Shared assets
200 Kbytes of LOC) reflects large variation among
Business 59.82% final products. To achieve similar variability using
Layers

only Java would have required many more LOC

Platform 34.37% without providing the same compact, precise se-
mantics that DSLs offer.
Core 9% Java lines of code The ModelTalk approach is based on three de-
DSL lines of code
sign principles that, when combined effectively,
0 50 100 150 200 250 enable programming with DSLs to scale up well:
Size (KLOC) textual DSLs, an integrated DSL-Java development
DSL: Domain-specific language environment, and an interpretive approach.

Figure 1. The ratio of Java (purple) to DSL (gold) code by architectural Textual DSLs
layer in a product line of business support systems. Most of the In ModelTalk, DSLs are textual rather than graphi-
assembly and the customization of products is done with DSLs. cal. The concrete syntax for DSL code is XML. The
ModelTalk core provides a general-purpose lan-
guage with abstractions (Class, Property, and so on)
Feedback
and syntax rules for defining DSLs. A developer
DSL and Java integrated Runtime creates a new DSL by adding new and constraining
development environment platform existing class properties to better describe the do-
DSL Executable DSL execution
main-specific concepts and terminology. In XML,
DSL sources
processors DSL code engine these are expressed via tag names, which constitute
the domain-specific terminology.
Constrains Conforms

Java Java Java Java Virtual

Integrated DSL-Java
sources processors bytecode Machine Development Environment
ModelTalk comes with a unified IDE for DSL and
Java, implemented over Eclipse (see Figure 2). The
Feedback DSL: Domain-specific language DSL development process in ModelTalk is analo-
gous to the Java development process. By provid-
Figure 2. An integrated ing IDE support for DSL scripting with the same
environment for DSL written in (meta) DSLs, specializing and containing look and feel as for Java programming, Model-
and Java development. instances of other DSLs, all governed by the same Talk achieves instant productivity in the IDE and
DSL development syntactical rules. easier assimilation and adoption of DSL-based
mirrors Java A system implementation in ModelTalk consists development.5
development, and DSL of The ModelTalk IDE reflects changes in DSL def-
code governs Java code. initions immediately, providing DSL programmers
■■ declarative DSL code containing definitions of with full support for autocompletion (during edit-
stateful instances, classes, and metaclasses that ing), navigation, and consistency checking. When
describe the system’s structure and configura- developers save their work, the Eclipse IDE auto-
tion; and matically invokes the ModelTalk DSL analyzer (a
■■ localized Java code containing methods that DSL processor in Figure 2), performing incremental
define the system’s behavior separate from the cross-system validation similar to background com-
structure and configuration data. pilation in Java.
After the developers have modeled and cap-
DSL code is the dominant part of the system. For tured the domain in a DSL, they implement the
example, Figure 1 depicts the distribution of DSL behavior in Java. During this stage, the DSL ana-
and Java code in a subsystem of an actual com- lyzer monitors incompatibilities between the Java
mercial business support system for the telecom- and DSL elements and reports violations in the
munications market developed with ModelTalk. IDE’s standard Problems view. Additional views
The ModelTalk architectural layers—Core, Plat- let developers browse and navigate the DSLs

40 IEEE Soft ware w w w. c o m p u t e r. o rg /s o f t w a re

(between one DSL element and another, as well
as between DSL elements and their Java counter- Product A: IEEE example

Particular assets
Customization

Product B

Product Z
parts). A refactoring tool for DSLs is also avail-
able, and changes are propagated to Java when Subscription HappyHour …
necessary.

Interpretive Approach

Business
DSLs in ModelTalk are interpreted; they don’t Goods Promotion Eligibility
need to be transformed into Java (by a code gener-
ator). At runtime, instances of DSL classes are in-

Shared assets
stantiated and used as meta-objects for their corre-

Platform
sponding Java instances through a technique called
Persistency Data-model
(model-driven) dependency injection.6 The DSL
execution engine is ModelTalk’s runtime compo-
nent, implemented as an inversion-of-control
container and a dependency injection framework
Core
Meta DSL Specializes
(in the Spring framework style). It can run either Contains
inside a standard J2EE application server (for ex-
ample, JBoss) or inside a lightweight container.
The execution engine’s primary responsibility is Figure 3. The ModelTalk
to maintain the relationships between the DSL and DSLs for use by domain experts (nonprogram- producer-consumer
Java elements. This includes object graph instanti- mers). In ModelTalk, however, developers both layered architecture.
ation and a reflection API.7 When a client requests produce and consume DSLs. Each developer The bottommost layer
a DSL instance, the DSL engine finds the corre- team specializes in a set of domains and shares defines the most
sponding Java class, instantiates it, and injects the its expertise with other teams via DSLs. This cre- generic Meta DSL.
property values into its instance variables. This is ates a supply chain of DSLs in the development DSLs at higher layers
applied recursively for injected values of a complex organization while organizing the DSL artifacts specialize DSLs at
type. The DSL-to-Java mapping allows for DSL in layers. lower layers. The
classes without a Java counterpart. In such cases, All developers are consumers of DSLs residing topmost layer contains
the DSL engine maps the class to its superclass’s at the Core layer. The technical experts are pro- the assembled products
Java counterpart. Consequently, developers and ducers (and the application and customization de- (products A through Z).
even users can change DSL definitions at runtime velopers are consumers) of DSLs at the Platform
without needing to also change the Java code.8 layer. The application developers are producers
The DSL execution engine eliminates the ab- (and the customization developers and business
straction gap between the rich ModelTalk meta- experts are the consumers) of DSLs at the Busi-
model and the one provided in Java, bringing ex- ness layer. The customization developers are pro-
plicit metaclass9 and other advanced capabilities ducers (and the business experts are consumers)
into Java. of DSLs at the Customization layer.

DSL-Based Software Development Architectural Layers

In ModelTalk, the framework developer uses DSLs ModelTalk’s Core layer resembles the Smalltalk
to declaratively expose variability points in impera- system core. This layer contains the DSL execu-
tive code. This exposure makes the variation man- tion engine and provides the basic capabilities for
agement explicit and moves application assembly defining and executing DSLs. Because all DSLs
from the realm of code-level development to that of in ModelTalk are specializations of a (meta)
declarative composition. DSL defined in Core, they all share the same ba-
sic syntax and semantic characteristics. This is a
DSL Reuse key enabler in achieving uniformity in user ex-
In ModelTalk, DSLs are interconnected (see Figure perience and tooling; for example, autocomple-
3). A DSL can specialize another DSL by narrow- tion (during editing), navigation, and consistency
ing the semantics to a more specific domain. A DSL checking operate generically on all DSLs. Further-
instance can contain an instance of another DSL. more, ModelTalk’s interpretive nature eliminates
the need for tool regeneration when a metamodel
DSL Supply Chain definition changes, as is commonly required in
Traditionally, developers (programmers) produce other DSL frameworks.10

July/August 2009 I E E E S o f t w a r e  41
 The Platform layer defines a rich set of DSL alerts the developer about inconsistency between
building blocks for creating business applications. existing DSL instances and their class definition.
In ModelTalk, Many of the DSLs defined in the Platform layer
Implementing DSLs in ModelTalk
the framework are bridges to third-party technologies, such as the
J2EE standard, the Spring framework, Hibernate, To explain the steps in defining instances, properties,
developer and Apache Axis. Concrete examples of DSLs in classes, methods, and metaclasses in ModelTalk,
uses DSLs this layer include Persistency and Data-model. Persistency
wraps the Hibernate framework with a DSL for
we’ll use a simplified example of an online market-
ing system that business experts use to launch tar-
to declaratively handling persistency concerns (for example, que- geted promotions on specific goods.
expose ries and object/relational mapping). The Data-model
DSL uses the Persistency DSL to define business enti- Instances
variability ties. Wrapping a third-party framework in a DSL Figure 4a shows a DSL instance named IEEE_HH.
points in hides in effect the technological complexity from This instance “is kind of” Promotion (in the Smalltalk
imperative the application developers, enabling them to focus
on their domain’s business logic.
sense)—specifically, a member of HappyHour (see the
listing in Figure 4b). It defines a happy-hour dis-
code. The Business layer is a collection of generic, count on subscriptions to IEEE Software targeted
reusable DSLs and constitutes the business logic. at students: $20 off during October 2009. While
Example DSLs residing here for an online mar- specifying this promotion, the DSL programmer
keting system include Goods, Promotion, and Eligibil- is constrained by the type HappyHour. All properties
ity. Goods defines the products and services offered must be assigned a value—that is, who is eligible for
to the customer. Eligibility defines the notion of cus- the promotion (Figure 4a, lines 2−6), the campaign
tomer segments and a set of operators that can time frame (lines 7−10), the incentive given to buy-
be applied to them. Promotion specializes Data-model ers (lines 11−14), and the goods participating in the
and uses Goods and Eligibility. It defines the notion promotion (line 15).
of a product being on sale—that is, the incentive
offered, the targeted segment, and the specific Properties
goods. When editing a DSL instance, you may assign val-
At the top resides the Customization layer, ues only to properties that are defined in the DSL
in which the complete customized systems (final class. The assigned value must be of a type that
products) are assembled mainly from Business- matches the constraints defined in the DSL class.
layer DSLs. DSLs from the Platform layer are also For properties of a complex (user-defined) type, you
used occasionally to customize deep aspects of the must specify an explicit type attribute. In the reward
system. The Customization layer is managed sep- property (Figure 4a, line 11), any subclass of Benefit-
arately for each customer or group of customers, Giver can serve as the type. For example, the menu
and customer-specific features are developed here. in Figure 5e lists FixedAmountDiscount, FixedPercentage-
In the example, Subscription and HappyHour special- Discount, and SubscriptionPeriodExtension as subclasses of
ize Goods and Promotion, respectively, to the IEEE’s BenefitGiver.
specific needs. Choosing the type of a complex property is
significant. At the semantic level, the type deter-
Variability Management and Evolution mines the system behavior. At the mechanical
ModelTalk accommodates the evolution of DSLs. level, the type determines the inner properties that
A new DSL is initially implemented in the Custom- the user should fill in. Setting Fixed­P ercentageDiscount
ization layer as a one-off customer-specific effort. as the type of benefit instead of FixedAmount­D iscount
At that stage, the need for variability is limited, (Figure 4a, line 11) would require the user to
so the DSL exposes only a few variability points. specify the discount percentage instead of the
Gradually, as new requirements accumulate, the amount and currency. The ModelTalk IDE au-
DSL developer identifies and implements new vari- tocompletion feature relieves the programmer
ability points. When the DSL developer recognizes from memorizing the valid choices. This compo-
a potential for significant reuse, additional develop- sition process is recursive, supporting the defini-
ment effort is put into pushing the DSL upstream tion of nested instance graphs. To promote reuse,
in the supply chain—that is, moving the DSL to a ModelTalk also supports references to external
lower layer. The DSL evolves from being a particu- instances as an alternative to inline definitions;
lar asset to being a shared asset. see, for example, the reference to IEEE_Software_
A variability point in ModelTalk is essentially Subscription (denoted by the suffix Ref—that is, by
a DSL class property. When DSLs evolve, the IDE business:SubscriptionRef in Figure 4a, line 15).

42 IEEE Soft ware w w w. c o m p u t e r. o rg /s o f t w a re

Figure 4. Three example DSL instances:
(a) a DSL instance named IEEE_HH; (b) a DSL 01 <Promotion ID=”IEEE_HH” type=”ieee:HappyHour”>
class named HappyHour; (c) a DSL metaclass 02 <eligibility type=”business:EligibilityBySegments”>
named EntityClass. The ModelTalk metalevel 03 <includedSegmentsList>
architecture treats instances, classes, and 04 <item type=”business:SegmentRef” ref=”IEEE_Students”/>
metaclasses uniformly. 05 </includedSegmentsList>
06 </eligibility>
07 <dateOfPurchase type=”business:TimeWindow”>
08 <fromTime>2009-10-01T00:00:00</fromTime>
Classes 09 <toTime>2009-11-01T00:00:00</toTime>
The syntax for a DSL class definition is the same 10 </dateOfPurchase >
as for instances. For example, HappyHour (see Fig- 11 <reward type=”business:FixedAmountDiscount”>
ure 4b) is an EntityClass (and a “kind of” ModelTalk 12 <amount>20</amount>
class). It extends the Promotion class, thus inheriting 13 <currency>USD</currency>
its structure and behavior. It defines an additional 14 </reward>
dateOfPurchase property (Figure 4b, lines 10–16) in 15 <product type=”business:SubscriptionRef” ref=”IEEE_Software_Subscription”/>
which users can set the effective time of the promo- 16 </Promotion>
tion campaign. (a)

01 <Class ID=”HappyHour” type=”platform:EntityClass” extends=”business:Promotion”>

Methods 02 <persistenceSpec type=”platform:ClassPersistencySettings”>
The DSL producer writes the HappyHour behavior di- 03 <tableName>HAPPYHOUR</tableName>
rectly in Java (see Figure 6a). The ModelTalk DSL 04 <fetchStrategy type=”EagerFetcher”>
engine combines on demand the structural and the 05 <fullDepth>true</fullDepth>
behavioral definitions. For example, when a client 06 <retrieveReferences>false</retrieveReferences>
code requests a DSL instance, perhaps by invoking 07 </fetchStrategy>
ModelTalk.getInstance(”IEEE_HH”), the HappyHour class in 08 </persistenceSpec>
Figure 6a is instantiated in the Java Virtual Ma- 09 <properties>
chine and injected (via dependency injection) with 10 <property type=”core:ComplexType”>
the values specified in IEEE_HH (see Figure 4a). The 11 <name>dateOfPurchase</name>
injected values are then readily available to the cli- 12 <type>ScheduleDef</type>
ent. For example, the call getDateOfPurchase (see Fig- 13 <description>
ure 6a, line 5) returns a TimeWindow instance (see 14 Schedule in which the happy hour is active
Figure 6b), injected with the dateOfPurchase value 15 </description>
(Figure 4a, lines 7−10). This object is then used to 16 </property>
determine whether the end user is eligible for the 17 </properties>
promotion. 18 </Class>
The HappyHour promotion also exemplifies how (b)
declarative composition controls the system behav-
ior. The specified dateOfPurchase constraint could be 01 <Class ID=”EntityClass” type=”core:Class” extends=”core:Class”>
an instance of any subclass of ScheduleDef (Figure 4b, 02 <properties>
line 12), including TimeWindow, Weekends, and so on. 03 <property type=”core:ComplexType”>
The choice is specified by the type attribute in IEEE_ 04 <name>persistenceSpec</name>
HH (Figure 4a, line 7). The DSL user may configure 05 <type>PersistenceSettings</type>
different HappyHour instances to have different types 06 </property>
of dateOfPurchase. For example, the user can declare 07 </properties>
dateOfPurchase to be of type Weekends, in which case 08 </ Class >
the isInTimeFrame method of Weekends is invoked. (c)

Metaclasses
The HappyHour listing in Figure 4b is an instance of Evaluation and Discussion
a specialized metaclass for persistent classes, called Since ModelTalk’s inception, we’ve been collect-
EntityClass (see Figure 4c). HappyHour specifies the per- ing data (duration of edit-execute cycles, compila-
sistency trait using the Persistency DSL (Figure 4b, tion times, error logs, and other code metrics) to as-
lines 2–8). The same rules that apply to instance sess its effectiveness. Figure 7 presents the growth
composition also apply to classes (and metaclasses). over time of the code base (net user-written code,

July/August 2009 I E E E S o f t w a r e  43
Figure 5. The ModelTalk development environment. A set of Eclipse plug-ins offers Java-like programming tool support
for DSL authoring: (a) Eclipse standard navigator view; (b) ModelTalk instance-of hierarchy view; (c) ModelTalk
source code editor; (d) ModelTalk documentation tool tip; (e) ModelTalk autocompletion menu; (f) Eclipse problems
view; (g) ModelTalk toolbar.

01 public class HappyHour extends Promotion { 01 public class TimeWindow extends ScheduleDef {
02 public boolean isEligible() { 02 public boolean isInTimeFrame() {
03 boolean result = super.isEligible(); 03 boolean result = false;
04 if (result) 04 Calendar currentTime=Calendar.getInstance();
05 result=getDateOfPurchase().isInTimeFrame(); 05 if (currentTime.after(getFromTime()))
06 return result; 06 result=currentTime.before(getToTime());
07 } 07 return result;
08 } 08 }
(a) 09 }
(b)

Figure 6. Java code

samples show the excluding tool-generated code) per architectural gregated code growth in the Customization layer.
behavior of (a) HappyHour layer. System evolution, new features, and enhance- DSL code has both the largest share in our code
and (b) TimeWindow ments account for the growth in shared assets (in base as well as the sharpest growth rate. This in-
instances. the Core, Platform, and Business layers). New cus- dicates that DSLs are at the center of gravity in
tomers and customized products account for the ag- the ModelTalk-driven development process. This

44 IEEE Soft ware w w w. c o m p u t e r. o rg /s o f t w a re

observation is reinforced by the near absence of
unmanaged code (Java code not governed by Mod- 200
elTalk) in the Business layer. DSL Customization
Currently, the framework contains 6,327 classes, Java (managed)
Java (unmanaged)
of which 292 are metaclasses. Tens of thousands of 150
instances are expressed in 381K lines of DSL code.

Size (KLOC)
Users have done most of the customization (83 per-
cent of Customization LOC) declaratively, further 100
indicating that the ModelTalk approach scales well.

Organization Perspective 50
An organization considering adopting an approach
similar to ModelTalk should take into account a
(a)
substantial initial investment in building the infra- 0
structure and tools. In ModelTalk, the initial in-
vestment was more than 10 person-years. There’s 100
DSL Business
also an ongoing cost for maintaining the develop-
Size (KLOC)
Java (managed)
ment environment. Java (unmanaged)
From the human-resources and skills-set per- 50
spective, metaprogramming tends to be highly
abstract and generic, so it requires highly capable
individuals who might also need an adjustment pe- (b) 0
riod before becoming productive. We also learned 100
DSL Platform
over time that our approach is less effective in do-
Java (managed)
Size (KLOC)

mains for which rich graphical tools are mature, Java (unmanaged)
such as user interface design and online analytical 50
processing.
Nevertheless, once a development approach
such as ModelTalk is in place, the benefits for the (c) 0
organization are tangible. Specifically, the time-to-
100
market and the cost of producing individual, cus- DSL Core
tomized products drop significantly. In a particular Java (managed)
Size (KLOC)

project, we needed to integrate a system with eight Java (unmanaged)

50
other systems and support up to 200 transactions
per second per machine. We went from kickoff to a
live system in 17 calendar weeks (10 person-weeks
of customization work, see Figure 8). 0
(d) 09/06 12/06 03/07 06/07 09/07 12/07 03/08 06/08 09/08
Date
Developer Perspective
Overall, developers report satisfaction using

D
ModelTalk and specifically praise the short edit- Figure 7. The amount
execute cycle. Our data corroborate this: the av- omain-specific languages aim to im- of different kinds of
erage incremental build time is less than 10 sec- prove the development process by rais- code in each layer:
onds per build. Customization developers enjoy ing the level of abstraction around a (a) Customization,
especially short build times because changes in specific area of the problem. Typically, develop- (b) Business,
the top layer have less impact on the system. To ers introduce and apply DSLs on a per-case ba- (c) Platform, (d) Core.
maintain these short build times, we periodically sis only after identifying a specific component The gold lines represent
devote development resources to improving the or concern that might benefit from having a DSL code, the gray lines
DSL processors. Developers appreciate the fact DSL around it. In large systems, this approach represent managed Java
that DSL scripting and Java programming take might result in a number of ad hoc, discon- (Java code governed
place in a unified, integrated environment and nected DSLs. Our work here shows the ben- by ModelTalk), and the
that they can work on incomplete or inconsistent efit in embracing DSLs not only for a small blue lines represent
models. Developers express some dissatisfaction number of components or concerns but also as unmanaged Java code.
with the lack of diagramming capabilities or in- building blocks for systematically constructing
teroperability with UML modeling tools. large software systems.

July/August 2009 I E E E S o f t w a r e  45
 Day 89 Day 121
Integration Project
tests start goes live 72%
10 Day 46
Day 21 Ready for integration
8 First major 26%
Size (KLOC)

6 Day 1 quality assurance

Development version
4 starts
DSL
2
Java (managed)
0
Timeline Java (unmanaged)

(a) (b)

Figure 8. A case study of a customization project from kickoff to deployment: (a) the growth of customization code;
(b) breakdown into kinds of code. Once an approach such as ModelTalk is in place, the organizational benefit is clear:
a short time to market.

About the Authors Acknowledgments

We thank Zvi Ravia and the anonymous reviewers for
their helpful comments on the article. ModelTalk was
Atzmon Hen-Tov is the chief software architect at Pontis and has led the develop-
influenced by the TGP (Type, Generic class, Profile)
ment of ModelTalk since its inception. He’s interested in model-driven development and other
methodology developed by Shay Ben-Yehuda. We’re
methods for software development industrialization. Hen-Tov is a member of the ACM and
grateful to Pontis, a leading vendor of online market-
the IEEE. Contact him at [email protected].
ing automation solutions for the telecommunications
market, for granting us access to their development
process and data. This work was supported partly by
the Israel Science Foundation under grant 926/08 and
by the office of the chief scientist of the Israel Minis-
try of Industry Trade and Labor.
David H. Lorenz is an associate professor in the Department of Mathematics and
Computer Science at the Open University of Israel. His research interests include aspect- References
oriented software engineering and programming, particularly involving multiple domain- 1. P. Clements and L. Northrop, Software Product
specific languages. Lorenz has a PhD in computer science from the Technion-Israel Institute Lines—Practices and Patterns, Addison-Wesley, 2001.
of Technology. He’s a member of the ACM and the IEEE. Contact him at [email protected]. 2. M. Voelter and T. Stahl, Model-Driven Software Devel-
opment: Technology, Engineering Management, John
Wiley & Sons, 2006.
3. D.S. Batory et al., “Achieving Extensibility through
Product Lines and Domain-Specific Languages: A
Case Study,” Software Reuse: Advances in Software
Assaf Pinhasi is a senior software architect at Pontis. His interests include domain- Reusability, Proc. 6th Int’l Conf. (ICSR 00), LNCS
specific languages, Web technologies, and scalable software architecture. Pinhasi has 1844, Springer, 2000, pp. 117−136.
a BSc in computer science and mathematics from Tel-Aviv University. Contact him at 4. A. Hen-Tov, D.H. Lorenz, and L. Schachter, “Model-
[email protected]. Talk: A Framework for Developing Domain-Specific
Executable Models,” Proc. 8th Ann. OOPSLA Work-
shop Domain-Specific Modeling (DSM 08), ACM
Press, 2008; www.dsmforum.org/events/DSM08.
5. M. Fowler, “Language Workbenches: The Killer-
App for Domain-Specific Languages?” 2005; http://
martinfowler.com/articles/languageWorkbench.html.
6. M. Fowler, “Inversion of Control Containers and
Lior Schachter is a senior software architect at Pontis and head of the ModelTalk the Dependency Injection Pattern,” 2004; http://
Core team. His interests include model-driven development, domain-specific languages, and martinfowler.com/articles/injection.html.
adaptive systems. Schachter has a BSc in electrical engineering and computer science from 7. D.H. Lorenz and J. Vlissides, “Pluggable Reflection:
Tel-Aviv University. He’s a member of the IEEE. Contact him at [email protected]. Decoupling Meta-interface and Implementation,”
Proc. 25th Int’l Conf. Software Eng. (ICSE 03), IEEE
CS Press, 2003, pp. 3−13.
8. R. Razavi et al., “Language Support for Adaptive
Object-Models Using Metaclasses,” Computer
Languages, Systems and Structures, vol. 31, nos.
3−4, 2005, pp. 188−218.
9. J.P. Briot and P. Cointe, “Programming with Explicit
Metaclasses in Smalltalk-80,” ACM SIGPLAN Notices,
vol. 24, no. 10, 1989, pp. 84−96.
10. B. Selic, “A Systematic Approach to Domain-Specific
Language Design Using UML,” Proc. 10th IEEE Int’l
Symp. Object and Component-Oriented Real-Time
Distributed Computing, IEEE CS Press, 2007, pp. 2−9.

46 IEEE Soft ware w w w. c o m p u t e r. o rg /s o f t w a re

View publication stats