[New-ITS] Complexity Measures

[Thomas Beale]

Tim Benson wrote:
> The real reason why complexity and size matter is that both are 
> positively correlated to the number of implementation errors.  All 
> other things being equal, the numbers of errors are related to both 
> size and complexity.
>
> V3 produces large documents and they are complex to understand; for 
> example the actual meaning of an activityTime may depend on classCode, 
> moodCode, code, status and even value.  
>
> If implementation errors are caught in the testing process, then it 
> simply adds to the costs and delays in implementing, testing and 
> maintaining messages.  If they are not spotted by the test process 
> (and the combinatorial explosion of errors is large), then they may 
> not be identified until patient safety has been jeopardised.
>
> Size and complexity are proxy measures, and what always matters most 
> is to avoid making implementation errors.  That requires 
> specifications which are not mis-understood by the human beings 
> responsible for implementing and using them.  When considering the 
> human-beings, we need to recognise that some stakeholders do 
> understand RBMs and XML, whilst others do not; we need to meet the 
> needs of all stakeholders if we are to reduce implementation errors.
>
> Tim
>
there is a basic quality to all RIM-derived models - they cannot avoid 
being built from the RIM components. This is a bit like looking at the 
assembly language of software  - a really large number of very small 
instructions. Human beings stopped looking at machine language as soon 
as they created higher level formalisms that could be compiled into 
assembler (or not, these days) - because the semantic gap between what 
they wanted to say and what assembler can say was too large. Some questions:
- should we be using an assembly language to express what are clearly 
high-order concepts, when there is clearly a large semantic gap?
- if not, then should we not develop higher order formal languages, and 
use those, and leave the assembly language to be the output of some tool 
(or not....)?
- the complexity of what is being said is not a function of the semantic 
power of the language used to say it - an assembler program and a pascal 
program for sorting say the same thing.
- what we are probably concerned with is different kinds of complexity:
    a) difficulty of direct human authoring and comprehension of 
assembly language artifacts
    b) processing and other resource costs involved in computer 
processing of these artifacts

I submit that currently, the semantic gap between the language of 
expression and the needs of the authors is too great to prevent a number 
of well-known problems that occur in these circumstances, and are 
well-known in computer science for some 40+ years. Any solution 
involving either more models (and acronyms...) or else a more RISC 
approach needs to address this.

- thomas beale