How to identify components in architecture - Concluding Part

Lets do a quick recap. We looked at CBSE, explored the benefits of CBSE, defined components, physical component and logical component. With this, I believe we are ready to go for the kill - How to identify components ?

We have classified components as 'logical' and 'physical'. Therefore we need to identify both in software architecture. Lets start with 'logical' components as they are the 'first-cut' components.

Logical Components are identified by "functional decomposition" of the system.

Although it sounds simple, it is not. Software Architecture happens during the initial stages of the project, when, seldom complete requirements are available. In fact all you have is a list of high level features/functionality and not to forget another list of desirable non functional requirements such as performance, usability, extensibility, portability etc. Lastly lets not ignore the constraints imposed by external factors such as technology, management etc. An architect needs to take all of these into consideration while arriving at solution.

Expanding upon the above statement, to identify the logical components of the system, I would recommend the following process -

1. Divide the entire system as a set of functions ( not algorithms). Each and every function should provide a well defined & unique user functionality that is not provided by any other.
2. Ensure that function should have a well defined boundary.
3. Decompose further considering other non functional aspects such as performance, usability, technology, standards etc. to refine the function(s) into component(s). Yeah! this is lot of work and tricky as well.
4. For each component so identified, define an interface.
5. Finally, validate that it fits well with the other components.

These steps will have to be carried out multiple times, until a convincing logical architecture is arrived.

Perhaps an Example would help. Consider a Real time Data Acquisition and Control system for a device connected to the serial port. Lets further assume that the data needs to be displayed on screen as well as recorded to a file. I can see 4 basic functions(and a good starting point) -

1. Data Acquisition
2. Control
3. Display
4. Record

Refining further, Data Acquisition can be further split into 2 components - 1) Data Reader 2) Data Publisher. The second component comes from the architectural style chosen to display/record the data. Since the data is being read real time over the serial bus, a push model is adequate.

Now lets look at Control - A close look reveals that 'Control' involves writing Data to the serial interface. So we need a Data Writer as well. The following figure depicts what we have compiled so far without interfaces.



Continuing with the refinement process..
Since Read & Write services complement each other, I think it makes sense to make it a single component and of course give a suitable name. This is what it all looks like along with the interfaces. Note that there is scope of further refinement, depending upon the requirements as well as application of other architectural styles.




Now having explored an example, let me clarify what did I mean by transformation of logical components. Taking the example above, Data acquisition got transformed (rather morphed) into 2 components - "Device Read/Write services" and "Data Publisher". In other words, a logical component at a higher level of abstraction gets transformed into one or more logical components ( that is closer to implementation) at a lower level of abstraction.

As mentioned before, it does not stop here. For e.g. If the development is done using .NET, then DataSet and DataGrid(for ScreenView) could be chosen for data representation and display. This will lead to further decomposition (perhaps the publisher is no longer required in the ScreenView as DataSet and DataGrid bind well).

Component Identification CheckList - Here is a list of guidelines that can be used to validate the credibility of the logical component. If all of these are positive for a component, then its a good abstraction of a component.

1. Functional Cohesion - The component must fulfill a single goal completely.
2. Well defined Boundary - Simple and well defined interface.
3. Replaceable - Consider change scenarios that could occur in future and ensure that changes are isolated as components.
4. Re-usability - Can it be reused as is? Are there portions that hinder reuse? If so, then there is a need for further decomposition.

That brings us to the end of Logical Component Identification.

I m not going to stress much on physical component identification as it is basically how you package the functionality.Taking the example above, all of the logical component may be packaged into a single executable ( if the deployment dictates that there be no files other than a single executable! ). Alternatively, it makes sense to package the UI components into one package and retain the non UI components (such as DataLogger) as separate DLL(s). Another option is to package the Publisher along with the Device Read/Write services. I leave it open. Although, the best option (unless otherwise constrained by something else) is to leave each of the component as a separate physical component.

This brings to the conclusion of my first technical topic and I would be glad to know what you think of it. I personally feel that i ran through some of the stages. If you want to know in detail or have trouble understanding some of the portions above, i would be more than glad to help.

How to identify components in architecture - II

In my previous blog, I discussed briefly about the advantages of CBSE and ended with a question instead of an answer. To reiterate, the objective is to identify components and to achieve that first we need to define what a component is and then understand the classification of physical and logical.

First this first ! Scope check - It is constrained to the realm of Software Architecture, although i believe it applies in the general sense as well.

Of all the definitions that i know, the one that i find simplest yet most appealing is -
"A component is a reusable software entity that exposes a set of one or more interfaces"

Lets do a reality check ! Is that really how we perceive components ?

For some of us ( or rather most of us), a software component is a COM component, a Dynamic Link Library(DLL), a Shared Object(Unix/Linux), Frameworks ( MFC, ATL), Libraries(QT, RogueWave).. the list goes on and on and on ....Isn't it ?

If you look closely, there is a similarity between the items in the list above. All of them have a physical identity in the sense that they directly consume resources - time as well as space; and indeed match the preceding definition. Incidentally this solves one of the earlier problems of identifying "physical component".

That leaves us with the question - whats a "Logical Component" ?

A Logical Component is also a reusable entity(not necessarily software! could be a model as well ! ) that is representative of complete or a portion of functionality in the system. Does this mean physical component do not encapsulate functionality? Of course they do.. In fact, often, a physical component can packs more than one Logical component. The differentiating factor is a Logical Component may or may not consume resources of time and space.

The reason for this is Logical Component(s) transform into other "forms" that will consume resources of time and space. But why would they "transform" ? That's because Logical Components are one of the earliest conceptions in software architecture and are susceptible to be replaced by other complete forms in the subsequent architecture process.

Time is not with me.. So I will have to keep the concluding part for my next blog. If you have questions, comments or thoughts, drop a note. I would be glad to share ( & learn)...

How to identify components in architecture - I

I never thought I would be posting my second blog so late. Actually I wondered how anyone would get to my blog! Thanks to Divyesh, I realized orkut is the way to go for being noticed.

This is my first tech blog and it is interesting!

In the past few months, i have done this twice and I m not satisfied or rather clear about it. No I m not referring to two blogs ;). Twice i had to go through the process of identifying components in a system for 2 different projects.

Component Based Software Engineering or CBSE, is a software engineering discipline wherein a system is decomposed into functional components having well defined interfaces. The concept is to build a system as an integration of several blocks a.k.a component leading to a modular solution. Keep in mind that components are usually at a higher level of abstraction in terms of 'time and space' than objects as in OOP. The key benefits accrued from CBSE are -

• Software Reuse - Of course if you ever need the functionality again, you can use the component
  
• Pluggability - I like this! Although not a standard quality attribute what this means is you can safely replace one implementation with another and cause little or no impact elsewhere in the system
  
• Smooth Evolution - It is well known that software systems evolve over a period of time. Decomposing into functional components makes the system evolve in a consistent manner without making a mess thus retaining the maintainability
  
• Higher probability of success - This takes the icing and the cake with it! Do you throw away the whole furniture if only a single chair is broken? No. In the same way if a portion of a system is broken, which in CBSE is a component, you only need to throw that component away. The system can still be built and project can continue although with a certain amount of delay.

CBSE is also referred to as CBD or Component Based Development and the architecture itself is called as Component Based Architecture.. I suppose thats enough for background.

So how to identify components ? Wait.. we are not ready yet for that. Before we do that we need to know the difference between 'Logical Components' and 'Physical Components'. I m going to defer it to my next post.

If you have any ideas on CBSE, i m willing to know!