The reading materials cover a wide range of design issues: from the original information hiding approach in the early 70's to the current design patterns. Most of them target on design reuse. Data abstraction and object-oriented design are emphasized by the papers. Here is the brief overview of each article.

On the criteria to be used in Decomposing systems into Modules discusses the criteria to decompose a system into modules. Modularization allows separate groups to work on each module with little knowledge of the code of other modules. By comparing the changeablity, independent development and comprehensibility, the author points out that it is almost incorrect to begin the decomposition of a system into modules on the basis of a flowchart. The "Information Hiding" approach is more efficient.

Designing software for ease of extension and contraction presents that designing software to be extensible and easily contracted is a special case of design for changes. The critical step is the design of the "uses" relation of software structure. It is shown that the identification of minimal subsets and minimal extensions which can help tailor to the needs of a broad variety of users.

Reconciling environment integration and component independence presents an approach that eases the design and evolution of integrated environment by increasing independence among components. Its approach combines mediators, which localize relationships, and a general event mechanism.

Beyond the black box: open implementation points out that the black-box abstraction has performance issues: exposing only the functionality of a module can lead to serous performance difficulties when reusing it. The author suggests using open implementation, which allows clients to control its implementation strategy.

An introduction to software architecture discusses that the architectural software design becomes more important as the size and complexity of software systems increases. This paper outlines a number of common architectural styles upon which many systems are currently based, and show heterogeneous styles can be combined in a single design. It uses six case studies to illustrate how architectural representations of a software system can improve our understanding of complex systems.

Design patterns: abstraction and reuse of object-oriented design proposes design patterns, a new mechanism for expressing design structures. Design patterns identify, name, and abstract common themes in object-oriented design. They capture the intent behind a design by identifying objects, their collaborations, and the distribution of responsibilities. Design patterns can be considered reusable micro-architectures that contribute to an overall system architecture. The paper also describes the current catalog of design patterns. It gives a brief summary and includes a few abridged patterns.

Components, frameworks, patterns indicated that frameworks are an object-orient technique. A framework is a larger-scale design that describes how a program is decomposed into a set of interacting objects. It includes part code reuse and part design reuse. This paper compares and contrasts frameworks with other reuse techniques, and describes how to use them, how to evaluate them, and how to develop them.

Experience assessing an architectural approach to large-scale systematic reuse addresses the important technical barrier to large-scale reuse called architectural mismatch. It reports an evaluation of the architectural approach to large-scale reuse represented by OLE. The evaluation followed by an experiment in which we developed a substantial application by integrating large-scale reusable components based on OLE. The result is that, although difficulties remain, the approach appears to have made significant progress towards realizing the promise of rapid development of sophisticated systems through reuse.

The first two articles, On the criteria to be used in Decomposing systems into Modules and Designing software for ease of extension and contraction, were written in the 70's. The two criteria emphasized there, independent development and comprehensibility, are actually applied to the object-oriented design. Object-oriented design encapsulates the information of each object and constructs loose system architecture. The idea of COM (Component Object Module) is: the less a client knows about a component it uses, the easier it is to make changes of the component or even replace it. Possible changes must be considered while designing a system. Changes are inevitable in the lifetime of an industrial product. So it is a crucial step to identify those likely changed items and make the interface insensitive to the anticipated changes.

I don’t agree with this article "Beyond the black box: open implementation" in some aspects. Open implementation method is against information hiding and encapsulation. For open implementation, each client has to implement its own version of a component. This requires that the client know the implementation details of the component. Thus the client and the component will be connected so tightly that the component can’t be easily reused by other clients. Even for the same client, it will result in the higher maintenance cost: Both clients and the component need to be changed if there is any change on either side.

The author believes that the client knows best how the module should be implemented. Actually in most cases, neither the client nor the component knows much about how to implement at the very beginning. A way to handle this situation is to collect all the uncertain factors and anticipate the changes. We may try to make the interface flexible enough, such as presenting uncertain factors as parameters, to tolerate the changes in the future. Of course there is a tradeoff between simplicity and power. The author also emphasizes the performance problem of information hiding design. This issue does exist. If performance is critical for a component, we should address this problem during designing the component and solve it when implementing the component.

The paper, an introduction to software architecture, is a very good article. It presents a balanced view of different system design styles. The author lists one of the disadvantages of object-oriented design: In order for one object to interact with another, it must know the identity of that other object. Actually COM( Component Object Module ) partially solves this problem. In a component system, different components communicate by interfaces. One component doesn’t know anything about the identity of that other object except its interface. If we replace one component with another, which supports the same interface, it doesn’t affect any other components in the system. My company, Concur Technologies Inc., uses the combination of object-oriented design and event-based implicit invocation for the system design. The overall system is organized by different components. Some methods of the components can fire different events. This provides more flexibility and variability. For example, customers can write scripts to catch these events and handle them differently based on their own requirement. Different domain has its own requirement and characteristics. I think that the Domain-specific software architectures will be developed and used in the future.

While reading the paper, design pattern: abstraction and reuse of object-oriented design, I find that object-oriented languages, such as C++ and Java, are easily applied to implement a lot of features it mentioned. For instance, "class creational" can be implemented by virtual functions, subclasses and overwriting functions of C++. But I don’t know whether other languages, such as scripting language, can implement these design patterns easily. Although we don’t need to consider implementation details during design, it is still important to make sure that a design is applicable based on the programming language and hardware we choose for a system. Scripting languages are widely used in the industry, as far as I know, because of their simple language feature.

One problem of current frameworks, which the paper "Components, framewroks, patterns" doesn't emphasize, is efficiency. As a developer, I used to use MFC to implement user interface. MFC framework is based on windows message loop and driven by events. Since the events and their orders are not well documented, it caused that a lot of source code in our program is executed redundantly. This results in a performance issue. Of course the performance is not that important for user interface implementation in most cases. But we did have a serious problem because of that. Another disadvantage of MFC is its lack of flexibility. MFC provides an easy way to implement user interface if the user follows its style. But it could be very hard for a user to implement a different style control while using MFC.