These models are interface automata. When you open the Graph menu, there are commands to compose them with other automata.

For a description of Interface automata and Ptolemy II, see:

Edward A. Lee, Yuhong Xiong. A behavioral type system and its application in Ptolemy II, Formal Aspects of Computing, 16(3):210-237, August 2003.

Interface automata [deH01] have been introduced as an interface theory [deH01a] capable of functioning as a behavioral type system. Behavioral type systems describe dynamic properties of components and their compositions. Like traditional (data) type systems, behavioral type systems can be used to check compatibility of components. In this paper, we use interface automata to devise a behavioral type system for Ptolemy II, leveraging the contravariant and optimistic properties of interface automata to achieve behavioral subtyping and polymorphism. Ptolemy II is a software framework supporting concurrent component composition according to diverse models of computation. In this paper, we focus on representing the communication protocols used in component communication within the behavioral type system. In building this type system, we identify two key limitations in interface automata formalisms; we overcome these limitations with two extensions, transient states and projection automata. In addition to static type checking, we also propose to extend the use of interface automata to the on-line reflection of component states and to run-time type checking, which enable dynamic component creation, morphing application structure, and admission control. We discuss the trade-offs in the design of behavioral type systems.

[deH01] L. de Alfaro and T. A. Henzinger, “Interface Automata,” Proc. of the Joint 8th European Software Engineering Conference and 9th ACM SIGSOFT International Symposium on the Foundations of Software Engineering (ESEC/FSE 01), Austria, 2001.
[deH01a] L. de Alfaro and T. A. Henzinger, “Interface theories for component-based design,” in Proceedings of the First International Workshop on Embedded Software (EMSOFT), Lecture Notes in Computer Science 2211, Springer-Verlag, 2001, pp. 148-165.

These models are interface automaton models for some Ptolemy II components with respect to token passing.

They are:

SDFActor.xml
An SDF sink actor. This actor does not call hasToken() before calling get().
PolyActor.xml
A Polymorphic actor. This actor calls hasToken() before calling get().
SDFDomain.xml
The combination of SDF receiver and scheduler.
DEDomain.xml
The combination of DE receiver and scheduler.

All the other automata are the compositions of two of the automata above. For example, SDFDomain_SDFActor.xml is the composition of SDFDomain.xml and SDFActor.xml. These compositions are computed by the InterfaceAutomaton class, but the Vergil layout is done manually.