Radu Bacioiu, CSE 584, fall 1998. Assigned Readings &ndash Design.

1. On the Criteria To Be Used in Decomposing Systems into Modules (D.L. Parnas)

Throughout the paper there is the implicit assumption that batch processing was the hot thing around when the paper was written. Things have changed quite a bit since then. Ideas proposed in the paper are now natural, they are the norm of Object Oriented programming. One insight that I got from this paper was the idea that objects (modules) should encapsulate design decisions that are likely to change and that interfaces are the ones that should capture aspects of the program that are not likely to change.

2. Designing Software for Ease of Extension and Contraction (D.L. Parnas)

I found it interesting how Parnas treats extensibility and contractability of a software product the same. In the commercial software world nowadays extensibility is a hot buzzword but I couldn&rsquot say the same about contractability. However, there are definitely applications that could be viewed as simple components of larger applications. I&rsquom thinking of applications such as Acrobat Reader, Word format converters, PowerPoint viewer. However, I doubt that at least the Microsoft "simplified apps" in question were built according to Parnas&rsquo model or that they are making enough use of the components of their respective "full blown" programs.

The most important idea for me in this paper is that flexibility has to be thought of from day one of an application design. The decision has to be made wisely as "it appears unavoidable that there is a run-time cost to be paid for generality" &ndash there is a fundamental tradeoff between flexibility and generality that has to be decided from the start. From what I&rsquove seen in the commercial software world today, since extensibility is the buzzword many applications tend to err on the side of too much (unneeded) flexibility just because it&rsquos cool.

Even though in the process of designing the prototype of an application one might start with a clean architecture ("uses" hierarchy) and a "minimal set" of features as Parnas suggests, as the application development progresses the architecture gets muddied and the minimal set tends to get corrupted. Changes are made to the minimal set so that in the end it can&rsquot function independently anymore. Due to marketing and performance pressures the cleanness of components suffers and the architecture of the product in general degrades as work progresses. This aging process usually gets unnoticed until the need for flexibility / extensibility comes into question (usually at the end of the product cycle). Only then the unorthodox hardcoded hacks become obvious and the benefits of sticking to a clean architecture throughout the development process become obvious.

3. Reconciling Environment Integration and Component Independence (K.J. Sullivan and D. Notkin)

Mediators are fairly powerful tools in representing relationships between objects. Designing a system to use mediators however requires a shift in the "traditional" way of thinking about Object Oriented programming (where relationships aren&rsquot usually represented by components but rather are hard wired and hidden using encapsulation). Does this shift in thinking pay off? Probably for the common commercial application encapsulation works well enough. However, when flexibility or ease of change is a major goal of a product, then using mediators should be seriously considered.

4. Beyond the Black Box: Open Implementation (G. Kiczales)

I should start by saying that the problem described in this paper is real. The problem is essentially that the implementor of the component usually can&rsquot think of all the ways his component will be used by various clients. Therefore performance problems often arise since an implementation is usually written with one or only a few "common cases" in mind. However, is Open Implementation the right solution to this problem? It is definitely one solution.

My first criticism is that if a component were intended to be flexible and used in more than one "common" way, then the interface (the "base interface" as defined in the paper) should reflect that fact. If it doesn&rsquot it&rsquos a design flaw of the base interface and the right solution isn&rsquot necessarily adding the meta interface but maybe enhancing the base interface to expose the entire functionality of the component.

The second comment I have is that maybe the spreadsheet example in the paper is just an example of a misuse of a component. Very likely the window object in question wasn&rsquot intended to be used the way the author used it, period. Often a programmer doesn&rsquot find any components out there that satisfy his performance needs and has to write his own. Requiring otherwise is shifting the responsibility of writing specialized code from the application developer to the component developer, which seems unreasonable. Not having the right component available is no excuse for using the wrong component.

Making a component more flexible usually comes at the expense of the performance of the common case. Either the Open Implementation approach or the expanding of the base interface to include performance control (as I suggested above) will very likely come at the expense of bloating the code for the component. Is this acceptable? Only the specific component / application developer can answer this question correctly. As D.L. Parnas mentions in his extensibility paper (2.), "it appears unavoidable that there is a run-time cost to be paid for generality."

5. An Introduction to Software Architecture (D. Garlan and M. Shaw)

The paper tries to address the new reality in Software design &ndash the sheer size of the commercial products make Software Architecture be the harder problem to solve setting traditional problems (such as Algorithms and Data Structures) in the background. Choosing poorly an architecture will usually have a larger impact on the finite product and will be harder to change than using an inefficient algorithm in a component of the product. The paper reviews a couple commonly used architectural styles and defines a framework of analyzing and recognizing the various styles. Strengths and weaknesses intrinsic to various styles are discussed. It is also important to recognize that various "pure" styles can be combined into hybrid "heterogeneous" architectures in an effort to benefit from the strength of more than one architectural style.

