Formal design constraints

Nils Klarlund, Jari Koistinen, Michael I. Schwartzbach
1996 SIGPLAN notices  
Large software systems are often built on system platforms that support or enforce speci c 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 di erent languages for di erent
more » ... tforms or even for di erent versions of the same 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. ery, exible service execution, and other functionality needed in most telecommunications applications. The characteristics of a platform and an application architecture are expressed as a set of general design constraints. In order to use these platforms in e cient or even correct ways, the programmer must ensure that design constraints are satis ed. Examples of design constraints are: Classes with persistent instances should inherit only from other classes with persistent instances and should not provide asynchronous operations. Classes abstracting hardware resources should provide asynchronous operations and respond through an event channel.
doi:10.1145/236338.236376 fatcat:orhqvapgpjalfb2sefvfddnljy