Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Developing a DSL Abstract Syntax with Eclipse : Page 5

Walk through the development of a domain-specific language (DSL) using the Eclipse Modeling Framework (EMF) and supporting components.


advertisement

3.6 Developing the Business Domain Model

Plenty of options exist for developing the domain model that will form the base of our fictitious Business Domain Modeling (BDM) project. We want something less complicated than the Unified Modeling Language (UML) model for structural class modeling, but something expressive enough to generate code either directly or through an intermediate model. Also, the model should constrain the user to the supported methodology and domain of business models. For the purposes of this book, the four archetypes described for business domain modeling in Java Modeling in Color with UML [46] seem like a good option. Figure 3-9 is a partial image of the Domain-Neutral Component (DNC) model, created with the editor we develop in Section 4.6, "Developing the Color Modeling Diagram." Of course, a black-and-white rendering of a color modeling diagram in the printed form of this book is not very compelling.

Figure 3-9. Color archetypes

Basically, a set of archetypes is used to model moment-interval, role, party, place, thing, and description elements and their relationships. The relationships and several described patterns of interaction are provided in the book, which we want to facilitate in our modeling environment. First, however, we need an underlying model (a DSL).



This DSL is strongly rooted in a general object-oriented DSL, so we begin with just that. Figure 3-10 is an oocore.ecore model that we extend to add our archetypes and other DNC elements. Why begin with a general object-oriented DSL? Well, we might decide to use this model as the basis for another DSL in the future. Why not simply extend Ecore itself, you might ask? Well, it contains elements that we really don't need or want, leaving us with all those E-prefixed elements and their properties. Besides, it's straightforward to develop our own object-oriented DSL. We can use the Java EMF Model (JEM) as a transformation target, giving us a chance to see what a model that extends Ecore is like.

Adventurous types can create a new org.eclipse.dsl.oocore DSL project and create the oocore.ecore model, as we have done previously. Complete the model using Figure 3-10 as a reference. Otherwise, simply copy the oocore.ecore domain model from the solutions into your project. Finally, create a new org.eclipse.dsl.dnc DSL project to hold our dnc.ecore model that will extend our core model.

Figure 3-10. Object-oriented core domain model

With our base model complete, we can create our dnc.ecore model. To reference our oocore.ecore model in our newly created dnc.ecore model, we need to use the EMF Load Resource context menu in the default EMF editor. Fortunately, the dialog that appears now contains options to Browse Registered Packages, Browse File System, and Browse Workspace. At one time, you needed to enter platform:/ URIs into the field to load a registered package. In our case, the oocore.ecore model is easily found in our workspace.

In creating our DNC model (Figure 3-11), several options exist, as always. You've seen that using an enumeration to define the type is one solution, as was used in the Mindmap domain model's Relationship class and Type enum. This approach has some drawbacks, including the loss of polymorphic behavior in our templates and transformation scripts. To illustrate the differences, let's go ahead and create an Archetype abstract class that extends our oocore::Class class. Each of our archetypes will extend the Archetype class. We also add an Association class that extends oocore::Reference and add a property to signify aggregation. Although it is not a true Association class in the UML sense, it aids us in developing our diagram and hiding some complexities of the underlying model to the Practitioner. As we develop the diagram and other DSL artifacts, we'll revisit this model and refine it as necessary, potentially pulling up some functionality into the domain model to aid in our color modeling and model transformations.

Figure 3-11. Domain-neutral component domain model

3.7 Summary

This chapter explored the capabilities of EMF as the means of describing our DSL abstract syntax. Although we leave the details of EMF to its own book, we covered enough to get started developing our sample projects. The benefits of leveraging a common underlying metamodel and generation capabilities should become clear as we continue to develop the DSL projects.

At this point, we have starter domain models for our fictitious ERP, plus a reference to a fifth oocore DSL. We now move on to describing how to create graphical concrete syntax for those we want to provide diagrams for, understanding that we will most likely revisit and enhance the EMF models we created in this chapter.

© Copyright Pearson Education. All rights reserved.



Richard Gronback is chief scientist for modeling products at Borland Software Corporation. Richard represents Borland on the Eclipse Board of Directors, co-leads the Modeling project Project Management Committee (PMC), and is the project lead for the Graphical Modeling Framework (GMF) and Modeling Amalgamation projects.
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap