WO2014125430A1 - Method for creating specifications of software systems, in particular of the oltp-app type, and device thereof - Google Patents

Method for creating specifications of software systems, in particular of the oltp-app type, and device thereof Download PDF

Info

Publication number
WO2014125430A1
WO2014125430A1 PCT/IB2014/058968 IB2014058968W WO2014125430A1 WO 2014125430 A1 WO2014125430 A1 WO 2014125430A1 IB 2014058968 W IB2014058968 W IB 2014058968W WO 2014125430 A1 WO2014125430 A1 WO 2014125430A1
Authority
WO
WIPO (PCT)
Prior art keywords
synt
property
entity
event
logic
Prior art date
Application number
PCT/IB2014/058968
Other languages
French (fr)
Inventor
Roberto REMMERT
Original Assignee
Remmert Roberto
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Remmert Roberto filed Critical Remmert Roberto
Publication of WO2014125430A1 publication Critical patent/WO2014125430A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/10—Requirements analysis; Specification techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs

Definitions

  • the present invention relates to a method in the field of the definition and creation of specifications of software systems, in particular of the OLTP-App ("On Line Transaction Processing- Application") type, without limitation of the potential range of logic expressivity, and therefore applicable to any semantic domain and any functional requirement, regardless of their extension and complexity.
  • OLTP-App On Line Transaction Processing- Application
  • the second approach uses automatic computer-aided software engineering tools (commonly called “CASE Tools”, e.g. StP by Atego), which on the contrary pursue “horizontal approximation”, privileging the objective of ensuring expressive universality, but sacrificing the detail depth of the specification.
  • CASE Tools commonly called "CASE Tools”
  • StP by Atego
  • This has shown that the manual programming of detailed logic, which is necessary in order to complete the high-level logic, is however very time-consuming, so that producing systems specified by using this approach will not cost less than traditionally specified systems for totally manual programming.
  • both the first and second approaches just described are inadequate for minimizing the number of code rows, since the manual coding required in both cases is not supported by a centralized and normalized repository of "atomic logic modules" (e.g.
  • code repositories which must be understood as the application's ultimate and indivisible units of behaviour: the progressive occurrence of requisites is responded to by creating an "ad hoc" code block, with no formal tool intrinsically ensuring non-duplication of already written code: the unavailability of a code repository prevents optimizing the reuse rate of the already written code, and the total quantity of code (defined by convention as the "number of code rows”) is not intrinsically minimized.
  • version control commonly referred to as "versioning"
  • chronologically evolution of the code's state over time
  • geographically co-presence of different code's states based on different users, the chronological version being the same
  • the software metrics known in the art are based on the definition of the so-called function point (also called “UFP” or “Unadjusted function point”), which is intended as a software "weight measurement unit”.
  • function points aim at measuring the functionality received and requested by the user, measuring the results of the software development and/or maintenance activities regardless of the technology in use, and providing a measurement which is consistent among different projects and producers.
  • the methods for measuring the functional dimension currently recognized as international standards are bound to detecting and weighing "data movements” and “logic archives”, without any evaluation of the complexity and number of algorithms, i.e. data manipulation components. Also, in some cases the programmers/technicians themselves calculate the function points of the software manually, thus considerably increasing software management costs.
  • testing plan The last important aspect to be taken into account is the creation of the software's functional testing plan.
  • a few testing standards are currently in use, e.g. the IEEE 829- 2008 standard, all of which require a strong manual intervention for compiling the testing plan.
  • a method and a device are described for creating specifications of software systems, in particular of the OLTP-App type, wherein, according to said method, a declarative process flow allows decomposing and reducing a global specification of any OLTP-app into atomic information units, which can be represented in the form of tuples of values of tables of a relation scheme in Third Normal Form, or of any other relation scheme semantically equivalent thereto, provided that it adheres to the Third Normal Form.
  • FIG. 2 shows a process flow of the method according to the present invention
  • FIG. 7 shows a further process flow of the method according to the present invention.
  • One example of a specification document, or requisite, expressed in free linguistic format may be the following:
  • the user company is a public-capital legal subject (with approx. 2,000,000 members) and is obliged to compile and keep a Register of Members, possibly also in electronic format, indicating all entries and exits of subjects becoming or ceasing to be members; each subject's entry/exit must correspond to a separate and individual record; no more than one record, whether relating to an entry or an exit, shall be ⁇ entered for one subject on the same day.
  • the subjects may be either physical persons PP or legal persons LP, and for each entry and each exit of each one of them the record must include a uni vocal membership code of the entering/exiting subject, the fiscal identifier (tax code for PPs, VAT number for LPs), the date of origin (birth date for PPs, date of establishment for LPs), the onomastic data (name and surname for PPs, corporate name for LPs), the date of entry/exit into/from the company's structure. Entries and exits are generated by share transactions between different subjects, which shall be univocally identified by the year of their initialization and by a univocal progressive number within each year (the number of transactions per year is approx.
  • REM SPECIFICATION a formal language adapted to be recognized by automatic reading devices
  • the automatic reading and writing device 200 may be, for example, an advanced parser, which comprises a software product that carries out a preliminary interpretation of a REM SPECIFICATION (reading and interpretation), a verification of its syntax (correction and validation) and, if the syntactical verification is successful, a definitive automatic transformation of the same into equivalent source code (source code writing).
  • an advanced parser which comprises a software product that carries out a preliminary interpretation of a REM SPECIFICATION (reading and interpretation), a verification of its syntax (correction and validation) and, if the syntactical verification is successful, a definitive automatic transformation of the same into equivalent source code (source code writing).
  • the automatic reading and writing device 200 operates through a declarative process that includes a STATIC step (also referred to as “persistent layer”, or ONTOLOGICAL FOUNDATION) and an anthropological configuration step, which then continues with the parallel development of a DYNAMIC sub-step (also referred to as “conversational layer”, or man-machine conversation) and a LOGIC sub-step (also referred to as “logic layer”, or logical predication).
  • STATIC step also referred to as “persistent layer”, or ONTOLOGICAL FOUNDATION
  • anthropological configuration step which then continues with the parallel development of a DYNAMIC sub-step (also referred to as “conversational layer”, or man-machine conversation) and a LOGIC sub-step (also referred to as “logic layer”, or logical predication).
  • Said automatic reading and writing device 200 comprises syntactical reading means
  • Said automatic reading and writing device 200 further comprises memory means 205 adapted to store the data obtained by reading the REM SPECIFICATION.
  • Such memory means 205 may comprise the "persistent layer" of the device, e.g. a relational database.
  • the automatic reading and writing device 200 further comprises a source code generator 207 adapted to output a source code implementing the REM SPECIFICATION of the requisite of an OLTP-App.
  • the "persistent layer” is meant to be a set of persistent structural components of an OLTP-App which are independent of the programs, and which can be programmed by exclusively using the relational database programming syntax, in particular the ASCII ("American Standard Code for Information Interchange") SQL ("Structured Query Language”) standard language.
  • ONTOLOGICAL FOUNDATION refers to the fact that the REM SPECIFICATION of the "persistent layer" of an OLTP-App is obtained by iteratively applying the ONTOLOGICAL FOUNDATION THEOREM and the ONTOLOGICAL REDUCTION RULE.
  • a predicative category is ontologically founded only if at least one creation EVENT exists which belongs to the PERCEPTION FIELD, the OCCURRENCES of which can be represented by means of the creation of one and only one tuple of the relation representing it (for example, the insertion of one and only one record in a table), and said relation (the table) complies with the "Third Normal Form", or 3NF.
  • all the predicative categories represented in the "persistent layer" of an OLTP-App must be ontologically founded, i.e. the ELEMENTS of a logic category without ONTOLOGIC FOUNDATION would be lacking a measurement process for individually identifying and qualifying them without any interaction with ELEMENTS of other logic categories, and therefore could not represent reality states.
  • PERCEPTION FIELD refers to the set of OCCURRENCES that the user thinks is useful to notify to the "persistent layer" for future certain, retrievable and authenticated memory.
  • the PERCEPTION FIELD is defined at the user's discretion on the basis of a usefulness criterion, and is an integral part of the requisite.
  • An OLTP- App can therefore be compared to an artificial organism equipped with a "sensory system” selectively and exclusively oriented towards the goal of its own existence: the "senses" of an OLTP-App are the programs through which the OCCURRENCES of interest are "perceived" (conversationally declared) and “stored” (saved into a database).
  • ONTOLOGICAL REDUCTION RULE means that any type of OCCURRENCE of the PERCEPTION FIELD not having the EVENT requirement can be reduced to a succession of EVENTS only affecting ontologically founded ENTITIES, which can be represented, for example, through a 1 -weighted conditional Petri net, also known as CASCADE.
  • the PERCEPTION FIELD being equal, this specification area is independent of the user's historical, economical, social, cultural, organizational, regulatory, operational or psychological environment, in that it is solely representative of the OCCURRENCES of the EVENTS belonging to the PERCEPTION FIELD itself.
  • the steps and sub-steps of the declarative process comprise a declaration of sentences, the syntactical structure of which is typified and the succession of which is regulated and controlled by a process flow; the admissible types of declarative sentences, as well as the syntactical format and writing rules applicable to each one of them, will be listed and described below.
  • the STATIC step consists of identifying EVENTS belonging to the PERCEPTION FIELD of an OLTP-App, and assigning values to attributes and relations that characterize them. Such identification and qualification of the EVENTS fully and univocally defines the "persistent layer" of the OLTP-App, e.g. a database ("DB", or Relation Scheme).
  • DB database
  • Figs. 3a, 3b and 3c show, for example, the following tables referring to the STATIC step:
  • each graph execution cycle starts at step 101, CENSUS
  • An EVENT is meant to be a specific type of OCCURRENCE of the PERCEPTION FIELD, intensively defined by the set of PROPERTIES subject to valorization in accordance with predefined and stable measurement protocols, which can be represented by means of the creation (creation EVENT) or modification (update EVENT) of one and only one tuple in one and only one ENTITY, called “ENTITY affected by the EVENT", and can therefore be implemented in computer science by exclusively inserting ("insert”) or updating ("update”) one and only one record (“row”) in one and only one table (“table”).
  • a PROPERTY is meant to be a logic attribute that identifies and/or qualifies an ENTITY, which can be represented by means of a relation column, and can therefore be implemented in computer science as an attribute ("column").
  • the EVENT ⁇ l_l_event_name> consisting of the ⁇ l_2_event_definition>, belongs to the PERCEPTION FIELD,
  • ⁇ l_l_event_name> is the primary key (synt);
  • ⁇ l_2_event_definition> must be a vocabulary definition of a generic instance of the EVENT (sem);
  • ⁇ l_3_event__type> is an obligatory attribute that admits the values ['C'('creation'), 'A' ('update')] (synt);
  • the EVENT ⁇ l_l_event_jiame> must reference, through ⁇ 12_updates>, at least one PROPERTY of the affected ENTITY ⁇ l_4_affected_entity> which undergoes valorization through the effect of its instances (synt);
  • the EVENT ⁇ l_l_event_name> must reference, through ⁇ 15_is_node_of> at least one CASCADE in which it recurs as a node (synt).
  • a writing rule is "syntactical" (synt) if it concerns the formal correctness of the specification (accuracy); instead, it is “semantic” (sem) if it refers to the compliance of the specification with the represented reality state (adequacy).
  • the syntax of a specification can be verified and validated by means of an automatic analyzer.
  • semantic writing rules do not affect the automatic transformation of a REM SPECIFICATION into source code, which is carried out by a parser device.
  • the obligatoriness of declaring the ENTITY affected by the EVENT imposes that, if the EVENT under census turns out to be the first creation EVENT of the declared affected ENTITY, the following contextual declaration must then be made.
  • ⁇ 2_l_entity_name> is the primary key (synt);
  • ⁇ 2_2_entity_definition> is an obligatory attribute (synt);
  • ⁇ 2_2_entity_defmition> must be a vocabulary definition of the generic ELEMENT of the ENTITY (sem).
  • An ELEMENT is meant to be a logic element belonging to an ENTITY, which can be represented by means of a relation tuple, and can therefore be implemented in computer science as a record ("row" of a table);
  • the ENTITY ⁇ 2_l_entity_name> must reference, through ⁇ l_is affected_by>, at least one creation EVENT that affects it (synt);
  • ⁇ 2_contains> at least one PROPERTY that belongs to it (synt);
  • the ENTITY ⁇ 2_l_entity_name> must reference, through ⁇ 6_is_identified_by>, the primary key that univocally identifies its ELEMENTS (synt);
  • step 105 CENSUS OF PRIMITIVE PROPERTIES.
  • the syntactical format of the declarative sentence CENSUS OF PRIMITIVE PROPERTIES, with multiple cardinality "j" is:
  • ⁇ 3_l_property_name> is the primary key (synt);
  • ⁇ 3_2_entity_it__belongs_to> is an obligatory attribute, referenced by ⁇ 2_contains> (synt);
  • ⁇ 3_3_migrated_primitive_flag> determines whether the PROPERTY ⁇ 3_l_property_name> is native of the ENTITY it belongs to ⁇ 3_2_entity_it_belongs_to> (value 'P') or is migrated in the ENTITY it belongs to ⁇ 3_2_entity_it_belongs_to> by a relation (value 'M') (sem);
  • ⁇ 3_4jproperty_definition> is an obligatory attribute (synt); ⁇ 3_4_property_definition> must be a vocabulary definition of the semantic attribute that identifies and/or qualifies the ELEMENTS of the ENTITY it belongs to ⁇ 3_2_entity_it_belongs_to> (sem);
  • ⁇ 3_5_dimension> determines the maximum number of significant characters available for the values of the PROPERTY ⁇ 3_l__property_name> (sem);
  • ⁇ 3_6_null_value_admissibility_flag> determines whether the value of the PROPERTY ⁇ 3_l_property_name> can be unknown when the ELEMENT is created (value 'NULL') or must necessarily be valorized (value 'NOT NULL') (sem);
  • ⁇ 3_7_zero_filling_on_the_right_flag> and ⁇ 3_8_zero_filling_on_the_left_flag> are both obligatory attributes that admit the values ['S ⁇ 'N'] (synt);
  • ⁇ 3_7_zero_filling_on_the_right_flag> and ⁇ 3_8_zero_filling_on_the_left_flag> determine whether the values of the PROPERTY ⁇ 3_l_property_name> must be exposed in conversation with zeroes entered on the right and/or on the left of the non-significant characters (value 'S') or must be limited to the significant characters (value 'N')
  • ⁇ 3_9_computable_comparable_flag> is an obligatory attribute that admits the values [' ⁇ ', 'C'] (synt);
  • ⁇ 3_9_computable_comparable_flag> determines whether the PROPERTY ⁇ 3_l_property_name> is computable (value 'N') or only comparable (value 'C'); a PROPERTY is computable if and only if the set of its admissible values is an ordered range, i.e. if a closed algebra of sum and product has been defined on it (typically, but non exclusively, a numeric set) (sem);
  • ⁇ 3_10_precision> determines, in base 10 (ten), the characteristic of the values of the PROPERTY ⁇ 3_l_property_name> (number of significant digits after point) (sem);
  • ⁇ 3_10_precision> may not exceed [ ⁇ 3_5_dimension> - 1] (synt);
  • ⁇ 3_l l_dimensionality> determines the dimensional equation of the PROPERTY ⁇ 3_l_property_name>, expressed in the MKSA$ (Metre-Kilo- Second-Ampere-Dollar) International System (sem);
  • ⁇ 3_12_negative_value_admissibility_flag> determines whether the PROPERTY ⁇ 3_l_property_name> admits negative values (value 'S') or only positive or null values (value 'N') (sem);
  • ⁇ 3_13_differential_absolutejvalue_flag> determines whether the measurement values of the PROPERTY ⁇ 3_l_property name> are absolute (value ⁇ ') or differential (value 'D') (sem);
  • PROPERTY is differential when its values are measured with reference to an origin of values conventionally assumed to be equal to 0, as is typically, but not exclusively, the case of dates (time intervals between the measured instant and a conventional instant of origin, assumed to be equal to 0) or localizations (spatial intervals between the measured point and a conventional point of origin, assumed to be equal to 0).
  • ⁇ 3_14_date_type_flag> and ⁇ 3_15_coordinate_type_flag> determine, respectively, whether the PROPERTY with differential values is a date (respective values: 'S', 'N') or a geographical coordinate (respective values: 'N', 'S') or neither of the two (respective values: 'N', 'N') (sem);
  • a PROPERTY ⁇ 3_l_property_name> with differential values may not be both a date and a geographical coordinate at the same time (synt);
  • ⁇ 3_16_open_closed_domain_flag> determines whether the value domain of the PROPERTY ⁇ 3_l_property_name> is free (value ⁇ ') or the PROPERTY ⁇ 3_l_property_name> only admits a set of previously known values, which may not be changed for the whole life cycle of the OLTP- App (value 'C') (sem);
  • ⁇ 3_17_discrimination_role_flag> determines whether one or more of the admissible values for a closed-domain PROPERTY ⁇ 3_l_property_name> play a role as discriminant values (value 'S') or not (value 'N') (sem);
  • ⁇ 3_18_regular_expression> determines the admissible characters for each one of the notification positions for the values of the PROPERTY ⁇ 3_l_property_name>, i.e. the so-called 'regular expression' of the information attribute that implements the PROPERTY ⁇ 3_l_property_name> (sem);
  • ⁇ 3_16_open_closed_domain_flag> 'C must reference, through ⁇ 9_admits_the_value>, at least two admissible values (synt);
  • PROPERTY ⁇ 3_l_property_name> must be updatable, through ⁇ 13_is_updated_by>, by at least one EVENT (synt); all those PROPERTIES ⁇ 3_l_property_name> which belong neither to the primary key ("PK") nor to any alternate key (“AK”) must comply with the Third Normal Form (“3NF”) (sem).
  • PK primary key
  • AK alternate key
  • 3NF Third Normal Form
  • PROPERTY is in "3NF” if and only if it functionally depends on the primary key (“PK”) and all alternate keys (“AK”) in a complete and non-transitive manner.
  • a "closed-domain PROPERTY” is meant to be a primitive PROPERTY whose set of admissible values is known a priori, and will not certainly change for the whole life cycle of the application: by way of example, the personal PROPERTY "sex" of an individual may always only take the value "M” (male) or "F” (female).
  • PROPERTIES with multiple cardinality "v”, is:
  • ⁇ 7_2_admissible_value> belongs to the primary key (synt); ⁇ 7_3_admissible_value_semantics> is an obligatory attribute (synt); ⁇ 7_3_admissible_value_semantics> must be a vocabulary definition of the specific meaning of the admissible value ⁇ 7_2_admissible_value> (sem);
  • PROPERTY ⁇ 7_l_vaIorized_property> must be a closed-domain primitive one (synt);
  • the admissible value ⁇ 7_2_admissible_value> must comply with the format of the PROPERTY ⁇ 7_l_valorized_property> as concerns dimension and regular expression (synt).
  • ⁇ 4_l_relation_name> is the primary key (synt);
  • ⁇ 4_3_referenced_entity> is an obligatory attribute, referenced by ⁇ 4_is_referenced> (synt);
  • ⁇ 4_4_relation_defmition> is an obligatory attribute (synt); - ⁇ 4_4_relation_definition> must be a vocabulary definition of the semantic connection established by the relation between the referencing ENTITY ⁇ 4_2_referencing_entity> and the referenced ENTITY ⁇ 4_3_referenced_entity> (sem);
  • ⁇ 4_5_relation_type_flag> is an obligatory attribute that admits the values [T, ⁇ ', 'D'] (synt);
  • ⁇ 4_5_reIation_type_flag> determines whether the relation ⁇ 4_l_relation_name> is an identifying one (value T: the primary-key ("PK") PROPERTIES of the referencing ENTITY ⁇ 4_2_referencing_entity>, migrated by the relation ⁇ 4_l_relation_name>, are a sub-set of the primary- key ("PK") PROPERTIES of the referenced ENTITY ⁇ 4_3_referenced_entity>), or is an elementary one (value ⁇ ': none of the primary-key (“PK”) PROPERTIES of the referencing ENTITY ⁇ 4_2_referencing_entity>, migrated by the relation ⁇ 4_l_relation_name>, belongs to the primary key ("PK") and/or to the alternate keys ("AK”) of the referenced ENTITY ⁇ 4_3_referenced_entity>), or is a discriminating one (value 'D' : the primary key ("PK”) of the referenced ENTITY
  • ⁇ 4_6_no_referencing_admissibility_flag> is an obligatory attribute that admits the values ['NULL', 'NOT NULL'] (synt);
  • ⁇ 4_6__no_referencing_admissibility_flag> determines whether the ELEMENT migrated by the relation ⁇ 4_l_relation_name> can be unknown when the ELEMENT is created in the referenced ENTITY ⁇ 4_3_reference_entity>) (value 'NULL') or must obligatorily be valorized (value 'NOT NULL') (sem);
  • ⁇ 4_7_numerosity> is an optional attribute: if valorized, it determines the maximum number of ELEMENTS admitted in the referenced ENTITY ⁇ 4_3_referenced entity>, for the same ELEMENT migrated by the relation ⁇ 4_l_relation_name> (sem);
  • the referencing ENTITY ⁇ 4 2_referencing_entity> and the referenced ENTITY ⁇ 4_3_referenced_entity> must be distinct (synt);
  • the number of relations referencing it must be smaller than or equal to the number of migrated PROPERTIES belonging to it
  • PROPERTIES are as follows:
  • ⁇ 3_l_property_name> is the primary key (synt);
  • ⁇ 3_2_entity_it_belongs_to> is an obligatory attribute, referenced by ⁇ 2_contains> (synt);
  • ⁇ 3_3_migrated_primitive_flag> is an obligatory attribute, which admits the values [' ⁇ ', ' ⁇ '] (synt);
  • ⁇ 3_3_migrated_primitive_flag> determines whether the PROPERTY ⁇ 3_l_property_name> is native of the ENTITY it belongs to ⁇ 3_2_entity_it_belongs_to> (value 'P') or is migrated in the ENTITY it belongs to ⁇ 3_2_entity_it_belongs_to> by a relation (value 'M') (sem);
  • ⁇ 3_19_migration_relation> is an obligatory attribute, referenced by ⁇ 5_transports> (synt);
  • ⁇ 3_20_migration_role> is an obligatory attribute (synt);
  • ⁇ 3_20_migration_role> must be a vocabulary definition of the semantic role acquired in the ENTITY to which the property belongs ⁇ 3_2_entity_it_belongs_to> (referenced ENTITY) by the ELEMENT of the ENTITY from which it migrates (referencing ENTITY), by means of the migration relation ⁇ 3_19_migration_relation>; for example, a subject's "province of residence", whose exclusive identity as province of the referencing ENTITY "PROVINCE” acquires the semantic role as "residence" of the subject to whom it has been attributed in the referenced ENTITY "SUBJECTS”) (sem);
  • PK primary key
  • the primary key (“PK") of the respective ENTITY ⁇ 3_2_entity_it_belongs_to> must only consist of all the PROPERTIES migrated by means of that relation (synt);
  • step 1 13 CENSUS OF DISCRIMINANT VALUES.
  • ⁇ 8_l_discrimination_relation> belongs to the primary key, and is referenced by ⁇ 10_is_discriminated_by> (synt);
  • ⁇ 8_l_discrimination_relation> determines the discrimination relation corresponding to the specific discriminant 2-ples [ ⁇ 8_2_discriminant _property> + ⁇ 8_3_discriminant_value>] (sem);
  • ⁇ 8_2_discriminant_property> belongs to the primary key, and is referenced by ⁇ 1 l_discriminates> (synt);
  • ⁇ 8_3_discriminant_value> belongs to the primary key, and is referenced by ⁇ 1 l_discriminates> (synt);
  • the discriminant PROPERTY ⁇ 8_2_discriminant_property> must be a closed-domain primitive property with discrimination role (synt);
  • the ENTITY to which the discriminant PROPERTY ⁇ 8_2_discriminant__property> belongs must coincide with the referencing ENTITY of the discrimination relation ⁇ 8_l_discrimination_relation> (synt); the discrimination relation ⁇ 8_l_discrimination_relation> must be of the discrimination type (synt).
  • Step 113 is followed by step 1 15, CENSUS OF KEYS.
  • the syntactical format of the declarative sentence CENSUS OF KEYS, with multiple cardinality "s”, is:
  • ⁇ 5_l_key_name> is the primary key (synt);
  • ⁇ 5_2_entity_it_belongs_to> is an obligatory attribute, referenced by ⁇ 6_is_identified_by> (synt);
  • ⁇ 5_3_key_type> is an obligatory attribute that admits the values [' ⁇ ', ' ⁇ ', ' ⁇ ', ' ⁇ '] (synt);
  • ⁇ 5_3_key_type> determines whether the key is a primary key (value 'PK': the key has the requisites of full valorization at ELEMENT creation, persistence and univocity, and is used in an implementative manner for establishing the referential integrity constraint in the relations in which the ENTITY ⁇ 5_2_entity_it_belongs_to> is referencing) or an alternate key (value ' ⁇ ': the key has the requisites of full valorization at ELEMENT creation, persistence and univocity), or a key with admissible null values and persistent non-null values (value 'NK': the key, if non-null, has the requisites of persistence and univocity), or a key with admissible null values and modifiable non-null values (value ' ⁇ ': the key, if non-null, has the requisite of univocity) (sem);
  • each key ⁇ 5_l_key_name> must contain at least one PROPERTY
  • the ENTITY referenced by the migration relation must coincide with the ENTITY ⁇ 5_2_entity_it_belongs_to> to which the key belongs (synt).
  • Step 115 is followed by step 117, CONNECTION OF KEY PROPERTIES.
  • ⁇ 6 1_key_it_belongs_to> belongs to the primary key, and is referenced by ⁇ 7_contains> (synt);
  • ⁇ 6_2_key_property> belongs to the primary key, and is referenced by ⁇ 8_belongs_to> (synt);
  • each key ⁇ 5_l_key_name> must contain at least one PROPERTY ⁇ 6_2_key_property> (synt).
  • Step 117 is followed by step 119, CONNECTION OF UPDATED PROPERTIES.
  • the EVENT ⁇ 10_l_update_event> valorizes the PROPERTY ⁇ 10_2_updated_property> according to the measurement protocol ⁇ 10_4_valorization_protocol>; the value thus measured is notified at the point ⁇ 10_3_conversational_order_index> (i.e. the i-th point of the EVENT conversation), labelled as in conversation by ⁇ 10_5_exposition_label>".
  • ⁇ 10_2_updated_property> belongs to the primary key, and is referenced by ⁇ 13_is_updated_by> (synt);
  • ⁇ 10_3_conversational_order_index> is an obligatory attribute (synt); - ⁇ 10_3_conversational_order_index> is a progressive integer number that determines the position occupied by the updated PROPERTY ⁇ 10_2_updated_property> in the conversational succession of notification of the instances of the EVENT ⁇ 10_l_update_event> (sem);
  • ⁇ 10_4_valorization_protocol> must be a vocabulary definition of the organizational/operational measurement protocol used for measuring the values of the updated PROPERTY ⁇ 10_2_updated_property> (the same PROPERTY may, in fact, be updated by different update EVENTS ⁇ 10_l_updated_event>, with different measurement protocols) (sem);
  • ⁇ 10_5 exposition_label> is an obligatory attribute (synt);
  • ⁇ 10_5_exposition_label> is a label exposed to the benefit of the user, which semantically identifies the PROPERTY under update ⁇ 10_2_updated_property> (sem) ;
  • EVENT ⁇ 10_l_update_event> must belong to the ENTITY affected by the same EVENT (synt);
  • EVENT ⁇ 10_l_update_event> if it is a creation event, it must update all the PROPERTIES ⁇ 10_2_updated_property> belonging to the primary key ("PK") and/or to the alternate keys ("AK") of the ENTITY affected by the same EVENT ⁇ 10_ 1 _update_event> (synt) ;
  • EVENT ⁇ 10_l_update_event> is an update event, it may not update any PROPERTY ⁇ 10_2_updated__property> belonging to the primary key ("PK") and/or to the alternate keys ("AK") of the ENTITY affected by the same EVENT (synt).
  • PK primary key
  • AK alternate keys
  • the DYNAMIC sub-step consists of identifying CASCADES constituting the modes for notifying to the "persistent layer” the EVENTS belonging to the PERCEPTION FIELD of an OLTP-App, and of procurzing the attributes and the relations that connote them.
  • identification and qualification of CASCADES fully and univocally defines the "conversational layer” and the "logic layer” of the OLTP-App.
  • the "conversational layer” is meant to be the set of program exposition components of an OLTP-App, aimed at governing the interactive conversations between a user and a software system (e.g. the programs of a graphic interface).
  • a CASCADE is meant to be a non-empty finite tree, the nodes of which are occupied by EVENTS. It can be considered to correspond, for example, to a 0/l/ ⁇ -weighted conditioned Petri net, fully executable in synchronous mode, and hence implementable in computer science through a single transaction made on a "persistent layer".
  • DYNAMIC sub-step also called “conversational layer”, or man- machine conversation.
  • Figs. 3b, 3c and 3d show, for example, the folio wing, tables referring to the DYNAMIC step:
  • ⁇ 9_l_cascade_name> is the primary key (synt);
  • ⁇ 9_2_cascade_definition> is an obligatory attribute (synt);
  • ⁇ 9 2_cascade_definition> must be a vocabulary definition of a generic notification to the "persistent_layer" of the group of EVENTS constituting the CASCADE, made by the user in observance of the succession and control logic that qualify the CASCADE itself (sem).
  • At least one EVENT must recur in any CASCADE ⁇ 9_l_cascade_name> (synt).
  • Step 121 is followed by step 123, CONNECTION OF EVENTS.
  • the syntactical format of the declarative sentence CONNECTION OF EVENTS, with multiple cardinality "n”, is:
  • ⁇ 1 l_l_branch_cascade> belongs to the primary key, and is referenced by ⁇ 14_is_mapped_by> (synt);
  • ⁇ 1 l_2_node_localization> must be a label of the node occupied by the EVENT ⁇ l l_3_node_event> in the tree that represents the CASCADE ⁇ 1 l_l_branch_cascade> (sem);
  • ⁇ 1 l_3_node_event> is an obligatory attribute, and is referenced by ⁇ 15_is_node_of> (synt);
  • CASCADE entry EVENT must be uni vocal (synt);
  • An EVENT may not recur more than once in a CASCADE BRANCH, but may recur multiple times in the same CASCADE, in different CASCADE
  • a CASCADE BRANCH is a succession of (n+1) CASCADE nodes to which a node belongs for each height i from 0 (root node) to n, such that, for each i from 0 to (n-1), the node of height i is topologically connected to the node of height (i+1), and the node of height n is the terminal node (i.e. it is not topologically connected to any node of higher height) (synt);
  • the census of CASCADES can be considered to be complete if and only if each EVENT recurs in at least one CASCADE (synt).
  • search and selection profile ⁇ 19_l_profile_name> is available, consisting of ⁇ 19_2_profile_description>.
  • ⁇ 19_2jprofile_description> is an obligatory attribute (synt);
  • ⁇ 19_2_profile_description> must be a vocabulary definition of the strategy for selecting and retrieving ELEMENTS of the ENTITY ⁇ 19_3_profiled entity> that connotes the profile ⁇ 19_l_profile_name> (sem); - ⁇ 19_3_profiled_entity> is an obligatory attribute, referenced by
  • the profile ⁇ 19_l_profile_name> must reference, through ⁇ 35_allows_selection_for>, at least one "selectable" PROPERTY, i.e. a PROPERTY on which the user can define selection value filters (synt);
  • ⁇ 38_displays> at least one "displayed" PROPERTY, i.e. a PROPERTY whose value state, as concerns all the ELEMENTS that comply with the defined selection value filters, is exposed during the conversation (synt);
  • Each ENTITY which is affected by at least one update EVENT and/or which references at least one relation must recur as a ⁇ 19_3_profiled_entity> in at least one profile ⁇ 19_ljprofile_name> (synt).
  • step 125 CONNECTION OF SELECTABLE PROPERTIES.
  • the syntactical format of the declarative sentence CONNECTION OF SELECTABLE PROPERTIES, with multiple cardinality "d”, is:
  • ⁇ 20_l_selectable_profile> belongs to the primary key, and is referenced by ⁇ 35_allows_selection_for> (synt);
  • ⁇ 20_2_selection__property> belongs to the primary key, and is referenced by ⁇ 36_is_selection_filter_in> (synt);
  • ⁇ 20_2_selection_property> is a PROPERTY on which the user can ' define selection value filters (sem);
  • ⁇ 20_3_selection_relational_path> belongs to the primary key, and is referenced by ⁇ 37_defines_selection_navigation> (synt);
  • ⁇ 20_3_selection_relational_path> is the logic sentence that connects the ENTITY to which the selection PROPERTY ⁇ 20_2_selection_property> belongs in a relational way to the profiled ENTITY ⁇ 19_3_profiled_entity>. If the two ENTITIES coincide, and hence there is no relational connection, the conventional logic sentence for a null relational path will be used in order to comply with the constraint of non-nullity of the primary key (sem);
  • ⁇ 20_4 explanatory_selection_message> is an obligatory attribute (synt);
  • ⁇ 20_4_explanatory_selection_message> is a tagline exposed to the benefit of the user, which explains the semantics of the selection PROPERTY ⁇ 20_2_selection_property> (sem).
  • step 129 CONNECTION OF DISPLAYED PROPERTIES
  • - ⁇ 21_l_displayable_profile> belongs to the primary key, and is referenced by ⁇ 38_displays> (synt);
  • ⁇ 21_2_display_property> belongs to the primary key, and is referenced by ⁇ 39_is_displayed_in> (synt); ⁇ 21_2_display_property> is a PROPERTY exposed to the user for display (sem);
  • ⁇ 21_3_display_relational_pafh> belongs to the primary key, and is referenced by ⁇ 40_defines_display_navigation> (synt);
  • ⁇ 21_4_display_label> is an obligatory attribute (synt); ⁇ 21_4_display_label> is a label exposed to the benefit of the user, which identifies the display PROPERTY ⁇ 21_2_display_property> (sem);
  • step 123 it is verified if all the necessary search and selection profiles and all the entry/exit guards already exist. If these two conditions are verified, then step 131, ATTRIBUTION OF ENTRY/EXIT GUARDS, is carried out.
  • the syntactical format of the declarative sentence ATTRIBUTION OF ENTRY/EXIT GUARDS, with multiple cardinality "q”, is:
  • ⁇ 1 l_4_entry_guard> is an optional attribute, and is referenced by ⁇ 18_conditions_entry> (synt);
  • ⁇ 1 l_4_ entry_guard> is the logic sentence to the truthfulness value of which the entry in the EVENT ⁇ 1 l_3_node_event>, which recurs in the CASCADE ⁇ l l_l_branch_cascade> at the node localized in ⁇ 1 l_2_node_localization>, is subordinated (sem);
  • the entry at the root node may not be subordinated to any logic sentence. Therefore, the maximum possible cardinality ⁇ qi ng > of entry guards is ( ⁇ n>-l) (synt);
  • ⁇ 1 l_5_exit_guard> is an optional attribute, and is referenced by ⁇ 19_conditions_exit>(synt) ;
  • ⁇ 1 l_5_exit_guard> is the logic sentence to the truthfulness value of which the exit from the EVENT ⁇ U_3_node_event>, which recurs in the
  • step 133 CENSUS OF CYCLES is carried out.
  • the syntactical format of the declarative sentence CENSUS OF CYCLES, with multiple cardinality "f , is:
  • the CASCADE ⁇ 15 1_cycle_cascade> admits a cycle of return to the node localized by ⁇ 15_3_return_node>, launchable by the node ⁇ 15_2_launch_node>"
  • ⁇ 15_l_cycle_cascade> belongs to the primary key, and is identically referenced by both ⁇ 20_launches> and ⁇ 21_closes> (synt);
  • ⁇ 15_2_launch_node> belongs to the primary key, and is referenced by ⁇ 20_launches> (synt);
  • the return node ⁇ 15_3_return_node> must belong to the same CASCADE BRANCH as the launch node ⁇ 15_2Jaunch_node> (synt);
  • step 135 ATTRIBUTION OF LAUNCH GUARDS is carried out.
  • ⁇ 15_4_launch_guard> is an optional attribute, and is referenced by ⁇ 22_conditions launch> (synt);
  • ⁇ 1 l_4_launch_guard> is the logic sentence to the truthfulness value of which the entry in the cycle identified by the 3-ple [ ⁇ 15_l_cycle_cascade> + ⁇ 15_2_launch_node> + ⁇ 15_3_return_node>] is subordinated (sem);
  • ⁇ g> the maximum possible cardinality ⁇ g> is equal to ⁇ f> (case wherein all the cycles of the CASCADE have conditioned entry) (synt);
  • ⁇ 15_2_launch_node> is an entry node for n cycles, and if the (n+1) guards for exit from the node and/or entry in the n cycles are not mutually exclusive, the user will choose a continuation path among those which, based on the value state formed when crossing the EVENT located in ⁇ 15_2_launch_node>, verify their respective guards (sem).
  • ⁇ 16_2_localization_under_conversation> belongs to the primary key: these are the ⁇ 1 l_2_node_localization> corresponding to ⁇ 16_l_branch_under_conversation>, referenced by ⁇ 23_is_in_conversation>
  • step 139 ATTRIBUTION OF UPDATE RULES, is carried out.
  • ⁇ 16_5_obligatory_valorization_guard> is an obligatory attribute, and is referenced by ⁇ 25_conditions_obligatoriness> (synt);
  • ⁇ 16_7_persistent_valorization_guard> is an obligatory attribute, and is referenced by ⁇ 27_conditions_persistence> (synt);
  • ⁇ 16_8_automatic_valorization_algorithm> is an obligatory attribute, referenced by ⁇ 28_calculates_value>, if
  • ⁇ 16_8_automatic valorization_algorithm> is the logic sentence, of the algorithm type, that provides valorization of ⁇ 16_4_property_under_update> (sem);
  • ⁇ 16_9_default_valorization_algorithm> is an optional attribute, referenced by ⁇ 29_calculates_default>, in the case wherein ⁇ ⁇ -('aut ⁇ '-('per') ⁇ 0; otherwise, it is not valorized (synt);
  • ⁇ 16_9_default_valorization_algorithm> is the logic sentence, of the algorithm type, that provides the default value to be proposed for ⁇ 16_4_property_under_update> (sem);
  • ⁇ 16_10_conversational_order_cascade_variation> is an optional attribute. It is a progressive integer number that determines the position occupied by the updated PROPERTY ⁇ 16 4_property_under_update> in the conversational succession of notification of the instances of the EVENT
  • step 141 ATTRIBUTION OF PERSISTENT VALUES, is carried out.
  • VALUES are as follows:
  • ⁇ 17_3_persistent_event> + ⁇ 17_4_persistent_property>] is the primary key, referenced by ⁇ 30_is_updated_for_persistence>. It identifies an update previously listed at the declarative point LIST OF PROPERTIES TO BE UPDATED, for which at the subsequent declarative point ATTRIBUTION OF UPDATE RULES ⁇ 16_7_persistent_valorization_guard> ⁇ 'NEVER' was set (synt);
  • ⁇ 17_5_persisted_node> is an obligatory attribute, referenced by [ ⁇ 31_ update_forjpersistence> ⁇ ⁇ 23_is_in_conversation>] (synt);
  • ⁇ 17_5_persisted_node> is, within the frame of the CASCADE ⁇ 17_l_persistence_branch>, the localization of the node from which the persistent value is taken ( sem);
  • ⁇ 17_6_persisted_event> is an obligatory attribute, referenced by [ ⁇ 31_update_for_persistence> ⁇ ⁇ 24_is_being_updated> ⁇ ⁇ 12_updates>] (synt);
  • ⁇ 17_6_persisted_event> is, within the frame of the CASCADE ⁇ 17_l_persistence_branch>, the EVENT from which the persistent value is taken (sem);
  • ⁇ 17_7_persisted_property> is an obligatory attribute, referenced by [ ⁇ 31_updates_for_persistence> ⁇ ⁇ 24 is_being_updated> ⁇ ⁇ 13_is_updated_by>] (synt);
  • ⁇ 17_7_persisted_property> is, within the frame of the CASCADE ⁇ 17_l__persistence_branch>, the PROPERTY that provides the persistent value (sem);
  • the PROPERTY ⁇ 17_4_persistent_property> valorized for persistence must turn out, in the declarative path of the CASCADE ⁇ 17_l_persistence_branch>, to be subsequent to the PROPERTY ⁇ 17_7_persisted_property> that provides the persistence value (synt);
  • ⁇ 18_4_constrained_node> belongs to the primary key, and is referenced by [ ⁇ 33_is_limited_by> ⁇ ⁇ 23_is_in_conversation>] (synt);
  • ⁇ 18_4_constrained_node> is, within the frame of the CASCADE ⁇ 18_ l_constrained_cycle>, the localization of the node occupied by the update
  • ⁇ 18_5_constrained_event> belongs to the primary key, and is referenced by [ ⁇ 33_is_limited_by> ⁇ ⁇ 24_is_being_updated> ⁇ ⁇ 12_updates>] (synt);
  • ⁇ 18_5_constrained_event> is, within the frame of the CASCADE ⁇ 18_l_constrained_cycle>, the update EVENT of the PROPERTY whose valorization is subject to the cyclic constraint (sem);
  • ⁇ 18_6_constrained_property> belongs to the primary key, and is referenced by [ ⁇ 33_is_limited_by> ⁇ ⁇ 24_is_being_updated> ⁇
  • ⁇ 18_6_constrained_property> is, within the frame of the CASCADE ⁇ 18__l_constrained_cycle>, the PROPERTY whose valorization is subject to the cyclic constraint (sem);
  • ⁇ 18_7_exclusion_persistence_flag> is an obligatory attribute that admits the values [' ⁇ ', ⁇ '] (synt);
  • ⁇ 18_7_exclusionj?ersistence_fLag> determines whether the value of the PROPERTY ⁇ 18_6_constrained_property> must be equal to that taken at the first execution of the cycle (value 'P') or must be different from all those taken at the previous (i-1 ) executions of the cycle (value ' ⁇ ') (sem).
  • LOGIC sub-step also called “logic layer”, or logical predication
  • logic layer refers to a set of access, computation and update components of the programs of an OLTP-App, aimed at ensuring that, through the effect of each execution of each program, the persistent state released by the execution will be different from the initial one and logically admissible (e.g. "commit”), or that, alternatively, the execution of the program will not produce any modifications of the initial persistent state (e.g. "rollback").
  • the “logic layer” specifies the "sentence-based” syntactical component of the REM SPECIFICATION relating to an OLTP-App. Unlike the other two layers, i.e. the "persistent” and “conversational” ones, which assess the specification components of the OLTP-App in "modelled” format (that is, they represent them by means of ELEMENTS of ENTITIES of a Relation Scheme), the “logic layer” needs a "sentence-based” language, which is used for specifying the non-relational integrity constraints affecting the "persistent layer” of the OLTP-App and the logic constraints that regulate the "conversational layer” of the same OLTP-App.
  • the "logic layer” may equivalently be specified in free linguistic format or by using a specific logic-formal language, e.g. the "Syriac” language.
  • “Syriac” is a specific pseudo-quantified declination of the more general Logic of Predicates ("First-Order Logic”), finalized and optimized for logical predication applied to "persistent layers” and “conversational layers” of OLTP-Apps previously specified in the formal language of the REM SPECIFICATION.
  • Fig. 3e shows, by way of example, the following tables, indicating at the centre the collection of the logic sentences that constitute the "logic layer”:
  • logic sentence The context of use of a logic sentence is transferred to the latter by the semantic connection that invokes it.
  • the logic sentence is pre-existent to any invocation, and is therefore independent of the specific invocation contexts (in other terms, the text of the logic sentence is not affected by any "side-effects").
  • the semantic invocation connection univocally defines the instancing field (field of assignment of the free variables of the logic sentence, on which the logic sentence makes the truthfulness computation) and the type of use of the logic sentence (constraint, or condition, or algorithm, or selection).
  • the free variables of the logic sentence are assigned the current value state at the instant of its invocation, in the course of the transactional conversation.
  • the free variables take valorization from the ELEMENT under update and/or from the ELEMENTS updated during a previous crossing (EVENTS localized at the nodes already crossed of the CASCADE BRANCH); in the case of multiple crossing due to the effect of return cycles, the free variables take valorization from the ELEMENTS updated in the last return cycle crossed.
  • FIG. 8 there is shown an exemplary table representing the association between each admissible declarative sentence (mapped in the logical predication graph of Fig. 7) and the table correspondingly filled in.
  • said sentence is of the 'C type, i.e. it can be used as a conversation control condition, i.e.
  • said sentence is of the 'A' type, i.e. it can be used for making automatic valorizations, i.e.
  • said sentence is of the 'S' type, i.e. it can be used for defining assignment fields
  • ⁇ 13_l_logic_sentence_predicate_synthesis> is the primary key (synt); - ⁇ 13 1_Iogic_sentence_predicate_synthesis> is a synthetic expression, formulated in natural language, of the content and/or function of the logical predicate expressed by the sentence (sem);
  • ⁇ 13_2_logic_sentence_natural_text> is an AK ("Alternate Key")
  • ⁇ 13_3_logic_sentence_syriac_predicate> is a key with admissible null values and persistent non-null values ("Nullable Key” or "NK”) (synt); if the key is not null, it has requisites of persistence and univocity, but may remain at
  • ⁇ 13_3_logic_sentence_syriac_predicate> must be the logical predicate expressed by the sentence, formulated in Iranc or another logic-formal language (sem);
  • ⁇ 13_4_constraint_logic_role_flag> is an obligatory attribute that admits the values ['S ⁇ 'N'] (synt);
  • ⁇ 13_4_constraint_logic_role_flag> takes the value 'S' when the logical predicate expressed by the sentence has a declarative nature and constitutes a permanent universal constraint on the state of the data; it takes the value 'N' in the other cases (sem);
  • ⁇ 13_5_condition_logic_role_flag> is an obligatory attribute that admits the values ['S', ' '] (synt);
  • ⁇ 13_6_algorithm_logic_role_flag> is an obligatory attribute that admits the values ['S ⁇ 'N'] (synt);
  • ⁇ 13_6_algorithm_logic_role_flag> takes the value 'S' when the logical predicate expressed by the sentence has imperative mode and can be used for making automatic valorizations; it takes the value 'N' in the other cases (sem);
  • ⁇ 13_7_selection_logic_role_flag> is an obligatory attribute that admits the values ['S ⁇ 'N'] (synt);
  • ⁇ 13_7_selection_logic_role_flag> takes the value 'S' when the logical predicate expressed by the sentence has imperative mode and can be used for defining assignment fields; it takes the value 'N' in the other cases (sem).
  • step 147 CENSUS OF ATOMIC FORMULAE.
  • the syntactical format of the declarative sentence CENSUS OF ATOMIC FORMULAE, with multiple cardinality " ⁇ " is:
  • ⁇ 12_l_symbolic_identifier> is the primary key (synt);
  • ⁇ 12_l_symbolic_identifier> must be a uni vocal synthetic symbolic expression, which is used in the logic sentences where the atomic formula ⁇ 12_2_atomic_formula_natural_text> recurs (sem);
  • ⁇ 12_2_atomic_formula_natural_text> must be a free formulation, formulated in natural language, of the comparison predicate expressed by the atomic formula (sem);
  • syriac predicate> is a key with admissible null values and persistent non-null values ("Nullable Key” or "NK”) (synt);
  • ⁇ 12_3 atomic_formula_syriac_predicate> must be the expression in Iranc, or in another logic-formal language, of the atomic formula (sem);
  • ⁇ 12_4_error_message_natural_text> is a key with admissible null values and persistent non-null values ("Nullable Key” or "NK”) (synt);
  • ⁇ 12_4_error_message_natural_text> is an obligatory attribute if the sentences ⁇ 13_l_logic_sentence_natural_text> where it recurs are used as a universal constraint (type 'V') and/or as a conversation control condition (type 'C'); otherwise, it is not valorized (sem).
  • step 149 CONNECTION OF ATOMIC FORMULAE
  • ⁇ 14_l_invoked atomic_formula> belongs to the primary key, and is referenced by ⁇ 16_recurs_in> (synt);
  • ⁇ 14_2_invoking_logic_sentence> belongs to the primary key, and is referenced by ⁇ 17_uses> (synt).
  • the declarative process flow (described above in detail with reference to the graphs of Figs. 2, 5a, 5b and 7) r allows to decompose and reduce the overall specification of any one OLTP-app into atomic information units, which can be represented in the form of tuples of values of tables of the relation scheme in Third Normal Form shown in Figs. 3a-3b-3c-3d-3e, or of any other relation scheme semantically equivalent thereto, provided that it is compliant with the Third Normal Form.
  • the process flow guides the declaration of the ONTOLOGICAL FOUNDATION component of the OLTP-app: said component exclusively sticks to the objective reality state of the PERCEPTION FIELD of the application, and is technologically implemented into the design of the database of the OLTP-App.
  • the Philosophical Configuration stage is supported, depending on progressively emerging "logic requirements", by a centralized “repository” of the OLTP-app's logic, which is progressively fed according to the flow shown in Fig.
  • this repository is the set of the logic propositions that regulate the access, computation, control and update of the application's database: such a centralization of the logical predication, which is also decomposed and reduced into tuples of tables of a relation scheme in Third Normal Form, intrinsically and automatically ensures minimization of code rows (the same "logic sentence", even when used by multiple invocation contexts, is specified only once, with no duplication of equivalent code); this decomposition or reduction also ensures, where a logic-formal language such as, for example, Iranc is used for the logic sentences, the possibility of writing the OLTP- app's code in a fully automated manner.
  • a logic-formal language such as, for example, Iranc is used for the logic sentences
  • the method of the invention obviates both types of approximation which are implicit in code generators and automatic computer-aided engineering tools known in the art, because it eliminates the need for any "downstream” manual programming while still preserving and ensuring "upstream” universal expressivity at the highest detail level; for this reason, the method of the invention is absolutely novel in this field of application.
  • Industrial applicability of the method according to the invention consists of the possibility of creating automatic reading and writing devices, e.g. a "parser”, comprising a software product that takes care of preliminarily interpreting a REM SPECIFICATION (reading and interpretation), verifying its syntax (correction and validation) and, if the syntactical verification is successful, definitively and automatically transforming it into equivalent source code (source code writing), one for each "technological stack" considered to be of interest, and then maintaining the evolution thereof consistent with the evolution of the respective reference technological levels.
  • a parser comprising a software product that takes care of preliminarily interpreting a REM SPECIFICATION (reading and interpretation), verifying its syntax (correction and validation) and, if the syntactical verification is successful, definitively and automatically transforming it into equivalent source code (source code writing), one for each "technological stack" considered to be of interest, and then maintaining the evolution thereof consistent with the evolution of the respective reference technological levels.
  • technological stack also called platform or architecture
  • platform or architecture refers to a complex of interconnected and cooperating apparatuses and hardware and/or firmware and/or middleware tools which, while operating in logistical and environmental conditions complying with their respective operating specifications, allow for operability and usability of software systems by human users and/or automatic computers.
  • a first advantage of the method and device according to the invention is the definition of a syntactical format and a writing rule that allow to represent the specification of an OLTP-app in such a way that the number of code rows to be produced is intrinsically and automatically minimized, and that the whole code can be produced in a fully automatic manner without requiring any further manual integration.
  • the unavailability of a "code repository” prevents optimizing the reuse rate of the already written code, and the total quantity of code (defined by convention as "number of code rows”) is not intrinsically minimized.
  • the method according to the present invention gets round this inefficiency by intrinsically ensuring minimization of the number of code rows.
  • a second advantage of the method and device according to the invention is the automation of chronological and geographical version control (also referred to as “versioning").
  • the notion of "variation” is aleatory and discretionary.
  • the present invention obviates such aleatoriness by providing a formal, metrical and universal definition of a "variation measurement unit” and by establishing a preset "variation threshold” that determines the division between "changed version” and "unchanged version”. Because such criterion has a formal, metrical and universal nature (non- discretionary), the management of chronological and geographical “versioning" can be totally automated without requiring "human discretion”.
  • a third advantage of the method and device according to the invention is that the computation of the code function points (also referred to as "Unadjusted function points") is totally and accurately automated prior to the production of the source code.
  • the present invention radically obviates the weak points of the function-point (FP) metrics.
  • FP function-point
  • the computation of the FPs consists merely of counting the number of "records" contained in some tables of the scheme. This computation can be completely automated, because it can be expressed, for example, in standard SQL syntax.
  • the computation can be made before the software coding stage begins, and is independent of it because it is exclusively founded on the specification.
  • a further advantage of the method and device according to the invention is the achievement of automatic availability and extractability of the functional testing plan.
  • the method according to the present invention allows for automatic extraction of the testing plan by connecting the specification to a relation scheme, which also models the logic component by atomizing it into atomic formulae. Also the census of all possible logic branches is referable to the combinatorial computation of all possible relational navigations in the current state of the relation scheme.
  • a further advantage of the method and device according to the invention is that the contextual (mouse-sensitive) user documentation is automatically available to the users, already incorporated into the application itself.
  • the so-called “semantic" columns of the relation scheme are specifically dedicated to this purpose, and they do not affect the syntactical validation of the specification.
  • Such a variant is semantically equivalent, because the logic function of an entry guard of an update EVENT and/or an EVENT that requires manual valorization of at least one migrated PROPERTY is to reduce the selection made by the invoked profile to values which are logically compatible with the previous valorizations in the course of the CASCADE. For example, if the cadastral surveys of the real estate units owned by a person subject to the Italian law are being updated to the EVENT 2, previously selected at the EVENT 1, the selection profile of the real estate units to be updated will have to exclude all those outside the national territory, whereas the invoked profile, being of decontextualized nature, would extract them all.
  • the present invention is not limited to a method and a device for defining and creating specifications of software systems, in particular of the OLTP-App type, but may be subject to many modifications, improvements or replacements of equivalent parts and elements without departing from the inventive idea, as clearly specified in the following claims.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

A method is described for creating specifications of software systems, in particular of the OLTP-App type, said method comprising a STATIC step, a DYNAMIC step and a LOGIC step adapted to build a relation scheme, and wherein said STATIC step, said DYNAMIC step and said LOGIC step use declarative sentences having a syntactical format and a writing rule based on an ONTOLOGICAL FOUNDATION THEOREM and on an ONTOLOGICAL REDUCTION RULE.

Description

METHOD FOR CREATING SPECIFICATIONS OF SOFTWARE SYSTEMS, IN PARTICULAR OF THE OLTP-APP TYPE, AND DEVICE THEREOF
DESCRIPTION
The present invention relates to a method in the field of the definition and creation of specifications of software systems, in particular of the OLTP-App ("On Line Transaction Processing- Application") type, without limitation of the potential range of logic expressivity, and therefore applicable to any semantic domain and any functional requirement, regardless of their extension and complexity.
It is known that the objective of defining a complete and universal syntactical format for specifying a software system, which allows the next programming stage to be automated without needing any further human intervention, has been pursued for a long time at both academic and industrial level, but ever-increasing theoretical expectations in terms of efficiency and productivity have led to disappointing practical outcomes. Two distinct approaches to the problem have been adopted so far. The first one is the code generator approach (e.g. Telon by CA Technologies), which pursues "vertical approximation", privileging the objective of fully automating the writing of the final source code, but limiting the breadth of the expressive range to a pre- packaged library of logic modules, selected according to their statistic recurrence index. Practice has shown that a real requisite is never totally referable to parameterization and assembly of standardized logic modules, however large and updated the available library. In systems developed by using code generators, therefore, the product code needs to be automatically integrated with a manually produced code, leading to high integration costs, low logic consistency and uncontrolled proliferation of the number of code rows.
The second approach uses automatic computer-aided software engineering tools (commonly called "CASE Tools", e.g. StP by Atego), which on the contrary pursue "horizontal approximation", privileging the objective of ensuring expressive universality, but sacrificing the detail depth of the specification. Practice has shown that the manual programming of detailed logic, which is necessary in order to complete the high-level logic, is however very time-consuming, so that producing systems specified by using this approach will not cost less than traditionally specified systems for totally manual programming. Furthermore, both the first and second approaches just described are inadequate for minimizing the number of code rows, since the manual coding required in both cases is not supported by a centralized and normalized repository of "atomic logic modules" (e.g. the so-called "code repositories"), which must be understood as the application's ultimate and indivisible units of behaviour: the progressive occurrence of requisites is responded to by creating an "ad hoc" code block, with no formal tool intrinsically ensuring non-duplication of already written code: the unavailability of a code repository prevents optimizing the reuse rate of the already written code, and the total quantity of code (defined by convention as the "number of code rows") is not intrinsically minimized.
It is known that all software systems need version control (commonly referred to as "versioning"), both chronologically (evolution of the code's state over time) and geographically (co-presence of different code's states based on different users, the chronological version being the same).
In the current state of the art, moreover, the notion of "variation" (i.e. occurrence of a "new version") is aleatory and discretionary: this is due to the fact that no definition of a formal, metric and universal "variation measurement unit" exists based on which, following any modification made to the code, one can take a "metric measurement of the quantity of variation" introduced, thus objectively and unquestionably defining if a "new version" has turned up depending on whether the quantity of variation introduced exceeds or not a preset "variation threshold", which of course is also expressed in "variation measurement units".
The software metrics known in the art are based on the definition of the so-called function point (also called "UFP" or "Unadjusted function point"), which is intended as a software "weight measurement unit". Such function points aim at measuring the functionality received and requested by the user, measuring the results of the software development and/or maintenance activities regardless of the technology in use, and providing a measurement which is consistent among different projects and producers. The methods for measuring the functional dimension currently recognized as international standards are bound to detecting and weighing "data movements" and "logic archives", without any evaluation of the complexity and number of algorithms, i.e. data manipulation components. Also, in some cases the programmers/technicians themselves calculate the function points of the software manually, thus considerably increasing software management costs.
The last important aspect to be taken into account is the creation of the software's functional testing plan. A few testing standards are currently in use, e.g. the IEEE 829- 2008 standard, all of which require a strong manual intervention for compiling the testing plan.
It is therefore one object of the present invention to provide a universally and completely expressive method, as well as a device thereof, for creating specifications of software systems, in particular of the OLTP-App type, which allow minimizing the number of code rows and producing them in a fully automatic manner.
It is a second object of the present invention to provide a universally and completely expressive method, as well as a device thereof, for creating specifications of software systems, in particular of the OLTP-App type, which allow automating the chronological and geographical versioning process.
It is a third object of the present invention to provide a universally and completely expressive method, as well as a device thereof, for creating specifications of software systems, in particular of the OLTP-App type, which allow automating the computation of the code function points.
It is a further object of the present invention to provide a universally and completely expressive method, as well as a device thereof, for creating specifications of software systems, in particular of the OLTP-App type, which allow obtaining the functional testing plan in an automatic, logically complete and operationally exhaustive manner. These and other objects of the invention are achieved through a method and a device for creating specifications of software systems, in particular of the OLTP-App type, as claimed in the appended claims, which are intended to be an integral part of the present description.
In brief, a method and a device are described for creating specifications of software systems, in particular of the OLTP-App type, wherein, according to said method, a declarative process flow allows decomposing and reducing a global specification of any OLTP-app into atomic information units, which can be represented in the form of tuples of values of tables of a relation scheme in Third Normal Form, or of any other relation scheme semantically equivalent thereto, provided that it adheres to the Third Normal Form.
The above objects will become more apparent from the following detailed description of a method for creating OLTP-Apps according to the present invention, with particular reference to the annexed drawings, wherein:
- Figure la shows an example of embodiment of a device according to the present invention;
- Figure lb shows one possible form of the topological and notational syntax of the graphs shown in the next figures;
- Figure 2 shows a process flow of the method according to the present invention;
. - Figures 3a, 3b, 3c, 3d and 3e show an example of a relation scheme with ERD ("Entity Relationship Diagram") syntax;
- Figure 4 shows an association between some admissible declarative sentences and the tables correspondingly filled in;
- Figures 5a and 5b show further process flows of the method according to the present invention;
- Figure 6 shows a further association between some admissible declarative sentences and the tables correspondingly filled in;
- Figure 7 shows a further process flow of the method according to the present invention;
- Figure 8 shows a further association between some admissible declarative sentences and the tables correspondingly filled in;
- Figure 9 shows an admissibility matrix of the logic sentence types depending on the invoking semantic connection types.
One example of a specification document, or requisite, expressed in free linguistic format may be the following:
"The user company is a public-capital legal subject (with approx. 2,000,000 members) and is obliged to compile and keep a Register of Members, possibly also in electronic format, indicating all entries and exits of subjects becoming or ceasing to be members; each subject's entry/exit must correspond to a separate and individual record; no more than one record, whether relating to an entry or an exit, shall be ■ entered for one subject on the same day. The subjects may be either physical persons PP or legal persons LP, and for each entry and each exit of each one of them the record must include a uni vocal membership code of the entering/exiting subject, the fiscal identifier (tax code for PPs, VAT number for LPs), the date of origin (birth date for PPs, date of establishment for LPs), the onomastic data (name and surname for PPs, corporate name for LPs), the date of entry/exit into/from the company's structure. Entries and exits are generated by share transactions between different subjects, which shall be univocally identified by the year of their initialization and by a univocal progressive number within each year (the number of transactions per year is approx. 150,000): such univocal identification shall be stated in the records of the Register of Members. The date of entry/exit shall be the date of execution of the generating transaction. Some types of transactions may generate simultaneous entry/exit of multiple subjects, up to a maximum number of 5 entries and 5 exits: other transaction types will generate no entry and no exit. Minor PPs shall not be allowed to gain access to the company's structure. Member PPs shall automatically exit the company's structure on the day of their death, whereas member LPs shall automatically exit the company's structure on the day of their dissolution."
Let us now suppose, therefore, that an analyst has fully acquired said requisite of an OLTP-App and has formalized such knowledge in that document.
With reference to Fig. la, said document is re- written, through a declarative process, into a second document (hereafter also referred to as REM SPECIFICATION) comprising a formal language adapted to be recognized by automatic reading devices
200 implementing the method of the invention.
The automatic reading and writing device 200 may be, for example, an advanced parser, which comprises a software product that carries out a preliminary interpretation of a REM SPECIFICATION (reading and interpretation), a verification of its syntax (correction and validation) and, if the syntactical verification is successful, a definitive automatic transformation of the same into equivalent source code (source code writing).
The automatic reading and writing device 200 operates through a declarative process that includes a STATIC step (also referred to as "persistent layer", or ONTOLOGICAL FOUNDATION) and an anthropological configuration step, which then continues with the parallel development of a DYNAMIC sub-step (also referred to as "conversational layer", or man-machine conversation) and a LOGIC sub-step (also referred to as "logic layer", or logical predication).
Said automatic reading and writing device 200 comprises syntactical reading means
201 adapted to interpret the REM SPECIFICATION, and a processor 203 adapted to control and process all the operations necessary for automatic reading and writing. Said automatic reading and writing device 200 further comprises memory means 205 adapted to store the data obtained by reading the REM SPECIFICATION. Such memory means 205 may comprise the "persistent layer" of the device, e.g. a relational database.
Finally, the automatic reading and writing device 200 further comprises a source code generator 207 adapted to output a source code implementing the REM SPECIFICATION of the requisite of an OLTP-App.
The "persistent layer" is meant to be a set of persistent structural components of an OLTP-App which are independent of the programs, and which can be programmed by exclusively using the relational database programming syntax, in particular the ASCII ("American Standard Code for Information Interchange") SQL ("Structured Query Language") standard language.
The term "ONTOLOGICAL FOUNDATION" refers to the fact that the REM SPECIFICATION of the "persistent layer" of an OLTP-App is obtained by iteratively applying the ONTOLOGICAL FOUNDATION THEOREM and the ONTOLOGICAL REDUCTION RULE.
According to the ONTOLOGICAL FOUNDATION THEOREM, a predicative category is ontologically founded only if at least one creation EVENT exists which belongs to the PERCEPTION FIELD, the OCCURRENCES of which can be represented by means of the creation of one and only one tuple of the relation representing it (for example, the insertion of one and only one record in a table), and said relation (the table) complies with the "Third Normal Form", or 3NF. As a consequence, all the predicative categories represented in the "persistent layer" of an OLTP-App must be ontologically founded, i.e. the ELEMENTS of a logic category without ONTOLOGIC FOUNDATION would be lacking a measurement process for individually identifying and qualifying them without any interaction with ELEMENTS of other logic categories, and therefore could not represent reality states.
The term PERCEPTION FIELD refers to the set of OCCURRENCES that the user thinks is useful to notify to the "persistent layer" for future certain, retrievable and authenticated memory. The PERCEPTION FIELD is defined at the user's discretion on the basis of a usefulness criterion, and is an integral part of the requisite. An OLTP- App can therefore be compared to an artificial organism equipped with a "sensory system" selectively and exclusively oriented towards the goal of its own existence: the "senses" of an OLTP-App are the programs through which the OCCURRENCES of interest are "perceived" (conversationally declared) and "stored" (saved into a database).
ONTOLOGICAL REDUCTION RULE means that any type of OCCURRENCE of the PERCEPTION FIELD not having the EVENT requirement can be reduced to a succession of EVENTS only affecting ontologically founded ENTITIES, which can be represented, for example, through a 1 -weighted conditional Petri net, also known as CASCADE.
The PERCEPTION FIELD being equal, this specification area is independent of the user's historical, economical, social, cultural, organizational, regulatory, operational or psychological environment, in that it is solely representative of the OCCURRENCES of the EVENTS belonging to the PERCEPTION FIELD itself.
With reference to Fig. lb, there is shown one possible form of the topological and notational syntax of the graphs shown in the next figures.
The steps and sub-steps of the declarative process comprise a declaration of sentences, the syntactical structure of which is typified and the succession of which is regulated and controlled by a process flow; the admissible types of declarative sentences, as well as the syntactical format and writing rules applicable to each one of them, will be listed and described below.
The STATIC step consists of identifying EVENTS belonging to the PERCEPTION FIELD of an OLTP-App, and assigning values to attributes and relations that characterize them. Such identification and qualification of the EVENTS fully and univocally defines the "persistent layer" of the OLTP-App, e.g. a database ("DB", or Relation Scheme).
The specification declarations of the STATIC step must proceed through the graph of the process flow shown in Fig. 2.
With reference to Figs. 3a, 3b, 3c, 3d and 3e, there is shown an ERD diagram ("Entity- Relationship Diagram") subdivided into five sheets connected through the reference numbering that comprises the following connection relationships:
'l_is_affected_by' from sheet 3a to sheet 3c;
7_contains' from sheet 3 a to sheet 3 b;
'8_belongs_to' from sheet 3a to sheet 3b;
'9_admits_the_value' from sheet 3a to sheet 3b; '10_is_discriminated_by' from sheet 3 a to sheet 3b;
'13_is_updated_by' from sheet 3a to sheet 3c;
Ί 8_conditions_entry' from sheet 3e to sheet 3c;
'19_conditions_exit' from sheet 3e to sheet 3c;
'22_conditions_launch' from sheet 3e to sheet 3c;
'23_is_in_conversation' from sheet 3c to sheet 3d;
'24_is_being_updated' from sheet 3c to sheet 3d;
'25_conditions_obligatoriness' from sheet 3e to sheet 3d;
'26_conditions_automaticity' from sheet 3e to sheet 3d;
'27_conditions_persistence' from sheet 3e to sheet 3d;
'28_calculates_value' from sheet 3e to sheet 3d;
'29_calculates_default' from sheet 3e to sheet 3d;
'32_is_subject_to_the_update_constraint' from sheet 3c to sheet 3d;
'34_is_profiled_by' from sheet 3a to sheet 3b;
'36_is_selection_filter_in' from sheet 3a to sheet 3b;
'37_defines_selection_navigation' from sheet 3e to sheet 3b;
'39_is_displayed_in' from sheet 3a to sheet 3b;
'40_defines_display_navigation' from sheet 3e to sheet 3b.
It is clear that the ERD diagram shown in Figs. 3a, 3b, 3c, 3d and 3e represents just an example; in fact, reference may also be made to any other semantically equivalent ERD scheme.
In particular, Figs. 3a, 3b and 3c show, for example, the following tables referring to the STATIC step:
1_EVENTS;
2_ENTITIES;
3_PROPERTIES;
4 RELATIONS;
5_KEYS;
6_KEY_PROPERTIES;
7_CLOSED_DOMAIN_PROPERTIES;
8_DISCRIMINANT_V ALUES;
10_UPDATED_PROPERTIES.
The association between each admissible declarative sentence (hence mapped in the graph of Fig. 2) and the table correspondingly filled in is expressed in Fig. 4.
Again with reference to Fig. 2, each graph execution cycle starts at step 101, CENSUS
OF EVENT.
An EVENT is meant to be a specific type of OCCURRENCE of the PERCEPTION FIELD, intensively defined by the set of PROPERTIES subject to valorization in accordance with predefined and stable measurement protocols, which can be represented by means of the creation (creation EVENT) or modification (update EVENT) of one and only one tuple in one and only one ENTITY, called "ENTITY affected by the EVENT", and can therefore be implemented in computer science by exclusively inserting ("insert") or updating ("update") one and only one record ("row") in one and only one table ("table").
A PROPERTY is meant to be a logic attribute that identifies and/or qualifies an ENTITY, which can be represented by means of a relation column, and can therefore be implemented in computer science as an attribute ("column").
The syntactical format of the declarative sentence CENSUS OF EVENT, with single cardinality "1", is, for example:
"The EVENT <l_l_event_name>, consisting of the <l_2_event_definition>, belongs to the PERCEPTION FIELD,
which creates [<l_3_event_type> ='C],
or
which updates [<l_3_event_type> =' A']
ELEMENTS of the ENTITY <l_4_affected_entity>".
The rules for writing the declarative sentence CENSUS OF EVENT are as follows:
<l_l_event_name> is the primary key (synt);
- <l_2_event_definition> is an obligatory attribute (synt);
<l_2_event_definition> must be a vocabulary definition of a generic instance of the EVENT (sem);
<l_3_event__type> is an obligatory attribute that admits the values ['C'('creation'), 'A' ('update')] (synt);
- <l_4_affected_entity> is an obligatory attribute, referenced by
<l_is_affected_by> (synt);
The EVENT <l_l_event_jiame> must reference, through <12_updates>, at least one PROPERTY of the affected ENTITY <l_4_affected_entity> which undergoes valorization through the effect of its instances (synt);
All the PROPERTIES referenced through <12_updates> by the EVENT <l_l_event_name> must ' belong to the affected ENTITY <l_4_affected_entity> (synt);
The EVENT <l_l_event_name> must reference, through <15_is_node_of> at least one CASCADE in which it recurs as a node (synt). A writing rule is "syntactical" (synt) if it concerns the formal correctness of the specification (accuracy); instead, it is "semantic" (sem) if it refers to the compliance of the specification with the represented reality state (adequacy). The syntax of a specification can be verified and validated by means of an automatic analyzer. On the other hand, semantic writing rules do not affect the automatic transformation of a REM SPECIFICATION into source code, which is carried out by a parser device. The obligatoriness of declaring the ENTITY affected by the EVENT imposes that, if the EVENT under census turns out to be the first creation EVENT of the declared affected ENTITY, the following contextual declaration must then be made.
At step 103, the syntactical format of the declarative sentence CENSUS OF ENTITY, with single cardinality "1", is:
"The ENTITY <2_l_entity_name> represents <2_2_entity_definition>".
The rules for writing the declarative sentence CENSUS OF ENTITY are as follows:
<2_l_entity_name> is the primary key (synt);
<2_2_entity_definition> is an obligatory attribute (synt);
<2_2_entity_defmition> must be a vocabulary definition of the generic ELEMENT of the ENTITY (sem).
An ELEMENT is meant to be a logic element belonging to an ENTITY, which can be represented by means of a relation tuple, and can therefore be implemented in computer science as a record ("row" of a table);
The ENTITY <2_l_entity_name> must reference, through <l_is affected_by>, at least one creation EVENT that affects it (synt);
- The ENTITY <2_l_entity_name> must reference, through
<2_contains>, at least one PROPERTY that belongs to it (synt);
The ENTITY <2_l_entity_name> must reference, through <6_is_identified_by>, the primary key that univocally identifies its ELEMENTS (synt);
If the EVENT founds primitive PROPERTIES in the ENTITY, then step 105, CENSUS OF PRIMITIVE PROPERTIES, is carried out. The syntactical format of the declarative sentence CENSUS OF PRIMITIVE PROPERTIES, with multiple cardinality "j", is:
"The primitive PROPERTY <3_l_property_name> [<3_3_migrated_primitive_flag> = 'P'] of the ENTITY <3_2_entity_it_belongs_to> measures <3_4_property_definition>, admits <3_5_dimension> characters at most,
is obligatory [<3_6_null_value_admissibility_flag> = 'NOT NULL'],
or
is optional [<3_6_nuU_value_admissibility_flag> = 'NULL'],
is filled on the right [<3_7_zero_filling_on_the_right_flag> = 'S'],
or
is not filled on the right [<3_7_zero_filling_on_the_right_flag> = 'N'],
is filled on the left [<3_8_zero_filling_on_the_left_flag> = ' S ' ] ,
or
is not filled on the left [<3_8_zero_filling_on_theJeft_flag> = 'Ν'],
is comparable [<3_9_computable_comparable_flag> = 'C'],
has an open domain [<3_16_open_closed_domain_flag> = Ά'],
with regular expression <3_18_regular_expression>,
or
has a closed domain [<3_16_open_closed_domain _flag> = 'C'],
with all non-discriminant values [<3_17_discrimination_role_flag> = 'N'],
or
has a closed domain [<3_16_open_closed_domain flag> = 'C'],
with discriminant values [<3_17_discrimination_role_flag> = 'S'],
or
is computable [<3_9_computable_comparable_flag> = 'N'],
has precision <3_10_precision>,
has dimensional equation <3_1 l_dimensionality>,
admits negative values [<3_12_negative_value_admissibility_flag> = 'S'],
or
does not admit negative values [<3_12_negative_value_admissibility_flag> = 'N'], is absolute [<3_13_differential_absolute_value_flag> = Ά'],
or
is differential with a constant base [<3_13_differentiaI_absolute_value_flag> = 'D'], or
is differential of the 'date' type [<3_13_differential_absolute_value_flag> = 'D' and <3_14_date_type_flag> = 'S'],
or
is differential of the 'coordinate' type [<3_13_differential_absolute_value_flag> = 'D' and <3_15_coordinate_type_flag> = 'S'].
The rules for writing the declarative sentence CENSUS OF PRIMITIVE PROPERTIES are as follows:
<3_l_property_name> is the primary key (synt);
<3_2_entity_it__belongs_to> is an obligatory attribute, referenced by <2_contains> (synt);
- <3_3_migrated_primitive_flag> is an obligatory attribute, which admits the values ['Ρ', 'Μ'] (synt);
<3_3_migrated_primitive_flag> determines whether the PROPERTY <3_l_property_name> is native of the ENTITY it belongs to <3_2_entity_it_belongs_to> (value 'P') or is migrated in the ENTITY it belongs to <3_2_entity_it_belongs_to> by a relation (value 'M') (sem);
<3_4jproperty_definition> is an obligatory attribute (synt); <3_4_property_definition> must be a vocabulary definition of the semantic attribute that identifies and/or qualifies the ELEMENTS of the ENTITY it belongs to <3_2_entity_it_belongs_to> (sem);
- <3_5_dimension> is an obligatory attribute with integer numeric values
(synt);
<3_5_dimension> determines the maximum number of significant characters available for the values of the PROPERTY <3_l__property_name> (sem);
- <3_6_null_value_admissibility_flag> is an obligatory attribute that admits the values ['NULL', 'NOT NULL'] (synt);
<3_6_null_value_admissibility_flag> determines whether the value of the PROPERTY <3_l_property_name> can be unknown when the ELEMENT is created (value 'NULL') or must necessarily be valorized (value 'NOT NULL') (sem);
<3_7_zero_filling_on_the_right_flag> and <3_8_zero_filling_on_the_left_flag> are both obligatory attributes that admit the values ['S\ 'N'] (synt);
<3_7_zero_filling_on_the_right_flag> and <3_8_zero_filling_on_the_left_flag> determine whether the values of the PROPERTY <3_l_property_name> must be exposed in conversation with zeroes entered on the right and/or on the left of the non-significant characters (value 'S') or must be limited to the significant characters (value 'N')
(sem);
<3_9_computable_comparable_flag> is an obligatory attribute that admits the values ['Ν', 'C'] (synt);
<3_9_computable_comparable_flag> determines whether the PROPERTY <3_l_property_name> is computable (value 'N') or only comparable (value 'C'); a PROPERTY is computable if and only if the set of its admissible values is an ordered range, i.e. if a closed algebra of sum and product has been defined on it (typically, but non exclusively, a numeric set) (sem);
<3_10__precision> is an attribute with integer numeric values: it is obligatory if <3_9_computable_comparable_flag> = 'N'; otherwise, it is not valorized (synt);
<3_10_precision> determines, in base 10 (ten), the characteristic of the values of the PROPERTY <3_l_property_name> (number of significant digits after point) (sem);
<3_10_precision> may not exceed [<3_5_dimension> - 1] (synt);
<3_1 l_dimensionality> is an obligatory attribute if <3_9_computable_comparable flag> = 'N'; otherwise, it is not valorized (synt);
<3_l l_dimensionality> determines the dimensional equation of the PROPERTY <3_l_property_name>, expressed in the MKSA$ (Metre-Kilo- Second-Ampere-Dollar) International System (sem);
<3_12_negative_value_admissibility_flag_> is an attribute that admits the values ['S','N']: it is obligatory if <3_9_computable_comparable_flag> = 'N'; otherwise, it is not valorized (synt);
<3_12_negative_value_admissibility_flag> determines whether the PROPERTY <3_l_property_name> admits negative values (value 'S') or only positive or null values (value 'N') (sem);
<3_13_differential_absolute_value_flag> is an attribute that admits the values [Ά',Ό']: it is obligatory if <3_9_computable_comparable_fiag> = 'N'; otherwise, it is not valorized (synt);
<3_13_differential_absolutejvalue_flag> determines whether the measurement values of the PROPERTY <3_l_property name> are absolute (value Ά') or differential (value 'D') (sem);
It is important to specify that a PROPERTY is differential when its values are measured with reference to an origin of values conventionally assumed to be equal to 0, as is typically, but not exclusively, the case of dates (time intervals between the measured instant and a conventional instant of origin, assumed to be equal to 0) or localizations (spatial intervals between the measured point and a conventional point of origin, assumed to be equal to 0).
<3_14_date_type_flag> and <3_15_coordinate_type_flag> are attributes that admit the values ['S' N']: they are obligatory if <3_9_computable_comparable_flag> = 'N' and
<3_13_differential_absolute_value__flag> = 'D' (synt);
<3_14_date_type_flag> and <3_15_coordinate_type_flag> determine, respectively, whether the PROPERTY with differential values is a date (respective values: 'S', 'N') or a geographical coordinate (respective values: 'N', 'S') or neither of the two (respective values: 'N', 'N') (sem);
A PROPERTY <3_l_property_name> with differential values may not be both a date and a geographical coordinate at the same time (synt);
<3_16_open_closed_domain_flag> is an attribute that admits the values ['A','C']: it is obligatory if <3_9_computable_comparable_flag> = 'C; otherwise, it is not valorized (synt);
<3_16_open_closed_domain_flag> determines whether the value domain of the PROPERTY <3_l_property_name> is free (value Ά') or the PROPERTY <3_l_property_name> only admits a set of previously known values, which may not be changed for the whole life cycle of the OLTP- App (value 'C') (sem);
<3_17_discrimination_role_flag> is an attribute that admits the values ['S','N']: it is obligatory if <3_9_computable_comparable_flag> = 'C and <3_16_open_closed_domain_flag> = 'C ; otherwise, it is not valorized (synt);
<3_17_discrimination_role_flag> determines whether one or more of the admissible values for a closed-domain PROPERTY <3_l_property_name> play a role as discriminant values (value 'S') or not (value 'N') (sem);
<3_18_regular_expression> is an obligatory attribute if <3_9_computable_comparable_flag> = 'C and <3_16_open- closed_domain_flag> = Ά'; otherwise, it is not valorized (synt);
<3_18_regular_expression> determines the admissible characters for each one of the notification positions for the values of the PROPERTY <3_l_property_name>, i.e. the so-called 'regular expression' of the information attribute that implements the PROPERTY <3_l_property_name> (sem);
given an ENTITY <3_2_entIity_it_belongs_to>, at least one PROPERTY <3_l_property_name>, whether primitive or migrated, must exist which, through <8_belongs_to>, belongs to the primary key ("PK") (synt); for all those PROPERTIES <3_l_property_name> which, through <8_belongs_to>, belong to the primary key ("PK"), or to at least one alternate key ("AK"), <3_6_null_value_admissibility_flag> must be 'NOT NULL' (synt);
all the other PROPERTIES that have
<3_16_open_closed_domain_flag> = 'C must reference, through <9_admits_the_value>, at least two admissible values (synt);
all those PROPERTIES <3_l_property_name> that have <3_16_open_closed_domain flag> = 'C and
<3_17 discrimination_role_flag> = 'S' must reference, through [<9_admits_the_value> → <1 l_discriminates>], at least one discrimination relation (synt);
the PROPERTY <3_l_property_name> must be updatable, through <13_is_updated_by>, by at least one EVENT (synt); all those PROPERTIES <3_l_property_name> which belong neither to the primary key ("PK") nor to any alternate key ("AK") must comply with the Third Normal Form ("3NF") (sem).
It is important to specify that an (elementary) PROPERTY is in "3NF" if and only if it functionally depends on the primary key ("PK") and all alternate keys ("AK") in a complete and non-transitive manner.
If there are any closed-domain primitive PROPERTIES, the CENSUS OF CLOSED- DOMAIN VALUES is carried out at step 107.
A "closed-domain PROPERTY" is meant to be a primitive PROPERTY whose set of admissible values is known a priori, and will not certainly change for the whole life cycle of the application: by way of example, the personal PROPERTY "sex" of an individual may always only take the value "M" (male) or "F" (female).
The syntactical format of the declarative sentence CENSUS OF CLOSED-DOMAIN
PROPERTIES, with multiple cardinality "v", is:
"The closed-domain comparable primitive PROPERTY <7_l_valorized_property> admits the value <7_2_admissible_value> meaning
<7_3_admissible_value_semantics>".
The rules for writing the declarative sentence CENSUS OF CLOSED-DOMAIN VALUES are as follows:
- <7_l_valorized_property> belongs to the primary key, and is referenced by <9_admits_the_value> (synt);
<7_2_admissible_value> belongs to the primary key (synt); <7_3_admissible_value_semantics> is an obligatory attribute (synt); <7_3_admissible_value_semantics> must be a vocabulary definition of the specific meaning of the admissible value <7_2_admissible_value> (sem);
The PROPERTY <7_l_vaIorized_property> must be a closed-domain primitive one (synt);
The admissible value <7_2_admissible_value> must comply with the format of the PROPERTY <7_l_valorized_property> as concerns dimension and regular expression (synt).
If, on the contrary, the EVENT founds at least one migrated PROPERTY in the ENTITY, then at step 109, CENSUS OF RELATIONS is carried out. The syntactical format of the declarative sentence CENSUS OF RELATIONS, with multiple cardinality "x", is:
"The relation is
identifying [<4_5_relation_type_flag> = T],
or
elementary [<4_5_relation_type_flag> = 'Ε'],
or
discriminating [<4_5_relation_type_flag> = 'D'],
<4_l_relation_name> connects, whether
obligatorily [<4_6_no_referencing_admissibility_flag> = 'NOT NULL'],
or
optionally [<4_6_no_referencing_admissibility_flag> = 'NULL'], the referencing ENTITY <4_2_referencing_entity> to the referenced ENTITY <4_3_referenced_entity> in the semantic role as <4_4_relation_definition>
without any numerosity limits [<4_7_numerosity> = NULL],
or
with maximum numerosity <4_7_numerosity>".
The rules for writing the declarative sentence CENSUS OF RELATIONS are as follows:
<4_l_relation_name> is the primary key (synt);
- <4_2_referencing_entity> is an obligatory attribute, referenced by
<3_references> (synt);
<4_3_referenced_entity> is an obligatory attribute, referenced by <4_is_referenced> (synt);
<4_4_relation_defmition> is an obligatory attribute (synt); - <4_4_relation_definition> must be a vocabulary definition of the semantic connection established by the relation between the referencing ENTITY <4_2_referencing_entity> and the referenced ENTITY <4_3_referenced_entity> (sem);
<4_5_relation_type_flag> is an obligatory attribute that admits the values [T, Έ', 'D'] (synt);
<4_5_reIation_type_flag> determines whether the relation <4_l_relation_name> is an identifying one (value T: the primary-key ("PK") PROPERTIES of the referencing ENTITY <4_2_referencing_entity>, migrated by the relation <4_l_relation_name>, are a sub-set of the primary- key ("PK") PROPERTIES of the referenced ENTITY <4_3_referenced_entity>), or is an elementary one (value Έ': none of the primary-key ("PK") PROPERTIES of the referencing ENTITY <4_2_referencing_entity>, migrated by the relation <4_l_relation_name>, belongs to the primary key ("PK") and/or to the alternate keys ("AK") of the referenced ENTITY <4_3_referenced_entity>), or is a discriminating one (value 'D' : the primary key ("PK") of the referenced ENTITY <4_3_referenced_entity> consists of all the primary-key ("PK") PROPERTIES ("PK") of the referencing ENTITY <4_2_referencing_entity>, migrated by the relation <4_l_relation_name>) (synt);
<4_6_no_referencing_admissibility_flag> is an obligatory attribute that admits the values ['NULL', 'NOT NULL'] (synt);
<4_6__no_referencing_admissibility_flag> determines whether the ELEMENT migrated by the relation <4_l_relation_name> can be unknown when the ELEMENT is created in the referenced ENTITY <4_3_reference_entity>) (value 'NULL') or must obligatorily be valorized (value 'NOT NULL') (sem);
<4_7_numerosity> is an optional attribute: if valorized, it determines the maximum number of ELEMENTS admitted in the referenced ENTITY <4_3_referenced entity>, for the same ELEMENT migrated by the relation <4_l_relation_name> (sem);
the referencing ENTITY <4 2_referencing_entity> and the referenced ENTITY <4_3_referenced_entity> must be distinct (synt);
If <4_5_relation_type_flag> = T or 'D', then <4_6 no_referencing_admissibility_flag> = 'NOT NULL' (synt);
If <4_5_relation_type_flag> = 'D', then <4_7_numerosity> = 1 (synt);
If <4_5_relation_type_flag> = 'D', then at least one discriminant value attributed to the relation <4_l_relation_name> must exist (synt);
If <4_5_relation_type_flag> o 'D', the primary key ("PK") and all alternate keys ("AK") of the referencing ENTITY <4_2_referencing_entity> must differ from the primary key ("PK") and from each one of the alternate keys ("AK") of the referenced ENTITY <4_3_referenced_entity> (synt); If <4_5_relation_type_flag> = 'D', the primary key ("PK") of the referenced ENTITY <4_3_referenced entity> must coincide with the primary key ("PK") of the referencing ENTITY <4_2__referencing_entity> (synt);
for a given ENTITY, the number of relations referencing it must be smaller than or equal to the number of migrated PROPERTIES belonging to it
(synt).
The CENSUS OF RELATIONS is followed by the CENSUS OF MIGRATED
PROPERTIES at step 1 1 1. The syntactical format of the declarative sentence
CENSUS OF MIGRATED PROPERTIES, with multiple cardinality "y", is:
"The PROPERTY <3_l_property_name> of the ENTITY <3_2_entity_it_belongs_to> migrates [<3_3_migrated_primitive_flag> = 'M'] by means of the relation
<3_19_migration_relation> in the semantic role as <3_20_migration_role>"
The rules for writing the declarative sentence CENSUS OF MIGRATED
PROPERTIES are as follows:
<3_l_property_name> is the primary key (synt);
<3_2_entity_it_belongs_to> is an obligatory attribute, referenced by <2_contains> (synt);
<3_3_migrated_primitive_flag> is an obligatory attribute, which admits the values ['Ρ', 'Μ'] (synt);
<3_3_migrated_primitive_flag> determines whether the PROPERTY <3_l_property_name> is native of the ENTITY it belongs to <3_2_entity_it_belongs_to> (value 'P') or is migrated in the ENTITY it belongs to <3_2_entity_it_belongs_to> by a relation (value 'M') (sem);
<3_19_migration_relation> is an obligatory attribute, referenced by <5_transports> (synt);
<3_20_migration_role> is an obligatory attribute (synt);
<3_20_migration_role> must be a vocabulary definition of the semantic role acquired in the ENTITY to which the property belongs <3_2_entity_it_belongs_to> (referenced ENTITY) by the ELEMENT of the ENTITY from which it migrates (referencing ENTITY), by means of the migration relation <3_19_migration_relation>; for example, a subject's "province of residence", whose exclusive identity as province of the referencing ENTITY "PROVINCE" acquires the semantic role as "residence" of the subject to whom it has been attributed in the referenced ENTITY "SUBJECTS") (sem);
given an ENTITY <3_2_entIity_it_belongs_to>, at least one PROPERTY <3_l_property_name>, whether primitive or migrated, must exist which, through <8_belongs_to>, belongs to the primary key ("PK") (synt); the PROPERTY <3_l_property_name> must be updatable, through <13_is_updated_by>, by at least one EVENT (synt);
given a migration relation <3_19_migration_relation>, there must be a number of migrated PROPERTIES <3_l_property_name> which is equal to the number of primary-key ("PK") PROPERTIES of the referencing ENTITY (synt);
if the migration relation <3_19_migration_relation> is an identifying one, all the PROPERTIES <3_l_property_name> which are migrated by means of that relation must belong to the primary key ("PK") of the respective ENTITY <3_2_entity_it_belongs_to> (synt);
if the migration relation <3_19_migrationjrelation> is an elementary one, none of the PROPERTIES <3_l_property_name> which are migrated by means of that relation must belong to the primary key ("PK") and/or to any alternate key ("AK") of the respective ENTITY <3_2_entity_it_belongs_to> (synt);
if the migration relation <3_19_migration_relation> is a discriminating on, the primary key ("PK") of the respective ENTITY <3_2_entity_it_belongs_to> must only consist of all the PROPERTIES migrated by means of that relation (synt);
all those PROPERTIES <3_l_property_name> which belong neither to the primary key ("PK") nor to any alternate key ("AK") must comply with the "Third Normal Form" ("3NF") (sem).
If there is at least one discrimination relation among the assessed ones, then step 1 13, CENSUS OF DISCRIMINANT VALUES, is carried out. The syntactical format of the declarative sentence CENSUS OF DISCRIMINANT VALUES, with multiple cardinality "o", is:
"The value <8_3_discriminant_value> of the closed-domain comparable primitive PROPERTY <8_2_discriminant_property> is a discriminant value of the discrimination relation <8_l_discrimination_relation>"
The rules for writing the declarative sentence CENSUS OF DISCRIMINANT VALUES are as follows:
<8_l_discrimination_relation> belongs to the primary key, and is referenced by <10_is_discriminated_by> (synt);
<8_l_discrimination_relation> determines the discrimination relation corresponding to the specific discriminant 2-ples [<8_2_discriminant _property> + <8_3_discriminant_value>] (sem);
<8_2_discriminant_property> belongs to the primary key, and is referenced by <1 l_discriminates> (synt);
<8_3_discriminant_value> belongs to the primary key, and is referenced by <1 l_discriminates> (synt);
the discriminant PROPERTY <8_2_discriminant_property> must be a closed-domain primitive property with discrimination role (synt);
- the values <8_3_discriminant_value> determine, given a PROPERTY
<8_2_discriminant__property>, the discriminant values of the discrimination relation <8_l_discrimination_relation> (sem);
the ENTITY to which the discriminant PROPERTY <8_2_discriminant__property> belongs must coincide with the referencing ENTITY of the discrimination relation <8_l_discrimination_relation> (synt); the discrimination relation <8_l_discrimination_relation> must be of the discrimination type (synt).
Step 113 is followed by step 1 15, CENSUS OF KEYS. The syntactical format of the declarative sentence CENSUS OF KEYS, with multiple cardinality "s", is:
"<5_l_key_name> is
a primary key [<5_3_key_type> = 'PK'],
or
an alternate key [<5_3_key_type> = ΆΚ'],
or
a key with admissible null values and persistent non-null values [<5_3_key_type> = 'NK'],
or
a key with admissible null values and modifiable non-null values [<5_3_key_type> = 'ΜΚ'],
of the ENTITY <5_2_entity_it_belongs_to>".
The rules for writing the declarative sentence CENSUS OF KEYS are as follows:
<5_l_key_name> is the primary key (synt);
<5_2_entity_it_belongs_to> is an obligatory attribute, referenced by <6_is_identified_by> (synt);
<5_3_key_type> is an obligatory attribute that admits the values ['ΡΚ', 'ΑΚ', 'ΝΚ', 'ΜΚ'] (synt);
<5_3_key_type> determines whether the key is a primary key (value 'PK': the key has the requisites of full valorization at ELEMENT creation, persistence and univocity, and is used in an implementative manner for establishing the referential integrity constraint in the relations in which the ENTITY <5_2_entity_it_belongs_to> is referencing) or an alternate key (value 'ΑΚ': the key has the requisites of full valorization at ELEMENT creation, persistence and univocity), or a key with admissible null values and persistent non-null values (value 'NK': the key, if non-null, has the requisites of persistence and univocity), or a key with admissible null values and modifiable non-null values (value 'ΜΚ': the key, if non-null, has the requisite of univocity) (sem);
each key <5_l_key_name> must contain at least one PROPERTY
(synt);
all PROPERTIES of the key <5_l_key_name> must belong to the ENTITY <5_2_entity_it_belongs_to> to which the key itself belongs (synt);
Given a respective ENTITY <5_2_entity_it_belongs_to>, all keys <5_l_key_name>, regardless of their type <5_3_key_type>, must be distinct from one another (synt);
for all migrated PROPERTIES of the key <5_l_key_name>, the ENTITY referenced by the migration relation must coincide with the ENTITY <5_2_entity_it_belongs_to> to which the key belongs (synt).
Step 115 is followed by step 117, CONNECTION OF KEY PROPERTIES.
The syntactical format of the declarative sentence CONNECTION OF KEY PROPERTIES, with multiple cardinality "t", is:
"The PROPERTY <6_2_key_property> belongs to the key <6_l_key_it_belongs_to>".
The rules for writing the declarative sentence CONNECTION OF KEY PROPERTIES are as follows:
<6 1_key_it_belongs_to> belongs to the primary key, and is referenced by <7_contains> (synt);
<6_2_key_property> belongs to the primary key, and is referenced by <8_belongs_to> (synt);
each key <5_l_key_name> must contain at least one PROPERTY <6_2_key_property> (synt).
Step 117 is followed by step 119, CONNECTION OF UPDATED PROPERTIES.
The syntactical format of the declarative sentence CONNECTION OF UPDATED PROPERTIES, with multiple cardinality "m", is:
"The EVENT <10_l_update_event> valorizes the PROPERTY <10_2_updated_property> according to the measurement protocol <10_4_valorization_protocol>; the value thus measured is notified at the point <10_3_conversational_order_index> (i.e. the i-th point of the EVENT conversation), labelled as in conversation by <10_5_exposition_label>".
The rules for writing the declarative sentence CONNECTION OF UPDATED PROPERTIES are as follows:
- <10_l_update_event> belongs to the primary key, and is referenced by
<12_updates> (synt);
<10_2_updated_property> belongs to the primary key, and is referenced by <13_is_updated_by> (synt);
<10_3_conversational_order_index> is an obligatory attribute (synt); - <10_3_conversational_order_index> is a progressive integer number that determines the position occupied by the updated PROPERTY <10_2_updated_property> in the conversational succession of notification of the instances of the EVENT <10_l_update_event> (sem);
<10_4_valorization_protocol> must be a vocabulary definition of the organizational/operational measurement protocol used for measuring the values of the updated PROPERTY <10_2_updated_property> (the same PROPERTY may, in fact, be updated by different update EVENTS <10_l_updated_event>, with different measurement protocols) (sem); <10_5 exposition_label> is an obligatory attribute (synt); <10_5_exposition_label> is a label exposed to the benefit of the user, which semantically identifies the PROPERTY under update < 10_2_updated_property> (sem) ;
- all the PROPERTIES <10_2_updated_property> updated by the
EVENT <10_l_update_event> must belong to the ENTITY affected by the same EVENT (synt);
if the EVENT <10_l_update_event> is a creation event, it must update all the PROPERTIES <10_2_updated_property> belonging to the primary key ("PK") and/or to the alternate keys ("AK") of the ENTITY affected by the same EVENT < 10_ 1 _update_event> (synt) ;
if the EVENT <10_l_update_event> is an update event, it may not update any PROPERTY <10_2_updated__property> belonging to the primary key ("PK") and/or to the alternate keys ("AK") of the ENTITY affected by the same EVENT (synt).
The DYNAMIC sub-step consists of identifying CASCADES constituting the modes for notifying to the "persistent layer" the EVENTS belonging to the PERCEPTION FIELD of an OLTP-App, and of valorizing the attributes and the relations that connote them. Such identification and qualification of CASCADES fully and univocally defines the "conversational layer" and the "logic layer" of the OLTP-App.
The "conversational layer" is meant to be the set of program exposition components of an OLTP-App, aimed at governing the interactive conversations between a user and a software system (e.g. the programs of a graphic interface).
A CASCADE is meant to be a non-empty finite tree, the nodes of which are occupied by EVENTS. It can be considered to correspond, for example, to a 0/l/∞-weighted conditioned Petri net, fully executable in synchronous mode, and hence implementable in computer science through a single transaction made on a "persistent layer".
With reference to the anthropological configuration step, the following section will deal with the DYNAMIC sub-step (also called "conversational layer", or man- machine conversation).
The specification declarations relating to the (anthropological configuration) DYNAMIC sub-step proceed through the flow represented by two connected graphs of man-machine conversation, i.e. the graphs shown in Figures 5a and 5b. In particular, Figs. 3b, 3c and 3d show, for example, the folio wing, tables referring to the DYNAMIC step:
9_CASCADES;
1 l CASCADE B RANCHES;
19_PROFILES;
20 SELECTABLE PROPERTIES;
21 DISPL AYED PROPERTIES ;
15_C AS C ADE C YCLE S ;
16_UPDATE_RULES;
17_UPDATES_FOR_PERSISTENCE;
18_UPDATE_CONSTRAINTS_rN_NON_PRiME_CYCLES.
The association between each admissible declarative sentence (hence mapped in one of the two graphs shown in Figures 5a and 5b) and the table correspondingly filled in is expressed, for example, in Fig. 6.
Again with reference to Figs. 5a and 5b, every graph execution cycle starts at step 121 with the CENSUS OF CASCADE. The syntactical format of the declarative sentence CENSUS OF CASCADE, with single cardinality "1", is:
"The CASCADE <9_l_cascade_name>, aimed at notifying the <9_2_cascade_definition> is available for man-machine conversation".
The rules for writing the declarative sentence CENSUS OF CASCADE are as follows:
<9_l_cascade_name> is the primary key (synt);
<9_2_cascade_definition> is an obligatory attribute (synt);
<9 2_cascade_definition> must be a vocabulary definition of a generic notification to the "persistent_layer" of the group of EVENTS constituting the CASCADE, made by the user in observance of the succession and control logic that qualify the CASCADE itself (sem).
At least one EVENT must recur in any CASCADE <9_l_cascade_name> (synt).
Step 121 is followed by step 123, CONNECTION OF EVENTS. The syntactical format of the declarative sentence CONNECTION OF EVENTS, with multiple cardinality "n", is:
"In the CASCADE <1 l_l_branch_cascade>, the place univocally localized by <1 l_2_node_localization> is occupied by the EVENT <1 l_3_node_event>". The rules for writing the declarative sentence CONNECTION OF EVENTS are as follows:
<1 l_l_branch_cascade> belongs to the primary key, and is referenced by <14_is_mapped_by> (synt);
- <1 l_2_node_localization> belongs to the primary key (synt);
<1 l_2_node_localization> must be a label of the node occupied by the EVENT <l l_3_node_event> in the tree that represents the CASCADE <1 l_l_branch_cascade> (sem);
<1 l_3_node_event> is an obligatory attribute, and is referenced by <15_is_node_of> (synt);
one and only one root node must recur in each CASCADE (there must be one and only one level- 1 node). In other terms, the CASCADE entry EVENT must be uni vocal (synt);
An EVENT may not recur more than once in a CASCADE BRANCH, but may recur multiple times in the same CASCADE, in different CASCADE
BRANCHES (synt). A CASCADE BRANCH is a succession of (n+1) CASCADE nodes to which a node belongs for each height i from 0 (root node) to n, such that, for each i from 0 to (n-1), the node of height i is topologically connected to the node of height (i+1), and the node of height n is the terminal node (i.e. it is not topologically connected to any node of higher height) (synt);
Given an OLTP-App, the census of CASCADES can be considered to be complete if and only if each EVENT recurs in at least one CASCADE (synt).
When in the CASCADE under declaration at least one update EVENT recurs which requires manual selection of the ELEMENT to be updated, and/or when at least one EVENT recurs which requires manual valorization of at least one migrated PROPERTY, it will be necessary to verify, for the ENTITIES affected by the manually selected update EVENTS, and/or for the ENTITIES referencing the manually valorized migrated PROPERTIES, if all the search and selection profiles requested by the user are already available. If profiles which are not yet available (because they have never been assessed in any one of the already declared CASCADES) are requested, it will be necessary to assess them by means of the declarative sentence CENSUS OF PROFILE at step 125 of Fig. 5b, with single cardinality "1", the syntactical format of which is, for example, as follows:
"For the ENTITY <19_3_profiled_entity>, the search and selection profile <19_l_profile_name> is available, consisting of <19_2_profile_description>".
The rules for writing the declarative sentence CENSUS OF PROFILE are as follows:
- <19_l_profile_name> is the primary key (synt);
<19_2jprofile_description> is an obligatory attribute (synt);
<19_2_profile_description> must be a vocabulary definition of the strategy for selecting and retrieving ELEMENTS of the ENTITY <19_3_profiled entity> that connotes the profile <19_l_profile_name> (sem); - <19_3_profiled_entity> is an obligatory attribute, referenced by
<34_is_profiled_by> (synt);
The profile <19_l_profile_name> must reference, through <35_allows_selection_for>, at least one "selectable" PROPERTY, i.e. a PROPERTY on which the user can define selection value filters (synt);
- The profile <19_l_profile_name> must reference, through
<38_displays>, at least one "displayed" PROPERTY, i.e. a PROPERTY whose value state, as concerns all the ELEMENTS that comply with the defined selection value filters, is exposed during the conversation (synt);
Each ENTITY which is affected by at least one update EVENT and/or which references at least one relation must recur as a <19_3_profiled_entity> in at least one profile <19_ljprofile_name> (synt).
If all the relational paths for reaching the selection PROPERTIES already exist, then step 125 is followed by step 127, CONNECTION OF SELECTABLE PROPERTIES. The syntactical format of the declarative sentence CONNECTION OF SELECTABLE PROPERTIES, with multiple cardinality "d", is:
"The PROPERTY <20_2_selection_property>, exposed under the label <20_4_explanatory_selection_message>, and semantically connected to the ENTITY <19_3_profiled_entity> profiled by <20_l_selectable_profile> by means of the relational path <20_3_selection_relational_path>, can be used as a filter for selecting the profile <20_l_selectablej)rofile>"
The rules for writing the declarative sentence CONNECTION OF SELECTABLE PROPERTIES are as follows:
<20_l_selectable_profile> belongs to the primary key, and is referenced by <35_allows_selection_for> (synt);
<20_2_selection__property> belongs to the primary key, and is referenced by <36_is_selection_filter_in> (synt);
<20_2_selection_property> is a PROPERTY on which the user can ' define selection value filters (sem);
<20_3_selection_relational_path> belongs to the primary key, and is referenced by <37_defines_selection_navigation> (synt);
<20_3_selection_relational_path> is the logic sentence that connects the ENTITY to which the selection PROPERTY <20_2_selection_property> belongs in a relational way to the profiled ENTITY <19_3_profiled_entity>. If the two ENTITIES coincide, and hence there is no relational connection, the conventional logic sentence for a null relational path will be used in order to comply with the constraint of non-nullity of the primary key (sem);
<20_4 explanatory_selection_message> is an obligatory attribute (synt);
<20_4_explanatory_selection_message> is a tagline exposed to the benefit of the user, which explains the semantics of the selection PROPERTY <20_2_selection_property> (sem).
If all the relational paths for reaching the display PROPERTIES already exist, then step 129, CONNECTION OF DISPLAYED PROPERTIES, is carried out.
The syntactical format of the declarative sentence CONNECTION OF DISPLAYED PROPERTIES, with multiple cardinality "p", is:
"The PROPERTY <21_2_display_property>, exposed under the label <21_4_display_label>, ancj semantically connected to the ENTITY <19_3_profiled entity> profiled by <21_l_displayable_profile> by means of the relational path <21_3_display_relational_path>, is exposed for display by the profile <2 l_l_displayable_profile>".
The rules for writing the declarative sentence CONNECTION OF DISPLAYED PROPERTIES are as follows:
- <21_l_displayable_profile> belongs to the primary key, and is referenced by <38_displays> (synt);
<21_2_display_property> belongs to the primary key, and is referenced by <39_is_displayed_in> (synt); <21_2_display_property> is a PROPERTY exposed to the user for display (sem);
<21_3_display_relational_pafh> belongs to the primary key, and is referenced by <40_defines_display_navigation> (synt);
- <21_3_display_relational_path> is the logic sentence that connects the
ENTITY to which the display PROPERTY <21 J2_display_property> belongs in a relational way to the profiled ENTITY <19_3_profiled_entity>. If the two ENTITIES coincide, and hence there is no relational connection, the conventional logic sentence for a null relational path will be used in order to comply with the constraint of non-nullity of the primary key (sem);
<21_4_display_label> is an obligatory attribute (synt); <21_4_display_label> is a label exposed to the benefit of the user, which identifies the display PROPERTY <21_2_display_property> (sem); Back to the graph of Fig. 5a, after step 123 it is verified if all the necessary search and selection profiles and all the entry/exit guards already exist. If these two conditions are verified, then step 131, ATTRIBUTION OF ENTRY/EXIT GUARDS, is carried out. The syntactical format of the declarative sentence ATTRIBUTION OF ENTRY/EXIT GUARDS, with multiple cardinality "q", is:
"The entry in the EVENT <1 l_3_node_event>, which recurs in the CASCADE <1 l_l_branch_cascade> at the node localized in <1 l_2_node_localization>, is only possible if the condition <1 l_4_entry_guard> is verified",
and/or
"The exit from the EVENT <1 l_3_node_event>, which recurs in the CASCADE <1 l_l_branch_cascade> at the node localized in <1 l_2_node_localization>, is only possible if the condition <1 l_5_exit_guard> is verified".
The rules for writing the declarative sentence ATTRIBUTION OF ENTRY/EXIT GUARDS are as follows:
the 2-ple [<l l_l_branch_cascade> + <1 l_2_node localization>] identifies one of the sentences previously expressed at the declarative point CONNECTION OF EVENTS (synt);
<1 l_4_entry_guard> is an optional attribute, and is referenced by <18_conditions_entry> (synt);
<1 l_4_ entry_guard> is the logic sentence to the truthfulness value of which the entry in the EVENT <1 l_3_node_event>, which recurs in the CASCADE <l l_l_branch_cascade> at the node localized in <1 l_2_node_localization>, is subordinated (sem);
in each CASCADE, the entry at the root node may not be subordinated to any logic sentence. Therefore, the maximum possible cardinality <qing > of entry guards is (<n>-l) (synt);
<1 l_5_exit_guard> is an optional attribute, and is referenced by < 19_conditions_exit>(synt) ;
<1 l_5_exit_guard> is the logic sentence to the truthfulness value of which the exit from the EVENT <U_3_node_event>, which recurs in the
CASCADE <1 l_l_branch_cascade> at the node localized in <1 l_2_node_localization>, is subordinated (sem);
the maximum possible cardinality <qusc > of exit guards is <n>, and therefore the maximum possible cardinality <q> = (<qing> + ^us^) of entry/exit guards is (2 * <n>- 1 ) (synt);
if the EVENT <1 l_3_node_event>, which recurs in the CASCADE <1 l_l_branch_cascade> at the node localized in <l l_2_node_localization>, requires both an entry guard <1 l_4_entry_guard> and an exit guard <1 l_5_exit guard>, these must be distinct (synt).
Subsequently, if there are any cycles in the CASCADE, step 133, CENSUS OF CYCLES is carried out. The syntactical format of the declarative sentence CENSUS OF CYCLES, with multiple cardinality "f , is:
"The CASCADE <15 1_cycle_cascade> admits a cycle of return to the node localized by <15_3_return_node>, launchable by the node <15_2_launch_node>"
The rules for writing the declarative sentence CENSUS OF CYCLES are as follows:
<15_l_cycle_cascade> belongs to the primary key, and is identically referenced by both <20_launches> and <21_closes> (synt);
<15_2_launch_node> belongs to the primary key, and is referenced by <20_launches> (synt);
- <15_3_return_node> belongs to the primary key, and is referenced by
<21_closes> (synt);
the level of the launch node <15_2_launch_node> must be higher than or equal to the level of the return node <15_3_return_node>. "Self-cycles" are therefore allowed, i.e. cycles for which <15_2_launch_node> = <15_3_return_node> (synt);
the return node <15_3_return_node> must belong to the same CASCADE BRANCH as the launch node <15_2Jaunch_node> (synt);
- given a CASCADE BRANCH M, comprising m nodes, the maximum number of admissible cycles <fM> for M is (m!-1) (synt).
If all the necessary launch guards already exist, then step 135, ATTRIBUTION OF LAUNCH GUARDS is carried out.
The syntactical format of the declarative sentence ATTRIBUTION OF LAUNCH GUARDS, with multiple cardinality "g", is:
"The entry in the return cycle to the node localized by <15_3_return_node> of the CASCADE <15_l_cycle_cascade>, launchable by the node <15_2_launch_node>, is only possible if the condition <15_4_launch_guard> is verified".
The rules for writing the declarative sentence ATTRIBUTION OF LAUNCH GUARDS are as follows:
the 3-ple [<15_l_cycle_cascade> + <15__2 1aunch node> + <15_3_return_node>] identifies one of the sentences previously expressed at the declarative point CENSUS OF CYCLES (synt);
<15_4_launch_guard> is an optional attribute, and is referenced by <22_conditions launch> (synt);
<1 l_4_launch_guard> is the logic sentence to the truthfulness value of which the entry in the cycle identified by the 3-ple [<15_l_cycle_cascade> + <15_2_launch_node> + <15_3_return_node>] is subordinated (sem);
the maximum possible cardinality <g> is equal to <f> (case wherein all the cycles of the CASCADE have conditioned entry) (synt);
if <15_2_launch_node> is an entry node for n cycles, and if the (n+1) guards for exit from the node and/or entry in the n cycles are not mutually exclusive, the user will choose a continuation path among those which, based on the value state formed when crossing the EVENT located in <15_2_launch_node>, verify their respective guards (sem).
Then, at step 137, the LIST OF PROPERTIES TO BE UPDATED is carried out. The syntactical format of the declarative sentence LIST OF PROPERTIES TO BE UPDATED, with multiple cardinality "m", is: 4 058968
32
"The value of the PROPERTY <16_4_property_under_update>, detected in the instances of the EVENT <16_3_event_under_conversation>, is notified in the CASCADE <16_l_branch_under_conversation> at the node localized by < 16_2_localization_under_conversation>" .
The declarative sentence LIST OF PROPERTIES TO BE UPDATED is not subject to any writing rule, since it can be completely deduced on the basis of the sentences expressed at the preceding declarative steps CONNECTION OF EVENTS and CONNECTION OF UPDATED PROPERTIES, in accordance with the following logic automatisms:
- <16_l_branch_under conversation> belongs to the primary key: it is the <9 1_ cascade_name> under declaration, referenced by [<23_is_in_conversation>→ <14_is_mapped_by>] (synt);
<16_2_localization_under_conversation> belongs to the primary key: these are the <1 l_2_node_localization> corresponding to <16_l_branch_under_conversation>, referenced by <23_is_in_conversation>
(synt);
<16__3_event_under_conversation> belongs to the primary key: these are the <l_l_event _name> referenced by [<24_is_being_updated> → <12_updates>], for <l_l_event _name> = <1 l_3_node_event> corresponding to the 2-ples [<16_l branch_under_conversation> +
<16_2_localization_under_conversation>] (synt);
<16j4_property_under_update> belongs to the primary key: these are the <3_l_property_name> referenced by [<24_is_being_updated> → <13_is_updated_by>], for <3_l_property_name> = <10_2_updated_property> corresponding to <10_l_update_event> - <1 l_3_node_event> (synt);
ii being the number of PROPERTIES updated by the i-th EVENT, and qt being the number of occurrences of the i-th EVENT in the CASCADE, the cardinality <m> will be,
Figure imgf000033_0001
(synt).
If all the necessary update rules already exist, step 139, ATTRIBUTION OF UPDATE RULES, is carried out.
The syntactical format of the declarative sentence ATTRIBUTION OF UPDATE RULES, with multiple cardinality "m", is:
"The valorization of the PROPERTY <16_4_property_under update>, detected in the instances of the EVENT <16_3_event_under_conversation> and notifiable in the CASCADE <16_l_branch_under_conversation> at the node localized by <16_2_localization_under_conversation>" is
always obligatory [<16_5_obligatory_valorization_guard> = ALWAYS],
or
always optional [<16_5_obligatory_valorization_guard> = NEVER],
or
obligatory under the condition <16_5_obligatory_valorization_guard>; the value detected is notified in automatic mode by means of the automatic valorization algorithm <16_8_automatic_valorization_algorithm> in the case wherein <16_6_automatic_valorization_guard>, or in persistent mode in the case wherein <16_7_persistent_valorization_guard>, and is finally notified in manual mode in the compound complementary logic case wherein
[^(< 16_6_automatic_valorization_guard>)A^(< 16_7_persistent__valorization_guard>) ] by proposing in conversation the default value <16_9_default_valorization _algorifhm>; the value notification occupies either the natural conversational place or the varied conversational place < 16_10_conversational_order_cascade_variation> .
The rules for writing the declarative sentence ATTRIBUTION OF UPDATE RULES are as follows:
The 4-ple [<16_l_branch_under_conversation> +
< 16_2_localization_under_conversation> +
< 16_3_event_under_conversation> + <16_4_property_under_update>] identifies one of the updates previously listed at the declarative point LIST OF PROPERTIES TO BE UPDATED (synt);
<16_5_obligatory_valorization_guard> is an obligatory attribute, and is referenced by <25_conditions_obligatoriness> (synt);
<16_5_obligatory_valorization_guard> is the logic sentence that determines the value condition under which valorization is obligatory (sem); - for all the PROPERTIES belonging to the primary key and/or to alternate keys of the respective ENTITY, whatever the EVENT and the CASCADE for/in which they recur, the following applies: <16_5_obligatory_valorization__guard> = 'ALWAYS' (synt); <16_6_automatic_valorizafion_guard> is an obligatory attribute, and is referenced by <26_conditions_automaticity> (synt);
<16_6_automatic_valorizafion_guard> is the logic sentence that determines the value condition under which valorization can be automated by means of an algorithm; when valorization can be automated in all/no value conditions, we will have: <16_6_automatic_valorization_guard> = 'ALWAYS/NEVER' (sem);
<16_7_persistent_valorization_guard> is an obligatory attribute, and is referenced by <27_conditions_persistence> (synt);
<16_7_persistent_valorization_guard> is the logic sentence that determines the value condition under which valorization can be automated by means of a persistence; when valorization is persistent in all/no value conditions, we will have: <16 7_persistent_valorization_guard> = 'ALWAYS/NEVER' (sem);
If <16_2_localization_under_conversation> = 1 (prime CASCADE EVENTS), the following must always be true <16_7_persistent_valorization_guard> = NEVER (synt);
assuming that 'aut' and 'per' designate the respective truthfulness fields of <16_6_automatic_valorization_guard> and
<16_7_j>ersistent_valorization_guard>, they must be mutually exclusive: {'aut'n'per'} = 0 (synt);
<16_8_automatic_valorization_algorithm> is an obligatory attribute, referenced by <28_calculates_value>, if
<16_6_automatic_valorization_guard> ≠ NEVER; otherwise, it is not valorized (synt);
<16_8_automatic valorization_algorithm> is the logic sentence, of the algorithm type, that provides valorization of <16_4_property_under_update> (sem);
<16_9_default_valorization_algorithm> is an optional attribute, referenced by <29_calculates_default>, in the case wherein {■-('aut^ '-('per')}≠ 0; otherwise, it is not valorized (synt);
<16_9_default_valorization_algorithm> is the logic sentence, of the algorithm type, that provides the default value to be proposed for <16_4_property_under_update> (sem);
<16_10_conversational_order_cascade_variation> is an optional attribute. It is a progressive integer number that determines the position occupied by the updated PROPERTY <16 4_property_under_update> in the conversational succession of notification of the instances of the EVENT
<16_3_event_under_conversation>, within the frame of the specific CASCADE <16_l_branch_under_conversation>, when said position is different from the natural (general) one defined by <10_3_conversational_order_index> (sem);
- given the i-th EVENT <16_3_event_under_conversation> of index i within the frame of the specific CASCADE <16_l_branch_under_conversation>, which requires the update of m, PROPERTIES <16_4_property_under_update>, the mt values <16_10_conversational_order_cascade_variation> will be either all null or all attributed (synt);
if the rrij values <16_10_conversational_order_cascade_variation> have all been attributed, they must constitute the first /«, natural numbers (synt). If there are any updates for persistence, then step 141 , ATTRIBUTION OF PERSISTENT VALUES, is carried out.
The syntactical format of the declarative sentence ATTRIBUTION OF PERSISTENT VALUES, with multiple cardinality "z", is:
"In the CASCADE <17_l_persistence_ branch> the PROPERTY <17_4j>ersistent_property>, detected in the instances of the EVENT <17_3_persistent_event> at the node localized in <17_2_persistent_node> takes the same value as the PROPERTY <17_7_persisted_property>, previously detected in the instances of the EVENT <17_6_persisted_event> at the node localized in
<17_5_persisted_node>".
The rules for writing the declarative sentence ATTRIBUTION OF PERSISTENT
VALUES are as follows:
- the 4-ple [<17_l_persistence_branch> + <17_2_persistent_node> +
<17_3_persistent_event> + <17_4_persistent_property>] is the primary key, referenced by <30_is_updated_for_persistence>. It identifies an update previously listed at the declarative point LIST OF PROPERTIES TO BE UPDATED, for which at the subsequent declarative point ATTRIBUTION OF UPDATE RULES <16_7_persistent_valorization_guard>≠ 'NEVER' was set (synt);
<17_5_persisted_node> is an obligatory attribute, referenced by [<31_ update_forjpersistence>→ <23_is_in_conversation>] (synt);
<17_5_persisted_node> is, within the frame of the CASCADE <17_l_persistence_branch>, the localization of the node from which the persistent value is taken ( sem);
<17_6_persisted_event> is an obligatory attribute, referenced by [<31_update_for_persistence> → <24_is_being_updated> → <12_updates>] (synt);
<17_6_persisted_event> is, within the frame of the CASCADE <17_l_persistence_branch>, the EVENT from which the persistent value is taken (sem);
<17_7_persisted_property> is an obligatory attribute, referenced by [<31_updates_for_persistence> → <24 is_being_updated> → <13_is_updated_by>] (synt);
<17_7_persisted_property> is, within the frame of the CASCADE <17_l__persistence_branch>, the PROPERTY that provides the persistent value (sem);
the PROPERTY <17_4_persistent_property> valorized for persistence must turn out, in the declarative path of the CASCADE <17_l_persistence_branch>, to be subsequent to the PROPERTY <17_7_persisted_property> that provides the persistence value (synt);
mi being the number of PROPERTIES updated by the EVENT that occupies the root node of a CASCADE of n nodes, since in each EVENT not localized in the root node at least one PROPERTY that cannot be valorized for persistence must exist, the maximum possible cardinality <z> will be:
[m - mi -(n-l)J = m-mj-n+1 (synt).
Subsequently, if there are any cyclic valorization constraints, the CENSUS OF CYCLIC VALORIZATION CONSTRAINTS is carried out at step 143.
The syntactical format of the declarative sentence CENSUS OF CYCLIC VALORIZATION CONSTRAINTS, with multiple cardinality "a", is: "At the i-th non-prime execution of the return cycle identified by the 3-ple [<18_l_constrained_cycle> + <18_2_constrained_launch_node> + <18_3_constrained_return_ node>], the value of the PROPERTY <18_6_constrained_property> updated in the EVENT <18_5_constrained_event> localized at the node <18_4_constrained_node> must be equal to that taken at the first execution of the cycle [<18_7_exclusionjpersistence_flag> = 'P'],
or
must be different from all those taken at the previous (i-l) executions of the cycle
[<18_7_exclusion_persistence_flag> = Έ']".
The rules for writing the declarative sentence CENSUS OF CYCLIC VALORIZATION CONSTRAINTS are as follows:
the 3-ple [<18_l_constrained_cycle> +
<18 _2_constrained_launch_node> + <18_3_constrained_return_node>], referenced by <32_is_subject_to the_update_constraint>, belongs to the primary key. It identifies a return cycle previously assessed at the declarative point CENSUS OF CYCLES (synt);
<18_4_constrained_node> belongs to the primary key, and is referenced by [<33_is_limited_by>→ <23_is_in_conversation>] (synt);
<18_4_constrained_node> is, within the frame of the CASCADE <18_ l_constrained_cycle>, the localization of the node occupied by the update
EVENT of the PROPERTY whose valorization is subject to the cyclic constraint (sem);
<18_5_constrained_event> belongs to the primary key, and is referenced by [<33_is_limited_by> → <24_is_being_updated> → <12_updates>] (synt);
<18_5_constrained_event> is, within the frame of the CASCADE <18_l_constrained_cycle>, the update EVENT of the PROPERTY whose valorization is subject to the cyclic constraint (sem);
<18_6_constrained_property> belongs to the primary key, and is referenced by [<33_is_limited_by> → <24_is_being_updated> →
<13_is_updated_by>] (synt);
<18_6_constrained_property> is, within the frame of the CASCADE <18__l_constrained_cycle>, the PROPERTY whose valorization is subject to the cyclic constraint (sem);
<18_7_exclusion_persistence_flag> is an obligatory attribute that admits the values ['Ρ', Έ'] (synt);
<18_7_exclusionj?ersistence_fLag> determines whether the value of the PROPERTY <18_6_constrained_property> must be equal to that taken at the first execution of the cycle (value 'P') or must be different from all those taken at the previous (i-1 ) executions of the cycle (value 'Ε') (sem).
With reference to the anthropological configuration step, the following section will deal with the LOGIC sub-step (also called "logic layer", or logical predication).
The term "logic layer" refers to a set of access, computation and update components of the programs of an OLTP-App, aimed at ensuring that, through the effect of each execution of each program, the persistent state released by the execution will be different from the initial one and logically admissible (e.g. "commit"), or that, alternatively, the execution of the program will not produce any modifications of the initial persistent state (e.g. "rollback").
The "logic layer" specifies the "sentence-based" syntactical component of the REM SPECIFICATION relating to an OLTP-App. Unlike the other two layers, i.e. the "persistent" and "conversational" ones, which assess the specification components of the OLTP-App in "modelled" format (that is, they represent them by means of ELEMENTS of ENTITIES of a Relation Scheme), the "logic layer" needs a "sentence-based" language, which is used for specifying the non-relational integrity constraints affecting the "persistent layer" of the OLTP-App and the logic constraints that regulate the "conversational layer" of the same OLTP-App.
The "logic layer" may equivalently be specified in free linguistic format or by using a specific logic-formal language, e.g. the "Syriac" language.
The translatability of the REM SPECIFICATION into any source language by resorting to automatic transformations is subordinated to the use of a logic-formal language, such as, for example, "Syriac".
"Syriac" is a specific pseudo-quantified declination of the more general Logic of Predicates ("First-Order Logic"), finalized and optimized for logical predication applied to "persistent layers" and "conversational layers" of OLTP-Apps previously specified in the formal language of the REM SPECIFICATION.
"Syriac" meets the requirement of "Relational Completeness", and is therefore equivalent to SQL ("Structured Query Language"). It can therefore be used both in imperative mode (for update purposes) and in declarative mode (for control purposes). In particular, Fig. 3e shows, by way of example, the following tables, indicating at the centre the collection of the logic sentences that constitute the "logic layer":
13_LOGIC_SENTENCES;
12 ATOMIC FORMULAE;
14_LOGIC_SENTENCE_CO POSITION_MATRIX.
They constitute a relation sub-scheme that does not depend on any one of the other tables filled in by the specification of the "persistent layer" and/or of the "conversational layer".
Said relation sub-scheme is related to the rest of the REM SPECIFICATION by means of the semantic connections documented in the preceding section describing the
"conversational layer", consisting of, for example:
<37_defmes_selection_navigation>;
<40_defines_display_navigation>;
<18_conditions_entry>;
<19_conditions_exit>;
<22_conditions_launch> ;
<25_conditions_obligatoriness>;
<26_conditions_automaticity>;
<27_conditions_persistence>;
<28_calculates_value>;
<29_calculates_default>
The context of use of a logic sentence is transferred to the latter by the semantic connection that invokes it. The logic sentence is pre-existent to any invocation, and is therefore independent of the specific invocation contexts (in other terms, the text of the logic sentence is not affected by any "side-effects").
Hence, the "side-effects" of the logic sentence are completely injected into it by the semantic invocation connection; in particular, the semantic invocation connection univocally defines the instancing field (field of assignment of the free variables of the logic sentence, on which the logic sentence makes the truthfulness computation) and the type of use of the logic sentence (constraint, or condition, or algorithm, or selection). The free variables of the logic sentence are assigned the current value state at the instant of its invocation, in the course of the transactional conversation.
Since at any moment (crossing state) of the conversation one and only one ELEMENT of one and only one ENTITY (the ENTITY affected by the EVENT occupying the CASCADE node being crossed) is under update, the free variables take valorization from the ELEMENT under update and/or from the ELEMENTS updated during a previous crossing (EVENTS localized at the nodes already crossed of the CASCADE BRANCH); in the case of multiple crossing due to the effect of return cycles, the free variables take valorization from the ELEMENTS updated in the last return cycle crossed.
The specification declarations relating to the LOGIC sub-step of anthropological configuration must proceed through the flow represented by the graph of the logical predication process flow shown in Fig. 7.
With reference to Fig. 8, there is shown an exemplary table representing the association between each admissible declarative sentence (mapped in the logical predication graph of Fig. 7) and the table correspondingly filled in.
Every execution cycle of the logical predication graph starts at step 145, CENSUS OF
LOGIC SENTENCE. The syntactical format of the declarative sentence CENSUS OF
LOGIC SENTENCE, with single cardinality "1", is:
"The logic sentence stating the following in free linguistic format is available for invocation: <13_l_logic_sentence_natural_text>, the syriac formal expression of which is <13_2_logic_sentence_syriac_predicate>".
(Said sentence is of the 'V type, i.e. it constitutes a permanent universal constraint on the state of the data, i.e.
[<13_3_constraint_logic_role_flag> = 'S' and
<13_4_condition_logic_role_flag> = 'S' and
<13_5_algorithm_logic_role_flag> = 'N' and
<13_6_selection_logic_role_flag> = 'N'].
and/or said sentence is of the 'C type, i.e. it can be used as a conversation control condition, i.e.
[<13_3_constraint_logic_role_flag> = 'N' and
<13_4_condition_logic_role_fIag> = 'S' and
<13_5_algorithm_logic_role flag> = 'N' and <13_6_selection_logic_role_flag> = 'Ν'],
or
said sentence is of the 'A' type, i.e. it can be used for making automatic valorizations, i.e.
[<13_3_constraint_logic_role_flag> = 'N' and
<13 4_condition logic_role_flag> = 'N' and
<13_5_algorithm_logic_role_flag> = 'S' and
<13_6_selection_logic_role_flag> = 'N'],
or
said sentence is of the 'S' type, i.e. it can be used for defining assignment fields
[<13_3_constraint_logic_role_flag> = 'N' and
<13_4_condition_logic_role_flag> = 'N' and
<13_5_algorithm_logic_role_flag> = 'N' and
<13_6_selection_logic_role_flag> = 'S'].)
The matrix of admissibility of the logic sentence types as a function of the types of semantic invocation connections is expressed in Fig. 9.
The rules for writing the declarative sentence CENSUS OF LOGIC SENTENCE are as follows:
<13_l_logic_sentence_predicate_synthesis> is the primary key (synt); - <13 1_Iogic_sentence_predicate_synthesis> is a synthetic expression, formulated in natural language, of the content and/or function of the logical predicate expressed by the sentence (sem);
<13_2_logic_sentence_natural_text> is an AK ("Alternate Key")
(synt);
- <13_2_logic_sentence_natural_text> must be a free formulation, formulated in natural language, of the logical predicate expressed by the sentence (sem);
<13_3_logic_sentence_syriac_predicate> is a key with admissible null values and persistent non-null values ("Nullable Key" or "NK") (synt); if the key is not null, it has requisites of persistence and univocity, but may remain at
NULL value when the record is created.
<13_3_logic_sentence_syriac_predicate> must be the logical predicate expressed by the sentence, formulated in Syriac or another logic-formal language (sem);
<13_4_constraint_logic_role_flag> is an obligatory attribute that admits the values ['S\ 'N'] (synt);
<13_4_constraint_logic_role_flag> takes the value 'S' when the logical predicate expressed by the sentence has a declarative nature and constitutes a permanent universal constraint on the state of the data; it takes the value 'N' in the other cases (sem);
<13_5_condition_logic_role_flag> is an obligatory attribute that admits the values ['S', ' '] (synt);
- <13_5_condition_logic_role_flag> takes the value 'S' when the logical predicate expressed by the sentence has a declarative nature and constitutes a permanent universal constraint on the state of the data or a conversation control condition; it takes the value 'N' in the other cases (sem);
<13_6_algorithm_logic_role_flag> is an obligatory attribute that admits the values ['S\ 'N'] (synt);
<13_6_algorithm_logic_role_flag> takes the value 'S' when the logical predicate expressed by the sentence has imperative mode and can be used for making automatic valorizations; it takes the value 'N' in the other cases (sem);
<13_7_selection_logic_role_flag> is an obligatory attribute that admits the values ['S\ 'N'] (synt);
<13_7_selection_logic_role_flag> takes the value 'S' when the logical predicate expressed by the sentence has imperative mode and can be used for defining assignment fields; it takes the value 'N' in the other cases (sem).
If all the atomic formulae invoked in the logic sentence have not been assessed yet, then step 147, CENSUS OF ATOMIC FORMULAE, is carried out. The syntactical format of the declarative sentence CENSUS OF ATOMIC FORMULAE, with multiple cardinality "β", is:
"The atomic formula stating the following in free linguistic format is available for recurrence in logic sentences: <12_2_atomic_formula_natural_text>, the syriac formal expression of which is <12_3_atomic_formula_syriac_predicate>.
Said formula is annotated with the following univocal symbol in the logic sentences where it recurs: <12_l_symbolic_identifier>.
If the sentence in which it recurs is used as a universal constraint (type 'V') and/or as a conversation control condition (type 'C'), and if in conversation it turns out to be falsified, it exposes the following conversational message:
< 12_4_error _message_natural_text>".
The rules for writing the declarative sentence CENSUS OF ATOMIC FORMULAE are as follows:
<12_l_symbolic_identifier> is the primary key (synt);
<12_l_symbolic_identifier> must be a uni vocal synthetic symbolic expression, which is used in the logic sentences where the atomic formula <12_2_atomic_formula_natural_text> recurs (sem);
- <12 2_atomic_formula_natural_text> is an AK ("Alternate Key")
(synt);
<12_2_atomic_formula_natural_text> must be a free formulation, formulated in natural language, of the comparison predicate expressed by the atomic formula (sem);
- <12_3_atomic formula syriac predicate> is a key with admissible null values and persistent non-null values ("Nullable Key" or "NK") (synt);
<12_3 atomic_formula_syriac_predicate> must be the expression in Syriac, or in another logic-formal language, of the atomic formula (sem);
<12_4_error_message_natural_text> is a key with admissible null values and persistent non-null values ("Nullable Key" or "NK") (synt);
<12_4_error_message_natural_text> is an obligatory attribute if the sentences <13_l_logic_sentence_natural_text> where it recurs are used as a universal constraint (type 'V') and/or as a conversation control condition (type 'C'); otherwise, it is not valorized (sem).
Conversely, if all the atomic formulae invoked in the logic sentence have already been assessed or step 147 has been performed, then step 149, CONNECTION OF ATOMIC FORMULAE, is carried out.
The syntactical format of the declarative sentence CONNECTION OF ATOMIC FORMULAE, with multiple cardinality "a", is:
"The atomic formula univocally identified by the symbol <14_l_invoked_atomic_formula> recurs in the logic sentence
< 14_2_invoking_lo gic_sentence>" .
The rules for writing the declarative sentence CONNECTION OF ATOMIC FORMULAE are as follows:
<14_l_invoked atomic_formula> belongs to the primary key, and is referenced by <16_recurs_in> (synt);
<14_2_invoking_logic_sentence> belongs to the primary key, and is referenced by <17_uses> (synt).
According to the method of the present invention, therefore, the declarative process flow (described above in detail with reference to the graphs of Figs. 2, 5a, 5b and 7) r allows to decompose and reduce the overall specification of any one OLTP-app into atomic information units, which can be represented in the form of tuples of values of tables of the relation scheme in Third Normal Form shown in Figs. 3a-3b-3c-3d-3e, or of any other relation scheme semantically equivalent thereto, provided that it is compliant with the Third Normal Form.
In particular, again with reference to Fig. 2, the process flow guides the declaration of the ONTOLOGICAL FOUNDATION component of the OLTP-app: said component exclusively sticks to the objective reality state of the PERCEPTION FIELD of the application, and is technologically implemented into the design of the database of the OLTP-App.
The process flows shown in Figs. Fig. 5a and 5b, instead, respectively guide the declaration of the Anthropological Configuration component: said component depends on the user's historical, economic, social, cultural, organizational, regulatory, operational or psychological environment, and is technologically implemented into the exposition and man-machine conversation (i.e. "programs") of an OLTP-App, which are used for governing the interactive conversation between the user and the application. The Anthropological Configuration stage is supported, depending on progressively emerging "logic requirements", by a centralized "repository" of the OLTP-app's logic, which is progressively fed according to the flow shown in Fig. 7; this repository is the set of the logic propositions that regulate the access, computation, control and update of the application's database: such a centralization of the logical predication, which is also decomposed and reduced into tuples of tables of a relation scheme in Third Normal Form, intrinsically and automatically ensures minimization of code rows (the same "logic sentence", even when used by multiple invocation contexts, is specified only once, with no duplication of equivalent code); this decomposition or reduction also ensures, where a logic-formal language such as, for example, Syriac is used for the logic sentences, the possibility of writing the OLTP- app's code in a fully automated manner.
Therefore, the method of the invention obviates both types of approximation which are implicit in code generators and automatic computer-aided engineering tools known in the art, because it eliminates the need for any "downstream" manual programming while still preserving and ensuring "upstream" universal expressivity at the highest detail level; for this reason, the method of the invention is absolutely novel in this field of application.
Industrial applicability of the method according to the invention consists of the possibility of creating automatic reading and writing devices, e.g. a "parser", comprising a software product that takes care of preliminarily interpreting a REM SPECIFICATION (reading and interpretation), verifying its syntax (correction and validation) and, if the syntactical verification is successful, definitively and automatically transforming it into equivalent source code (source code writing), one for each "technological stack" considered to be of interest, and then maintaining the evolution thereof consistent with the evolution of the respective reference technological levels.
The term "technological stack" (also called platform or architecture) refers to a complex of interconnected and cooperating apparatuses and hardware and/or firmware and/or middleware tools which, while operating in logistical and environmental conditions complying with their respective operating specifications, allow for operability and usability of software systems by human users and/or automatic computers.
The features of the present invention, as well as the advantages thereof, are apparent from the above description.
A first advantage of the method and device according to the invention is the definition of a syntactical format and a writing rule that allow to represent the specification of an OLTP-app in such a way that the number of code rows to be produced is intrinsically and automatically minimized, and that the whole code can be produced in a fully automatic manner without requiring any further manual integration. As aforesaid, the unavailability of a "code repository" prevents optimizing the reuse rate of the already written code, and the total quantity of code (defined by convention as "number of code rows") is not intrinsically minimized. The method according to the present invention gets round this inefficiency by intrinsically ensuring minimization of the number of code rows. The reduction of the specification to a collection of atomic logic modules mapped in columns of tables of a relation scheme directly leads to the fact that the application's source code can be produced in a fully automatic manner by an automatic reading and writing device, which is appropriately programmed for acquiring the input relation scheme through syntactical reading means (reading and interpretation), verifying its syntactical correctness and completeness through a logic analyzer (correction and validation), and writing the source code through a source code generator (source code writing).
A second advantage of the method and device according to the invention is the automation of chronological and geographical version control (also referred to as "versioning").
As already mentioned in the section describing the prior art, the notion of "variation" (i.e. occurrence of a "new version") is aleatory and discretionary. The present invention obviates such aleatoriness by providing a formal, metrical and universal definition of a "variation measurement unit" and by establishing a preset "variation threshold" that determines the division between "changed version" and "unchanged version". Because such criterion has a formal, metrical and universal nature (non- discretionary), the management of chronological and geographical "versioning" can be totally automated without requiring "human discretion".
A third advantage of the method and device according to the invention is that the computation of the code function points (also referred to as "Unadjusted function points") is totally and accurately automated prior to the production of the source code. The present invention radically obviates the weak points of the function-point (FP) metrics. First of all, since the application specification refers to a relation scheme, the computation of the FPs consists merely of counting the number of "records" contained in some tables of the scheme. This computation can be completely automated, because it can be expressed, for example, in standard SQL syntax. Secondly, the computation can be made before the software coding stage begins, and is independent of it because it is exclusively founded on the specification. Finally, since the application's logic modules (data manipulation algorithms) are mapped in the relation scheme as logical- mathematical combinations of elementary propositions, all having unitary logic weight (called "atomic formulae"), also the "complexity computation" of each logic module is limited to counting the number of atomic formulae and the number of logical- mathematical combination operators invoked in the logic module: of course, also this computation can be totally automated.
A further advantage of the method and device according to the invention is the achievement of automatic availability and extractability of the functional testing plan. The method according to the present invention allows for automatic extraction of the testing plan by connecting the specification to a relation scheme, which also models the logic component by atomizing it into atomic formulae. Also the census of all possible logic branches is referable to the combinatorial computation of all possible relational navigations in the current state of the relation scheme.
A further advantage of the method and device according to the invention is that the contextual (mouse-sensitive) user documentation is automatically available to the users, already incorporated into the application itself. The so-called "semantic" columns of the relation scheme are specifically dedicated to this purpose, and they do not affect the syntactical validation of the specification.
The method and device for defining and creating specifications of software systems, in particular of the OLTP-App type, may be subject to many possible variations without departing from the novelty spirit of the inventive idea; it is also clear that in the practical implementation of the invention the illustrated details may have different shapes or be replaced with other technically equivalent elements.
For example, the division of the declarative flow into three layers, i.e. STATIC, DYNAMIC and LOGIC, is merely conventional and is solely used for adhering to the widespread convention according to which an application consists of a persistent layer ("DB"), a logic layer ("logic") and a conversational layer ("interface"), but it does not follow any structural segmentation, on account of the fact that the relation scheme is unique, homogeneous and totally connected.
Furthermore, the above-listed advantages will also be obtained by using any relation scheme in Third Normal Form being semantically equivalent to the one exemplified herein, even though it will introduce modifications and/or variations into the syntactical format and writing rules of the corresponding declarative sentences. Merely by way of example, let us assume, for example, that the column <1 l_4_entry_guard> is removed from the table 1 l CASCADE BRANCHES and a new table XX PROFILE REDUCTIONS is introduced, wherein, under a primary key composed of [(19_PROFILES) x (10JJPDATED PROPERTIES) x (11 CASCADE BRANCHES)], the census of the logic sentence that reduces the selection field of the invoked profile is carried out as a function of the valorization context created in the CASCADE EVENTS that precede the invoked one. Such a variant is semantically equivalent, because the logic function of an entry guard of an update EVENT and/or an EVENT that requires manual valorization of at least one migrated PROPERTY is to reduce the selection made by the invoked profile to values which are logically compatible with the previous valorizations in the course of the CASCADE. For example, if the cadastral surveys of the real estate units owned by a person subject to the Italian law are being updated to the EVENT 2, previously selected at the EVENT 1, the selection profile of the real estate units to be updated will have to exclude all those outside the national territory, whereas the invoked profile, being of decontextualized nature, would extract them all.
It can therefore be easily understood that the present invention is not limited to a method and a device for defining and creating specifications of software systems, in particular of the OLTP-App type, but may be subject to many modifications, improvements or replacements of equivalent parts and elements without departing from the inventive idea, as clearly specified in the following claims.

Claims

1. A method for creating specifications of software systems, in particular of the oltp- app, or "On-Line Transaction Processing-application", type, said method comprising a static step, a dynamic step and a logic step adapted to build a relation scheme through an automatic reading and writing device (200), and wherein said static step, said dynamic step and said logic step use declarative sentences having a syntactical format and a writing rule based on an ontological foundation theorem and on an ontological reduction rule.
2. A method according to claim 1 , wherein said ontological foundation theorem is only valid if there is at least one creation event, belonging to a perception field of an application, the occurrences of which can be represented through the creation of one and only one tuple of a relation representing it, in particular the insertion of one and only one record in a table, and if said relation, i.e. said table, complies with the Third Normal Form.
3. A method according to claim 1, wherein said ontological reduction rule requires that any type of occurrence of said perception field not having the event requirement can be reduced to a succession of events only affecting ontologically founded entities, which in particular can be represented through a 1 -weighted conditional Petri net, also known as cascade.
4. A method according to claim 1, wherein said declarative sentences intervene in said static step through tables of a "persistent layer", in particular a database that is present in memory means (205) of said automatic reading and writing device (200).
5. A method according to one or more of the preceding claims, wherein said event of said event table is a specific type of occurrence of said perception field, defined by a set of properties that undergo valorization in accordance with predefined and stable measurement protocols, which can be represented through the Creation, or modification, of one and only one tuple in one and only one entity, said entity being affected by said event.
6. A method according to claim 5, wherein said property is a logic identification and/or qualification attribute of said entity.
7. An automatic reading and writing device (200), said device (200) comprising syntactical reading means (201) adapted to interpret a requisite, memory means (205) adapted to store data obtained by reading said requisite, a source code generator (207) adapted to generate a source code implementing said requisite, and a processor (203) adapted to control said elements (201,205,207), said device (200) being adapted to carry out the method according to one or more of claims 1 to 6.
8. An automatic reading and writing device (200) according to claim 7, wherein said requisite is a requisite written in a formal language of a software system of the oltp- app type, adapted to be syntactically recognized by said automatic reading and writing device (200).
9. An automatic reading and writing device (200) according to claim 7 or 8, wherein said memory means (205) comprise a "persistent layer", in particular a relational database.
10. A computer product which can be loaded into a memory (205) of said automatic reading and writing device (200), in particular an advanced parser, comprising portions of software code adapted to implement the method according to one or more of claims 1 to 6.
PCT/IB2014/058968 2013-02-18 2014-02-13 Method for creating specifications of software systems, in particular of the oltp-app type, and device thereof WO2014125430A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
ITTO2013A000133 2013-02-18
IT000133A ITTO20130133A1 (en) 2013-02-18 2013-02-18 METHOD FOR THE REALIZATION OF SPECIFICATIONS OF SOFTWARE SYSTEMS, IN PARTICULAR OF THE OLTP-APP TYPE, AND RELATIVE DEVICE

Publications (1)

Publication Number Publication Date
WO2014125430A1 true WO2014125430A1 (en) 2014-08-21

Family

ID=48446523

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2014/058968 WO2014125430A1 (en) 2013-02-18 2014-02-13 Method for creating specifications of software systems, in particular of the oltp-app type, and device thereof

Country Status (3)

Country Link
IT (1) ITTO20130133A1 (en)
TW (1) TW201439915A (en)
WO (1) WO2014125430A1 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110489178A (en) * 2019-07-12 2019-11-22 中国人民解放军63961部队 The reading/writing method and device of application state information, storage medium, terminal
CN111221264A (en) * 2019-12-31 2020-06-02 广州明珞汽车装备有限公司 Gripper self-defining method, system and device and storage medium

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI659317B (en) * 2018-03-12 2019-05-11 財團法人資訊工業策進會 Apparatus and method thereof for determining a control condition set of a production line
CN109241101B (en) * 2018-08-31 2020-06-30 阿里巴巴集团控股有限公司 Database query optimization method and device and computer equipment

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001048625A1 (en) * 1999-12-29 2001-07-05 Baker Hughes Incorporated Method of and system for designing an n-tier software architecture for use in generating software components
WO2001079993A2 (en) * 2000-04-16 2001-10-25 Kestrel Institute Method and apparatus for method and apparatus for self-adaptive code
US20050198618A1 (en) * 2004-03-03 2005-09-08 Groupe Azur Inc. Distributed software fabrication system and process for fabricating business applications
US20090320093A1 (en) * 2007-12-31 2009-12-24 Enterra Solutions, Llc Holistic xacml and obligation code automatically generated from ontologically defined rule set

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001048625A1 (en) * 1999-12-29 2001-07-05 Baker Hughes Incorporated Method of and system for designing an n-tier software architecture for use in generating software components
WO2001079993A2 (en) * 2000-04-16 2001-10-25 Kestrel Institute Method and apparatus for method and apparatus for self-adaptive code
US20050198618A1 (en) * 2004-03-03 2005-09-08 Groupe Azur Inc. Distributed software fabrication system and process for fabricating business applications
US20090320093A1 (en) * 2007-12-31 2009-12-24 Enterra Solutions, Llc Holistic xacml and obligation code automatically generated from ontologically defined rule set

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
AMBRIOLA V ET AL: "Towards innovative software engineering environments", JOURNAL OF SYSTEMS & SOFTWARE, ELSEVIER NORTH HOLLAND, NEW YORK, NY, US, vol. 14, no. 1, 1 January 1991 (1991-01-01), pages 17 - 29, XP026671803, ISSN: 0164-1212, [retrieved on 19910101], DOI: 10.1016/0164-1212(91)90085-K *
MARCA D A: "Specifying groupware requirements from direct experience", SOFTWARE SPECIFICATION AND DESIGN, 1991., PROCEEDINGS OF THE SIXTH INT ERNATIONAL WORKSHOP ON COMO, ITALY 25-26 OCT. 1991, LOS ALAMITOS, CA, USA,IEEE COMPUT. SOC, US, 25 October 1991 (1991-10-25), pages 224 - 232, XP010025647, ISBN: 978-0-8186-2320-2, DOI: 10.1109/IWSSD.1991.213056 *
POLO M ET AL: "Generating three-tier applications from relational databases: a formal and practical approach", INFORMATION AND SOFTWARE TECHNOLOGY, ELSEVIER, AMSTERDAM, NL, vol. 44, no. 15, 1 December 2002 (2002-12-01), pages 923 - 941, XP004390163, ISSN: 0950-5849, DOI: 10.1016/S0950-5849(02)00130-1 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110489178A (en) * 2019-07-12 2019-11-22 中国人民解放军63961部队 The reading/writing method and device of application state information, storage medium, terminal
CN111221264A (en) * 2019-12-31 2020-06-02 广州明珞汽车装备有限公司 Gripper self-defining method, system and device and storage medium
CN111221264B (en) * 2019-12-31 2023-08-04 广州明珞汽车装备有限公司 Grip customization method, system, device and storage medium

Also Published As

Publication number Publication date
TW201439915A (en) 2014-10-16
ITTO20130133A1 (en) 2014-08-19

Similar Documents

Publication Publication Date Title
Suciu et al. Probabilistic databases
Szárnyas et al. The Train Benchmark: cross-technology performance evaluation of continuous model queries
US9355145B2 (en) User defined function classification in analytical data processing systems
US8943059B2 (en) Systems and methods for merging source records in accordance with survivorship rules
US7822795B2 (en) Apparatus and methods for displaying and determining dependency relationships among subsystems in a computer software system
CN102339316B (en) Coding is constrained using the inquiry of the state machine based on type
US8856151B2 (en) Output field mapping of user defined functions in databases
CN106250382A (en) A kind of metadata management automotive engine system and implementation method
US9229984B2 (en) Parameter expressions for modeling user defined function execution in analytical data processing systems
WO2012102707A1 (en) Analytical data processing
JP6492008B2 (en) Cohort identification system
CN111914534A (en) Semantic mapping method and system for constructing knowledge graph
CN108766507B (en) CQL and standard information model openEHR-based clinical quality index calculation method
WO2014125430A1 (en) Method for creating specifications of software systems, in particular of the oltp-app type, and device thereof
Calvanese et al. A ‘historical case’of ontology-based data access
CN112445867A (en) Intelligent analysis method and system for data relationship
Caruccio et al. Visual data integration based on description logic reasoning
Wojszczyk et al. The process of verifying the implementation of design patterns—used data models
CN113221528B (en) Automatic generation and execution method of clinical data quality evaluation rule based on openEHR model
Farhan et al. Transforming conceptual model into logical model for temporal data warehouse security: a case study
WO2019010277A2 (en) Highly atomized segmented and interrogatable data systems (hasids)
Naeem et al. Generating OLAP queries from natural language specification
Guidoni et al. Preserving conceptual model semantics in the forward engineering of relational schemas
Jakob et al. View creation of meta models by using modified triple graph grammars
Kwakye A Practical Approach to Merging Multidimensional Data Models

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14714339

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 23.11.2015)

122 Ep: pct application non-entry in european phase

Ref document number: 14714339

Country of ref document: EP

Kind code of ref document: A1