Difference between revisions of "Adequation"
| Line 3: | Line 3: | ||
In terms of software development, a good object model is characterised by a high degree of adequation between objects in the problem domain (the "things" in reality) and software objects (the models used by the computational intellect). | In terms of software development, a good object model is characterised by a high degree of adequation between objects in the problem domain (the "things" in reality) and software objects (the models used by the computational intellect). | ||
| − | Good object models need to be able to describe all valid states of the problem domain while creating as little opportunity for representing invalid states. Good behavioural models need to restrict state transitions to the valid ones and rule out state transitions that are not possible in reality. | + | Good object models need to be able to describe all valid states of the problem domain while creating as little opportunity for representing invalid states. For relational databases, [[normalisation]] is a process that improves adequation by eliminating redundant storage of data and thereby eliminating states that cannot be consistent with reality. Good behavioural models need to restrict state transitions to the valid ones and rule out state transitions that are not possible in reality. |
| + | |||
| + | Adequation of software is the basis of | ||
| + | * extensibility, because adequate objects can readily be used to build modules for purposes not considered when designing the objects in the first place (because adequation does not depend on specific purposes), | ||
| + | * maintainability, because causes of discrepancies between reality and software structure or behaviour can be identified on a high level of modelling and code updates are necessary in few locations that can be rationally determined, | ||
| + | * scalability, | ||
| + | * usability, because adequation leads to transparent and logical behaviour of software that, over time, appears logical and perhaps even "intuitive" to users. | ||
Revision as of 15:37, 7 April 2010
According to Aquinas, truth is the adequation of a thing to the intellect. Equivalently, truthful understanding amounts to having an adequate mental model of the part of reality which one has understood.
In terms of software development, a good object model is characterised by a high degree of adequation between objects in the problem domain (the "things" in reality) and software objects (the models used by the computational intellect).
Good object models need to be able to describe all valid states of the problem domain while creating as little opportunity for representing invalid states. For relational databases, normalisation is a process that improves adequation by eliminating redundant storage of data and thereby eliminating states that cannot be consistent with reality. Good behavioural models need to restrict state transitions to the valid ones and rule out state transitions that are not possible in reality.
Adequation of software is the basis of
- extensibility, because adequate objects can readily be used to build modules for purposes not considered when designing the objects in the first place (because adequation does not depend on specific purposes),
- maintainability, because causes of discrepancies between reality and software structure or behaviour can be identified on a high level of modelling and code updates are necessary in few locations that can be rationally determined,
- scalability,
- usability, because adequation leads to transparent and logical behaviour of software that, over time, appears logical and perhaps even "intuitive" to users.
