Using a partition to ease discovery of a model

31 January 2017

Navigating results via a top-down hierarchy

The lean collection type in STEM is long established as a neat way to group elements and provide systematic aggregation across all results available for those elements. A collection can also be used to group other collections, and so it is possible to build up one or more hierarchies of the costs in a model (e.g., by network function, or by vendor).

This is easy to manage in a modestly-sized model, but it becomes harder to verify when a model is very large and extends over multiple views. To address this challenge, we are working on a partition concept which requires any nominated hierarchy to be checked for completeness, and to ensure that each cost appears precisely once within that hierarchy. The Editor makes this a breeze to work with by automatically breaking previous links when a cost (or group of costs) is connected to a new branch of the hierarchy.

Navigating the results of a large model can also be challenging; even the filtering option in STEM 7.5 won’t help if you don’t know what to look for in the first place! A partition enables an optional top-down navigation of results where you can expand individual branches of a hierarchy to drill-down into the desired detail.

Mathematical definition and implementation in STEM

A partition of a set X is a set of nonempty subsets of X such that every element x in X is in exactly one of these subsets (i.e., X is a disjoint union of the subsets)1.

In STEM terms: a partition is a homogeneous collection where all sub-collections and all elements of the given type appear exactly once.

We have added a new collection input, Partition = Yes / No, which activates the required constraints. A key insight is that this property must be defined only for the top-most collection in a hierarchy; this is sufficient to impose the constraints on all the branches.

Just as with plain collections, it is quite feasible to have more than one partition of any given type, and even for them to share one or more sub-collections.

Note: a regular collection makes no such checks and allows for the inclusion of overlapping sub-collections. However, by design, STEM has always avoided double-counting in such an instance, calculating the associated results as the aggregate over all elements which appear in any of the sub-collections.

Working with an example

If we set the input Partition = Yes for the collection, My partition, in the illustration below, then its structure will be checked for completeness and uniqueness whenever the model is run. Any relevant issues will be reported as warnings.

Figure 1: Example partition structure

However, there is much more that the Editor can do to manage the membership proactively, e.g.:

  • if I add Vendor #2 to Access, then it will be removed from Routing
  • if I add Routing to Vendor #2, then the Editor will report the circularity and immediately undo the change
  • when I first set Partition = Yes then the Editor will ensure that:
    • any missing resources are added
    • any existing duplicates are reported as they would be at check-time.

The Editor will not fix anything which would require an arbitrary choice to be made and any issues of this sort will be left for you to resolve when the warnings are reported later.

Using a partition to navigate available elements for results

Once you have a verified partition, it will obviously make a pleasing alternative to the usual flat list of available elements to draw when accessing results:

  • it will facilitate a top-down discovery of the model structure
  • it will make it easy to drill-down into the aspects of most interest (e.g., greatest cost).

The operation of this hierarchical list remains to be specified in full, but it will include the ability to expand or collapse the sub-collections within a partition to any depth.

We are considering various element-navigation options as follows, perhaps selected from a Navigation drop-down below the Available list (for drawing graphs):

  • Flat: all elements in the model, in logical or alphabetical order
  • By type: equivalent to a collection of flat partitions of each type (same order)
  • By partition: equivalent to a collection of all defined partitions (alphabetical)
  • Individual partition 1: just the named partition (which could also be a single collection of partitions)
  • Individual partition 2:

There is nothing much yet to be gained from understanding these tentative options, but please try to figure them out first if you want to make any further suggestions!

Controlling the order of elements in a collection (and the model too)

Historically, list management has not been a focus in STEM. However, it will become a more significant expectation once navigation by partition is implemented and you want to determine the order in which items are presented at each level.

So we are planning a minor change to the drag-and-drop behaviour for collections as follows:

  • when you first drop a selection of elements in a collection, they are added in the order you see them (across, and then down)
  • but if some are already present, currently they are not disturbed
  • instead, we will move them to the end with the other new additions, as if we had removed them first.

This will provide a very intuitive and accessible way to control the order of a collection, and in turn each level of a partition hierarchy.

We may add rudimentary up/down commands to the Elements list-box in the Details dialog to sort the elements manually, but it will be fundamentally easier to visualise and then update the order by manipulating the elements graphically in two dimensions first.

Logical order when selecting elements for a graph

The list of elements presented by the results program appears in the rather obscure order of creation unless you select Alphabetical order. The raw logical order is not very useful and more or less impossible to change. In fact it would always have been very cumbersome to manipulate the master list of elements of a given type in a large model.

