IBM SG24-7368-00 manual GPS navigation system usages

￿GPS navigation system usages:

–Help me identify my destination using the information I know.

–Guide me to a destination.

–Find a Mexican restaurant that is on my way to my destination.

–Show me the hotels that I can reach in about 5 more hours of driving.

–Where are the truck stops in the cities I will pass through today?

This is quite a different kind of list. By describing the actual usages to which the system will be put, and basing our designs on those, we are assured that the system we design will meet the real needs. It is also interesting to note that many of these usages can be accomplished with little additional development effort, and no additional hardware. They are a matter of imagination. By combining existing elements, we can perform interesting new usages, provided we imagine these in our design process.

The important question to ask at this point is, What is the relationship between the features and the usages? The answer to this is one of the keys to understanding the MDSD modeling process. Usages are, in a way, combinations of various features or services arranged in a sequence so as to provide value.

Instead of using a set of features as the sole statement of requirements of a system, what if we were to describe a comprehensive set of system usages, and then from these, derive the necessary features and functions? This would result in an architecture optimized for usage. We would be sure that we have all of the capabilities needed to perform (or realize) the usages, and we would be sure we have not required any unnecessary functions.

Then, if we took it a step further, and used the same usage-based models to design subsystems and components within the overall system, we could provide comprehensive traceability. We could show precisely how even the most minute operation of a component contributes to particular system usages. Changes to any part of the system could be analyzed for impact to all other system elements, and we would be assured of complete requirements coverage.

This is the kind of model MDSD can produce through system decomposition and operation analysis, as introduced in “System decomposition” on page 22 and “Operations analysis” on page 30, and explained in “Operation analysis” on page 72. Of course, we still have to consider how constraints on functionality and on the system itself will influence the architecture, and we will do that when we consider localities and joint realization.

Chapter 3. Black-box thinking: Defining the system context 39