Formal design constraints

Abstract

Large software systems are often built on system platforms that support or enforce specific characteristics of the source code or actual design. These characteristics are either captured informally in design guideline documents or in specialized design and implementation languages. In our view, both approaches are unsatisfactory. Informal descriptions do not allow automated analysis and lead to vague constraint descriptions. The language-based approach leads to different languages for Afferent platforms and even for diflerent versions of the same basic platform. Our approach is to describe and name the constraints separately in a design constraint language called CDL, which is based on an extraordinarily concise logic of parse trees. Designs are then annotated with the names of the constraints they are supposed to satisfy. We discuss how the design constraint language is integrated into a design language environment. We exhibit industrial and experimental evidence that our choice of design constraint language allows us to formalize naturally and succinctly common design characteristics.

Maintaining the consistency of class libraries during their evolution

“…In [13], Klarlund et al consider the profiagation of design constraints of a base telecommunication platform to the applications by means of a general purpose design language. In this approach, design constraints are formally described and named in a design constraint language, called DCL.…”

“…First, it is possible that the base module has certain design properties which must be propagated in order to avoid inconsistencies in the composition of base and inheritor modules [13,201. Second, the base module designer is impeded-to supply efficient implementations.…”

“…'As argued by Minsky [20], be-, cause of their global nature, manual implementations of implicit protocols are not only hard to be realized by the inheritor, but also unreliable, unstable and difficult to verify and to change. Other proposals [13,14] make use of type-systems, or tools built on top of design languages, in order to support the detection of some problematic cases of the first category.…”

“…Except for the general purpose properties outlined so far, particular application domains may have their own specific design properties. For example, Klarlund et al [13] present several examples of properties that are specific for telecommunication applications.…”

Documentación y evolución de componentes reusables

“…Presentan una visón general de algunos problemas pero no ofrecen soluciones particulares. Con relación a este tema el trabajo de [KKS96] ayuda en el chequeo automático de validación de un número de restricciones de diseño. El trabajo de Mezini [Mez97] ayuda además a resolver automáticamente algunos problemas que fueron especificados por diseñadores.…”