Now we plan to add an option to re-order this list from a partition of the corresponding type, proceeding through the elements depth-first, as per the fully-expanded hierarchical navigation. The task will be much more manageable this way, as you can focus on one branch at a time rather than manipulating the whole list at once, and it will reap the same benefits of manipulating the elements graphically in two dimensions.

Other miscellaneous considerations

A prototype of this functionality has received rave reviews in recent demonstrations, but there are many questions which remain to be resolved in such a broad implementation before the system will be ready and sufficiently tested for external consumption. Some of the more interesting details are presented in the following paragraphs.

It is quite feasible for a collection to have both sub-collections and explicit elements as members, and where this is the case:

  • we may optionally group the explicit elements in an automatic Other category
  • there is a related suggestion to be able to graph the top n items of a given category, with the remainder grouped together as Other.

An existing function or market segment may be included within a partition of resources or services, respectively, just as if it were a regular collection of those elements.

It may prove useful as an option to indicate how many leaves there are within a given branch of a hierarchy, and/or for the individual leaves to be numbered. This would make it easy to verify that you have a complete report at any level, especially if linked to Excel.

A partition will still work with template replication:

  • any partition item which is replicated, either an element or a collection of replicated elements, will be replaced by a collection of each variant instance, so the partition will just branch by variant at this level, but
  • it will be an error for a partition to include a replicated collection which includes a non-replicated element as this latter element would then be present in each variant-instance collection, making the structure as a whole non-disjoint.

If a template has many variants, they can already be grouped with collections, and now this would allow for them to be arranged in a partition too. This would provide for a hierarchical navigation when drawing a graph for the Variants tab too, with potentially interesting implications for Linear Selection mode, and even more so for Linear Selection mode with cost-breakdown results – see separate article.

Better browsing, easier consistency checks

Results browsing will be significantly enhanced by the ability to navigate both elements and variants via a top-down hierarchy defined by one or more partitions in a model. This will deliver benefits for both the original modeller and someone else less familiar with it:

  • guiding the exploration and comparison of related results at every level, and
  • enabling an orderly and informed discovery/digestion of what is in the model.
1 See

Free subscription when we review your business model

How well do you understand your business? It may be profitable now, but how prepared are you for this to change? We have a track record of analysing individual services or entire businesses in an interactive workshop style that engages and informs. Our visual software enables multi-disciplinary dialogue about the business you thought you knew and the more uncertain future ahead.

Read the article

STEM User Group Meeting 2017 proceedings

Our most recent customer event was held on 27–28 September 2017 at King’s College, Cambridge. The modelling track explored three growth models for a start-up business, from unconstrained to measured to driven. The remainder of the event covered the forthcoming STEM version 8.0, the revised business model for Implied Logic, and two guest presentations.

Read the article

A freshly baked model of a start-up

We examine Michaela’s Best Bread Direct service, from her first unconstrained vision, through a more realistic measured phase and finally to a more ambitious, customer-driven approach. We demonstrate how STEM can be applied to almost any business topic and always delivers a systematic and reliable treatment of time and money.

Read the article

Business-case design and training at your service

Ever wondered what we do at Implied Logic? We have recently posted a comprehensive update to our services portfolio online which is effectively a self-service proposal for everything from online training on-demand through to on-site business-modelling consulting and hosting services for business models on the web.

Read the article

Connecting elements to graphs and publishing online

In what is likely to be the final preview article for the forthcoming STEM version 8.0, we explore visual connections between individual icons and a related graph, as well as intuitive, interactive options for adding an element to an existing graph. We also explore new layout options for pushing a presentation of results in STEM to the web.

Read the article

Our latest help and training materials

Documentation is never regarded as a very exciting activity, but our comprehensive help and training materials are a vital element of the self-serve experience with STEM. In the last quarter we have posted two significant updates to our online help site which enhance both of these aspects.

Read the article

A radical re-think on STEM pricing

We announce a new freemium strategy for accessing the STEM software, including a free and fully-functional demo system for small projects and study as a taster for an innovative minimal-support subscription to the Conventional STEM (C-STEM) desktop solution at just GBP 330 p.a..

Read the article

Vision for the forthcoming STEM 8.0

As part of our vision for a more intuitive way of working that bridges previous mental leaps wherever possible, we preview another two features of the forthcoming STEM version 8.0 – direct-draw connect mode and more flexible user data – that form part of a joined-up approach to fulfilling this dream.

Read the article

© Implied Logic Limited