The Methodologies Package contains a set of classes pertaining to the results of a methodology, design, or process that can be added as a consistent means of expressing overall results and their application to aspects of a study (i.e. a resultant weight and its application within a set of variables, or the resultant sample and its use by a Data Capture or as an input to a weighting process). Classes include BusinessFunction, Goal, Precondition, Result, Guide, and AppliedUse.

Namespace URI:
Include in build?: 


I would remove the last paragraph. The so called extension point in this model may be the design. We have design models for coding, weighting, etc. These models introduce classes and relationships. Think of these models as topological. They specify the things that make up the method. This topology (design) is distinct from the process. The process is the how to. The topology is the what. They need to be distinct.

The how to may be what was executed or what we are planning to do.

Reviewing some of the minutes. does the current model give algorithm the right role? Sometimes the minutes talk about algorithm as something midway between design and process. In this regard maybe we might want to think of an algorithm as a design pattern. See

In particular consider "It is not a finished design that can be transformed directly into source or machine code. It is a description or template for how to solve a problem that can be used in many different situations." We have talked about "templates" in previous meetings.

A design might have a design pattern (algorithm) or not. If it did then then the process would be informed by the design pattern. The design pattern is the best practice and the process implements the best practice. The same best practice can spawn multiple implementations. Alternatively, there may not be any established design pattern, and the relationship between design and process is ad hoc.

I am not sure we need Rule in the model.


In light of your comment, Dan Gillman and I looked at the definitions of algorithm found from googling and compared them with the definition of Algorithm in the model, and the definition of Rule in the model. They seemed very duplicative, such that it would be hard to know which one to use in the case of some types of algorithmic expression. For this reason we have removed Rule and extended the definition of Algorithm.

Our review resulted also in the addition of some relationships: now, a Result may become the basis of a further Precondition in a future Design and Process. Also, Result and Goal can now be related through an evaluation.

Package Graph