|Parnas. 1972.||importance of decomposition strategies;
"uses" and program hierarchy
|Classic paper in the field
||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
||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:
|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
||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:
||The paper focuses on 6 distinct architectural
styles -- there are others. Their intent is to:
||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]:
|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.