Domain Science &â Engineering A Foundation for Computation ... - DTU

Domain Science &∗ Engineering A Foundation for Computation for Humanity.† Dines Bjørner Fredsvej 11, DK-2840 Holte, Denmark [email protected], www.imm.dtu.dk/~db January 17, 2012: 09:13 Abstract Physicists abstract and model ”the world around us”. Domain scientists & engineers, it is suggested, abstract and model tangible aspects of systems where phenomena (other than humans) interact with humans, that is, systems which crucially depend on their human components. Examples of such systems are air traffic, banking, consumer commerce, container lines, health care, manufacturing, oil, gas and water pipelines, railway systems, web-based systems, or fragments thereof. We shall analyse one kind of formal science and science-based engineering, one that can tackle the (informal and formal) description of systems in which human actors play a significant rˆ ole: either (actively) by monitoring & controlling such systems or (passively) by being positively or adversely affected by good, respectively bad designs of IT systems that serve to handle one or another facet of such systems. We argue that ’Domain Science & Engineering’ is a relatively “new” science that transcends conventional computer and computing sciences. We shall also argue that the scientific and engineering pursuit of domain science & engineering should result in models of a number of domains described both informally and formally such that teaching material can be made readily available for the use in primary, secondary and tertiary schools whereby precise models of complex, man-made systems can be made easily accessible. So, just as children are taught (“laws of”) physics and become familiar with ‘mother nature’, that is, enable us to cope with the physical world around is, likewise children can be taught (“laws of”) of man-made domains preparing us, in our societal life for a better control of those domains. The paper contains an initial analysis of what we mean by ‘humanity’, and a final analysis of how domain science & engineering may contribute to “human computing”. ∗ We use the connection ‘&’ instead of the more conventional ‘and’. The reason can be explained as follows: ‘A and B’, to us, sugnals that two topics, A and B are covered. whereas ‘A & B’ signals that there is one topic named by the compposite ‘A & B’ † Invited paper for Computation for Humanity IT to Advance Society, a book in the Computational Analysis, Synthesis, and Design of Dynamic Systems series published by the CRC Press, Taylor & Francis Group, eds. Justyna Zander, Harvard and MIT, and Pieter Mosterman, MathWorks and McGill.

1

2

1

Introduction

This section will discuss what might be meant by ‘Computation for Humanity’, what we mean by a domain and a domain description, and how domain science & engineering otherwise fits into the narrower context of software engineering.

1.1

What Can We Mean by ‘Computation for Humanity’ ?

There does not seem to be a generally accepted characterisation of what might be meant by ‘Computation for Humanity’. We shall therefore examine reasonably broadly accepted characterisations of the term ‘humanity’, while focusing on those aspects that might be supported positively or negatively by computing, in particular on Peterson and Seligman’s Character strengths and virtues: A handbook and classification 1 and Maslow’s Theory of Human Motivation.2 1.1.1

Humanity

This section is edited from various Wikipedia pages: Reasonably Established Uses of ‘Humanity’ Humanity may refer to: the human species, the total world population, human nature, psychological characteristics that all normal humans have in common, compassion, empathy, altruism, aggression and fear; the human condition, the experiences of being human in a social, cultural, and personal context. the humanities, academic disciplines which study the human condition using analytic, critical, or speculative methods; humanity (virtue), one of six core virtues in the Character Strengths and Virtues Handbook: wisdom and knowledge (strengths that involve the acquisition and use of knowledge) creativity, curiosity, open-mindedness, love of learning, perspective and wisdom; courage: bravery, persistence, integrity and vitality; humanity: love, kindness and social intelligence; justice: active citizenship/social responsibility/loyalty/teamwork, fairness and leadership; temperance: forgiveness and mercy, humility and modesty, prudence and selfregulation and self control; transcendence: appreciation of beauty, appreciation of excellence gratitude, hope, humor and playfulness and spirituality. Maslow proposed a hierarchy of human needs; from the physiological, basic needs of breathing, food, water, sex, homeostasis, and excretion; via the safety and security needs of body, employment, resources, the family, health and property; and love/belong needs of friendship, family and sexual intimacy; and esteem needs of self-esteem, confidence, achievement, respect of others and respect by others; to self-actualisation needs of morality, creativity, spontaneity, problem solving, lack of prejudice and acceptance of facts. 1 Christopher Peterson and Martin E. P. Seligman, Character strengths and virtues: A handbook and classification. Oxford University Press, 2004 2 Abraham H. Maslow, A Theory of Human Motivation, Psychological Review 50(4) (1943):370-96 and Motivation and Personality, Third Edition, Harper and Row Publishers, 1954

c Dines Bjørner 2011. Fredsvej 11, DK–2840 Holte, Denmark

Domain Science & Engineering January 17, 2012: 09:13

3 Hijacked Uses of ‘Humanity’ The above enumerations are the result of ‘humanities’ studies. That is, of primarily analytical, critical, or speculative investigations. There are other speculative studies that purport to hinge on and represent issues of ‘humanity’. For example: human rights,3 humanity in action,4 humanism,5 etcetera, We somewhat controversially label these uses as being hijacked: there are the concepts listed in the previous paragraphs, and we consider these ‘universal’, and then there are the “movements” which, in one way or another, capitalizes on these concepts, interprets them almost politically, religiously (or anti-such), etc. In our quest for ‘computation for humanity’ we shall try avoid “hijacking” while striving for ‘universality’. 1.1.2

Computation: From Sciences to E-Government

