Acme Project Overview
The Acme design language provides software architects with a rich language for describing software architecture designs, constraints on the evolution of those designs, and architectural design expertise. The types of architectural design expertise that can be captured with the Acme language include design vocabulary, design rules, and architectural styles. In addition to capturing software architecture design expertise, the Acme design language is also a full-fledged software architecture description language in its own right.
The Acme design language is also used as the configuration language for the Acme software architecture design environment. This environment can be rapidly and incrementally configured to use the design expertise captured with the Acme design language. This captured design expertise guides software architects using the Acme environment in the creation of appropriate software system architectures and provides an analytical base to confirm that the system designs produced obey the design rules specified.
This document provides a detailed description of the syntax and the semantics of the Acme design language and illustrates its use as a design specification language for capturing both architectural design expertise and the specifications of individual software architectures. The design environment, and details on how the design language can be used to customize the environment, are not discussed in this document. They will be described in detail in a subsequent technical report.
This document is the first public draft of the Acme Language Reference Manual. It is intended as a detailed proposal for the language that will allow people to begin experimenting with the design language and provide feedback on ways in which it may be improved. Please read the manual with these goals in mind.
As with any design language, Acme[1] must make tradeoffs between competing goals and constituencies. This section enumerates the fundamental principles and design decisions underlying Acme, and discusses the tradeoffs made in defining the language.
The following principles have guided the design of the Acme language.
· Acme focuses on the description of system structure and how that system structure may evolve over time rather than the dynamic run-time behavior of systems.
· Acme is a fundamentally declarative language. Acme specifications describe architectural structure and constraints on that structure; they do not describe operations for modifying or deleting architectural structures. At an informal level, an Acme specification describes the structure of a system and the constraints that must hold on that system. The Acme description itself describes neither how to create the structure of a system, nor how to check that the constraints are satisfied. These operations are embedded in the language processing tools, rather than the language itself.
· Acme uses a single integrated language for describing instances of system architectures and capturing abstract architectural design expertise.
· Acme is built as an extension to the Acme architecture description and interchange language to encourage easy translation to and from Acme. This interchangability should allow Acme users to take advantage of existing and future Acme-based tools and infrastructure.
· The Acme constraint language allows a style or system designer to differentiate between invariant constraints (fundamental design constraints) and heuristics (rules of thumb).
· The Acme constraint language uses a first-order predicate logic-based language to express and package design constraints. This language stays decidable by allowing variables to be quantified only over finite sets.
· Acme uses the following seven core constructs for describing instances of architectural designs: components, connectors, ports, roles, systems, representations, and properties. These constructs are described in greater detail in the following section.
· Acme supports the capture of reusable abstract design expertise with the following core constructs: design element types, property types, design invariants, heuristics, and analyses, and architectural styles. These constructs are also described in greater detail in the following section.
In designing the Acme language, there were two critical classes of tradeoffs to be made. The first class of tradeoff concerns the conflicting goals of making the language well suited for use as a stand-alone textual design language for humans vs. making a machine-manipulable storage format for architectural designs and design expertise. In general, most decisions favored making the language flexible, expressive, and concise for human language users. These decisions were, however, tempered by the need to make everything that can be expressed in the language readily usable by automated tools.
The second critical tradeoff in designing the Acme language deals with the need to make the language rich and intuitive for the software architects and environment designers that make up Acme’s target audience, while keeping the language simple, elegant, and tractable enough to support automated tooling and some degree of semantic formalization. Acme walks a fine line between these two goals, tending to favor richness and naturalness of expression only when doing so does not severely compromise the semantic tractability of the language.
Acme provides seven core constructs for describing instances of architectural designs:
Components represent the primary computational units of a system.
Connectors represent and mediate interactions between components.
Ports represent components' external interfaces.
Roles represent connectors' external interfaces.
Systems are collections of components, connectors, and a description of the topology of the components and connectors.
Properties are annotations that store additional information about elements (components, connectors, ports, roles, and systems).
Representations allow a component, connector, port, or role to describe its design in greater detail by specifying a sub-architecture that refines the parent element.
To support the capture of reusable abstract design expertise, Acme provides the following core language constructs:
Design Element Types are predicates that describe the fundamental structure and constraints of design vocabulary elements.
Property Types are predicates that describe the type and structure of properties.
Design Invariants capture design constraints that must hold in a design.
Design Heuristics capture suggestions for creating effective designs.
Design Analyses are functions computed over instances of architectural designs. Design analyses may be specified in the Acme predicate language or as external functions linked directly into the environment.
Architectural Styles aggregate collections of the previous five constructs for capturing design expertise to form a coherent collection of reusable design expertise.
[1] For the remainder of this document the single term Acme will refer to the Acme design language. The design environment associated with the language will be referred to as the Acme design environment.