Database Reference
In-Depth Information
Components are by their nature an excellent way to manage changes. Changes are
not harmful for component-based software since they are localized inside the particular
component or on the interfaces between components, so they cannot be spread across the
system in an uncontrolled manner. By defi ning higher-level, business-driven component-
based architecture that balances business needs and software implementation, developers
protect their investments under changing requirements, and at the same time easily map
the architecture into software code using e.g., advanced model transformers and code gen-
erators. Components can support high quality work, which is one of the main targets in an
agile project, since, if used, COTS components or Web Services are usually pre-tested and
certifi ed through a number of previous usage cases.
Component and service concepts can add signifi cant value to the simple and easily
scalable architectural design in agile development. As stated earlier, agile methodologies do
assume certain design activities but they perform them in a different manner than traditional
methodologies. In our opinion, component concepts can play a signifi cant role in agile ar-
chitecture modeling, design and planning game. Since components are defi ned as providers
of business services at a higher level of abstraction and granularity than traditional objects,
they can be used as the main building blocks of a simple architectural design understand-
able for all involved project stakeholders. By its defi nition a component hides a complexity
of its interior so that components can help in more easily making an architecture metaphor
and architecture prototypes (spikes) as the main design-level artifacts in an agile project.
Components as a mechanism for organizing business requirements in cohesive business
service providers, and at the same time a blueprint of future implementation, can provide
bi-directional traceability between business needs and software artifacts. That certainly helps
in better understanding and communication across the project, and more straightforward
iterations and increments. Good business-driven, component-oriented architecture design
can reduce the need for refactoring (that can be also a time-consuming task), as well as
permanent customer presence, in the case it is not feasible.
The representation of the component in designing architecture can vary in the level of
details, which depends on the project nature. The component can be described through its
main properties defi ned briefl y above, as well as in Stojanovic and Dahanayake (2003a),
using different mechanisms at different levels of formality, such as natural language and
sketches on the whiteboard, business vocabulary on some kind of the cards, formal speci-
fi cation language and contract-based theory in a CASE tool, or software code. Hence, the
level of details in specifying components can be truly scalable, depending on the project
settings. In this way the same component-approach can fi t into really agile projects, as well
as large, safety-critical projects and teams, depending on particular needs.
Among the main issues in AD are test-driven design and the test-before-implementa-
tion principle. Since components are identifi ed and defi ned based on use cases they are
responsible for, as well as information types used by these use cases, it is easy to defi ne test
suite for components based on use cases and conditions related to them. These tests can
guide an effective implementation of components that fulfi ll given business needs. These
tests represent agile black-box unit tests. By putting components together in a plug-and-play
fashion, the whole release can be easily tested as well. Components are well suited for some
coding and implementation practices defi ned in AMs, such as continuous integration, using
coding standards and pair programming. The fi rst release as an important artifact in a XP
project can be easily constructed using components, where some or most of them have just
defi ned interfaces (so-called dummy interfaces) without real implementation. Components are