Classically computation seems first to have occurred, in greater measures, in connection with verifying or predicting physical behaviours: at the core of such computations were models of physics (including chemistry), and the computations either had as purpose to verify proposed models, and, once these models could be trusted, then to predict physical (incl. chemical) behaviours. The computational physics models had to satisfy exact mathematical models and these models were not proprietary. But the market for computation lay, not in government laboratories nor in the weapons industry, but in commercial enterprises: initially banks and insurance companies, then in production (manufacturing) and and in monitoring & control (f.ex. the gas and oil industry), then in transport: logistics etc., and in e-commerce, the Internet, the Web, etc., public administration computation grew and e-government computation has arrived. The computational models should satisfy some exact models since computations lure one to believe in their precision, but usually many such models, increasingly in public administration and in e-government in general are implicit: have never been precisely formulated. 1.1.3

Computation for Humanity

We shall now put forward a reasonably objective and non-controversial interpretation of humanity. That interpretation is not complete, it does not claim to cover “as many”, let alone “all” aspects of humanity, that is simply not possible. We shall now summarise Sect. 1.1.1’s enumerations of issues that characterise a concept of ‘humanity’. Underlined terms are suggested to identify such concepts of humanity that may be supported by computation. From the ‘Character Strengths & Virtues’ enumeration: wisdom & knowledge: creativity, curiosity, open-mindedness, love of learning, 3

http://en.wikipedia.org/wiki/Human rights, http://www.hrw.org/ http://www.humanityinaction.org/ 5 http://en.wikipedia.org/wiki/International Humanist and Ethical Union, an umbrella organisation embracing humanist, atheist, rationalist, secular, skeptic, free-thought and Ethical Culture organisations worldwide. 4

January 17, 2012: 09:13

c Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark A Foundation for Computation for Humanity

4 perspective, wisdom, courage: bravery, persistence, integrity, vitality, humanity: love, kindness, social intelligence, justice: active citizenship/social responsibility/loyalty/teamwork, fairness, leadership, temperance: forgiveness, mercy, humility, modesty, prudence, self-regulation, self control, transcendence: appreciation of beauty, appreciation of excellence, gratitude, hope, humor, playfulness, and spirituality. And from Maslow’s ‘Hierarchy of Human Needs’: physiological: breathing, food, water, sex, homeostasis, excretion; safety & security: body employment, resources, the family, health, property; love/belong: friendship, family, sexual intimacy; esteem: self-esteem, confidence, achievement, respect of others, respect by others; self-actualisation: morality, creativity, spontaneity, problem solving, lack of prejudice, and acceptance of facts. By computation for humanity we shall mean any such computation which support one or another or a combination of the (especially underlined) concepts appearing in the two lists above.6 How domain science & engineering may support the underline-designated concepts of humanity will be indicated as we now turn to the issue of what a domain description is.

1.2

What is a Domain Description ?

We first give a brief list of domain names. In doing so we rely on the reader’s familiarity with what these names stand for. Then we give a ‘summary’ definition of what we mean by ‘domain’. And finally we survey important ingredients of a domain description. 1.2.1

Example Domains

Already in the abstract we listed names of some domains. We repeat and augment this list below. air traffic, banking, bus transport, consumer commerce, container lines, food processing, freight transport, health care, manufacturing, pipelines (gas, oil), railway systems, rail transport, resource management, the web, water supply & processing, or fragments thereof.Common to all of the above areas is that involve humans in interaction with other humans and within man-made systems constructed, operated and maintained by humans. We shall, in Sect. 2, rough-sketch outlines of descriptions of some of these domains. In that connection we shall then relate domain descriptions and hence software derived from domain descriptions to some of the underline-designated issues. 1.2.2

Domains

By a domain we mean the observable phenomena and concepts derived from these, of a human-based parts, actions, events and behaviours entities that “make up” the domain, and where humans behaviours interact with other human behaviours and with “other processes”. 6

Or in lists “of that kind” and otherwise generally accepted.



5 1.2.3

Domain Descriptions

By a domain description we mean an orderly set of statements that detail the observable or abstracted properties of parts, actions, events and behaviours of the domain, both informally, in narrative form, and formally – thereby enabling verifiable theories about the domain. We shall soon give examples of domain descriptions. Domain descriptions can, from both a pragmatic and a theoretical point be composed from descriptions of at least six kinds of phenomena and concepts: intrinsics, support [technologies], rules & regulations, scripts, management & organisation and human behaviour Intrinsics: By intrinsics we mean those phenomena and concepts without which nothing can be described, that is, those phenomena and concepts which are basic to everything in the domain. Example intrinsics of a road transport system are: (parts) the road net, street segments, street intersections, vehicles, drivers and passengers, etc.; (actions) inserting and removing vehicles into, respectively from a road net and starting, accelerating, decelerating and stopping vehicles along street segments and around street intersections, etc.; (events) vehicle crashes, etc.; (behaviours) driving a vehicle from point A to point B, etc. Support [Technologies]: By a support[ technologies]s we mean those, primarily technologies which support parts, actions, events and behaviours of the domain. Example support technologies for a road transport system are: street signals, level railway crossing gates and parking meters. Rules & Regulations: By ‘rules & regulations’ we mean a set of pairs of rules and regulations pertaining to a well delineated set of domain parts. For a domain there can be many such sets. Rule: By a rule we mean the prescription of a predicate over pairs of domain states (i.e., designated domain parts), a ‘before’ and an ‘after’ state, which must hold for any given action, event or behaviour; if not, then the rule is said to have been violated. Regulation: By a regulation we mean the prescription of a set of one or more actions which should be applied if a corresponding rule has been violated — with the effect of creating a new pair of ‘before/after’ states in which the rule now holds. Example rules & regulations for road traffic are: Speed: rules for speed limits per road type and fine regulations if caught speeding; Travel direction: stop for red traffic signal and a fine regulation if caught crossing while red signal. Scripts: By a script we mean a [structured] set of rules and regulations to be respectively applied and [conditionally] enacted according to the set structure. An example script could be the set of questions to be asked of and the actions to be carried out with respect to a potential hospital patient for the anamnese, analysis, diagnosis and treatment plan when this patient is first admitted to a hospital. January 17, 2012: 09:13


