Fix typos
ci/woodpecker/push/build Pipeline was successful
Details
ci/woodpecker/push/build Pipeline was successful
Details
This commit is contained in:
parent
763c0a515b
commit
4f5f4996af
|
@ -590,7 +590,7 @@ text*[claimNotion::myclaim, authored_by="{@{myauthor \<open>church\<close>}}"
|
||||||
One can now reference a class instance in a \<^theory_text>\<open>term*\<close> command.
|
One can now reference a class instance in a \<^theory_text>\<open>term*\<close> command.
|
||||||
In the command \<^theory_text>\<open>term*\<open>@{myauthor \<open>church\<close>}\<close>\<close>
|
In the command \<^theory_text>\<open>term*\<open>@{myauthor \<open>church\<close>}\<close>\<close>
|
||||||
the term \<^term>\<open>@{myauthor \<open>church\<close>}\<close> is type-checked, \<^ie>, the command \<^theory_text>\<open>term*\<close> checks that
|
the term \<^term>\<open>@{myauthor \<open>church\<close>}\<close> is type-checked, \<^ie>, the command \<^theory_text>\<open>term*\<close> checks that
|
||||||
\<^theory_text>\<open>church\<close> references a term of type \<^typ>\<open>myauthor\<close> against the global context.
|
\<^theory_text>\<open>church\<close> references a term of type \<^typ>\<open>myauthor\<close> against the global context
|
||||||
(see \<^side_by_side_figure>\<open>type-checking-example\<close>).
|
(see \<^side_by_side_figure>\<open>type-checking-example\<close>).
|
||||||
\<close>
|
\<close>
|
||||||
|
|
||||||
|
@ -908,8 +908,8 @@ onto_class Hardware = Informatic +
|
||||||
|
|
||||||
This ontology defines the \<^typ>\<open>Resource\<close>,
|
This ontology defines the \<^typ>\<open>Resource\<close>,
|
||||||
\<^typ>\<open>Electronic\<close>, \<^typ>\<open>Component\<close>, \<^typ>\<open>Informatic\<close> and \<^typ>\<open>Hardware\<close> concepts.
|
\<^typ>\<open>Electronic\<close>, \<^typ>\<open>Component\<close>, \<^typ>\<open>Informatic\<close> and \<^typ>\<open>Hardware\<close> concepts.
|
||||||
In our example, we focus on the \<^typ>\<open>Hardware\<close> class containing a \<^const>\<open>mass\<close> attribute
|
In our example, we focus on the \<^typ>\<open>Hardware\<close> class containing a \<^const>\<open>Component.mass\<close> attribute
|
||||||
and composed of a list of components with a \<^const>\<open>mass\<close> attribute formalising
|
and composed of a list of components with a \<^const>\<open>Component.mass\<close> attribute formalising
|
||||||
the mass value of each component.
|
the mass value of each component.
|
||||||
The \<^typ>\<open>Hardware\<close> class also contains a local \<^theory_text>\<open>invariant c1\<close>
|
The \<^typ>\<open>Hardware\<close> class also contains a local \<^theory_text>\<open>invariant c1\<close>
|
||||||
to define a constraint linking the global mass of a \<^typ>\<open>Hardware\<close> object
|
to define a constraint linking the global mass of a \<^typ>\<open>Hardware\<close> object
|
||||||
|
@ -922,7 +922,7 @@ To check the coherence of our local ontology, we define a relationship between t
|
||||||
and the reference ontology using morphism functions (or mapping rules as in ATL framework~@{cite "atl"}
|
and the reference ontology using morphism functions (or mapping rules as in ATL framework~@{cite "atl"}
|
||||||
or EXPRESS-X language~@{cite "BGPP95"}). These rules are applied to define the relationship
|
or EXPRESS-X language~@{cite "BGPP95"}). These rules are applied to define the relationship
|
||||||
between one class of the local ontology to one or several other class(es) described in the reference
|
between one class of the local ontology to one or several other class(es) described in the reference
|
||||||
ontology. In our case, we have define two morphises, \<^const>\<open>Product_to_Component_morphism\<close>
|
ontology. In our case, we have define two morphisms, \<^const>\<open>Product_to_Component_morphism\<close>
|
||||||
and \<^const>\<open>Computer_Hardware_to_Hardware_morphism\<close>, detailed in the following listing:
|
and \<^const>\<open>Computer_Hardware_to_Hardware_morphism\<close>, detailed in the following listing:
|
||||||
|
|
||||||
%\begin{figure}
|
%\begin{figure}
|
||||||
|
@ -983,7 +983,7 @@ lemma Computer_Hardware_to_Hardware_total :
|
||||||
After unfolding
|
After unfolding
|
||||||
the invariant and the morphism definitions, the preservation proof is automatic. The advantage
|
the invariant and the morphism definitions, the preservation proof is automatic. The advantage
|
||||||
of using the \<^dof> framework compared to approaches like ATL or EXPRESS-X is
|
of using the \<^dof> framework compared to approaches like ATL or EXPRESS-X is
|
||||||
the possibility of formally verifying the \<^emph>\<open>mapping rules\<close>. \<^ie> proving the preservation
|
the possibility of formally verifying the \<^emph>\<open>mapping rules\<close>, \<^ie>, proving the preservation
|
||||||
of invariants, as we have demonstrated in the previous example.
|
of invariants, as we have demonstrated in the previous example.
|
||||||
\<close>
|
\<close>
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue