Skip to content
This repository was archived by the owner on Jun 25, 2025. It is now read-only.

Data Model

Jump to bottom
abencomo edited this page Jun 2, 2014 · 17 revisions

The Activity Dictionary (also referred to as the AD) is the basic method by which data is defined and manipulated in the SPIFe planning framework. The intent of the data modeling is to allow users to define metadata on data objects, as well as capture javascript formulas to define effects and constraints / requirements for any data element.

The Metamodel

The definition of the Activity Dictionary can be found in the gov.nasa.ensemble.dictionary plugin under /model/Dictionary.ecore. This model is effectively an extension of EMF's ecore meta-model. The fundamental modeled element in the Dictionary.ecore is the EActivityDef. This is an extension of EClass and adds some basic attributes like duration, description, category, as well as the more complex list of containment references such as effects (claimable, numeric, state, shared, etc) and requirements (numeric, state). The Dictionary.ecore is a metamodel which defines the types of things allowed by the model itself. Creating a model is akin to implementing the language provided and supplying a set of EActivityDef elements, each with a unique set of metadata to capture and persist data, as well as a set of effects and requirements that are processed in order to define the validity and/or impact of the activity on its environment. In other words, the Dictionary.ecore is NOT the actual model, but a metamodel that defines the things capable of being described by an SPIFe planning application natively without code changes / recompilation.

If you are not familiar with with modeling technologies, then you can think of a metamodel as a way of defining Java classes (that is, hierarchy relations, fields, method signatures, and so on).

###Implementing an AD

Implementing a model using the Dictionary.ecore yields the meta-model for the plan itself. Thus, from the perspective of the AD, the Dictionary.ecore is a metamodel, but from the perspective of the plan, the Dictionary.ecore is a meta-meta-model. Regardless of the level of modeling, implementing an Activity Dictionary is highly domain specific. Defining WHAT EActivityDef elements are available and what their metadata / effects / requirements / constraints are is highly specified to the task that is being planned and scheduled for. This information is intended to be agnostic of the persistence mechanism used to store the data. Using EMF's ecore, the data can be modeled for use in any file file or database schema. Creating a model from the Dictionary.ecore is similar to creating a model based on EMF's ecore so it can be done using standard Eclipse EMF editors.

####ActivityDef The main component of the Activity Dictionary is the EActivityDef element. It defines the metadata, resource effects and constraints in a static way. That means that for each defined EActivityDef, subsequent instantiation of those elements in the plan will statically contain the information defined.

Some of the most salient features of the activity definition are:

  • Parameters - Either as a simple type (int, double, boolean, etc) or as an object type (e.g. pointing to instances of ObjectDefs), they allow planners to specify the metadata of the activity.
  • Requirements - The activity specification of resource requirements to evaluate at runtime for potential violations.
  • Effects - The effect that the activity can have on resources (start and end effect).

####ObjectDef The ObjectDef is a way to specify the additional objects in the planning scenario. CrewMembers are a great example in that they are complex objects that have time, claim and availability restrictions.

####EResourceDef Resources are defined as the environmental things we wish to track. They can either be in terms of discrete modes (EStateResourceDef) or numeric resources that have a range of possible values (ENumericResourceDef).

###Plan Representation

As opposite to the Activity Dictionary, the plan model is actually an EMF ecore model. The core plan representation consists of three main concrete EMF classes:

  • EPlan representing the plan as a whole
  • EActivity representing a single activity or event
  • EActivityGroup representing a group of related activities or events

SPIFe uses several EMF models and they can generally be found as files with the extension .ecore in the model folder of a plugin.

All plan elements have a reference property called 'data' which holds onto any EMF object and makes it editable without the need for compilation. Note that this holds onto an EMF EClass and not necessarily an EActivityDef object like in the AD. This allows for expanded association of Activities and the data that it can hold.

plan_model

The plan hierarchy is modeled using parent and children references (similar to UML associations). Instances of EActivity and EActivityGroup can have a parent so they extend EPlanChild, while instances of EActivityGroup and EPlan can have children so they extend EPlanParent. Instances of EActivity can also have other instances of EActivity as children subactivities. Both EPlanChild and EPlanParent extend EPlanElement, which represents the common aspects of all three concrete classes such as a name attribute, a unique persistent identifier for an element ("persistentID"), and the depth of an element in the plan hierarchy ("depth").

The core plan representation only models the structural aspects of a plan; other aspects are modeled for each instance of EPlanElement by associating instances of EMember using the members reference. A number of different subclasses of EMember have been defined to model different types of information that may be important in representing and analyzing plans. The CommonMember class has attributes affecting the display appearance of a plan element such as "color", "expanded", and "visible" and well as a "notes" attribute for associating descriptive text and a "diffID" attribute used in comparing plans.

####Temporal Member

