Design and Architecture of Complex Software Systems (DACSS)

Assignment 1: Fundamental Architectural Styles (Pipes-and-Filters, Blackboard, Event-driven)

The goal of this assignment is to understand the set of fundamental architectural styles and study how the choice of a particular architectural style affects the solution of a problem.

Our problem is given by a program that simulates the activities of the workers in a furniture factory. The problem can be adapted to be modeled in different styles: Pipes and Filters, Blackboard, and Event bus.

Each student will complete 3 different implementations: using pure Pipes and Filters, Blackboard, and Event bus architectural styles.

The architectural styles assigned for implementation are part of the requirements. You are doing this assignment in order to prove your understanding of these arch styles, by adapting the problem to fit them. The assignment requires that you provide implementations of the Furniture Factory such that they illustrate the definitory characteristics of the imposed styles.

You can freely choose the details for your implementations:

object-oriented or an non-nobject oriented implementation
concurrency or no concurrency
in-process or inter-process

In all the cases, the workers represent the interacting components.

This assignment puts together two lab sessions (corresponding weeks 3 and 4). The duration of this assignment is 2 weeks (results should be presented no later than week 5). Delays bring a penalty of 1 point for each weeek of delay after the deadline.

General grading policy: Grades reflect your individual knowledge and contribution. Each student must complete and present their own solutions. The solutions developed "in group" or copied will be assigned 0(zero) points. Not presenting the assignment is assiogned 4 points.

References:

Lecture notes of weeks 2 and 3
POSA1 - chap.2.2 (for Pipes and Filters and Blackboard), 3.6 (only Publisher-Subscriber - paragraph Event Bus)
S. Gupta, J. Hartkopf, S. Ramaswamy: Event Notifier, a Pattern for Event Notification, online
David Garlan, Mary Shaw, An Introduction to Software Architecture, Technical Report Carnegie-Mellon University, no CMU-CS-94-166, online . (subsections 3.1 - Pipes and Filters, 3.3 - Event-based, 3.5 - Repositories and the exemples in section 4)

Detailed description

Consider a program that simulates the activity of a furniture factory. For simplicity, we assume that the factory only produces chairs, like the one in the figure below:

The factory employs workers for the following jobs:

C = Cut seat
F = Assemble feet
B = Assemble backrest
S = Assemble stabilizer bar
P = Package chair

The technological process imposes the following restrictions: assembling legs and backrest can be done only after the seat was cut; assembly of the stabilizer bar can be done only after the feet are assembled; Packaging can be done only after all assembly operations are finished.

The furniture factory problem (the interactions between its workers) can be modeled as a Pipes and Filters style, as a Blackboard style, or as an Event based style.

Version 1 - The Furniture Factory in Pipes and Filters style

The factory employs specialized workers for each production stage (C, F, B, S, P). Each worker is specialized in doing the operation that represents his job. The workers receive a chair in progess, do their operation on it, and pass the chair further. Workers do not have any responsibility outside strictly doing their specific operation. They do not know which production stages precede or follow theire stage, nor are they guaranteed to know how to behave if their input is not correct. It is the responsibility of the production manager to set up a correct production line (a pipleline), with stages in correct order.

A production line (pipeline) makes chairs of a single type.

An example of a pipeline with 5 workers that assemble that kind of chairs may be composed by following stages: C (cut seats) - F(assemble feet) - B (assemble backrest) - S (assemble stabilizer bar) - P (package). In each stage of the pipeline we have a specialized worker doing the job.
Ion:C, Vasile:F, Petru:B, Gheo:S, Costi:P.

The stages of the pipeline could be also reordered, without affecting the production process of this type of chair:
Ion:C, Petru:B, Vasile:F, Gheo:S, Costi:P.

If the factory wants to diversify its production, producing also a different kind of chairs (i.e., chairs without a backrest), it will set up another pipeline, with only 4 stages:
Ion:C, Vasile:F, Gheo:S, Costi:P.

In the future, the marketing department of the furniture factory plans to come out with a new type of chair that also has armrests. It will hire workers specialized in building armrests (workers of type A - armrest builders) and will set up a new pipeline: C (cut seats) - F(assemble feet) - B (assemble backrest) - A (armrest) - S (assemble stabilizer bar) - P (package).

If the factory wants to diversify its production, the easiest way is to set up a different pipeline for every product(for every type of chair). This has the disadvantage that it will need to hire several workers of the same type (for example, several seat cutters, since every production line needs one). If the factory does not want to hire several workers of the same type, it can try to set up production lines that share certain workers. A worker will be then connected to several input pipes and several output pipes, and he will need to know where to correctly "route" each furniture item.

The definitory characteristic of the pipes-and-filters style is that filters must be easy to reuse by recombination in different orders.

Thus, the specialized workers (the filters):

have no dependencies on each other (no particular specialized worker is allowed to depend on any other particular specialized worker; but a worker is allowed to be aware that he is working in a pipeline setting - he may know that he is exchanging data with some generic worker or by means of some kind of input and output pipes. )
they all handle the same type of data as input and output data. There has to be a common way of representing the "chair in progress", accepted by all the filters as input and output data.
the workers can exchange data only with their neighbors in the pipeline. There is no global shared datastructure or context that can be accessed by all the workers.

