View source

From APIDesign

You do not have permission to do that, for the following reason:

The action you have requested is limited to users in the group Bureaucrats.

You can view and copy the source of this page:

== 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:

[[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. 

[[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. 

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: 


[[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]].

== 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 [[The_Motivation_to_Create_an_API|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 [[BackwardCompatibility|Binary Compatibility]] and also have some automated tests to assert functional compatibility during runtime execution (more in [[Runtime_Aspects_of_APIs|Chapter 11]]).

Templates used on this page:

Return to Amoeba Model.

Retrieved from "http://wiki.apidesign.org/wiki/Amoeba_Model"

View source

From APIDesign

Views

Personal tools

blogs & look

Navigation

Search

Toolbox

View source

From APIDesign

Views

Personal tools

blogs & look

Navigation

Search

Toolbox

buy