Download
1 / 104
1.05k likes | 1.32k Views
ソフトウェア工学特論（６）. 田中 譲. Utilities for Meme Media. Generic Utility Functions as Pads. To modify a target pad. To coordinate a group of pads. To inspect a target pad. To manage and to retrieve pads. To transport a target pad. The modification of pads. Modification of
E N D
ソフトウェア工学特論（６） 田中 譲
Generic Utility Functions as Pads • To modify a target pad. • To coordinate a group of pads. • To inspect a target pad. • To manage and to retrieve pads. • To transport a target pad.
The modification of pads • Modification of • the controller part of a target pad. • the view part of a target pad. • the model part of a target pad.
The coordination of pads • Spatial coordination. • Temporal coordination. • Spatio-temporal coordination Spatial coordination geometrically arranges pads, while temporal coordination controls the timing of activating pads. Spatio-temporal coordination controls both the activation and the movement of target pads.
The inspection of pads • The inspection examines the structure and the status of a target pad. • For example, the inspection of a composite pad structure represents the composition structure as a tree of components.
The management of pads The management and retrieval store a variety of pads, index them, and help us to find the pads we want.
Utility functions as pads • All these utility functions need to be represented as pads. • Once represented as pads, these functions are easily applied to any pads through direct manipulations by end users. They are mostly represented as base pads on which target pads are placed. • When a pad is pasted on another pad, the child pad usually works as an input and/or output device of the parent pad. However, this is not the only relationship we can define between a pad and its parent. Utility function pads used as base pads apply their functions to their child pads.
How to share events? • Event sharing has the following two ways of implementation. • Events need to be detected at each site. • The detected events are sent to the central arbiter, and made consistent with each other. This arbitration neglects some events if necessary. • Mutually consistent events are applied either to the master copy of the environment, or to all the copies of the environment.
2 Ways of Event Sharing • The former approach requires each slave copy of the environment to work just as a monitor display of what happens to the original copy. Such slave copies are called view copies. • The latter approach requires every copy to have the same set of pads with the same initial states. • Every copy of the same environment has the same pads with the same initial states at the same relative locations on this copy, and receives the same sequence of events.
View Copy • The view copy of a pad can be implemented in either of the following two ways. • The first method multiplies the view part of the original pad, and uses copies of the original view part as the view copies. • The second method uses only a copy of the original’s display image as a view copy. Each copy changes its image whenever the original changes its display image. Such a copy of the original is sometimes called ‘a shadow copy’.
Event Sharing • Event sharing has also two ways of implementation. • The first multiplies the controller of the original pad, and uses each of these copies to detect events at each site. • Detected events are all dispatched to the original pad, and arbitrated there to neglect conflicting events. • This controller-copy method is combined with the view-copy method to define copies of the same environment. Each copy consists of a view copy of the original, and the controller copy of the original. These two components are not locally connected, but remotely connected through the original pad.
Event Sharing • The second way of sharing events uses a special mechanism to intercept all the events over the shared environment. • Intercepted events are arbitrated by a centralized mechanism, and then made consistent with each others. They are sent back to every copy of the shared environment, and applied there. We call this approach the interceptor approach. • The interceptor approach is further classified to the following two approaches. • The first one uses a transparent pad as the event interceptor, which covers a desktop area to make it a shared environment. This pad is called an EventInterceptorPad. • The second approach uses a special base pad to define an event-sharing field. This base pad is called a FieldPad.
Event-sharing with a FieldPad • The event-sharing mechanism with a FieldPad is consistent with the definition of the shared copies of the same composite pad if we consider a pad environment on a FieldPad to be a composite pad with this FieldPad as the base pad. • Only the model part of the base FieldPad is shared by these shared copies.
FieldPad for sharing events • A FieldPad used as the base of an environment cannot physically intercept events unless we change the event dispatch mechanism of each pad. • We solve this problem as follows. Whenever a pad is put over a FieldPad, its controller is replaced with a special controller. When the pad is dragged out from the FieldPad, its controller is changed to the original one. A new controller sends the event information of each event on it to the nearest FieldPad below itself. • This FieldPad receives event information through its view part, which then sends this to its model part. The model part is shared by all the shared copies of this FieldPad, and arbitrates events coming from different copies to make them consistent. It may neglect conflicting events. Each accepted event is sent back to every view part copy of this FieldPad. For each arrival of event information, each view then searches for the pad to apply this event. This pad is found as the outermost pad at the event location. The event location is obtained from the event information.
EventSensingPad and EventApplicationPad • In the real implementation, we divided the function of a FieldPad into two independent functions and implemented each of them as a pad. • An EventSensingPad intercepts each event, translates it to its event information data, and sends this information to the corresponding EventApplicationPad through a slot connection between them. • This EventApplicationPad sends this information to its model part, which arbitrates events coming from different copies to make them consistent. Each accepted event is sent back to every view part copy of the EventApplicationPad. Each view part copy of the EventApplicationPad then searches for the pad to apply this event. This pad is found as the outermost pad at the event location relative to each view of the EventApplicationPad.
When a user applies a user event to a pad P, its controller sends the corresponding event information to the nearest EventSensingPad below P. This information consists of the event type and the relative location of the event over this EventSensingPad. • This EventSensingPad stores this event information in its model slot. Its model notifies its view that its model has been updated. • The view of the EventSensingPad reads this slot value and sends this event information to the event slot of its parent pad EventApplicationPad. • The view of the EventApplicationPad stores this event information into the event slot defined in the model part. This model is shared by more than one view of the same EventApplicationPad. • The model notifies its update to all of its views. Each of these views then reads out the stored event information, and sends it to the controller of the target pad over itself. • Then the controller of the target pad sends the corresponding message to the view of the target pad.
Each view of the EventApplicationPad finds the target pad using the relative location of the event. The target pad over each view of the EventApplicationPad is identified as the outermost pad at this relative location over this view. This method of identifying the target pad from its location is based upon the following two assumptions. First, the EventApplicationPad and the paired EventSensingPad have the same size. Second, the relative locations of pads over a pair of these pads are kept the same among their different copies. • The moving of a pad with a mouse over a FieldPad may generate a large sequence of mouse events that successively changes the state of the FieldPad, which may seriously deteriorates the performance. Our implementation treats each pad moving operation as a single event with two locations as its parameters, the origin and the destination of the movement.
Manipulation of event information data • The separation of the two functions of a FieldPad as an EventSensingPad and an EventApplicationPad allows us to insert a pad between them to filtrate or to modify events that the EventSensingPad sends to the EventApplicationPad.
Manipulation of event information data: Example (1) • During your collaboration with other people, you may have to leave the workspace for a while. When you come back, you may first like to see the sequence of all the events occurred during your absence, and then re-join the collaboration. • The use of a special pad QueuePad as shown in the next figure enables you to temporarily stop the transfer of the shared events to a FieldPad pasted on a shared copy of this QueuePad, to hold all the events in the queue buffer in their arrival order, and to send these stored events one by one to the FieldPad later in response to a user’s request. • Instead of sharing the FieldPad model, this configuration with a FieldPad on each shared copy of this QueuePad shares the QueuePad model. Each view of a QueuePad works as an input queue buffer for data items coming from its model. A new input to a QueuePad changes its model with this input value, and then the model sends this value to its view, or to all of its views if there exist any shared copies of this pad.
Inserting a pad between EventSensingPad and EventApplicationPad
QueuePad • A QueuePad has such slots as #queueInput, #queueOutput, #numberOfEvents, #startToQueue, #outputSingleEvent, and #outputEvents. • The slot #queueInput is used to receive event information from its model or from its parent pad, while the slot #queueOutput holds the first event stored in the queue. • The length of the queue is held by the slot #numberOfEvents. • To start the queuing of events, you can send a ‘true’ to the slot #startToQueue. This also temporarily breaks the transfer of each event either from its model or from its parent pad to its child pad FieldPad. • To output the events stored in the queue to the child pad FieldPad, you can send a ‘true’ either to the slot #outputSingleEvent or to the slot #outputEvents. • The former outputs only the first event of the queue, while the latter outputs all the events in the queue one after another. • Whenever the last event in the queue is output, the QueuePad resumes the direct transfer of each input event either from its model or from its parent pad to the child pad.
Manipulation of event information data: Example (2) • You may sometime want to enlarge or to reduce some copies of the shared environment to arbitrary sizes. • The configuration shown in the next figure answers this requirement. It uses another pad with a slot to store a single event. • This pad is used as the base pad to share event information. The right FieldPad is pasted directly on a copy of this pad with its slot connection to this event-holding slot, while the left one is connected to another copy of this pad via a coordinate-translation pad. This translation pad multiplies each coordinate of the location in the event information coming from its child pad by a specified parameter value, and sends the translated location together with the event type to its parent pad. It also divides each coordinate of the location in the event information coming from its parent pad by the same specified parameter value, and sends the translated location together with the event type to its child pad.
Controllers over FieldPads • Instead of replacing the original pad controller with the special one used only over the FieldPad, we may extend the function of the original controller to work in both ways. • This controller has two switches. Different combinations of their states allow different ways of using pads over an EventSensingPad and/or an EventApplicationPad.
Conflict resolution • The event sharing mechanism using a FieldPad shares event information through its shared copies. • FieldPad is classified among combinatorial pads. • Its next state is determined by the new event information, and does not depend on its current state. • A combinatorial pad may accept a new update request with the higher priority, neglecting the preceding one under the processing, if the pad is still in either the update-request phase or the model-update phase. It cannot accept a new update, neglecting the preceding one under the processing, if it is already in the view-update phase. • Therefore, a FieldPad accepts new event information with the higher priority, neglecting the preceding one under the processing, unless its views are being updated with the preceding one. • The same is true with the EventApplicationPad.
Nested shared environments • FieldPads or pairs of an EventSensingPad and an EventApplicationPad can be overlaid. Shared copies of this composite pad are defined as shown in the next figure. This allows us to define the nesting of more than one different shared space.
Nested shared environments • When an event occurs over the FieldPad FP1 that consists of the EventSensingPad ESP1 and the EventApplicationPad EAP1, it is detected by ESP1 and its information is sent to the EventApplicationPad EAP0 through the EventSensingPad ESP0. The EventApplicationPad EAP0 updates its model, which then sends back this event information to all of its views. The view of EAP0 then propagates this event information to EAP1, which then updates its model. The model of EAP1 is shared by its two views. Its update is propagated to the two views EAP1 and EAP1’. Both of them apply the new event information respectively to pad P and to pad P’. • When an event occurs over the FieldPad FP1’, it is detected by the EventSensingPad ESP1’, and sent to the EventApplicationPad EAP1’, which updates its model with this new event information. Then this model sends this information to its other view FP1, which further sends this information to EAP0 through ESP0. The remaining event application process proceeds in the same way as described above.
Nested shared environments • Every change of event information goes to the bottommost EventApplicationPad to resolve any event conflict. • This process passes the event information from each EventSensingPad to the next underlying EventSensingPad. • The application of each event information goes from the bottommost EventApplicationPad to the target pad. • This process passes event information from each EventApplicationPad to the next overlying EventApplicationPad.
Warm holes among different spaces • Different FieldPads as well as different desktops define different workspaces. We cannot directly move a pad from one workspace to another workspace. We need a special pipe that connects one workspace to another. • We may use the metaphor of a wormhole for this pipe, where the entrance and the exit of each pipe may be respectively called a black hole and a white hole. • Our system provides black holes and white holes as pads. Each black hole may be paired with more than one white hole, while each white hole is paired with only one black hole. • If you drop a pad on the BlackHolePad on the desktop of the user A, this pad is transferred to each of the two WhiteHolePads on the two copies of the same FieldPadone on the desktop of the user A, and the other on the desktop of the user B. Whichever user may drag this pad out of a WhiteHolePad onto a FieldPad, it is moved into the shared space.
An outline of StagePad • StagePad uses a drama metaphor. • StagePad applies the drama metaphor in order to control pads. It can automate whatever tasks a user can do by manipulating more than one document and/or tool composed as pads. • The distinctive feature of StagePad is that all structures are standard since all the elements that comprise a drama are pads. Any composite pad can become a performer on a StagePad, and hence a StagePad with some composite pads on itself may also become a performer of another StagePad. • The composition and decomposition of pads can be also programmed in a StagePad. Thus, the compositional elements of a drama have all been created as components. Furthermore, a drama itself can be made as a component, i.e., a compositional element of another drama