6 Management & Organisation We analyse the conjoined (hence the &) concept of ‘management & organisation’ into its three components: ‘management’, ‘organisation’ and ‘management & organisation’. Organisation: By organisation we mean an iterative partitioning of resources, and, where applicable, their related behaviours, into some (hierarchical, matrix or other) structure. An organisation example is: The divisioning of an automobile company into personal car, truck, motor, transmission, parts, etcetera divisions and some of these again into continent/country divisions. Management: By management we mean the monitoring and control of resources (i.e., parts): human staff, time, monies and physical plant and materials — where monitoring & control implies that staff and/or machines, as behaviours, are charged with the performance of actions while obeying rules & regulations and scripts. A management example could be: The overall management of the main divisions of an automobile company with its directives and lines of monitoring and control (including change) of the organisational structure and strategies, tactics, that is reactions to or preparations for market conditions, and operational handling of, for example, the day-to-day business. Management & Organisation: By management & organisation we mean that management primarily follows the organisational structure but that some rules & regulations and/or scripts mandate deviation from the organisational structure. Human Behaviour By human behaviour we mean the manner in which a person conducts herself with respect to performing (or not performing) mandated or expected actions and to respond to expected or unexpected events. The behavioural description usually includes descriptions that reflects a spectrum from diligent via sloppy and delinquent to outright criminal behaviour.

1.3 1.3.1

Rˆ ole of Domains in Software Development Three Phases of Software Engineering

Computations are usually based on computer software. Before Software can be designed one must understand its Requirements: what is expected from the software not how it operates. Before Requirements can be expressed one must understand the underlying Domain: not how it operates, but its properties. From this S, R, D triplet we conclude that we must first do some Domain Science & Engineering, then “derive” the Requirements before we finally design the Software. Yes, there are rather precise methods for “discovering”, based on a domain description and in collaboration with stake-holders of the domain a significant part of the desired requirements. We refer to [8, 11, ?, ?, 16]. 1.3.2

“Deriving” Requirements from Domain Descriptions

We review some of the [almost] algebraic operations that the domain cum requirements engineers perform in collaboration with both domain and requirements stake-holders. We c Dines Bjørner 2011. Fredsvej 11, DK–2840 Holte, Denmark


7 do so in order to better understand how both domain and requirements engineering can contribute to ‘computing for humanity’. We shall overview some of the [almost] algebraic operations, namely projection, instantiation, determination and extension. Projection: By the projection of a domain we mean the removal, from a domain description of those part, action, event and behaviour descriptions which are deemed irrelevant for expressing the requirements. The result of projection is a requirements prescription. An example projection arises for a road net building application in which we are not concerned with vehicle traffic and hence also not with drivers and passengers. So we remove vehicles, drivers and passengers. Another example projection arises for a road pricing application in which we are not concerned with drivers and passengers. So we remove drivers and passengers. Instantiation: By instantiation we mean the refinement7 of parts, actions, events and behaviours: where before an entity specification allowed many, for example, part compositions, an instantiated specification usually is “less flexible” suggesting a more specific entity. An example instantiation arises for a toll way application: has road nets as orderly, finite sequences of pairs of one way toll road segments between adjacent toll road intersections which latter one can also access or leave through two way plaza road segments from or to toll plaza “intersections”. Determination: By determination we mean the refinement of non-deterministic choices into less non-deterministic, including only deterministic choices as concerns parts, actions, events and behaviours. An example determination arises for a toll way application in which the state of toll roads always and only allow traffic only and always in one direction, in which the state of toll plaza roads always allow traffic both directions, and in which the state of toll road intersections always allow traffic from any toll [plaza] road incident upon the intersection to any toll [plaza] road eminent from the intersection. Extension: By an extension we mean the inclusion of a further domain description of phenomena and concepts that were not feasible without computation. An example extension is a road pricing arrangement whereby car movements are tracked and records kept on car routes from which payment can then be calculated. Discussion: We have included the above aspects of requirements engineering for the following reasons. The listed requirements operations are all described with no reference to specific computation concepts and hence invite “technology-free” creativity, innovation and problem solving all of whom contribute towards satisfying some of the ‘humanity’ criteria. 7 By refinement is understood a concretisation of the specification, that is: from a more abstract specification is obtained a more concrete one, one that is “closer” in some sense to how one might specify the software.

January 17, 2012: 09:13


8

Informal Description of Some Domains

2 2.1

A Banking System

We describe a generic class of main street banks, that is, banks which service ordinary citizens, hold demand/deposit accounts with credit limits and offer mortgages (and loans), hence with mortgage cum loan accounts, repayments, etc. We abstract away from branch offices, that is, a bank with all its branch offices appears as one unit, Yet there may be several banks serving several communities: states, provinces, cities or just unincorporated areas. 2.1.1

Intrinsics

Parts and Their Attributes 1. A banking system is here delineated by a a set of (uniquely identified) clients, b a set of (uniquely identified) banks, and c a banking “watchdog”: an authority which monitors banking practices etcetera8 . d Client and bank identifications are further undefined. We shall focus, in this paper, just on the client aspects of banks. 2. A client is here considered an atomic part with the following attributes: a name, b addresses (physical and electronic), c national identifier, d a set of zero, one or more demand/deposit bank account numbers (of accounts held), e a set of zero, one or more mortgage account numbers (of outstanding mortgages), such that each mortgage accounts is outstanding against exactly one client; etcetera. One observes that a demand/deposit bank account may be shared between two or more clients. It is assumed that all accounts listed do indeed exist. 3. A bank a is uniquely identified (an attribute), 8 The watchdog authority is: in the US FEC: Federal Exchange and Securities Commission,in the UK FSA: Financial Services Authority,in Germany BaFin: Bundesanstalt fr Finanzdienstleistungsaufsich.



