Marshall Cline

Aspects of software adaptability

Permission to make digital/hard copy of part or all of this work for person-al or classroom use is granted without fee provided that copies are not madeor distributed for profit or commercial advantage, the copyright notice, thetitle of the publication and its date appear, and notice is given that copyingis by permission of ACM, Inc. To copy otherwise, to republish, to post onservers, or to redistribute to lists requires prior specific permission and/or afee.

The pros and cons of adopting and applying design patterns in the real world

D ESIGN patterns are a valuable tool for the practicing software professional. There are a number of pragmatic benefits from using design patterns, and, not surprisingly, there are also a number of common problems. This sidebar shows project managers and object-oriented (OO) designers some of the organizational as well as technical issues that come up when design patterns are introduced into a software production shop. Design patterns coordinate the entire process and community. Design patterns provide a standard vocabulary among developers. They provide a list of things to look for during a design review and a list of things that must be taught in a course on OO design. They communicate information between designer, programmer , and maintenance programmer at a significantly higher level than individual classes or functions. These advantages of design patterns scale well to large organizations. We have applied them on a three-year project with 150 OO/C++ developers. Almost every developer was trained and men-tored using a uniform set of design patterns, and these patterns were used throughout the development lifecycle. Even though the patterns and their names were different from those in standard use today (they were largely reinvented by the author, since the project predated the standard design patterns text [3] by several years), they were nonetheless uniform across the project teams, and this uniformity allowed the developers to communicate at a higher level of abstraction. Design patterns were an important component to the overall success of this project [1]. Design patterns can be used reactively. Design patterns can be used as a documentation tool to classify the fragments of a design, making it easier for a team to absorb new developers. For example, many of the teams design philosophies are captured explicitly rather than strictly being in the heads of the original team. Design patterns can be used proactively. Patterns are more than a documentation tool. In addition, they can be used to build robust designs with design-level parts that have well understood trade-offs. Using design patterns this way requires the designer to perform a degree of high-level pattern matching, as well as to have the ability to abstract the essence of the design problem from the morass of details. It also requires that the design patterns be part of ones flesh and blood— looking things up in a book would be completely unacceptable in these on-the-fly situations. Design patterns can be used to …

Enduring business themes

ion? Most likely, they would come up with objects called “delicatessen,” “cash registers,” COMMUNICATIONS OF THE ACM May 2000/Vol. 43, No. 5 103 One of the most glaring problems with OO technology has been the failure of management to exercise its proper role in the software process. “streets,” and so on. But, as Holland points out, these have nothing to do with what a city is all about. It is too easy to get bogged down in the details, and miss the essence of what is happening from a change standpoint. Food distribution in New York City is not about food and distribution channels, it is an exercise in Adam Smith economics wherein adaptive agents, buyers, and sellers, use price as a rationing mechanism. These agents will behave rationally, that is, change as their best interests dictate. Eventually, everything works out. It is precisely this adaptive behavior that remains constant over time, and it is precisely this constant behavior that must be the basis for any sensible computer model. Policies, products, and distribution channels cannot be the focus, because they will change, and when they change the investment in the software that models them will be lost. Better to focus the software investment in the areas that do not change, and subordinate the changeable aspects as mere details. The enduring themes, in this case of free enterprise and marketplace economics, frequently do not stand out in the problem definition. Problem definitions and requirements models seem to feature details, because details are easier to understand and explain. Themes are abstractions, which are very difficult for many people to recognize and use. Liberal arts students recognize that most literary works revolve around a few basic themes such as “the triumph of good over evil” or the “epic saga of a nation.” There are a handful of themes that appear repeatedly, each time with a slightly different twist. Business is no different because it too is an adaptive process, and it is known that adaptive processes that survive must have an internal simplicity that we call a “theme.” Cellular automata and fractal geometry are examples of how apparently complex superstructures are actually built around simple primitives or themes. The Custom Manufacturing Problem. Suppose a manufacturing company wants to automate its production lines where chemicals are mixed, heated, and drained into a mold. The traditional way to model this problem is to use a noun orientation. Here the objects would be Vat, Input Valve #1 and #2, Input Chemical #1 and #2, Gas Furnace, Output Valve, and Mold. In this case, each of these objects could know a small piece of the overall recipe for the product, and the recipe would be executed by the objects communicating with each other. It is also possible to model the problem using a verb orientation, that is, treating the verbs as firstclass objects. Then, the objects would be Set Valve Position, Stir, Wait, and Set Furnace Temperature. In this case, the recipe for the product would be determined by the order that these objects are created and stored in a To-Do-List object (see Figure 1). These are quite different models of the same requirements definition, so which one is better? Either will fulfill the requirements specification. The real question is which approach is more likely to survive change. If the recipe is enduring, such as the manufacturing of a classic wine, the changes over time are likely to be in the equipment, and the noun orientation is likely to be better. If, on the other hand, the company is involved in mass customization, such as a custom chemical shop, the recipe must not be buried in the valve objects, and the verb-centric approach is the better route. The theme behind the first approach focuses on the machinery used to implement the process, while the second approach embodies a theme that focuses on following any recipe. This is not unexpected; there are almost always several themes that can explain a situation, but for our purposes, the correct theme is the one that survives over time. This enduring quality can only be determined by examining the underlying business issues, rather than a narrow focus on some abstract technical notion of goodness. This is why an EBT requires insights into the structural nature of the business rather than operational details. It is important this process not be confused with the steps of a functional decomposition, which mixes policy with mechanism [2]. An EBT expresses what should be done, not how it is implemented, and its implementation relies on a language of the business to specify implementation detail. The Transportation Problem. Suppose a designer has been transported back in time to the mid-1800s, and has been tasked with developing a computer system for package or merchandise delivery. An industry objects orientation would focus on classes for buggy whips and clipper ships, which is obviously the wrong long-term approach. A much better approach is to 104 May 2000/Vol. 43, No. 5 COMMUNICATIONS OF THE ACM Recipe

