Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411507 Posts in 69374 Topics- by 58429 Members - Latest Member: Alternalo

April 26, 2024, 05:09:43 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)Identifying synchronous components design
Pages: [1]
Print
Author Topic: Identifying synchronous components design  (Read 528 times)
ronhartley
Level 0
*


View Profile
« on: July 09, 2017, 10:46:59 AM »

Trying to get some generalization for spreadsheet design (when there is cells, cell has dependencies and compute function, updates are automated) I'm stuck to find similar approaches or any elaboration of the next idea.

The system is acyclic fixed graph of components, for example:

Code:
          (C)+-----+
           +       |
           |       v
    (D)    |      (B)
     +     |       +
     |     v       |
     +--->(A)<-----+

Where A, B – object-oriented components, B (client) depends on A (supplier).

All execution is done in single thread.

We look at one interaction with the system (e.g. process one event in application event loop).

Interaction starts with execution of any component (call of public method of component object).

When component is executed all of its suppliers is completed and in consistent state, component can directly call supplier. When component complete its execution (so its state is consistent), its clients get execution in order of dependencies to update itself.

(optional) The update can be based on events that are fired by suppliers, this events form log. On update client processes event log to know what to do. (Are there any examples of how to do this?) In simple case, it looks like deferred notification from supplier to client.

(optional) Control of execution can be implemented with hooks at the entrance and exit of component (at the exit of public method of component object we can decide where to pass control next).

Example of interaction: (user part is fully shown, the “Ctrl” object represents implementation, and implementation details is omitted)

Code:
       Ctrl    A     B     C     D
         |     |     |     |     |
     +------------------------->+|
         |     |     |     |    ||
         |    +<---------------+||
         |    ||     |     |    ||
         |    +- - - - - - - - >||
         |     |     |     |    ||
         |     |  upd|     |    +|
         +--------->+|     |     |
         |     |    ||     |     |
         |     |    +|  upd|     |
         +--------------->+|     |
         |     |     |    ||     |
         |     |     |    +|     |
     <- -+     |     |     |     |
         |     |     |     |     |

Simpler it can be written like this
D
| A
uB    (update B)
uC

It is possible to call supplier from update:
D
| A
uB
uC
| A
| uB
uD

The key properties of this approach (and advantages over observer pattern) are:
- When component gets control, its supplier subsystem is in consistent state.
- Automatic ordering of updates.

Here some example for A, B, C, D components from the top.
Let's look at the application, that show List of Items, you can add or remove Item.
Proposed decomposition:
A - domain model, controls List of Items;
B - selection, controls witch items is selected; (depends on A);
C - list view, controls widget to display items; (depends on A, B);
D - extension to domain model, external properties of Items; (depends on A);


Logged
Pages: [1]
Print
Jump to:  

Theme orange-lt created by panic