Amoeba Model
From APIDesign
(→Amoeba Model) |
|||
| Line 7: | Line 7: | ||
The [[Amoeba Model]] is one way to imagine the relation between the specification, that is our expectations and the reality. Here is a picture showing our great vision: | The [[Amoeba Model]] is one way to imagine the relation between the specification, that is our expectations and the reality. Here is a picture showing our great vision: | ||
| - | + | [[Image:AmoebaApp.png]] | |
Yes, the visions are always nice. However this does not mean that our users will be satisfied with the quality of what they really get. A good enough specification is just half of what they see. They also need good enough implementation. Any expectations we put into our application can or even are (in ideal state) expressed in our specification, but before they get to the user they have to be implemented in code and it is very likely that the code will not follow the specification fully. There will be differences between the code and the specification. | Yes, the visions are always nice. However this does not mean that our users will be satisfied with the quality of what they really get. A good enough specification is just half of what they see. They also need good enough implementation. Any expectations we put into our application can or even are (in ideal state) expressed in our specification, but before they get to the user they have to be implemented in code and it is very likely that the code will not follow the specification fully. There will be differences between the code and the specification. | ||
| - | + | [[Image:AmoebaActual.png]] | |
The '''amount of the differences''' between our code and our specification '''is the measurement of quality'''. If the final system is not doing what we originally intended it to do, then it is not good enough. Its quality or maybe better term is our confidence in it is lowered with every difference from the expected behaviour. | The '''amount of the differences''' between our code and our specification '''is the measurement of quality'''. If the final system is not doing what we originally intended it to do, then it is not good enough. Its quality or maybe better term is our confidence in it is lowered with every difference from the expected behaviour. | ||
| Line 18: | Line 18: | ||
| - | + | [[Image:AmoebaNext.png]] | |
Over the time, with new and new releases, regressions occur. The functionality of the code is changing, it starts to do new things and alas, it also stops to do what it used. Of course one can execute the manual test procedures once more with every release, but that is first of all very expensive as people have to try all specified features from all previous releases, and the accuracy of such findings often is not good enough. As a result the shape of the application code is changing from release to release as [[wikipedia::amoeba|real amoeba]] changes its shape over time. That is why this behaviour is called the [[Amoeba Model]]. | Over the time, with new and new releases, regressions occur. The functionality of the code is changing, it starts to do new things and alas, it also stops to do what it used. Of course one can execute the manual test procedures once more with every release, but that is first of all very expensive as people have to try all specified features from all previous releases, and the accuracy of such findings often is not good enough. As a result the shape of the application code is changing from release to release as [[wikipedia::amoeba|real amoeba]] changes its shape over time. That is why this behaviour is called the [[Amoeba Model]]. | ||
Revision as of 15:05, 23 December 2008
What does "quality of a library" mean?
There are many possible answers to the question "when an application has good quality?". Depending on one's standpoint the application can be requested to have a slick UI, natural work flow, be acceptably fast, not crash from time to time, etc. These are all good expectations, and let's include them under one general category - specification. If we are good UI designers and if we can understand the user needs, then we can create a good specification, which describes how our application should look.
Amoeba Model
The Amoeba Model is one way to imagine the relation between the specification, that is our expectations and the reality. Here is a picture showing our great vision:
Yes, the visions are always nice. However this does not mean that our users will be satisfied with the quality of what they really get. A good enough specification is just half of what they see. They also need good enough implementation. Any expectations we put into our application can or even are (in ideal state) expressed in our specification, but before they get to the user they have to be implemented in code and it is very likely that the code will not follow the specification fully. There will be differences between the code and the specification.
The amount of the differences between our code and our specification is the measurement of quality. If the final system is not doing what we originally intended it to do, then it is not good enough. Its quality or maybe better term is our confidence in it is lowered with every difference from the expected behaviour.
Sometimes the application does not do what we expect it to do, sometimes it does more. Both situations are dangerous, but only one of them is easy to find. One can read through the spec and test (manually, automatically) if everything that is requested is really implemented. So by carefully testing for the expected features of the library, one can minimize the places where the code offers less than expected. But even this has its limits:
Over the time, with new and new releases, regressions occur. The functionality of the code is changing, it starts to do new things and alas, it also stops to do what it used. Of course one can execute the manual test procedures once more with every release, but that is first of all very expensive as people have to try all specified features from all previous releases, and the accuracy of such findings often is not good enough. As a result the shape of the application code is changing from release to release as real amoeba changes its shape over time. That is why this behaviour is called the Amoeba Model.
Minimizing Amoeba Effect
Clearly, the differences between the perfect vision and imperfect real estate are always going to exist. The goal of API designer is to minimize them, the less differences between them, the greater will be the chance that the API user and API designer are going to understand each other. As API designed is mostly about communication (see Chapter 2) it helps if the API designer and user talk the same language - for example they know and use the right APIDesignPatterns.
The other important direction to tackle the Amoeba Model differences, is to do testing. At least run some SignatureTests to guarantee Binary Compatibility and also have some automated tests to assert functional compatibility during runtime execution (more in Chapter 11).
Follow
