Database Reference
In-Depth Information
To achieve the most from CBD, the nature and structure of the whole development
process have to be aligned with the fi ve contingency factors of the analytical framework.
This in turn means that entirely new development methods and tools that are aligned with
CBD and SOA principles are required. Therefore, the framework given above was used to
identify the required method and characteristics for each of the contingency perspectives to
provide a consistent and comprehensive CBD methodology. The requirements were deter-
mined by studying the CBD literature and visionary papers such as Welke (1994), Gartner
Group (1997), Butler Group (1998) and from methodology engineering approaches such
as Kumar and Welke (1992), Dahanayake (1997), Rossi (1998), and Tolvanen (1998). We
then looked at the trends in CBD methodologies and fi nally categorized the requirements
according to the contingencies of the analytical framework. We then presented the fi rst cut of
the evaluation framework with its requirements to a small number of practitioners involved
in CBD application development and incorporated their feedback to provide an improved
framework. The number of experts and the level of expertise at the time of the study was
limited due to the pace of adoption of CBD technology into the local (the Netherlands) sys-
tems and (Dutch) software industry. The analytical framework and its contingency factors
leading to the CBD methodology requirements evaluation framework is as follows:
Way of Thinking
The underlying philosophy of a CBD method should focus on:
Components and services as the main focus of a development process.
•
• The concepts of component and service should be the focus and the
main elements of a method consistently used throughout the system development
lifecycle.
Clear, consistent, and technology-independent component and service concepts.
•
• By defi ning a component as an encapsulated concept with specifi c roles and behavior
in the domain, and with hidden interior and exposed services through interfaces, it
can be easily understood by both business and IT worlds. The component concept
should enable business domain experts to model business processes and requirements
at a higher level, in a domain-specifi c, but implementation-independent way. On the
other hand, application developers retain control over how these component models
are turned into complete applications using advanced component-based technology.
Semi-formal and/or formal defi nition of component and service concepts.
•
• The semantics of the basic component and service concepts should be clearly and
precisely defi ned using the semi-formal way (by defi ning metamodels using e.g.,
the UML and MOF) and/or formal notation (by using Object Constraint Language
(OCL) grammar, mathematical set-theory expressions, or other formal specifi cation
techniques).
Enriched contract-based interface construct.
•
• The interface of a service-based component must be extended beyond simple op-
erations' signatures to represent a real business contract between the provider and
consumer of the service. Complete and precise, implementation-independent service
specifi cation including confi guration and quality-of-service parameters provides ef-
fective mechanisms for service discovery and usage.
