Tool Friction Factor

The difference between what we are trying to accomplish, in terms of creating the models in the problem, solution, and background spaces, and what the tool provides is called the “friction factor” between the conceptual modeling and the models documented in the CASE tool. Furthermore, the conversion of the models into the final software product is also fraught with friction. Many good CASE tools try to reduce this friction by enabling as smooth a transition as possible between various models and between models and code. The key to reducing the friction factor is interaction. If a tool is able to provide continuous interaction between the various parties involved in modeling (the business analysts, system designers, system architects, and users) and the developers, then the CASE tool is said to have minimum friction.

Ensure that the tool complies with what you are trying to do, and not the other way around. CASE tool limitations should not limit the thinking of the modelers. For example, creating the MOPS, MOSS, and MOBS is an exercise that, when documented in a CASE tool, may have to become a single model. The differentiation between the modeling spaces is crucial, and the closeness of the three models is also important for a good quality modeling exercise. However, creating the three modeling spaces may not always be possible in CASE tool-based modeling. Ideally, CASE tools should enable the creation of as many modeling spaces as necessary, and then enable reduced or zero friction between the modeling spaces.

Disclaimer: Please note that I am a user and adviser but not a reseller of any of these UML-based CASE tools and I do not have any vested interest in recommending one tool over the other. My priority is always what is in the best interest of my client. The order of presentation of these tools is random.