On the Definitions of Architecture , Design , and Implementation ( * )

class Decorator { public void Draw(); } class BorderDecorator extends Decorator { public void Draw() { Decorator.Draw(); } private int BorderWidth; } The design model of this program consists of the following: Atoms: C={Decorator, BorderDecorator, int, void} F={BorderDecorator.Draw, Decorator.Draw } Relations: Abstract(Decorator) Member(Decorator.Draw, Decorator) Member(BorderDecorator.Draw, BorderDecorator) Inherit(BorderDecorator, Decorator) Reference(BorderDecorator, int) Invoke(BorderDecorator.Draw, Decorator.Draw) ReturnType(Decorator.Draw, void) ReturnType(BorderDecorator.Draw, void) Table 2 depicts a detailed example of a trivial JavaTM program and a design model that represents it. As this example demonstrates, an object-oriented program is abstracted as a collection of definitions of classes and methods (also routines or function members) and their relations. Atoms represent classes and methods declared in the program, such as the class Decorator and the method Decorator.Draw. Relations represent their correlations, such as Inherit(BorderDecorator,Decorator) Invoke(BorderDecorator.Draw,Decorator.Draw) Note that design models are abstractions which were made to reflect only the structural aspects of computer programs that are relevant to design and architecture. Hence, our analysis focuses on the declarations of program constructions. Obviously, this representation limits the type of reasoning we may perform (e.g., for discussing fairness [24]), but it is appropriate for the purposes of our discussion. 2.2 Specifications, Denotations, and Programs In this subsection, we discuss specifications, programs, and their relations. We make some reasonable assumptions on the languages used to write specifications. These assumptions allow us to provide a clear definition for the intensional criterion (Definition VI). Let us designate SPEC as the set of formal languages of any order [1]. Let SPEC* designate the set of all expressions made in some language in SPEC. A specification is an element of SPEC*. SPEC includes familiar specification languages such as Z [40], as demonstrated in formulas (3.1) and (3.2), and LePUS [9], as demonstrated in formula (2). SPEC also includes programming languages such as Eiffel [28], C++ [41], and JavaTM [18]. Naturally SPEC is not restricted to known programming or specification languages. A specification is only useful if we can determine whether it is “satisfied” or not. Having chosen design models as our semantics we can ask: Does this model “satisfy” our specification? More importantly, we would like to be able to answer the question: Does this program satisfy our specification? To answer these questions, we first define an “instance” of a specification: Definition II. Let φ(x1,.xn) be a first order expression in SPEC*, such that x1,. xn are free variables in φ. Let m designate a design model (Definition I) containing the n-tuple of atoms (a1,.an). Let A be the consistent assignment [1] of a1,. an to x1,. xn. If the result of assignment A in φ is true in m then we say that (a1,.an) is “an instance of φ in the context of A”. If there exists such an assignment A, we say that “m instantiates φ”, written mφ. Definition II extends naturally to n-tuples of sets of atoms of any order, and to include expressions in higher order languages, such as LePUS. Observe that, in the degenerate case where φ has no free variables (also closed formula, sentence), φ is either true or false in each model m . This distinction will serve us in defining the Locality criterion (Definition VIII). What is the expected relation between a program and an instance? An instance is only a part of the program, and depending on the specification, every program can contain zero, one, or any number of instances. In addition, we expect a “program” to be as a specification that is associated with only one design model. The association between “real” programs and design models is provided by a morphism we refer to as the denotation function: Definition III. Let D : SPEC*→M designate a relation that maps each element in a subset of SPEC* into a design model, such that for every expression φ in dom(D ) the domain of D , the following conditions