Creation of the Domain-Model
Before we can start with the domain model for our application we need to know
what the model is going to be for. So let me explain the application we are
going to write in this blog series:
Suppose the Eclipse Foundation hired you to write an application which allows them to administrate their committer and project metadata.
We now need to create a domain model of this minimal information given
which could potentially look like this:
Let’s take a closer look on the domain model objects:
- Foundation
The root of the domain model is the foundation which has 2 list properties:- projects: top level projects like EMF, Technology, Platform, …
- persons: persons who take a part in one ore multiple projects
- Project
An Eclipse project has many different properties from the project start to the project end date to the url of the homepage. The most interesting ones are:- subprojects: a project can have subprojects who can then itself have subprojects
- parent: a project has one parent pro ject (beside the top-level ones) – this means projet-subprojects relation is modeled as a bidirectional relationship
- projectleads: a projet can have multiple project leads
- committers: a project has multiple committers
- CommitterShip
People who are committers on a project get a so called committership which has a start and end date. The most interesting of them are:- project: the project the committership is for – this means once more that the committership-project relation is modeled as a bidirectional relationship
- person: the person who holds the committership
- Person
The “real” person who gets committer or project lead on a project. The field of interest here is:- committerships: which holds all committerships a person has this means that the committership-person relation is also once more modeled as a bidirectional relationship
To get a highlevel overview above the model and how the classes are related together the Class-Diagram helps a lot:
As you noticed I modeled many of the relations as bidirectional relations. This is not strictly need everywhere because some of the relations like project-subproject have an implicit parent relation because they are containments and hence eContainer() could be used to access the parent. Still when it comes to databinding such a containment relationship doesn’t help because there’s no feature you can use to navigate from child to container but only the call to the method eContainer().
EMF also provides an editor to create an instance of your Ecore-Model and save it to XMI which makes it easy for us to create test data. An example of an XMI looks like this:
Tomsondev Blog 
Pingback: Galileo: Improved EMF-Databinding-Support « Tomsondev Blog
Hi Tom,
great work! I like the example.
You say “there’s no feature you can use to navigate from child to container but only the call to the method eContainer”. Wouldn’t it make sense to add support for this to the EMF data binding?
Michael
I already thought about it – the main problem is that there’s no event when reparenting elements IIRC but we could definately take a look at this in 2.6 to see if we can provide such a feature.
Pingback: 2010 in review « Tomsondev Blog
Pingback: 10 common EMF mistakes « Nirmal's Blog
Very useful. I have a thorny issue though: How do you use this if there is no feature from the source to the target, only in the reverse direction? I.e. you want a->b (0..*), but the ecore only contains b->a(0..1) I am not sure how to implement the ObservableFactory under these circumstances.
unfortunately there’s no way. You’d have to define eOpposites