The Open Protocol Notation Programming Guide 1 Document Version 1 (4/23/2018)



Download 1.37 Mb.
Page7/24
Date23.04.2018
Size1.37 Mb.
#46651
1   2   3   4   5   6   7   8   9   10   ...   24

Aspects


In OPN, the use of metadata for describing additional contructs of the specification is ubiquitous. Therefore, the notation supports rich means to attach metadata to declarations. The notation construct to achieve this is referred to as aspects. Aspects are similar to attributes in C# and annotations in Java, yet there are differences in expressiveness and syntax as to the central role metadata has for the OPN domain.

Conceptually, as in C# and Java, metadata is information not required for the core semantics of a specification. The core semantics consists of the mathematical model required to describe raw data values and computations on that data. Metadata can be erased from a specification without changing its meaning with respect to the core semantics. However, interpretations of OPN by specific tools may require specific metadata to be present for proper functionality. Also, runtime behavior of library functions may be dependent on interpretation of metadata. Such dependencies are documented together with these tools. In some documented exceptions, aspects may also indirectly influence execution semantics of OPN, as they describe configuration of the execution environment.

In contrast to C# and Java, aspects are introduced by a special declaration form. This shows that they are not values present at execution time, and the declaration form enables customized notations. Aspects are attached to language elements by using the affix (with) notation instead of the prefix notation as in C# and Java. This demonstrates the fact that they represent additional and not core information about that declaration. The following shows an example of an aspect declaration and usage.

aspect Info 

{

string Description;



int Version;

}

type Person { string Name; int Age; }



     with Info{Description = "The type of persons.", Version = 1};

Syntactically an aspect declaration is very similar to a type declaration: it consists of a set of fields, and it is constructed by initializing those fields.

An aspect can use the well-known name this in a field declaration in order to relate constraints within the declaration to which an aspect is attached. The this field then represents the value to which the aspect associates. This concept is referred to as context binding of aspects. The following is an example of an aspect with context binding that describes the width in bits of an integer, ensuring that the actual value fits in that width.

aspect IntegerEncoding

{

int this;



int WidthInBits;

invariant this >= MaxValue(WidthInBits) && this <= Int.Max(WidthInBits);

}

type Frame 



{

int Value with IntegerEncoding{WidthInBits = 6};

}

While an aspect value is not actually constructed at runtime, the constraint it imposes is propagated to its application context. For the execution semantics, the preceding example is therefore equivalent to thefollowing example.



type Frame 

{

int Value;



invariant Value >= Int.Min(WidthInBits) && 
Value <= Int.Max(WidthInBits);

}

    1. Modules, Name Resolution, Visibility, and Lifetime


OPN supports a simple concept of modularization, which is similar to namespaces in C# or packages in Java. An OPN document can be prefixed by a declaration indicating a module name. All names declared in the document do then implicitly belong to that module. The fully-qualified name of the entities in the module consists of the module name separated by a dot (.) from the declaration name.

In the following example, the type Person has the fully qualified name DataModel.Core.Person, and the method Summary has the fully qualified name DataModel.Core.Summary.

module DataModel.Core;

public type Person { ... }

public string Summary(Person p) { ... }
In order to use the declarations from another module in a document, one has to supply a using clause to include the class to be used. The names from another module can then be referred with or without qualification. Names are not implicitly available in fully qualified form without a using clause, making usage relations explicit, for example.

module DataModel.Extensions;

using DataModel.Core;

type Employee : Person { ... }

A module can be defined using multiple documents. The using clauses are only relevant for the document that they appear in and are not inherited from other documents.

Modules can contain global methods and fields that are implicitly static. These are methods declared directly under the document scope. Types can contain both static and instance methods and fields. A declaration with static lifetime can only access other declarations that are static as well.

OPN supports two levels of visibility: public and internal. Internal declarations are only visible in a project (a set of coherent documents) to which the declaration belongs. As a modeling language, the default in OPN is public, not internal.

Name resolution is based on lexical scoping and context information. In a lexical scoping context, inner declarations shadow outer declarations, but outer declarations can be accessed using full name qualification. The using clauses of a document constitute an outer lexical scope relative to the document, such that they are implicitly shadowed by document declarations.

In some cases, name resolution is influenced by the expected resolved entity. For example, in a context where a pattern or type is expected, only names for such declarations are considered. In a context where a value is expected, pattern and type names are not considered. If a method name can resolve to different declarations, parameter types, stripping off any patterns, are used to disambiguate the declaration. Disambiguation does not consider global type inference.



    1. Download 1.37 Mb.

      Share with your friends:
1   2   3   4   5   6   7   8   9   10   ...   24




The database is protected by copyright ©ininet.org 2024
send message

    Main page