9 and holds, as separate parts, b a cash register, c zero or more clients, each of which is an atomic part, d zero or more client demand/deposit accounts, each of which is an atomic part, and e zero, one or more mortgage accounts, each of which is an atomic part. 4. The cash register holds coins and bank notes. 5. A client demand/deposit account (which is an atomic part) has the following attributes: a a unique identifier, b a balance which is a money designation above a credit limit, c an interest rate to be paid quarterly to the bank on averaged client demand/deposit account balances between a possibly negative balance credit limit and zero money units, and d a yield rate to be paid quarterly by the bank into the account when averaged client demand/deposit account balances are above zero money units, e a list of transaction designators9 , f a date when established, etc. We observe that each individual client demand/deposit account has its own interest and yield rates. Should a particular bank not offer differentiated client demand/deposit account interest and yield rates then that is modelled by all the individual client demand/deposit accounts having identical interest and yield rates. 6. A client mortgage (cum loan) account (which is an atomic part) has the following attributes: a a unique identifier, b a repayment balance, c an original mortgage (loan) amount, d an interest rate, e a repayment schedule, f a repayment fee, and g a deed (referring to some property held by the client as security against the mortgage (loan)). 9

which will be described later, see Item ?? on page ??

January 17, 2012: 09:13


10 Actions The following actions are performed on demand/deposit accounts: 7. open demand/deposit account where: a a client states the bank name, the client name, addresses and national personal identifier, and a cash deposit amount with which to open the account, and b that bank provides that client with an account number, interest and yield rates, and establishes the account balance and a credit limit while recording this timestamped transaction as the first of that new account’s transaction list; 8. deposit money where: a an identified client states the bank name, an appropriate account and a cash amount to be deposited, and b the bank accepts the amount, that is, increments the identified account’s balance accordingly while recording this time-stamped transaction as the most recent of that account’s transaction list; The above descriptions can be made more precise. We omit description of further demand/deposit transactions, for example: 9. withdraw cash, 10. transfer monies, 11. open share count,

12. close share account, 13. request transaction statement and 14. close demand/deposit account.

The following actions are performed on mortgage/loan accounts for which we also omit more suggestive descriptions: 15. negotiate mortgage/loan, 16. open mortgage/loan account, 17. mortgage/loan repayment,

18. default mortgage/loan repayment and 19. close on mortgage/loan account.

Events 20. overdraft on demand/deposit account where: a a cash withdrawal (Item 9) exceeds the balance and credit limit on the account. 21. bankruptcy where: a the bank’s outstanding debt exceeds its cash and credits. c Dines Bjørner 2011. Fredsvej 11, DK–2840 Holte, Denmark


11 Behaviours 22. demand/deposit account behaviour as a series of zero or more cash deposits, cash withdrawals, transfers, open and close share accounts, and transaction statement requests, in any order, prefixed and suffixed by open, respectively close account transactions — all of these with respect to a specific account and interwoven with possible events. 23. mortgage account behaviours as a series of zero or more mortgage repayment, and default mortgage repayment prefixed by a pair of negotiate mortgage and open mortgage account, and suffixed by a close on mortgage/loan account transaction — all of these with respect to a specific account and interwoven with possible events. 24. client behaviour as a series of zero or more “interwoven” demand/deposit account behaviour and zero one or more mortgage account behaviours — with respect to the same client. 25. bank behaviour as a series of “interwoven” client behaviours — over all of its clients — together with internal bank transactions — so far not mentioned: calculate demand/deposit interests, calculate demand/deposit yields, calculate mortgage interests, and interwoven with possible events. 2.1.2

Support Technologies

We omit careful descriptions of “standard” support technologies such as 26. credit cards,

28. E-banking,

27. ATM,

29. etcetera.

2.1.3

Rules & Regulations

We omit careful descriptions of rules & regulations such as 30. related to overdraft,

32. bankruptcy,

31. default on loans,

33. etcetera.

2.1.4

Scripts

We omit careful descriptions of scripts such as 34. calculation of interest or yield,

36. estimation of loan risks,

35. calculation of loan repayments,

37. etcetera.

January 17, 2012: 09:13


12 The borderline between the concepts of ‘rules & regulations’ and of ‘scripts’ can be fuzzy. 2.1.5

Management & Organisation

We omit careful descriptions of management & organisation matters such as: 38. main vs. branch offices, 39. bank teller vs. ‘‘back office’’ staff, 2.1.6

40. signatory rights (say on loans), 41. etcetera.

Human Behaviour

We omit careful descriptions of human behaviours such as: 42. interest or yield calculation,

44. loan risk assessment,

43. loan repayment calculation,

45. etcetera.

2.1.7

Discussion

We have just barely rough-sketched a partial narrative bank description. A proper bank description would focus on each of the numbered items and formulate these with far more precision than shown here. And a proper bank description would be “paired” with a formal description, numbered item by numbered item. The formalisation would follow the narrative wording very closely. The formalisation would then be the basis for stating and proving theorems, i.e., laws of banking, such as seen by the whole banking plus client domain, by any individual bank, and by any individual client.

2.2

A Health Care System

Health care systems can be domain described from a variety of rather distinct views. One could be singled out: the monitoring and control of flow patients, medical staff, medical supplies, patient information, health care management information, visitors, etcetera within and between private physicians, hospitals, policlinics, pharmacies, health insurance companies, health industry monitors, etcetera. Other, perhaps ‘orthogonal’, view-points are possible. But just with the one given we can see the overall complexity. Domain describing the health care sector seems to be “a must”. To given an example of a fragment of a “flow”-oriented description we refer to one aspect of the patient/medical staff/medical supplies/patient information flow, one that can be captured by the flow/state diagrams of Fig. 1 on the next page. We let the labels of the patient handling action rectangles and the medical staff diamond shaped decision “box” “speak” for the interpretation of the diagrams. c Dines Bjørner 2011. Fredsvej 11, DK–2840 Holte, Denmark


