Information about http://www.ics.uci.edu/~franz/Site/pubs-pdf/C12.pdf
Towards Language Support for …
Tags: ality, component oriented programming, computer science university, development resources, franz peter, irvine ca, irvine irvine, language support, michael franz, o thomas, pervasive software, phf, position paper, programming languages, programming position, real time systems, software components, thomas kistler, time programming, university of california irvine,Pages: 5
Language: english
Created: Thu Jan 27 15:17:24 2000
Display cached document
Page 1
Page 2
Page 3
Page 4
Page 5
Towards Language Support for
Component-Oriented Real-Time Programming
(Position Paper)
Michael Franz Peter H. Frš hlich
o Thomas Kistler
franz@uci.edu phf@acm.org kistler@ics.uci.edu
Department of Information and Computer Science
University of California, Irvine
Irvine, CA 92697-3425, USA
Abstract nents. Both can be developed by independent and mutually
unaware vendors, and their composition into a running sys-
Component-oriented programming promises to finally tem be performed by a third party.
make the vision of pervasive software components a re- A component-based approach to software development
ality. In the area of dependable real-time systems, the promises many advantages, almost all of which result from
benefits of increased reuse, reliability, and efficiency make the possibility of vendors specializing in a single domain of
component-oriented programming especially attractive. As expertise. Development resources can thus be concentrated
part of the Lagoona project, we are investigating how com- on a single component (or a single framework), hopefully
ponent-oriented programming can be supported at the level increasing its reliability and efficiency beyond what would
of programming languages. Recently, we have also become be possible otherwise. These qualities make component-
interested in supporting the construction of real-time sys- oriented programming especially attractive for dependable
tems within the Lagoona framework, and we have started real-time and embedded systems, where adherence to strict
exploring the language design space for this domain. We quality standards is of paramount importance.
outline the design of the experimental programming lan- However, the very nature of real-time systems compli-
guage Lagoona and discuss two of its novel features in more cates the composition of independently developed compo-
detail. We also discuss the difficulties we see for integrating nents. Apart from functional requirements, which have
the ideas of component-oriented programming with the re- been expressed successfully in the past, certain non-
quirements of real-time systems. It is our hope that feedback functional requirements--most obviously related to execu-
from the workshop will enable us to more clearly define a tion time constraints--have to be taken into account. Be-
research agenda in this area. sides the goal of making functional and non-functional re-
quirements orthogonal as far as possible, there seems to be
little agreement on how non-functional requirements should
be modelled and enforced [7, 14].
1 Introduction
We have been investigating how to support the
component-oriented paradigm directly at the programming
The vision of pervasive software components has guided language level. The experimental programming language
software engineering research for over three decades [8]. Lagoo na1 achieves this goal better than other currently pop-
Currently, the most promising approach for making this vi- ular languages such as Java [1] and C++ [15]. Recently, we
sion a reality is the idea of component-oriented program- have also become interested in supporting the construction
ming [16]. Component-oriented programming aims to re- of dependable real-time systems within the Lagoo na frame-
place traditional monolithic software systems with reusable work, and we have started exploring the language design
software components and layered component frameworks. space for this domain.
Components extend the capabilities of frameworks, while
frameworks provide an execution environment for compo-
Current address: Transmeta Corporation, 3940 Freedom Circle, Santa 1 An earlier version of Lagoo na, from which the one described here has
Clara, CA 95054, USA, kistler@transmeta.com evolved over the last two years, was described in [5].
Definite results are still pending. We have identified sev- elled by inheritance from an abstract base class or through
eral problems that seem to preclude a straightforward exten- the interface mechanism. However, these approaches have
sion of the Lagoo na model (and more generally component- fundamental limitations in a component-based setting. For
oriented programming) to real-time systems. Nevertheless, example, interfaces and implementations must be statically
some of Lagoo na's mechanisms can be used to support bound to each other (by name) to ensure compatibility [3].
scheduling of non-essential computations within a real-time Lagoo na distinguishes explicitly between messages that
system. It is our hope that feedback from the workshop will define protocols of interaction, and methods that define par-
help us in understanding this paradox better and maybe en- ticular implementations of such a protocol. Messages are
able us to more clearly define a research agenda in this area. "stand-alone" in the sense that they are not subordinate to a
The rest of this paper is organized as follows. Sec- specific language construct such as interfaces or classes in
tion 2 introduces the experimental programming language Java and C++. Instead, messages are declared at the mod-
Lagoo na, focusing mainly on its novel object model. Sec- ule level. As we have discussed elsewhere [6], this is in part
tion 3 outlines the problems we see for integrating the ideas motivated by the observation that messages have to be "an-
of component-oriented programming (and hence Lagoo na) chored" in some static, unchanging place to retain a unique
with the requirements of real-time systems and shows how identity. If they are subordinate to entities such as interfaces
Lagoo na's flexible message-send semantics could be ex- or classes, both of which are usually extensible through sub-
ploited to schedule non-essential computations. typing and subclassing, syntactic and semantic interface in-
compatibilities can arise.
2 The Programming Language Lagoona To define more complex protocols of interaction,
Lagoo na provides message set types to group arbitrary sets
Lagoo na is an imperative, modular, and object-oriented of messages. For example, given messages A, B, C, and
programming language loosely based on Oberon [13]. Note D, the type S = {A, B, C} represents such a group.
that we use the term "object-oriented" somewhat reluctantly Note that a message set type only provides a convenient
because the better term "component-oriented" is not yet name for a set of messages, but messages are not subor-
widely accepted. As will become clear below, Lagoo na dinate to it. New message set types can be constructed from
differs fundamentally from common object-oriented lan- existing ones through "set-like" union and difference op-
guages, for example in the treatment of messages and the erations. For example, the type above could also be ex-
absence of inheritance. pressed as S = {A} + {B, C} - {D}. Compatibility
The basic compilation unit in Lagoo na is the MODULE between two message set types is defined using a subset
as opposed to the class or interface in conventional object- relation between the sets of messages they denote. Given
oriented languages. Modules contain declarations of con- the type T = {A, B, C, D} and variables s: S and
stants, variables, types, procedures, messages, and meth- t: T, the assignment s := t is legal, while the reverse
ods. The core of Lagoo na is a conventional imperative assignment t := s is not. The obvious consequence of
programming language. Basic data types include INTE- this definition is that type compatibility between message
GER, REAL, BOOLEAN, CHAR, and SET. Structured data set types is structural. Nevertheless, this structural com-
types include ARRAY and RECORD. Apart from assignment patibility is safe in Lagoo na because individual messages
commands, Lagoo na supports the usual control structures have and retain unique identities, unlike in languages such
such as IF, CASE, WHILE, REPEAT, FOR, and arithmetic as Java and C++. Furthermore, the combination of set-like
expressions. Sequences of commands or arithmetic ex- operations and structural compatibility enables the expres-
pressions can be abstracted using a standard PROCEDURE sion of subtyping as well as supertyping in a straightforward
mechanism. However, unlike in Oberon, parameter pass- way. Hence variables and formal parameters can be typed
ing modes are expressed abstractly as IN, OUT, or INOUT, "minimally" to exactly specify the relevant interaction pro-
similiar to Ada [12] and the COM Interface Definition Lan- tocol. For example, a method X that only applies the D
guage (IDL) [2, 4]. This allows describing the intended message to some object can be declared as X(INOUT ob-
data-flow across a parameter explicitly, but without com- ject: {D}); instead of having to mandate an imple-
mitting to a certain implementation of parameter passing. mentation of the complete T message set.
While the imperative core of Lagoo na is conservative, its Message set types can be used to reference objects that
object model differs considerably from conventional object- implement the messages denoted by the type in the form of
oriented languages. The fundamental concept "borrowed" methods. In Lagoo na, an object type is basically a record
from the object-oriented paradigm is a form of polymor- type with attached methods (procedures). This idea is fairly
phism: it must be possible to dynamically use different im- standard, except for the fact that object types do not explic-
plementations (component instances) through one and the itly declare which message sets they implement. Rather,
same static interface. In C++ or Java, this would be mod- the structural type compatibility mechanism introduced be-
tween message set types is extended to object types. A vari- denoted by the corresponding message set type. Note that
able of object type Z can be assigned to a variable of mes- this rule applies to all messages, regardless whether they re-
sage set type S if and only if Z implements (has methods turn a result. If a message is sent to an object type variable,
for) all messages denoted by S. However, between two ob- and if the message returns a result, an implementation for
ject types, name-based compatibility is used, since record it must statically exist in the object type. If it does not re-
fields are still subordinate to their type and thus are not turn a result, the message might be handled (possibly after
unique. cascaded forwarding), it might be ignored, or an exception
Compatibility between message set types and object might be raised. Hence developers can decide on the ex-
types is checked when they are actually used in assignments act message-sending semantics they need at a fine-grained
or as actual parameters. This supports the evolution of soft- level.
ware components better than static declarations do, at the From an architectural perspective, the availability of
price of detecting certain type-errors "slightly" later. Note source-language support for fine-grained message forward-
that this is also important when a component implements ing (at the level of individual objects) makes it possible to
messages that might not even be known to the rest of the structure software systems in a particularly straightforward
composed system. Furthermore, a method can implement manner. In most cases, the resulting systems are less com-
multiple messages of compatible signature if the developer plex than corresponding object-oriented systems because
of the method decides that they are semantically compati- all control flow is explicit. In Lagoo na, code-reuse that
ble. Hence duplication of method bodies can be avoided and in object-oriented systems would be achieved by inheriting
no additional forwarding methods have to be introduced. from a class that already has the desired behavior is instead
Instead of inheritance (in the sense of reuse of field or realized by forwarding messages to an object that performs
method declarations in a subclass), Lagoo na provides a the operation on behalf of the original receiver. The imple-
generic message forwarding mechanism. Avoiding inher- mentation challenge is to remove the overhead of this (pos-
itance (and delegation) helps to guard against certain se- sibly cascaded) dispatch and make it no more costly than a
mantic problems caused by the self-referential nature of this virtual function call in an object-oriented language.
mechanism [9]. It has been shown that restricting inheri- Programming in Lagoo na has certain similarities with
tance (and delegation) for safety purposes in a component- object-oriented programming, but also important differ-
based setting essentially makes inheritance equivalent to ences. The central activity in object-oriented program
forwarding [10, 17]. Therefore we rely on forwarding from development is typically that of incrementally modifying
the outset, which also provides for more uniform software a given application framework through subclassing and
architectures (see below). method overriding. In contrast to this "incremental modi-
fication" paradigm, system-building in Lagoo na is strictly
The generic forwarding mechanism works as follows.
compositional: a program is assembled using pre-existing
When an object receives a message, and a correspond-
objects and newly created objects by connecting them us-
ing method implementing this message exists in the object
ing appropriate "pipes." Hence, Lagoo na takes the overall
type, that method is executed. If no matching method is
system architecture already in widespread use at the macro-
found, but the special method DEFAULT is implemented,
scopic level in component-oriented systems and pushes it
it is executed instead. Inside a default method we can re-
down to the microscopic level of individual objects, yield-
send the message to other objects. However, resending is
ing a structural uniformity across all levels of abstrac-
a generic operation in which the actual message remains
tion. We contend that message forwarding is a "natu-
opaque. Note that an empty default method can be used to
ral" paradigm for component-based systems since it uni-
ignore all messages an object does not explicitly implement.
formly applies to intra-component messaging as well as
Furthermore, the forwarding mechanism can be used to em-
inter-component communication.
ulate the semantics of both static and dynamic inheritance
if the original receiver is passed as an explicit parameter.
If neither a matching method nor a default method exists, 3 Towards a Real-Time Variant of Lagoona
execution is aborted with an exception.
For this flexible message forwarding approach to be safe, The first obvious step for extending Lagoo na with sup-
some restrictions on message-sends have to be imposed. In port for dependable real-time systems would be the addition
particular, for messages that return a result, we must be able of a tasking model and suitable synchronization primitives.
to statically determine whether they are handled or not. Oth- We do not believe that this extension poses any particular
erwise using the result of the message-send would be un- problems, except maybe for the parametrization of tasks ac-
sound. In Lagoo na, we decided to offer two clear alterna- cording to various relevant scheduling and behavioral poli-
tives to the programmer. If a message is sent to a message cies. In what follows, we assume that some form of tasking
set variable, it must statically exist in the set of messages model is already available.
The addition of real-time constraints seems to be a much putation is iterative it might be feasible to terminate the
more difficult problem. A central issue is which lan- computation early and return the last consistent result as
guage constructs should be annotated with such constraints, soon as the timing constraints are approaching.
and in what form the annotations should be expressed. In Lagoo na, such a problem can be solved by using a
Unfortunately, several previously feasible approaches to guaranteed message-send for essential computations while
real-time systems are fundamentally incompatible with the successive refinements can be obtained through an op-
component-oriented paradigm. This stems from the fact tional message-send. The idea of optional message-sends
that the latter specify functional requirements (i.e., inter- is that they can be skipped automatically as the deadline ap-
faces and their semantics), whereas the former additionally proaches. As described in Section 2 above, message-sends
specify non-functional constraints on the behavior of appli- can be ignored if (a) the message does not return a result,
cations (i.e., component interactions as well as their timing (b) the message is sent to a variable of an object type, and
constraints). (c) no implementation for the message is statically visible
As an example, individual methods can not sensibly be in the object type. 2 By consciously modeling the system in
annotated with timing constraints such as an upper bound a way that (ac) hold for all non-essential computations, we
associated with their execution. This is because timing con- can give the scheduler more flexibility to achieve a deadline
straints are usually global properties of an application and by ignoring these message sends completely.
not local to an individual component. One system might Another example for non-essential computations are de-
impose an end-to-end deadline for a sequence of message- bugging and logging operations. These operations are often
sends, requiring a given method to perform its task in 10ms. removed from a production version of the system in order
However, in another system using different call chains and to increase its efficiency. However, in the case of a failure it
a different end-to-end deadline, the same method might be could still be useful to have as much information as possible
required to perform its task in only 5ms. Constraining com- logged.
ponents on a per method basis therefore inherently limits
the reuse of a given component across different constraint Acknowledgements
systems. Annotating messages (and therefore interfaces)
might seem to work better. However, if functionally equiva- We would like to thank Ziemowit Laski and Christian Stork
lent messages specify different timebounds as parts of their for valuable comments on an earlier version of this paper.
semantics, the number of functionally equivalent but still We are also grateful to the participants of the Lagoo na mail-
incompatible interfaces would explode, again affecting the ing list. This work was partially supported by the National
potential for reuse negatively. Science Foundation under grant EIA-9975053.
Instead of specifying timing constraints on a per method
or per message basis, the specification of real-time con- References
straints could also be separated from the specification of the
functional behavior (e.g., using a special real-time synchro- [1] K. Arnold and J. Gosling. The Java Programming Lan-
nizers language [11]). However, this scheme is also par- guage. Addison-Wesley, second edition, 1998.
tially incompatible with the component-oriented paradigm. [2] D. Box. Essential COM. Addison-Wesley, 1998.
[3] M. Bš chi and W. Weck. Compound types for Java. In A. M.
u
Not only does it not scale because the specification of con-
Berman, editor, Proceedings of the 1998 ACM SIGPLAN
straints grows linearly with the size of applications, but Conference on Object-Oriented Programming Systems, Lan-
specifying a real-time component also requires the full un- guages, and Applications (OOPSLA'98), pages 362373,
derstanding of the component implementation and its inter- Oct. 1998. Published as SIGPLAN Notices 33(10), Octo-
action schemes, which contradicts the notion of black-box ber 1998.
reuse. In light of these facts, it is still an open question how [4] M. Corporation. The Component Object Model (Version
timing constraints can best be specified at the programming 0.9), Oct. 1995. Available at http://www.microsoft.com/
language level to facilitate component reuse across different COM/resources/COM1598C.ZIP.
systems and platforms. [5] M. Franz. The programming language Lagoo na: A fresh
look at object-orientation. Software -- Concepts and Tools,
However, the flexible message-send semantics of 18(1):1426, Mar. 1997.
Lagoo na could potentially be used to the benefit of a real- [6] P. H. Frš hlich and M. Franz. Component-oriented program-
o
time system in the area of non-essential computations. One ming in object-oriented languages. Technical Report 99-49,
example of a non-essential computation can be found in al- Department of Information and Computer Science, Univer-
gorithms that are iterative and produce successively refined sity of California, Irvine, Oct. 28, 1999. Revised Dec. 11,
results. In such cases, upper bounds for timing constraints 1999. Available at http://www.peter.froehlich.com/.
are extremely difficult to find because they might intricately 2 Alternatively a second, non-binding message-send operator could be
depend on dynamic input data. Nevertheless, since the com- introduced to make this behavior more explicit.
[7] M. Lycett and R. J. Paul. Component-based development:
Dealing with non-functional aspects of architecture. In
Weck et al. [19].
[8] M. D. McIlroy. Mass produced software components. In
Proceedings of the Nato Software Engineering Conference,
Garmisch, Germany, pages 138155, Oct. 1969. Available
at http://www.cs.dartmouth.edu/~doug/components.txt.
[9] L. Mikhajlov and E. Sekerinski. The fragile base class prob-
lem and its solution. Technical Report 117, Turku Center
for Computer Science, Lemminkš isenkatu 14, FIN-20520
a
Turku, Finland, June 1997.
[10] L. Mikhajlov, E. Sekerinski, and L. Linas. Develop-
ing components in the presence of re-entrance. Techni-
cal Report 239, Turku Center for Computer Science, Lem-
minkš isenkatu 14, FIN-20520 Turku, Finland, Feb. 1999.
a
[11] B. Nielsen and G. Agha. Towards re-usable real-time ob-
jects. Technical Report RS-98-44, BRICS, Department of
Computer Science, University of Aarhus, Ny Munkegade,
building 540, DK-8000 Aarhus C, Denmark, Dec. 1998.
Available at http://www.brics.dk/RS/98/44/index.html.
[12] I. S. Organization. (ISO/IEC 8652:1995): Information Tech-
nology -- Programming Languages -- Ada. 1995.
[13] M. Reiser and N. Wirth. Programming in Oberon: Steps
beyond Pascal and Modula. Addison-Wesley, 1992.
[14] B. Robben, F. Matthijs, W. Joosen, B. Vanhaute, and P. Ver-
baeten. Components for non-functional requirements. In
Weck et al. [19].
[15] B. Stroustrup. The C++ Programming Language. Addison-
Wesley, third edition, 1997.
[16] C. Szyperski. Component Software: Beyond Object-
Oriented Programming. Addison-Wesley, 1998.
[17] W. Weck. Inheritance using contracts and object composi-
tion. In Weck et al. [18], pages 105112.
[18] W. Weck, J. Bosch, and C. Szyperski, editors. Proceed-
ings of the Second International Workshop on Component-
Oriented Programming (WCOP'97), number 5 in TUCS
General Publications, Turku Center for Computer Science,
Lemminkš isenkatu 14, FIN-20520 Turku, Finland, Sept.
a
1997.
[19] W. Weck, J. Bosch, and C. Szyperski, editors. Proceed-
ings of the Third International Workshop on Component-
Oriented Programming (WCOP'98), number 10 in TUCS
General Publications, Turku Center for Computer Science,
Lemminkš isenkatu 14, FIN-20520 Turku, Finland, Oct.
a
1998.