tn 2 Half Table Study: Elevator Case Study - modelint/shlaer-mellor-metamodel GitHub Wiki

mint.sm-meta.system.tn.2 / Leon Starr / Version 0.2.0 / 22-7-5

Now let's take a look at some of the bridging requirements in the Elevator Case Study.

We will focus our attention on the bridge between the Elevator Management Application domain (ELEV) and the UI domain since it appears to be a target rich environment for implicit bridging.

Here is a summary of the existing explicit bridging between our two domains:

We're going to take them one at a time and decide whether or not to use implicit bridging and to what extent. Then we will look at the information that the modeler must supply to provide a complete mapping.

When the Transfer Assigner enters the state Check for active floor service it invokes the following external entity operation:

UI.Cabin arrived( Shaft, direction: /R53/Cabin.Travel direction )

To do this implicitly, we must map the state entry to, what exactly? For the physical interface, the UI might trigger an audible tone and illuminate an arrow pointing in the announced direction. It might do other things. Unlike the Animation example in tn1, we don't have visibility into the components of the UI domain. It hasn't been modeled and it might never be. Though it certainly can be!

The only thing we know for sure is that we should remove an mention of the UI from our ELEV domain.

For the moment though, we need to take a look at what we can map to on the service side. Here is a proposed client facing external entity:

Now let's recast the external entity in the ELEV domain along the lines of the scheme detailed in [EE]

Now let's recast the UI operation invocation at the top to this:

XFER.Cabin arrived( Floor: Destination floor, Service direction : /R53/Cabin.Travel direction )

Not only did we replace UI with our new service facing entity XFER, but we also changed the parameters a bit. We're going to assume that the source ID is available to the EE via its proxy relationship with the Xfer class, so we dropped Shaft. And we supply the destination floor since that was an oversight in the original model.

Now we need to think about how the modeler can specify the wiring between the two external entity operations.

The identifier of Transfer is its Shaft ID and let's say that transfer S1 invokes the service facing operation of its proxy EE (external entity) with the following values:

Cabin arrived( Floor: 4, Service direction: up )

Note that the above is not Scrall since literal values are not legal. But we do need to examine the actual values 4 and up for this study.

Now we need to fill in the following values in the wired service facing operation:

• What happened
• Source
• Event data

Here we just use the name of the service facing ee operation, Cabin arrived. Let's say that this is available as <opname>.

The XFER EE is a proxy for the Transfer class, so it has access to the invoking instance's identifier value, let's say as <id>. (We'll need to show this proxy relationship in the bridge subsystem class model).

This is the tricky bit since we need to set up a value mapping similar to the Mapped Attribute Value solution in tn1. We could add a new Bridgeable Entity subclass and call it Mapped Parameter Value. The modeler would have to fill in a table as shown:

Most of the other service facing announcements from the ELEV domain are simpler cases of what we just described.

But this one is crying out for an implicit bridging solution:

ui-update-cabin-position

First some explanation.

Relationship R43 in the ELEV domain represents the current position of the Cabin in terms of Floors. So the current position of a Cabin is either the Floor where it is waiting, or the most recently passed Floor threshold while it is moving. Each time a Floor is encountered, R43 is updated.

Now R43 is formalized with a single referential attribute in the Cabin class. Note Cabin.Current floor {R43} on the class diagram excerpted here:

When the Transport (TRANS) domain determines that a floor has been encountered, Stop in TRANS terminology, the Update location domain operation is invoked in the ELEV domain. This, in turn calls the Cabin.Update location method which updates R43. This same method invoke the UI.Update cabin position EE operation.

So that's quite the thread of invocations with no purpose other than to update the cabin location. And we haven't even considered the mapping from the SIO domain to the TRANS domain since, surely, the SIO domain is really the first to detect the floor crossing. But let's ignore SIO for the moment and just focus on the TRANS-ELEV-UI thread.

Let's get started with the part of the thread from the TRANS to the EV domain.

We start by defining two external entity operations that need to be wired together as shown:

In the TRANS domain a Load moves along an Axis and passes a numbered Stop. Each Shaft Level (Floor/Shaft intersection) in the ELEV domain corresponds to a Stop. And each Cabin in the ELEV domain corresponds to some Load in the TRANS domain.

We'll assume that we have modeled the ability to wire a client facing ee operation to a service facing ee operation in separate domains. The problem is in mapping the parameter values.

We'll also assume that we've modeled the proxy relationships from EE to class in each domain so that we don't need to explicitly supply the Load ID or the Cabin (Shaft ID) as parameter values. This means that when a Passed stop ee operation is invoked, we have an associated Load instance reference, and therefore Load.ID value, available.

We can use the Load ID to look up the associated Cabin if we do the following as explained in tn 1.

In case this wasn't covered adequately in tn1 (and it most likely wasn't), where do we get these instance correspondence tables?

Cabins and Loads are not created dynamically in the Elevator Case Study. All Load and Cabin instances, as well as all physical instances are supplied during initialization. This means that the correspondences must also be supplied. The modeler will need to fill in a table, then, like the following:

For these tables to be generated, the modeler must specify the class counterpart join points as follows:

Now we just need some way to know that the parameter in the Passed stop operation is implicitly mapped. If we know this is the case, then we know that we need to do an implicit table lookup to get the value for a wired parameter in the ingress operation. Here's the data we somehow need to connect:

We can see that we are in fact announcing an instance of Stop, identified by its instance reference Stop[ID:5, Load:L9] which must be translated to the Shaft Level instance reference Shaft Level[Shaft:S1, Floor:4]. It's much easier to think in terms of instance references than individual parameters. So we can simply redefine our parameter types to be instance references. So let's do a bit of renaming:

We do need to ensure that the bridge subsystem class diagram is updated to show how EE's and EE params are wired together. Note that these are not join points themselves. We only join metamodel elements and we don't consider an EE parameter to be a metamodel element. It is part of are bridge wiring scheme.

Now it is a matter of mapping the EE operation invocation source and target and then mapping the two instance references.

We have an join point established for the Cabin—Load class counterparts. This means we have a generated instance correlation table filled in during initialization (for this system). This table is consulted to map the invoking Load instances to the target Cabin instance.

Similarly we have a join point established for the Shaft Level-Stop class counterparts. The associated instance correlation table, also filled in at initialization, is consulted to map the parameter values.

Now all that's left is to write the action performed by the ingress operation on the client side. It could be something like this:

&R43 in.Shaft level

Since the incoming parameter is a Shaft Level instance reference and since we presumably supplied a complete instance population, we don't need to do any selection and verification before performing the link. in.Shaft level refers to an existing Shaft Level instance, so the one action is all we need.

We haven't continued the thread into the UI domain yet.