Database Reference
In-Depth Information
with additional diagrams, while Extreme Modeling follows standard UML and uses the
tools for creating executable and testable models. Interestingly, these methodologies do not
include or use any advanced concepts such as components (D'Souza & Wills, 1999) and
services (IBM, 2003). In our opinion, exactly components as providers of services represent-
ing concepts at a higher level of abstraction than traditional classes/objects can signifi cantly
support principles and practices of agile development. Component thinking can provide
mechanisms for effective and agile design up-front that can be straightforwardly mapped
to software code. We strongly believe that the implementation-independent, service-based
component concept can be used as the mechanism for balancing agility and discipline in a
software development project.
Service-Based Component Concept
Components have been so far used mainly as implementation artifacts. However, the
components are equally useful and important if used as modeling and design artifacts in
building the logical architecture of the system. The essence of the component approach is
the explicit separation between the outside and the inside of the component. This means that
only the question of WHAT is considered (what useful services are provided by the particular
building block to the context of its existence), not the HOW (how these services are actually
implemented). In the sequel, some important component properties used in architectural
design and development will be listed, while more details on a component-oriented design
and development approach can be found in Stojanovic and Dahanayake (2003a).
A component fulfi ls a particular role in the context by providing and requiring ser-
vices to/from it. A component has a hidden interior and exposed interface. It participates
in a composition with other components to form a higher-level behavior. At the same time
every component can be represented as a composition of lower-level components. Well-
defi ned behavioral dependencies and coordination of activities between components are of
great importance in achieving the common goal. The metamodel of the basic component
concepts is shown in Figure 2.
According to the role(s) a component plays in the given context, it exposes corre-
sponding behavior by providing and requiring services to/from its context, or by emitting
and receiving events. The services a component provides and requires are the basic part of
its contract. Services can be of different types, such as performing computation, providing
information, communication with the user, etc. They are fully specifi ed in a contract-based
manner using pre-conditions, post-conditions and other types of constraints. A component
must handle, use, create or simply be aware of certain information in order to provide its
services properly. In order to be used in a different context or to be adaptable to the changes
in its context, a component can possess so-called confi guration parameters that can adapt
the component according to new requirements coming from the outside. A component can
possess a set of so-called non-functional parameters that characterize the “quality” of its
behavior. Figure 3 shows the component specifi cation concepts.
Component-Orientation in Agile Development
In our opinion, component concepts presented above represent the clear case for ag-
ile design and development. They can support the most important principles of AD, such
as simplicity, good communication between stakeholders, rapid feedback, and effective
adoption of changes. By focusing on components in representing the problem and propos-
Search WWH ::




Custom Search