13 Admit

Interview

1

1

2

2 Plan Analysis

3

3

4 Analyse Analysis Finished? Yes

MA More Analysis?

4

nMAanAF

Yes Diagnose

5

More Analysis?

MA

nMA

6

Plan Treatment

Yes

5

Yes

nMDaMA

6

Yes

More Analysis? More Treat

Diagnosis?

7

7

Yes

MD

nMDanMA

nAFu 8

Yes

Is Patient OK?

AFu

MT

nMTanPok

8

Analyse

Analysis Follow−up? More Treatment ?

nMTaPok

Yes Release

9

9

Figure 1: A hospitalisation plan: flowchart and finite state machine So, instead of domain describing even this aspect of the health service, we indicate, to the reader, that a domain description could very well follow the lines of the banking domain description. Our students, in MSc and PhD courses in Denmark, Japan, Singapore, Austria, France, Germany, Scotland, Hungary and Sweden have sketched and formalised descriptions of patient journal and hospitalisation sub-domains In [20] we sketch a script language for patient/hospital contracts based on the kind of flow diagrams shown in Fig. 1.

2.3

Other Domains

Over the years many domain descriptions have been worked out. Some can be mentioned: airports, air traffic [1]10 , banking11 , container lines [9]12 , the consumer market [2]13 , logistics [13]14 , manufacturing, (water, oil, gas, etc.) pipelines [12]15 , railways [5, 6, 22, 7, 24, 23, 3, 10

www.imm.dtu.dk/˜db/airtraffic.pdf www.imm.dtu.dk/˜db/fsi.pdf 12 www.imm.dtu.dk/˜db/container-paper.pdf 13 www.imm.dtu.dk/˜db/themarket.pdf 14 www.imm.dtu.dk/˜db/logistics.pdf 15 www.imm.dtu.dk/˜db/pipeline.pdf 11

January 17, 2012: 09:13


14 4, 19, 18, 17]16 transport systems (in general) [10]17 , stock exchanges [15]18 , etcetera.

3

Humanities and Domain Science & Engineering

We now review the “products” of domain science & engineering in the light of our characterisation of ‘humanity’ in Sect. 1.1.1.

3.1

Banking for Humanity

Let us review the underlined items in the first of the two lists of Sect. 1.1.3. From the ‘Character Strengths & Virtues’ enumeration: Wisdom & Knowledge: studying (i.e., “learning”) a domain model for banking (creativity) should enable a bank employee and/or a software engineer to better create new banking products, respectively new computing supports for banking; (curiosity) provoke more in-depth studies of banking; (love of learning) if the domain description is of a reasonable high standard its study should entice the reader towards further studies; (perspective) while giving those new in ‘banking’ who understand the domain model a perspective they cannot have had before; and wisdom. Humanity: understanding and possessing a domain model for banking (social intelligence) should significantly facilitate the human capacity to effectively navigate and negotiate complex banking relationships and environments. Justice: understanding and possessing a domain model for banking (active citizenship/social responsibility/loyalty/teamwork) should allow this domain “expert” to better deploy her insight i the direction of these /’ed areas; and (leadership) thus show leadership. Temperance: understanding and possessing a domain model for banking (modesty) (with all its complexities, even when expressed in an as simple manner) ought instill some modesty with, for example, thet domain expert’s opinion of his own fallibility ; and (prudence) enable that ‘expert’ to govern and discipline by the use of reason. Transcendence: (appreciation of beauty) A domain description, i.e., a domain model, must be beautiful [21] – hence it must instill appreciation for beauty also in matters of banking. (appreciation of excellence) Grasping a domain model should be easier than learning it “by osmosis”. The domain model should be an excellent piece of intellectual work.

3.2

Other Domains for Humanity

The observations of Sect. 3.1 apply, with suitable term changes, to basically any other domain. Understanding a well-described domain – in general – enhances, we claim, creativity, 16

http://www.railwaydomain.org/ www.imm.dtu.dk/˜db/isola-pa.pdf 18 www.imm.dtu.dk/˜db/todai/tse-1.pdf 17



15 curiosity, love of learning, perspective, and wisdom; social intelligence, active citizenship/social responsibility/loyalty/teamwork and leadership; modesty and prudence; and appreciation of beauty and excellence. We now relate Maslow’s ‘Hierarchy of Human Needs’ to domains in general: Physiological: (Food) Domain descriptions of eventually all aspects of the food chain and subsequent IT support for relevant facets should enable improved production, distribution and sale of foodstuffs. Today there are no such comprehensive set of related domain models for “all” sides of the food chain. There are many IT applications, but only where these can be commercially marketed. Domain models for, for example, the food chain, is a task, not of commerce or industry, but, it seems of public, international research. We claim, that once such part models emerge, new IT supports will be commercially feasible, that is, computations that “interface” smoothly with other such IT supports. (Water) The above paragraph (for food) can be rephrased, inter alia, for water. Safety & Security: Resources: Domain descriptions of eventually all aspects of the resources on which we, as humans, rely, will eventually emerge. We may distinguish between the following kinds of resources: economic: commodity, service, or other asset used to produce goods and services that meet human needs and wants; biological: a resource is defined as a substance or object required by a living organism for normal growth, maintenance, and reproduction; IT equipment; natural resources are derived from the environment and include such resources as land, water, air, minerals; labor; capital; infrastructure: there are basic physical and organizational structures needed for the operation of a society or enterprise; and intangible resources, such as corporate images, brands and patents, and other intellectual property, exist in abstraction. Researching, teaching and learning such domain models should empower the individual, already from youth, to better understand the rôle of resources in all their variety; and to objectively know what factual problems of resources are: shortage, price, availability and accessibility. Domain models of resources may be “implemented” in terms of computation19 [14]. Computational models may, for example, demonstrate (“demo”) “non-renewable resource chains”: from their origin, via extraction, transport and processing, to their eventual consumption. Computational models may simulate “what-if” scenarios. And computational models may calculate risks and benefits. We claim that “demo”, simulator and calculator computations based on domain descriptions (with which the users of these computations are familiar) represent a significant advantage, i.e., “can be far more human”, compared to computations not based on serious domain descriptions. Health: On the basis of domain descriptions, such as very sketchily hinted at in Sect. 2.2, we can claim the following. Studying and learning domain models of increasingly wider areas of the health service sector empowers ordinary citizen – and their elected politicians to better understand, organise, monitor and control that sector. Thus enabling computations that are better founded, hence more human. Especially the health sector and its computerisation is, today, at a cross-roads: 19 There are certainly many IT applications wrt. resources. But none or few are based on publicly available domain descriptions of the kind we are advocating; descriptions which. for example, can be the basis for secondary school education.

