Versions Compared

Old Version 26

changes.mady.by.user Unknown User (hal)

Saved on

compared with

New Version 27

changes.mady.by.user Unknown User (hal)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • With a code-centric perspective, you create Ecore classes with the features that allows needed for the generator to generate the desired Java classes, fields and methods.
  • With a runtime-perspective, you think of the Ecore classes as a way of constraining the object structures that are allowed during runtime.

...

ConstructRuntime instance structures

EClassifier

Abstract superclass of EClass and EDataType

 

EClass

The class construct, has a name and can be abstract (cannot be instantiated) and also marked as interface (no state, just methods). A container of so-called structural features (attributes and associations). May have a list of superclasses (EClass).

Example:

PlantUML Macro
class OrgUnit
class Person

Non-abstract classes can be instantiated. Instances will have attributes values and links to other objects corresponding to contained and inherited features.

 

PlantUML Macro
object "~#o1 : OrgUnit" as o1
object "~#p1 : Person" as p1

EDataType

A non-modelled or "foreign" type, provided by the host language and runtime environment, like int, double, String, Date etc. Many such types are pre-defined by Ecore, e.g. EInt, EIntegerObject, EDouble, EDoubleObject, EBoolean, EBooleanObject, EString, EDate corresponding to Java's int, Integer, double, Double, boolean, Boolean, String and Date types. You can define your own, to be able to use other Java types in your model.

Instances of the corresponding (non-abstract) Java classes can be created from Strings.

EStructualFeature

Abstract superclass of EAttribute and EReference. The distinction between these two is the kind of type they have, EDataType and EClassifier, respectively.

 

EClass, respectively, so when adding a "property" to a class you decide which of EAttribute and EReference to use based on whether the type is an EDataType or EClass.

An EStructuralFeature has a 

EAttribute

Has a name, type (an EDataType) and multiplicity (lower and upper bounds).

 

EAttribute

An EStructuralFeature where the type is an EDataType.

 

PlantUML Macro
class OrgUnit {
	String name
}
class Person {
	String name
}
or using inheritance
PlantUML Macro
abstract class Named {
	String name
}

class OrgUnit extends Named
class Person extends Named

Both OrgUnit and Person instances have a name attribute.

 

PlantUML Macro
object "~#o1: OrgUnit" as o1 {
	name = "IDI"
}
object "~#p1: Person" as p1 {
	name = "Hallvard"
}

EReference

Has a name, type (An EStructuralFeature where the type is an EClass) and multiplicity. Corresponds to the target role of an association from the owning EClass to a target EClass. The association itself is not explicitly modelled.

PlantUML Macro
class OrgUnit {
}
class Person {
}
OrgUnit <- Person: works-in

PlantUML Macro
object "~#o1: OrgUnit" as o1 {
	name = "IDI"
}
object "~#p1: Person" as p1 {
	name = "Hallvard"
}
o1 <- p1: works-in

Two EReferences may be each other's opposite, meaning they correspond to roles of the logically same association. This implies the consistency requirement that if one instance refers to another, the other must refer back, and vice versa.

 

PlantUML Macro
class OrgUnit {
}
class Person {
}
OrgUnit "works-in" <--> "workers *" Person

Consistency requirement: Since o1 has workers links to p1 and p2, p1 and p2 must both have a works-in link to o1.

PlantUML Macro
object "~#o1: OrgUnit" as o1 {
	name = "IDI"
}
object "~#p1: Person" as p1 {
	name = "Hallvard"
}
object "~#p2: Person" as p2 {
	name = "Letizia"
}
o1 <-- p1: works-in
o1 --> p1: workers
o1 <-- p2: works-in
o1 --> p2: workers

EOperation

Corresponds to methods. Includes return type (EClassifier), typed (EClassifier) parameters and a list of types it may throw (EDataType).


PlantUML Macro
class OrgUnit {
   void fire(Person)
}
class Person {
}

 

...

An annotation is added as an EAnnotation object to a model element, and its source attribute is used as a qualifier to identify its meaning/purpose. This qualifier is typically an URI or qualified name that identifies the tool that uses it. E.g. to use Ecore-specific annotation you use http://www.eclipse.org/emf/2002/Ecore as the source attribute value. The annotation data are added as key-value pairs and value in the annotation's details map.

Model elements as meta-objects

When you build an Ecore model, whether using the tree-based editor, Ecore tools diagram editor or Xcore text editor, you are actually building an object structure, a structure of so-called meta-objects (meta because they are at a conceptual level above the instances of the classes they model). E.g. in the example above, OrgUnit and Person are instances of the EClass, the name attribute is an instance of EAttribute and the workers and works-in references are instances of EReference. The figure below shows the standard class diagram notation (left) and the corresponding object diagram of the meta-objects (right).

Class diagramObject diagram of meta-objects

PlantUML Macro
abstract class Named {
	String name
}
class OrgUnit {
   void fire(Person person)
}
class Person {
}
OrgUnit "works-in" <--> "workers *" Person

PlantUML Macro
object "~#c1 : EClass" as Named {
	name = "Named"
	abstract = true
}
object "~#c1 : EAttribute" as nameAttr {
	name = "name"
	lower = 0
	upper = 1
}
object "~#dt1 : EDataType" as EString {
	name = "EString"
	instanceClassName = "java.lang.String"
}
nameAttr --> "eType" EString
Named *--> "eStructuralFeatures" nameAttr
 
object "~#c2 : EClass" as OrgUnit {
	name = "OrgUnit"
}
object "~#c3 : EClass" as Person {
	name = "Person"
}
object "~#m1" : EOperation" as fire {
	name = "fire"
}
object "~#p1" : EParameter" as personParam {
	name = "person"
}
fire *--> "eParameters" personParam
OrgUnit *--> "eOperations" fire
 
object "~#r1 : EReference" as worksInRef {
	name = "works-in"
	lower = 0
	upper = 1
}
worksInRef --> "eType": OrgUnit
Person *--> "eStructuralFeatures" worksInRef
 
object "~#r2 : EReference" as workersRef {
	name = "workers"
 	lower = 0
	upper = -1 // unbounded
}
workersRef --> "eType": Person
OrgUnit *--> "eStructuralFeatures" workersRef
 
workers "eOpposite" <--> "eOpposite" worksInRef