On “The Right” Software
On “The Right” Software
On “The Right” Software
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
<strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong><br />
Dines Bjørner<br />
Denmark<br />
Beijing 26–27 April 2011<br />
April 1, 2011, 12:27 <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark<br />
1
2<br />
Summary<br />
• Boehm [Boehm81] is credited to have formulated the “Two Rights” of software:<br />
– the problem of getting the right software<br />
– and<br />
– the problem of getting the software right.<br />
• The development processes needed<br />
– to achieve software that is right, to us,<br />
∗ requires that a proper study of the application domain<br />
∗ be done before a serious requirements study is attempted; and<br />
– to achieve the right software,<br />
∗ that is, software that is correct, to us,<br />
∗ requires that a proper engineering degree of formalism<br />
∗ be applied to the entire development process;<br />
– that is, that we re-interpret classical development processes<br />
[Spiral-Model-Boehm-1988].<br />
c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> April 1, 2011, 12:27
• We shall in this paper focus only on the issue of obtaining the right<br />
software.<br />
• In this talk we shall outline<br />
– what we mean by a proper study of the application domain<br />
– and how it influences the requirements development.<br />
April 1, 2011, 12:27 <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark<br />
3
4<br />
1.<br />
1. Introduction<br />
1.1. The Triptych Phases of <strong>Software</strong> Development<br />
• Before we can design software we must understand its requirements.<br />
• Before we can prescribe the requirements we must understand the<br />
domain,<br />
– that is, the application area for the contemplated software.<br />
• Thus we argue that software development consists of three major<br />
phases:<br />
– Domain engineering — which results in a carefully analysed (verified,<br />
checked, tested and validated) domain description;<br />
– Requirements engineering, based on the domain description — which results<br />
in a carefully analysed (verified, checked, tested and validated) requirements<br />
prescription; and<br />
– <strong>Software</strong> design, based on the requirements prescription — which results in<br />
carefully analysed (verified, checked, tested and validated) software code.<br />
c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> April 1, 2011, 12:27
1. Introduction 1.2. What Is Different ?<br />
1.2. What Is Different ?<br />
• Among several differences comparing the Triptych approach to conventional<br />
software engineering, we consider, in this talk, four differences.<br />
1.2.1. Domain Engineering<br />
• Classical software engineering focus on Requirements and <strong>Software</strong> design.<br />
• Although Requirements engineering do entail considerations of the Domain<br />
– there is no real attempt to establish<br />
– a comprehensive description and analysis of the domain<br />
– free from any considerations of requirements — let alone software.<br />
• The Triptych approach calls for such a free-standing description and analysis.<br />
– Yes, it is true that one understands far more of the domain after software<br />
design,<br />
– but it is sort of groping in the dark prescribing requirements without really<br />
having made an honest attempt at understanding the domain.<br />
• Including domain engineering into software development helps avoiding risks.<br />
April 1, 2011, 12:27 <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark<br />
5
6 1. Introduction 1.2. What Is Different ? 1.2.2. Derivation of Requirements From Domain Descriptions<br />
1.2.2. Derivation of Requirements From Domain Descriptions<br />
• We show a new approach to requirements engineering.<br />
– Whereas requirements conventionally are acquired,<br />
laboriously, from stake-holders,<br />
– major parts of requirements are now systematically “derived” from domain<br />
descriptions.<br />
– Of course, the burden has shifted,<br />
∗ facts about the domain is now acquired, laboriously, from stake-holders,<br />
∗ but the classical problem of “always changing requirements”<br />
has been partly alleviated:<br />
· domains are more stable than requirements<br />
· and arriving at “less fluctuating” requirements is made more<br />
deterministic in being based, to a large degree, on a more stable domain<br />
understanding.<br />
• Deriving requirements helps avoiding risks.<br />
c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> April 1, 2011, 12:27
1. Introduction 1.2. What Is Different ? 1.2.3. Duality of Narratives & Formalisation<br />
1.2.3. Duality of Narratives & Formalisation<br />
• For all specifications of<br />
– domain facts,<br />
– requirements and<br />
– software design<br />
• we mandate the use of informal narratives and formal specifications.<br />
– The formalisms serve the developers.<br />
– The narratives serve the stake-holders.<br />
– And narratives and formalism fit one-another: “hand in glove”.<br />
• Stating all domain facts, requirements as well as software<br />
architectures both informally and formally further helps avoiding<br />
risks.<br />
April 1, 2011, 12:27 <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark<br />
7
8<br />
• Engineering builds on science.<br />
1. Introduction 1.2. What Is Different ? 1.2.4. Domain Theory<br />
1.2.4. Domain Theory<br />
• And science is expressed through theories.<br />
• <strong>Software</strong> engineering, for every specific software (product)<br />
development, builds on usually three sets of theories:<br />
– theories of programming,<br />
– theories of the application domain and<br />
– theories of software development practice & management.<br />
• The example of this paper builds on a programming theory of<br />
formal specification, abstraction, refinement and verification.<br />
• The example itself builds a theory of a transport domain.<br />
• The person we are all honouring with this symposium has<br />
contributed, well, almost established the field of software<br />
development practice & management.<br />
c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> April 1, 2011, 12:27
1. Introduction 1.2. What Is Different ? 1.2.4. Domain Theory<br />
• The example of this paper does not really present a theory.<br />
• It primarily lays a foundation for such a theory.<br />
• A theory, in the sense as we shall mean it,<br />
– presents a set of axioms,<br />
– some proof rules, and<br />
– a set of theorems<br />
– that can then be proven.<br />
• The proof rules are those of the specification language.<br />
• The axioms is pretty much all the formulas<br />
(from Item 1 on page 27 to Item 27 on page 49)<br />
that we have written down — plus much more.<br />
• We need to express (and prove) far more theorems.<br />
April 1, 2011, 12:27 <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark<br />
9
10 1. Introduction 1.3. Relation to Other Work on Domains<br />
• The terms<br />
1.3. Relation to Other Work on Domains<br />
– ‘domain analysis’,<br />
– ‘domain specific languages’ and<br />
– ‘domain engineering’<br />
are used,<br />
– by different authors,<br />
– in different contexts, and hence<br />
– with different meanings.<br />
c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> April 1, 2011, 12:27
1. Introduction 1.3. Relation to Other Work on Domains 1.3.1. Domain Analysis<br />
1.3.1. Domain Analysis<br />
1.3.1.1. An Information Science Viewpoint:<br />
Hjørland & Albrechtsen suggested domain-analysis as a new paradigm for Library<br />
and Information Science (LIS):<br />
• ‘The domain-analytic paradigm’ is a theoretical approach to Information<br />
Science (IS),<br />
• which states, that the best way to understand information in LIS<br />
• is to study the knowledge-domains as ‘discourse communities’, which are<br />
parts of the society’s division of labor.<br />
• Knowledge organization, structure, co-operation patterns, language and<br />
communication forms, information systems and relevance criteria are<br />
reflections of the objects of the work of these communities and of their role<br />
in society.<br />
• The individual person’s psychology, knowledge, information needs, and<br />
subjective relevance criteria should be seen in this perspective.<br />
April 1, 2011, 12:27 <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark<br />
11
12 1. Introduction 1.3. Relation to Other Work on Domains 1.3.1. Domain Analysis 1.3.1.1. An Information Science Viewpoint:<br />
Our understanding of ‘domain analysis’ is less ambitious.<br />
• Our approach is involved in ‘discourse communities’, we refer to<br />
them as domain stake-holders.<br />
• Such terms as ‘knowledge organization, structure, co-operation<br />
patterns, language and communication forms, information<br />
systems and relevance criteria are here reformulated into simple<br />
entities, actions, events and behaviours.<br />
• We do not consider ‘the individual person’s psychology,<br />
knowledge, information needs, and subjective relevance<br />
criteria’.<br />
c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> April 1, 2011, 12:27
1. Introduction 1.3. Relation to Other Work on Domains 1.3.1. Domain Analysis 1.3.1.1. An Information Science Viewpoint:<br />
• Our approach to ‘domain analysis’ is to create a model for a<br />
domain,<br />
– a model from which we can “derive” computable requirements,<br />
– a model which we can formalise in order to prove properties, and<br />
– in general, in order to create a domain theory.<br />
• We seek to describe only that in the domain which can be<br />
objectively “measured” and hence modelled mathematically.<br />
• Our technical approach thus appears to be quite different from that<br />
of Hjørland & Albrechtsen .<br />
April 1, 2011, 12:27 <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark<br />
13
14<br />
1. Introduction 1.3. Relation to Other Work on Domains 1.3.1. Domain Analysis 1.3.1.2. A More Conventional <strong>Software</strong> Engineering Viewpoint<br />
1.3.1.2. A More Conventional <strong>Software</strong> Engineering Viewpoint<br />
• The more conventional understanding of domain analysis is in<br />
connection with software product line R&D.<br />
– In [Champeaux et al.: Chap. 13: Domain Analysis, 1993],<br />
– in various papers by D. Batory and his colleagues,<br />
– and in The FODA Report: Feature Oriented Domain Analysis [Kang et al.,<br />
1990],<br />
• domain analysis is basically restricted<br />
– to consider only feature modelling<br />
– for a class of potential products (a product line),<br />
– and is hence bound to considerations of requirements and software design.<br />
• To us, domain analysis goes well beyond those concerns,<br />
– it is not restricted to be aimed at requirements and software design<br />
subsequent to domain description, but<br />
– stands alone and can be concerned with just understanding the domain, free<br />
from any concerns of IT.<br />
c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> April 1, 2011, 12:27
1. Introduction 1.3. Relation to Other Work on Domains 1.3.2. Domain Specific Languages<br />
1.3.2. Domain Specific Languages<br />
• ‘Domain specific languages’ (DSL) [M.Fowler: DSLs, 2010]<br />
– usually are programming (less often specification) languages<br />
– tailored for a very specific domain.<br />
– And usually one can program “whole” applications within such a<br />
DSL.<br />
– Thus DSLs are typically so-called “executable” and lack<br />
abstraction, refinement and proof systems.<br />
– We are not concerned with DSLs in this paper.<br />
• “Our” DSL is that of RAISE [RaiseMethod] formal Specification<br />
Language, RSL [RSL].<br />
– It allows abstraction,<br />
– facilitates refinements and<br />
– permits proofs.<br />
April 1, 2011, 12:27 <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark<br />
15
16<br />
1. Introduction 1.3. Relation to Other Work on Domains 1.3.2. Domain Specific Languages<br />
• The domain of RAISE includes<br />
– software development in general and<br />
– quite a number of real-life, also man-made universes of discourse.<br />
• But RAISE is not “universal”.<br />
– In fact, none of the leading formal specification languages<br />
(including RSL) can cope with<br />
∗ all facets of all possible software developments, but it can with<br />
quite a few, nor with<br />
∗ all observable phenomena of all domains, but again it can<br />
handle quite a few.<br />
– What, then, to do for cases where a DSL fails.<br />
– Well, as for DSLs (cf. [M.Fowler: DSLs, 2010]), one combine two<br />
or more DSLs.<br />
c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> April 1, 2011, 12:27
1. Introduction 1.3. Relation to Other Work on Domains 1.3.2. Domain Specific Languages<br />
• Besides RSL there are other formal specification languages, some<br />
leading ones are:<br />
–Alloy,<br />
–CafeOBJ,<br />
–CASL,<br />
–B, Event B,<br />
–VDM and<br />
–Z.<br />
• These are then to be used jointly with one or more of, for example:<br />
–DC,<br />
–Timed Automata,<br />
–MSC,<br />
–Petri nets,<br />
–Statechart and<br />
–TLA+.<br />
April 1, 2011, 12:27 <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark<br />
17
18<br />
1. Introduction 1.3. Relation to Other Work on Domains 1.3.3. Domain Engineering<br />
1.3.3. Domain Engineering<br />
• The term ‘domain engineering’ is commonly used synonymously<br />
with ‘software product line engineering’.<br />
• Our use of the term may not be that fortunate:<br />
– perhaps we should rather use the term ‘domain analysis and<br />
description engineering’.<br />
c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> April 1, 2011, 12:27
1. Introduction 1.3. Relation to Other Work on Domains 1.3.3. Domain Engineering<br />
• The distinguishing point between the ‘software product line<br />
engineering’ term and our use of the term ‘domain engineering’ is<br />
the following:<br />
– The ‘product line’ term refers to a usage<br />
∗ where domain analysis<br />
· (usually informal,<br />
· but except for its “tie-in” to software feature analysis,<br />
· like ours)<br />
is but part of the meaning of the ‘product line’ term.<br />
∗ The “larger” meaning of the ‘product line’ term<br />
∗ is that domain analysis plays a rôle,<br />
∗ but the goal is software versions.<br />
April 1, 2011, 12:27 <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark<br />
19
20<br />
1. Introduction 1.3. Relation to Other Work on Domains 1.3.3. Domain Engineering<br />
– Our use of the term ‘domain engineering’<br />
∗ does not necessarily entail software;<br />
∗ we are focused only on the domain;<br />
∗ we entertain no considerations of software features;<br />
∗ we wish to establish, independent of software, a theory of the<br />
domain being considered.<br />
– But, as a derivative from domain engineering comes the<br />
possibility of “deriving” requirements.<br />
– In [Domains: Their Simulation, Monitoring and Control] we<br />
show how a single domain description can be the basis for a wide<br />
software product line.<br />
∗ In this sense the two interpretations of ‘domain engineering’<br />
converge.<br />
c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> April 1, 2011, 12:27
1. Introduction 1.4. Structure of This Talk<br />
1.4. Structure of This Talk<br />
1.4.1. General<br />
• We overview the Triptych model of software development (first<br />
part of Sect. 2), that is we highlight some, but far from all, aspects<br />
of<br />
– domain engineering (Sect. 2.1) and<br />
– requirements engineering (Sect. 2.2).<br />
– We omit detailed consideration of software design (Sect. 2.3).<br />
• Then we relate the Triptych approach to the “Two Rights”<br />
formulated in [Boehm81].<br />
April 1, 2011, 12:27 <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark<br />
21
22 1. Introduction 1.4. Structure of This Talk 1.4.2. Rôle of The Example<br />
1.4.2. Rôle of The Example<br />
• In connection with the brief summarisations of<br />
– domain and<br />
– requirements<br />
engineering<br />
• we bring the rather large example.<br />
– Without a reasonably “substantial” example our brief summaries<br />
would be mere postulates.<br />
– With the example we can now better see<br />
∗ how a not insignificant number of domain description and requirements<br />
prescription development principles and techniques<br />
∗ warrant a far more detailed understanding of software engineering process<br />
models [Spiral-Model-Boehm-1988].<br />
c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> April 1, 2011, 12:27
2. Introduction<br />
2. An Example of Triptych <strong>Software</strong> Development<br />
• Before software can be designed<br />
– one must have a solid grasp<br />
– of its requirements.<br />
• Before requirements can be precisely prescribed<br />
– one must have a solid grasp<br />
– of the [application] domain.<br />
• The Triptych model of software development hence evolves<br />
around<br />
– a phase of domain engineering,<br />
– a phase of requirements engineering and<br />
– a phase of software design —<br />
• properly reiterated while incrementing scopes and spans.<br />
April 1, 2011, 12:27 <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark<br />
23
24<br />
2. An Example of Triptych <strong>Software</strong> Development 2.1. Domain Engineering<br />
2.1. Domain Engineering<br />
2.1.1. Business Processes<br />
• The business processes of transport nets include:<br />
– (1) transport: vehicles entering and leaving the net at any hub<br />
or along any link and moving along routes seen as sequences of<br />
links and hubs;<br />
– (2) the maintenance, extension and reduction of nets through<br />
insertions and removals of hubs and links;<br />
– etcetera.<br />
• Telling a careful “story” here<br />
– is a good entry<br />
– to the more stringent domain descriptions to follow.<br />
• We later follow-up on BPE by BPR: business process<br />
re-engineering.<br />
c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> April 1, 2011, 12:27
2. An Example of Triptych <strong>Software</strong> Development 2.1. Domain Engineering 2.1.2. Domain Description<br />
2.1.2. Domain Description<br />
• The core part of the domain engineering of an application area is<br />
the description of the domain.<br />
• A domain description tells us the facts of the domain —<br />
– of what can be objectively observed<br />
(by human senses and physical apparati):<br />
∗ simple entities,<br />
∗ actions,<br />
∗ events and<br />
∗ behaviours.<br />
April 1, 2011, 12:27 <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark<br />
25
26<br />
2. An Example of Triptych <strong>Software</strong> Development 2.1. Domain Engineering 2.1.2. Domain Description<br />
• A domain description tells us of<br />
– what the domain is, seen from certain points of view,<br />
– without any reference to software for that domain<br />
– let alone requirements to such software.<br />
• A domain description is a specification of the domain<br />
modulo any requirements.<br />
• Let us exemplify fragments of descriptions for a domain of<br />
transport nets.<br />
c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> April 1, 2011, 12:27
2. An Example of Triptych <strong>Software</strong> Development 2.1. Domain Engineering 2.1.3. Simple Entities<br />
2.1.3. Simple Entities<br />
The basic simple entities of transport nets are their hubs<br />
(intersections, stations, airports, harbours) and links (road segments,<br />
rail tracks, air lanes and sea lanes, respectively).<br />
1. There are net, hubs and links<br />
2. From a net one can observe a set of<br />
one or more hubs and zero or more<br />
links.<br />
Hubs and links are sub-entities of composite nets.<br />
type<br />
1. N, H, L<br />
value<br />
2. ωHs: N → H-set, ωLs: N → L-set<br />
April 1, 2011, 12:27 <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark<br />
27
28<br />
2. An Example of Triptych <strong>Software</strong> Development 2.1. Domain Engineering 2.1.3. Simple Entities 2.1.3.1. Unique Entity Identifiers:<br />
2.1.3.1. Unique Entity Identifiers:<br />
In order to identify how hubs and links are composed into nets we<br />
introduce the abstract concepts of unique hub and link identifiers.<br />
3. Hubs and links have unique and<br />
distinct identifiers.<br />
type<br />
3. HI, LI<br />
value<br />
3. ωHI: H → HI, ωLI: L → LI<br />
c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> April 1, 2011, 12:27
2. An Example of Triptych <strong>Software</strong> Development 2.1. Domain Engineering 2.1.3. Simple Entities 2.1.3.2. Mereology:<br />
2.1.3.2. Mereology:<br />
The mereology of composite simple entities such as nets explains how<br />
its sub-entities are composed.<br />
4. From hub one can observe the<br />
identifiers of the zero or more links to<br />
which it is connected.<br />
5. From a link one can observe the<br />
identifiers of the two hubs that the<br />
link connects.<br />
6. Hubs and links so referenced in links<br />
and hubs are indeed hubs and links of<br />
the net.<br />
value<br />
4. ωLIs: H → LI-set<br />
5. ωHIs: L → HI-set<br />
axiom<br />
6. ∀ n:N,h:H,l:L•h ∈ ωHs(n)∧l ∈ ωLs(n) ⇒<br />
6. let lis=ωLIs(h),his=ωHIs(l) in<br />
6. card his = 2 ∧<br />
6. ∀ li:LI•li ∈ lis ⇒<br />
6. ∃ h ′<br />
:H • h ′<br />
∈ ωHs(n)∧ωHI(h ′<br />
)=li∧<br />
6. ∀ hi:HI•hi ∈ his ⇒<br />
6. ∃ l ′<br />
:L • l ′<br />
∈ ωLs(n)∧ωLI(l ′<br />
)=hi<br />
6. end<br />
April 1, 2011, 12:27 <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark<br />
29
30<br />
2. An Example of Triptych <strong>Software</strong> Development 2.1. Domain Engineering 2.1.3. Simple Entities 2.1.3.3. Simple Entity Attributes:<br />
2.1.3.3. Simple Entity Attributes:<br />
Entities have attributes. These are properties. Essential properties<br />
cannot be “removed” from an entity of a certain kind without<br />
destroying its being an entity of that kind. Inessential properties<br />
can be so ‘removed’ without such a ‘destruction’.<br />
7. Nets have geographical area of<br />
location, names, owners and so on,<br />
attributes.<br />
8. Hubs 1 have geographical location,<br />
length, name, and so on, attributes.<br />
9. Links 2 have geographical locations,<br />
name, and so on, attributes.<br />
1 besides unique identification and the identification of its connected links<br />
2 besides unique identification and the identification of its connected hubs<br />
type<br />
7. Area, Name, Owner, ...<br />
8. Loc, Len, Name, ...<br />
9. Loc, Name, ...<br />
value<br />
7. ωArea: N → Area, ...<br />
8. ωLoc: H → Loc ...<br />
9. ωLocL: L → Loc ∗ , ...<br />
c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> April 1, 2011, 12:27
2. An Example of Triptych <strong>Software</strong> Development 2.1. Domain Engineering 2.1.3. Simple Entities 2.1.3.4. States:<br />
2.1.3.4. States:<br />
The domain describer chooses a suitable subset of simple entities to<br />
serve a notion of state. Nets form an important state-notion. With<br />
hubs and links we associate observable state attributes.<br />
10. A hub (h) state, hσ, is a set of pairs of link<br />
identifiers (each pair (li, lj) stands for the<br />
ability to move from link li to link lj, where it<br />
is assumed that {li, lj, . . .} ⊆obs LIs(h)).<br />
11. A link (l) state, lσ, is a set of zero, one or two<br />
pairs of hub identifiers (each pair (hm, ln)<br />
stands for the ability to move on link l from<br />
hub hm to hub hn, where it is assumed that<br />
{hm, hn} =obs HIs(l)).<br />
12. A hub (h) state space, hω, is the set of hub<br />
states that a hub may take on.<br />
13. A link (l) state space, lω, is the set of hub<br />
states that a link may take on.<br />
type<br />
10. HΣ = (LI×LI)-set<br />
11. LΣ = (HI×HI)-set<br />
12. HΩ = HΣ-set<br />
13. LΩ = LΣ-set<br />
value<br />
10. ωHΣ: H ⇒HΣ<br />
11. ωLΣ: H ⇒HΣ<br />
12. ωHΩ: H ⇒HΩ<br />
13. ωLΩ: H ⇒HΩ<br />
axiom<br />
12. ∀ h:H •ωHΣ(h)∈ωHΩ(h)<br />
13. ∀ l:L •ωLΣ(l)∈ωLΩ(l)<br />
April 1, 2011, 12:27 <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark<br />
31
32<br />
2. An Example of Triptych <strong>Software</strong> Development 2.1. Domain Engineering 2.1.4. Actions<br />
2.1.4. Actions<br />
Actions occur. An action potentially changes a state.<br />
14. Nets are [de-]constructed from new<br />
net, insert and remove hub and insert<br />
and remove link actions.<br />
15. An insert hub (or link) action can be<br />
designated by providing a “fresh” hub<br />
(or link) with suitable unique identifier<br />
properties.<br />
16. A remove hub (or link) action can be<br />
designated by providing a suitable<br />
unique identifier.<br />
17. Insert and remove actions are<br />
commensurate with the net: the hub<br />
and link are new; so are their<br />
identifiers; inserted hubs are not<br />
connected, inserted links are<br />
connected.<br />
c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> April 1, 2011, 12:27
2. An Example of Triptych <strong>Software</strong> Development 2.1. Domain Engineering 2.1.4. Actions<br />
type<br />
value<br />
14. ActDes = iH | rH | iL | rL xtr LIs: N → LI-set, xtr HIs: N → HI-set<br />
15. iH :: H<br />
xtr LIs(n) ≡ {ωLI(l)|l:L<br />
16. rH :: HI<br />
15. iL :: L<br />
16. rL :: LI<br />
axiom<br />
17. ∀ n:N,iH(h),rH(hi),iL(l),rl(li):ActDes ⇒<br />
17. h ∈ ωHs(n) ∧ l ∈ ωLs(n) ∧<br />
17. hi ∈ xtr HIs(n) ∧ li ∈ xtr LIs(n)<br />
17. ωLIs(h)={} ∧ ωHIs(l)⊆xtr HIs(n)<br />
•l ∈ ωLs(n)}<br />
xtr HIs(n) ≡ {ωHI(h)|h:H•h ∈ ωHs(n)}<br />
get H: HI → N ∼ → H,get L: LI → N ∼ → L<br />
get H(hi)(n) ≡<br />
let h:H•h ∈ ωHs(n) •hi=ωHI(h) in h end<br />
pre: ∃ h:H•h ∈ ωHs(n) •hi=ωHI(h)<br />
get L(li)(n) ≡<br />
let l:L•l ∈ ωLs(n) •li=ωLI(l) in l end<br />
pre: ∃ l:L•l ∈ ωLs(n) •li=ωLI(l)<br />
April 1, 2011, 12:27 <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark<br />
33
34<br />
2. An Example of Triptych <strong>Software</strong> Development 2.1. Domain Engineering 2.1.4. Actions<br />
The following action specifications should be “obvious”:<br />
value<br />
newN: Unit → N<br />
newN() as n<br />
post (ωHs,ωLs)(n)=({},{})<br />
emptyN: N → Bool<br />
emptyN(n) ≡ (ωHs,ωLs)(n)=({},{})<br />
insertH: iH → N ∼ → N<br />
insertH(iH(h))(n) as n ′<br />
pre iH(h): axiom 17.<br />
post ωHs(n)=ωHs(n ′<br />
) ∪ {h} ∧<br />
ωLs(n)=ωLs(n ′<br />
)<br />
removeH: rH → N ∼ → N<br />
removeH(rH(hi))(n) as n ′<br />
pre iH(hi): axiom 17.<br />
post ωLIs(get HI(hi)(n))={} ∧<br />
ωHs(n ′<br />
)=ωHs(n)\{get HI(hi)(n)}<br />
18. The above action definitions can be proven to result in nets that<br />
satisfy previously stated axioms.<br />
theorem:<br />
18. ∀ n:N,h:H,hi:HI•h∈ ωHs(n)∧hi=ωHI(h)<br />
18. ⇒ removeH(rH(hi))(insertH(iH(h))(n))=n<br />
c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> April 1, 2011, 12:27
2. An Example of Triptych <strong>Software</strong> Development 2.1. Domain Engineering 2.1.5. Events<br />
2.1.5. Events<br />
• A domain event can be characterised<br />
– a time or a time interval (“the” time [interval] of the event),<br />
– a pair of states of the domain: just before and right after the<br />
event, and<br />
– a predicate over time and the state pair.<br />
• Examples of transport events could be:<br />
– a mud slide covering a link or a hub and<br />
– a vehicle veering off a link.<br />
• We shall omit more detailed descriptions, including formalisations,<br />
of events in this paper.<br />
April 1, 2011, 12:27 <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark<br />
35
36<br />
2. An Example of Triptych <strong>Software</strong> Development 2.1. Domain Engineering 2.1.6. Behaviours<br />
2.1.6. Behaviours<br />
• Behaviours are sets of sequences of actions, events or behaviours.<br />
• Our example shall model such sequences by a function from time to<br />
states of nets and positions of vehicles on the net.<br />
19. Vehicle traffic<br />
(a) There are vehicles and there is time.<br />
(b) Vehicles are positioned at hubs<br />
(c) or fractions down links.<br />
(d) Vehicles either do not move or move<br />
monotonically.<br />
(e) Vehicles may leave or enter the net.<br />
type<br />
19(a). V, T<br />
19(b). VP == atH(hi:HI)|onL(fhi:HI,f:F,li:LI,thi:HI)<br />
19(c). F = Real axiom 0≤f≤1<br />
19(d). TF = T → (N × (V →m VP))<br />
19(e). etcereta.<br />
c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> April 1, 2011, 12:27
2. An Example of Triptych <strong>Software</strong> Development 2.1. Domain Engineering 2.1.7. Discussion<br />
2.1.7. Discussion<br />
• We have hinted at what a domain description contains and what it<br />
might look like.<br />
• Our descriptions form pairs of narratives and formalisations.<br />
• The narrative is what the stake-holders read and validate.<br />
• The formalisations should fit, “hand-in-glove”, the narratives.<br />
• The formalisations are what the domain engineers construct<br />
‘hand-in-hand’ with constructing the narratives.<br />
• Requirements engineers read and transform domain descriptions.<br />
April 1, 2011, 12:27 <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark<br />
37
38<br />
2. An Example of Triptych <strong>Software</strong> Development 2.2. Requirements Engineering<br />
2.2. Requirements Engineering<br />
2.2.1. The Machine = Hardware + <strong>Software</strong><br />
• By ‘the machine’ we shall understand the<br />
– software to be developed and<br />
– hardware (equipment + base software) to be configured<br />
• for the domain application.<br />
c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> April 1, 2011, 12:27
2. An Example of Triptych <strong>Software</strong> Development 2.2. Requirements Engineering 2.2.2. Requirements Prescription<br />
2.2.2. Requirements Prescription<br />
• The core part of the requirements engineering of a computing<br />
application is the requirements prescription.<br />
– A requirements prescription tells us which parts of the domain<br />
are to be supported by ‘the machine’.<br />
– A requirements is to satisfy some goals.<br />
– Usually the goals cannot be prescribed in such a manner that<br />
they can served directly as a basis for software design.<br />
– Instead we derive the requirements from the domain descriptions<br />
and then argue (incl. prove) that the goals satisfy the<br />
requirements.<br />
– In this talk we shall not show the latter but shall show the<br />
former.<br />
April 1, 2011, 12:27 <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark<br />
39
40<br />
2. An Example of Triptych <strong>Software</strong> Development 2.2. Requirements Engineering 2.2.3. A Suitable Decomposition of the Requirements Prescription<br />
2.2.3. A Suitable Decomposition of the Requirements Prescription<br />
• We consider three forms of requirements prescription:<br />
– the domain requirements,<br />
– the interface requirements and<br />
– the machine requirements.<br />
• Recall that the machine is the hardware and software (to be<br />
required).<br />
– Domain requirements are those whose technical terms are from<br />
the domain only.<br />
– Machine requirements are those whose technical terms are from<br />
the machine only.<br />
– Interface requirements are those whose technical terms are from<br />
both.<br />
c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> April 1, 2011, 12:27
2. An Example of Triptych <strong>Software</strong> Development 2.2. Requirements Engineering 2.2.4. An Aside on Our Example<br />
2.2.4. An Aside on Our Example<br />
• We shall continue our “ongoing” example.<br />
• Our requirements is for a toll-road system.<br />
• The goals of having a toll-road system are:<br />
– to decrease transport times between selected hubs of a general<br />
net; and<br />
– to decrease traffic accidents and fatalities while moving on the<br />
toll-road net as compared to comparable movements on the<br />
general net.<br />
April 1, 2011, 12:27 <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark<br />
41
42<br />
2. An Example of Triptych <strong>Software</strong> Development 2.2. Requirements Engineering 2.2.4. An Aside on Our Example<br />
• The toll-road net, however, must be paid for by its users.<br />
– Therefore toll-road net entries and exits occur at toll-road plazas<br />
– with these plazas containing entry and exit toll-booths<br />
– where tickets can be issued, respectively collected and travel paid<br />
for.<br />
• We shall very briefly touch upon these toll-booths, in the Extension<br />
part (as from Slide 53) below.<br />
• So all the other parts of the next section (Sect. on page 44) serve<br />
to build up to the Extension part.<br />
c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> April 1, 2011, 12:27
2. An Example of Triptych <strong>Software</strong> Development 2.2. Requirements Engineering 2.2.5. Business Process Re-engineering (BPR)<br />
2.2.5. Business Process Re-engineering (BPR)<br />
• Before embarking on the detailed elaboration of requirements<br />
– it is advised that a thorough, rough-sketching of the<br />
re-engineering of the business processes take place.<br />
– We refer to our earlier mentioning of business processes.<br />
– Our example focus on following up on Item (1) of BPE:<br />
∗ A toll-road system is a special net consisting of a linear sequence of toll-road<br />
links separated by toll-road hubs.<br />
∗ Vehicles gain access to these hubs and links by entering (and leaving) the<br />
toll-road net at toll plazas, through entry (respectively exit) booths<br />
connected to the toll-road hubs by plaza to toll-road hub hubs.<br />
∗ Vehicles collect tickets upon entering the toll-road net.<br />
∗ Vehicles move around the toll-road hubs and links.<br />
∗ And vehicles return tickets and pay for using the toll-road net upon leaving<br />
that net.<br />
April 1, 2011, 12:27 <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark<br />
43
44<br />
2. An Example of Triptych <strong>Software</strong> Development 2.2. Requirements Engineering 2.2.6. Domain Requirements<br />
2.2.6. Domain Requirements<br />
• Domain requirements cover all those aspects of the domain —<br />
– simple entities,<br />
– actions,<br />
– events and<br />
– behaviours —<br />
• which are to be supported by ‘the machine’.<br />
c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> April 1, 2011, 12:27
2. An Example of Triptych <strong>Software</strong> Development 2.2. Requirements Engineering 2.2.6. Domain Requirements<br />
• Thus domain requirements are developed by systematically<br />
“revising” cum “editing” the domain description:<br />
– which parts are to be projected: left in or out;<br />
– which general descriptions are to be instantiated into more<br />
specific ones;<br />
– which non-deterministic properties are to be made more<br />
determinate; and<br />
– which parts are to be extended with such computable domain<br />
description parts which are not feasible without IT.<br />
April 1, 2011, 12:27 <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark<br />
45
46 2. An Example of Triptych <strong>Software</strong> Development 2.2. Requirements Engineering 2.2.6. Domain Requirements 2.2.6.1. The Domain to Domain Requirements Operations<br />
2.2.6.1. The Domain to Domain Requirements Operations<br />
• Projection, instantiation, determination and extension are the basic<br />
engineering tasks of domain requirements engineering.<br />
• An example may best illustrate what is at stake.<br />
• The example is that of a toll-way system — in contrast to the<br />
general nets covered by description Items 1–19(e).<br />
• See Fig. 1.<br />
c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> April 1, 2011, 12:27
2. An Example of Triptych <strong>Software</strong> Development 2.2. Requirements Engineering 2.2.6. Domain Requirements 2.2.6.1. The Domain to Domain Requirements Operations<br />
links<br />
hubs<br />
General Net<br />
plaza<br />
to<br />
plaza<br />
hub<br />
toll−way<br />
p1 links p2 p3<br />
p7 p8<br />
.....<br />
.....<br />
h1 h2 h4 h7 h8<br />
"twinned" toll−way hub<br />
toll−way links<br />
Toll−way Net<br />
Figure 1: General and Toll-way Nets<br />
April 1, 2011, 12:27 <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark<br />
47
48<br />
2. An Example of Triptych <strong>Software</strong> Development 2.2. Requirements Engineering 2.2.6. Domain Requirements 2.2.6.2. Projection<br />
2.2.6.2. Projection<br />
We keep what is needed to prescribe the toll-road system and leave<br />
out the rest.<br />
20. We keep the description, narrative and<br />
formalisation,<br />
(a) nets, hubs, links,<br />
(b) hub and link identifiers,<br />
(c) hub and link states,<br />
21. as well as related observer functions.<br />
type<br />
20(a). N, H, L<br />
20(b). HI, LI<br />
20(c). HΣ, LΣ<br />
value<br />
21. ωHs,ωLs,ωHI,ωLI,<br />
21. ωHIs,ωLIs,ωHΣ,ωL Σ<br />
c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> April 1, 2011, 12:27
2. An Example of Triptych <strong>Software</strong> Development 2.2. Requirements Engineering 2.2.6. Domain Requirements 2.2.6.3. Instantiation<br />
2.2.6.3. Instantiation<br />
• From the general net model of earlier formalisations<br />
• we instantiate the toll-way net model now described.<br />
22. The net is now concretely modelled as<br />
a pair of sequences.<br />
23. <strong>On</strong>e sequence models the plaza hubs,<br />
their plaza-to-toll-way link and the<br />
connected toll-way hub.<br />
24. The other sequence models the pairs<br />
of “twinned” toll-way links.<br />
25. From plaza hubs one can observe their<br />
hubs and the identifiers of these hubs.<br />
26. The former sequence is of m such<br />
plaza “complexes” where m ≥ 2; the<br />
latter sequence is of m − 1 “twinned”<br />
links.<br />
27. From a toll-way net one can abstract a<br />
proper net.<br />
28. <strong>On</strong>e can show that the posited<br />
abstraction function yields well-formed<br />
nets, i.e., nets which satisfy previously<br />
stated axioms.<br />
April 1, 2011, 12:27 <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark<br />
49
50<br />
2. An Example of Triptych <strong>Software</strong> Development 2.2. Requirements Engineering 2.2.6. Domain Requirements 2.2.6.3. Instantiation<br />
type<br />
22. TWN = PC ∗ × TL ∗<br />
23. PC = PH × L × H<br />
24. TL = L × L<br />
value<br />
23. ωH: PH → H, ωHI: PH → HI<br />
axiom<br />
26. ∀ (pcl,tll):TWN •<br />
26. 2≤len pcl∧len pcl=len tll+1<br />
value<br />
27. abs N: TWN → N<br />
27. abs N(pcl,tll) as n<br />
27. pre: wf TWN(pcl,tll)<br />
27. post:<br />
27. ωHs(n) =<br />
27. {h,h ′ |(h, ,h ′ ):PC •(h, ,h ′ )∈ elems pcl} ∧<br />
27. ωLs(n) =<br />
27. {l|( ,l, ):PC •( ,l, )∈ elems pcl} ∪<br />
27. {l,l ′ |(l,l ′ ):TL •(l,l ′ )∈ elems tll}<br />
theorem:<br />
28. ∀ twn:TWN • wf TWN(twn) ⇒ wf N(abs N(twn))<br />
c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> April 1, 2011, 12:27
51<br />
2. An Example of Triptych <strong>Software</strong> Development 2.2. Requirements Engineering 2.2.6. Domain Requirements 2.2.6.3. Instantiation 2.2.6.3.1 Model Well-formedness wrt. Instantiation<br />
2.2.6.3.1. • Model Well-formedness wrt. Instantiation•<br />
• Instantiation restricts general nets to toll-way nets.<br />
• Well-formedness deals with proper mereology: that observed<br />
identifier references are proper.<br />
• We shall omit showing a formalisation of well-formedness.<br />
April 1, 2011, 12:27 <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark
52<br />
2. An Example of Triptych <strong>Software</strong> Development 2.2. Requirements Engineering 2.2.6. Domain Requirements 2.2.6.4. Determination<br />
2.2.6.4. Determination<br />
• Determination, in this example, fixes states of hubs and links.<br />
• The state sets contain only one set.<br />
– Twinned toll-way links allow traffic only in opposite directions.<br />
– Plaza to toll-way hubs allow traffic in both directions.<br />
– Toll-way hubs allow traffic to flow freely from<br />
∗ plaza to toll-way links<br />
∗ and from incoming toll-way links<br />
∗ to outgoing toll-way links<br />
∗ and toll-way to plaza links.<br />
• We omit formalisation.<br />
c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> April 1, 2011, 12:27
2. An Example of Triptych <strong>Software</strong> Development 2.2. Requirements Engineering 2.2.6. Domain Requirements 2.2.6.5. Extension<br />
2.2.6.5. Extension<br />
• For our example we choose to consider the toll plazas.<br />
• A toll plaza,<br />
– in addition to its hub,<br />
– also contains vehicle<br />
∗ entry and<br />
∗ exit<br />
booths.<br />
• We refer to Fig. 2 on the next page.<br />
April 1, 2011, 12:27 <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark<br />
53
54<br />
2. An Example of Triptych <strong>Software</strong> Development 2.2. Requirements Engineering 2.2.6. Domain Requirements 2.2.6.5. Extension<br />
Vehicle<br />
Direction<br />
Ticket Dispensor<br />
Entry Booth<br />
Exit Gate<br />
Entry Booth<br />
Exit Booth<br />
Enter Sensor Exit Sensor<br />
Car<br />
Entry Booth<br />
Exit Sensor<br />
Exit<br />
Booth<br />
Entry<br />
Booth<br />
Car<br />
Exit Booth<br />
Enter Sensor<br />
Figure 2: Entry and Exit Toll Boths<br />
Exit Booth<br />
Exit Gate<br />
Payment Display & Acceptor<br />
Ticket Collector<br />
Vehicle<br />
Direction<br />
c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> April 1, 2011, 12:27
2. An Example of Triptych <strong>Software</strong> Development 2.2. Requirements Engineering 2.2.6. Domain Requirements 2.2.6.5. Extension<br />
• Surely the mechatronics of toll-booths warrants a detailed<br />
prescription;<br />
– it is therefore, with regret, that we omit such a prescription.<br />
– The “bare-bones” of a plausible prescription would take up an<br />
additional four pages of narratives and formalisation.<br />
– So we refrain.<br />
– Instead we refer to [Olderog & Dirks 2008] for a convincing story<br />
on how to domain model and develop provably correct software<br />
for real-time, safety critical embedded systems.<br />
April 1, 2011, 12:27 <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark<br />
55
56<br />
2. An Example of Triptych <strong>Software</strong> Development 2.2. Requirements Engineering 2.2.7. Interface and Machine Requirements<br />
2.2.7. Interface and Machine Requirements<br />
• Interface requirements take into consideration both<br />
– the domain description and<br />
– the machine:<br />
∗ the hardware + base systems software<br />
∗ upon which the software to be designed<br />
is to be implemented.<br />
• So interface requirements are not exclusively “derived” from the<br />
narrated and formalised domain description.<br />
• And the machine requirements<br />
– make hardly any concrete reference to the domain description.<br />
c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> April 1, 2011, 12:27
2. An Example of Triptych <strong>Software</strong> Development 2.3. <strong>Software</strong> Design<br />
2.3. <strong>Software</strong> Design<br />
• We shall likewise omit any serious coverage of the software design<br />
process — except for these remarks:<br />
– As the domain description serves as a model for the development<br />
of the requirements development,<br />
– so do the requirements prescription serve as a model for software<br />
design; that is,<br />
– our whole software development is model-oriented.<br />
April 1, 2011, 12:27 <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark<br />
57
58<br />
2. An Example of Triptych <strong>Software</strong> Development 2.4. A Summary<br />
2.4. A Summary<br />
• We have over-viewed the Triptych approach to software<br />
development:<br />
– core aspects of domain engineering and<br />
– core aspects of requirements.<br />
• The conclusions that one may be able to draw from the example —<br />
– or at least a reasonable small number of such examples —<br />
are<br />
– that domains can be described, informally as well as formally;<br />
– that domain requirements can be systematically (but not<br />
automatically) “derived” from domain descriptions; and<br />
– that this approach puts requirements engineering in a<br />
rather new light.<br />
c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> April 1, 2011, 12:27
3. An Example of Triptych <strong>Software</strong> Development<br />
3. Relations to Boehm’s Work<br />
• In this section we shall discuss the issue of<br />
– how the Triptych approach secures “the two rights” of<br />
software.<br />
• Barry W. Boehm is often quoted [The2Rights:Boehm1989] as<br />
having expressed:<br />
– “verification is building the product right, and<br />
– validation is building the right product.”<br />
April 1, 2011, 12:27 <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark<br />
59
60<br />
3. Relations to Boehm’s Work 3.1. Correct <strong>Software</strong><br />
3.1. Correct <strong>Software</strong><br />
• The Triptych approach to software correctness is based on the<br />
use of formal specification.<br />
– Ideally, and eventually, one can prove properties of even large<br />
scale software systems.<br />
– This includes proving correctness of software with respect to<br />
requirements.<br />
• Verification proofs<br />
D, S |= R<br />
– show that the <strong>Software</strong> is<br />
– correct with respect to the R<br />
– while making assumptions about the Domain.<br />
c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> April 1, 2011, 12:27
3. Relations to Boehm’s Work 3.1. Correct <strong>Software</strong><br />
• But just the use of formal specification of software helps.<br />
• Then the rigorous “derivation” of<br />
– software designs from requirements, and<br />
– domain requirements from domain descriptions,<br />
• contributes towards “building the product right”.<br />
• The above claims are supported by numerous reports on the<br />
industry-scale use for ‘formal methods’. 3<br />
3 See also: http://www2.imm.dtu.dk/˜db/fm-industry-project-survey/<br />
April 1, 2011, 12:27 <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark<br />
61
62<br />
3. Relations to Boehm’s Work 3.2. The Right <strong>Software</strong><br />
3.2. The Right <strong>Software</strong><br />
• Our approach to getting the right software differs from that of<br />
Boehm’s [Boehm-Lifetime-Achievements-2007].<br />
– It is not sôlely based on validation.<br />
– It is first based on<br />
∗ a careful domain analysis,<br />
∗ resulting in a detailed narrative and formal description,<br />
– and then ending with a likewise careful validation<br />
∗ of that description, by the stake-holders<br />
∗ who, in the first place, provided the “input” to the domain analysis.<br />
• But we claim that Boehm’s coinage<br />
– “verification is building the product right, and<br />
– validation is building the right product”<br />
has been very inspirational and influential.<br />
c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> April 1, 2011, 12:27
3. Relations to Boehm’s Work 3.2. The Right <strong>Software</strong><br />
• The Triptych approach to obtaining the right software is<br />
– ultimately based on its starting the whole development process<br />
– with understanding the domain thoroughly;<br />
– then on “deriving” domain and interface requirements from the<br />
domain description.<br />
• An important aspect of achieving the right software is<br />
– the dual expression of domains and requirements both<br />
– in terms of narratives, i.e., informal specifications,<br />
– and in terms of formalisations:<br />
– ensuring a thorough, deep and comprehensive<br />
∗ understanding of the domain and<br />
∗ of the requirements.<br />
April 1, 2011, 12:27 <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark<br />
63
64<br />
• The repeated use<br />
3. Relations to Boehm’s Work 3.2. The Right <strong>Software</strong><br />
– of both [i.e., informal and formal expression], together, and<br />
– for domains, requirements and software design,<br />
– and across many distinct stake-holder groups<br />
has shown to lead to very low numbers of misunderstandings.<br />
• All this has been experienced in many industry-scale projects since<br />
the early 1990s [UNU-IIST-10-Years].<br />
c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> April 1, 2011, 12:27
3. Relations to Boehm’s Work 3.3. Process Models<br />
3.3. Process Models<br />
• There is a much larger area of SE concern so carefully worked on<br />
by Boehm.<br />
– That area is epitomized<br />
∗ by his books<br />
· [<strong>Software</strong> Engineering Economics 1981]<br />
· [Risk Management 1989]<br />
and<br />
∗ by his project as of late [LeanMBASE 2006].<br />
April 1, 2011, 12:27 <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark<br />
65
66 3. Relations to Boehm’s Work 3.3. Process Models<br />
• Supporting — indeed implied by — the Triptych approach,<br />
– there is a general set of generic process models<br />
[The SE Book Vol.3, Chaps. 16, 24, 30].<br />
• Paired with, for each instance of a domain-specific development, a<br />
[smaller] set of software development graphs<br />
[misc. 1980s papers],<br />
– the generic process models can be instantiated with the software<br />
development graphs,<br />
– to achieve specific practices process models.<br />
c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> April 1, 2011, 12:27
3. Relations to Boehm’s Work 3.3. Process Models<br />
• A [formal] domain, requirements or software specification<br />
– can itself be developed in stages<br />
– and each stage can be understood as a 360 o revolution<br />
– with respect to Boehm’s Spiral Model.<br />
• Assuming a reasonably comprehensive and complete domain model,<br />
– a development into requirements and software design<br />
– which unravels the development, “a bit at a time”, that is,<br />
“spiraling”,<br />
– now makes sense — as has been shown in a number of projects<br />
already in the 1980s and 1990s.<br />
April 1, 2011, 12:27 <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark<br />
67
68<br />
3. Relations to Boehm’s Work 3.3. Process Models<br />
• These spiral process models can now be used by management for<br />
process assessment and improvement.<br />
– The care with which process models are chosen and<br />
deployed as described in the LeanMBASE model .<br />
– including, notably, the intricately laid out pragmatic<br />
concerns: issues, checkpoints, resolutions, etcetera,<br />
– is something that need be considered by Triptych users.<br />
• I have been much inspired and derived several benefits from<br />
Boehm’s work in this area — as witnessed, alas, only to a tiny<br />
extent by [The SE Book Vol.3, Sect. 2.4].<br />
c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> April 1, 2011, 12:27
4. Relations to Boehm’s Work<br />
4. Conclusion<br />
• It seems that the R&D of LeanMBASE<br />
– originally took its departure point in observing how software<br />
engineers performed their tasks<br />
– and then went on to apply empirical evidence and statistically<br />
observable measures<br />
– in monitoring and controlling such developments;<br />
April 1, 2011, 12:27 <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark<br />
69
70<br />
4. Conclusion<br />
• whereas the R&D of Triptych<br />
– originally took its departure point in results from programming<br />
methodology: program specification and verification<br />
– and then went on to apply the academic ideas of programming<br />
methodology to larger and large scale projects,<br />
– ending up, in the case of Triptych, with exactly that:<br />
Triptych.<br />
• A final claim of this talk is then going to be<br />
– that these two diametrically “opposed” and “originating”<br />
approaches<br />
– are now merging into one another.<br />
c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> April 1, 2011, 12:27
4. Conclusion<br />
• Both the LeanMBASE and the Triptych approaches may<br />
appear, to some,<br />
– to only apply to conventional, usually large scale software<br />
systems<br />
– such as compilers, operating systems, military information,<br />
command and control systems, banking systems, air traffic<br />
control systems, etc.<br />
• It is, however, also fully applicable, according to our experience,<br />
also from observation<br />
– of the kind of software development that goes on in about a<br />
dozen software houses started by our students, and now in their<br />
15th–25th year of existence,<br />
– to the development of software that in many aspects can be<br />
characterised as representing “immaterial labour” so aptly<br />
described in [ImmaterialLabor2011].<br />
April 1, 2011, 12:27 <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark<br />
71
72 5. Conclusion<br />
5. Acknowledgements<br />
• I gratefully expresses his thanks to<br />
– Prof. Lu RuQian, Mathematics Institute, CAS, a friend since<br />
1980 (The IFIP Congress in Melbourne, Australia), and<br />
– Prof. Li MingShu, <strong>Software</strong> Institute, CAS, a friend also of<br />
quite a few years<br />
– for enticing him to submit and partially<br />
– supporting him to present this paper.<br />
• I also gratefully acknowledges the tremendous support received<br />
from Prof. Lee Osterweil and the anonymous referees in their<br />
refereeing this paper.<br />
• Final acknowledgements should be given to Barry W. Boehm for<br />
bringing all this about !<br />
c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark <strong>On</strong> <strong>“The</strong> <strong>Right”</strong> <strong>Software</strong> April 1, 2011, 12:27