From c9e2f22c8b4a8d28c9e1594f609c80b873d4aabb Mon Sep 17 00:00:00 2001 From: Burkhart Wolff Date: Wed, 13 Apr 2022 19:59:46 +0200 Subject: [PATCH] layout massage --- .../scholarly_paper/2021-ITP-PMTI/paper.thy | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/examples/scholarly_paper/2021-ITP-PMTI/paper.thy b/examples/scholarly_paper/2021-ITP-PMTI/paper.thy index e405dfb4..91801641 100644 --- a/examples/scholarly_paper/2021-ITP-PMTI/paper.thy +++ b/examples/scholarly_paper/2021-ITP-PMTI/paper.thy @@ -1189,14 +1189,14 @@ According to CENELEC Table C.1, for example, we specify the category of ``Design as follows: @{boxed_theory_text [display] \ doc_class cenelec_document = text_element + - phase :: phase + phase :: phase written_by :: role \ \Annex C Table C.1 \ - fst_check :: role \ \Annex C Table C.1 \ + fst_check :: role \ \Annex C Table C.1 \ snd_check :: role \ \Annex C Table C.1 \ ... invariant must_be_chapter :: "text_element.level \ = Some(0)" invariant two_eyes_prcple :: "written_by \ \ fst_check \ - \ written_by \ \ snd_check \" + \ written_by \ \ snd_check \" \} This class refers to the ``software phases'' the standard postulates (like \SPL\ for ``Software Planning'' or \SCDES\ for ``Software Component Design'') @@ -1205,7 +1205,7 @@ Similarly, the standard postulates ``roles'' that certain specified teams in the (like \VER\ for verification and \VAL\ for validation). We added invariants that specify certain constraints implicit in the standard: for example, a \cenelec_document\ must have the textual structure of a chapter (the \level\-attribute is inherited from an underlying -ontology library specifying text-elements) as well as the two-eyes-principle between authors and +ontology library specifying basic text-elements) as well as the two-eyes-principle between authors and checkers of this document. \ text\ The concrete instance of the \cenelec_document\ - class is the @@ -1214,8 +1214,8 @@ where the role assignment is done for this document type as follows: @{boxed_theory_text [display] \ doc_class SWIS = cenelec_document + \ \software interface specification\ phase :: "phase" <= "SCDES" written_by :: "role" <= "DES" - fst_check :: "role" <= "VER" snd_check :: "role" <= "VAL" - components :: "SWIS_E list" + fst_check :: "role" <= "VER" snd_check :: "role" <= "VAL" + components:: "SWIS_E list" \} The structural constraints expressed so far can in principle be covered by any conventional validation process and suitable editing support (\<^eg>, Protégé @{cite "protege"}). @@ -1223,10 +1223,10 @@ However, a closer look at the class \SWIS_E\ (``software interface element'') referenced in the \components\-attribute reveals the unique power of \<^dof>: @{boxed_theory_text [display] \ doc_class SWIS_E = - op_name :: "string" + op_name :: "string" op_args_res :: "(string \ typ) list \ typ" \ \args and result type\ - pre_cond :: "(string \ thm) list" \ \labels and predicates\ - post_cond :: "(string \ thm) list" \ \labels and predicates\ + pre_cond :: "(string \ thm) list" \ \labels and predicates\ + post_cond :: "(string \ thm) list" \ \labels and predicates\ invariant well_formed_pre :: "\cond \ set(map snd (pre_cond \)). iswff\<^sub>p\<^sub>r\<^sub>e (op_args_res \) (cond)" invariant well_formed_post:: ...