Sometimes designers experience that a solution for a particular problem leads to an explosion in complexity, because the ASD:ModelVerifier reports a state space explosion (for more details see The effect of ASD on the software development lifecycle). Project managers may experience this as rework while the designer is actually performing an exploration of the design space.
These are some modelling guidelines for designers to keep their components simple and therefore more predictable to plan:
Note: Actually, these guidelines always apply for all components independent whether or not ASD is used. ASD only reports the resulting effects of making certain architectural/design decisions.
- A component should only have one functional responsibility. Adding more functional responsibilities quickly lead to explosion in complexity and it also limits possibilities to apply concurrent engineering;
- A component (actually, its interface) should abstract implementation away by only offering what his clients need to know (rather by offering what clients can do). Often interfaces reveal the internal structure and/or behaviour of a component that can often be simplified by making more abstract interfaces. Simpler interfaces mean simpler usage. Simpler usage means less complexity;
- A component should only offer what is needed now. Often components and their interfaces are prepared for re-use causing over-generalizing of the behaviour as offered by the component. The net effect is that more complexity is introduced for which there is no value yet; worse, experience often tells that this (re-usable) behaviour either needs relocation to a different component or is wrong causing (again) extra work in both cases;
- A component should be as synchronous as possible. Only introduce asynchronous behaviour when needed from a functional and/or performance point of view. Asynchronous behaviour, especially in combination with unsolicited and/or unconstrained notifications, quickly causes an increase of state space and therefore complexity;
A fairly objective way that determines whether or not these guidelines are met is the following: A component should be small in terms of ASD function points, have a limited fan-in ASD interface models, and have a limited number of states during verification.
As a rule-of-thumb, a design model should be smaller than 1000 ASD function points and it should have around 3 used components, but certainly not more than 5. Design models that are bigger in terms of ASD function points and/or have more used interfaces typically violate one or more of the first three guidelines as described above.
Note: Upon loading the model in the ASD:ModelBuilder, the size is unknown until the first verification or code generation action. If necessary, an end-user can explicitly request the model size by going into the "Tools" menu and select the "Determine model size" entry.
Further, the number of internal states as reported during verification of a design model should be smaller than 100.000 (the number of states is roughly equivalent to the number of execution paths and is therefore an indication of the complexity of a component). When the number of states becomes higher than this, the component often contains a lot of asynchronous behaviour which causes state explosion – especially in combination with not meeting one or more of the first three guidelines. Keeping the number of states below this number allows sufficient room for making changes local to the component, such as adding alternative error handling scenarios.
Note: To make sure that the number of states is indeed displayed, go to "Tools->Options->Model Verification" and ensure that "Display internal states" is ticked.
The figure below shows where these numbers are displayed in the ASD:ModelBuilder:
Note that the model size in ASD function points does not have any correlation with the number of states as reported during model verification. It is quite easy to build large models that have a small state space and vice versa.