Database Reference
In-Depth Information
also well suited for incremental and iterative development and fast, small solution releases.
Each new iteration cycle adds more functionality to particular components and refi nes the
interfaces among them. Coding practice can be applied at the level of single components,
their sub-components, or a set of collaborative components.
Agility in Component-Based Development
Component-based development can also benefi t from certain principles and mechanisms
used in agile development processes. The main idea behind code refactoring—changing
interior while preserving exposed behavior and semantics—can be effectively applied in
designing fl exible component-based architecture. We propose here a process called component
refactoring, which aims at reallocating and rearranging sub-components of the component
being addressed, while preserving its contractual behavior. Component refactoring can be
performed at two levels. At the fi rst level, the high-level business components are identifi ed
and constructed based on business requirements they fulfi ll and business services they offer.
However, the decision of allocating use cases to particular business service components is not
straightforward, and other criteria, such as existing legacy, business rules, and information
placement must be taken into account. Furthermore, for every system being developed, a
number of so-called changing cases can be defi ned that can be modifi ed in the future. The
process of component refactoring should ensure that the business needs are fulfi lled by the
well-architected set of business components following the principles of lowest coupling
and highest cohesion. At the level of application architecture, the component refactoring
practice can support placing lower-level application components into higher-level business
components. This is especially important in the case when data or computation redundancy
must be avoided, i.e., when an application component is used by several business components
and it must be decided what business component is really responsible for it.
For representation components during the development process we can use standard
UML diagrams enriched with proper extensions (stereotypes and tagged values). For the
purpose of lightweight component modeling that can be easily understood by both business
people and software architects, we propose a new variant of well known Class-Responsibil-
ity-Collaborator (CRC) cards, called CRCC or CRC
2
cards, which stands for Component-
Responsibility-Collaborator-Coordination (Figure 4). In this way the basic properties of each
business component (identifi er, responsibility, collaborating components and coordination)
are specifi ed without going too much into detail, according to AD principles and practice.
At this level, the system architect can communicate and negotiate with the business user
to see whether this initial business component architecture captures all user requirements.
Defi ned cards can provide fast and easy design of the initial business-driven component-
oriented architecture that can be understood by both business and IT sides, and can be
used according to XP principles of simple design, architecture metaphor, rapid feedback
and extensive user involvement. At the same time, the stack of CRC
2
cards can be used for
planning future developments, as well as for delivering tasks (i.e., component development)
to particular developers.
Components and Agile Development Limitations
It is obvious that depending on the kind and nature of the system being developed, its
domain and environment, as well as involved stakeholders, an agile development process
can represent either the right or not proper solution. If short time-to-market and extreme
