Databases Reference
In-Depth Information
Although product-line engineering is fully integrated within KobrA, it is not neces-
sary to develop a product-line when applying KobrA. KobrA extends the usual “binary”
view of components by providing a higher-level representation based on a suite of tightly
related UML diagrams. The method defi nes a component by two main parts: specifi cation,
which describes the externally visible characteristics of a component, and realization, which
describes how a component satisfi es the specifi cation in terms of interactions with lower-
level sub-components. The central artifact in KobrA is the framework, which represents
a collection of KobrA components organized in a tree-structure based on the composition
hierarchy. In KobrA, every behavior-rich element of a system is a
Komponent
, i.e., a KobrA
component. The method uses qualifi ers to distinguish between different kinds of compo-
nents: instance vs. type and specifi cation vs. realization. KobrA supports the principles of
architecture-centric and incremental development. KobrA also includes systematic, rigorous
quality assurance techniques, namely inspections, testing and quality modeling. A KobrA
component has at the same time properties of a class and a package. On the other hand the
role of component interface is not emphasized enough. The composition of components
is defi ned mainly through containment trees, instead of collaboration between component
interfaces. The KobrA approach does not offer strict rules about how to identify components.
The approach rather treats important business domain concepts as components and follows
OO analysis and design on them. The authors of the method are researchers describing a
theoretical approach that has not been extensively proven in practice. The authors propose
a notation that is not standard UML, but rather a custom notation loosely based on UML.
The KobrA method is a broad mix of software engineering guidance for CBD. Much of this
guidance is theoretical, without supporting tools or reports of commercial experience. The
method is based on a number of software engineering principles (parsimony, encapsulation,
and locality) that are often restatements of generally accepted principles for keeping things
simple, separating concerns, and minimizing coupling.
UML Components
Cheesman and Daniels (2000) propose a method called UML Components that is
strongly infl uenced by Catalysis, RUP, and Syntropy (Cook & Daniels, 1994). The method
focuses on the specifi cation of components using the UML. While the method is published
in the topic form, there is no information of its application in practice. The method describes
how to architect and specify enterprise-scale, component-based systems using the UML.
The method gives a detailed explanation of the basic principles of software components and
component-based development, in a manner that establishes a precise set of foundational
defi nitions that are essential in practicing the method. The method discusses how core UML
diagrams such as the Use Case can be used in the context of components. Although, the
method defi nes the six main workfl ows (similar to RUP) as Requirements, Specifi cation,
Provisioning, Assembly, Test, and Deployment, it primarily focuses on the fi rst two. The
specifi cation workfl ow is the most interesting one from the perspective of CBD, and con-
sists of three main sub-workfl ows: component identifi cation, component interaction, and
component specifi cation. For the purpose of component-based design, the method uses the
UML notation enriched with proper extensions, stereotypes and modeling conventions.
The method stops with the activity of Component Specifi cation. It does not offer
the ways to translate the component specifi cation into implementation and verify that the
implementation complies with the specifi cation. The method proposes a number of exten-
