Search code examples
methodologyheuristics

Are there any structured methodologies for defining metaphors to simplify complexity in programs

Sorry if this seems like a hazy question but it's something that's been bugging me for a little while.

In my day job, some of the code I write gets pretty complex. Not that it's usually very technical but the problem domain itself is a complex matter dealing with spacial data amongst many other things. I'm pretty sure my NDA would prohibit me from giving any details of what I'm working on so, unfortunately, I'll have to keep this pretty general.

Now, I'm all for reducing complexity so I try to find the right abstractions when I can but is there any way to reduce it further by explicitly not dealing with the actual matter at hand but rather some metaphor that could be operated on and then translated into the actual result I want later?

Of course, since the area is so complicated in itself,..I've tried but failed (many times!)to find the right metaphor :-(

So my question is, has someone already done this work and found (or even half found) a structured way to extrapolate an appropriate metaphor or heuristic for a set of given programming problems?

Again, my apologies if this seems like a bit of an odd question. I'm just trying to find new ways of being a better programmer.

Thanks in advance.

Solution

  • So my question is, has someone already done this work and found (or even half found) a structured way to extrapolate an appropriate metaphor or heuristic for a set of given programming problems?

    I may have the start of an answer to your query. This consists of multiple levels of abstraction; descriptions of multiple domains; and the application of "modelling" techniques in a particular way - really rather different from what is normally done in modelling. The overall approach is, I believe, what you are seeking - it gives metaphors that are operated on, and then translated into the actual result. It is based on a number of published approaches, and relies heavily on some of these approaches and methods.

    What follows is subject to these caveats:

    1. This is very much "work in progress".
    2. I have been on the receiving end of derogatory comments that I am an "architecture astronaut", with the consequent implication that I am out of touch with the nitty-gritty of real system development. This is one of the reasons this is work in progress - my current project is designed to validate this concept, and demonstrate that it has real utility. In order to do this I need to develop a system of sufficient scale and complexity, using my approach, that would normally be out of reach of an individual developer. I am only part way through such proof of concept development.
    3. While the concepts I describe are derived from consideration of complex problem domains (sonar contact tracking system, and chip design systems), my examples relate to a simpler domain - basically an information system, constrained by a rules system. The rules base includes not only rules about the domain, but also rules about the applicability of other rules.
    4. I suspect, from your question, that I am coming to it from the opposite direction to you. You ask for a way to extrapolate an appropriate metaphor or heuristic for a set of given programming problems - which to me implies starting with the programming problems. My impetus has been from the analysis side - trying to find and formulate ways of describing a proposed system so that it can be implemented as a real system.
    5. When I use the words "model" and "modelling" I mean modelling as described below. This description is somewhat different from common usage of these terms.

    The three main consituents needed for this approach are:

    Multiple domains

    My definition of a domain is wider than that normally adopted:

    A domain is a separate real, hypothetical, or abstract world inhabited by a distinct set of objects and phenomena that behave according to rules and policies characteristic of the domain. In problem analysis.the domain is a useful unit of consideration when developing complex systems.

    Under this definition, there are multiple domains for consideration within a system, Often when developers refer to a domain, they mean the problem (or application) domain (referred to hereafter as P). However for this approach, any aspect of the system, or system development is a potential subject for modelling. This includes the system architecture (A); system production artefacts (code, make scripts, database schemas, etc) (C); DBA functions; etc. To approach P via metaphor requires development of several such domains - relating to the metaphor and transformations from the metaphor to a model of the real world, or to the code realisation of the real world in the developed system. When multiple such models are developed, they are all developed to the same degree of scope and precision.

    Multiple levels of abstraction

    To describing a problem and system, one models not only P, but also models appropriate higher levels of abstraction. Thus the metaphor chosen to describe P is modelled (M). In a similar way, the formalism of A (F) is modelled, and if deemed necessary the transformation process between P and C using A (R). So one abstracts the problem domain; abstracts the abstraction and so on.

    The application of multiple models is similar to colour separations - they lie on top of each other, and the system has to meet all the descriptions (the "complete picture") of all the layers. Again this differs from common ways of modelling which tend to meet such multiple requirements by elaborating the original model to take in the different constraints. This has particular implications when all of the architecture domains are effectively applied to all the elements of all the problem domains.

    Modelling

    What I mean by modelling differs from more usual approaches to modelling in the following respects:

    1. The subject matter of the model is highly likely to be different from domain to domain. This contrasts with modelling where initial models are elaborations of other models. Indeed, one test of the validity of a model is that it represents an extreme version of the DRY principles - if something is defined in more than one place, it indicates a deficiency in the model. This extends to all domains under consideration, so the way the system is built is defined only in one place.
    2. A domain, once modelled, is likely to be fairly static. The higher the level of abstraction, the less likely it is to change.
    3. The scope of a model is likely to be much narrower, and much deeper than those conventionally developed. There are likely to be fewer objects within a particular domain than in conventional modelling; but these models must be complete and there are tests which give some indication of the completness of the model (obviously, one can never prove that a system description is complete).
    4. P is described in terms defined by M. The model might be expressed as diagrams, OO representations, mathematical formulae, or whatever is appropriate for the domain M.

    The following example, derived from my proof of concept project, may give some flesh to my descriptions above. I list some of my domains, together with candidate contents of the domain models.

    • P [Vehicles, units, movements, exhaustion, speed...]
    • P1 [Rules, applicability, states, priorities...] (a subsidiary problem domain)
    • M [Object types, attributes, relationships, domains...]
    • A [Events, tables, columns, database domains, classes...]
    • F [Persistence mechanism, processing,.....]
    • C [Database schemas, source code, SQL scripts, build scripts,....]
    • R [Formalisms, transforms, mappings...]

    There is at least one major disadvantage with this approach - the work involved in developing the models can be seen by management as non-productive, with no real deliverables being produced.

    The sources for this answer are many and varied, but do rely heavily on works by:

    1. Michael Jackson on structured programming; system analysis; and problem domain descriptions.
    2. The Shlaer-Mellor method of system development by transformation rather than elaboration.
    3. The Kennedy-Carter method consultancy.