Abstract form

Mutually Dependent Systems

Posted in Architecture, Development, Modeling by Homam Hosseini on March 11, 2010

In this post I am discussing a problem that I have faced several times in the past year. Simplicity is always a goal in design as it saves resources during development and maintenance. But it’s not always clear which design is simpler. Sometimes a seemingly complex design turns out to be simpler to develop, maintain and extend.

In a master-slave architecture, assume S1 is the master. It produces one or more tasks form a given job and transfers them to S2 (the slave); S2 does the tasks and return the results back to S1. S2, the slave, depends on S1, the master.

If the next time that S1 assigns a task to S2 it uses the information that exists in the result of a previous task that had been assigned to S2 then S1 also depends on S2 and we have a mutually dependent couple.

In our terminology the systems are mutually dependent if and only if S1 uses the information it gained as a result of a previous task that it had already assigned to S2. It doesn’t matter if S2 has completed the previous task or not, but it should have reported something to S1 that is useful for S1 for a next assignment of a task to S2.

If S1 is only using the fact that S2 is busy or free then we don’t call it a mutual dependency. S1 must use the information that is generated by processing a task at S2. For example a MapReduce system is not a mutually dependent system.

Why is it important? You should have already guessed that S2 is the name of a class of slave systems that work with S1. There could be many instances of S2. Let’s define a homogenous mutually dependent system as a system that in which all slaves of S1 are in the same class.

Two slaves are of the same class if they share a common interface for communicating with S1.

Now assume that S3 is also a slave for S1. S3 is in a different class other than S2 if either its input or its output interface is different from S2’s.

When designing mutual dependent systems we have to always decide whether to keep the mutual dependencies or to break them by introducing new nodes. It’s mainly a decision over complexity. The other factor that may affect your decision is the swiftness of the system. Introducing a new node will usually reduce the responsiveness.

Breaking the mutual dependency by using S4 node. Note that S3 is another class and uses a different interface to communicate with S4.

For instance a new node must not be added if S1 waits for S2 to return. Generally you should try to keep the number of nodes as small as possible if the operations are not asynchronous.

Homogenous mutual dependency is OK (when the systems are simple and synchronous) but things get much dirtier as we introduce new classes to the system. On the other hand if extensibility is a goal you should try to avoid mutual dependencies.

For a conclusion, use mutual dependent systems in live systems, when a rapid response is required, and try to avoid them by introducing middle nodes if you have many classes of slaves or if extensibility is a goal.


What is a UI Only Interaction

Posted in Dig and Win, Modeling by Homam Hosseini on December 29, 2008

In our business documents we use a concept named “transaction” to describe requirements and workflows. A transaction is simply a list of jobs including the roles that perform them and their sequential relationship. Although I am not satisfied with this approach, as it is not a standardized discipline, I worked to improve it, you know when your boss keep talking about some sophisticated ideas for more than a year, you have little choices but to endorse his ideas.

Anyway, I was working to model how we deal with UI in this transactions approach yesterday, I thought it’s a good idea to record my work here because I have doubts we ever use my model 🙂

In business documents describing transactions we define some UI elements related to transactions. So a transaction, lets call Tk has a collection of ejTk of UI elements associated with. A UI element could be a composition of other UI elements, in my notation: ejTk = {viejTk}. In contrast with ejTk These viejTk are a matter of importance for UI designers.



Em is a composite UI element:

A transaction (or user interaction) in user perspective changes viejTk to vi’ej’Tk’. The interaction T will be a UI only interaction if and only if j = j’ and k = k’. Business documents don’t deal with these kinds of interactions because they are not part of a transaction. For example if transaction T requires a pack of data D to be collected in UI, the UI designer has freedom to collect all the D in a single form or a wizard (utilizing multiple UI only interaction). The business document that described T has stated there’s a UI element ejT that collects D, it does not matter for the business document if ejT is a composite element or if the UI designer introduces several UI only interactions.
This is a transaction as is seen in UI:
This is a generalization of the concept: