Information Technology Reference
In-Depth Information
2
The Basic Ideas Behind rCOS
The motivation of the research on rCOS is to provide a semantic foundation
for
model driven development
in the combined framework of object-oriented and
component-based software development. Practical software engineering shows
that this is a promising approach to heighten productivity in software develop-
ment while maintaining a high quality. It lets developers design systems at a
higher level of abstraction using models or specifications of components which
will be produced and integrated at a later implementation, assembly and de-
ployment stage.
2.1
rCOS Formulation of Software Concepts
A project using model driven development starts with a set of component spec-
ifications which may be given for previously developed components or be newly
introduced for components that are to be developed later. The designers then
proceed to
-
build new components by applying component operators (connectors) to the
given ones,
-
build new components by programming glue processes,
-
define application work-flows as processes that use services from components,
-
verification and validation are performed on components before and after
composition.
To provide formal support to such a development process, we formulate in rCOS
the key notions as mathematical structures and study the rules for manipula-
tion of these mathematical entities. These notions include
interfaces
,
contracts
of interfaces
,
components
,
processes
,
compositions
and
refinement relations
on
contracts, components and processes. In the next subsection, we give a brief
introduction to formulations.
Interfaces and Contracts.
An interface
I
provides the syntactic type infor-
mation of an interaction point of a component. It consists of two parts, the
data
declaration section
denoted by
I.FDec
, that declares a set of variables with their
types, and the
method declaration section
, denoted by
I.MDec
, that defines a set
of method signatures each with the form
m
(
T
1
in
;
T
2
out
)
. Interfaces are used
for syntactic type checking. The current practical component technologies only
provide syntactical aspects of interfaces and leave the semantics of interfaces to
informal naming schemes. This is obviously not enough for rigorous verification
and validation. For example, a component with only syntactic interfaces shown
in Fig. 1 has no information about its functionality or behavior.
A
contract
is a specification of the semantic details for the interface. How-
ever, different usages of the component in different applications under different
environments may contain different details, and have different properties:
Search WWH ::
Custom Search