Specifying Architectural Structure

 

Overview of the Structural Instance Language

Acme uses seven core constructs to specify a system’s architectural structure – components, connectors, ports, roles, systems, representations, and properties.  Each of these constructs is described below in detail.

Components and Ports

Components represent the primary computational elements and data stores of a system.  Intuitively, they correspond to the boxes in box-and-line descriptions of software architectures. Typical examples of components include clients, servers, filters, objects, blackboards, and databases.

Components’ interfaces are defined by a set of ports. Each port identifies a point of interaction between the component and its environment. A component may provide multiple interfaces by using multiple ports. A port can represent an interface as simple as a single procedure signature or more complex interfaces such as a collection of procedure calls that must be invoked in a specified order or an event multi-cast interface point.

Connectors and Roles

Connectors represent interactions among components.  Computationally speaking, connectors mediate the communication and coordination activities among components. Informally they provide the "glue" for architectural designs and correspond to the lines in box-and-line descriptions. Examples include simple forms of interaction, such as pipes, procedure call, and event broadcast. But connectors may also represent more complex interactions, such as a client-server protocol or a SQL link between a database and an application. 

Like components, connectors have explicitly specifiable interfaces that are defined by a set of roles. Each role of a connector defines a participant of the interaction represented by the connector. Binary connectors have two roles such as the caller and callee roles of an RPC connector, the reading and writing roles of a pipe, or the sender and receiver roles of a message passing connector.  Other kinds of connectors may have more than two roles. For example, an event broadcast connector might have a single event-announcer role and an arbitrary number of event-receiver roles.

Systems

Systems represent configurations of components and connectors.   A system includes (among other things) a set of components, a set of connectors, and a set of attachments that describe the topology of the system.  An attachment describes the relationship between a connector and a component by associating a port interface on a component with a role interface on a connector.

Example

To illustrate the simple structure language, Example 2.1 describes a trivial architectural specification of a system with two components – a client and a server -- connected by an rpc connector.  The client component is declared to have a single send-request port, and the server has a single receive-request port. The connector has two roles designated caller and callee. The topology of this system is declared by the set of Attachments.

System simple_cs = {

      Component client = { Port send-request }

      Component server = { Port receive-request }

      Connector rpc = { Roles {caller, callee} }

      Attachments {

                           client.send-request to rpc.caller ;

                           server.receive-request to rpc.callee }

}

 

Example 2.1: Simple client-server specification in Acme

 

Representations

Complex architectural designs generally require hierarchical descriptions to provide a specification that is both sufficiently detailed and tractable for individual designers to understand. Recognizing this, Acme supports hierarchical decomposition of architectures.  Specifically, any component or connector can be represented by one or more detailed, lower-level descriptions. Each such description is termed a representation. The use of multiple representations allows Acme to encode multiple views of architectural entities (although there is nothing built into Acme that supports resolution of inter-view correspondences). It also supports the description of encapsulation boundaries, as well as multiple refinement levels.

Properties

There is clearly more of interest in an architectural description of a system than the topology of its components and connectors.  The property construct in Acme provides a mechanism for annotating designs and design elements with detailed, generally non-structural, information.  All of the architectural entities described to this point (components, connectors, ports, roles, systems, and representations) can be annotated with properties.

An Acme property is a name, type, value triple. The Acme type system is described in detail in section 3.

Examples

The following example describes an extension to the simple client-server system given in Example 2.1.  This example has been annotated with properties that describe characteristics of the structural elements of the system.

System simple_cs = {

         Component client = {

                Port send-request;

                Properties {          request-rate : float = 17.0;

                                    source-code : external-file = "CODE-LIB/client.c" }}

 

         Component server = {

                  Port receive-request;

                  Properties { idempotent : boolean = true;

                                             max-concurrent-clients : integer = 1;

                                             source-code : external-file =  "CODE-LIB/server.c" }}

 

         Connector rpc  = {

                  Role caller;

           Role callee;

           Properties { synchronous : boolean = true;

                                      max-roles : integer = 2;

                                      protocol : Wright = "..." }}

 

         Attachments {     client.send-request to rpc.caller ;

                                    server.receive-request to rpc.callee }

}

 

Example 2.2: Simple-client-server system with properties

 

 

Acme structural language syntax

The full Acme BNF is included in Appendix A (along with a description of the BNF notation used here).  A short BNF for the core Acme structural language is provided here.  The simplicity of the core structural language is reflected in the language's short and simple BNF.  This syntax description will be extended and improved throughout this document as new language features are introduced.

System                         ::=  System Name = { EntityDecl* } ;

EntityDecl                     ::=  ComponentDecl
| Connector-Decl
| Port-Decl
| Role-Decl
| Property-Decl
| Rep-Decl
| Attachments-Decl

GenericDecl                 ::=              PropertyDecl | RepDecl;

ComponentDecl            ::=  Component Name = {
            (PortDecl | GenericDecl)* } ;

ConnectorDecl              ::=  Connector Name = {
            (RoleDecl | GenericDecl)* } ;

PortDecl                       ::= Port Name = { GenericDecl * } ;

RoleDecl                      ::= Role Name = { GenericDecl * } ;

AttachmentDecl            ::=  Attachments { (PortName To RoleName)* } ;

Name                           ::=  [a-zA-Z][a-zA-Z0-9_\-+]*

Properties

PropertyDecl                ::= Property Name [ : Type ] = Value
| Properties { (Name [ : Type ] = Value ; ) * } ;

Representations

RepDecl                       ::=  Representation [ Name ]= System
            Bindings = { (Name To Name)* } ;

Meta-properties

Meta-properties are ignored for purposes of semantic evaluation.  At an informal level, a meta-property is a property tuple that applies to a property, rather than an element.  Meta-properties are allowed as annotations on properties for the purposes of tooling, but they have no effect on the underlying semantic meaning of an Acme expression.  Specifically, meta-properties are not considered for type-checking or consistency checking.  It is possible that a future extension of the semantics will support meta-properties by allowing property tuples to recursively include other property tuples (which represent that property’s meta-properties) but this step is not taken in this draft of the Acme semantics specification.

Case sensitivity

Throughout the full Acme language, identifiers for all entities are case sensitive.  This includes user-defined types, instances, design rules, and design analyses.  Keywords, on the other hand, are not case sensitive.