Page History

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:

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.

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.

EStructualFeature

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

EAttribute

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

class OrgUnit {
	String name
}
class Person {
	String name
}

abstract class Named {
	String name
}

class OrgUnit extends Named
class Person extends Named

Both OrgUnit and Person instances have a name attribute.

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

EReference

Has a name, type (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.

class OrgUnit {
}
class Person {
}
OrgUnit <- Person: 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.

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.

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).

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