January 17, 2012: 09:13


16 most electronic patient journal systems fail in communication with each other, and most patient hospitalisation systems likewise. Esteem: The key attributes here are confidence, achievement and respect of others. Researching, developing, studying and learning domains through well structured, scientifically objective domain descriptions should empower citizens, from researchers and developers via domain “owners” to domain users, to be far more confident in the understanding and use of that domain than when no such properly researched and documented understandings are available. At the same time these citizens should achieve far better and technologyindependent use of such domains and thereby be able to have a well-founded esteem for all stake-holders of the the domain. Self-actualisation: The key attributes here are creativity, problem solving and acceptance of facts. Researching, developing, studying and learning domains through well structured, scientifically objective domain descriptions give, we claim, those scientists and engineers who have researched and developed these domain descriptions hitherto unrivalled abilities to (business process) re-engineer (i.e., create) several facets of these domains20 , thus, most likely, and at least on a more informed background, solve existing, usually human relations domain problems; and bring to those other domain stake-holders who have studied and understood descriptions of domains which would have been near-impossible to fully grasp without such domain descriptions a “peace-of-mind” acceptance of domain facts, while empowering them to better voice their possible dissatisfaction with existing domain practices.

3.3

Natural Sciences versus Domain Sciences

It is commonly accepted that we teach and that we are expected to learn and be reasonably capable in reckoning (i.e., to calculate), mathematics, natural and life sciences: physics, chemistry, botanic, zoology, geology, biology, etcetera. To study logic and learn to reason logically is, however, not considered so necessary ! We shall now plead that we must expand what is taught from primary school onwards to also include studies of man-made domains. The study of the natural and life sciences is motivated with such statements as “we must understand the world that surrounds us”, “engineering is based on these sciences and, to stay competitive, we must study them”, “health care is based on these sciences and, to survive, we must thus study them”, etcetera. The study of the domain sciences, that is the study of domains such as the financial service industry21 , transportation22 , manufacturing(in its widest sense23 ), the Web and Internet. etcetera, can be likewise motivated:“many aspects of the processes of man-made domains 20 f.ex.: new support technologies, new rules, regulations and scripts, and new management & organisation structures 21 banking, insurance, portfolio management, the trading of securities instruments [stocks, bonds and other commodities (oil, gas, minerals, grain, meat, etc.)], etcetera 22 road nets, bus, rail, ship and air transport, shipping, logistics, pipelines, etc,. 23 energy production and distribution, petrochemical industry, water supplies, iron ore to steel processing, metal working, electronics, etc.



17 are hidden from the human eye, and thus they all too easily attain an undesirable ‘air’ of mystification”24 , “many processes of man-made domains are are prone to be ‘process engineered’ in such a manner as to reflect misuse of power of those who manage these processes over those whom these processes deal with”, etcetera, Therefore, in a free (read: human) society, it seems reasonable to also expect that we properly educate and train coming generations — from school — in the seeming complexities of their society. Why should the natural and life sciences be taught and learned and not the domain sciences and engineering ? And to make use of domain knowledge we must also strengthen logical reasoning.

4

Conclusion

What have we achieved ? We have introduced the notion of domain. First we have characterised its descriptional ingredients and then we have given an albeit very rough sketch example of a fragments of a banking domain and an even sketchier example of a fragment of a hospital domain. Before these examples we have enumerated a number of concepts that we claim characterise one set of facets of ‘humanity’. There, surely, may be other such sets of facets. But these are the ones that we shall “bring to bear” on ‘domain sciences and engineering’. After the examples we review the underlined selection of ‘humanity’ concepts of Sect. 1.1.1 in the light of the examples – and in general. This review is not a clear cut “scientific” review. That is, it does not argue by way of (formal) logical reasoning. Instead it reasons by way of more-or-less persuasive statements. Two subject areas have been brought together, contrasted with one another: domain sciences & engineering, a reasonably “strict” discipline whose expressions (i.e., the domain descriptions) are reasonably precise and ‘humanities’, a far more “fluent” discipline, whose enumeration, in Sect. 1.1.1 are not based on mathematics. If you think that ‘humanities’ can (also) be characterised by the enumerations of Sect. 1.1.1 can be supported by computation as sketched in Sect. 3, then domain science & engineering, as exemplified in Sect. 2, can contribute in significant ways to computations for humanity, otherwise our claims are just that: claims. There is no one and only concept of ‘humanity’. The discipline area of formulating a concept of ‘humanity’ is fraught with problems. It easily becomes a ‘battle ground’ for political or other opinions and a “feel good” ‘position’ to claim to be ‘human’ or to speak for ‘humanity’. In this paper we have tried to view ‘computation for humanity’ in a cool, detached manner, relying on reasonably non-controversial (the enumerated) concepts. Whether we have succeeded is, partly, up to you to decide. At least we hope that your critical sense, when you are next confronted with the term ‘humanity’ has been alerted and primed differently from before you read this chapter ! 24 in “ye olde days” children could easily grasp the “industry” of their parents: father at the woodwork bench making tools for farming and furniture, mother at the weave, etc.