Concurrency: The pipes-and-filters version is well suited for concurrency. All the workers can work in the same time, each worker doing its job on another item (chair). Since not all workers work equally fast, or certain production stages take more time than others, it may happen that a worker stays idle, waiting to receive an item, or that a worker waits for somebody to pick up its finished item, such that he may proceed further. It is nice to have the synchronization and buffering of furniture items delegated to the pipes, and not burden the workers to take care of these aspects. A final remark regarding concurrency: its purpose is to keep all the existing components (workers) busy, during the whole lifetime of the factory. It is an incorrect concurrency approach (and extremely expensive!) to just "hire" a new team of workers for every produced item !

In-process or inter-process: The worker filter components can be located all of them in the same process (in this case they could be objects or functions, interacting by method or function calls), with or without thread-level concurrency between them, or they can be located in different processes (in this case they interact via inter process comunication mechanisms).

Disadvantages of the pipes-and-filters factory:

The pipeline organization does not facilitate to use the same resources (workers) to simultaneausly produce a larger variety of furniture items: For example, using the same pieces, it could have: chairs with backrest and armrests, chairs with armrests and without backrest, chairs with no backrest and armrests. Different types of decorations could be invented at later moments and they could be used in new versions of chairs.
Certain operations may take much longer than others and, in order to not become the weak point of the pipelines throughput, several workers could be temporary employed to do this operation. This is difficult with a fixed pipeline.

Version 2 - The Furniture Factory in Blackboard style

The factory activity is organized around new principles, the blackboard principle.

There is a central repository (the blackboard), containing all the furniture items currently in different stages of their production. The workers are more qualified persons, they are able to recognize if an item from the repository needs their intervention and if it is in a stage that allows their intervention. All the workers have access to this repository. They go there, look around, and if they see an item (an unfinished chair) they can work on, they request it, do their work and put it back into the repository.

The figure presents a blackboard with 6 workers. Ion:C, Vasile:F, Viorel:F, Petru:B, Gheo:S, Costi:P.

The definitory characteristics of the blackboard style are:

The workers (knowledge sources) have absolutely no dependencies on each other
The workers exchange data only with the central repository, there is no direct data exchange between any pair of workers
The workers in the blackboard setting have more domain knowledge than their counterparts in the pipes and filter setting: the workers (knowledge sources) must be able to decide themselves, examining the data, if it is the right moment for them to be activated and do their tasks.

Concurrency: The workers may work concurrently, there can be more workers entering the repository looking for work to do, but a chair can be taken by only one worker at a time.

In-process or inter-process: All the workers may run inside the same process (with or without thread-level concurrency), accessing a repository that is a shared data structure, or in different processes accessing a repository which is in a database.

Disadvantages of blackboard: It is very unefficient, the workers do many walks around the repository, hoping that they will find some work for them to do.

Version 3 - The Furniture Factory in Event Bus style

The factory workers get help from a gofer (the Event-bus), that take a chair from a worker who just finished doing its task on it to another worker that may start working on it. When a worker finishes doing its task X on a chair, he just shouts out "Done Task X" and a gofer will take the chair to one of the workers that could do another task on it. The gofer has been previously instructed to know which are the prerequisites for every operation - for eample, that the assembly of the backrest can be done only after the seat was cut. In the beginning, each worker announces its prerequisites (a backrest assembler will subscribe to events of type DONE_SEAT). Thus, when a worker announces that he has finished cutting a seat (publishes event DONE_SEAT), the gofer will take it to one of the workers that assemble backrests.

The set of events could be defined as: DONE_C, DONE_F, DONE_B, DONE_S, DONE_P. Every worker subscribes to the events that are prerequisites for its own job.

Which Event Notifier to use for this homework?

Recommended: The Event Notifier of [Gupta, Hartkopf, Ramaswamy] (discussed in Lecture of week 3). http://www.marco.panizza.name/dispenseTM/slides/exerc/eventNotifier/eventNotifier.html

An implementation of this Event Notifier and an example application using it is provided: EventNotifier.zip. You can use this code in your homework.

If you prefer, you can use various existing third party libraries implementing event busses.

Optional part: Implement an improved EventBus that overcomes certain disadvantages of the simple EventNotifier mentioned before.

The presented Even Notifier offers genericity at the expense of having the Subscribers check in their inform methods the type of the event and doing downcasts to expected types. Implement another Event Bus (or change the given Event Notifier implementation) to solve this issue. Subscribers will not have to implement a fixed Subscriber interface. Every Subscriber should be able to freely declare his event handlers for different event types. You should use Reflection and maybe Annotations. The implementation of this EventBus appears also as Assignment 2-variant A4, since it is based on heavily using Reflection. More details about the requirements and possible solutions are presented in these slides here EvBusAssignment.pdf. Implementing this improved Event Bus and using it in the Furniture Factory problem brings 1 Bonus point for Assignment 1. The complete assignment1 still contains also PipesFilters and Blackboard implementations. The optional bonus part has a deadline extended with 1 week (week 6). If you present this improved EventBus as bonus point of Assignment1, then you will have to choose a different variant for Assignment2.