This page is a sub-page of our page on TELL ME.

///////

Spacification and Placification: Separating Spaces from Places

As described earlier, our approach to achieving flexibility of integration and physical deployment is to pay attention to the distinction between Spaces and Places. Generally speaking, spaces express intentions and places express physical deployment. ”Places are created by placing things in Spaces” is the overall guiding principle here. We can think of Spaces as representing intentional backgrounds upon which things (= production processes) can be physically realized (= ”placed” or ”placified”). The difference between Place and Space is a subtle one, which has gained the attention of major thinkers, both in relation to fields close to manufacturing (e.g., “factory physics”) and more generally (e.g. the social sciences of place and space).

The major reason for separating the WorkSpace model from the WorkPlace model is that human and technological networks allow new strategies for deployment, i.e., “placification” of a given business model. Therefore there is a need to experiment with different “placification strategies” and evaluate them with respect to different value models. A major outcome of the work reported in this deliverable is a more sophisticated way to model how the concepts of ’place’ and ’space’ can be used in manufacturing.

Examples that are discussed below include ”Placification of WorkSpaces” (Figure 10) and ”Instantiation of “Placification of WorkSpaces” for Java/C++” (Figure 11). The section containing those figures (and others) provides a powerful new way to model ways to augment the capabilities of a factory and its workers, and to combine workflows as services. For example, this could entail adding Internet of Things (IOT) services to a place being used for manufacturing, to enable detailed real-time tracking and rapid analysis of the position and state of every object in the place, and then to link and control certain objects. The IOT services could be delivered by wifi and could mix private/public and local/global IT services. Thus, the services available in that Place could make use of data from far-away Places (physically) and Spaces (conceptually) – such as e.g., (a) data on batch quality in a subcontractor’s factory, or (b) data on the location, speed, vibration, tilt and interior climate of a truck on its way to deliver parts made in that subcontractor’s factory.

In summary, the major reason for separating the WorkSpace (business) model from the WorkPlace (business) model is that technology allows new strategies for deployment (= “placification” of the intentions of a business model). Placification is about creating Places within Spaces in our case WorkPlaces within WorkSpaces. Our major enhancement of the placification service consists in the fact that the mentioned separation between space and place allows us to more flexibly experiment with different kinds of deployment (= placification) strategies under various explicitly modelled hypothetical conditions.

TELL ME D4.4 Figure 9: Creating Augmented Places for Augmented Performance

Figure 9 shows three types of Space and Place that share the same context (= background), namely Virtual-, Real-, and Mental Space and Virtual-, Real-, and Mental Place. These types of spaces and places participate as building blocks in the construction of the Augmented Space and Augmented Place shown to the right of Figure 9. The aim is to construct an augmented performance space of the service and placify it (= localize it = personalize it) in such a way as to optimize for augmented performance of the client.

Creating places by placing things in spaces

The main idea of the model/pattern presented in this section is to separate the concepts of WorkSpace and WorkPlace in order to create more options for “placification” (= localization = deployment) of a given WorkSpace. We will make use of Democritus’ definition of Space as a sort of container (= background) of things and Aristotle’s definition of Place, (Jammer, 1969, pp. 11-17) For Aristotle, a place is defined by its confinement, and for Democritus, space is identified with the common background for all places, upon which (or within which) things can move around and change their positions. Hence, from a mathematical perspective, aPlace corresponds to a (physically situated) subset of Space, i.e.,

Hence, from a structural perspective, aPlace can be thought of as a mapping from Space to a set of two elements (called e.g., inside and outside):

aPlace(x) = inside if x represents a position inside aPlace, and aPlace(x) = outside otherwise.

Space-to-Place: a design pattern for placifying spaces

The Space-to-Place pattern describes a way to placify (= localize = realize) a space. Here we will discuss a specific type of Space called a WorkSpace, but the Space-to-Place (= placification) pattern works for any type of space.

Placification of WorkSpaces

The purpose of the WorkSpace-to-WorkPlace pattern is to separate the logical/intentional model from its different physical implementations, i.e., to separate whatever it is that we want to happen (in the WorkSpace) from ‘however’ it is that it’s taking place (in the WorkPlace). The reason for this separation is the desire to be able to explore different ways to placify (= deploy) the intentions of a business model and turn its corresponding WorkSpace into a WorkPlace.

TELL ME D4.4 Figure 10: Placification of WorkSpaces

As depicted in Figure 10, the abstract class WorkSpace declares an Intentive interface by declaring the intentions (= logics = semantics) of the Business Model.The subclass Concrete WorkSpace implements these intentions by making use of the delegation pattern. A call to an abstract function is delegated to a concrete version of it. In Figure 11 the points of delegation are marked by red-lighting the word ‘concrete’.

Note that although it provides some implementation, the class Concrete WorkSpace is not “totally concrete”, since it declares a deployment interface, that it does not implement, but which is instead implemented by its subclass Concrete WorkPlace. This is the crucial design element that provides the freedom to experiment with various placification strategies of the business model, and e.g., applying the generic MMO methodology itself (as described in D1.4) to optimize them with respect to different value models.

WorkPlace declares a Locative Interface by declaring the localization of the elements of the Business Model of things in spaces. Concrete WorkPlace implements this locative interface. The reason for localizing the elements of the WorkSpace is to make it easier for the deployment process to do its work. This process can then concentrate on placifying the relationships between the elements in the business model, while relying on the “concrete_where” functions for the corresponding placifications of the elements themselves. Moreover, in the process of placifying a person, a piece of material or a tool, we can also include a link to corresponding possibilities of re-placement.