January 17, 2012: 09:13


18

Bibliographical Notes

5 5.1

The Notes

We have permitted ourselves to rather unusually and perhaps far too “generously” reference own publications25 with respect to domains. That “breach” on propoer academic decor is “excused” as follows. (i) Domain science & engineering, as outlined here, is a relatively new branch of computer science and software engineering so perhaps the reader should be informed that there are publications and reports that support the claims made in this chapter with respect to the concepts of domain science & engineering. (ii) The readers of the present volume are assumed not to be well versed in the field of domain science & engineering.

5.2

References

[1] D. Bjørner. Software Systems Engineering — From Domain Analysis to Requirements Capture: An Air Traffic Control Example. In 2nd Asia-Pacific Software Engineering Conference (APSEC ’95). IEEE Computer Society, 6–9 December 1995. Brisbane, Queensland, Australia. [2] D. Bjørner. Domain Models of ”The Market” — in Preparation for E–Transaction Systems. In Practical Foundations of Business and System Specifications (Eds.: Haim Kilov and Ken Baclawski), The Netherlands, December 2002. Kluwer Academic Press. Final draft version. [3] D. Bjørner. Dynamics of Railway Nets: On an Interface between Automatic Control and Software Engineering. In CTS2003: 10th IFAC Symposium on Control in Transportation Systems, Oxford, UK, August 4-6 2003. Elsevier Science Ltd. Symposium held at Tokyo, Japan. Editors: S. Tsugawa and M. Aoki. Final version. [4] D. Bjørner. New Results and Trends in Formal Techniques for the Development of Software for Transportation Systems. In FORMS2003: Symposium on Formal Methods for Railway Operation and Control Systems. Institut für Verkehrssicherheit und Automatisierungstechnik, Techn.Univ. of Braunschweig, Germany, 15–16 May 2003. Conf. held at Techn.Univ. of Budapest, Hungary. Editors: G. Tarnai and E. Schnieder, Germany. Final version. [5] D. Bjørner. The Grand Challenge – FAQs of the R&D of a Railway Domain Theory. In IFIP World Computer Congress, Topical Days: TRain: The Railway Domain, IFIP, Amsterdam, The Netherlands, 2004. Kluwer Academic Press. [6] D. Bjørner. The TRain Topical Day. In Building the Information Society, IFIP 18th World Computer Congress, Tpical Sessions, 22–27 August, 2004, Toulouse, France — Ed. Renéne Jacquart, pages 607–611. Kluwer Academic Publishers, August 2004. A Foreword. 25

At least these rather many references to own publications do not count in Scholar Indexes.



19 [7] D. Bjørner. Towards a Formal Model of CyberRail. In Building the Information Society, IFIP 18th World Computer Congress, Tpical Sessions, 22–27 August, 2004, Toulouse, France — Ed. Renéne Jacquart, pages 657–664. Kluwer Academic Publishers, August 2004. [8] D. Bjørner. Software Engineering, Vol. 3: Domains, Requirements and Software Design. Texts in Theoretical Computer Science, the EATCS Series. Springer, 2006. [9] D. Bjørner. A Container Line Industry Domain. Technical Report, IT Informatics, Technical University of Denmark, 2800 Kgs. Lyngby,, Denmark, June 2007. Extensive Draft. [10] D. Bjørner. Transportation Systems Development. In 2007 ISoLA Workshop On Leveraging Applications of Formal Methods, Verification and Validation; Special Workshop Theme: Formal Methods in Avionics, Space and Transport, ENSMA, Futuroscope, France, December 12–14 2007. [11] D. Bjørner. From Domains to Requirements. In Montanari Festschrift, volume 5065 of Lecture Notes in Computer Science (eds. Pierpaolo Degano, Rocco De Nicola and José Meseguer), pages 1–30, Heidelberg, May 2008. Springer. [12] D. Bjørner. A Domain Model of Oil Pipelines. Technical Report, Incomplete Draft, IT Informatics, Technical University of Denmark, 2800 Kgs. Lyngby, Denmark, June 2009. [13] D. Bjørner. What is Logistics ? A Domain Analysis. Technical Report, Incomplete Draft, IT Informatics, Technical University of Denmark, 2800 Kgs. Lyngby, Denmark, Denmark, June 2009. [14] D. Bjørner. Domains: Their Simulation, Monitoring and Control – A Divertimento of Ideas and Suggestions. Festschrift for Hermann Maurer: Rainbow of Computer Science Lecture Notes in Computer Science, volume 6570 (eds. C. Calude, G. Rozenberg and A. Saloma). Springer, Heidelberg, Germany, January 2011. [15] D. Bjørner. The Tokyo Stock Exchange Trading Rules. R and D Experiment, IT Informatics, Technical University of Denmark, 2800 Kgs. Lyngby, Denmark, January and February, 2010. Version 1, 78 pages: many auxiliary appendices, Version 2, 23 pages: omits many appendices and corrects some errors.. [16] D. Bjørner. The Role of Domain Engineering in Software Development. Why Current Requirements Engineering Seems Flawed! In Perspectives of Systems Informatics, volume 5947 of Lecture Notes in Computer Science, pages 2–34, Heidelberg, Wednesday, January 27, 2010. Springer. [17] D. Bjørner, Y. L. Dong, and S. Prehn. Domain Analyses: A Case Study of Station Management. In KICS’94: Kunming International CASE Symposium, Yunnan Province, P.R.of China. Software Engineering Association of Japan, 16–20 November 1994. January 17, 2012: 09:13


