Databases Reference
In-Depth Information
Figure 4: Component-Responsibility-Collaborator-Coordination card
Component
Collaborator
Responsibility
Coordination
fl exibility of the system under the constantly and rapidly changing requirements are of the
highest importance, then that is the case for agile development. If the system being built
is rather complex, safety-critical and supposed to be stable over the longer period of time,
then the agile development process may not be the right solution (Turk, France & Rumpe,
2002). The following are the limitations of agile methodologies in terms of the types of
projects where they cannot potentially provide a full support:
Limited support for projects with distributed development teams and resources.
•
Limited support for outsourcing.
•
Limited support for building or using reusable artifacts.
•
Limited support for using legacy systems or Commercial-Off-The-Shelf (COTS)
components.
•
Limited support for projects involving large teams.
•
Limited support for the development of large software systems.
•
Limited support for the development of safety-critical software systems.
•
In our opinion, using the component paradigm can help in overcoming or mitigating
these limitations of agile methodologies. Using the component way of thinking, the whole
problem can be divided into pieces according to cohesive sets of business functionality.
These functional units, called business components, can be specifi ed according to the
defi ned component properties, in an informal, semi-formal or formal way, depending on
a particular situation. The more formal specifi cation of component interfaces can help in
communication between team members and customers when customers are separated from
developers, or a development team is distributed over several locations. Components can
help in an agile project when a particular task should be outsourced to subcontractors. In
that case components related to the task can be specifi ed in a more formal way than in an
ordinary agile project, in order to provide a precisely defi ned subcontracted task. This actually
represents the specifi cation of the components that are outsourced. Additional fl exibility in
a sub-contract specifi cation can be achieved using confi guration context-aware parameters
of components in order to provide easier adoption of possible changing requirements.
Components are about reusability, so each component that normally encapsulates well-
defi ned business or technical functionality can be reused in a similar context in the future.
On the other hand, well-defi ned component-oriented architecture provides using third-party
components such as COTS components or wrapped legacy assets, as long as the interfaces
toward the other components are fulfi lled. In that case an agile project would be responsible
for the rest of the system and its interface to existing third-party solutions. By providing an
effective separation of concerns, the component paradigm can help in supporting the agile
