COSTANTINE is a tool developed within the work-package WP1D.3 of the STEPS (phase 1) Project. A project funded by Regione Piemonte in the area of aerospace. The class diagram formalism of UML has been adopted to formally define the conceptual data model. UML has been chosen because it is de facto a standard for the design of data schemas, whose semantic is well-known and not ambiguous. UML, however, has some limitations. Its expressive power, in fact, it is not sufficient to represent all the aspects of the reality. In other words, there are constraints that cannot be modeled just in terms of classes and relations between classes. This weakness of UML may arise some critical problems when the purpose of organizing data into a DB is not just to store them efficiently, but also to reason about them and to check their consistency. That is, UML is a good solution when one is interested in storing data, but it is not sufficient when data must be verified. In fact, one the objective of the WP1D.3 is to support an engineer during the design process; ideally, whenever the designer makes a choice, that choice has to be validated in order to establish whether it conflicts with the choices the designer has already made, or with the decisions taken by other engineers. UNITO’s task has been to find a way to overcome the UML’s weaknesses and to develop a tool (indeed a proof of concepts) for validating decisions made by designers. The Constantine Validator module is in charge of assessing the correctness of data against a set of constraints; only when data are consistent with the constraints, they can be stored into the centralized DB. To accomplish its job, the Validator exploits the constraints provided on one side by the annotated UML schema (defined by a knowledge engineer), and on the other side by the designer. In section 5.5 we will specify the characteristics of these two types of users, the designer and the knowledge engineer, and in which way the constraints they define are different. The data to be validated are provided by the designer. If during the validation process no violation is detected, Constantine allows the store of the data into the DB; otherwise, Constantine provides the designer with a report containing all the violations that have been detected. The designer is therefore in charge of adjusting the data baseline according to the suggestions provided with the report.

CONSTANTINE: CONSTraints ANalysis and Toolkit IN Eclipse.

MICALIZIO, ROBERTO
2012

Abstract

COSTANTINE is a tool developed within the work-package WP1D.3 of the STEPS (phase 1) Project. A project funded by Regione Piemonte in the area of aerospace. The class diagram formalism of UML has been adopted to formally define the conceptual data model. UML has been chosen because it is de facto a standard for the design of data schemas, whose semantic is well-known and not ambiguous. UML, however, has some limitations. Its expressive power, in fact, it is not sufficient to represent all the aspects of the reality. In other words, there are constraints that cannot be modeled just in terms of classes and relations between classes. This weakness of UML may arise some critical problems when the purpose of organizing data into a DB is not just to store them efficiently, but also to reason about them and to check their consistency. That is, UML is a good solution when one is interested in storing data, but it is not sufficient when data must be verified. In fact, one the objective of the WP1D.3 is to support an engineer during the design process; ideally, whenever the designer makes a choice, that choice has to be validated in order to establish whether it conflicts with the choices the designer has already made, or with the decisions taken by other engineers. UNITO’s task has been to find a way to overcome the UML’s weaknesses and to develop a tool (indeed a proof of concepts) for validating decisions made by designers. The Constantine Validator module is in charge of assessing the correctness of data against a set of constraints; only when data are consistent with the constraints, they can be stored into the centralized DB. To accomplish its job, the Validator exploits the constraints provided on one side by the annotated UML schema (defined by a knowledge engineer), and on the other side by the designer. In section 5.5 we will specify the characteristics of these two types of users, the designer and the knowledge engineer, and in which way the constraints they define are different. The data to be validated are provided by the designer. If during the validation process no violation is detected, Constantine allows the store of the data into the DB; otherwise, Constantine provides the designer with a report containing all the violations that have been detected. The designer is therefore in charge of adjusting the data baseline according to the suggestions provided with the report.
1
Thales Alenia Space, Italia
http://www.di.unito.it/~micalizi/constantine.html
OCL; UML; Collaborative Design
Roberto Micalizio
File in questo prodotto:
File Dimensione Formato  
ANNEX 09 to D1 D-2 - UNITO - Micalizio - Report Third - FINAL.doc

Accesso aperto con embargo fino al 09/05/2015

Tipo di file: MATERIALE NON BIBLIOGRAFICO
Dimensione 1.74 MB
Formato Microsoft Word
1.74 MB Microsoft Word Visualizza/Apri

I documenti in IRIS sono protetti da copyright e tutti i diritti sono riservati, salvo diversa indicazione.

Utilizza questo identificativo per citare o creare un link a questo documento: http://hdl.handle.net/2318/127740
Citazioni
  • ???jsp.display-item.citation.pmc??? ND
  • Scopus ND
  • ???jsp.display-item.citation.isi??? ND
social impact