The TemporalMember class is used to represent the start time, duration, and end time of a plan element and to control how the temporal information for a parent activity group relates to the temporal information of its child activity groups and activities. If the useChildTimes attribute for an activity group is true, then the start time of the activity group is determined from the earliest start time of its children and the end time of the activity group is determined from the latest end time of its children. On the other hand, if the useParentTimes attribute for a child plan element is true, then the start time, duration, and end time of the child element are determined by offsets relative to its parent plan element. The startOffsetTimepoint and endOffsetTimepoint attributes indicate whether the start time (resp. end time) of the child element is offset with respect to the parent elements start or end. The startOffsetAmount and endOffsetAmount attributes give the size of the respective offsets.

temporal_model

####Additional Types of EMembers

  • PlanTemporalMember (TemporalPlanning.ecore) -- A PlanTemporalMember is only associated with the plan as a whole (an EPlan) and is a subclass of TemporalMember. It associates two additional attributes with the plan, startBoundary and endBoundary, which specify the range of the plan to be displayed in the timeline tab of the plan editor.
  • ADPlanMember (ActivityDictionaryPlanning.ecore) -- An ADPlanMember is only associated with the plan as a whole and may be used to store the version of the Activity Dictionary that is used with the plan (activityDictionaryVersion).
  • ADEffectMember (ActivityDictionaryPlanning.ecore) -- An ADEffectMember for an EActivity is used to store the specific effects determined for the activity by the ResourceUpdater and DependencyMaintenanceSystem based on information associated with the activity's EActivity in the Activity Dictionary. Effects may be expressed as formulas in the Activity Dictionary that depend on the activity's parameters and/or the state of resource profiles at a time related to the activity's occurrence.
  • ConstraintsMember (ConstraintsPlanning.ecore) -- The ConstraintsMember for an EActivity or an EActivityGroup stores lists of the different types of temporal constraints that have been applied to the EActivity or EActivityGroup. A temporal constraint may be a BinaryTemporalConstraint expressing a relationship between two plan elements, a PeriodicTemporalConstraint expressing earlier and/or latest times of occurrence for a plan element during the day, or a TemporalChain constraining the order of occurrence of two or more plan elements.
  • HibernateMember (HibernatePlanning.ecore) -- The name of the HibernateMember is a residue of an earlier implementation of persistence for SPIFe plans that used the Hibernate object-relational mapping library for Java to store plans in a relational DB. Currently, it is only used for a runtime linkage to a non-EMF object that is an instance of the class gov.nasa.ensemble.core.plan.Plan. The Plan object is used as an anchor for storing instances of a number of non-persisted, non-EMF IMember (contrast EMember) classes that are associated with the plan and allow additional information to be stored with a plan while it is being edited.
  • ProfileMember (ResourceProfile.ecore) -- The ProfileMember associated with an EActivity stores a list of ProfileConstraints (in the constraints reference) and a list of ProfileEffects (in the effects reference) that have been associated with that EActivity.
  • ResourceConditionsMember (ResourceMembers.ecore) -- The ResourceConditionsMember is only associated with the plan as a whole and is used to store a list of instances of Conditions (also called Incons for "Initial Conditions") that give data values at a particular point in time (often the plan start time) for resources that the plan may affect.
  • PlanAdvisorMember (AdvisorPlanning.ecore) -- The PlanAdvisorMember is only associated with the plan as a whole and stores a list of instances of WaiverPropertiesEntry (in the waivers reference) that indicate plan-level constraints that have been waived.
  • ActivityAdvisorMember (AdvisorPlanning.ecore) -- The ActivityAdvisorMember associated with an EActivity stores a list of instances of WaiverPropertiesEntry (in the waivers reference) that indicate constraints that have been waived for the particular EActivity.

####Types of IMembers

  • PlanAdvisorMember -- acts as a coordination point for the set of plan advisors, distributing plan change notifications to the plan advisors, receiving updated lists of violations from the plan advisors, and managing listeners (instances of AdvisorListener) for violation changes and other advisor events.
  • PlanModifierMember -- stores an instance of IPlanModifier used to make modifications to the plan, either a DirectPlanModifier that allows free movements of plan elements of a SpifePlanModifier (extends ConstrainedPlanModifier) that augments direct movements of plan elements with movements of related plan elements so that temporal constraints are not violated.
  • ResourceUpdater -- works out the effects of plan activities on resource profiles using a dependency network (DependencyNetworkManager).
  • TemporalEdgeManagerMember -- used by the ActivityRequirementPlanAdvisor and the ProfileConstraintPlanAdvisor to keep track of the start and end times of activities and the times of resource profile data points.
  • TemporalNetworkMember -- used by the ConstraintsPlanAdvisor to determine when the plan's network of temporal constraints is inconsistent and to provide suggestions on how to fix discovered inconsistencies.
  • ResourceProfileMember -- used to associate resource profiles with a SPIFe plan. A list of all the Profiles can be retrieved with the getResourceProfiles method and a specific Profile can be retrieved given its ID using the getProfile method.

Clone this wiki locally