20 [18] D. Bjørner, C. W. George, and S. Prehn. Scheduling and Rescheduling of Trains, chapter 8, pages 157–184. Industrial Strength Formal Methods in Practice, Eds.: Michael G. Hinchey and Jonathan P. Bowen. FACIT, Springer, London, England, 1999. [19] D. Bjørner, C. W. George, and S. Prehn. Computing Systems for Railways — A Rôle for Domain Engineering. Relations to Requirements Engineering and Software for Control Applications. In Integrated Design and Process Technology. Editors: Bernd Krämer and John C. Petterson, P.O.Box 1299, Grand View, Texas 76050-1299, USA, 24–28 June 2002. Society for Design and Process Science. Extended version. [20] Dines Bjørner. Chap. 10: Towards a Family of Script Languages: Licenses and Contracts for Electronic Document (Music etc.) Sharing, Public Transport and for Hospitalisation., pages 283–328. JAIST Press, March 2009. [21] W. Feijen, A. van Gasteren, D. Gries, and J. Misra, editors. Beauty is Our Business, Texts and Monographs in Computer Science, New York, NY, USA, 1990. Springer. A Birthday Salute to Edsger W. Dijkstra. [22] M. Pˇeniˇcka and D. Bjørner. From Railway Resource Planning to Train Operation — a Brief Survey of Complementary Formalisations. In Building the Information Society, IFIP 18th World Computer Congress, Topical Sessions, 22–27 August, 2004, Toulouse, France — Ed. René Jacquart, pages 629–636. Kluwer Academic Publishers, August 2004. [23] M. Pˇeniˇcka, A. K. Strupchanska, and D. Bjørner. Train Maintenance Routing. In FORMS’2003: Symposium on Formal Methods for Railway Operation and Control Systems. L’Harmattan Hongrie, 15–16 May 2003. Conf. held at Techn.Univ. of Budapest, Hungary. Editors: G. Tarnai and E. Schnieder, Germany. Final version. [24] A. K. Strupchanska, M. Pˇeniˇcka, and D. Bjørner. Railway Staff Rostering. In FORMS2003: Symposium on Formal Methods for Railway Operation and Control Systems. L’Harmattan Hongrie, 15–16 May 2003. Conf. held at Techn.Univ. of Budapest, Hungary. Editors: G. Tarnai and E. Schnieder, Germany. Final version.



21

Contents 1 Introduction 1.1 What Can We Mean by ‘Computation for Humanity’ ? . . 1.1.1 Humanity . . . . . . . . . . . . . . . . . . . . . . . . . Reasonably Established Uses of ‘Humanity’ . . . . . Hijacked Uses of ‘Humanity’ . . . . . . . . . . . . . . 1.1.2 Computation: From Sciences to E-Government . . . 1.1.3 Computation for Humanity . . . . . . . . . . . . . . . 1.2 What is a Domain Description ? . . . . . . . . . . . . . . . 1.2.1 Example Domains . . . . . . . . . . . . . . . . . . . . 1.2.2 Domains . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.3 Domain Descriptions . . . . . . . . . . . . . . . . . . Intrinsics: . . . . . . . . . . . . . . . . . . . . . . . . . Support [Technologies]: . . . . . . . . . . . . . . . . . Rules & Regulations: . . . . . . . . . . . . . . . . . . Scripts: . . . . . . . . . . . . . . . . . . . . . . . . . . Management & Organisation . . . . . . . . . . . . . Human Behaviour . . . . . . . . . . . . . . . . . . . . 1.3 Rˆ ole of Domains in Software Development . . . . . . . . . 1.3.1 Three Phases of Software Engineering . . . . . . . . 1.3.2 “Deriving” Requirements from Domain Descriptions Projection: . . . . . . . . . . . . . . . . . . . . . . . . Instantiation: . . . . . . . . . . . . . . . . . . . . . . . Determination: . . . . . . . . . . . . . . . . . . . . . . Extension: . . . . . . . . . . . . . . . . . . . . . . . . . Discussion: . . . . . . . . . . . . . . . . . . . . . . . . 2 Informal Description of Some Domains 2.1 A Banking System . . . . . . . . . . . 2.1.1 Intrinsics . . . . . . . . . . . . Parts and Their Attributes . . Actions . . . . . . . . . . . . . Events . . . . . . . . . . . . . . Behaviours . . . . . . . . . . . 2.1.2 Support Technologies . . . . . 2.1.3 Rules & Regulations . . . . . . 2.1.4 Scripts . . . . . . . . . . . . . . 2.1.5 Management & Organisation 2.1.6 Human Behaviour . . . . . . . 2.1.7 Discussion . . . . . . . . . . . 2.2 A Health Care System . . . . . . . . 2.3 Other Domains . . . . . . . . . . . . . January 17, 2012: 09:13

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

2 2 2 2 3 3 3 4 4 4 5 5 5 5 5 6 6 6 6 6 7 7 7 7 7

. . . . . . . . . . . . . .

8 8 8 8 10 10 11 11 11 11 12 12 12 12 13


22 3 Humanities and Domain Science & Engineering 3.1 Banking for Humanity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Other Domains for Humanity . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Natural Sciences versus Domain Sciences . . . . . . . . . . . . . . . . .

14 14 14 16

4 Conclusion

17

5 Bibliographical Notes 5.1 The Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18 18 18



Domain Science &â Engineering A Foundation for Computation ... - DTU

Domain Science &â Engineering A Foundation for Computation ... - DTU

Suggest Documents