Part III Proper Conceptualisation
Definition 31: Abstract Type Syntax Definition
5.3.3 Axiomatic Semantics
Definition 35 – Axiomatic Semantics: By an axiomatic semantics we understand a pair of abstract type presentations of syntactic and semantic types and a set of axioms which express the meaning of some syntactic values in terms of semantic values.
s235
Example 32 – An Axiomatic Semantics: Banks: We continue Example 28. We now give an axiomatics semantics of the simple commands of Example 28. We start by recalling semantic and syntactic types and observer functions. First the semantic types:
type
63 BANK, C, A, Amount, M value
64 obs Cs: BANK→C-set 65 obs As: BANK→A-set 66 obs As: BANK×C→A-set
preobs As(bank,c): c∈obs Cs(bank) axiom
∀ bank:BANK•
67 ∀c:C •c∈obs Cs(bank)⇒obs As(bank,c)⊆obs As(bank) type
68 obs M: BANK×C×A→M
preobs M(bank,c,a): c∈obs Cs(bank)∧a∈obs As(bank,c) Then the syntactic types: s236
type
69 cmd:Command, Open, Deposit, Withdraw, Amount, Close value
70 is Open, is Deposit, is Withdraw, is Close: Command→Bool 71 obs C: Command→C
72 obs A: Command→∼ A
preobs A(cmd):∼is Open(cmd) 73 obs M: Command→∼ M
preobs M(cmd): is Deposit(cmd) 74 obs Amount: Command→∼ Amount
preobs Amount(cmd): is Withdraw(cmd) The semantic function signatures are: s237
value
open: Open→BANK→BANK×A
deposit: Deposit→BANK→BANK×(ok|nok)
withdraw: Withdraw→BANK→BANK×(mkM(m:M)|nok) close: Close→BANK→BANK×(mkM(m:M)|nok)
We shall illustrate an axiomatic semantics of just Open commands. s238
value m0:M axiom
∀ bank:Bank
∀op:Open•
letc=obs C(op),
(bank′,a)=open(op)(bank),
cs =obs Cs(bank), cs′=obs Cs(bank′),
acs=obs As(bank), acs′=obs As(bank′),
cacs=if c∈obs Cs(bank)thenobs As(bank,c)else{}end, cacs′=obs As(bank′,c)in
cs\{c}=cs′\{c} ∧ c∈cs′∧a6∈acs∧a6∈cacs′∧
acs′=acs∪{a} ∧cacs′ =cacs∪{a} ∧m0=obs M(bank′,c,a)∧
∀c′:C• c′∈cs\{c} ⇒ obs As(bank,c′)=obs As(bank′,c′)∧
∀ a:A•a ∈obs As(bank,c′)⇒ obs M(bank,c′,a)=obs M(bank′,c′,a) end
s239 The reader is encouraged to formulate the axiomatic semantics for the Deposit, Withdraw and Close
commands. This ends Example 32
5.4 Pragmatics
s240We recall our definition of pragmatics: pragmatics is the study of and knowledge about the use of words, sentences and structures of sentences, and of how contexts affect the meanings of words, sentences, etc.
Recall that we “extended” the notion of sentences and words to include building drawings, city plans, machine drawings, production floor machinery, radio circuit diagrams, railway track layouts, enterprise organisation charts, et cetera, We think of these two or three dimensional artefacts as designating systems.
s241
Rather than dwelling on how, for example bank clients may use the client/banking language of command, we shall, in our example we therefore emphasise
• mostly the pragmatics of bothwhatandhow
⋆ we choose to domain model (describe) and
⋆ requirements prescribe and
• to some extent also the pragmatics ofwhythese systems are endowed with certain structurings.
We shall emphasise“the use of words, sentences and structures of sentences,” and not say much about“how contexts affect the meanings of words, sentences, etc.”
s242
Example 33 –Pragmatics: Banks: The pragmatics ofwhatwe describe of banks is determined by the pedagogics of giving as simple, yet as “convincing” examples of syntactic and semantic types and both denotational (albeit a rather “simplistic example of that) without embellishing the example with too many kinds of banking services (for example, intra-bank account transfers, mortgages, statement requests, etc.).
s243
The pragmatics of how we describe banks is determined by the didactics of covering both con-crete type syntaxes and abstract type syntaxes of syntactic types, and covering both denotational and behavioural semantics definitions.
s244
The pragmatics of whywe describe banks is determined by our wish to convince the reader that it is not a difficult software engineering task to give easy and realistic domain descriptions of important, seemingly “large” infrastructure components (such as banks).
s245
The pragmatics related to“how contexts affect the meanings” includes that we do not, in Exam-ples 26, 28, 29, and 30–31, describe other financial institutions such as portfolio (wealth and investment) management, insurance companies, credit card companies, brokers, trader, commodity and stock ex-changes, let alone include the modelling of several banks. These other institutions and banks form one possible context of our model and hence our model limits the meaning of client/banking commands.
Another possible context is provided by the personal diligent or casual or delinquent or sloppy, etc., behaviour of client. The human behaviours are not modelled, but must eventually be modelled (cf.
Sect. 7.8’s Examples 68 on page 125 and 69 on page 125).
5.6 Exercises 53
s246
Pragmatics is not about empirical aspects of software engineering. The pragmatics that we refer to, in the above definition, is that of staff and users of banks. The pragmatics that we covered in the example is that of the pedagogics and didactics of presenting a methodology for software
engineering. s247
The aspects of software engineering that we cover, namely that of domain and requirements engineering, are not empirical sciences, or, more precisely the methodologies of domain and require-ments engineering are not based on studies of the behaviour of neither domain nor requirerequire-ments engineers. The aspects of software engineering that we put forward in this book are based on s248 computing science4 and computing science, like mathematics, upon which it is based, is not an
empirical science.5 s249
The pragmatics of the kind of domains in the context of the way in which we wish to describe these domains and prescribe requirements for computing systems to serve in these domains is far from studied.
We, but this is only a personal remark and not a scientific conjecture, venture to claim that perhaps one cannot formalise pragmatics, that is, that pragmatics is what cannot be formalised.
But this is just a “hunch” !
5.5 Discussion
s250We summarise this chapter on semiotics by first recalling our definition: Semiotics is the study of and knowledge about the structure of all ‘sign systems’. In accordance with some practice we have divided our presentation into three parts: syntax, semantics and pragmatics. s251
BNF grammars were first6 made known (in the late 1950s) in connection with the work on defining the first block structured programming language,Algol 60[9]. So BNF grammars were for defining the one-dimensional, i.e., textual layout of programming languages. In Sect. 5.1 we enlarge the scope of syntax to also embody the definition of the structure of ‘systems’ (that is, domains) such as mentioned there (Page 37). The “language” of systems is the possibly infinite set of utterings that staff and users, i.e., system stake holders express when working with (or in) the system. We exemplified this only briefly and in terms of client/banking commands. We make, s252 in this chapter and in this book, a distinction between using syntax definitions to define syntactic types versus using syntax definitions to define semantic types.
more to come
We encourage readers to embark on studies of the (albeit informal) pragmatics of domains.
5.6 Exercises
See Items 5–6 (of Appendix D, starting Page 230).
4Software engineering is applied computing science.
5Although some may reasonably claim that Mathematics is what Mathematicians do, that is not, in our opinion, the same as saying: let us therefore study how all those people who claim they are mathematicians are doing call what they mathematics and let the result of such an empirical study determine what mathematics is!
6 Dines: Find reference to Don Knuth’s “paper” on ancient Indian’s knowing of “BNF”.