# Which is larger, the number of paths in a program or the number of points in its domain? [closed]

-

## closed as unclear what you're asking by Bruce McLeod♦May 1 '14 at 23:26

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question.If this question can be reworded to fit the rules in the help center, please edit the question.

Could you define what you mean with the "Paths in a program" and "Points in its domain"? What you mean with latter is unclear to me. – Niels van Reijmersdal Apr 18 '14 at 8:58

This question is dependent on whether the domain structure is has branching or recursive elements.

For example, a simple code containing three function points performed in sequence may have a single path. If those are selected from a case statement, then you could identify the case as one function point (or node) and the number of paths as three (or four if there is a "null" path with no selection made).

With branching or recursion, however, the number of paths could become infinite with the addition of a single decision statement that leads back to the original case statement and/or one of the functions calling itself or another of the functions. In that case, only a few point could produce an enormous number of possible paths.

-

I suppose that path is any sequence of consecutive 'links' between 'points' in a program, including recursive and repeating 'links', thus potentially even the simplest program has infinite amount of possible paths, while any domain has some finite number of points. Thus, if my assumptions are correct, program paths are greater in number than domain points.

-

As Jeff and Eduard have said, in most non-trivial applications the number of paths is going to be greater than the number of function points. The exception is in systems where there are no or very few decisions.

To take an extremely simple and well-known example, consider the most basic text editor application, such as the Microsoft notepad.exe. Now consider only the most basic features of that application: entering text, saving, and opening a saved file.

Function points are (assuming that the file open and file save functions simply call the Windows API): - echo keyboard input to screen - save keyboard input to local memory - display the contents of an opened file on the screen - send the contents stored in local memory to the API file save function.

Potential paths are effectively infinite, because each keystroke triggers a separate invocation of the echo/save locally function points. In addition, it's possible to invoke the save to file function at any time, even after each keystroke.

You can simplify the potential path issue by conceptually grouping paths (which is a static form of equivalence partitioning) by treating all paths with recursion as the same effective path (e.g. any path that iterates through entering text and saving any number of times greater than 1 is treated as a single path). If you get the boundary points right (e.g. does the path consume more local memory than the machine has available? - and yes, it is possible to create a notepad file that will overrun application memory limits) this can limit the number of paths you need to consider.

You're still going to have a lot of possible pathways.

A slightly more concrete (realistic) example:

Take a point of sale application with three check-box (yes/no) configuration options, all independent. Ignoring saving configuration and the like, the process of making a sale has 8 possible starting points (2 possible states for each of the three options => 2x2x2 = 8). Each starting point has some impact on the sales process, so must be considered a distinct path.

If there are three distinct product types and two accepted forms of payment with no further differences, that increases the minimum number of paths to 48 (8x3x2) - the minimum number of paths in this example is the simplest possible sales process: purchase one item and pay for it.

Depending on how the quantity is selected, you could have multiple extra paths: selecting a quantity versus selecting the item multiple times, and so forth.

As a general rule of thumb, each decision the software makes adds at least one conceptual path.

-