CSE584 Software Engineering
Derrick Tucker

Design

Paper	Key Concept/Idea	Summary	Comments
Parnas. 1972.	importance of decomposition strategies; "uses" and program hierarchy	Classic paper in the field illustrates how decomposition strategy affects system properties, notably, each of modification and extension an assertion: "It is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart" -- But what about pipe and filter systems? -- instead, start with a list of difficult or changeable design decisions and isolate one to a module.	This is an early paper, so the comments on decomposition, information hiding, and hierarchical structure probably carried more weight when the paper was written than they do now. The assertion -- a possible practical lesson to take from the paper -- is suspect. (Pipes and filters.) It would be useful to think in terms of the other architectural styles in Garlan and Shaw to see how robust the ideas are. It seems that the basic insight of the paper when it was written was that decomposition strategy matters, and the naive, functional approach to decomposition probably is wrong.
Parnas. 1979.	"uses" and program hierarchy	Extends the discussion of "uses" [Parnas, 1972]; treats the concept more formally; focuses on functional extension and contraction of a system as a decomposition-guiding criteria argues for a design hierarchy structured by the "uses" relationship the virtual machine concept is useful for understanding the benefits of the approach without the structure, complex and cyclical interdependencies among modules (may) exist and families of programs understood as extensions and, particularly, subsets of a single system cannot be easily implemented stops short of arguing for strict enforcement of the uses hierarchy (... I think I read) a useful analogy for me is with the discipline of stratified datalog programs in the databases literature	The "uses" hierarchy seems like an extremely useful discipline, especially during development. It provides a coherent strategy for (1) backing away from overly ambitious goals and (2) ensuring that some system testing can be done early -- even if the timelines slip -- if the implementation milestones are scheduled right. Both are common development problems. Questions: Can all reasonable systems be designed with a strictly enforced "uses" hierarchy? (Probably.) Has this been studied? Could the enforcement of the hierarchy be wired into the project description in a programming development environment? (Probably.) Has this been done?
Sullivan and Notkin. 1990.	mediators; event-based, implicit invocation	The key contribution, and innovative idea in this paper is not the event-based architecture (is it?), but rather coupling the event-based architecture with mediators -- first-class components that encapsulate and localize relationship coordination among other components. Mediators are added to the event message bus and register their interest in certain events. When the events of interest occur, the mediator can take the appropriate actions to coordinate the relationship between the signaler and other components. With this design strategy independence and modularity of components -- for the coordinating components and the mediator -- is maintained. The related components do not have to worry about each other; they only need to notify the system.	A recurrent problem in reading research papers is trying to understand the historical context in which a particular paper was written. With this paper, it is not entirely clear what is original -- beyond the idea of a mediator. Coming to the paper from a naive perspective, but in the context of the Garlan and Shaw paper, this is one useful architecture, among others, but with the weaknesses noted by Garlan and Shaw: the primary disadvantage of implicit invocation is that components relinquish control over the computation performed by the system -- a component has no idea what components respond to an event and what, if anything, is done worse, it cannot rely on the order in which other components are invoked; nor can it know when they are finished exchange of data: sometimes data can be passed with the event, but in other situations event systems must rely on a shared repository for interaction; in these cases global performance and resource management can become a serious issue reasoning about correctness can be problematic Looks great on paper, but I do not have enough practical experience to know how well it works in practice.
Kiczales. 1996.	open implementation	Makes the case, convincingly, that clients sometimes need control of the implementation to tailor it to the needs of the application. Discusses one way in which the implementation can be opened up to the client: pragmas plus meta-interfaces. Summarizes the open issues that need or are receiving attention designing meta-interfaces deciding what to expose to the client devising implementation technologies studying existing instances of open implementation	I can imagine that some students in the class liked this paper because it spoke to issues they face in their daily work, like having to code between the lines to fine tune an application to achieve adequate performance. But, while the material may be of practical importance, it is not that interesting to me. I am more concerned about the larger and more fundamental problem of how to design systems that can be modified without getting bogged down in their own complexity.
Garlan and Shaw. 1994.	topology of architectural styles: pipes and filters data abstraction and object-oriented design event-based, implicit invocation layered systems repositories table driven interpreters mentioned: client-server main program/subroutines state transition systems process control systems	The paper focuses on 6 distinct architectural styles -- there are others. Their intent is to: illustrate the current state of the field examine how architecture effects software design survey alternative design strategies, including the strengths, weaknesses, and illustrative domains. argue that this appreciation of design alternatives, which typically is gained from experience by practicing software engineers, is neglected in undergraduate education, and can be introduced with considerable benefit to students. (I agree.)	I found this paper to be the single most interesting and useful of this collection. Given my background, the explicit discussion of the different architectural styles is a very useful tool to organize my thinking about systems I have met and those I may meet. Makes the implicit explicit. Main weakness: the treatment, especially of strengths, weaknesses, and domains of applicability, is incomplete and uneven. Left me wanting a fuller treatment, which, unfortunately, is not provided by the authors in their book on this material, either. (The book includes related material and more cases, but almost a verbatim reproduction of this treatment of architectural styles.)
Gamma et al. 1993.	design patterns	The design patterns agenda is to identify, name, and abstract common themes in object-oriented design. The idea is to help designers and implementors work more effectively by using (and reusing) a vocabulary of more general, abstract, and therefore, robust design ideas. "Design patterns can be considered reusable micro-architectures..."	I see the three papers (Gamma et al., Johnson, and Sullivan and Knight) as addressing the same question at different scales. The shared question is: How to design and develop more robust systems more productively by reusing existing ideas and components. This paper (Gamma et al.) tackles this question at the lowest level of the three. At the same time its approach is the most abstract and generic of the three. What they are trying to do is raise the level of thinking to larger and more robust components. This is useful, indeed, needed. The next step in developing this approach is to articulate how the design patterns themselves can be combined (should be combined) to create larger useful components, or perhaps, subsystems.
Johnson. 1997.	frameworks	"Frameworks are an object-oriented reuse technique that are [is] widely used in industry but not discussed much by the software engineering research community." Okay. Also, "a framework is a reusable design of all or part of a system that is represented by a set of abstract classes and the way their instances interact." And finally, "a framework is the skeleton of an application that can be customized by an application developer." I think the most useful way to think about a framework is as an implemented architectural design over an application design space.	Examples: OWL, MFC, Java Beans (?) Comment on the paper: No publication info is given for this paper, and it does read like a working draft: it rambles, it is conversational, and just about every point is followed by a counterpoint -- "On the one hand, . . . . On the other hand, . . . ," such that it is hard to figure out exactly what Johnson thinks. The designers and implementers of a (good and reasonably mature) framwork have struggled through the design decisions and included components that allow the user to do most things that are plausible to do in the application design space in a reasonably straightforward and efficient way. The components in the framework are relatively small (light-weight). The key to the usefulness of a framework is the coverage of the design space. Compared to design patterns, the abstractions are much more domain-specific, and less robust, and there has been a great deal of work on how they work together. The real gain for the user is not as much the inherent usefulness of the components themselves as the architectural spadework that the user needs to understand, but does not need to recreate.
Sullivan and Knight. 1996.	component integration architecture	The key in component integration architectures is to provide consistent interfaces among stand-alone applications from functionally diverse application domains so that larger and more specific applications that incorporate functions from the different domains can be easily created. The paper notes 4 possible sources of architectural mismatch [Garlan et al., 95]: incompatibilities in assumptions about the nature of components the nature of connectors the global architectural structure, and the construction process Successful component integration architectures need to: get the communication channels right provide all the needed hooks to the stand-alone applications to export the needed functionality provide a programming environment to specify the required functionality of the application and access the capabilities of the stand-alone applications/components to deliver it.	Examples: OLE, CORBA Johnson states, "The so-called 'component systems' such as OLE, OpenDoc, and Beans are really frameworks that solve standard problems that arise in building compound documents and other composite objects. But any kind of framework provides the standards that enable existing components to be reused." I do not buy this characterization. The consideration that distinguishes component integration architectures from frameworks is the raw size and stand-alone functionality of the components in component integration architectures. In my way of parsing the terminology, no framework has anything comparable to such components. In terms of the continuum suggested in my comments on Gamma et al., component integration architectures operate with much heavier components at a larger scale than frameworks. What component integration architectures do share with frameworks is that the system designers have done the architectural design work to create an infrastructure for component integration that makes most things that it is plausible to do reasonably easy to do. Two caveats: (1) with component integration the application design space is much broader than with frameworks; (2) delivering all the needed functionality from the components to cover this design space is still a work in progress. The variation in the design-space coverage in moving from design patterns to frameworks to component integration architectures is interesting. Design patterns can be used in just about any design space. Frameworks are very much domain specific. Component integration systems have much more robust domain coverage than frameworks, but less than design patterns. What is interesting, though, is that the domains covered by design patterns and component integration systems are entirely incommensurate: the levels of abstraction (or conceptualization) are different. The distance between them is roughly comparable to the distance between assembler as an abstraction of machine language and design patterns. The vocabularies for describing the design spaces are entirely disjoint.