Methodology Package.

Methodology grows the vision of Dan Gillman and others from the Minneapolis Sprint in several ways. Methodology now integrates with the process model (CoreProcess) if folks want to describe a methodology in detail (not required).

Also, in line with BPMN / BPEL and the visions of Denis, Arofan and Flavio who want to integrate DDI and a standard business processing language to facilitate metadata-driven execution, across the Methodology and CoreProcess models I created two types of process description.

There are two types of flows - workflows, describing process steps, and message flows which describe communications between or inside and organization. We can chain business functions from the GSBPM, the GLBPM or any other catalog of business functions without regard for inputs, outputs and the data flow. The second swim lane BPMN calls the messaging swim lane and it includes inputs, outputs, bindings and so forth.

Finally, Methodology includes an extension point (xEntity). Methodology manipulates these and other DDI classes to realize specific business functions.

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