Accessibility described using Object Oriented Analysis and Design (OOA/OOD) – Part 7 Independent Problem Domains

Image of Fragment of a Shlaer-Mellor information model

I’ve already written about my systems-led approach to accessibility research. This series of articles is designed to put a little more flesh on the bone with a detailed look at how OOA/OOD (Object Oriented Analysis and Design) can be used to describe computer systems and their interaction with users.

Back to table of contents
Previous: A thinking tool

2.3 Independent Problem Domains

As with Aspect Oriented Modelling (Kindler and Schmelter, 2008) which in many ways shadows Shlaer and Mellor’s own ideas, the Shlaer and Mellor method views systems as a collection of independent, but related problem domains. In Shlaer and Mellor the relationships between problem domains are expressed by “bridges”, whilst in Aspect Oriented Modelling they are expressed by “join points”. This idea of related problem domains maps easily to the concept of an encounter between capability and capacity being expressed as independent, yet related ontologies.

With Shlaer and Mellor, each problem domain is expressed either by a single Information Model, or a collection of related Information Models with each representing one subsystem of the whole domain. The formal definition of a problem domain in this context is:

A domain is a separate real, hypothetical, or abstract world inhabited by a distinct set of objects that behave according to rules and policies characteristic of the domain.
(Shlaer and Mellor, 1992, p133).

Shlaer and Mellor’s definition of a domain is an an almost perfect match for the ontologies surrounding the encounter between user and entity. The definition also raises interesting comparisons with the general concept of an intelligent agent acting on behalf of a user within a given problem domain, which in itself suggests one potential modelling approach.

Shlaer and Mellor’s approach to describing the relationships between domains using bridges is more problematic. A client/server hierarchical structure is imposed by the method upon domains to create a hierarchy of problem domains, with an abstract application model at the top requiring the services of (generally) more concrete domains, which themselves may require the services of even more concrete domains. A practical commercial example from Ascom AG, Switzerland in the mid 1990s is a telephone exchange application domain that depended upon a routing domain (to route calls) and a numbering plan domain (to identify users and potential trunk routes), both of which in turn depended on an event logging/call charging domain and a communications protocol domain; the communications protocol domain in turn, depended upon a device input/output domain, and so on. Certainly at the outset of my research into accessible design, no such hierarchy was apparent, rather there were relationships between “peer” ontologies, and it was these “peer” relationships that were considered to express the encounter between user and entity.

A Shlaer and Mellor bridge is composed of a number of elements that express the dependency between two related domains:

  1. Object counterparts.
  2. Event counterparts.
  3. Change over time.

Descriptions of items (a) and (b) may be found in Shlaer & Mellor (1992) whilst item (c) comes from personal commercial experience with the method (with Sally Shlaer as consultant) in commercial projects where describing the dependencies between domains could only be effectively achieved through expression as sequences of interactions traversing domain boundaries.

In terms of my work, it is item (a) that I consider of most importance. A counterpart is some entity or object in A that has some equivalence in B; it may not be a direct equivalence, or be a direct one-to-one match. For example, again in a telephone exchange, a telephone number recorded in a phone book may be reached by many different physical trunk routes depending upon time of day and the current network load.

As a second example, this time using mobile phones, the indication of an incoming text message may be represented visually, audibly, and haptically (through vibration); even the visual representation may have multiple simultaneous forms, for example a flashing icon on the screen, and a change in the message count for the in-box. Depending upon the selection of problem domains to represent the phone, counterpart mapping may involve bridges between multiple domains, for example domains representing different human senses. So, with this in mind, the principle of counterparting was retained, but the hierarchy of domains constructed upon it was removed from consideration.

Figure 1: Image of Comparison of Aspect Oriented Design and Shlaer Mellor Bridges
Figure 1: Comparison of Aspect Oriented Design and Shlaer Mellor Bridges

The decision to concentrate on counterparting rather than domain dependency was reinforced by a short on-line, non-peer reviewed paper from Stephen Mellor where he considered the relationship between the Shlaer and Mellor method and Aspect Oriented Modelling (Mellor, 2004). The relevant diagram is reproduced above as Figure 1, showing the relationship between join points and categories of counterparts.

The example given is of a bridge between an Elevator domain on the left of the diagram, and a Transport domain on the right. Elevator aspects considered are: floor selection, cabin dispatching, and door open/close timing. The Transport domain’s aspects are: safe acceleration and precise transport. Representative objects for the Elevator are: Bank, Door and Cabin. Representative objects for Transport are: Load, Motor, Acceleration Profile. Three join points are identified: one between the classes in each domain, one that is an operation, and one that is a signal. For example the operation goToFloor() in Elevator is shown with a join point to the signal move() in Transport.

It is this emphasis given by Mellor to bridges and join points that reinforced the idea that counterpart mapping is a natural and common aspect to describing complex systems; organizing such mappings hierarchically is only one expression of their use.

Next: Abstract user interfaces

Leave a Reply

Your email address will not be published. Required fields are marked *