Have you ever wondered how much time is spend on repeated changes in module. You, your team and testing teams spend considerable amount of time in making sure existing code base is not broken. At the end, your client is not happy with the turn around time and quality. All the time and good work you and your team spend is not been appreciated. Have you ever felt this? Even other wise what about saving considerable effort in providing new solutions in your existing product ?. I will explain some interesting technical solution which can be applied if you are working in a product company. If you are working on a product or going to develop one, and you expects lots of churn in future below explained technique will help.
Let's take an example of efforts required on a medium churn feature change request from field on an existing product.
If you closely analysis this data and from your experience you can make out that ~3-3.5 WK will be spent on making sure existing code is intact and none of the functionality is broken. That is around 30% of total schedule. How do we save this time or reduce to minimum? First thing comes to your mind will be to, separate the base functionality and feature to different planes. Yes that is what I am trying to explain further, how to achieve that. Feature Processing Environment(FPE) is discussed in details, so read on.
Feature Processing Environment is a different processing environment from the the base application where all the features are getting added. Provide a mechanism from base application code to give a generic call to this environment. Each feature is executed independently in this environment and result is send back to the application code in a pre-defined protocol. Base application code defines pre-defined events from where trigger to FPE is invoked. Once the event notification is received in FPE environment each feature registered for that event will get a chance to look into it and take action if interested. (So you guessed now, that FPE is following Chain Of Responsibility patten). Let us jump into high level diagrams to get inside of it.
FPE Communication Diagrams
FPE Class Diagram
Lets examine the important classes and its responsibilities.
BaseApplTriggerPt1 and BaseApplTriggerPt2 :- These are the application base level trigger from where FPE can be entered.
EventFeatureController :- This is an optional class needs only if required. In this implementation the responsibility of this class is to mould FPEInOutData which is the protocol between FPE and application base. This class also can be used for taking any intermediate action before and after entering the FPE if required.
FeatureProcessor :- This class is the core of the FPE framework and is a singleton pattern. This class holds all the registered feature objects. All the events are notified to this class and in turn invokes the registered feature objects and thus by giving each feature object to take action if it is interested.
FeatureObjectFactory :- This class is responsible for creating all the FPE objects and initialize the objects. During this initialization procedure all the FPE object shall register with FeatureProcessor with interested events.
Feature 1,2,3 :- are the features in this example which has implementation for specific feature.
FPEAction Pool :- This class is optional. In this example this is a flyweight pool where action objects are stored. FPE Feature Object can request for any action objects from this pool and take generic actions.
FPEInOutData :- Is the data structure which is the core of protocol. FPE and base application communicates using this data structure. Only the base application code and FPE Feature Objects understands this structure and all other classes should be unaware of this structure to make sure the FPE frame work is generic.
Registration of FPE Feature Objects and invocation.
During application initialization FeatureObjectFactory creates all the feature objects and initializes using initialize method. Each feature object is aware of the events it is interested in and registers for those events with FeatureProcessor. When application bases passes the events to Feature Processor, this register is used for invoking interested features. This way any new feature addition doesn't need any change in base application code. New feature can be added in FPE without touching the base code.
Let us check again how much effort we saved by using this framework.
We are able to save ~25% with this effort. If you analyse closely, we couldn't save any thing from sanity+system test. This is mainly due to the reason that system test team doesn't believe in the way low level design is organized. Since entire application is rebuild, they have to do the basic sanity + system test. Also the build and packaging effort is still same even with this design. The solution to this problem is adding feature objects dynamically. Means, base code is always same and add feature objects dynamically which can be added and removed run time without providing any new load. Seems interesting... ? Then read on..
Let us enhance our static FPE Object frame work to dynamic FPE object frame work.
To achieve this, we need to depend on some of the OS functions to load, shared objects dynamically. I am using Linux OS, so other OS freaks should check your OS manual for similar functions.
The static'ness' of the FPE is due to FeatureObjectFactory which is hard coded way of creating all FPE objects. So obviously we need to re-work on this class to achieve dynamism. In order to load features dynamically all the features needs to be packaged as separate .so object or group in a .so object library. Call dlopen function to load these .so objects and dlsym to invoke the entry procedure. This will invoke the entry procedure defined in the .so object library. From this entry procedure create the FPE object and register it back to FeatureProcessor. So how do we know the absolute name of the of .so library?
We need to have a dat file (.dat/xml/.txt) where all the names of the shared library names are defined. Introduce a new builder object in FPE frame work to open this dat file and load all .so libraries dynamically. All the library entry procedure names needs to be a common one. In my example code I am using the name as featureEntryProc.
Let's examine the modified class diagram (only important classes are shown).
Main of your program creates and initializes the builder class which in turn parses the XML file and gets the absolute name of the shared objects (.so lib). Using the dynamic loading functions, builder invokes the entry procs in these shared library which in turn creates the FPE objects and register it back to FeatureProcessor. This way for adding any new Feature into your product, all you have to do is to create your own .so having the feature implementation and make an entry in XML file. You need to supply just this .so library and XML file to the field for new feature functionality to be supported in your product.
We are there. Let's get back the sanity effort from Sanity + System Test.
Note:- Note that even though this looks to be straight forward, implementation will have different problems to solve. For example if you are adding FPE into your already existing product, the protocol between base application and FPE needs to be worked with lot of thought. FPE responses shall be very generic and covering all the cases to make sure to avoid rebuild of base product. Another area you need to be careful is where inOutData is passed. FPE should get all the data it is looking from the base application and should have place holders for response. Another point requires thinking is the trigger points from where FPE can be entered.
Check the C++ code sample below to get the complete picture.
http://docs.google.com/Doc?id=ddcxq998_1gx7tcscg&hl=en
Conclusion :- FPE is an efficient way of adding new features dynamically which saves lots of effort in all the states of software life cycle. It not only saves effort but will enable you to deliver features with less turn around time. Since no new build is provided customer's comfort will be high. However, core of the FPE is the framework. Considerable thought and effort should be applied while making the framework to make sure it is generic enough and works in most of the cases.
