Normative language approach a framework for understanding

BoSDL: An Approach to Describe the Business Logic of Software Services in Domain-Specific Terms

“…During the course of the evaluation, we observed that the generic association relationship, which was part of the language to interrelate information objects, was defined too broadly and often used instead of specialization and aggregation relationships. After consulting extant conceptual modeling literature (e.g., Ortner and Schienmann 1996), we decided to drop this relationship type and introduced an object connection relationship to fill the gap. Since participants of the laboratory experiment moreover indicated to prefer a graphical presentation format, we decided to develop such an additional format.…”

“…In principle, a specification language also should establish strict guidelines on how to use its constructs (Davis et al 1993;Ortner and Schienmann 1996;Moody 2009). Such guidelines do not only facilitate its use.…”

“…The intent of the BoSDL accordingly is to specify a system of concepts to express the business logic of software services. Such a system of concepts can be documented by two measures (Ortner and Schienmann 1996;Gómez-Pérez et al 2004): the building of (1) a vocabulary, which contains the domain-specific business terms, and (2) a set of statements, which interrelate business terms to express complex semantics. In the inventory management domain, characteristic terms would be ''storage bin'', ''storage strategy'' etc.…”

The Details of Conceptual Modelling Notations are Important - A Comparison of Relationship Normative Language

“…Figure 1. The Relationship Notation from Barker [1989] An interesting aspect of the Barker notation is that a normative language is also specified and is mandatory (see [Ortner & Schienmann, 1996] for an explanation of 'normative language'basically the constrained language defined for the notation). The normative language takes the form of a combination of entity-type name, optionality, relationship name, cardinality, and entitytype name.…”

Deriving static and dynamic concepts from software requirements using sophisticated tagging

“…Typically, these approaches focus on transforming natural language requirements specifications into conceptual schemata and thus predetermining the target conceptual model. Sometimes however a normative specification language is used [15]. Usually in requirements elicitation end-users have to communicate with the designers using either natural language or conceptual schemata in order to negotiate and validate the requirements specifications.…”