The Rosetta specification language aims to enable system designers to abstractly design complex heterogeneous systems. To this end, Rosetta allows for compositional design to facilitate modularity, separation of concerns, and specification reuse. The behavior of Rosetta components and facets can be viewed as systems, which are well suited for coalgebraic denotation. The previous semantics of Rosetta lacked detail in the denotational work, and had no firm semantic basis for the composition operators. This thesis refreshes previous work on the coalgebraic denotation of Rosetta. It then goes on to define the denotation of the composition operators. Several Rosetta examples using all types of composition serve as a demonstration of the power of composition as well as the clean modular abstraction it affords the designer.
TopBackground
By their nature, complex systems must be viewed from many different perspectives. A building provides comfort (HVAC, plumbing, heating, lighting and aesthetics), shelter (structure and safety), and consumes resources (power, water, maintenance) in addition to supporting its business function. Similarly, an embedded system has weight, must be manufactured, must operate in real-time, generates electromagnetic noise, and consumes power in addition to performing its basic function. These systems requirements are as important as a systems basic function. For example, no one buys a cell phone because it makes phone calls – battery life, weight, interoperability, and smart functions play a huge role in such purchases. Given the importance of these system-level issues, design languages should support their inclusion as first-class citizens in the design process.
Rosetta accommodates these multiple specification views by providing a framework for heterogeneous specification, called domains (Streb et al., 2006; Streb and Alexander, 2006). Each domain defines a modeling vocabulary and semantics for representing information related to some specification viewpoint. The basic building blocks of Rosetta are components and facets use domains to represent system models. A component defines assumptions, definitions, and implications over a set of declarations specifying not only behavior, but assumptions on that behavior and secondary behaviors that follow from the specification. A facet is a component with no assumptions or implications – a basic, ideal model. Every facet or component models a specific system aspect by extending a domain with specific definitions for the system being modeled. For example, an encryption device might be specified in the discrete_time domain while a filter might be written in the frequency domain. In these cases, the domain is serves as the type of the facet.