Recognizing the existence of the various styles and having a clear idea of the intrinsic benefits and drawbacks of each style can be a tremendous tool in the process of early design when the architecture of a product is defined and crystallized.

6. Design Patterns: Abstraction and Reuse of Object Oriented Design (E. Gamma, R. Helm, R. Johnson, J. Vlissides)

The way I see it, by defining / formalizing Design Patterns the authors try to achieve two things. First is to build a formal "common language" that makes it easy to express various software designs and architecture using proven building blocks. The second is to make it easier for the programmer trained in the spirit of Design Patterns to rapidly recognize patterns and think in terms of patterns when looking at a software product.

However, from the point of view of the practitioner I&rsquoll have to say that I find the formalism &ndash at least in the form it&rsquos presented in the paper &ndashhard to use by the common (however seasoned) programmer. While the rigor of a formal definition is (ok, should be) intrinsic to the academic world, I think the ideas presented in this paper should be simplified or better crystallized before they can have a significant impact in the industry.

It is useful to contrast Frameworks with Design Patterns. While the Framework is pretty much a concrete tool that helps programmers implement software faster, Design Patterns are more of a "way of thinking" about software design.

7. Components, Frameworks, Patterns (R.E. Johnson)

The author acknowledges that the concept of "framework" is one of the &ndash few I would say &ndash concepts that are already extensively used by the software industry but wasn&rsquot given enough attention in the academia. The model I had in mind throughout reading the paper was the "application wizard" of Visual C++ that pretty much fits the definition of a framework as described in this paper.

Having used a framework &ndash even without knowing it &ndash for quite a while, many of the statements in the paper seemed obvious. However what the author calls "inversion of control" was a pleasant and unexpected insight. Now that I realize it I think this is one of the primary differences between traditional programming &ndash starting by writing main( ) &ndash and programming using a framework. In traditional programming one starts with building the control flow &ndash using existing components or writing everything from scratch. In framework programming the control flow structure is already in place and the programmer needs only to change or add components.

One thing that I noticed was that the author strongly links the idea of framework to the concept of object oriented programming. Given one of the definitions in the paper &ndash "a framework is the skeleton of an application that can be customized" &ndash one can think of a framework as a "sample" or "template" application that has the right architecture and constitutes the starting point for building a more complex, fully developed software product. It is true that in general commercial frameworks are presented to an object oriented programming environment and come with a set of library objects (library components), but I wonder whether or not the idea of a framework can be de-coupled from the idea of OO programming.

8. Experience Assessing an Architectural Approach to Large-Scale Systematic Reuse (K.J. Sullivan and J.C. Knight)

Although this article is flattering to Microsoft&rsquos OLE technology, I can&rsquot help being skeptical at the almost childish exuberance of the authors. Their view of "what&rsquos out there" in the industry and how reliable software products are being built is at least unrealistic if not downright insulting. The bottom-line number they come up with for completing their project is the 1 man week. I am willing to accept that they didn&rsquot include testing time or time needed to learn the component interfaces to this total time. I&rsquom also willing to accept that the product was less than perfect in its final form. After all, this is an academic experiment. However, all these things aside there still was the need to explore Visio extensions, to discover and find workarounds for the problems mentioned in the paper plus writing from scratch the "less than 10,000 lines of code." In one of the first lectures we were told that commercial programmers write an average of about 1,000 lines of code per year. One conclusion I can draw is that a grad-student week in the academia is much longer than a man-week in the industry.

Ignoring the boastful numbers, the paper does a good job at identifying the potential problems and pitfalls encountered when building a software product using large and sophisticated OLE components. One is that components tend to expose either a very simplistic interface that usually isn&rsquot up to the task or a very hairy and complex interface that&rsquos rather hard to understand and use. Rarely a good balance is achieved, but in general erring on the side of a more complex interface is better than erring on the side of a simple interface since this would give the component more flexibility. Second point is that few applications expose their components via OLE and therefore the range of components available to the common programmer is small. This is a concern acknowledged by the industry and as far as I know Microsoft and other vendors are trying to address it.

D. L. Parnas makes a point in the Extensibility paper (2.) that "flexibility cannot be an afterthought," but rather built into the product from the beginning. By the same token, one of the conclusions of this paper is that componentizing a large and powerful software product shouldn&rsquot be an afterthought either.