# Improving Conceptual Modeling with Object-Process Methodology Stereotypes
## 2 Literature Review
### Stereotypes  
A stereotype has been defined as \"_A well-formed mechanism for expressing user-definable extensions, refinements or redefinitions of elements of the language without (directly) modifying the meta-model of the language_\" [19]. Modeling languages used primarily for MBSE employ stereotypes to empower users to extend, or even modify, the modeling language. Modelers use stereotypes to adapt the language to specific situations or needs, such as creating a specific structure for an airplane in the aerospace domain. Designers of modeling languages, who introduced stereotypes to overcome certain language limitations, created a well-defined set of extension mechanisms--general-purpose model elements for language customization. Stereotypes respond to local needs and requirements, such as the ones arising in a specific domain, software development process, or problem [19; 21; 22]. To meet such needs, stereotypes provide means of customizing visual, general purpose, and object-oriented modeling languages, as well as specific constraints. A stereotype can add new properties to elements of the underlying language or modify existing ones. Stereotypes often express specific properties or add specific semantics to a certain kind of model element. Accordingly, stereotypes range in scope and kind from creating a basic structure, e.g., of a car, or adding a constraint to a system design, all the way to introducing specialized notation for modeling IoT systems security [25]. With both positive and negative effects, a stereotype is like a double-edged sword: When used correctly, stereotypes help balance the model, formalize it, and improve its understandability. However, if stereotypes are misused, they can have adverse effects of distorting the model in which they are used, making it more difficult to understand and implement. The roles of stereotypes have been investigated mainly for UML and SysML [19; 20; 21; 26]. Creating a stereotype in UML can be done in different ways by different tools: one can apply stereotypes to a range of model element types, such as Elements (e.g., Classes, Objects), Relationships (e.g., Dependencies, Associations), Association Ends, Attributes, and Operations. A UML stereotype is the only kind of meta-class that cannot be extendedby stereotypes [27]. This is not the case with OPM; As we show later, OPM stereotypes can be recursively extended by other OPM stereotypes (see Section 3.5). A UML stereotype is used mostly in cases when a primitive building block is needed frequently, so providing the UML modeler with a stereotype saves the time needed to redesign that building block repeatedly. An example from [25] for a use of a UML stereotype, related to IoT systems, is presented in Figure 1.  
We have not found a case in which a UML stereotype serves to define a standard building block that includes definition of constrains, such as allowable ranges, which can be then verified in the model statically, let alone in runtime. OPM stereotypes provide such options. Range and value validation are defined in Section 4, and their implementation is demonstrated in Section 5. No research about the need to introduce OPM stereotypes and how they should be designed and implemented has been carried out. A likely reason for this is that until recently, the need for stereotypes did not arise in OPM, because unlike UML and SysML, OPM uses a single kind of diagram, Object-Process Diagram (OPD), enhanced by its complementary, textual modality--OPL, Object-Process Language (a subset of English or any other natural language), which describes in a subset of natural language precisely what the OPD describes graphically. The combination of a single diagram kind and the bimodal visual-textual model representations has provided a robust capability to model systems of various kinds and domains using a minimal set of elements defined in its core metamodel: stateful objects and processes that transform objects by creating or consuming them, or by changing their states.