Instantiating the WorkSpace-to-WorkPlace pattern for Java/C++

As mentioned above, the idea of modelling the stakeholders of each aspect of a process module provides a way to connect these modules into service networks. The “interfacing questions” that must be answered in order to set up these connections can be summarized as follows:

• which( ) – Which products should we produce?
• forWhom(Product) – Which stakeholder needs are being satisfied by this product?
• why(Product) – Why is this product satisfying those needs, and why do we want to satisfy them?
• byWhom(Product) – How should the producing process for the product be performed?
• whatFromWhom(Product) – What input resources from whom should be refined in the process?
• usingWhatFromWhom(Product) – What resources from whom should support the process?
• adheringToWhat(Product) – What constraints should be obeyed in the production process?
• whenActive(Act) – Chronos: During what subsets of Time is an act active? // “time”
• whenFavorable(Act) –Kairos: During what subsets of Time is an act favourable? // “timing”

TELL ME D4.4 Figure 11: Instantiation of “Placification of WorkSpaces” for Java/C++

The modelling framework depicted in Figure 10 and Figure 11 provides a generic way to model organizational processes as linked to general goals, with a possible decomposition into partial goals that interconnect in order to support the overall goals of the service process network.

Patterns used in the Space-to-Place pattern

The Space-to-Place pattern makes use of the following patterns, some of which are described in (Gamma et al., 1994):
• Configuration by Abstract Factories
• Implementation by Delegation (Factory Method)
• Exceptions by Code Contracts (Design by Contract)
• Localization by Recursive Placification (Universal Discourse Graph)
• Design for Anticipated Change

Configuration by Abstract Factories

Each one of the WorkSpace and the WorkPlace class hierarchies are examples of the Abstract Factory pattern, which is described in (Gamma et al., 1994, p. 85) in terms of:

Intent: Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

Applicability: Use the Abstract Factory pattern when
• a system should be independent of how its products are created, composed, and represented.
• a system should be configured with one of multiple families of products.
• a family of related product objects is designed to be used together, and you need to enforce this constraint.
• you want to provide a class library of products, and you want to reveal just their interfaces, not their implementations.

All of these four points are relevant to the WorkSpace-WorkPlace hierarchies.

Implementation by Delegation (Factory Method)

Delegation is essentially a Factory Method pattern, which is described by (Gamma et al., 1994, p. 107) in terms of:

Intent: Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

Applicability: Use the Factory Method pattern when
• a class can’t anticipate the class of objects that it must create.
• a class wants its subclasses to specify the objects it creates
• classes delegate responsibility to one of several helper subclasses, and you want to localize the knowledge of which helper subclass is the delegate.

In the WorkSpace-WorkPlace pattern, delegation localizes the knowledge of which classes belong together. This increases the “design freedom” of the placification process.

Exceptional Services: Exceptions by Code Contracts

Below is an example of how to deliver “foobar” as a Service with Exceptions (= an exceptional service) while depending on the result of “internalfoobar” as an (exceptional) InternalService:

Service foobar(Types parameters)
{
if preconditions (parameters) ≠ true
{ throw(“pre-foobar exception”) } ;
InternalParameters internalParameters ;
internalParameters = (InternalParameters) parameters ;
InternalService internalResult ;
internalResult = internal_foobar(internalParameters) ;
Service result = (Service) internalResult ;
if postconditions (result) ≠ true
{ throw(“post-foobar exception”) } ;
return result ;
}

The service foobar makes use of a pattern called design-by-contract® (Meyer, 1991) by not allowing any input that does not satisfy its pre-conditions. Dually, it checks that its post-conditions are satisfied before returning the result. If either of these conditions are not satisfied, foobar throws a corresponding exception. In this way it is easier to locate the faulty service/task and to correct it than if foobar would try to be clever and do something to rescue the situation. This would most probably result in an error further down the call-chain, where the cause of the error would be much harder to localize.

Localization by recursive placification

Anything that is “composite” is structured as a recursive aggregate. For this purpose we introduce the class Module is an abstract superclass that includes Agent, Activity, Space, Place, Tool, Equipment, etc. In Figure 12 modules are modelled as recursive aggregates, where an aggregated module consists of two or more modules that could be either atomic or aggregated, and so on. The atomic modules cannot be further broken up into parts. Moreover, each aggregated module contains a protocol. This protocol expresses the supra-activities (= the collaborations) among the intra-modules (= sub-modules) that are involved.

TELL ME D4.4 Figure 12: Protocol for supra-activities among the involved intra-modules

Here is some code for placifying (= locating) an (aggregated) thing in an (aggregated) space:

Place placify(Thing thing, Space space)
{
Thing_Space_Graph thing_space_graph = unpack_relations(thing, space) ;
Thing_Place_Graph thing_place_graph ;
IntraThing_IntraPlace_Graph intraThing_intraPlace_graph ;
for (intraThing_intraSpace_relation in thing_space_graph) do
{ thing_place_graph += placify(intraThing, intraSpace) } ;
Place place = pack_relations(thing_place_graph) ;
return place ;
}

Design for Anticipated Change

The Space-to-Place pattern declares a locative interface because it provides support for anticipated changes in location. This “design for anticipated locative change” is a special case of the more general pattern “design for anticipated change.” A declared interface for anticipated change will allow concrete subclasses to implement these changes in various ways – so that clients can experiment with them while protected by their ignorance of how they are actually implemented.

////////