Temporal Coupling (Part 4)

Deployment

Once we design our application with the element of concurrency, it becomes easier to think and adapt to many concurrent services. The system becomes more flexible.

Architecting the system with independent services helps us to make our configurations dynamic. By planning for decoupling and concurrency, we can also have independent options where we can choose not to be concurrent.

But trying to add concurrency to a non-concurrent system is much more harder. 

If we design to allow for concurrency, we can more easily meet scalability or performance requirements when the time comes—and if the time never comes, we still have the benefit of a cleaner design.

- summary of Deployment, from The Pragmatic Programmer: From Journeyman to Master

Temporal Coupling (Part 3)

Design for Concurrency

It is always easier to make assumptions with linear programming, which might lead to sloppy programming. But concurrency forces us to think more carefully. Because, there are things that can happen at the same time. We’ll see a lot of time based dependencies.

The Java platform exposed more programmers to Multithreaded programming. But threads impose new design constraints, which help us to decouple our code and avoid programming by coincidence.

Consider a windowing system where widgets are created and displayed in two separate steps. In the first step, widgets are created and in the second step, we display them on the screen. This means, no other objects can access the widgets until we show it on the screen.

But in a concurrent system, this may not be true. An object must be in a valid state whenever it is called. They can be called at the most awkward times. We have to ensure that the object is valid at any time it could possibly be called.

Always Design for Concurrency

- summary of Design for Concurrency, from The Pragmatic Programmer: From Journeyman to Master

Temporal Coupling (Part 2)

Workflow

In all projects, we would like to know what all things can happen at the same time, and what must happen in a strict order. This is why we need to know users’ workflow. One way for recording this is to use UML Activity Diagram.

Activity Diagram consists of rounded boxes, representing actions. An arrow from one action leads to another action, which can start after the first action. It also contains a thick line called Synchronization Bar. Once all the actions leading to a synchronization bar are complete, we can then proceed along any arrows leaving the bar. Also, an action can be started at any time if no arrows are leading into it. Activity diagrams can be used for achieving parallelism.

Analyze Workflow to Improve Concurrency


- summary of Workflow, from The Pragmatic Programmer: From Journeyman to Master

Temporal Coupling (Part 1)

Temporal coupling, as the name indicates, is related to time. In software development, we think about time schedules or deadlines. But time should always be a design element of the software. Usually we don’t approach programming with this aspect in mind. Normally, during development or architectural stage, things are always linear. We have plans like - do this after doing that, or method A should be called before calling method B.

This approach is not very flexible, and not very realistic

We should allow concurrency in our programs. Always think about decoupling and ordering dependencies. This helps us to gain flexibility and reduce any time-based dependencies in many areas of development.

- summary of Temporal Coupling, from The Pragmatic Programmer: From Journeyman to Master