PTOLEMY II - CiteSeerX

Introduction
associated with such diagrams. Formalizing the semantics is essential if these diagrams are to be used
for system specification and design. Ptolemy II supports exploration of the possible concurrency
semantics. A principle of the project is that the strengths and weaknesses of these alternatives make
them complementary rather than competitive. Thus, interoperability of diverse models is essential.
1.2.5 Architecture Design
Architecture description languages (ADLs), such as Wright [6] and Rapide [97], focus on formalisms
for describing the rich sorts of component interactions that commonly arise in software architecture.
Ptolemy II, by contrast, might be called an architecture design language, because its objective is
not so much to describe existing interactions, but rather to promote coherent software architecture by
imposing some structure on those interactions. Thus, while an ADL might focus on the compatibility
of a sender and receiver in two distinct components, we would focus on a pattern of interactions among
a set of components. Instead of, for example, verifying that a particular protocol in a single port-to-port
interaction does not deadlock [6], we would focus on whether an assemblage of components can deadlock.
It is arguable that our approach is less modular, because components must be designed to the
framework. Typical ADLs can describe pre-existing components, whereas in Ptolemy II, such preexisting
components would have to wrapped in Ptolemy II actors. Moreover, designing components to
a particular interface may limit their reusability, and in fact the interface may not match their needs
FIGURE 1.6. Visual rendition of a Ptolemy II model as a block diagram in Vergil (in the DE domain).
12 Ptolemy II