'
'
Jou mal of Compuler Science & Its Application" June 2006, Vol. 12 No.1
.;r-J
:. '
,"
. .,
.
,
,
.
~
The Attraction and Challenges Of Software Componentization: An experience of AutoBudget
'J.O. DARAMOLAANDO.M. BAMIGBOLA *Department of
Computer and Information Sciences, Covenant University, Otta, Nigeria. (wand iex@yahoo.eom),
Department of Mat hematics, University of Ilorin, IIorin, Nigeria. (ombamigbola@hotmail.com)
ABSTRACT
The ever-growing requirements of use/'s for more advancedfunctionalities ill software systems Itave
ade tlte software development process more complex. This has also created the needfor higher-level abstraction of
oftware systems in order to accurately and sufficiently model real-world systems.
III this paper, we present the attractions and the challenges of software componentizatiol1. Also! we
ive the report of a successful application of this concept in the design lmd development of an automated software for
ecurrent Budgeting and Planning in a tertiary institution. The software christened
"AutoRudget" is a t/lree-tier component-based system that reflects tlte power of software componentization.
ACM Category: Software Engineering
Keywords: Components, Component-based
elopment,
1. INTRODUCTION
Software
componentization,
also
known
as component can be deployed independently and is also
onent-based development entails the conceptualization
subject toofcomposition by a third party e.g., Commercial Off The
are systems as a composition of individual reusable
Shelf(COTS)
parts tools [3].
Software componentization, therefore, involves the dividing of
ponents) that are integrated for coherent interaction in order
systems into components for the purpose of easy development,
hieve the specified requirements of a system. software
A software
deployment
onent by definition is a unit of computation
withand
eptually
specified
interfaces
and
explicit
context
ndencies [3]. It is a modular, deployable and replaceable part
maintenance. TillS form of higher-l eve! abstraction of
software systems becomes attractive because it engenders the
development
system that encapsulates and exposes a set of interfaces
[7], of software system using an approach that is similar to industrial
componentbased
An interface specifies the set of services provided
by a assembly line procedures. This has proved
advantageous by reducing the time and cost of development, at
onent. A
the same bringing a boost to software
1
i
~
The Attraction and Challenges Of Software Componentization:
An experience of AutoBudget
*J.O.
Daramola and O.M. Bamigbola
*Department of Computer and Information Sciences, Covenant University,
Otta, Nigeria. (wandi_ex@yahoo.com).
Department of Mathematics, University of Ilorin, Ilorin, Nigeria.
(ombamigbola@hotmail.com)
ABSTRACT
The ever-growing requirements of users for more advanced functionalities
in software systems have made the software development process more
complex. This has also created the need for higher-level abstraction of software
systems in order to accurately and sufficiently model real-world systems.
In this paper, we present the attractions and the challenges of software
componentization. Also, we give the report of a successful application of this
concept in the design and development of an automated software for Recurrent
Budgeting and Planning in a tertiary institution. The software christened
“AutoBudget” is a three-tier component-based system that reflects the power of
software componentization.
ACM Category: Software Engineering
Keywords: Components, Component-based development,
1. Introduction
2
Software
componentization,
also
known
as
component-based
development entails the conceptualization of software systems as a composition
of individual reusable parts (components) that are integrated for coherent
interaction in order to achieve the specified requirements of a system. A software
component by definition is a unit of computation with conceptually specified
interfaces and explicit context dependencies [3]. It is a modular, deployable and
replaceable part of a system that encapsulates and exposes a set of interfaces
[7], [8]. An interface specifies the set of services provided by a component. A
component can be deployed independently and is also subject to composition by
a third party e.g., Commercial Off The Shelf (COTS) tools [3].
Software componentization, therefore, involves the dividing of software
systems into components for the purpose of easy development, deployment and
maintenance. This form of higher-level abstraction of software systems becomes
attractive because it engenders the development of software system using an
approach that is similar to industrial component-based assembly line procedures.
This has proved advantageous by reducing the time and cost of development, at
the same bringing a boost to software product reliability, maintenance and
efficiency [3].
Although relatively new, software componentization as a software
engineering practice has many advantages. Some of these are clearly
highlighted in this paper with a report of our experience in the application of
software componentization for the development of an automated software
system for recurrent budgeting and planning (named AutoBudget) at the
University of Ilorin, Ilorin in Nigeria.
However, with these also came some challenges which were not only
peculiar to our case study but to software componentization in general.
In section two of this paper, we give an overview issues related to
software componentization. Section three is a report of our experience in terms
of derived advantages and the different challenges encountered during the
application of software componentization concept to the AutoBudget project and
the approach adopted in handling them.
3
2. Attraction of Componentization
The attraction of software componentization or component-based development
stems from a number of reasons. Some of these are:
1.
it affords the opportunity to practice abstraction at the componentlevel which is higher than the object level;
2.
It has the potential to boost the understanding and perception of the
composition of software systems;
3.
It presents ample opportunity for development and application of
reusable components (e.g. COTS);
4.
The inherent reliability of reusable components has the potential to
boost the reliability of composed systems.
5.
The replacibility of components can enhance the maintainability of
systems.
6.
The time and cost of development can be greatly reduced, with the
developer doing more of integration than building from the scratch;
7.
Lastly, apart from the benefits outlined above, It has produced
satisfactory results in terms of efficiency and performance in many
situations.
3. Challenges of componentization
3.1 General Issues
Component-based development or software componentization as a relatively
new field of software engineering is presently faced with a number of challenges
apart from the particular ones mentioned in our experiment with AutoBudget.
Some of the issues and challenges involved in the development and
maintenance of reusable components in general are:
i. Quality control: Since component-based systems are composed of many
components bought or outsourced, the quality control becomes more difficult
since it includes parts from other providers.
Issues like copyrights,
maintenance and upgrade of components becomes complex.
4
ii. Profitability: There is a reduction in the frame of profits since many
components are bought.
iii. Component Generality and Efficiency: It is difficult to build a reusable
component that is simple to use and sufficiently generic to cover the different
aspects of its use. There is also a problem of efficiency, since in most cases
the requirements of the components are usually incomplete and not well
understood [10]. Although, the basic concepts of component functionality may
be clear, the demands on the component interface and behaviour are usually
varied in different components and products. Some components may require
a high level of abstraction while others may require the interface to be on a
more detailed level.
These different types of requirement often lead to
several variants of components, which can be used on different abstraction
levels [3].
iv. Components Maintenance and Upgrade: It is not easy to maintain and
upgrade components due to system evolution , which can be of different
kinds [2], such as:
-Evolution of system requirements, functional and non-functional;
-Evolution of technology related to different domains;
- Evolution of technology used in software products;
- Evolution of technology used for the product development; and
-Evolution of society and business changes.
v. Migration Between Different Platforms: The emergence of the Internet and
the existence of various kinds of operating systems such as UNIX, Window,
Linux, MacOS etc., a requirement for running application distributed over the
network and across different platforms becomes important.
This is,
therefore, an essential attribute of components in component–based systems
[2].
vi. Compatibility: One of the most important factors of successful reusability is
the compatibility between different versions of the components.
A
component can be replaced easily or added to new parts of a system if it is
compatible
with
its
previous
version.
5
Therefore,
the
compatibility
requirements are essential, since smooth upgrading of system running for
many years is required.
vii. Configuration Management: The configuration management of componentbased system is also an important issue due to the heterogeneous nature of
these systems having being constituted from several components with
different behaviours.
viii. Replacibility : The replacibility of components in a component-based system
without re-building the application, especially in performance critical system
is also a challenge in component-based development [2], [3].
3.2 Research Issues
There are also a number of research issues that will greatly affect the
practice of component-based development in the immediate future. Some
of these are:
i.
The assurance and certification of component and component–
based system using appropriate metrics.
ii.
The availability of prediction models for properties of component
assemblies.
iii.
The availability of procedures for verification, testing and checking
of component–based systems.
iv.
The creation of composition reasoning techniques for component
models.
v.
The generation and adaptation of component–based systems.
vi.
The existence of patterns and frameworks for component–based
systems.
vii.
The creation of measures (metrics) for the evaluation of system
properties.
viii.
The determination of trustworthiness of software components and
objective evidences of trustworthiness.
ix.
The creation of extra–functional system properties of components
and component–based systems [4], [13].
6
4. A Case Study of AutoBudget System.
The University of Ilorin is a second-generation University located in the
North-Central geo-political zone of Nigeria. It has an approximate student
population of fifteen thousand, with a staff population of three thousand and five
hundred. The staff is broadly categorized into academic and non-academic staff
[12]. The task of recurrent budgeting in this tertiary institution is an annual
exercise that is always very demanding with a lot of drudgery involved. Also,
there is so much inaccuracy with the un-automated approach, which usually
leads to a prevalence of complaints from different departments and units after the
budgeting exercise. This is mainly due to numerous omissions and inaccurate
budget provisions for prospective staff promotions and other forms of desirable
budgetary inputs. This scenario created the need for an intensive approach that
will produce the desired level of thoroughness and ingenuity that will effectively
cater for all necessary parameters that will generate a sound basis for accurate
fiscal budget plan for every upcoming year. Some of these budget parameters
include fiscal provision for salary and non-salary emoluments of existing staff
positions, provisions for salary and non-salary emoluments of all prospective staff
promotions, expected staff recruitments and other recurrent expenditures of all
departments and units within the institution.
This is ordinarily a hardous task that can best be tackled by adopting a
comprehensive, flexible and highly modular form of abstraction like software
componentization. This is because componentization offers the opportunity to
abstract at a higher level by grouping together the various pockets of similar
object requirements and object interactions that exist within the system as
specific functional components through a process of object aggregation [1], [5].
These components can then be integrated for coherent interaction in order to
achieve the requirements of the whole system. The core requirements of the
AutoBudget system, after the system study was conducted, are given as follows:
i.
Provision of total automation for the budget and fiscal planning process
7
ii.
Provision of budget allocation for all departments and units within the
tertiary institution system.
iii.
Provision for other recurrent expenditures for departments and units.
iv.
Automatic simulation of a new year’s budget using the previous year’s
budget as a template. This should also make use of parameters like:
a. All prospective staff retirements due
b. All prospective staff promotions due
c. The departmental or unit pyramidal structure of staff hierarchy
d. Adjustments of departmental and unit staff budgets in respect of
movement within the available job cadres
v.
Rich query and report facilities for various data views such as
departmental budgets, departmental promotions, departmental staff
list, general staff list, job cadre distribution, budget position distribution,
personal staff records, general expenditure report, central expenditure
report, schedule of proposed revenue report and relevant budget
summaries.
Figure 4.1 shows a modular view of the AutoBudget system.
AutoBudget
Input Functions







