blob: d15152b01266d9a20edb00e6cb08be8d8e85b13a (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
|
//
// ============LICENSE_START=======================================================
// Copyright (C) 2016-2018 Ericsson. All rights reserved.
// ================================================================================
// This file is licensed under the CREATIVE COMMONS ATTRIBUTION 4.0 INTERNATIONAL LICENSE
// Full license text at https://creativecommons.org/licenses/by/4.0/legalcode
//
// SPDX-License-Identifier: CC-BY-4.0
// ============LICENSE_END=========================================================
//
// @author Sven van der Meer (sven.van.der.meer@ericsson.com)
//
== Concepts and Keys
Each element of the policy model is called a __concept__.
Each __concept__ is a subclass of the abstract __Concept__ class, as shown in the next figure.
Every concept implements the following abstract methods:
.Concepts and Keys
image::apex-policy-model/ConceptsKeys.png[Concepts and Keys]
* `getKey()` - gets the unique key for this concept instance in the system
* `validate()` - validates the structure of this concept, its sub-concepts and its relationships
* `clean()` - carries out housekeeping on the concept such as trimming strings, remove any hanging references
* `clone()` - creates a deep copy of an instance of this concept
* `equals()` - checks if two instances of this concept are equal
* `toString()` - returns a string representation of the concept
* `hashCode()` - returns a hash code for the concept
* `copyTo()` - carries out a deep copy of one instance of the concept to another instance, overwriting the target fields.
All concepts must have a __key__, which uniquely identifies a concept instance.
The __key__ of a subclass of an __Concept__ must either be an `ArtifactKey` or an `ReferenceKey`.
Concepts that have a stand-alone independent existence such as __Policy__, __Task__, and __Event__ must have an `ArtifctKey` key.
Concepts that are contained in other concepts, that do not exist as stand-alone concepts must have an `ReferenceKey` key.
Examples of such concepts are __State__ and __EventParameter__.
An `ArticactKey` has two fields; the __Name__ of the concept it is the key for and the concept's __Version__.
A concept's name must be unique in a given PolicyModel.
A concept version is represented using the well known __major.minor.path__ scheme as used in semantic versioning.
A `ReferenceKey` has three fields.
The __UserKeyName__ and __UserKeyVersion__ fields identify the `ArtifactKey` of the concept in which the concept keyed by the `ReferenceKey` is contained.
The __LocalName__ field identifies the contained concept instance.
The __LocalName__ must be unique in the concepts of a given type contained by a parent.
For example, a policy called `_SalesPolicy_` with a Version of `_1.12.4_` has a state called `_Decide_`.
The `_Decide_` state is linked to the `_SalesPolicy_` with a `ReferenceKey` with fields __UserKeyName__ of `_SalesPolicy_`, __UserKeyVersion__ of `_1.12.4_`, and __LocalName__ of `_Decide_`.
There must not be another state called `_Decide_` in the policy `_SalesPolicy_`.
However, there may well be a state called `_Decide_` in some other policy called `_PurchasingPolicy_`.
Each concept in the model is also a JPA (link:https://en.wikipedia.org/wiki/Java_Persistence_API[Java Persistence API]) Entity.
This means that every concept can be individually persisted or the entire model can be persisted en-bloc to any persistence mechanism using an JPA framework such as link:http://hibernate.org/[Hibernate] or link:http://www.eclipse.org/eclipselink/[EclipseLink].
|
