Database Reference
In-Depth Information
•
Focus on behavior-driven rather than data-driven service and component concepts.
• Services and components should not correspond to a single business object such
as Customer or Order; they should manage information across the set of objects in
providing required business value-added functionality.
•
Defi ning different scope and granularity levels of components and services.
• It is essential to defi ne different scopes and granularity levels of services fulfi lling
different roles in business/technical system architecture through recursive composition
and choreography. This means that each service can be realized through lower-level
services and at the same time is a part of a higher-level service.
Way of Modeling
The underlying way of modeling of a CBD method should focus on:
Appropriate modeling notation for component and service concepts.
•
• The method should provide proper textual and/or graphical notations for component
and service representation (human-understandable, machine-readable, or graphical
notation) that is uniquely understandable by all actors in the development process.
Defi ning models at different levels of abstraction.
•
• Techniques and mechanisms for defi ning component-based and service-oriented
computational independent models (CIM), platform independent models (PIM) and
platform specifi c models (PSM) of the system being developed are necessary elements
for achieving truly model-driven system development using components and services
(OMG, 2003).
Modeling from various viewpoints using the concepts of component and service.
•
• System should be modeled from different viewpoints in order to refl ect different
concerns in the development process, such as enterprise, information, computational,
engineering and technology (ODP, 1996; Stojanovic, Dahanayake & Sol, 2000). The
concepts of component and service should be integrating factors across the view-
points.
Focus on collaboration, interaction and coordination of components and services.
•
• Components and services should support particular steps of a business process and
should be chained and coordinated in a way to create a business process fl ow. The
modeling focus should be on representing service interaction, nesting, coordination
and mutual dependencies, rather than on component internal realization.
Rigorous component specifi cation.
•
• A precise, formal or semi-formal notation should be available to describe component
specifi cation. This should be suffi cient for a rigorous analysis of the specifi cation
against a user's needs. Precise component specifi cation should be precise and complete
in order to provide easy, straightforward and effective component implementation. It
should also represent the main information support for browsing a COTS catalogue
or a Web Service registry.
Reusability of modeling artifacts.
•
• Single component or the whole patterns of component interactions can be explicitly
modeled, stored in the repository and subsequently reused in further system designs.
Thus, the models beside software code can represent valuable reusable artifacts.