Report and Query
functions
Processing Functions
Departmental
Budget
Staff Data
Central Expenditure
General Expenditure
Proposed Revenue


Simulate staff Budget
Simulate other Recurrent
Expenditure (O.R.E) Staff
Departmental Pyramidal Structure
Create Budget Template
8







Simulated Departmental Budget
Edited Budget Report
Central Expenditure Report
General Expenditure Report
Schedule of Proposed Revenue
Budget Summary
Queries
4.1 The Component Architecture of AutoBudget
The AutoBudget system was modelled as a three-tier component-based system
consisting of three layers. These are the Budget User-Interface Component, the
Budget Simulation Component and the Budget Database Component. Figure 4.2
shows the three-tier component-based Conceptual architecture design of
AutoBudget.
The Budget Interface Component (BIC), implements the presentation
logic of the system. It is an ActiveX component with the input capture and report
generation functions. The second layer of the system is the Budget Simulation
Component (BSC), which corresponds to the implementation of the business
logic of the AutoBudget system.
It has a single interface called the
IBudgetSimulate, which is an instance of a DCOM (Distributed COM) that
specifies the four distinct methods that are used for the processing of budget
data. These are:
-
SimulateBudget: which is responsible for the generation of a new
financial year’s budget using the previous year as the template;
-
SimulateORE: which generates a new value per each recurrent
expenditure head based on a specified increment or decrement
factor;
-
PyramidalStruct: which computes the pyramidal structure for a given
department using the existing budget statistics of that department;
-
BudgetTemplate: which transforms a budget records for a particular
year to a basis for the simulation of a new year’s budget.
The Budget Database Component (BDC) has the IBudgetConnect interface
that enables run-time connection with a database of choice using the selected
9
database driver. This Component makes use of an OLE ActiveX Data Object
(ADO) control to achieve the connection Figure 4.3 shows the component
diagram of the AutoBudget System [8], [9].
10
Input interface
Report interface
Budget User Interface
Budget logic
Simulation for Staff Promotion
Budget logic
Budget logic
Simulation for Ordinary
Recurrent Expenditure
-
Budget template
Pyramidal Structure
Database
Drivers
Budget
Database
Figure 4.2 A Three-tier Conceptual Architecture design of AutoBudget
Input
BIC
Report
IBudgetSimulate
IBudgetConnect
BSC
IBudgetSimulate: Methods (1..n)
BDC
IbudgetConnect: Methods (1..n)
Figure 4.3 Overview of Component diagram of AutoBudget
11
4.2 Interface Specification and Code Implementation of AutoBudget
Components
By convention, the Microsoft‘s version of Interface Definition Language (MIDL)
was used to specify component interfaces. An interface specification indicates
the type of services a component can provide to its prospective clients [6]. It
therefore, corresponds to a contract between the component and its clients. As
an example Figure 4.4 shows the IDL specification of the Budget Simulation
Component (BSC) and typical instances of interface methods calls with Visual
Basic.
Import “unknown.idl”
[uuid (5C7DB21-546D-12D3-27BE-005907A7C34F),dual]
interface IBudgetSimulate :IDispatch {
HRESULT BudgetSimulate([in] BSTR budgetyear, [in] BSTR dept_id, [out,retval]
Bool* found );
HRESULT ORESimulate ( [in] BSTR ore_id, [in] float factor, [in] BSTR operator,
[Out,retval] float * ORE_Allocation);
HRESULT PyramidalStruct ([in] BSTR dept_id , [out,retval] float *
pyramidalStructure);
HRESULT BudgetTemplate ([in] BSTR budgetyear, [out,retval] Bool* done);
};
[uuid (5C7DB27-548D-12D3-27B3-005907A7C34F),VERSION (1.0)]
Library BudgetSimulationToolLib {
Importlib(“stdole32.tlb”);
[uuid (5C7DB23-548D-12D3-27BE-005907A7C34F)]
coclass BudgetSimulationTool {
Interface IBudgetSimulate;
};
}
‘Code Sample for Budget Simulation Component interface Method calls with Visual Basic
Dim Simula As IBudgetSimulate ‘declaration of interface-based reference
Set Simula = New BudgetSimulationTool ‘ use of concreateinstance to load component’
Bool found = Simula.BudgetSimulate(“2004”, “9507”) ‘ invocation of BudgetSimulate method for the
department with dept_id = “9507” for the year 2004 budget year
Dim ORE = Simula.ORESimulate(“001”,0.5,”+”) ‘invokes ORESimulate method for recurrent expenditure
head with ore_id = “001” with an adjustment factor of 0.5 and the increment operator .
Dim Pyramidal = Simula.PyramidalStruct(“9507”) ‘ invokes the pyramidal structure determinant method
for the department with dept_id = “9507”
Bool done = Simula.BudgetTemplate(“2003”) ‘ invokes the BudgetTemplate method on the year 2003
budget records”
Figure 4.4 IDL Specification for Budget Simulation Component (BSC)
12
4.3 Post Implementation Experiences
4.3.1 Benefits
Our experience with the software componentization experiment was
generally very pleasant. Some of the advantages derived include:
i.
Increased Understandability: The breaking down of the system into
modular units with specific functionalities made each of these parts to
be self-contained and very easy to understand in terms of system
design and implementation as instances of fault tracing and fault fixing
were much simplified.
ii.
Reuse and Distribution: The development of independently
deployable components made it possible for us to reuse this
components
in
some
other
software
systems
where
similar
functionalities were required. For example, the database component
(BDC) is actually a generic tool that offers the opportunity to
dynamically connect with any kind of database supported by the
Microsoft Windows platform at run time. The Budget Interface
Component (BIC) is also readily customizable for deployment as an
implementation of the presentation logic of many other kinds of
business application systems.
iii. Maintainability: One of the most visible gains derived from this
componentization experiment with AutoBudget is the ease of
maintenance. The system, which has been at work for four years
running, has been very easy to maintain. During these years, the
University Budget and Planning department have had occasion to
request that new report modules be included in the system. Also, there
had been instances of creation of new departments and faculties and
splitting of departments. Furthermore, there had been modifications in
the criteria for determining the promotion of staff of the university as a
result of new administrative policies. All these changes have been well
accommodated and adequately handled by the system, simply by
adding new interfaces and methods to the particular system
13
component concerned. The upgraded components are then used to
replace the older ones. This ensured that compatibility with other
components is still retained without disrupting the balance of the whole
component-based system.
iv. Reliability: The AutoBudget system has proved very credible and
reliable, an attribute that stems directly from the individual reliability of
the components within the system. The fault tolerance and fault
avoidance built into this component was testably high.
v. Efficiency and Performance: The system has performed efficiently
thus far, and the budget simulations have been very accurate.
However, the design of the system was such that after an automated
simulation has been generated, it will still be possible to edit any
particular departmental budget of choice after securing the necessary
authorization. This is to allow for flexibility and discretionary inputs that
can further improve the overall outcome of the budget preparation
process.
4.3.2 Challenges
There were many challenges encountered during the software
componentization experiment with AutoBudget, which underscores some
of the existing issues in component-based software engineering in
general. Some of these are itemized below:
i.
We found the statement of C. Szyperski [11] to be true, which says,
“Developing a reusable component requires three to four times more
resources than developing component which serves a particular case”.
Much programming effort went into the process of building the
reusable components and certifying their behaviour and functionality.
This made the time of development relatively slower. None of the three
components was outsourced or bought from a third party. Rather, we
had three teams of programmers each working on the development of
14
the
three
components
in
parallel
but
with
effective
on-line
communication.
ii. Maintaining
active
communication
among
different
component
developer groups was not as easy as earlier envisaged. The early
sessions of component certification tests carried out by the quality
assurance group identified the need to foster closer communication
among the developer groups to avoid a situation where the different
components will be so much at variance with one another such that
integration becomes difficult, if not impossible. This made the project
management team to introduce a scheme akin to the Joint Application
Development (JAD) methodology into the development process which
facilitated the creation of an inter-group committee of three persons (in
this case the group team leaders) to meet twice a week for regular
interaction. This experience with AutoBudget is a pointer to one of the
most common problems that arise in outsourcing of component-based
development where partners find it difficult to completely implement
contractual agreement due to inadequate communication.
iii. Policy Changes: The evolutionary changes that occurred during the
development of the system were also a source of challenge. There
were several policy developments like creation of new departments,
instances of merging of some separate units under some umbrella
units for budget purposes, which occurred late into when the different
component developer groups had started work. These changes
disrupted the initial design of some components forcing new interfaces
and methods to be introduced in order to cater for this. This is
particularly challenging because of the need for integration and
interoperability among components.
5. Conclusion
Although, still a maturing field of software engineering, software
componentization through the practice of component technology and
15
component-based development has demonstrated its capability to offer
that
new and necessary platform required to enhance the process of
software modelling and abstraction. This is further demonstrated by our
experience with the AutoBudget software system.
References
1.
Bamigbola O.M., Olugbara O.O. and Daramola J.O. (2003): An Object-Oriented Software
Model for Students’ Registration and Examination Result Processing in Nigerian Tertiary
Institutions; Science Focus; 6, 70-80.
2.
Crnkovic, I. and Larsson, M. (2002): Challenges of Component-based development;
Journal of Systems and Software, 61(3),
201-212
3.
Crnkovic, I. (2001): Component-based Software Engineering- New Challenges in Software
Development; Software Focus, 2(14),
127-133
4.
Crnkovic, I., Stafford, J., and Larsson, S. (2002): Composing Systems from Components;
9th IEE conference and Workshop on Engineering of Computer-Based Systems, Lund
University, Lund.
5.
Daramola J.O. (2003): Application of Software engineering and RAD tools; Unpublished
M.Sc Thesis, University of Ilorin, Ilorin, Nigeria.
6.
Jifeng, H., Zhiming, L., and Xiaoshan, L. (2003): Component Calculus; UNU/IIST Report
No. 285
7.
OMG: OMG-Unified Modelling Language Report V1.5; Object Management Group;
http//www.omg.org/
8.
OMG (2000) : The Common Object Request Broker: Architecture and Specification,
Report V.25; OMG Standard Collections.
9.
Microsoft (1996), The Component Object Model Specification; Report V 0.99, Microsoft
Standards, Redmond WA.
10.
Sommerville, I. (1996): Software Engineering; Addison-Wesley, Massachusetts.
11.
Szyperski, C. (1998), Component Software Beyond Object-Oriented Programming;
Addison-Wesley, Massachusetts.
12.
13.
University of Ilorin (2004): University of Ilorin Calendar; University of Ilorin Press, Ilorin.
Eight International SIGSOFT Symposium on Component-based Software Engineering
(CBSE 2005): Software Components at work; call for paper
http://www.cs.wustl.edu/icse05/ ColocatedEvents/ColocatedEvents
16