The way that I was taught, there is a clear difference between the two.
A software process model is an abstract representation of a process methodology. Waterfall1 is a process model. Iterative methodologies are process models. They don't specify how to do things, but outline the types of things that are done and sequencing for things. For example, Waterfall identifies the phases that a project goes through - requirements, design, implementation/unit testing, integration testing, system testing, deployment - without saying what artifacts to produce or what tools to use (although the output of code is implied). Agile defines core values in the form of the Manifesto for Agile Software Development, time-boxed iterations, and continuous response to change, but it doesn't say how long your iterations should be or how you go about responding to change. The Spiral model is a third software process model.
A software process methodology is a specific way of conducting a software project. These are things like the Rational Unified Process and Scrum. They define exactly what, when, and/or how various artifacts are produced. They might not be entirely explicit with all regards - for example, Scrum doesn't identify what documents to produce or not to produce, since it's focus is on delivering value to the customer - but they define, in some way, the actions that members of the project team must deliver.
However, in actuality, the point is often moot. Many times, process methodologies are presented as frameworks in which you tailor to the needs of your customer and development team, based on requirements and resources. On top of this, organizations might deal with regulatory or legal guidelines that dictate certain aspects of what must be produced or how to go about performing certain tasks (especially related to verification and validation activities).
It frequently becomes more important to discuss each team or organization's process in terms of plan-driven versus agile or amount of formality and ceremony. Discussing the terminology difference between a "process model" and a "process methodology" is mostly useful during academic discussions of process models.
1 I'm referring to the traditionally taught Waterfall, not the more explicitly defined Waterfall in Winston Royce's paper.
It seems to me that the issue is in part due to the GetProportionOfDrainage
being probably the wrong method. It seems strange that you're having to pass all this information in through multiple levels of object in the first place. Surely it would be better to make the SoilType
the focus for those sorts of computations, with it asking the DrainageType
instance for just the information it is an expert on.
Once you've done that, you just have to deal with the complexities of real paddocks. I believe they're not all flat and don't always have a single soil type. Thus, the application of the ratios might need to be the responsibility of the Paddock
, as that knows about such information. (I assume that this is a proxy for the real model, yes?)
Best Answer
The notion of hints is a particular way to express a specific API contract, or maybe more precisely, lack thereof. Basic idea is that application developer passes some information to the underlying system / library without any guarantees that it will be taken into account.
I personally like the way how this is described in OpenGL API docs for glHint:
Wikipedia article on SQL hints mentions: