Design patterns provide guidance to system designers on how to structure individual classes or groups of classes, as well as constraints on the interactions among these classes, to enable them to implement flexible and reliable systems. Patterns are usually described informally. While such informal descriptions are useful and even essential, if we want to be sure that designers precisely and unambiguously understand the requirements that must be met when applying a given pattern, and be able to reliably predict the behaviors the resulting system will exhibit, we also need formal characterizations of the patterns.In this paper, we develop an approach to formalizing design patterns. The requirements that a designer must meet with respect to the structures of the classes, as well as with respect to the behaviors exhibited by the relevant methods, are captured in the responsibilities component of the pattern's specification; the benefits that will result by applying the pattern, in terms of specific behaviors that the resulting system will be guaranteed to exhibit, are captured in the rewards component. One important aspect of many design patterns is their flexibility; our approach is designed to ensure that this flexibility is retained in the formalization of the pattern. We illustrate the approach by applying it to a standard design pattern.

Preparing for an accreditation evaluation under Engineering Criteria 2000 is a demanding task. For many programs, the most challenging requirements of the criteria have to do with establishing mechanisms to obtain input from various constituencies, formulating objectives on the basis of these inputs, formulating outcomes corresponding to each objective, establishing a range of assessment mechanisms to evaluate the program and outcomes, and establishing feedback mechanisms to use the results of the assessment to improve the program. This paper presents the experience of one program and some of the lessons learned.

Reasoning, specification, and verification of Aspect-Oriented (AO) programs presents unique challenges especially as such programs evolve over time. Components, base-code and aspects alike, may be easily added, removed, interchanged, or presently unavailable at unpredictable frequencies. Consequently, modular reasoning of such programs is highly attractive as it enables tractable evolution, otherwise necessitating that the entire program be reexamined each time a component is changed. It is well known, however, that modular reasoning about AO programs is difficult. In this paper, we present our ongoing work in constructing a relyguarantee style reasoning system for the Aspect-Oriented Programming (AOP) paradigm, adopting a trace-based approach to deal with the plug-n-play nature inherent to these programs, thus easing AOP evolution.

No abstract

Engineering Criteria 2000 (EC 2000), the recently revised set of accreditation criteria for engineering programs in the US, places considerable stress on outcomes assessments. EC 2000 requires the assessment results to be used to identify program improvements, and for such usage and the resulting improvements to be documented.While numerous assessment instruments have been developed and discussed in the literature, less attention has been paid to the question of how to use these to improve the programs or to document this usage. In this paper, we present an approach that serves both to identify possible improvements based on the results of assessments, as well as to provide high-quality documentation. As an added bonus, it also helps incoming students and new faculty to get a good understanding of the structure and evolution of the program.