This chapter is from the book
This chapter is from the book
This chapter is from the book
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.
)
Figure 3-10 Object-oriented core domain model
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.
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