Lessons learned from the OS/400 OO project

This article describes some of the lessons learned when a team of 150 developers with a minimal prior exposure to object-oriented (OO) technology undertook a large development project. Team members became proficient in OO design, using C++ as an OO language rather than just using C++ as a better C, and developed IBMs RISC version of the AS/400 and System/36 operating systems from 1992 to 1994 in Rochester, Minnesota. The project contains 14,000 thousand classes, 90,000 thousand methods, and 2 million lines of C++ integrated into 20 million lines of total code. The result of their efforts was the development of a product that is being used daily by a substantial international customer base.

Managing Object-Oriented Software Development

roject managers should not use the novelty of the object-oriented ’ approach as an excuse to let software developers manage themselves. Even though project managers may be unfamiliar with the latest technical advances, they must stay involved in planning and controlling software development. Nonetheless, in many organizations developers have usurped management planning and control by convincing managers that 00 is so different from other technologies that they can’t understand or control it. The long-term results of this “hyperempowerment” are almost always unfortunate, ultimately threatening the business value of the 00 appr0ach.l The solution is not authoritarian control. Managers must control the project in a way that doesn’t destroy the qualities theywant to deve1op.l For example, if they want an application to be flexible in a certain way, they must allocate resources to engineer that flexibility. However, developers must not be given a blank check to add flexibility wherever they want. It should be added onlywhere it wil bring the most business value. Marketing and management issues determine this, not technical ones. The fundamental aspects of the traditional software development approach are woven into the fabric of the organization’s culture. Yet the analogous fundamentals for the 00 software development approach are new to many, and this novelty often cuts across the grain of the established cultural norms. Changing the cultural aspects is often much more difficult than helping software developers understand 00 technology. Because of the need to adapt the culture to the approach, a wise manager participates in some form of 00 training or education. This issue provides part of that 00 education for both managers and developers. We have distilled management practices and techniques from our experiences in more than 100 00 projects and explored new practices. We cover the manyways that 00 complicates the project manager’s role in such areas as planning, staffing, training, scheduling, cost estimation, documentation, development, legacy systems, and metrics, as shown in Figure 1.

Identifying domain patterns using software stability

The fact that domain applications share core aspects has turned software reuse into a viable option. System development has experienced time saving, cost saving, and the luxury of deploying proven-to-work solutions as main advantages of software reuse. Software patterns represent a major approach for reuse. Domain patterns capture system components shared by different applications that belong to the same context. In this paper, we propose a new approach to identifying and reusing domain patterns based on software stability. We show that enduring business themes and business objects, together, can form a pattern among domain applications. We, also, present three case studies to show how the new approach can be applied.

Extracting Domain-Specific and Domain-Neutral Patterns Using Software Stability Concepts

Extracting domain-specific patterns and domain-neutral patterns is a challenge for both expert and novice software engineers. Currently, no mature guidelines or methodologies exist for extracting patterns. Software stability model proposed in [3] provides a base for extracting the core knowledge of the domain and identifying atomic notions that can be thought of as patterns by extracting another level of abstraction using software stability concepts. This paper proposes and demonstrates, through examples, how to extract both domain-specific and domain-neutral patterns from systems that are built using software stability concepts.

Extracting domain- specific and domain-independent patterns

There are no mature guidelines or methodologies exist for extracting patterns. Software Stability Model [2] can provide a base for extracting patterns. This poster presents the concept of extracting both domain-specific and domain- independent patterns from systems that are built using software stability concepts.