Computational Artefacts and Software Requirements

Software engineering, as a discipline, could benefit from a more rigorous grounding in epistemology/ ontology, e.g., by referring to the concept of “computational artefact”:

Introducing the Computational Artefact

As we have learned from Kroes [K] a technical artefact (TA) is based on the duality of:

  • physical structure and
  • some agent’s intention, expressed as function in a context.

see also Technical Artefacts and Software Requirements.

So, for our purpose – reflections on software requirements engineering – intended here as a special case of the TA, we define a computational artefact (CA), as the running unit of software and hardware, like an application running on a PC (ignoring all the other apps on the PC) or an embedded system, integrated into an electromechanical device (without the surrounding device).

Starting Small: the Logic Machine

We start with a very basic example of a CA: a logic machine takes various Boolean inputs and computes from it a Boolean output. Therefore, intentionally it implements a function, that can be represented in a truth table, as in the figure below, from the domain (A, B, C) to the codomain R.

truthtable

Truth table: (A, B, C) → R

Physically it is a digital circuit constructed from gates, digital units that perform logical operations, like AND, OR, XOR, etc. Therefore, building the physical artefact from the intentional truth table, becomes a lot easier when we describe the logic of the input by means of a formula. For the above example, this may be:

(A ∧ B) ∨ (B ∧ C)

Summing up, wrt. our aforementioned duality notion, we have:

  • the physical artefact as a digital circuit
  • the intended function as a truth table
  • and ‘in between’, a formula, which accords with the truth table and defines the logical structure of the circuit.

So now, does this formula belong to the intentional and/or the physical side?

Reaching the Edge: is this still Design?

Turner [T] regards the formula as being on the physical side, as the result of the design activity:

“The truth table informs us what to compute; the logical formula tells us how“.

So, the formula describes the logical/mathematical structure of the artefact, that is not physically tangible, but is part of the physical artefact, similar to CAD drawing which enables the simulation of the behaviour of a physical object.

Kroes [K] argues, that such a formula/drawing cannot be intentional:

“But the simulation model does not contain any information about the functional features of the technical artefact, for instance, that the function of the resistance is to transform electric power into heat, or that it ought to produce the amount of power”.

However, what if the intention of the artefact is not physical, but logical? What if we build the logical machine not for the purpose of heating the room, or emptying the battery, but solely for implementing the logic? Would this make the formula a mixed ‘physio-intentional’ (excuse the word) notion? Would it affect the separation of the concerns of analysis and design? And what about computational systems of higher complexity than a logical machine? Have to give it a muse. So, stay tuned.

Opinions welcome,
|=

Goon here: Artefacts of logic Intention

[K] P. Kroes (2012) “Technical Artefacts: Creations of Mind and Matter”
Series: Philosophy of Engineering and Technology (6), Springer Dordrecht
DOI 10.1007/978-94-007-3940-6

[T] R. Turner (2018) “Computational Artifacts (Theory and Applications of Computability)”
Springer Berlin Heidelberg
DOI 10.1007/978-3-662-55565-1

About modelpractice

Modeling Theory and Abstraction Awareness in strive for scientific rigour and relevance to information systems engineering.
This entry was posted in Epistemology, Requirements and tagged , , , , , , , , , , , , , , , . Bookmark the permalink.

5 Responses to Computational Artefacts and Software Requirements

  1. Pingback: Technical Artefacts and Software Requirements | modelpractice

  2. Pingback: Artefacts of logic Intention | modelpractice

  3. Pingback: Artefacts of logic Intention | modelpractice

  4. Pingback: Artefacts in Technical and Social Contexts | modelpractice

  5. Pingback: Modelling the World … | modelpractice

Leave a comment