Loading...
Please wait, while we are loading the content...
Similar Documents
Web-Advertised Generators and Design Wizards
| Content Provider | Semantic Scholar |
|---|---|
| Author | Smaragdakis, Yannis |
| Copyright Year | 1998 |
| Abstract | Automatic programming is the problem of compiling a formal (or high-level) specification into an implementation [Bal85]. Among the many difficulties of automatic programming is navigating the vast space of implementations for a given specification. It is not uncommon that navigation requires human intervention and guidance — much like advanced theorem provers still need human guidance to navigate the space of potential proofs. Our design wizard successfully avoids the need for human guidance for two reasons. First, we are not exhaustively searching the space of all implementations; our approach is reminiscent of human designers that quickly apply design heuristics to produce a credible design without exhaustive searching. Second, the reason why humans quickly home in on candidate designs is that they reason about software at a high-level of abstraction and do not get mired in the minutia of implementation detail. P3 (or GenVoca components) encapsulate precisely this kind of high-level design knowledge for which reasoning about the construction of applications is substantially simplified; low-level implementation details are hidden. In contrast, the rewrites that one finds in typical program translation/automatic programming literature express very tiny effects on programs, where significant numbers of such transformations must be applied to produce largely the same effect that a single GenVoca component produces [Bax92]. We note also that the problem of critiquing component-based software designs is an open problem in software architectures []. Our design wizard is among the first demonstrations of a practical solution to this problem. The techniques we used for optimizing type equations are similar to those of rule-based query optimization [Das95, War97]. Queries are represented by operator trees. Query optimization progressively rewrites an operator tree according to a set of rules, where the goal is to find the tree with lowest cost. From this perspective , the problems are identical. However, there are differences. First, query optimization deals with a rather small set of relational operators, such as join, scan, and sort, whereas type equation optimization potentially deals with a much larger set of layers. Second, constraints among relational operators can be expressed simply by algebraic rewrite rules. In contrast, we do not yet have an algebraic representation for our rules. Moreover, the correct usage of layers requires design rule checking algorithms that we have not yet been able to express as algebraic rewrites. For these reasons, type equation optimization is more difficult than query optimization. We note that arranging layers according … |
| File Format | PDF HTM / HTML |
| Language | English |
| Access Restriction | Open |
| Content Type | Text |
| Resource Type | Article |
