This page provides guidance on the correct usage of IISOMI and ONAP stereotypes in the model. Not all stereotypes are described. For a full description of IISOMI stereotypes, please refer to the IISOMI Modeling Guidelines listed in the previous page.

Introduction

Stereotypes are the core extension mechanism of the Unified Modeling Language (UML). If you find that you need a modeling construct that isn't in the UML but is similar to something that is, you treat your construct as a stereotype of the UML construct. Stereotypes get "applied" to UML artifacts (like "Class", "Attribute (property)", "Interface", etc.) and are a means to supply additional relevant information to that artifact. Stereotypes are usually shown in text between guillemets, but you can also show them by defining an icon for the stereotype. 

Here is an example in Papyrus of stereotypes between guillemets. There are two stereotypes (OpenModelClass and OnapModelLifecycle) "applied" to the class Vnfd.

Stereotypes themselves are defined in "Profiles" that get applied to models. Currently in Papyrus we have two profiles that are applied to the ONAP model:

• ONAP_Profile   (ONAP specific profile)
• OpenModel_Profile  (IISOMI profile)

Stereotypes, like classes, may contain a set of attributes, or properties. Here is an example of how the IISOMI "OpenModelAttribute" stereotype is defined in Papyrus. Note the icon with a little "s" to indicate that OpenModelAttribute is a stereotype. 

Note also that there is an attribute called "support". This particular attribute means what level of support is required over a management interface. It is further defined below

When defining the "Applied Stereotypes" in a wiki, it is important to note which stereotype is being applied (in this case OpenModelAttribute) and then the value given to a particular attribute, such as "support". Saying the "Applied Stereotypes" is "support=MANDATORY" is not exactly correct. One should say, for example "OpenModelAttribute.support = MANDATORY"

Some stereotypes, such as the IISOMI lifecycle stereotypes, don't have attributes. Here's an example of the "Deprecated" stereotype

This sterotype implies that the UML artifact has been deprecated in the model. 

Applying Stereotypes

ONAP Stereotypes

OnapModelLifecycle

There is currently only one ONAP stereotype defined, called OnapModelLifecycle. The definition in the profile looks like this:

It has an attribute called "state" that defines the development lifecycle and is based on an enum LifecycleState. The LifecycleState can take one of the following values: 

• INPUT                  Provided as a contribution to the model
• DISCUSSION      Has been discussed by the model project team 
• CLEAN                Has been agreed upon by the model project team
• APPROVED        Has been approved by the modelling subcommittee

These correspond to the various phases of development of the artifacts in the ONAP model, as seen currently in the wiki pages. It is used as a means to capture that classification in Papyrus. The "base_Class" and "base_Property" attributes imply that the stereotype can be applied both to a "Class" and an "Attribute".

Wiki Constraints:

• As the current wiki division of a model for a given release contains "INPUT", "DISCUSSION", and "CLEAN" pages (note: there is no equivalent APPROVED wiki), there is no need to note this stereotype in the "Applied Stereotypes" column. 
• The current wiki classification doesn't allow for applying the stereotype to both a Class and an Attribute, whereas in the Papyrus model it does. For example, in the wiki, one can't have a Class that is CLEAN (meaning the team has agreed they want that class in a release), and certain attributes to still be in a DISCUSSION phase (meaning the attribute as currently defined has not been agreed). 

IISOMI Stereotypes

As stated in the introduction section, only the IISOMI stereotypes that are currently relevant to ONAP model development are defined. 

OpenModelClass

The OpenModelClass stereotype, as the name implies, gets applied to a Class. It is defined as follows:

The definition of the attributes are as follows:

• base_Class : Class               Implies this stereotype gets applied to a Class
• support: SupportQualifier      Implies the "support" attribute defines the required support over a management interface and is based on an enum SupportQualifier, which takes one of the following values:
  • MANDATORY  The capability, as referenced by the artifact, shall be supported.
  • OPTIONAL      The capability, as referenced by the artifact, may or may not be supported.
  • CONDITIONAL-MANDATORY The capability shall be supported under certain conditions, specifically:
    When qualified as CM, the capability shall have a corresponding constraint defined in the "condition" attribute. If the specified constraint is met then the capability shall be supported.
  • CONDITIONAL-OPTIONAL     The capability may be supported under certain conditions, specifically:
    When qualified as CO, the capability shall have a corresponding constraint defined in the "condition" attribute. If the specified constraint is met then the capability may be supported.
• condition                                When the "support" attribute has a value of CONDITIONAL-MANDATORY or CONDITIONAL-OPTIONAL, this specifies the constraint that must be met.

The use of the OpenModelClass stereotype is currently applied by default to every class in Papyrus, with the default "support" being MANDATORY.  

Wiki constraints: There is currently no capturing of the OpenModelClass as an "Applied Stereotype" to a Class.

OpenModelAttribute

The OpenModelAttribute stereotype, as the name implies, gets applied to an Attribute of a Class.

It is defined as follows:

As one can see from the many properties in this stereotype, there are multiple additional values that can be defined for an "Attribute". The definition of the properties are as follows:

