UserAttributes : public package
Created: 2007-12-19 13:29:02
Modified: 2010-06-01 13:45:02
Project:
Advanced:
<p>User attributes in EAST-ADL are primarily intended to provide a mechanism for augmenting the elements of an EAST-ADL model with customized meta-information. All instances of metaclass UserAttributeableElement can have user attributes attached to them. The scope and structuring of this meta-information can be defined on a per-project basis by defining user attributes for certain types of EAST-ADL elements within UserAttributeTemplates.<br/></p><p><br/></p><p>Since EAST-ADL Requirements are, in their most general form, simple objects with all information contained in user-customized, project-specific attributes, the concept of user attributes is also perfectly suitable for defining those attributes of requirements. In that sense, basic Requirements in EAST-ADL can be seen as "empty" elements which only provide a node to which user attributes can be attached in order to supply the Requirement with all necessary information, including its main textual description. However, in the case when the Requirement is the context in which the available user attributes are defined, the container (context) of the Requirements is the point where user attribute definitions are stored and these are only applicable within this container.<br/></p><p><br/></p><p>The role of user attributes within the overall EAST-ADL is thus twofold: they (1) provide a means to customize the language to specific company and project needs and (2) constitute an important part of the requirements support of the language.<br/></p><p><br/></p><p>The mechanism of user attributes was optimized for flexibility and simplicity. User attributes are realized by simple key/value pairs where the globally unique key identifies the user attribute (cf. class UserAttributeValue). In principle, any key/value combination may be attached to any element, but user attribute definitions may optionally be provided to define valid keys and a set of legal values for them (cf. class UserAttributeDefinition). However, the actual attributes attached to an element and/or their values may well conflict with these attribute definitions: for example, it is perfectly legal to not provide an attribute value if an attribute definition was specified, or to provide a value for an undefined attribute. The attribute definitions are merely meant as a guideline for the engineer and as a basis for optionally checking if all attribute values are correct with respect to attribute definitions (by way of tool support). With this concept of attribute values and definitions, many intricacies and difficult situations during the creation and evolution of a model are circumvented and complex interdependencies between parts of the model are avoided. For example, it makes sure that a model, and all its user attribute values, can be safely viewed and edited even if the attribute definitions for the model are temporarily unavailable or permanently lost.<br/></p><p><br/></p><p>Whenever interoperability with third parties is required an internet domain naming scheme should be used, similar to packages in the Java programming language. For example, a company with a home page URL of "www.example.com" could use the key "com.example.Status" for a status attribute.<br/></p><p><br/></p><p>User attributes in EAST-ADL serve a similar purpose to stereotypes in UML2 but are intended as a much simpler mechanism, especially with respect to tool implementation.<br/></p><p><br/></p>