• base_StructuralFeature        This is essentially saying it gets applied to an attribute
• partOfObjectKey                   This property indicates if the attribute is part of the object key or not
• uniqueSet                              This property defines if the attribute is part of a set of attributes which together (i.e., their values) have to be unique among all instances within a defined context.

  No value means no uniqueness constraint. An integer value identifies the uniqueness set.

• isInvarient                              This property defines at which time the attribute can be set. true = attribute can only be set at creation time; false = attribute can be set at any time.
• valueRange                           This property provides the restriction on the attribute values.
• unsigned                                This optional property indicates if the attribute type is unsigned (value = true) or signed (value = false); if applicable, otherwise ignored.
• counter                                   This optional property defines the counter type of the attribute type; if applicable.
• unit                                         This optional property contains a textual definition of the unit associated with the attribute value.
• support                                   The same definition as for OpenModelClass.support
• condition                                 The same definition as for OpenModelClass.condition

Wiki constraints:  In the introduction section it was noted that the correct usage of this stereotype in the "Applied Stereotypes" column of a class attribute would be, for example "OpenModelAttribute.support=MANDATORY". Though not specifically a constraint, none of the other properties of the OpenModelAttribute stereotype appear to be used in the wiki. One could consider using these properties if needed.

 Lifecycle Stereotypes

It was noted in the introduction that each phase in the lifecycle of a UML artifact is represented by its own stereotype. The possible stereotypes that can be used to represent the various lifecycle phases are as follows:

• Example
  This stereotype indicates that the entity is NOT to be used in implementation and is in the model simply to assist in the understanding of the model (e.g., a specialization of a generalized class where the generalized class is to be used as is and the specialization is simply offered to more easily illustrate an application of the generalized class).
• Experimental
  This stereotype indicates that the entity is at a very early stage of development and will almost certainly change. The entity is NOT mature enough to be used in implementation.
• Faulty
  This stereotype indicates that the entity should not be used in new implementation and that attempts should be made to remove it from existing implementation as there is a problem with the entity. An update to the model with corrections will be released.
• LikelyToChange
  This stereotype indicates that although the entity may be mature, work in the area has indicated that change will be necessary (e.g., there are new insights in the area or there is now perceived benefit to be had from further rationalization). The entity can still be used in implementation but with caution.
• Obsolete
  This stereotype indicates that the entity should not be used in new implementation and that attempts should be made to remove it from existing implementation. The entity should be kept in the model for at least one further release. The team has to decide on a case by case basis when to remove it from the model.
• Preliminary
  This stereotype indicates that the entity is at a relatively early stage of development and is likely to change, but is mature enough to be used in implementation.
• Deprecated  This stereotype indicates that the entity may become obsolete in the near future. It may still be used in new implementation. The entity should  be kept in this state for one further release. The team has to decide on a case by case basis when to move it to obsolete.
• Mature
  This stereotype indicates that the entity is fully developed and can be used in implementations without any constraints.

One and only one lifecycle state has to be associated to every UML artifact. It is recommended that every new UML artifact is initially annotated with the “Experimental” lifecycle stereotype.

Wiki constraints:

• The IISOMI lifecycle state is not currently being used in the wiki, or is not being used as intended. For example, saying "support=DEPRECATED" would not be correct, because DEPRECATED is not one of the values the "support" takes. The correct usage in the "Applied Stereotypes" column would be to add the stereotype "Deprecated" as one of the stereotypes being applied. The correct way to define this in the "Applied Stereotypes" column on the wiki would be:
  
  

  OpenModelAttribute.support = MANDATORY

  Deprecated

• Note also the meanings provided above for "Deprecated" and "Obsolete". In both cases it is noted that the entity should be kept in the model for at least one further release. If one wants to actually deprecate an attribute it should go to the "Deprecated" state, then the "Obsolete" state, and THEN eventually be deleted from the model, per the state diagram below.

The associated state machine is as follows:

Example of GenDoc Output

The purpose of showing an example from a GenDoc output of the Papyrus model is to show how GenDoc currently captures all the applied stereotypes in comparison to how they are captured on the wiki. It is intended to show how stereotypes are applied to UML artifacts and how possibly the wiki model pages could be improved to take better advantage of the existing stereotypes.

The example below shows a snippet of the HomingGroup class as is currently defined in the Vnf sub-model.

Note in particular that the class HomingGroup has 3 stereotypes applied to it: OnapModelLifecycle, OpenModelClass, and Experimental. The class has an attribute (of many) called homingStrategy that has 2 stereotypes applied to it: OpenModelAttribute and OpenModelLifecycle. The fact that there are only 3 OpenModelAttribute properties listed is simply because GenDoc was configured to output only those 3 and not the rest of them to save space. It can be configured to output all the properties, if desired.

Homing Group

Homing selects what cloud selection strategy will be used.  HomingGroup is used to determine where VNF's within a given group are placed with respect to a service component.  Homing strategy is as follows: Colocation - members of the group share the same cloud region (VIM Domain) isolation - members of the group do not share the same cloud region.

Applied stereotypes:

• OnapModelLifecycle
  •  state: INPUT
• OpenModelClass
  • support: MANDATORY
• Experimental

.