Functional Representation for Reusable Components Dean Allemang and Beat Liver Research & Development Swiss Telecom PTT 3000 Berne 29,Switzerland Tel: +41 31 338 4472 Email: allemang@vptt.ch Abstract In this research abstract we outline the framework ZD for constructing libraries of reusable software components. The work is inspired by functional representation of physical devices [1], but has undergone considerable changes while being adapted to support software engineering. The approach is a formal one, in that the semantics of the representations is based on proofs of program correctness. This makes it particularly easy to compare it to more `classical' software engineering approaches. In particular,we contrast our approach to the construction of software libraries based on `local certifiable modules' [2]. We have shown that while the goals of local certifiable modules constitute a sound basis on which to build a mature software industry, unfortunately, dedication to local certifiability constrains the grain size of the library components too severely to allow the desired flexibility. In the ZD framework, we resolve this problem with a method called proviso propagation. Local certifiable modules place the proof process at module creation time; ordinary proofs of correctness place the proof process at configuration time (or later). Proviso propagation divides the proof process - the majority of the proof is done at library creation time, except for the proviso propagation, which is done at configuration time. In this way, ZDretains much of the flexibility of freely combinable modules, while retaining capability to provide provably correct software. Keywords: Reuse, formal verification, modular design, program modeling. Workshop Goals: Comparison of our models to requirements of other SE methodologies. Working Groups: Design guidelines for reuse - general, reuse and formal methods, reuse handbook. 1 Background Dean Allemang began his contribution to software reuse with his dissertation in 1990. The goal of that work was to represent the knowledge required to `understand' a program. The work was based on the Functional Representation work done by Chandrasekaran and Sembugamoorthy on representing mechanical devices. Since that time, Dean Allemang and Beat Liver at Swiss Telecom PTT Research and Development have extended the method described there to include support for software configuration, diagnosis, debugging and repair. This work will culmintate in Mr. Liver's Ph.D. dissertation, which will include an implementation of the software modeling language ZD. 2 Position Since the industrial revolution, most manufacture of mechanical devices is done on the basis of the assembly-line - a large number of identical parts are produced, and assembled into the final product. But the final products are not all identical - there are a number of options and models from which the customer may choose, and these impact the manufacturing process. Software, on the other hand,is typically done on a custom-order basis; each piece of software is tailored to the needs of its end users. The dream of software engineering is that the software industry might one day have the flexibility and productivity of more mature mechanical industries. A common problem with mass-production of software or mechanical devices is quality control - how do we know that the device produced willp erform as advertised, especially in safety or security critical situations? In order for software to be able to satisfy quality control constraints, it is necessary that we have a reliable method for specifying what software is to do, and of determining whether it achieves this goal. In order to satisfy these two goalsof a mature software industry, Weide et al [2] propose local certifiable modules. Alocal certifiable module is a reusable piece of software,whose correctness can be verified in purely local terms;that is, its own specification, its own code, and the specification of the programs it calls directly. A library of such components could be built and certified; then writing a program is merely a matter of selecting the necessary components, com posing them together,verifying that the specifications of services match the specifications of requirements. The local certifiability guarantees that the resulting composite program does what its specification promises. 2.1 ZD and Software Configuration In order to avoid reducing all problems to a single implementation level, software is normally understood at several levels of abstraction.This concept is well-known to any experienced programmer, and is supported by a number of methods in modern programming languages. This means that a library of reusable components must also have components at various levels of abstraction;the configuration of a new system will be explainable at several levels simultaneously, depending on the configuration decisions made during its construction. This means that a representation of the specifications of reusable components as well as the requirements will have to have a mechanism for mediating between description languages at different levels of abstraction. We have designed ZDafter functional modeling languages used for describing physical devices at several levels of abstraction [1]. We have formalized the change of abstraction levels by using the notion of representation functions from ALPHARD [3]. Each module in ZD mediates an explanation in some state description language (SDL). For any implementation choice, a function maps from the abstract language to the chosen concrete language. For example, for an array implementation of a stack,the high-level (in terms of stack operators) expression `empty(S)' is translated into the concrete expression `stack:top = 0'. [Figure 1: Afunctional prototype. The prototype has services (top,square boxed), and an implementation (middle,round box), which specifies what it requires of other devices (bottom, square boxes again). Figure 2: Schematic configuration of a functional decomposition - a functional prototype - from a library of functional prototypes. Functional prototypes from the library are shaded; figures shown in dotted lines are to be determined; and the components new to first three stages are shown in bold.] A reusable component in ZD is called a functional prototype, after the use of the term in CAD research [4]. Figure 1 show the coarse structure of a ZD functional prototype. On the top of the diagram is a specification of the service provided by the prototype; in the middle is an implementation that achieves this specification (only one is shown in the figure, but in principle, there can be several implementations per prototype). Finally, each implementation specifies some requirements for other services upon which it will call. The requirements and the service will not be at the same level of abstraction - thus associated with each implementation is a representation function. Just as in the case of local certifiable components, configuration of a program in ZD involves making a selection of a number of such prototypes, and matching them together,as shown in figure 2. In general, a library user cannot expect the specifications of one service to match the requirements of another exactly - hence we introduce `glue code' [2] to connect them. Glue code is shown as extra implementations in the figure. 3 Limits on Configuration So far, there is no apparent advantage to using ZD over a system of certifiable components - in fact, if we were to certify our functional prototypes, the two approaches would be identical. The primary difference between ZD and local certifiable components is that each service specification of ZD includes a predicate called its proviso, which specifies a context in which the use of this prototype is valid. Unlike the specification of the prototype (or of the local certifiable module),the proviso is not merely matched to the requirement specification of the client program. Verification of the proviso is subject to a more comprehensive proof mechanism. The details of how provisos are propagated in ZD can be found in [5]. The ramifications of having a proviso that is checked at configuration time is that features of the program that are only known at configuration time may take part in the verification process. Requiring that a module be certified in advance of any possible use is quite a severe constraint to place on a module; the use of the proviso allows this constraint to be relaxed. Of course,this relaxation has a price - the proviso must be proven at configuration time. The trade-off between a too-rigid library,and intractable proviso verification is the art of writing good reusable modules and provisos. A short example should illustrate how this trade-off works. Iteration is a common action that many programs have to do over and over again. Consider a module called passive_iterator. It takes two arguments - an ordered set of items,and a fragment of code. The iterator runs the code on each item in the set, and guarantees that although the order of the set might be changed, its contents will not. A local certifiable version of passive_iterator would be guaranteed to satisfy this specification, for any input set and action. If the desired action were to re-arrange the set (say, shift every element one to the right), then an action that moves a single item could be used. But the integrity of the set depends upon the order in which the iterator traverses it - it is impossible to anticipate during library construction which actions might be desired. Thus passive_iterator alone cannot be encapsulated as a local certifiable module. Weide solves this problem by using an active iterator instead of a passive one,and by encapsulating the action into the specification of the reusable module [6]. This makes for a local certifiable module, but the shift action is already included - the client cannot decide what new ordering of the set he wants. ZD, on the other hand, can encapsulate a passive iterator. Indeed there is a condition on the action - not just any action may be used in conjunction with the ZD passive iterator total_loop [7]. The action itself must be instantiated from the library - along with the function prototype for the action, a proviso for its correct use is retrieved. In the case of a simple action to move an item from one place to another,the proviso requires that the target of the move be `empty'. Since each item will be moved, checking that this proviso is satisfied is more complicated than simply checking that it is guaranteed by the requirement specification. In general, this involves the invocation of a theorem prover to show that the proviso is satisfied at every iteration of the loop. In this case, the proviso can be checked quite easily from a formal statement of the principle of induction, without an exponential proof structure. This process of verifying a proviso in its context is called Proviso Propagating and Proving (PPP). 4 Comparison The value added to local certifiable components by ZD is the capability to buy flexibility of modules, by paying with computational effort(theorem proving, in the worst case) at configuration time. Modules that are local certifiable can be treated in ZD by specifying a null proviso; even very simple provisos can buy big gains in flexibility, as the preceding example showed. The PPP algorithm has already been worked out and implemented, in a system called Dudu [5] running in InterLisp on a Xerox 1108/9. Dudu used a functional representation that preceded ZD to recognize the difference between correct and incorrect student programs in a tutorial setting. In our current work we are resolving a number of the details of the ZD formalism to specify how the connections between requirements and specifications can be formalized, and under exactly what circumstances a proviso must be propagated [8]. Our goal is to implement ZD in such a way that the proviso propagation algorithm from Dudu can be rebuilt, along with support for configuration of the form shown in figure 2. Further applications include modeling of distributed systems [9] and fault isolation [10]. ZD will then become a language in which function prototypes can be written, and the details of the trade-off betweenflexibility and design-time computational expense can be more systematically studied,in the context of a growing library of semi-local certifiable prototypes. References [1]Sembugamoorthy, V. and Chandrasekaran, B., "Functional Representation of Devices and Compilation of Diagnositc Problem-Solving Systems," in Experience, Memory and Reasoning (J. Kolodner and C.Riesbeck, eds.), pp. 47-73, Lawrence Erlbaum Associates, 1986. [2]B. W. Weide, W. F. Ogden, and S. H. Zweben, "Reuseable software components," in Advances in Computers (M. C. Yovits, ed.), vol. 33, pp.1-65, Academic Press, 1991. [3]W. Wulf, R. London, and M. Shaw, "Abstraction and Verification in Alphard: Introduction to Language and Methodology," in ALPHARD: Form and Content (M. Shaw, ed.), Computer Science Monograph, pp. 15-60, Springer, 1981. [4]Y. Umeda and T.Tomiyama, "A CAD for Functional Design," in Working Notes of the AAAI'93 Workshop "Reasoning about Function", (Washington DC), 1993. [5]D. T. Allemang, Understanding Programs as Devices. PhD thesis, The Ohio State University, 1990. [6]B. W. Weide, S. H. Edwards, D. E. Harms, and D. A. Lamb, "Design and specification of iterators usingthe swapping paradigm," IEEE Transactions on Software Engineering, vol.20, pp. 631-643, August 1994. [7]D. T. Allemang,"Functional Representation and Program Debugging," in Proc. of the 6th Knowledge-Based Software Engineering Conference, (Syracuse, NY), IEEE Computer Society Press,1991. [8]B. Liver and D. T. Allemang, "AFunctional Representation for Software Reuse and Design," Software Engineering and Knowledge Engineering, vol. in press, 1995. Special Issue on Evolutionary Approaches to Software Engineering. [9]B. Liver, "Working-around Faulty Communication Procedures using Functional Models," in Working Notes of the AAAI-93 Workshop "Reasoning about Function", (Washington DC), 1993. [10]B. Liver,"Modeling Software Systems for Diagnosis," in Working Notes of the 5th Int. Workshop on Principles of Diagnosis, 1994. Difference-Based Engineering Sidney C. Bailin CTA Incorporated 6116 Executive Boulevard, Suite 800 Rockville, MD 20852 Tel: (301)816-1451 Email: sbailin@cta.com Abstract This position paper describes a concept, Difference Based Engineering, which is an attempt to bring reuse out of the specialty arena. I try to reformulate the reuse concept so that it explicitly addresses the concerns and needs of working software andsystem engineers and, even more, managers with profit and loss responsibility. Keywords: Deltas, case-base, engineering analysis Workshop Goals: Stay abreast ofwhat others in the field are doing. Promulgate a view of reuse that emphasizes evolution and the unique characteristics of software. Working Groups:Reuse management,organization and economics;Domain analysis/engineering; Tools and environments 1 Background After 8 years of research and development in domain analysis and reuse methodology and tools, we decided to turn Capturetm into a commercial product. No sooner had we convinced the Board of Directors to go for it,than the second thoughts began. This is not surprising for a company that has thrived on Government contracts since its inception; but it has forced us to do a continual selling job both within and outside our company _ not on the goodness of reuse, but on whether there is really a market for such technology. It's a tough question, and in this position paper I summarize where it has led us. 2 Position My basic position is that we have to stop thinking of reuse as a thing in itself to be promoted and sold. Why? Well,because it's become a fetish, and a lot of people are not especially turned on by it. One of the things we did was hire a consultant to do a market analysis. He called a bunch of people and asked them a lot of questions about their software environment needs,and right in the middle of the questionaire he stuck an inconspicuous question about the desirability and importance of reuse (so that the interviewees wouldn't catch on that that was the real topic). Their typical answer - "Yes, reuse would be nice, Iguess, but it's not high on the agenda." To which the knee-jerk reaction of the plug- pullers here was, "You see, it (our productization effort) was a mistake, let's pull the plug." We all know that polls are skewed by the way the questions are asked.And the problem is that this poll asked a question like,"Would you care for an extra dollop of extra-rich high-fat chocolate syrup essence on your sundae?"So of course the answer was, "Well, yeah, I guess, since you offered." But what if we ask the question in a different form, such as: "Would you place a high priority on staying in business?" Let me formulate this a little more soberly. We need to think of reuse as a fundamental aspect of disciplined engineering _ and to derive from that the "compelling reason to buy" that must be articulated when marketing new technology [2]. One such argument might be, "You're going broke. You're profits are down, you're laying people off, your industry is consolidating - this technology can give you a competitive edge,or at least competitive parity in a rapidly evolving world." I think that's a pretty compelling reason to buy. Of course, the devil is in the details : To which purpose, I offer the concept of Difference-Based Engineering (see the figure at the end of this paper). The concept is simple: streamline the system and software engineering process byconstructing new systems as deltas of existing systems. A problem (i.e., a set of requirements fora system) comes in, and the first thing the engineer asks is, "Have we done this before - do we have a solution?" If the answer is yes, we're done. If the answer is, "Not quite," then the next question is, "How is what we've done before different from what we need to do now? What approaches can we take to adapt what we've done before? What would have to change, and what are the implications/ramifications of making such changes?" It is in answering these questions that the system/software engineering is performed.The Capture tool - and reuse technology in general - is intended to provide knowledge to help in obtaining answers to these questions, rapidly and reliably; credibly, rather than through guess-work. Of course,to some extent most engineering organizations and individuals do this already. But they don't do it systematically,and therefore they don't benefit from the labor-minimizing consequences. The objective of introducing a Difference-BasedEngineering process is that you no longer build systems, you build deltas, and this becomes the institutionalized approach. 3 Comparison My position that reuse is really a fundamental aspect of disciplined engineering is similar to Ruben Prieto-Diaz's at last year's reuse conference in Rio, where he predicted the Disappearance of Software Reuse by the year 2000 [3]. My emphasis on Darwinian survival is similar to the themes developed by Brad Cox [1].However, his vision of a system development industry based on "software ICs" is quite different from my view. I maintain that software - by its very nature - is the medium in which we tend to dump complexity and, in particular, unprecedented requirements. To Cox (Ithink), that is a pathology in need of fixing. To me, it is the very role of software in our society. The Difference Based Engineering paradigm is really just an example of the case-based reasoning paradigm first developed by Schank [4] and now a full-fledged field of AI. For many years I have referred to Capture as a case-based approach to domain engineering. By coining this new term I am hoping for a slightly different emphasis - a case-based approach to system building, in which domain analysis plays an important role.This, to me, is the essence of software reuse, but it tends to get lost in the forest of techniques and tools, conferences and curricula that we develop. 4 Biography Sidney C. Bailin is a Vice President of Engineering at CTA, Inc. where he heads up the Software Development Automation Group. He has worked in the field of reuse and, more generally, automating aspects of the software development process, for the past 10 years. Prior to this he worked as both a systems and a software engineer in a variety of domains including electronic funds transfer, operating systems, computer communications,office automation, and satellite ground systems. His academic background is in mathematical logic, and a principal emphasis in his current work is engineering as a reasoning activity, and the introduction of automated reasoning into the software development process in a way that is compatible with mainstream software skills and practice. References [1]B. Cox. Planning the Software Industrial Revolution. IEEE Software, November 1990. [2]G. A. Moore. Crossing the Chasm: Marketing and Selling Technology Products to Mainstream Customers. Harper Collins, 1991. [3]R. Prieto-Diaz. The Disappearance of Software Reuse. In Third International Conference on Software Reuse. IEEE Computer Society Press, 1994. [4]R. Schank. Dynamic Memory: The Theory of Reminding and Learning in Computers and People. Cambridge University Press, 1982. Tradeoffs in Packaging Reusable Assets Kevin M. Benner Andersen Consulting 100 S. Wacker Dr. Chicago, IL 60606 Email: kbenner@andersen.com Abstract Within a comprehensive reuseplan, one of many decisions that an organization must make is how to package assets for reuse. When an asset is packaged it is done be striking some balance between four delivery vehicles: people,deliverables (i.e., any sort of work product), tools, and processes. This position paper addresses the tradeoffs that an organization makes when deciding how to package assets for reuse. In general, these decisions are basedon the business environment in which reuse will be performed and the importance that it places on each of the following values: flexibility,productivity, speed of delivery, cost of delivery, investment cost, evolvability over time, and distributability. This paper will describe specific commitments that selected Andersen Consulting organizations have made based on their business environment. Keywords: Reuse processes, management, economics Workshop Goals: Learning; networking; exchanging information on recent reuse experiences. Working Groups: reuse process models, management andeconomics. 1 Background CSTaRis currently leading an effort to raise the level of reuse within Andersen Consulting using existing technology which will then prepare the way for new reuse technology as it becomes available. The general goal of this reuse initiative is to guide, lead, direct, cudgel, push, and entice Solution Centers and other large development organizations (e.g., large regional offices) within Andersen Consulting to integrate reuse as a fundamental part of their development and maintenance activities. A fundamental problem to date in achieving this end is that most organizations are significantly preoccupied with meeting their more near term objectives, and thus do not have the resources to dedicate toward reorienting themselves to be more reuse-centric. The goal of this initiative is to provide as many leverage points as possible so that organizations can step up to reuse in a planned way,leveraging existing knowledge on how reuse should best be accomplished. This reuse initiative is focused on the following four broad categories of activities: creating knowledge capital to enable reuse, partnering with organizations to make them more reuse-centric,evaluating current and future reuse activities, and proselytizing about reuse throughout the firm. 2 Position 2.1 Introduction To date Ihave had the opportunity to become familiar with several different reuse-based development efforts within the firm. One of the most interesting aspects of these reuse efforts is how they package assets to enable reuse. An asset may be packaged via any combination of the following delivery vehicles: people,deliverables (i.e.,any sort of work product), tools, and processes.When one is creating a reusable asset,one decides how much to rely on each of these vehicles. This decision is ultimately driven by a trade-off between competing delivery values. These delivery values are: flexibility,productivity, speed of delivery, cost of delivery, investment cost, evolvability over time, and distributability. This paper will describe in moredetail the basic nature of these delivery vehicles and then describe how asset packaging approaches maximize some values at the expense of others. 2.2 Asset Packaging and Delivery Vehicles Asset packaging is achieved by deciding some balance between complimentary delivery vehicles. As stated above,these vehicles are people, deliverables, tools, and processes. People are the most important element of asset packaging. This element is the only one which can standalone. In fact, reuse of people and their skills has always been one of the strengths of AC. The greatest advantage of people is their inherent flexibility. At the extreme,people who have some specialized knowledge often are able to apply it to solve the problem at hand. And when the problem is well suited to their specialized knowledge,they are particularly effective and productive at solving it. People also have the capacity to evolve their knowledge over time based on previous experiences. Relative to our delivery values,an organization relying solely on people is limited in several ways. Because knowledge resides within the individual,investments to improve this knowledge is spent on the individual whom may leave the organization thus taking the investment with him/her. Assuming the person stays,there are still only so many people with the knowledge,thus people become the limiting factor, potentially limiting opportunities if their knowledge is necessary and they are not available. Distribution of this knowledge is another issue. In the case of knowledge held by people, its distribution is fairly limited based on the typical bandwidth in human communication. Finally, there is the boredom factor. If people are forced to be too specialized and are used only to work in their specialized area, thus maximally reusing their knowledge,they get tired of doing this and will leave or demand to do other things. In either case, we lose the asset. Informally, people invariably leverage their knowledge by incorporating tools, deliverables, processes,and other people so as to reduce their work and increase their overall productivity. Systematizing this, by making specific organizational commitments to develop and maintain these other delivery vehicles is an essential part of any reuse strategy. The most common approach to systematic reuse is to focus on deliverables (including various intermediate work products). Characterizing what a deliverable is, is not an easy task. This is because deliverables have several dimensions to how they are represented. What choices one makes within each dimension greatly influences: the cost of creating the deliverable, the utility of reusing the deliverable,and the knowledge necessary to use the deliverable.The choices made within these dimensions are also a critical part of ones reuse strategy since it will effect the overall balance between the alternative delivery vehicles. The dimensions of a deliverable are: Formality - How formally should an asset be represented?(e.g., informal, structured, semi-formal, and formal documents ) Lifecycle deliverable - An asset may be characterized in terms of any of its lifecyle deliverables or intermediate work products (e.g., domain specifications, requirement documents including use cases and scenarios, system specifications, conceptual models, working models, designs, code, test plans, project management plans, process models,etc.). The most import ones for reuse are domain models, architectures, and component specifications. Domain specificity - What is the intended domain of the asset? How generically has the asset been represented? Examples include specific technicalarchitectures, industry solutions, business functions, and product lines. Form - How are variable and nonvariablep ortions of an asset delineated? (e.g., black box assets, white box assets, generic assets, parameterized assets, generated assets, informal template-like assets, etc.) Clearly,all of our delivery values play into the decisions one makes within the above dimensions on how to represent a deliverable. Increased flexibility,productivity, speed of delivery, evolvability, and distributability all come at the expense of investment costs. These decisions though are not linear (i.e., investments in some areas will have much higher payoffs then in others). It is critical that one look at the business case to see where the payoffs will come. The stability of the business environment and the variability among potential clients are only some of the influences on which values to weight the most. The next delivery vehicle of packaged assets is tools. Tools are a common mechanism for embodying deep knowledge about a deliverable and how to use it. A given deliverable by itself may not be very valuable if it is hard to create and use. Tools can automate or assist in the use of a deliverable asset, thus reducing the amount of knowledge one needs in order to use it effectively. Tools do not necessarily need to be paired with deliverables. Another common pairing is tools and process. In this situation,tool(s) embody deep knowledge of the process. As people use the tools, they are also implicitly adhering to the process embodied in it. The final delivery vehicle of packaged assets is process. One of the things AC has always been a leader in is the application of well-defined, repeatable processes within the software development lifecycle. This same conceptcan be specialized to working with reusable assets. One of the things that an individual learns when they become a specialist is not just deep knowledge about something, but also detailed procedural knowledge on how to apply that knowledge. At an informal level, when one mentors with an expert,one is both learning the knowledge of this expert, as well as the process on how they apply it. The process delivery vehicle is an explicit representation of this process knowledge, which is then available for reuse by non-experts. 2.3 Experiences with Asset Packaging Given this general characterizationof asset packaging and the delivery vehicles for achieving it, consider the following organizations within Andersen Consulting and their existing reuse efforts: Utilities Industry,Communications Industry, Denver Office, and CSCOE. In the Utilities Industry, the principle reusable assets are various versions of Customer /1. As a packaged asset, Customer/1 uses people and selected deliverables as the delivery vehicles. The expertise which the Utilities Industry is reusing based on Customer /1 was gained over time by working on a variety of engagements. In those engagements, both the reusable assets were created and the people who know how to use the asset were trained (i.e.,by virtue of building the asset they were trained in how to use it). Only a limited amount of effort was put into generalizing deliverables to make them easier to reuse. Reuse was based on the strong similarity of problem shared by most utilities. Because of the similarity of problem, the solutions were potentially reusable across utilities. Since the deliverables have not been packaged in a particularly general form, one relies on the developers to understand what aspects of Customer /1 can be easily changed. This form of deliverable reuse is "clearbox" reuse [this is my term]. Clear box reuse is a less desirable alternative to either black box or white box reuse. Clear box reuse means that one reuses an asset by making changes to what ever portion of its insides one needs to change in order to make it do what you want it to do.This type of reuse is necessary when the developers of the asset have not packaged the asset such that it provides any guidance on what portions of it have been designed to be customized/adapted. The danger of this type of reuse is that one could change some portion of the asset which should not be changed (e.g., some hidden design assumption). This danger is mediated by limiting who can reuse the asset to only people who are intimately familiar with it. This approach also leaves one vulnerable to creating many variant versions of the same asset thus reducing future reusability. The pairing of these two delivery vehicles, people and deliverables,has resulted in a packaged asset which is fairly flexible, productive, and quick when applied to appropriate problems. The greatest limitation is that only people who are intimately familiar with the asset can decide if the problem is appropriate. Additionally, only these people can use the asset effectively. Granted new people can be trained on the asset, but this is a time consuming activity requiring multiple uses of the asset on multiple engagements before enough knowledge is distributed to the trainee. This is a serious problem for future Customer /1 based engagements. The Communications Industry tells an almost identical story on the development and use of BPP1 and BPP2. The only difference between the two is that the Communications Industry is creating a solution center which will keep together people who are familiar with the reusable asset. The intent is to both ensure necessary asset experts are available to support the creation and use of assets, as well as provide an environment for training future experts. This should also result in a dedicated producer organization which supports multiple engagement teams. CSCOE differs from both of the above cases in several important ways. First, CSCOE is an established solution center leveraging the expertise of people with on-going relationships to assets developed by CSCOE. Second, CSCOE's principle asset, UCT, is fairly mature - encapsulating a well understood body of services (i.e.,technical architecture services). The advantage of such maturity is that it is stable and thus presents the opportunity to package the asset for blackbox reuse. Third, UCT is more than just a set of reusable deliverables,it also includes tools and processes which are integral to using UCT. CSCOE has segmented its operations to support (1) maintenance and enhancement of UCT and (2) utilization of UCT. The utilization projects include: PRA, NSP, and several custom jobs. Unique to CSCOE is its concentration on the use of UCT as the technical architecture for all projects. This concentration develops specialized skills in CSCOE personnel on how to best use UCT when building an application. Relative to our delivery values this concentration maximizes productivity, speed of delivery,and distribution of knowledge. Specific compromises are made with respect to flexibility. UCT is "the technical architecture". If a project can not be done on the technical architecture it is not done by CSCOE (i.e., they walk away from business,a radical concept in this firm). An additional cost which CSCOE commits to is ongoing investment in UCT. This investment is required to ensure that it evolves as the business environment changes. Part of this planned evolution is a clear articulation of what services UCT will provide. All users of UCTcan expect these common services. Variabilities were not initially well characterized by CSCOE, but over time CSCOE has supported selected alternative components (e.g., UCT initially only supported one type of database and one type of window painter, now it supports several alternatives). The Denver Office has had a vision similar to CSCOE regarding the use of a common technical architecture and the development and use of tools for working within that environment. This visionis known as the Application Software Factory (ASF). One of the differences between the two, besides being on a different technical architecture, is that ASF demonstrates a more aggressive approach toward advanced tools to aid the developer. ASFhas made significant investments (funded by individual engagements) to develop specialized development tools which have had a demonstrated increase in productivity of 4-5x and an even more dramatic improvements in reliability. Another difference between the two is that the Denver Office has not at this time adopted the solution center model. Without such a model,or at least some explicit mechanism for maintaining and improving their assets,use of their assets will become progressively more difficult as people who are familiar with the asset move on. 2.4 Conclusion When individual people leverage past experiences and previously created deliverables, tools, and processes, this is referred to as ad hoc reuse. When the organization institutionalizes the creation and use of deliverables, tools, and processes by people with specialized skills, the organization is on its way to performing systematic reuse. The idea is to make an organizational commitment to a specific balance of these four knowledge delivery vehicles and then build up a development process around these such that they are maximally leveraged with respect to the delivery values the organizations values (i.e.,some specific valuation of flexibility, productivity,speed of delivery, cost of delivery, investment cost, evolvability overtime, and distributability). The reuse efforts described above have adopted a particular balance. One outstanding issue, among many, is to develop a model of specific business environments and these four delivery vehicles such that it can prescriptively state what the ideal balance should really be for that environment. 3 Comparison In general this work is concerned with assessing the effectiveness of current reuse practices and using this information as a first step toward increasing the overall reuse level of an organization. This work leverages a variety of previous works including: [1], [2], and [3]. References [1]"STARSConceptual Framework for Reuse Processes (CFRP)," tech. rep., Advanced Research Projects Agency (ARPA), 1992. [2]V. Basili and H. Rombach, "Support for Comprehensive Reuse," Tech. Rep. UMIACS-TR-91-23, University of Maryland, College Park, Md., February 1991. [3]P. Kulton and A. Hudson, "A Reuse Maturity Model," in Proceeding of the Fourth Annual Workshopon Software Reuse, November 1991. 4 Biography Dr. Kevin Benner is a researcher at Andersen Consulting's Center for Strategic Technology Research (CSTaR)Software Engineering Lab (SEL). Within SEL, he is a leader of Andersen's reuse program to change their development practices to be more reuse centric. Thus far,the reuse program has focused principally on affecting Andersen's organizations, policies, processes, and people. A secondary goal is to lay the ground work for technology based reuse solutions as they become available. Dr. Benner is also co-principle investigator of the Knowledge-Based Software Assistant Advance Development Model. The KBSA/ADM is an effort to integrate the latest ideas in knowledge-based software engineering into a next generation CASE tool for object-oriented development of software components. Dr. Benner's research interests include: software development environments, software reuse,specification languages, specification development, validation and transformations. Prior to joining CSTaR in 1993, he was a research assistant atthe University of Southern California/Information Sciences Institute from 1988 to 1993 where he completed his graduate degree. His work there was within the ARIESproject and was concerned with the development and validation of formal specifications. Prior to this he was an officer at the Air Force's Rome Laboratory where he was the technical lead on the KBSA program from 1985 to 1988. Understanding OOP Language Support for Reusability Robert Biddle and Ewan Tempero Department of Computer Science Victoria University of Wellington Wellington, NEW ZEALAND Tel: +64 4 471-5328 Fax: +64 4 495-5232 Email: fRobert.Biddle,Ewan.Temperog@Comp.VUW.AC.NZ Abstract Object-oriented programming (OOP)has been widely acclaimed as a technology that will support the creation of reusable software. However,the practical impact has so far been limited. We believe success has been limited because of widespread misunderstandingof the way the technology supports reusability. In this position paper,we introduce our analysis of the connection between OOP and reusability. In particular,we show that inheritance does support reusability, but not in the way commonly supposed. More generally, we claim better understanding about language support for reusable software is necessary. Keywords: Reusability, Object-Orientation, Programming Languages Workshop Goals: Develop Models for Reusability, Analyse and Understand Programming Language Support Working Groups: Reusability vs. Reuse, Reusability Support Models, Reuse and OO Methods, Reuse Handbook 1 Background Object-oriented programming (OOP)has been widely acclaimed as the technology that will support the creation of reusable software [1]. However,it is also true that the amount of reusable software is not as vast as the marketing hyperbole associated with the object-oriented bandwagon led us to expect. So what has gone wrong? There are many definitions of what software reuse means, but most involve some variation of "the use of engineering knowledge or artifacts from existing systems to build new ones" [2]. This definition encompasses many diverse areas, from application generators, to domain analysis, to design patterns, to classification and search, to management [3, 4]. Our interest is in the use of existing code. In particular, we want to establish precisely how different language features impact the reusability of code. As Meyer has said: "any acceptable solution must in the end be expressible in terms of programs, and programming languages fundamentally shape the software designers' way of thinking" [5]. We have been looking at this issue from the point of view of specific languages and specific features [6, 7,8] . 2 Position We believe the lack of success of OOP is due not any particular shortcoming in the technology,but to widespread misunderstanding of the way the technology supports reusability. In this position paper, we briefly outline our analysis of the connection between object-orientation and reusability. We begin with a discussion of what it means for software to be reusable. While reusability is an understood aim in programming language design,it is seldom discussed directly; we have found that discussing it directly helps our analysis. In the next section,we discuss the important features of OOP. We regard OOP as "design by analogy",which we believe offers a concise, consistent,and hype-free description of the object-oriented paradigm, and provides a foundation forunderstanding the support of reusability. Finally we discuss the key issue of the role of inheritance in software reusability. We show that inheritance does support reusability,but does so in ways that are not well understood, and not in the ways usually claimed. 2.1 Reusability and Reuse We believe the first step to a better understanding of this topic is recognising the distinction between software reuse and reusable software. Software reuse is an activity that takes place afterward, when software was initially created in the past. To best support this,reusable software must be created beforehand in such a way that it is later easy to reuse. It is our broad aim to better understand howto support reusability. Towards this, we wish to analyse language structures, and also develop a language independent model for reusability support. We refer to the code that we want to reuse as the component,and this is used by other code that we call the context. For our purpose, reusable software consists of components that can be successfully used by all relevant contexts without change and with the minimum of effort. A context is relevant if it can use functionality in the component. However, the functionality may not be accessible by the context.Typical reasons for this are: unhelpful encapsulation, namespace conflicts,and dependence on irrelevant or inaccessible components. A reusable component therefore must be designed to avoid such limitations. We refer to this property as generality. Where a context invokes a component to make use of some functionality,nothing but the functionality should matter. In fact,there may be no requirement that it be provided the same way every time. The weaker the binding between the context and the component,the more components can be used in that context. The strength of the binding required between the context and the component represents the flexibility of the binding. Finally,a context invoking a component connects two different sets of assumptions and behaviour. Care must be taken to prevent connections where assumptions and behaviour are sufficiently misaligned that the results are not well defined. Prevention of this kind of mistake requires concern for safety. 2.2 Object-Orientation and Reusability To best understand how OOP involves reusability,it is important to understand just what OOP is all about. In fact,we believe there are two elements in the foundations of OOP, one technical and the other more philosophical. Both have significant practical implications. The more technical foundation of OOPconcerns an evolutionary process in program design and programming language support. From a historical perspective, OOP may be seen as the confluence of various threads of development in program design: some involving the design of control, others involving the organisation of data. The more philosophical foundation of OOP goes deeper,and directly addresses one of the most fundamental issues in programming: organising complexity. There are two key ideas involved. The first idea is that we should design programs by analogy. That is, we should organise our programs using structures like the structures in the application domain. The second idea is that most application domains, like the real world, are commonly regarded as structured as entities and actions on entities. In the world of entities and actions, it is typical that both entities and actions are involved in many different contexts. Entities are used for various purposes, and the same action may be applied to various entities. Accordingly, when we design by analogy, we are likely to use structures that either have already been needed and designed before, or that will needed in the future. Either way, there are obvious advantages of reusability. The more technical foundations of OOP also support reusability, particularly via encapsulation. Encapsulation means that the object is a capsule, whereby the behaviour and state are bound together as a unit, with the only access being the designated operations. For the object to be reusable in different (perhaps as yet unknown) contexts, it is necessary to make certain that the behaviour cannot be interfered with. Moreover, it might be useful to use the context code together with a different implementation of the object, then the reusability of the context code is of interest. Accordingly it is important that the context code cannot depend upon the implementation of the object at all, and this can be enforced by encapsulation. 2.3 Classes It is a big organisational step from seeing the world as consisting of entities to seeing the world as classes of entities; it can also be a problematic step. Every thing is distinct, but we consider many things to have such similar operations and behaviour we regard them as mere instances of the larger class. In the real world, however, there are many ways to classify things,and the ways are not always consistent. Some OOP languages allow dynamic organisation of objects into classes; others require the programmer to deal will classification conflicts at the design stage, and make classes explicit in the program - this typically allows more efficient implementation. Whichever approach is taken,there are strong organisational reasons to structure objects into classes: it fosters reusability, because code can be written for any instance of a class,rather then for one particular object. 2.4 Composition Perhaps the most common way that two different entities can be statically structured together is by composition: where one object is used as a component part of the other. This is common in the real world, where technology and nature build larger things using smaller things. We model this in programs, and so OOP languages typically allow the construction of objects by implementing them using several other objects. This facility thus makes further use of the reusability of objects and classes, especially because a wide variety of larger kinds of objects can be constructed using other classes in various ways. Moreover, the end result is the creation of more objects and classes, allowing further reusability still. 2.5 Inheritance One of the ways we deal with thereal world is by organising objects with similar operations and behaviour into classes. As discussed above, simple classification cannot always adequately represent the necessary complexities. One such situation occurs when there are objects that do seem to belong in a class, except for some specialised operations and behaviour. In the real world this leads to taxonomical hierarchies,with a general category at the top which is then divided and sub-divided into increasingly specialised cases. In OOP, this kind of classification hierarchy is usually represented directly with inheritance. This is undoubtably the most celebrated mechanism in OOP languages,but also the most misunderstood. The main idea is that object of a more specialised class inherits the operations and behaviour and operations of a more basic class. The usual claim is that this is a big advantage because it involves reusing the operations and behaviour of the base class. It does involves reusing the base class, but it is not a big advantage. After all, the base class can be reused perfectly well by using composition. For example, a manager might be regarded as having a component that is an employee. The real advantage of inheritance is gained because the new class conforms to the interface of the base class. That is: any place an object of the base class can be used,an object of the specialised class can too. Accordingly,any context code that takes objects of the base class can also be used with objects of the specialised class. For example, if a manager is regarded as a specialised form of employee, any program that uses employees will also work with managers. This is the real advantage of inheritance: it makes the context code reusable. Some OOP discussion distinguishes inheritance and polymorphism. Inheritance can mean that objects of the specialised class conform to the base class interface in a primitive way by ignoring any specialised behaviour. Polymorphism then implies the extra step, where specialised objects conform to the base class interface,but retain their specialised behaviour. The nature of the advantage is the same flexibility in both cases, simply allowing lesser or greater reusability of the context code. Inheritance and polymorphism are used to represent classification hierarchies in the application domain, but can also play a role in program organisation. Where a class of objects may have several different implementations, they can be regarded as specialised cases of an abstractclass. The abstract class itself has no behaviour, but specifies an interface to which inheriting classes conform. The advantage is that context code may then be written in terms of the abstract class, and then used with any inheriting class. In this way the context code will be reusable with any implementation of the class,even if several implementations are used within one program. Abstract classes are also the basis of Object-Oriented Frameworks [9]. In this approach, a high- level design is written as a program that consists only of abstract classes, and the design is applied to particular situations by providing implementations of the abstract classes. In this way the advantages of reusability can be extended to the program design level, as well as the program implementation level. 2.6 OOP and Reusability Support Earlier we outlined our working model for reusability support. In these terms,the key features of OOP can be described as follows: Encapsulation: ensures safety of connecting context and component, so ensuring both are reusable elsewhere. Composition: allows generality in object implementation contexts, so that the context is reusable with other component implementations, and equivalently that components may be reusable with various contexts. Inheritance: enables flexibility of coupling context and component, so that the context may be reusable with components of conforming interfaces. These relationships between OOPand reusability have some important implications for object-oriented design. Most importantly,program designers hoping to achieve reusability must understand how OOP can help deliver it. The process of object-oriented design is largely one of class identification and class organisation. At any point in the design,it is reasonable to consider whether, and how well, the reusability caters for future reuse. In particular,there are significant implications of our observations about inheritance and reusability. Because inheritance supports reusability of context code, programmers should take care to design context code to take advantage of this support, and thus facilitate later reuse. We believe this is the major implication of inheritance for program designers, but also suspect it is not widely understood. Throughout the design process, understanding how OOP can deliver reusability will can illuminate attractive options, and help lead to success. 3 Comparison While there have been a number of discussions on reusability, very few consider the impact of language features on the reusability of software. Those that do tend to blur the distinction between reuse of software and reusability of software, often using both concepts in the same sentence as if they are synonyms [1, 10]. As a consequence,any comments that do pertain to reusability are overlooked. Although the distinction between software reuse and reusable software is often confused, it is generally accepted that effort must be made in the creation of code if it is to be made easier to reuse. This is generally referred to as "design for reuse". Such discussions tend to focus on general advice and heuristics for making classes more reusable[9] or higher-level class organizations that have been found to have been useful in the past [11]. Other efforts such as the "adaptive software" approach [12] support reusability with strategies and tools that use structures within the code, but that work at a level above the code. While all these approaches are important, and offer significant assistance in the creation of reusable code,in our own work we have been primarily concerned with support at the programming language level. References [1]B. Meyer,"Reusability: the case for object-oriented design," IEEE Software , pp. 50-64, Mar. 1987. [2]W. Frakes and S. Isoda, "Success factors for systematic reuse," IEEESoftware, pp. 14-22, September1994. [3]I. Software, "Special issue on systematic reuse," September 1994. [4]T. J. Biggerstaff and A. J. Perlis, eds., Software Reusability, vol. 1. New York: ACM Press, 1989. [5]B. Meyer,"Genericity versus inheritance," in 1986 Object-Oriented Programming Systems, Languages, and Applications Conference Proceedings (N. Meyrowitz, ed.), pp. 291-405, Oct. 1986. Published as ACM SIGPLAN Notices, 21(11), November 1986. [6]P.Andreae, R. Biddle, and E. Tempero, "Understanding code reusability:Experience with C and C++," New Zealand Journal of Computing, vol. 5, pp. 23-38, Dec. 1994. [7]R. Biddle, E. Tempero, and P. Andreae, "Object oriented programming and reusability," Tech. Rep. CS-TR-95/6, Victoria University of Wellington, 1995. [8]R. Biddle and E. Tempero, "Reusability and inheritance," Tech. Rep. CS-TR-95/8, Victoria University of Wellington, 1995. [9]R. E. Johnson and B. Foote, "Designing reusable classes," Journal of Object-Oriented Programming, June/July 1988. [10]J. Micallef, "Encapsulation, reusability and extensibility in object- oriented programming languages," Journal of Object-Oriented Programming, pp. 12-36, April/May 1988. [11]E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Professional Computing Series,Addison-Wesley, 1995. [12]K. J. Lieberherr,I. Silva-Lepe, and C. Xiao, "Adaptive object-oriented programming using graph-based customization," Communications of the ACM, pp. 94-101, May 1994. 4 Biographies Robert Biddle is a faculty member in the Computer Science department of Victoria University of Wellington,New Zealand. He is involved in research on software reusability,distributed systems management, and mathematics education. He teaches courses on object-oriented programming, and human-computer interaction. He received a Ph.D. in Computer Science in 1987 from the University of Canterbury in NewZealand; previously he received B.Math and M.Math degrees from the University of Waterloo in Canada. He has also worked as a programmer for Bell Northern Research, Systems Dimensions, and the Government of Canada. Ewan Tempero is a faculty member in the Computer Science of Victoria University of Wellington, New Zealand. His main research interest is examining how programming languages features affect the production of code. His current focus is the impact programming languages, particularly object-oriented languages,have on the reusability of the resulting code. He is also interestedin various aspects of distributed systems. He received a Ph.D.in Computer Science from the University of Washington in 1990. Second Order Reusable Libraries and Meta-Rules for Component Generation Ted J. Biggerstaff Microsoft Research One Microsoft Way Redmond, WA 98052-6399 Tel: (206) 936-5867 Email: tedb@microsoft.com Abstract I discuss the scaling limitations inherent in libraries of static reusable components and motivate the difficulties by an example. I suggest that these limitations are not solvable in the context of todayÕs programming language representations. Finally, I propose a different kind of reuse library called a Òsecond order reuse library.Ó Such libraries extend conventional libraries of static components by the addition of Òmeta-componentsÓ that transform the structure of the static components by introducing feature variations into the static components. I will argue that second order libraries can overcome the limitations inherent in conventional libraries of static, concrete components. Greater detail on the organizational characteristics required of such meta-components is provided in Biggerstaff 94. Keywords: Concrete components, repositories, limitations, payoff, scaling, generation, transformations. Workshop Goals: To explore the notions of new representational abstractions for reuse components and the concomitant requirement for generative architectures to support those abstractions. Working Groups: Domain analysis/engineering representations, or possibly reuse and OO methods and technology. 1 Background I organized the first workshop/conference on reuse in Newport, RI (1983). Since then, I have done research on reuse and related topics (e.g., design recovery) and this has resulted in a number of books, papers and systems. Most recently, I have been working in the area of representations that can enhance the reusability of components and yet allow most of the reuse to happen automatically. This work has led me to consider the limitations of the concrete representations (i.e., mainstream programming languages) for reusable components and to seek ways around the limitations they introduce. The concept of second order reuse libraries, which include transformation-based components, arose from this work. 2 Position 2.1 Hypothesis The first hypothesis of this paper is that structurally static reusable components (i.e., components that allow program construction only via the strategies of functional composition and forward refinement based on parametric substitution) are not adequate to solve the scaling problem [1,2]. As a consequence, classes, abstract classes, templates, and similar mechanisms are inadequate tools for developing reuse systems. The second hypothesis of this paper is that meta-components a.k.a. meta-rules1 (i.e., rules that transform and revise the design of static components) are required to overcome the scaling problem. The hallmark of a meta-rule, in addition to the fact that it revises the design of a static component, is that the operational logic of a meta- rule may be based on design information that exists outside of the code proper, e.g., a property of a part of the application computation. Such design information might be derivable from the code but such derivations typically require a difficult process of inference and often require evidential reasoning (i.e., fuzzy reasoning) and guessing. A further hallmark is that the effect of meta-rules is often global across one or more components. I will use the term ÒSecond Order Reuse SystemÓ for libraries that contain meta-rules in addition to static components2. By implication then, a ÒFirst Order Reuse SystemÓ is one that contains only static components -- components that can be composed and specialized but not architecturally revised in an automated fashion. I will present a small example of the kind of structural revision typical of meta-rules to motivate the need for them and to illustrate their nature. 2.2 Problems with composition of static components Reuse systems that are based on static components rely on several mechanisms to create the structure of the resulting program: ¥ Component composition: Large scale application program structures are formulated by the assembly of the static reusable components. This is the fundamental strategy for building up and enriching the structure of the target program. ¥ Forward refinement: Forward refinement is a substitution-based strategy that rewrites the body of a component (e.g., a macro component or a template component) by substituting the componentÕs arguments for references to the formal parameters within the body of the component. Forward refinement is often used to support component composition. In contrast to function calls, forward refinement typically happens before run time and alters the structure of the source program. ¥ Specialization: Specialization reduces the generality of components by pruning parameters and paths on the basis of constant or known data values used within the program. An example of a type of specialization is currying functions based on knowing the data value of one of a functionÕs parameters. Specialization is a kind of forward refinement that is also a highly constrained form of partial evaluation. The key problem with first order reuse libraries is that all composition, refinement, and specialization activity is localized to predetermined areas of a target program. However, many design features that one would like to treat as separable components are global in their effect and transformational in their nature. That is, they are not static components that can be locally composed, refined, or specialized but rather they are second order components. They are operations on static components and very often their effects need to be felt globally over the whole target program. The exact range of their effect cannot be determined a priori but rather is often dependent on the structure of the application program in which they are used. They revise and modify basic static components to incorporate new feature variations and to coordinate global feature variations among the (often many) affected components. 2.3 An example of the problem The need for meta-components is illustrated by the design of a hypothetical Integrated Development Environment (IDE3) which one might like to build from reusable parts. IDEs are evolving toward architectures that perform most of their operations (e.g., compiling or program revision) incrementally. This incrementality becomes more and more important as the size of the target programs (i.e., the programs developed using the IDE) grow larger and larger and the overhead associated with batch-oriented operations (e.g., compiling) becomes more and more onerous. Such incrementality forces customization of the IDEsÕ architectures and this customization introduces requirements for many variations of common static components, that is, combinatorially many variations of what is conceptually a single abstract component. The need for such variability makes it difficult for reuse libraries with static components to accommodate the resulting requirements without combinatorially exploding (i.e., providing a hand built reusable component variant for each combination of features that might be needed). The alternative to combinatorial explosion of the component library is a strategy that builds all of the feature variations into highly general components and requires run-time data to be used to sort out which pathways out of the complex warren of possible pathways are applicable to a specific application of the component. Thus, only a small portion of the features are required in any specific application context. These general components come with so much overhead baggage that their performance typically fails to meet the application requirements and with such mind numbing complexity that they are difficult to maintain and change. Neither of these options is acceptable. The software development organization is trapped between exploding growth of their component library and declining performance and maintainability of their target systems. I am claiming that the way out of this trap is to provide a small number of basic static components that capture the general abstractions to be reused and then add to those static components some meta-components (or meta-rules) that revise or massage the static components to include just those features that are needed for any given application context. Let us look at an example of one such feature variation and analyze the kind of meta-component needed to accommodate it. The following example illustrates a design feature that is motivated by IDE incrementality. This is only one of a large number of interacting features that are motivated by incrementality in IDEs.  Figure 1 illustrates the kind of data structures typical of an IDE system. In this case, we have two pointer attributes -- Type and DeepType -- within the IDE data structures. These attributes reference remote parts of a target program. DeepType is the inferred, most basic type of the variable or expression to which it is associated. Type is the data type as declared by the user. Various parts of the IDE (e.g., the compiler subsystem and often the display subsystem) will need to use these and similar attributes. Further, the computation of such attributes for a large program is often computationally quite expensive. Therefore, they are often computed once and the values cached in data structures associated with the target variables or expressions. The algorithms for performing the costly operations (e.g., inferring the deep type from the surface type) are known and are likely to be components in a reusable library. However, a problem arises from using such components in the context of an incremental IDE system. Changes made interactively by the user from the IDEÕs editor (e.g., changing the foo typedef) may invalidate the cached value for DeepType attribute of the expression Òx = a + b ;Ó. Consider the following pseudo-code (a vast simplification of a real IDE design): 1. Infer type of operands and operator of current expression; 2. Cache results in expression description; 3. ....... 4. Respond to user edit actions; 5. Use expression type information to compile expression; Steps 1 and 2 compute the DeepTypes and cache them. This is an expensive operation because it may have to chain through many levels of definitions. It is typically a batch oriented operation where the batch size may be a single function or a full .c file. Step 3 may potentially use the DeepType for some orthogonal purpose. For example, the display subsystem may use the DeepType information to compute display properties of certain kinds of program structures. Step 4 is the user interface subsystem and it services the user who may be using the editor to change the program. For example, the user might decide to change Òtypedef int fooÓ to Òtypedef double fooÓ, which will invalidate the DeepType value for the expression Òx = a + b ;Ó. Clearly, the design of this pseudo code (which ideally would be assembled from reusable components) has to be altered to accommodate this potential for invalidation of the deep type attributes and it must be altered in a coordinated and global manner. It is important to note that the property of whether or not deep types need to be recomputed in step 5 must be determined on the basis of the properties of steps 3 and 4 and these properties may be very difficult to determine in any automated way. In this case, recomputation is necessary. So, steps 1 through 5 must be revised (in a globally coordinated way) so that some logic is introduced to deal with the invalidation actions and then later, to recompute the deep type values when they are needed. There are a variety of designs (i.e., meta-rules) that might be chosen to perform this revision. For example, an invalidation field might be introduced at the item level, the function level, or the module level to indicate that the deep types must be recomputed. Similarly, depending upon how much work the invalidation code does to narrow down the specific entities that need to have their deep types recomputed, the actual deep type recomputation can have a broad range of complexity and computation costs. On the one hand, it can be fairly broad and include extra items whose deep type does not actually need to be recomputed in order to simplify the invalidation code. Alternatively, the recomputation code may be much more narrow and only expend computational resources where they are really needed, at the cost of greater complexity in the invalidation code. In general, the variety of invalidation designs is quite wide and often highly application specific. Consequently, it seems unlikely that any first order reuse library (i.e., one containing only static components) would be able to cope with the potential variety that might be needed. Further, the invalidation feature and its design variations are only one class of a variety of similar features that are motivated by IDEs that emphasize incrementalism. This rich variety lends even more weight to the argument that first order reuse libraries will not suffice to solve the library scaling problem. 2.4 Conclusions The conclusions from this line of reasoning are: 1. First order reuse libraries (i.e., those containing only static, concrete components) will fail to solve the scaling problem; 2. Programming constructs built in conventional languages (e.g., abstract classes, templates, etc.) will fail to solve the scaling problem; and 3. Second order reusable libraries will be required to solve this problem, i.e., libraries that provide the ability to write general transformations to manipulate the designs of the static components in ways that generate feature variations of the static, concrete components. 3 Comparison Batory et al and Neighbors [1,3] have both effectively created second order reuse libraries with each having slightly differing emphases. See Biggerstaff 94 [2] for a more detailed comparison. Similarly, Kiczales et al 91 [4] have in effect produced a mechanism that is capable of being applied to the creation of second order reuse libraries. The emphasis of their research, however, is focused more on allowing clean, simple abstractions without paying the price of the implementation inefficiency that often accompanies such abstractions. Their technique is to open up the implementation of the compiler and allow the user to engineer high performance implementations based on his special knowledge of his application context. References [1] Batory, D., Singhal, V., Sirkin, M. and Thomas, J. ÒScalable Software Libraries.Ó Symposium on the Foundations of Software Engineering. Los Angeles, CA, December, 1993. [2] Biggerstaff. T.ÒThe Library Scaling Problem and the Limits of Concrete Component Reuse,Ó Third International Conference on Software Reuse, November, 1994, Rio de Janeiro, Brazil. [3] Neighbors, J.M. Software Construction Using Components, PhD Dissertation, University of California, Irvine, CA, 1980. [4] Kiczales, G., des Rivieres, J. and Daniel G. Bobrow, The Art of the Metaoject Protocol, MIT Press, 1991. Biography Ted J. Biggerstaff is Research Program Manager of the Intentional Programming Project at Microsoft Research Laboratories. He is responsible for exploring ways of enhancing reuse capabilities of application development. Before coming to Microsoft, he was Director of Design Information at MCC where he led the research and development of the DESIRE design recovery system. Before that, he worked for ITT's programming laboratory (on reuse) and Boeing Computer Service's Advanced Technology and Application Division (on CASE tools). He received a Ph.D. in Computer Science from the University of Washington in 1976. He is a member of ACM, IEEE Computer Society, IEEE Software magazine Industrial Advisory Board, and the Washington Technology Center Software Review Board. 1 I will call these components meta-components when I wish to emphasize their component-oriented role in reuse and meta-rules when I wish to emphasize their operational behavior. 2 For abstractly similar ideas, see [4]. 3 IDEs minimally contain an editor, compiler, and debugger. An example of an IDE is MicrosoftÕs VC++. RAMP: A Reusable Application Module Process Eric W. Booth Computer Sciences Corporation System Sciences Division 7700 Hubble Drive Lanham-Seabrook, Maryland 20706 Tel: (301) 794-2013 Fax: (301) 794-2280 Email: ebooth@csc.com Abstract Introducing systematic software reuse into the software engineering process often conflicts with the primary driver of delivering the current system on schedule and within budget. Developing for reuse can lengthen the schedule and increases the cost in the short term. However, until making this up-front investment, an organization cannot realize the schedule and budget benefits of developing with reuse. Resolving this conflict requires changing the traditional view of the software engineering to facilitate the development and evolution of what we call Reusable Application Modules, or RAMs. This paper presents CSCÕs RAM Process (RAMP) which is based on the best practices among System Sciences DivisionÕs most successful reuse projects and on the current research and development that is taking place throughout the software reuse community. Keywords: process, software engineering, life cycle Workshop Goals: to discuss current reuse technology trends with researchers (particularly in the area of generative systems) and to share technology transition and insertion experiences with researchers and fellow practitioners. Workshop Groups: reuse process models, product-line development, institutionalizing reuse, generative reuse systems 1 Background As a practitioner involved in software reuse technology transfer and insertion, I have taken part in and observed several software reuse efforts throughout Computer Sciences Corporation (CSC) System Sciences Division (SSD). We document each reuse success in papers, history reports, and corporate reprints. However, to be useful for future projects, a reuse guidebook, capturing the best practices and outlining a comprehensive process model was required. CSC/SSD sponsored a multi- year IR&D effort, combining our reuse Òbest practicesÓ with the promising reuse research into, Systematic Software Reuse: A Guidebook for Developing Cost Effective Systems [1]. This position paper summarizes one aspect of CSCÕs guidebook: the Reusable Application Module Process (RAMP) model, comprising three separate, parallel disciplines: domain engineering, library management, and application engineering. CSCÕs RAMP Model: A Systematic Software Reuse Process 2 Position: RAMP Overview CSCÕs RAMP model provides a framework for planning and managing the parallel domain engineering and library management activities in addition to the more standard application engineering activity. This framework identifies and relates the objectives, activities, and products among the three parallel disciplines. RAMP identifies the major technical activities involved in implementing a systematic software reuse program and provides a list of typical products from each activity. RAMP also provides some flexibility in selecting how each activity is accomplished, based on the availability of legacy systems, domain experts, reuse process experts, and schedule constraints. The choices of methods, tools, and products are specified as part of a plan developed during context analysis. 2.1 Domain Engineering The focus of domain engineer-ing is much broader than application engineering, encom-passing families of systems and multiple clients. Individual clients typically are unwilling to incur the overhead of creating a general solution; however, they usually are willing to reap the benefits of domain engineering (e.g., meeting 95% of their requirements at 50% of the cost). Organizations can accom-plish this through investment within specific business areas. However, systems may be large and complex and the investment can be both high-cost and long-term. High-investment and long----term return translate into high risk. Therefore, domain engineering may be funded separate from application engineering and the risk mitigated by adopting an evolutionary approach to establishing a domain engineering capability. Domain engineering , a term gaining acceptance in the industry, is a life cycle process for evaluating current systems and determining the potential for creating reusable assets. The adoption of the term domain engineering is the result of an expanding definition for the original term domain analysis. Domain analysis methods have expanded to include various levels of detail and different software life cycle activities. Some definitions of domain analysis include aspects of domain requirements definition, requirements analysis, and the creation of a generic design. Other domain analysis methods even include domain implementation as a validation activity.Therefore, the preferred term domain engineering (DE) encompasses all life cycle activities associated with evaluating, selecting, or creating reusable assets: á Context AnalysisDefines the domain or business area of interest, collect collect (and possibly improve upon) available resources related to the domain, and plan the overall domain engineeringDE effort. á Domain AnalysisDefine the features and capabilities of a class of related software systems, within the domain, and develop a general set of requirements for the Òproduct family.Ó1 The requirements are described with special consideration of the commonality between systems and the variability among systems. á Domain DesignDefine the generic design(s) or software architecture(s) of a family of systems within the domain, called domain- specific software architecture(s)s (DSSA). This activity defines static and dynamic properties, component architecture, and interconnection protocols. á Domain ImplementationCreate reusable source code level assets by translating generic requirements, into a solution that fits into the framework of one or more DSSAs. This entails mapping the domain language into a form that implements a DSSA. It is important to note that the Òreusable source code level assetsÓ may comprise a translator or generator that that embodies knowledge of the DSSA and translates the abstract domain language to the concrete third-generation language [2]. á Asset TestingEvaluate if the product is right (based on previous domain products) and if it is the right product (based on domain, business needs, and user requirements). 2.2 Library Management Library management is the process of growing an asset (or product) library and the process of tracking, evaluating, and maintaining a collection of assets, or a product line. There is a tight interaction between the domain engineering and library management efforts. For each library management effort there are several active application engineering projects. While library management is an important aspect of RAMP, it is important to emphasize that libraries are not the reuse solution, rather they are an important component of a systematic reuse program. It is possible to have an effective reuse program, which produces a substantial return on investment, with relatively few numbers of components and without any sophisticated automated library tools. The important ingredients for success are targeting what goes into a library and how the libraryÕs contents are used. Producing a reuse library is a worthless investment, unless there has been an accompanying change in the management and technical culture which makes the use of the library an integral part of the software development process. The library management effort is an iterative process, applied across domain engineering products. The library management activities are grouped into a 3-P model2: á PopulatingControl what goes in the library. This includes defining the process of how assets are selected for inclusion into (or removal from) the library. á PublishingControl what is allowed out of the library, but also to ñsellî the assets to the consumers. This includes establishing an efficient capability for the consumer to locate, evaluate, and retrieve the necessary assets and related information. á PolishingControl what (and how) changes are made to the assets and to the library tool(s). This process must include the continual evaluation of strategic goals and the impact of change on multiple application engineering systems, to assure that the library and its management system can adapt quickly to a changing business environment. 2.3 Application Engineering Application engineering is the term used to describe the typical software development process that is evolving to incorporate the increasing levels and the expanding scope of software reuse. The application engineering life cycle is the process of composing, generating, operating, and maintaining a software system from an existing base of reusable assets. Software systems, or applications, are engineered in the context of a domain to satisfy a specific clientÍs need. Two key reuse activities are consumption of reuse assets and the identification of new assets that are candidates for reuse. Assets from one or more libraries are consumed throughout the application engineering life cycle. Reuse consumption is composing or generating one system with assets, in contrast to domain engineering that is building assets for multiple systems. Reuse identification occurs when assets are unavailable to meet a client requirement. This systematic reuse consumption and identification changes the roles, activities, inputs, constraints, and products for each activity of the traditional software engineering life cycle: á System Requirements Definition and DesignDetermine if the system is within an established domain, select a discrete set of requirements from the domain model which represent a clientÍs needs, and allocate those requirements to application components based on a domain specific system architecture. Any deficiencies in the domain model are identified. á Software Requirements DefinitionFocus is on the requirements new to the domain model and derive project specific software requirements specifications for each new application component. á Software DesignSelect a DSSA, identify the software components, interfaces, and relationships necessary to satisfy the system requirements and specifications. á Software ImplementationTranslate the instantiation of a generic software architecture into executable code (a high-order language (HOL), Fourth Generation Language (4GL), or other executable solution) and to perform initial testing. á Software and System TestFormally verify each component, subsystem, and the overall system against the software and system requirements. 2.4 RAMP Model Summary In software engineering, maintenance is historically defined as ñall the other previous activities repeated.î In this sense the RAMP model more closely resembles software maintenance rather than software development. However, RAMP introduces a key change in the process. Traditional software development and maintenance are project or system oriented; that is, the activity is focused on one instance of a system. RAMP is concerned with developing and maintaining a class of systems within a targeted domain. As such RAMP is fundamentally different from both the traditional development and maintenance processes. 3 Comparison This view of a systematic software reuse process is an aggregation and organization of methods and techniques developed in the reuse community and employed on projects in SSD. For example, we have used elements of Feature-Oriented Domain Analysis (FODA) [3] for domain engineering, the Basic Interoperability Data Model [4] for library management, and concepts from DRACO [5] for application generation. These are methods which may be employed within the context of a systematic software reuse process. The two activities that RAMP effort most closely resembles are the SEIÕs Model-Based Software Engineering (MBSE) [6] and the STARS Conceptual Framework for Reuse Processes [7]. References [1] Booth, E.W. and Bowen, G.M, Systematic Software Reuse: Guide To Building Cost Effective Systems, internal publication, Computer Sciences Corporation, 1995. [2] Biggerstaff, T.J., ÒThe Limits of Concrete Component Reuse,Ó Proceedings of the Sixth Annual Workshop on Software Reuse, Owego, NY, Nov. 1993. [3] Kang, K.C., Cohen, S.G., Hess, J.A., Novak, W.E, and Peterson, A.S., Feature-Oriented Domain Analysis (FODA) Feasibility Study, Technical Report CMU/SEI-90-TR-21, November 1990. [4] Hobbs, E.T., et al., A Basic Interoperability Data Model for Reuse Libraries (BIDM), Reuse Library Interoperability Group, IEEE Standards Committee, P1420.2 Software Reuse, April 1993. [5] Neighbors, J. M., ÒDRACO: A Method for Engineering Reusable Software Systems,Ó Software Reusability, eds.: T. Biggerstaff and A. Perlis, ACM, New York, NY, 1989, pp. 295-320. [6] Withey, J.V., Model-Based Software Engineering (MBSE) Draft, Technical Report CMU/SEI-93-TR-xx, Software Engineering Institute, November 1993. [7] Creps, D., STARS Conceptual Framework for Reuse Processes (CRFP) Volume I: Definition Version 3.0, Unisys STARS Technical Report STARS- VC-A018/001/00, October 1993. Biography Mr. Booth is a Senior Computer Scientist at CSC in the Applied Technology Department supporting the NASAÕs Data Systems Technology Division's Reusable Software Library project. He works closely with SSD Software Process Improvement Center and CSC Corporate Technology Center to define, train, and transition systematic software reuse into CSCÕs process. Prior to his current assignment, Mr. Booth's responsibilities have included software development on NASA space applications, including satellite simulators, where he developed a DSSA, a domain- specific specification language, and an application generator. Mr. Booth received his MS in Computer Science from Johns Hopkins University. 1 A product family is used here to refer to a set of systems which are logically the same, but differ in order to meet specific user requirements (cost, configurations, country, regulations, size, safety, or other differentiating factors). 2 The 3-P model is an instance of the class of all 3-character models. Software Reuse in High Performance Computing Shirley Browne University of Tennessee 107 Ayres Hall Knoxville, TN 37996-1301 Tel: (615)974-5886 Fax: (615) 974-8296 Email: browne@cs.utk.edu Jacki Dongarra University of Tennessee and Oak Ridge National Laboratory Email: dongarra@cs.utk.edu Geoffrey Fox Syracuse University Email: gcf@npac.syr.edu Ken Hawick Syracuse University Email: hawick@npac.syr.edu Tom Rowan University of Tennessee and Oak Ridge National Laboratory Email: rowan@msr.epm.ornl.gov Abstract Although high performance computingarchitectures in the form of distributed memory multiprocessors have become available, these machines have not achieved widespread use outside of academic research environments. The slowness in adopting high performance architectures appears to be caused by the difficulty and cost of programming applications to run on these machines. Economical use of high performance computing and subsequent adoption by industry will only occur if widespread reuse of application code can be achieved. To accomplish this goal, we propose strategies for achieving reuse of application code across different machine architectures and for using portable reusable components as building blocks for applications. Keywords: high performance computing, parallel and distributed computation, linear algebra, distributed memory multiprocessor Workshop Goals: Advance state of reuse of parallel software Working Groups: Tools and environments, Education 1 Background We have been involved in the development of the Netlib mathematical software repository (http://www.netlib.org) and of much of the reusable software available from Netlib and the National HPCC Software Exchange (NHSE) (http://www.netlib.org/nse/). The NHSE is a recent effort to construct a distributed virtual repository of all the software produced by the High Performance Computing and Communications (HPCC) program. As part of the NHSE, we have developed the InfoMall technology transfer program (http://www.infomall.org/) which identifies reusable HPCC technologies and makes them available to industry. In the area of parallel computing, we have carried out pioneering work in programming applications on parallel computers and in determining how to make the resulting codes portable across different parallel architectures. 2 Position High performance computing involvesthe use of parallel computing systems to solve computationally intensive applications. Some of these applications, termed Grand Challenges, address fundamental problems in science and engineering that have broad economic and scientific impact. Examples include global climate modeling,materials simulation at the molecular level, coupled structural and airflow simulation for aircraft, and mapping of the human genome. The computational requirements of these problems have pushed the physical limits of how fast processors can operate and have focused effort on increasing the number of processors in a multiprocessor. Consequently, emphasis is being placed on developing parallel algorithms and software that are scalable,meaning that they continue to perform their tasks efficiently as the number of processors is increased. Parallel computing will realize its full potential only if it is accepted and adopted in the real world of industrial applications. Cost-effective parallel computing will require that the specialized hand coding of parallel programs gives way to widespread reuse of parallel software. Although specialized hand coding can achieve peak performance on thetarget architecture, a small loss in performance will be acceptable to achieve a more productive software development environment. Reuse of parallel software involves the following aspects: Portability and scalability of application codes. Because writing parallel programs requires substantial effort and investment, it is unacceptable to rewrite for every current and future parallel architecture. Code that is portable and scalable, however, will run with high efficiency on almost all current and anticipated future parallel architectures. Use of fundamental building blocks. A large number of scientific and engineering applications rely heavily on a small core of linear algebra routines. Scalable, portable, efficient, and easy-to-use versions of these routines will provide the fundamental building blocks for applications. We propose a strategy for promoting software reuse in high performance computing that includes the following components: 1. A classification scheme for applications thatmaps an application to a problem class, rather than to a machine architecture, and the development of high level software systems based on this classification. Fox, together with other researchers,has developed a classification scheme for applications that includes the categories synchronous, looselysynchronous, asynchronous, and embarrassingly parallel [1]. After a developer maps an application to a particular class, he should express that application in a programming language that has features optimized for that class, rather than for a particular machine architecture. Using a language such as Fortran 77 or C enhanced with message-passing obscures the parallelism that is inherent in a problem. Expressing a problem in a parallel language that is nearer the problem than to the target machine automatically enhances reuse because the resulting program may be more easily ported to a variety of parallel machines. 2. Development of high-level parallel languages for writing scalable, portable code. High Performance Fortran (HPF) [2] has been agreed on as a new industry standard data parallel language. The synchronous and embarrassingly parallel application classes may be expressed straightforwardly in HPF. Researchers are working on extensions to HPF to handle the irregular structure of loosely synchronous problems[3]. HPF compilers will be able to obtain good performance for the same code on a variety of parallel architectures [4]. Asynchronous problems cannot be expressed in a data parallel language and will require different algorithmic and software support built on top of message passing. 3. Adoption of the Message Passing Interface (MPI) portable message- passing standard. The MPI standard defines the syntax and semantics for a core of library routines useful for writing portable message-passing programs in Fortran 77 or C [5]. MPI forms a possible target for compilers of high-level languages such as HPF. 4. Development of a scalable linear algebra library for distributed memory multiprocessors. Researchers led by Jack Dongarra at the University of Tennessee are developing the ScaLAPACK library of subroutines for performing linear algebra computations on distributed memory multiprocessors [6, 7]. When completed the library will contain subroutines for performing dense, banded, and sparse matrix computations. Among the important design goals are scalability, portability,flexibility,and easy of use. All communication in a ScaLAPACK library routine is handled within the distributed Level 3 Basic Linear Algebra Subroutines (BLAS) and the Basic Linear Algebra Communication Subroutines (BLACS), so that the user is isolated from the details of the parallel implementation. Specially tunedversions of the BLAS and the BLACS may be implemented by the manufacturer of a parallel architecture to achieve near peak performance for matrix computations. 5.Dissemination of software and information related to high performance computing via the National HPCC Software Exchange (HPCC). The NHSE has a software submission and review procedure that classifies software submissions and evaluates them according to a set of criteria that includes scope, completeness, documentation, construction, correctness, soundness, usability, and efficiency [8]. Roadmaps to HPCC software and technologies are being developed that will assist the user in locating and understanding relevant reusable components. For example,a roadmap that illustrates the use and application of the High Performance Fortran (HPF)language has been developed (http://www.npac.syr.edu/hpfa/). Educational and technology transfer materials and activities are also being undertaken by the NHSE. 3 Comparison The Archetype Working Groupat CalTech (http://www.etext.caltech.edu/) is developing a library of parallel program archetypes with the aim of reducing the effort required to produce correct and efficient parallel programs. A parallel program archetype is a program design strategy appropriate for a restricted class of problems. The design strategy includes the software architecture for the problem class, archetype-specific information about how to derive a program from its specification,methods of reasoning about correctness and performance, suggestions for test suites, and suggestions for performance tuning on different architectures. An archetype identifies the common computational and communication structures of a class of problems and provides development methods specific to those structures. So far archetypes have been developed for mesh computations and for spectral methods. Archetypes are proposed as an alternative to reuse libraries. The Archetype Group argues that reuse libraries are inadequate for parallel programming because they are language and run-time system specific and because of difficulties with parallel composition of library procedures. Our approach has been to develop portable subroutine libraries in Fortran,which is the predominant programming languagefor scientific computing, and to isolate the applications programmer from the details of the parallel implementation. The High Performance C++ (HPC++) project is attempting to extend industry stand ard object oriented software ideas to the world of massively parallel computing (http://www.extreme.indiana.edu/hpc++/index.html). Parallel extensionsto the C ++ programming language include pC++, a data parallel programming language that combines HPF style programming with object oriented techniques, and CC++, a task parallel extension to C++ suited to both distributed and parallel applications. The HPC++ project is also working to extend the Object Management Group's CORBA and IDL specifications to support application servers running on massively parallel computers. Such extensions will support language interoperability between C++ based parallel programming systems and MPI implementations. Work on parallel object oriented programming languages complements our work on data parallel problem architectures and on high performance linear algebralibraries. We have developed LAPACK++, an object-oriented C++ extension of LAPACK (http://www.netlib.org/c++/lapack++). The object oriented approach provides an extensible framework for incorporating extensions of LAPACK, such as ScaLAPACK++ for distributed memory architectures. Researchers at Rice University are developing the D System,which is a set of tools for machine-independent data parallel programming (http://www.cs.rice.edu/fortran-tools/DSystem/DSystem.html) [9]. The tools support development of programs in Fortran D, an abstract, machine-independent parallel programming language. The D System editor allows theprogrammer to interactively parallelize existing Fortran code, and the data mapping assistant helps the programmer choose good decompositions for data structures. Because data parallel compilers perform aggressive program transformations, the relationship between the source program and ob ject program may be difficult for the programmer to understand. Thus,the D System debugging and performance analysis tools support analysis in terms of the source program. Fortran D is a predecessor to HPF, and features of the D System are expected to carry over to environments for HPF and other data parallel languages.We speculate that the D System might be extended to support our problem classification scheme andto partially automate selection and use of linear algebra components. References [1]G. Fox,R. Williams, and P. Messina, Parallel Computing Works. Morgan Kaufmann, 1994. Accessible on-line at http://www.infomall.org/npac/pcw/. [2]"High Performance Fortran language specification, version 1.1," Tech. Rep. CRPC-TR92225, High Performance Fortran Forum,Nov. 1994. Available at http://softlib.rice.edu/CRPC/softlib/TRs_online.html. [3]K. Dincer, K. Hawick, A. Choudhary, and G. Fox, "High Performance Fortran and possible extensions to support conjugate gradient algorithms," Tech. Rep. SCCS-703, Northeast Parallel Architectures Center, Syracuse University. Available at http://www.npac.syr.edu/techreports/. [4]Z. Bozkus, A. Choudhary, G. Fox, T. Haupt, and S. Ranka, "CompilingHPF for distributed memory MIMD computers," Tech. Rep. SCCS-507, Northeast Parallel Architectures Center, Syracuse University. Available at http://www.npac.syr.edu/techreports/. [5]J. Dongarra, S. Otto, M. Snir, and D. Walker, "An introduction to the MPI stan-dard," Tech. Rep. UT-CS-95-274, University of Tennessee, Jan. 1995. Available at http://www.netlib.org/tennessee/. [6]J. Dongarra and D. Walker, "Software libraries for linear algebra computation on high-performance computers," Tech. Rep. ORNL-TM- 12404, Oak Ridge National Laboratory, Aug. 1993. Available at http://www.netlib.org/tennessee/. [7]J. Choi, J. Demmel, I. Dhillon, J. D. S. Ostrouchov, A. Petitet, K. Stanley, D. Walker, and R. C. Whaley, "ScaLAPACK: a portable linear algebra library for distributed memory computers," Tech. Rep. UT-CS-95- 283, University of Tennessee, Mar.1995. Available at http://www.netlib.org/tennessee/. [8]S. Browne, J. Dongarra, K. Kennedy, and T. Rowan, "Management of the NHSE - a virtual, distributed digital library," in Digital Libraries '95, (Austin, Texas), June 1995. Also available as University of Tennessee Technical Report UT-CS-95-287 at http://www.netlib.org/tennessee. [9]V. Adve, A. Carle, E. Granston, S. Hiranandani, K. Kennedy, C. Koelbel, U. Kremer, J. Mellor-Crummey, C.W. Tseng, and S. Warren, "Requirements for data-parallel programming environments,"IEEE Transactions on Parallel and DistributedTechnology, vol. 2, pp. 48-58, Fall 1994. Also available at http://softlib.rice.edu/CRPC/softlib/TRs_online.html as CRPC-TR944378-S. 4 Biographies Shirley Browne is a Research Associate and Adjunct Professor in the Computer Science Department at the University of Tennessee, where she is a member ofthe Netlib Development Group. Her research interests are in replicated database issues for a scalable information infrastructure and in information system support for software reuse. She received a Ph.D. in Computer Sciences from Purdue University in 1990. Jack Dongarra holds a joint appointment as Distinguished Professor of Computer Science in the Computer Science Department at the University of Tennessee (UT) and as Distinguished Scientist in the Mathematical Sciences Section at Oak Ridge National Laboratory (ORNL) under the UT/ORNL Science Alliance Program. He specializes in numerical algorithms in linear algebra, parallel computing, use of advanced- computer architectures, programming methodology, and tools for parallel computers. Other current research involves the development,testing and documentation of high quality mathematical software. He was involved in the design and implementation of the software packages EISPACK, LINPACK, the BLAS, LAPACK, ScaLAPACK, Netlib/XNetlib, PVM/HeNCE, MPI andthe National High-Performance Software Exchange,and is currently involved in the design of algorithms and techniques for high performance computer architectures. He received a Ph.D. in Applied Mathematicsfrom the University of New Mexico in 1980. Geoffrey Fox is an internationally recognized expert in the use of parallel architectures and the development of concurrent algorithms. He leads a major pro ject to develop prototype high performance Fortran (Fortran90D) compilers. He is also a leading proponent for the development of computational science as an academic discipline and a scientific method. His research on parallel computing has focused on development anduse of this technology to solve large scale computational problems. Fox directs InfoMall,which is focused on accelerating the introduction of high speed communications and parallel computing into New York State industry and developing the corresponding software and systems industry. Much of this activity is centered on NYNETwith ISDN and ATM connectivity throughout the state including schools where Fox is leading developments of new K-12 applications that exploit modern technology. Fox is currently a Professor of Computer Science and Physics at Syracuse University and director of NPAC, The Northeast Parallel Architectures Center.He obtained his PhD from Cambridge, England and spent 20 years at Caltech where he was Professor and Associate Provost for educational and academic computing. Ken Hawick is a research scientist at the Northeast Parallel Architectures Center (NPAC) at Syracuse University,working in the areas of computational scienceand high performance computing, and in information technology for industry. He formerly headed the Numerical Simulations Group at the Edinburgh Parallel Computing Centre in Edinburgh, Scotland. Tom Rowan is a Collaborating Scientist in University of Tennessee's Computer Science Department and Oak Ridge National Laboratory's Mathematical Sciences Section. His primary research interests are in the areas of numerical analysis and mathematical software. Much ofhis research has focused on developing algorithms and software for automatic detection of instability in numerical algorithms and for optimization of noisy functions. He received his Ph.D. from the University of Texas at Austin in 1990. A Program Editor to Promote Reuse Paolo Bucci Department of Computer and Information Science The Ohio State University 2015 Neil Avenue Columbus, OH 43210 Tel: (614)292-1152 Email: bucci@cis.ohio-state.edu Abstract A software engineer's mental model of software is influenced by many factors, including the application, the programming language, and even the programming environment. In particular, all programmers have to interact with a program editor, i.e., a tool to enter, modify, and view programs. This tool plays a role in shaping the way programmers think of software and of the software development process. In this position paper we explore the impact of the program editor on the programmer's view of software, and in particular those aspects thathave direct relevance for safe and successful software reuse. Keywords: Programming environment, software reuse, software education, reuse education Workshop Goals: Learning, networking Working Groups: Design guidelines for reuse, tools and environments,education 1 Background For the past decade,the Reusable Software Research Group (RSRG) at the Ohio State University has been exploring various aspects of software reuse, and in particular a component-based reuse technology for software engineering. This has resulted in the RESOLVEframework, language and discipline for component engineering [1]. Several of the ideas developed by the group have found their way into software courses at OSU and elsewhere. Efforts are under way to redesign and restructure the OSUsoftware curriculum to reflect the need for a software education aimed at a modern integrated component-based view of software engineering. The success of this new approach will depend in part on the availability of appropriate tools to assist the programmer in the development and composition of software systems. This position paper describes some of the issues involved in the design of a program editor that will be able not only to support, but also to promote a disciplined, organized view of software that emphasizes good "component engineering" habits. 2 Position Program editors usually are seen by programmers as simple, somewhat unsophisticated tools that do not (and are not expected to) provide assistance beyond the features of, say, a text editor. In part, this is due to the fact that most programmers form, from the beginning, a mental model of software as plain text. They learn to program with text editors that give them complete freedom and usually little guidance during the processof program development, and they never consider how much more an editor could and should provide. In this paper, however, we take the position that a carefully designed program editor could be quite sophisticated in providing assistance tothe programmer. This would free programmers from uninteresting (but essential) concerns, while appropriately guiding them towards better programming practices and productive software reuse. As discussed in the next sections,there are many ways in which a program editor could support software reuse. It is important to realize, however, that for the editor to have a real impact on software reuse,and essentially on the way programmers think,it is necessary for the editor to be designed with this goal in mind. Furthermore, experience with other programming environments, such as structure editors and syntax- directed editors, suggests that such an editor would be more likely to succeed in its goals and to be accepted by programmers if it were used from the beginning in the training of software engineers. This is before programmers have the opportunity to form in appropriate mental models and before they learn unsafe programming habits. A well- designed editor that truly promotes software reuse and that supports safe, disciplined programming practices could also be useful in helping experienced programmers make the transition from old habits to more modern approaches to software engineering and software reuse. Throughout this paper we will refer to a program editor (or simply an editor) as the tool used to enter,modify, and view programs. 2.1 The editor should provide a consistent, high-level view of software Program editors provide the programmer with a view of what software is and how it can be manipulated. This view contributes to themental model of software that the programmer forms while editing. The mental model that the editor projects depends essentially on two things: the representation used to display software components, and the kinds of operations the editor provides to the user to manipulate, modify, and combine components. For example, a text editor that displays programs as simple text,and that provides only text-editing operations, promotes a model of software as plain text with no other structure or abstraction. Programmers are affected by themo del of software presented by the editor. When interacting with the editor,their thinking is inevitably biased towards the structures they are editing and the transformations that are allowed by the editor. If software systems are to be constructed by explicitly combining reusable components [2], the editor must not only allow the editing of components, but also their retrieval and composition, and this in as uniform and consistent away as possible. It has to make sure that components can be reused based on their abstract specifications and without the need to know the details of their implementation. It must also ensure that components are reused only where appropriate. In other words, the editor needs to actively promote a component view of software,as opposed to a text view of software, and it has to allow only safe operations on components. For the above goals to be achievable, the editor needs to present a higher- level model of software than the currently available editors such as text editors or syntax-directed, structure editors. It is essential that the representation be abstract, and that the operations allowed operate at a conceptual (and not just syntactic) level, so the programmer can clearly see what each entity in the program does, and can think in terms ofabstract concepts instead of syntactic units, or just sequences of characters. 2.2 The editor should promote (even enforce) a good programming discipline It has been recognized that programming for reuse and with reuse requires a disciplined approach on the part of software engineers [3]. Clearly,we want to allow programmers to think about conceptual problems rather than spending time worrying about those aspects of principles and guidelines that can be enforced by the editor (not to mention syntax and other statically checkable properties of software). The editor can be seen as a tool to guide software engineers through the hard task of writing programs by ruthlessly pruning the space of all possible programs, eliminating those that do not satisfy certain rules or that do not obey certain disciplines. In this way, the editor allows only syntactically and static semantically correct programs. But more importantly,it supports the user in the application of appropriate programming disciplines. Especially during the training stage,an editor that enforces a good programming discipline can be an invaluable tool in teaching appropriate programming habits, from the beginning. Existing editors vary in the amount of freedom (or lack of guidance) they give to the programmer: from text editors that have no restrictions (leaving the burden completely on the programmer),to syntax-directed editors that enforce syntactic correctness of the program and possibly include some static semantic checking.In any case, most such editors do notconsider the possibility of helping users follow safe programming disciplines. 2.3 The editor should support safe reuse techniques and prevent unsafe ones As an example of an "unsafe" (though commonly used) reuse technique, consider source code scavenging. In most cases, programmers copy a fragment of code and then proceed to modify the copy to make it fit the new context and new purpose. This process is the source of many subtle and not-so-subtle mistakes,due to lack of a full understanding of the code being copied and of the differences in the contexts of the original code and the copy. The idea of copying and pasting arbitrary segments of source code is clearly encouraged by text editors and the text mental model. However, commonly used editors do not provide any support or guidance to assist programmers in the safe application of this form of reuse. Part of the problem is the fact that code scavenging is based on copying a code fragment whenever its (textual) representation is similar to the (textual) representation of the code that has to be written. Given this, it is almost impossible to conceive of any assistance the editor might provide. On the other hand, if the editor provides a higher-level view of code, and if it promotes source code reuse of similar conceptual units (as opposed to syntactic units that only share similar representations), then it can attach to the copied unit all the context information necessary to give it a meaning,and this information can be used by the editor to guide the programmer in adapting it to the new context. In this way,unsafe scavenging of text fragments can be prevented, while the safer, editor- assisted reuse of conceptual units can be supported. 3 Comparison Program editors have been an active area of research for over 30 years,so there is an extensive body of literature on the subject,with many different approaches and points of view. There is an ongoing debate between advocates of text editors and supporters of syntax-directed, structure editors. The common observation is that experienced programmers are comfortable with text editing capabilities, and are not willing to accept the restrictions imposed by structure editors; while novices find the help and guidance provided by structure editors helpful [4, 5]. Still others support editors that combine the characteristics of both text and structure editors [6, 7]. Our claim here is that both text and parse trees are inadequate models of software for effective support of reuse; specifically, text and parse trees are too low level. Other researchers [5, 8] have recognized the importance of the programmer's mental model of software for the success of a syntax- directed editor. Theyhave speculated that the obvious lack of popularity of existing syntax-directed,structure editing environments among experienced programmers is due to poor design of editors, particularly their user interface and the view of software that is promoted. Some researchers [9] have advocated using structure editors to reinforce concepts of good programming methodology in novice programming courses. However, noone seems to have taken the more pro-active position that program editors have the potential to help shape the way programmers learn to think about software and about how it is developed. Hence,researchers typically advocate designing editors to satisfy the demands ofto day's programmers, e.g., supporting text editing features. Otherwise,experienced programmers will not use them. In contrast,our view is that editors should be designed with the goal of assisting,and even leading, programmers in the process of program development. We believe that such editors could promote software reuse and contribute positively to training in reuse. References [1]M. Sitaraman and B. W. Weide, eds., "Special Feature: Component- Based Software Using RESOLVE," ACM SIGSOFT Software Engineering Notes, vol. 19, pp. 21-67, Oct. 1 994. [2]B. W. Weide,W. F. Ogden, and S. H. Zweben, "Reusable software components," in Advances in Computers (M. C. Yovits, ed.), vol. 33, Academic Press, 1991. [3]J.Hollingsworth, Software Component Design-for-Reuse: A Language Independent Discipline Applied to Ada. PhD thesis, Dept. ofComputer and Information Science, The Ohio State University, Columbus, OH, 1992. [4]S. Dart, R. Ellison, P. Feiler, and A. Habermann, "Software Development Environments," Computer, vol. 20, pp. 18-28, Nov. 1987. [5]S. Min|r,"Interacting with Structure-Oriented Editors,"International Journal of Man-Machine Studies, vol. 37, pp. 399-418, Oct. 1992. [6]R. Waters,"Program Editors Should Not Abandon Text Oriented Commands,"ACM SIGPLAN Notices, vol.17, pp. 39-46, July 1982. [7]R. Bahlke and G. Snelting, "Design and Structure of a Semantic-Based Programming Environment," International Journal of Man-Machine Studies, vol. 37, pp. 467-479, Oct. 1992. [8]J. Welsh and M. Toleman, "Conceptual Issues in Language-Based Editor Design," International Journal of Man-Machine Studies, vol. 37, pp. 419-430, Oct. 1992. [9]D. Garlan and P. Miller, "GNOME: An Introductory Programming Environment Based on a Family of Structured Editors," ACM SIGPLAN Notices, vol. 19, pp. 65-72, May 1984. Proceedings of the ACM SIGSOFT/SIGPLAN Software Engineering Symposium on Practical Software Development Environments. Biography Paolo Bucci is a doctoral student in the Department of Computer and Information Science at The Ohio State University. He received his undergraduate degree in computer science from Universita degli Studi, Milan, Italy in 1986,and his M.S. in computer science from Ohio State in 1989. His current research interests include software design and reuse,programming environments, programming languages, and education. Mr. Bucci gratefully acknowledges financial support from the National Science Foundation (grant number CCR-9311702) and the Advanced Research Projects Agency (contract number F30602-93-C-0243, monitored by the USAF Materiel Command, Rome Laboratories, ARPA order number A714). Design Deltas in Reusable Object-Oriented Design Greg Butler Centre Interuniversitaire en Calcul Mathematique Algebrique Department of Computer Science Concordia University Montreal, Quebec, H3G 1M8 Canada Tel: (514)848-3031 Tel: (514)848-3000 Fax: (514) 848-2830 Email:gregb@cs.concordia.ca with Peter Grogono, Li Li, Ra jjan Shinghal, Ono Tjandra Department of Computer Science Concordia University Montreal, Quebec, H3G 1M8 Canada Abstract Reusable object-oriented design aims to describe and classify designs and design fragments so that designers may learn from other peoples' experience. Thus, it provides leverage for the design process. The field includes software architectures, application frameworks, design patterns, and the design of class libraries. The field is young with many open problems that still need to be researched. This position paper opens a discussion on "design deltas" to describe increments of change in designs that arise in software evolution,between versions of software,and in adaptation during white-box reuse. Keywords: Reuse, design, framework, design pattern, architecture, formal methods Workshop Goals: Learning; networking; clarifying "design deltas"; Working Groups:reuse of designs, reuse and OOmethods, formal methods, design guidelines for reuse _ C++ 1 Background My background in computer algebra systems is described in my WISR6 position paper [1]. These experiences convinced me that a more flexible environment, using a single language, C++, is needed to research the issues of software architectures and their integration for computer algebra systems. Also, there is a greatneed from researchers in algebraic algorithms for a software library. Since moving to Concordia University at the end of 1991, my research has focussed on C++ libraries and frameworks, issues of reuse, and issues of reliability (which includes correctness). In the past two years I have been actively leading a discussion group at Concordia on C++ programming and object-oriented design. These have recently split into two discussion groups, the latter concentrating on design patterns. Ialso teach a course on object-oriented design based on OMT [14] that also includes material on reuse. On the research side there is ongoing work on application frameworks for combinatorial enumeration [6] and deductive databases [2] are in preliminary stage of construction with the help of students: we are still learning how to develop and document frameworks - much more practical implementation needs to be done; use of design patterns for development and documenting software (especially frameworks) is the focus of several student projects, and the discussion group on object-oriented design; survey of reusable object-oriented designlooked at reuse of design artifacts: how they were developed, how they were reused, and how they were described/documented/specified and classified [7]; trends in software engineering for which there was documented empirical evidence for their cost benefits were surveyed [3]: this included improvements in process quality and product quality, software reuse at the level of code component, frameworks, and application generators, and the use of formal methods and other modeling notations; document understanding for reverse engineering was investigated with colleagues[5, 4] to consider whether reverse engineering of legacy systems could benefit from knowledge extracted automatically from paper documents: we are concentrating on data flow diagrams. In recognition of the importance of software evolution, at the WISR7 workshop I wish to focus onhow to describe design increments and clarify the notion of what is a "design delta". 2 Position The conclusions from [7] contain my position on research directions in reusable object-oriented design: " One clear conclusion is that reusable design artifacts are the result of evolution and iteration. This is especially true for application frameworks and class libraries - the concrete artifacts, where all details must be spelt out. " Another clear conclusion is that models and notations play several important roles. The abstract artifacts are themselves models, but even for them the role of models and notations extends much further. Models and notations are an aid to communication. Models and notations improve understanding through precision, conciseness, and visual cues. A model or documentation template often providesa checklist of the information needed to fully understand or reuse a design artifact. For example, these may include: - responsibilities of each participant; - collaborations amongst participants; - purpose of the artifact; and - preconditions for applicability. " There are many open problems for architectures, frameworks, micro- architectures, and, to a lesser degree,for the design of class libraries. We have broadly categorized these into problems of retrieval, understanding, and evaluation. " Retrieval problems are those related to the classification and description of design artifacts,as well as the problem of enlarging our catalogue of known reusable design artifacts. " Each of the following is aimed towards enlarging and organizing our knowledge of design artifacts. This provides a base from which to retrieve design artifacts and also provides a conceptual classification scheme that forms the basis of the attributes mentioned in retrieval queries. Although we have seen examples of work on each of these areas in this survey,there is much more that needs to be done still. A taxonomy of design artifacts provides a map of the space of artifacts, their commonality and their differences. This organizes our knowledge,helps designers to appreciate the breadth of choices and trade-offs, and may guide the discovery or invention of new artifacts,and assist the development of design notations and languages. Classification of individual artifacts according to their significant or distinguishing features aids our understanding of that individual artifact and contributes to the development of the taxonomy. Cataloguing the existing design artifacts requires assistance from industry to release details of the design of their systems. Our understanding of software architectures and application frameworks depends heavily on enlarging the base of examples in the catalogue, particular to assist the development of a taxonomy. The invention and discovery of new designs is also a part of this open problem. " Understanding problems are those related to reducing the effort by a reuser to understand a design artifact and to understand how to reuse a design artifact. Documentation styles and standards are required to ensure that all information needed by reusers is documented, and to present the information to reusers in a timely fashion: that is, precisely when they need it. The spiral approach of patterns tailors the timing and volume of information that a reuser of a framework is presented with. The documentation templates for design patterns ensures that each item of necessary information is provided, and that examples of use are also included. Documentation of architectures and class libraries is still in need of good styles and standards. Formal specification and description of design artifacts claim to provide improved precision, conciseness, and reasoning. Each of which may improve understanding. Most of the work on the description of design artifacts has been done by practitioners who do not share a belief in the merit of formal specifications: they used natural language and diagrams for their documentation. As a consequence there is only a small body of work on how to formally specify design artifacts. There is scope for further work in this area. Experimental validation of claims that certain do cumentation or specification styles do improve understanding in practice is required. All asp ects of research into software development need a firm experimental foundation. " Evaluation problems include thoseof comparing design artifacts, those concerned with the evolution of artifacts, and the problems of evaluating design artifacts. Metrics for design artifacts are in very short supply. The correlation between metrics and the desirable qualities of a design also needs to be established quantitatively. The metrics research community is large and active so we predict that a stream of new design metrics will be forthcoming. There is also a strong interest from practitioners who are establishing quality assurance programmes and are collecting the necessary data to confirm any correlation between measurement and quality. Specifying and describing the evolution of a design and the differences between designs may require a notion of a "design delta" to capture the increment of change or difference. Alternatively, evolution could be viewed transformationally,and the increment would be a description of the transformation. Ralph Johnson and his students call these transformations "refactorings". Given the importance of evolution, refinement,and iteration to design and reuse, this is a major open problem for reusable object-oriented design. " It is this last point: the importance of the notion of a "design delta" for describing the evolution of a design (just as a source code delta is used in software configuration management [16] to describe the differences between versions of code) that I think deserves more study at WISR7. 3 Comparison The notion of a "design delta" is related tomany existing concepts. Each of which might help us clarify a precise definition of the notion. Refactoring describes a reorganisation of the class hierarchy for an object- oriented system [8] as a means of identifying reusable classes or frameworks. Johnson and Opdyke [12, 11] have catalogued several refactorings as transformations on the class hierarchy. Programming-by-difference constructs a design increment by specialisation of asuperclass. So the equation design = subclass n superclass or one can view the subclass definition alone as the "design delta". Mixins are a purer form of programming-by-difference. A mixin is a design increment. Adaptation in software reuse allows controlled change via instantiation or specialisation,and allows uncontrolled editing of source code: perhaps editing to produce a "design delta" provides controlled white-box reuse which lies between these two extremes. Increments in Cleanroom software development are documented in a construction plan that divides the system development into vertical increments instead of the traditional horizontal breakdown into subsystems. Each vertical increment describes a working system,though with a subset of the behavior, and should correspond to a part of the top-level black box and a part of the usage model and usage profile [9]. Change management inthe PRISM software process model [10] documents changes in staff, policies, laws, processes or systems on sheets that record dependency, resource, and status information. Design steps are the actions taken during design in response to the identification of issues and their resolution via arguments for and against in the model of Potts and Bruns [13]. Design increments are implicit in the model as paths (sequences of arcs) relating two design artifacts. Re-engineering in the most simple case at the design level involves two designs D and D0 for a common specification S, so although the designs differ (by a design delta) there is a context which is invariant: the specification of their observable behaviour. Transformational software development maps a specification S to a design (and eventually to an implementation) D via a sequence of transformations f which are guaranteed to preserve semantic correctness. A change in specification to S0 leads to a new design D0. It would be convenient if a design increment D0 n D was f(S0 n S), however there are two obstacles: The change in specification may require a change in the choice of transformations; and, even if that does not occur, we would require the incrementof change in the specification to itself be a specification (of something meaningful) in order to apply f. Composition operators such as in Z schema calculus [15] can describe increments of change in specifications as specifications. It is common Z practice to separate the specification of typical behaviour (the AddBirthday schema) from error-handling described in terms of successful execution (the Success schema) and error-type (the AlreadyKnown schema). RobustAddBirthdayb=(AddB irthday^ Success) _ AlreadyKnown: References [1]G.Butler, Reusable reliable software components for computer algebra. Position paper for the 6th AnnualWorkshop on Software Reuse to be held in Owego, November 2-4, 1993. [2]G.Butler, Datalog and Two Groups and C++, to appear in Proceedings of the Second International Conference on Artificial Intelligence and Symbolic Mathematical Computing,Cambridge, UK, August 3-5, 1994. [3]G.Butler, Technical trends in industrial software engineering: Quality, reuse, modelling,submitted. [4]G. Butler, P. Grogono, R. Shinghal, I.A. Tjandra, Analyzing the logical structure of data flow diagrams in software documents, to appear in Proceedings of Third International Conference on Document Analysis and Recognition, Montreal, Canada, August 14-16, 1995. [5]G. Butler, P. Grogono, R. Shinghal, I.A. Tjandra, Knowledge and the recognition and understanding of software documents, submitted. [6]G. Butler and C.W.H. Lam, The preliminary design of an object- oriented framework for combinatorialenumeration, to appear in proceedings of the Colloquium on Object Orientation in Databases and Software Engineering, 62nd Congress of ACFAS, May 16-17, 1994, Montreal. [7]G. Butler, L. Li and I.A. Tjandra, Reusable object-oriented design,submitted. [8]R.E. Johnson and B. Foote, Designing reusable classes, Journal of Object-Oriented Programming 1 (1988) 22-35. [9]Even-AndreKarlsson, Reuse and cleanroom, 1st European Industrial Symposium on Clean-room Software Engineering, 26-27 October, 1993, Copenhagen. [10]N.H.Madhavji,Environment evolution: The PRISMmodel of changes, IEEE Trans. Software Eng. 18, 5 (May 1992) 380-392. [11]William F. Opdyke, Refactoring Object-Oriented Frameworks, Ph.D. Thesis, University of Illinois at Urbana-Champaign, 1992. [12]W.F. Opdyke adR.E. Johnson, Refactoring: An aid in designing application frameworks and evolving object-oriented systems, Proceedingsof the Symposium on Object-Oriented Program-ming Emphasizing Practical Applications (SOPPA), September 1990. [13]C. Potts and G. Bruns, Recording the reasons for design decisions, Proceedings of the 10th International Conference on Software Engineering, IEEE Computer Society Press, Los Alamitos, CA, 1988, pp. 418-427. [14]J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorenson, Object- Oriented Modelling and Design, Prentice Hall, 1991. [15]J.M. Spivey, The Z Notation: A Reference Manual, Prentice Hall,1992. [16]Walter F. Tichy, RCS - A system for version control, July 1985, 19 pages. 4 Biography Gregory Butler is Associate Professor in Computer Science and a member of Centre Interuniversitaire en Calcul Mathematique Algebrique (CICMA)at Concordia University, Montreal,Canada. His research interests are reusable object-oriented design, software architectures, C++ libraries and frameworks for computer algebra systems which integrate knowledge-based facilities. He obtained his PhD from the University of Sydney in 1980 for work on computational group theory. He spent 1976/77 at ETH, Zurich as part of his doctoral studies, and for two years, 1979-1981, was a postdoctoral fellow at McGill and Concordia Universities in Montreal. He was on the faculty of the Department of Computer Science at the University of Sydney from 1981 to 1990. He has held visiting positions at the University of Delaware and Universitat Bayreuth. Evolutionary Metrics Adoption Method for Reuse Adoption Patricia Collins & Barbara Zimmer Hewlett Packard Software Initiative 1501 Page Mill Road, Bldg. 5M Palo Alto, CA 94303 Tel: (415) 857-2681, 857-4894 Email: collins@ce.hp.com, zimmer@ce.hp.com Abstract Adoption of reuse metrics using an evolutionary approach is well matched to organizational readiness for metrics in managing reuse adoption.. In Hewlett-Packard, groups are using an evolutionary development and delivery lifecycle [4] to manage reuse risks and to address the very real limits in an organization's ability to adapt to changes. We have developed a method for reuse metrics adoption that reflects this evolutionary approach. The metrics identification method is a refinement of Basili's Goal-Question-Metric paradigm.[1] We have extended the Goal Statement activity to include explicit alignment of reuse goals with business goals. The questions and metrics identification are highly focused. The focus is guided by the desire to manage the risk of the reuse adoption and the limits of the organization in adopting metrics; therefore, those questions and metrics most likely to aid the organization in managing their reuse risks are identified and adopted first. In reuse adoption and institutionalization, cultural and organizational issues can determine the success of the effort. For that reason, reuse metrics can play a particularly important role in communications for building and reinforcing partnerships, assessing and ensuring customer satisfaction, communicating value, and monitoring impact and progress. Keywords: software metrics, reuse metrics, reuse management, GQM paradigm, metrics implementation, evolutionary lifecycle Workshop Goals: Exchange learnings in incremental reuse adoption, including adoption models and methods, the role of metrics and alternative means of managing reuse. Working Groups: Patricia: 1. Reuse process models 2. Domain analysis/engineering 3. Reuse and OO methods and technology Barbara: 1. Reuse management, organization and economics 2. Reuse maturity models 3. Useful and collectible metrics 1 Background In the HP Software Initiative, Patricia Collins served initially as a reuse process improvement consultant, pioneering the use of domain analysis and utilizers' needs analysis methods within HP. While she is still considered a corporate resource for reuse process knowledge, she now also partners with R&D groups to develop roadmaps, plans, and implementations for reuse adoption and institutionalization that address reuse processes and methods, process improvement adoption methods (including change management), reuse metrics, reusable architecture and design methods, and organization redesign. Barbara Zimmer has been working in partnership with several HP R&D groups to plan and implement software metrics programs in reuse organizations. She has written an extensive review of software reuse activities in HP that has been used as a valued reference by HP groups exploring software reuse. 2 Position For the past five years, organizations in Hewlett-Packard have been moving from leverage of software between successive products to systematic reuse of software among products being developed in very close succession, or even in parallel. The need for reuse is not in question, since there are few proposed alternatives for achieving the diverse business goals of these organizations. Typically, the move from leverage to systematic reuse is motivated by a need for higher productivity, decreased time-to-market, increased rate of innovation, and/or limited resources. This paper describes a few of our specific innovations in software metrics adoption methods. The HP Software Initiative's Evolutionary Reuse Metrics Adoption (ERMA) Method refines the work of others in goal, question, and metrics (GQM) identification and implementation, as well as the management of this change (metrics adoption) in the organization. This paper focuses on innovations in the identification and implementation parts of the method. Traditionally, the GQM method has involved full enumeration of goals, then questions whose answers can help evaluate progress toward the goals, and then metrics that can be used to answer the questions. Organizations new to using metrics to manage reuse adoption are easily overwhelmed by this exhaustive method. This can result in lost momentum for metrics adoption or circumventing the GQM process entirely in favor of metrics that may contribute nothing to managing toward their critical goals. The ERMA method keeps the GQM process highly focused on delivering metrics that provide information needed to manage progress toward critical goals. The innovations of ERMA are: - Explicitly state the goals as well-formed, strategic objectives - Identify which objectives require metrics support for progress toward that objective to be managed. Include reasons metrics are critical for each goal selected. - Identify 1 or 2 key assessment questions for the objective(s). The assessment questions are well formed (i.e., they align with the well-formed objective, and the answer to the question enables the organization to assess progress toward the objective). - Identify criteria for what metrics will be used (e.g. organization's readiness, collectibility). - Identify 1 or 2 metrics for the question(s) deemed to be most critical for managing reuse adoption. The essence of our contribution is thus a pruning of the GQM expansion process, the support for distinguishing between assessment and understanding questions, and evolutionary identification and implementation appropriate to incremental reuse adoption. In practice, we contribute significantly by facilitating the development of well-formed objectives, an essential first step in the GQM process. We describe these innovations through representative examples from our experiences in reuse metrics adoption. 2.1 Goal Clarification Establishing reuse goals that are aligned with business goals is a new activity for HP engineering organizations. In one organization that was exploring the potential for designing and developing a reusable measurement platform, the first step was to conduct a domain analysis (DA), which included the explicit delineation of DA goals. We developed and delivered a domain analysis workshop that first focused on the overall business goals, then aligning the reuse goals with those business goals, and finally aligning the domain analysis goals with the reuse and business goals . The workshop participants represented four related, but traditionally independent product line organizations which develop and manufacture test equipment. In order to understand what approach (e.g., reuse) might adequately support a business goal, we interviewed stakeholders in each organization who understood business and market trends, current practices, internal and external constraints, and what was possible to achieve. The interviews allowed us to assure the business goal statements were aligned with the intentions of the organizations. For example, one organizationÕs breakthrough goal was to shorten the time-to-profit for the customer. We explored how HP products could impact time-to-market in the customerÕs R&D use of the equipment, and how they could impact time-to-profit in the customerÕs manufacturing use of the equipment. We then brainstormed how reuse could be focused to support this manufacturing customer, and developed sample reuse requirements (e.g., ÒThe test equipment domain architecture must support optimized throughput in the customerÕs manufacturing use of the equipment.Ó). Throughout this analysis, we developed, in parallel, product development and reuse objectives; appropriate targeted utilizers for the reusable assets; implications for product capabilities and marketing; and assessed the appropriateness of our objectives against constraints. In the domain analysis workshop, we explicitly asked each of the stakeholders to identify the product line business goals to which their reuse initiative would contribute. The responses included decreased time-to-profit, decreased time-to-market, and improved inter-product compatibility. Using the ERMA method, we asked the group to prioritize the business goals and explore options for which goals would be used to guide the domain analysis project, as well as the subsequent domain architecture and asset engineering projects. We stated the overall reuse goal and the specific domain analysis goals as a well-formed objectives: - The desired outcome is explicitly stated. - The attainment of the outcome is observable and assessable. - The statement is clearly written and readily understandable by all stakeholders. - The undertaking associated with achieving the objective is within the charter of the organization. - The desired outcome is aligned with the organization's business goals. - The time for achieving the outcome is explicit.1 Stating goals as well-formed objectives has been a very important and challenging task. Most organizations are not experienced in developing well-formed objectives. We have found that most teams need facilitation in eliciting a statement of the objective in terms of a desired outcome where progress toward that outcome will be assessable. As the next step in the ERMA method at the DA workshop, we established questions, and then metrics for this project using the ERMA method (discussed further in the following sections). At a management checkpoint for the domain analysis, the project's objectives were presented in the context of the business goals and the progress was assessed using the metrics. This contributed significantly to the organization's ability to manage their continued investment in the DA effort. The use of project objectives aligned with business goals and focused metrics derived from well-formed objectives supported the team's efforts to communicate with their management teams from a business frame of reference. The project sponsors supported the reported results and recommendations. 2.2 GQM for Reuse Another organization was frustrated in managing their investments in reuse and their approach in communicating the value of their efforts in developing and delivering reusable assets. The organization is a large, central asset production and management group with teams for developing and evolving assets, as well as supporting distribution and integration of the assets in products. Because value is traditionally assessed in this organization by the success of the HP product in the marketplace, there were no metrics in place that would assess the value of an organization whose contribution to products was considered indirect. We began the reuse metrics adoption process by assisting the organization in developing well-formed objectives for each project and for the two departments in which these projects were being undertaken. At first, each project team produced a long list of desired outcomes because they were unaccustomed to prioritizing and pruning their list of responsibilities. We used the strategic business goals and overall organization objectives to prioritize and trim the list to a critical few objectives. Then the stakeholders learned to restate their desired outcomes as well-formed objectives. Using a synthesis of methods described by Basili and Grady, we brainstormed sets of questions the group could use to assess progress toward the objectives. We then identified two types of questions. Assessment questions directly inquire about progress toward the objective. Understanding questions assist the analyst in understanding terminology, concepts, and implications for the objective. The stakeholders learned to distinguish between assessment questions (e.g., ÒIs the time (in engineering-months) to design a productÕs software decreasing with increased use of the reusable framework?Ó) and understanding questions (e.g., ÒWhat do we mean by inter-product compatibility?Ó). 2.3 Evolutionary GQM When a sister organization approached metrics adoption, they were just beginning a reuse initiative. They were planning the project to develop and deliver a reusable architecture, then a steady stream of reusable frameworks scheduled to deliver value to product development teams with limited resources. With this group, we developed a set of goals and then pursued the critical few for which the stakeholders believed metrics might help them to manage better. Then we developed one or two critical questions for each goal for which management help was most needed. This evolutionary GQM approach is based on the same principles as a pruned search algorithm [3]. We establish a ÒcostÓ for pursuing a particular goal, question or metrics; and attempt to get the most return for implementing a particular metric. The team established criteria for pursuing one goal, question or metric over another. These criteria (in order of priority) included that they would pursue a path if 1. The organization has a strong need to manage progress toward the associated goal. 2. The information needed to manage progress is not currently available. 3. Having answers to the associated assessment question would significantly improve the organizationÕs ability to manage progress toward the goal. 4. The cost/benefit of implementing the metric is acceptable to the organization. Of the important business goals for which the reuse effort was a tactic the group identified three critical goals, for which metrics could contribute substantially to managing progress. Asking only one or two key questions about each goal led them to a small set of metrics that were feasible and would provide the data needed for analysis. Future phases of evolutionary metrics adoption will employ the same method to implement and utilize additional metrics. 3 Comparison Reed [5] has reported on a metrics effort at Digital Equipment Corporation which is similar in its goal and strategic planning orientation and in its emphasis on communication as a critical success factor to metrics adoption. They do not attribute critical importance to the cultural and organizational factors which we feel make an incremental approach to metrics adoption imperative at HP. Grady [2] has documented various metrics efforts within HP which used the GQM paradigm. This experience base has led us to a more "pruned'' approach to the GQM tree and to a greater emphasis on alignment with business goals. May and Zimmer [4] discuss the benefits of Evolutionary Product Development in managing the risks of software development. The method uses small incremental product releases or builds, frequent delivery of the product to users for feedback, and dynamic planning that can be modified in response to this feedback. Successful implementation of this model in many HP organizations has helped shaped the incremental approach we are using in reuse metrics. Basili's [1] Goal-Question-Metric model is the basis for our approach and has been widely applied with varying results. References [1] Basili, V. & Weiss, D.M. ÒA Methodology for Collecting Valid Software Engineering DataÓ, IEEE Trans. Software Engineering, Vol. SE-10, no. 3, November 1984, pp. 728-738 [2] Grady, B. Practical Software Metrics for Project Management and Process Improvement, Prentice-Hall, 1992. [3] Lowerre, B. Pruned Search in Speech Recognition, Ph.D. Dissertation, Carnegie-Melon University, 1994. [4] May, E. and Zimmer, B. Evolutionary Product Development at Hewlett-Packard, Hewlett-Packard, 1994. [5] Reed, J. ÒSoftware Metrics and Policy DeploymentÓ, Proceedings of the Applications of Software Measurement ConferenceÊ, 1994 Biography Patricia Collins has been at HP 15 years. She was a speech recognition researcher in HP Laboratories, then served as project manager for various software systems and software engineering environment research projects. She has been a reuse consultant in HP's Software Initiative for 4 years. She holds an MSEE from Stanford University and a BA in mathematics and philosophy from Dickinson College. Barbara Zimmer has been at HP 12 years. After 6 years as a financial/business analysis, she moved to R&D to work with the software process assessment group. The results of these assessments of SW development processes in HP R&D laboratories were instrumental in convincing HP management to launch the Software Initiative. Within the SWI, she has focused on technology transfer and communications activities, including a number of internal publications of various aspects of software development as well as a Software Quality and Productivity Guide. Her current work focuses on working directly with HP R&D group partners on various aspects of software development. She has a BA in Communications and MBA from the University of Washington. 1 The time limit may be stated as occurring before an event, but is often stated as being accomplished by a specific date or within a timeframe. Representing Domain Models Graphically Margaret (Maggie) J. Davis Boeing Defense & Space Group P.O. Box 3999, MS 87-37 Seattle, WA 98124-2499 Tel: (206)773-3980 Fax: (206) 773-4946 Email: mjdavis@plato.boeing.com Abstract Transitioning domain analysis to experienced systems and software engineers would be eased by the availability of automation supporting graphical modeling. Further,it would be even more useful if the domain modeling seemed to be an extension to the graphical modeling the engineers are already performing. Commercial support (ObjectMaker,PTech) does exist for customizing a graphical modeling tool but it is either relatively expensive to license or takes a considerable amount of additional code. The approach taken was to put together NASA's CLIPS and Motif in a prototype that would be suitable for experiments integrating domain analys is with different graphical modeling methods. Keywords: Reuse, Domain Analysis, Graphical Representation Workshop Goals: Learning; networking; gathering information on successful reuse technology transitions Working Groups: reuse process models; reuse technology transition; and management; reuse and OO methods and technology 1 Background Ms. Margaret (Maggie) J. Davis is the technical lead for reuse on the Boeing STARS project, which is sponsored by ARPA under USAF contract. Ms. Davis has served in a lead capacity on the Boeing STARSproject since its award in 1988. Maggie is also principal investigator for a Boeing internal research and development project promoting domain-specific reuse awareness within the company and experimenting with graphicalrepresentations of domain analysis models. World Wide Web technology is being used to promote reuse awareness by providing a forum for user questions as well as an information resource. Facilities of NASA's CLIPSexpert systems shell and Motif are being used to create a family of tools for graphical representation of domain models. This family will in turn be used as the base for domain graphical modeling trials by Boeing projects. 2 Position 2.1 Problem Description In my experience so far,transitioning of domain analysis concepts and techniques to experienced software or systems engineers proceeds more smoothly if the "process" already in use is augmented rather than replaced. These "processes" are sometimes collections of analysis and modeling techniques known to be useful in the particular application area of the team or sometimes are commercially-available end-to-end software development methodologies such as P+. Quite often these processes rely on graphical representations to communicate results and concepts to other team members, management, and customers. The learning curve for domain analysis can be less steep if a way can be found to augment a team's familiar graphical representations to include the necessary information for domain modeling.At a minimum, differentiating commonality from variability is required. If a team is already performing analyses closely related to semantic modeling, KAPTUR can be used. In the embedded software milieu of most of Boeing's business,this is not the case. More often, entity-relationship models, data flow, control flow, stimulus-response networks , or architectural structures are depicted. Some teams or groups have adopted (and adapted to their needs) object-oriented analysis methods such as Rumbaugh or Coad defines. Such groups are more open to domain analysis because they have been become familiar with the is-a concept. However,all these object-oriented analysis techniques promote unique graphical representations,no one of which seems to include depicting commonality versus variability explicitly. Of the graphical models that can be encountered, software architecture representations pose a particularly knotty problem. Unlike electronic design, there is no standard symbology nor even a few competing defacto standards. Worse, architecture graphical models are often created as diagrams using whatever drawing package was at hand. The semantics associated with each symbol shape can vary within the diagram or across a series of diagrams that make a complete model. As a technologist attempting to intro duce domain analysis and modeling concepts into a group or team's way of working, it would be extremely useful to have at one's fingertips a graphical modeling program that worked either on a Unixor a PC platform and that supported customization for different methods or techniques. This customization would address three areas: Symbol presentation characteristics, Data attributes associated with each symbol, Methodology semantics. 2.1.1 Symbol presentation characteristics The symbol presentation semantics cover visual characteristics assigned to each methodology concept to be depicted: shape such as rectangle, oval, diamonds, lines; style such as line thickness or fill; size such as height and width; whether a user-entered text string should be displayed with a symbol instance; whether a symbol instance can be resized by the user; and whether a symbol instance can be reshaped such as from a square to a rectangle. 2.1.2 Data attributes associated with each symbol To elevate the tool from a mere drawing package to supporting graphical modeling, it is necessary to have the ability to associate data attributes with each symbol instance. For instance, if a symbol represented an abstract data type, itwould be useful to associate with that symbol dynamic characteristics such as timing and sizing expressions that could be used in subsequent simulations predicting performance. Besides assigning a label for prompting the user for entry of a value for an attribute, it may also be useful to designate: whether the user must supply a value or not; what is the type of the attribute (text, integer, float, ...); a range of legal values; and a default value. 2.1.3 Methodology semantics Methodology semantics cover checking validity of data item values at instance creation or update, checking the validity of instance deletion, and a set of modeling characteristics that are manifested through user interaction with the tool.These user interaction semantics cover details such as: whether symbol instances can be parents of other diagrams; whether symbols can contain, overlap, or touch other symbols; and whether symbols must be connected to other symbols. 2.2 Approach Being Used Commercial tools (e.g., ObjectMaker, PTech) are available that support certain customization characteristics listed above. When licensed to permit customization, either their cost is high or customization is a long and involved process. Thus, the decision was made to bring together NASA's CLIPS with MOTIF/X Windows to create prototype suitable for experimentation with various graphical model representations. CLIPS is an embeddable expert system shell that provides an inference engine and an object language. Using CLIPS thus provides an opportunity to save individual models in files that can be subsequently manipulated or analyzed by other CLIPS applications. CLIPS is a lso available for Unix, MacIntosh, and PC platforms. MOTIF/X Windows may not have been the best choice - it was what was at hand. It does make it possible to provide the drawing and data entry capabilities familiar to software engineers. 2.3 Major lessons learned so far Motif programming is tedious. Implementing dialog boxes, menus, and buttons with Motif widgets is a fairly straightforward data definition task. There is a large amount of detail to keep consistent. GUI builders can help manage the detail. Neither GUI builders nor application definition languages provide any assistance in implementing the drawing area. Implementation of drawing, selection, sizing, shaping, andplacement of symbols requires copious amounts of code and knowledge of two-dimensional geometry. Customization takes copious amounts of data. For each symbol defined, it is necessary to provide 16 to 64 separate customization decisions. These decisions are coded into CLIPS objects and used by the tool framework to dynamically configure an instance of the tool family. To simplify the customization activity that a technologist would have to perform, a generator was constructedusing the KAMEL tool created under the Boeing STARS project. This application of KAMEL queries the technologist for the customization decisions for each symbol, queries the technologist for the customization decisions that involve more than one symbol (connection, containment, ...), and then generates from those decisions the symbol customizations as CLIPS objects.The KAMEL application took about 16 hours to construct where the majority of the work involved writing the generator function. The effort was worthwhile since it ensures all the keywords are correct and the methodology-unique data is consistently applied. The KAMEL application also made it easier to specify the customizations that cross symbols. All of these had been problems when customization files were hand crafted. Buy rather than build if at all reasonable. It has been an interesting learning experience to discover what it means to support data-driven customization of a graphical modeling tool frame-work. But, that effort has consumed more resource than was expected. 3 Biography Maggie Davis is Reuse Technology Area Lead for the Boeing STARSprogram, participating in joint STARS activities and leading the Boeing-specific reuse technology development. Maggie is also principal investigator on a Boeing internal research and development project promoting reuse and transitioning reuse technology. Other Boeing applied research projects Maggie has participated in include applying object-oriented and knowledge-based techniques to the problem of system integration testing, using graphical user interfaces to support timing and sizing analyses, and authoring a guidebook for the Air Force on software specification techniques. Prior to her Boeing career, Maggie worked as a scientific and systems programmer. Maggie holds a M.S. in Computer Science from the University of Delaware. Measuring the benefits of Software Reuse Prem Devanbu and Sakke Karstu Software and Systems Research Laboratory AT&T Bell Lab oratories Murray Hill, NJ 07974 USA Email: prem,karstu@research.att.com Abstract How much can be saved by using existing software components when developing software? With the increasing adoption of reuse methods and technologies,this question becomes critical. However, accounting for the actual cost savings due to reuse may be difficult. It would be desirable to measure the savings indirectly by analyzing the code for reuse of components. The central focus of our work is the development of some properties that (we believe) should hold of any reasonable measure of reuse benefit. We explore the relationship between several existing approaches to reuse measurement and these properties. We have developed an "expanded source" measure as an indirect measure for reuse benefit, and evaluate it theoretically, using our properties; we have also built tools to gatherour measures and the previously proposed ones, and done some preliminary empirical work using some public domain windowing software. Keywords: metrics, indirect, axioms Workshop Goals: Learning; networking. Working Groups:reuse process models, reuse education, application generators. 1 Background As reuse efforts mature,it is very important to demonstrate to management and funding agencies that reuse makes good business sense; to this end, it is necessary to have methods to gather and furnish clear financial evidence of the benefits of reuse in real projects. Thus, we need to define good metrics that capture these benefits. We can think of reuse benefit of a project or system, as being the normalized (percentage) financial gain due to reuse. This is an example of an external process attribute (see [1]),concerned with an external input (money) into the software development process. Unfortunately,the direct measurement of the actual financial impact of reuse in a system can be difficult. There are different types of reuse - reuse of specifications, of design, and code. Specification and design processes often have informal products (such as natural language documents) which can be quite incommensurate. Even in reuse of code, there are different modus operandi, from the primitive "cut, shred, and paste", to the formal, controlled language based approaches provided in languages such as C++. In any case, to determine cost savings, one may have to ask individual developers to estimate the financial benefit of the code that they reused. This information may be unreliable and inconsistent. There has been a body of work in the area that addresses this issue: a variety of methods for measuring the degree of reuse in a system have been proposed [2, 3, 4, 5, 6]. 2 Position Fortunately,one of the key approaches to reuse is the use of features such as functions and modules in modern programming languages. In this context, one can find evidence of (some kinds of) reuse directly in the code; thus, it may be possible to find an indirect measure of the benefits of software (code) reuse directly in the code. Measures derivable directly from the code are internal measures; this paper, then, is concerned with the problem of finding an indirect, internal measure, in the code of a system, of an external process attribute, namely, reuse benefit. Following Weyuker [7] in the field of complexity measures, we develop some general properties or axioms that (we argue) should apply to any measure of reuse benefit. Although (for reasons discussed above) it is difficult to develop a direct, external measure of reuse benefit, these axioms give us a yardstick to evaluate candidate internal measures. Fenton [1] categorizes software measures along two orthogonal axes. The first is the process/product axis: a metric may measure an attribute of software product, (e.g., quality of code), or an attribute of software process (e.g., cost of design review meetings). Another, orthogonal axis is the internal/external axis. A metric may measure an internal attribute (e.g., the number of loops in a module), or an external attribute (e.g., maintainability of a module). Our goal is to develop a reasonable way of measuring the actual financial impact of reusing software. By Fenton's categorization, this is an external process attribute. We would like to measure reuse benefit as a normalized (we shall explain later why we choose to normalize) measure of the degree of cost savings achieved by adopting software reuse. Thus, we define Rb, the reuse benefit of a system S, as follows: cost-of-developing-S-without-euse - (1) Rb(S) = cost-of-developing-S-with-reuse --------------------------------------------------------------------------------- cost of S without reuse It can often be difficult to get a reasonable direct measure of Rb. In cases like this, software metricians have used indirect measures. For example, the external process attribute of maintainability is often measured indirectly1by internal product measures of complexity such as cyclomatic complexity. Likewise,the internal product measure of software size (in units of NCSL) is considered be a reasonable indirect measure of the external process attribute of maintenance cost. Following this approach, we are concerned with the development of an indirect internal measurement of Rb, the normalized reuse benefit of a system S,from the product, by searching the source code of S for instances of language-based reuse such as subroutine calls. The desire for an indirect benefit is one reason we choose a normalized measure. The relationship of the actual benefit to the source code may be much more implementation dependent than the normalized benefit: the actual cost of each line of code is likely to depend much more on the project than the relative cost for each line of code. With such an indirect measure,there is a risk that we are not really measuring what we seek to measure; we would therefore like to validate our indirect measure in some way. One approach to validating indirect measures is to perform empirical studies. Aparallel (or prior) approach, proposed by Weyuker [7] and others is to enumerate some formal properties that should hold of any measure (direct or indirect) of the attribute in question. Weyuker used this approach to evaluate several internal measures of complexity. Of course, we are using this approach differently than Weyuker: she "axiomatized2" properties of a complexity internal measure,and evaluated several internal complexity measures againstthese properties. We are seeking to "axiomatize" an external measure_reuse benefit_and use these "axioms" to evaluate and develop indirect internal measures of reuse benefit. In addition, measuring reuse benefit is quite different from measuring complexity; thus many of her axioms aren't relevant in our context. However,her Property 4 (implementation dependence) is critically important in measuring reuse, and in fact, we reformulate and strengthen Property 4 in several ways applicable specially to measures of reuse benefit. In the full paper, we present a set of 10 axioms that formalize desirable properties of internal metrics that seek to indirectly measure reuse benefit. 3 Related Work There are many models and metrics is the literature that try to evaluate the relative benefit achieved by reuse in a software system. In the full paper, we describe 2 main types of measures: the producer-consumer models of [8, 9, 10, 3, 6],and the reuse level measures of Frakes and Terry [2]. The former category gives weight to the actual size (NCSL) of the reused portion of the system. The latter suggests a reuse requency measure that gives weight to the number of times a component is used or reused. Both these measureshave been used in actual systems, and theresults have been reported by the authors. The axioms we report in [11] are applicable to both these measures,although in the case of [9] (and in [2]) some system-specific interpretations may be needed, since Poulin's measures involve some subjective accounting (Poulin, however gives detailed guidance on the accounting to minimize variance). Our properties serve as a formal framework in which these different measures can be compared. In [11], we undertake such a comparison, and propose a new measure that combines attractive elements from both these categories. Indirect measures are also used often in the physical and social sciences. For example the attribute of temperature is measured indirectly by the length of a mercury column in a thermometer. We use the quotation marks here because these are not necessarily axioms in the formal mathematical sense, but rather a list of properties that would appear to most people to hold of the measures in question. 4 Conclusion This paper is concerned with the indirect measurement of the benefit of software reuse by observing reuse occurrences in code. We have proposed a set of desirable properties of reuse benefit measures. In the full paper [11], we fully describe and justify these properties; we evaluate existing measures with respect to these properties;we propose a new measure of software reuse, which conforms more closely to our proposed properties; we also identify some basic difficulties in measuring reuse benefit that appear to be intractable. In addition to this theoretical evaluation,we have constructed the tool infrastructure to gather data on our measures and the other measures suggested in the literature by direct analysis of ANSI C and C++ systems.We have done a pilot study using some public- domain windowing software.We are currently pursuing cross-validation of these internal metrics data with external process attributes. This validation should shed some light on the appropriateness of our axiomatization. References [1]N. E. Fenton, Software Metrics: A Rigorous Approach. Chapman & Hall, 1991. [2]W. Frakes and C. Terry, "Reuse level metrics," in Third International Conference on Software Reuse, pp. 139-148, 1994. [3]J. J. E. Gaffney and Cruickshank, "Economic impact of software reuse," in Fourteenth Inter-national Conference on Software Engineering, IEEE Press, 1992. [4]J. Poulin,"Survey of approaches to reusability metrics," Tech. Rep. 14 March, Federal Systems Company IBM, 1994. [5]J. Poulin,"Measuring software reusability,"in Third International Conference on Software Reuse, pp. 126-138, 1994. [6]Y.-F. Chen andB. K. a= nd Kiem-Phong Vo, "An Objective Reuse Metric: Model and Methodology," in Fifth European Software Engineering Conference, 1995. [7]E. J. Weyuker, "Evaluating software complexity metrics," IEEE Transacations on Software Engineering, vol. 14, no. 9, pp. 1357-1365, 1988. [8]T. Bollinger and S. Pfleeger, "Economics of reuse: issues and alternatives, " Information and SoftwareTechnology, vol. 32,no. 10, pp. 643-652, 1990. [9]J. Poulin,J. Caruso, and D. Hancock, "The business case for software reuse," IBM Systems Journal, vol. 32, no. 4, pp. 567-594, 1993. [10]J. J. E. Gaffney and T. A. Durek, "Software reuse - key to enhanced productivity: some quantitative models,"Information and Software Technology, vol.31, no. 5, pp. 258-267, 1989. [11]P.Devanbu and S. Karstu, "Measuring the benefits of software reuse," tech. rep., AT&TBell Laboratories, 1994. 5 Biography Premkumar T. Devanbu is a member of the Software and Systems Research Laboratory at AT&T Bell Laboratories in Murray Hill, New Jersey. He is the creator of the GENOA/GENII system, which was used to implement GEN++, the first widely distributed meta-analysis tool for C++ programs. His research interests include static analysis, reverse engineering, application generators, dynamic analysis, applications of AI to software engineering and software tools. He received a Ph.D. in Computer Science from Rutgers University in 1994. Sakke Karstu is a member of the Center for Experimental Computation at Michigan Technological University in Houghton,Michigan. He has developed several tools with GEN++, including a reuse analyzer used in this research and a static slicer, which is used to calculate slice based cohesion measures. His research interests include software metrics and their utilization in commercial software development. He received a MS in computer science from Michigan Technological University in 1994. A Case Study of Software Architecture Life Cycle Processes David Dikel, Carol Terry, David Kane, Bill Loftus Applied Expertise 1925 North Lynn Street Suite 802 Arlington, VA 22209 Tel: (703)516-0911 Email:ddikel@aecorp.com, cterry@aecorp.com dkane@aecorp.com,william.loftus@kant.wpl.com Abstract A growing number of technologists believe that an architecture-based approach to software development can enable smaller teams to build better products faster and maintain those products more effectively. However, growing experience indicates that the primary problems to evolving and maintaining a long-standing architecture are organizational, not technical. Applied Expertise will conduct a case study of Bell Northern Research's Transmission System's architecture to learn how the organizational challenges of maintaining a software architecture once fielded were overcome. Keywords: architecture, product-line, organizational processes, case study Workshop Goals: learning; networking; receiving feedback and input on our case study. Working Groups:reuse management, organization and economics. 1 Background The Applied Expertise team has long-standing experience with software reuse. Dave Dikel's 1987 case studies of commercial Ada use identified reuse as a key driver for adopting Ada. [1] Since then, Dikel has developed and worked with customers to implement reuse-related operating concepts, strategies and plans for NASA, Department of Defense and Fortune 500 clients. For example, Dikel drafted key elements of DOD's plan for its Software Reuse Initiative (SRI), submitted to Congress in April 1994. Dikel led a case study for the ARPA Software Technology for Adaptable,Reliable Systems (STARS) focusing on software reuse criteria within Bell Canada's Trillium capability model. Later AE's team, including Carol Terry, Dave Kane and Dikel, captured and applied Bell Canada's use of Trillium to manage risks related to software reuse. Terryhas also published widely on software reuse metrics. Sponsored by NASA, Dikel and Terry, both help to lead the Reuse Library Interoperability Group (RIG), Terry as Vice Chair of TC6 and Dikel,as Vice Chair of the Executive Board. Kanemanages the RIG Secretariat for STARS. Kane has also performed domaim analysis for information systems. Since the mid 80's William Loftus has also maintained an important role in DoD's STARSprogram. As an AE Senior Associate, Loftus helped developed a software reuse strategy for a major Wall Street firm. Mr. Loftus recently completed a major software re-engineering project for a Fortune 500 firm, on time and below budget, leveraging software reuse and object oriented programming technologies. Terry manages AE's support to DoD's Interoperability Vision Working Group for SRI. Under this contract, Loftus and Terry lead the design of a technical reference model and concept of operations for reuse library interoperability for the DoD Software Reuse Initiative. 2 Position 2.1 Problem Architecture-based software development is an emerging technology. [2] A growing number of technologists believe that an architecture approach can enable smaller teams to build better products faster and maintain those products more effectively. There is a growing body of knowledge about how to design and build a software or systems architecture, as evidenced in programs such as the Software Technology for Adaptable, Reliable Systems (STARS). The STARS program has developed and increased the maturity,visibility and viability of architecture-based software engineering technology. Growing experience indicates that the primary problem in implementing, evolving and maintaining a long-standing architecture is often organizational, not technical. [3] Introducing an architecture- based approach and achieving product-line reuse can require an organization to make major changes that affect not only technology, but its very management structure. Even though the perceived benefits of this technology are great,the risk of moving to this technology is also perceived as high for both managers and for the technology champions who are driving the effort. There are few case-studies that providedirections to use, re-use, maintain and terminate these architectures. As a result, the organizational problems, issues, and solutions that can be learned from the long-term users of a software architecture are not widely known. For these and other reasons, it is important that these long-term software architectures be studied to learn how these organizational challenges can be overcome. 2.2 Our Work Applied Expertise (AE) is conducting a case study to uncover the key organizational elements in successfully evolving a product-line architecture. This work builds on a 1993 case study of Bell Canada's Trillium that identified several examples of long-term, successful software architectures within the telecommunications industry. One such example is Bell Northern Research (BNR) Switching Systems' evergreen architecture. First fielded in 1975,the architecture adapted to vast technological changes,and was used to build a range of products from simple office switches to toll switches that serve entire countries. AE's study will inspect BNR's Transmission product-line architecture. The study team will develop a focused set of hypotheses from the work ofGrady Booch, the Software Engineering Institute (SEI) and others,consisting of the key elements necessary for successfully evolving along-term product-line architecture. For example, one hypothesis might be: Successfully evolving a product-line architecture requires a ruthless focus on simplification, clarification and minimalization. [4] To provide depth, we plan to involve the intended audience for our products in the design and review of the initial study by forming an advisory group. This will increase the efficiency of our research and the impact of the products. The advisory group includes stakeholders in industry and government who have a strong interest and/or experience base in using an architecture-based approach to developing software. The group will review the initial hypotheses for the study,and will also collaboratively review and discuss the findings of the study. 3 Comparison Most current software architecture research efforts focus on defining and building an architecture and the skills and tools necessary for implementation. The Domain Specfic Software Architecture (DSSA) is a good example ofsuch an approach. A major thrust of this effort is to use software architectures to create applications inan automated fashion. [5] There is a growing amount of anecdotal evidence that organizational issues are a major obstacle to the institutionalization of softwarereuse. There is some work that addresses these factors,including Grady Booch's forthcoming book, Object Solutions: Managing the Object Oriented Project. [4] However, we have found few formal case studies covering the topic. Further,while Booch addresses software architectures in some depth, the primary focus of his work is object-oriented project management. Our approach will establish new ground by investigating the organizational issues surrounding the software architecture life-cyclewith more structure and rigor than has been done previously. References [1]D. Dikel,"Tracking the use of ada in commercial applications," Tech. Rep. 387-001-001,Ad-damax Corporation, 1987. [2]D. E. Perry and A. L. Wolf, "Foundations for the study of software architecture," ACMSIG-SOFT, October 1992. [3]P. Collins,"Software reuse at hewlett-packard," 1995. [4]G. Booch, Object Solutions: Managing the Object-Oriented Project. unpublished, 1995. [5]W. H. Christine Braun and T. Ruegsegger, "Domain specific software architectures - commands and control," 1993. 4 Biography Dave Dikel is Vice President and director of research at Applied Expertise.He currently directs work for DoD, NASA, and industry, focusing on software reuse, software risk management and technology transition, including projects for the Advanced Research Projects Agency, NASA, Loral and Hewlett-Packard. Mr. Dikel led a landmark study of Bell-Canada's Trillium software capability model. Mr. Dikel earned international distinction for his work in sizing and analyzing the Ada market and for his case studies of Ada,and other emerging technologies. He founded the ACM SIGAda Commercial Ada Users Working Group. Mr. Dikel earned a bachelor's degree in philosophy and physical sciences at the University of California, San Diego. Carol Terry is a Research Engineer at Applied Expertise, Inc. where she leads software engineering research and policy analysis for customers in government and industry. Her current research areas are software reuse and architecture-based development, technology transfer,and software risk management. Ms. Terry has a master's degree in information systems with a concentration in software engineering from Virginia Polytechnic Institute and State University, where she achieved distinction for research in software reuse and metrics. David Kane isa Software Engineer at Applied Expertise. He has developed information systems for a variety of government organizations, and has created an innovative technology transfer workshop for Hewlett-Packard. His research interests include risk management and software process improvement for small organizations. Mr. Kane has a bachelor's degree in computer science - mathematics from the State University of New York at Binghamton. William Loftus is an Applied Expertise Senior Associate. Mr. Loftus performs major systems design, development and software reuse assessment work for Applied Expertise. Mr.Loftus is a certified Sun Microsystems consultant.He has given many seminars and presentations on advanced software technology and has been published in a number of journals. At Unisys,Mr. Loftus received several awards and commendations for his contributions to the Unisys advance software program and the DoDAda Command Environment (ACE). He earned a bachelor EDs degree and a master's degree in computer science from Villanova University. Good Mental Models are Necessaryfor Understandable Software Stephen H. Edwards Dept. of Computer and Information Science The Ohio State University 395 DreeseLab 2015 Neil Avenue Columbus, Ohio 43210-1277 Tel: (614)292-5841 Email:edwards@cis.ohio-state.edu URL: http://www.cis.ohio-state.edu/edwards Abstract People form internal mental models of the things they interact with in order to understand those interactions. This psychological insight has been used by the human-computer interaction (HCI) community to build computer systems that are more intuitive for end users, but it has not yet been applied to the problems of software designers, programmers, and maintainers. In fact, conventional programming languages do little to help client programmers develop good mental models of software subsystems. The main problem is that the conventional wisdom that software modules are merely a syn-tactic mechanism for organizing declarations and controlling visibility is wrong. This skewed view of the nature of software modules limits their utility as effective building-blocks for creating large, complex software systemsthat are comprehensible to human readers. To constitute effective building-blocks,modules must present simple mental models to the softwa reprofessionals involved in assembling them into larger modules,and ultimately into complete software systems. Because a module has no real semantic denotation of its own, there is no way for one to imagine such building-blocks as contributing to the understandability of the software comprising them. Keywords: Mental model, module, programming language, understandability Workshop Goals: Cross-fertilization of ideas with other researchers; building on the results of WISR6; keeping abreast of other on going reuse work; advancing the theoretical foundations of software reuse. Working Groups: reuse and formal methods, design guidelines for reuse, reuse and OO meth-ods, component certification. 1 Background The Reusable Software Research Group at the Ohio State University has been exploring the technical problems of software reuse for the past several years, focusing on a disciplined approach to software engineering as a possible solution. The key goal of ensuring that this discipline of software construction will scale up to large systems has led the RSRG to center on the concept of supporting modular reasoning or local certifiability at the component level [1, 2,3]. In short, the client of a reusable component or subsystem should only have to consider a bounded amount of information (i.e., local, rather than global) when reasoning about whether that component is the correct one to choose, and whether it is being used correctly. A specific software discipline that ensures that all components have this property is described by Hollingsworth [4]. In addition to the requirement for local certifiability from a technical perspective, however, good reusable software must also support effective (and modular) human understanding from a psycho-logical perspective. This position paper claims that current programming languages do not offer any support for human understanding of programs. This claim is further developed elsewhere by Edwards [5], where a proposed solution is also detailed. 2 Position In interacting with the environment, with others, and with the artifacts of technology, people form internal, mental models of themselves and ofthe things with which they are interacting. These models provide predictive and explanatory power for understanding the interaction. These statements hardly need be said, for they are consistent with all that we have learned about cognitive processes and,within [the book Readings in Human-Computer Interaction], represent the major underlying conceptual theme. Nonetheless, it does not hurt to repeat them and amplify them,for the scope of the implications of this view is larger than one might think. - Donald Norman [6, p. 241] As Donald Norman indicates, the human-computer interaction (HCI) community has benefited from exploring the implications of mental models. This perspective has aided their ability to create more usable, understandable user interfaces for computer programs, as exemplified by the popular "desk top" metaphor. Researchers also have used the concept of mental models to examine how programmers design new software [7][8][9] and understand existing software [10][11]. The next logical step,as it was for the HCI community, is to ask how focusing on mental models can help us create software that is more usable and understandable to programmers. This is particularly important in the coming age of "software reuse, "where software parts will be written with the goal of being utilized by different programmers in quite disparate contexts. Unfortunately,asking questions about how programming languages support the formation of effective mental models leads one to conclude that conventional programming languages are inadequate for constructing large, sophisticated software systems that are "understandable." 2.1 Why Conventional Languages Fail In short, modern programming languages have evolved from their predecessors with the primary purpose of describing instructions to computers. They were never designed to help explain to people the meaning of the software that they can describe. This has led to two critical problems with programming languages today: modules are considered to be purely syntactic constructs with no independent meaning,and those parts of programs that are deemed meaningful (usually procedures, in imperative languages) have a "hierarchically constructed" meaning. First,most modern programming languages have some construct that is intended to be the primary "building-block" of complex programs. This building-block may be called a "module,"a "package," a "structure," or a "class." Unfortunately, these constructs are rarely given meaningful semantic denotations. Conventional wisdom in the computer science field indicates that these constructs are primarily for grouping related definitions, controlling visibility, and enforcing information hiding. For example, when speaking of module-structured languages like Ada or Modula-2, Bertrand Meyer states: In such languages, the module is purely a syntactic construct, used to group logically related program elements; but it is not itself a meaningful program element, such as a type, a variable or a procedure, with its own semantic denotation.[12, p. 61] In this view, there is no way forone to make such building-blocks contribute directly to the understandability of the software comprising them. While object-oriented languages usually give a stronger meaning to the notion of a "class,"they also fail to provide any vision of how the meaning of individual classes can contribute to a broader understanding of the software systems in which they are embedded. Second, those program elements that are given a real semantic denotation are often given a meaning that is "hierarchically constructed,"or synthesized. In other words, the meaning of a particular program construct, say a procedure, is defined directly in terms of its implementation_a procedure "means" what the sequence of statements implementing it "means." The meaning of its implementation is defined in terms of the meanings of the lower-level procedures that it calls. Thus, a procedure's meaning is "constructed" from the meanings of the lower- level program units it depends on,and the meanings of those lower-level units in turn depend on how they are implemented, and so on. This simple synthesis notion of how meaning is defined bottom-up is adequate from a purely technical perspective. It is also very effective when it comes to describing the semantics of layered programming constructs. Unfortunately, it is at odds with the way human beings form their mental representations of the meaning of software parts [5]. The result of these two features of programming languages is that they are inadequate for effectively communicating the meaning of a software building-block to people (programmers, in particular). The semantic denotations of programming constructs in current languages only relate to how a program operates. They fail to capture what a program is intended to do at an abstract level, or why the given implementation exhibits that particular abstract behavior. In order to address these concerns, it is necessary to assign meaning to software building-blocks, to separatethe abstract description of a software part's intended behavior from its implementation,and to provide a mechanism for explaining why the implementation of the part achieves behavior consistent with that abstract description. 2.2 Why Comments Alone are not Enough When trying to provide simple mental models for software components, the question ofthe effectiveness of comments arises. Thorough commenting of a component interface can allow a software designer to document the conceptual model of the part and pass this model on to other professionals using that part. In addition to the possibility of informal written descriptions of conceptual models, comments also allowthe inclusion of formally defined behavioral specifications. Entire specification languages, such as ANNA [13], have been designed to support complete or partial formal specifications via structured comments. Unfortunately, this is really only enough to capture (most often, informally) the external behavior advertised in a component's specification.To truly embrace the perspective instigated by mental models, one must also provide support for forming mental models of the implementation of a software component, how that implementation works, and why it gives rise to the abstract description in its specification. Software implementations typically rely on more information to operate correctly than is represented in the source code alone in a conventional language [14, pp 70-74][15, pp. 47-48]. Consider an abstract data type, where an implementation level "representation invariant" or its equivalent is proposed to capture some of this information. This,in addition to a model of the representation of the exported data type and behavioral descriptions of all internally declared operations, makes up a maintainer's mental model of a component implementation. Further, however, one must also account for the maintainer's mental model of why that implementation conforms to its specification - the basis for explaining why the behavior of the inner, more detailed mental model can be interpreted as being consistent with that predicted from the specification's more abstractly described cover story. This information is usually associated with an "abstraction function," "abstract relation," or "type correspondence" that explains the relationship between the representation of a given data type and its abstract specification. Similar information must be recorded about the relationship between module-level state variables in the implementation and those visible in the specification. Certainly it is possible to lay out a comprehensive plan for how to document all of this information via structured,formal or informal comments. Once all of this information is captured in the software component itself, it is even possible to start asking questions about whether the component is being used correctly: Does this implementation actually conform to that specification? From the client's point of view,is she using the given component "correctly" (i.e., in accordance with its professed abstract model)? Will a proposed maintenance change introduce new defects by violating the expectations of the remainder of the implementation, asexpressed in the representation invariant(s)? Will it invalidate the reasons why the implementation currently conforms to the specification? Unfortunately, to lay out this comprehensive commenting plan, one mustgo to a great deal of trouble to provide a firm foundation for it. Indeed, one must understand all of the information that must be represented, and have a firm grasp of the theoretical underpinnings of how valid answers to questions like those above are generated. In doing this, the researcher steps far beyond the idea of "simply commenting the code," and runs head on into the same problem of how to (formally) address support for mental models in a meaningful way. 2.3 Correcting the Deficiency The ACTI model proposed by Edwards [5] is centered around the notion of a "software subsystem," a generalization of the idea of a module or a class that serves as the building-block from which software is constructed. A subsystem can vary in grain size from a single module up to a large scale generic architecture. ACTI is designed specifically to capture the larger meaning of a software subsystem in a way that contributes to human understanding, not just the information necessary to create a computer-based implementation of its behavior. ACTI is not a programming language, however. It is a formal, theoretical model of the structure and meaning of software subsystems. It has two features that specifically address the inadequacies of conventional languages: 1. In ACTI, software subsystems (building-blocks) have an intrinsic meaning; they are not just syntactic constructs used for grouping declarations and controlling visibility. This meaning encompasses an abstract behavioral description of all the visible entities within a subsystem. 2.The meaning of a software subsystem is not, in general, hierarchically constructed. In fact, it is completely independent of all the alternative implementations of the subsystem. Thus, ACTI provides a mechanism for describing what a subsystem does, not just how it is implemented. The meaning provided for a subsystem is a true abstraction - a "cover story" that describes behavior at a level appropriate for human understanding without explaining how the subsystem is implemented. Further, ACTI provides a formally defined mechanism, called an interpretation mapping, that captures the explanation of why an implementation of a subsystem will give rise to the more abstractly described behavior that comprises the meaning attributed to the subsystem - in short, an explanation for why the cover story works. 3 Comparison Edwards [5] presents a thorough comparison of several programming languages that are representative of best current practices: RESOLVE [16, 1],OBJ [17], Standard ML [18],and Eiffel [12]. As typical of current efforts, most of these languages do little to support the formation or maintenance of effective mental models of software parts. The complete analysis, including a detailed check list of software structuring and composition properties supported by some or all of these languages, is available electronically [5]. Other efforts to provide better support for mental models has concentrated primarily on adding (possibly structured) comments to component specifications, the inadequacy of which is described in Section2.2. References [1]B. W. Weide, W. F. Ogden, and S. H. Zweben, "Reusable softwarecomponents," in Advances in Computers (M. C. Yovits, ed.), vol. 33, pp.1-65, Academic Press, 1991. [2]B. W. Weide and J. E. Hollingsworth, "Scalability of reuse technology to large systems requires local certifiability," in Proceedings of the Fifth Annual Workshop on Software Reuse, October 1992. [3]B. W. Weide, W. D. Heym, and W. F. Ogden, "Procedure calls and local certifiability of component correctness," in Proceedings of the Sixth Annual Workshop on Software Reuse (L. Latour, ed.), Nov. 1993. [4]J.Hollingsworth, Software Component Design-for-Reuse: A Language Independent Discipline Applied to Ada. PhD thesis, Dept. of Computer and Information Science, The Ohio State University, Columbus, OH, 1992. [5]S. Edwards, A Formal Model of Software Subsystems. PhD thesis, Dept. of Computer and Information Science, The Ohio State University, Columbus, OH, 1995. Also available as technical report OSU-CISRC-4/95-TR14, by anonymous FTP from ftp://ftp.cis.ohio- state.edu/pub/tech-report/1995/TR14-DIR, or through the author's home page. [6]D. A. Norman, "Some observations on mental models," in Readings In Human-Computer Interaction: A Multidisciplinary Approach (R. M. Baecker and W. A. S. Buxton, eds.), pp.241-244, San Mateo,CA: Morgan Kaufmann Publishers, Inc., 1987. [7]R. Guindon, H.Krasner, and B. Curtis, "Breakdowns and processes during the early activities of software design by professionals," in Empirical Studies of Programmers (E . Soloway and S. Iyengar,eds.), pp. 65-82, Ablex, 1985. [8]D. B. Walz, J. J. Elam, H. Krasner, and B. Curtis, "A methodology for studying software design teams: An investigation of conflict behaviors in the requirements definition phase," in Empirical Studies of Programmers (E. Soloway and S. Iyengar, eds.), pp. 83-99, Ablex, 1985. [9]R. L. Glass,"The cognitive view: Adifferent look at software design," in Software Conflict: Essays on the Art and Science of Software Engineering, pp. 25-31, Englewood Cliffs, NJ: Yourdon Press, 1991. [10]R. W. Holt, D.A. Boehm-Davis, and A. C. Schultz, "Mental representations of programs for student and professional programmers," in Empirical Studies of Programmers (E. Soloway and S. Iyengar,eds.), pp. 33-46, Ablex, 1985. [11]D. C. Littman,J. Pinto, S. Letovsky, and E. Soloway, "Mental models and software maintenance,"in Empirical Studies of Programmers (E. Soloway and S. Iyengar, eds.), pp.80-98, Ablex,1986. [12]B. Meyer, Object-Oriented Software Construction. NewYork, NY: Prentice Hall, 1988. [13]D. Luckham,F. W. von Henke, B. Krieg-Bruckner, and O. Owe, ANNA: A Language for Annotating Ada Programs. New York, NY: Springer-Verlag, 1987. [14]B. Liskov and J. Guttag, Abstraction and Specification in Program Development. The MIT Electrical Engineering and Computer Science Series, Cambridge, MA: MIT Press, 1986. [15]P.Bucci, J. E. Hollingsworth, J. Krone, and B. W. Weide, "Implementing components in RESOLVE," ACM SIGSOFT Software Engineering Notes, vol. 19, pp. 40-52, Oct. 1994. [16]B. W. Weide et al., "Special feature: Component-based software using RESOLVE," ACM SIGSOFT Software Engineering Notes, vol. 19, pp. 21-67, Oct. 1994. [17]J. A. Goguen, "Principles of parameterized programming," in Software Reusability, Volume I: Conceptsand Models (T. J. Biggerstaff and A. J. Perlis, eds.), pp. 159-225, New York, NY: ACM Press,1989. [18]R. Milner, M. Tofte, and R. Harper, The Definition of Standard ML. Cambridge, MA: MIT Press,1990. Biography Stephen H. Edwards is a Senior Research Associate in the Department of Computer and Information Science at the Ohio State University. His research interests include formal models of software structure, software composition, software reuse,software engineering, the use of formal methods in programming languages,and information retrieval technology.He is also currently the Archive Administrator for the Reusable Software Research Group at OSU. Dr. Edwards is a recent graduate from OSU, having received a Ph.D. in computer and information science in March,1995. Prior to working at OSU, he was a research staff member at the Institute for Defense Analyses, where he worked on software reuse activities, simulation frameworks, active databases, and Ada programming issues. Mr. Edwards gratefully acknowledges financial support from the National Science Foundation (grant number CCR-9311702) and the Advanced Research Projects Agency (contract number F30602-93-C-0243, monitored by the USAF Materiel Command, Rome Laboratories, ARPA order number A714). Life Cycle Interaction in Domain/Application Engineering David Eichmann and Carl Irving* Repository Based Software Engineering Program, Box 113 Research Institute for Computing and Information Systems University of Houston - Clear Lake 2700 Bay Area Blvd. Houston, TX 77058 Tel: (713) 283-3875 Fax: (713) 283-3869 Email: eichmann@rbse.jsc.nasa.gov WWW: http://ricis.cl.uh.edu/eichmann/ RBSE on the Web: http://rbse.jsc.nasa.gov/eichmann/rbse.html Abstract The interactions between the life cycles for domain engineering and application engineering are not commonly recognized. We discuss the nature of these interactions and how they are reflected in a specific large reengineering project. Keywords: domain engineering, application engineering, software processes, reengineering Workshop Goals: To obtain feedback on a collaboration and do some technology transfer. 1 Background 1.1 Introduction The increasing emphasis in large, government software engineering projects on engineering domains, rather than engineering specific systems holds a promise of reduced costs, faster fielding of systems and a host of other anticipated benefits. However, this transition to a new perspective on software life cycles is not without side-effects. In particular, we have found that the separation of development into a domain engineering cycle and an application engineering cycle is not as clear and distinct as might be imagined. The Repository Based Software Engineering (RBSE) project at the Research Institute for Computing and Information Systems (RICIS) has been working for a number of years in the area of software reuse and more recently, in the reengineering of legacy systems as an aspect of reuse [3]. The purpose of RBSE is the support and adoption of software reuse through repository-based software engineering in targeted sectors of industry, government, and academia. The project consists of two principal activities, a repository initiative and reuse engineering initiative. RICIS conducts research and development for both initiatives. MountainNet operates ELSA as the publicly accessible aspect of the repository initiative [4]. The reuse engineering initiative at RICIS focuses on the support of specific software projects as they transition to a reuse oriented development and maintenance paradigm. One such project is the Reusable Object Software Engineering (ROSE) project, involving the Rockwell Space Operations Company (RSOC) (including UNISYS as a major subcontractor), the Software Technology Branch of the Information Systems Directorate of NASA (NASA/STB) and the RBSE research group. ROSE is a reengineering effort being developed to provide an economical and effective modern implementation of the Shuttle Flight Design and Dynamics (FDD) systems in order to supplant the costly legacy systems which have evolved since the early days of the Shuttle program. The ROSE project is intended to apply modern software engineering techniques in order to reproduce the systemsÕ functionality in a consistent object-oriented architecture and design framework. The project applies a reuse-based dual lifecycle process in order to achieve efficiency and consistency across the software products as a whole. 1.2 The ROSE Lifecycle in a Nutshell The ROSE project is a reuse-based dual-lifecycle software development project. The ROSE lifecycle (or lifecycles, to be exact since there are separate domain engineering and application engineering lifecycles) is based upon a collapse of the Clear Lake Lifecycle Model (CLLCM) [5] from eight phases to four. The fundamental division of responsibilities between domain and application perspectives can be summarized as follows: The domain engineers scope the domain, identify the potential applications and establish a common Òdomain language.Ó Domain Analysis is composed of domain survey, business analysis, concept development, domain scoping and domain modeling sub-phases. Domain Design is a design effort for one common architecture to the domain. The design process includes explicit searches for reusable components at various levels of abstraction and provides for reverse engineering of portions of the legacy system in order to serve as (positive or negative) Òinspiration.Ó The paradigm is for one architecture to cover the domain which can then be tailored by pruning unneeded features and grafting extensions on an application by application basis. Domain Implementation focuses on the implementation and testing of the architecture components in an orderly fashion prioritized in such a way to support the application implementation efforts. Implementation of architecture components includes their integration to the degree that this is possible without a complete application.  Application Analysis is a twofold extension process of the Domain Analysis product set. Following concept exploration of the application, the set of requirements and models produced by the domain engineers is pruned down to form a starting subset of the application requirements. This set is then extended through a requirements gathering process in order to obtain a full set of application requirements. Application Design is concerned with the selection of architecture subsets that match the application requirements and constraints followed by a design process similar to that applied during Domain Design Ð but only for additions and modifications to the architecture. Application Implementation uses exactly the same process as Domain Implementation but applied to the application-specific components remaining to be developed. Integration testing of the application is meant to follow-on from the testing performed during Domain Implementation: their union forms one seamless integration activity. The application and domain maintenance processes are designed as a two-tiered hierarchy where the customer interacts with Application Maintenance which in turn makes requests of the Domain Maintenance process as needed. Both processes are similar but differ where it comes to the impact of change requests on domain products. ROSE is scheduled as a number of Òdelivery incrementsÓ where a significant portion of the product set is delivered on a regular basis and the projectÕs performance is reevaluated. This division has interesting effects on the evolution of the projectsÕs maturity with respect to its dual-lifecycle organization. On one hand, transitions from one increment to the next are excellent times to implement upgrades in lifecycle models. On the other, the relative proximity of the next scheduled delivery make incremental changes from a relatively conventional initial process a necessity. ROSE is evolving towards a mature dual-lifecycle organization, having started from more humble traditional point-solution beginnings. It should be noted that the lifecycle presented in figure 1 is the result of the current delivery incrementÕs labors and is expected to be institutionalized as of the next increment. 2 Position The software lifecycle is a complex set of interrelated activities. Some in our field claim to understand the nature of the relationships between the phases of the lifecycle and the roles involved in traditional Òpoint-solutionÓ approaches to software development. However, newer and arguably more productive reuse-based process models such as the Òdual-lifecycleÓ approach to software development where two perspectives (domain engineering and application engineering) are employed raise new uncertainties about the way the lifecycles (and their individual phases) fit together. Our experience with the ROSE project has allowed us to witness the establishment and implementation of a reuse-based dual-lifecycle software development organization on a non-trivial scale. The choice and tailoring of initial ÒtheoreticalÓ models (e.g., the CLLCM) into the practical processes that ROSE team members use on a day-to-day basis give insight into the structure and interactions within working teams using this approach. The introduction of a second lifecycle to the overall development process introduces new ways in which the phases of the lifecycle influence each other. The traditional Òpoint-solutionÓ lifecycle implies that the various phases of the lifecycle influence each other in a Òproducer-consumerÓ sense: earlier phases produce products which are picked-up, interpreted and transformed (ÒconsumedÓ) by later ones. Influences can exist when considering both products and processes present in the lifecycles, as shown in Table 1. Table 1: Some Process Influences with Examples Influence Medium Example Application Analysis is a consumer of Domain Analysis products Product Domain requirements and models Domain Analysis is influenced by the Application Analysis process: The products of Domain Analysis must be compatible with adaptation as performed by Application Analysis Process The initial process employed by ROSE Domain Analysis captured requirements as a classified ÒflatÓ set of requirements. This later evolved into a hierarchical classification as such a structure facilitates the job of application analysts through the manipulation of requirement hierarchies as a whole rather than individually. The change was directly related to the needs of the Application Analysis process. Domain Analysis influences Domain Design as far as the expression of variability in the domain Product The scope (i.e. applications) of the requirements and constraints with the (explicit or implicit) variability requirements captured during Domain Analysis are the basis for the domain designersÕ use of adaptable design idioms Application Design is a consumer of Domain Design products Product Architecture design models and design feature catalogues Application Design influences Domain DesignÕs choice of design idioms to be compatible with the adaptation techniques it employs Both The ROSE Domain Design process explicitly contains a step early in the process to determine suitable design guidelines with respect to the Application Design process and the expected targets. Care is taken to include the application engineering role where possible to ensure design adaptability. Application Implementation is a consumer of Domain Implementation products Product Coded partially or completely integration-tested components with documentation and test plan Domain and Application Implementation processes influence each other with respect to their shared task Process The domain and application implementation processes are differ in their ability to integration test implemented products. The former is constrained by the non-availability of complete subsystems to integrate (since key components may be application-specific) so integration and target testing are distributed unevenly across both implementation phases The Domain Maintenance process influences the Application Maintenance process Process Since the maintenance processes are organized as a two-tiered hierarchy, the Application Maintenance process needs to delegate domain issues to the Domain Maintenance process through a well-defined interface Understanding the ways in which the processes interact and influence each other in a dual-lifecycle software organization has the potential for insights into the workings of domain engineering processes as we know them and hence a better footing for improving them. For example, a better understanding (and a catalogue) of the design adaptation mechanisms employed during Application Design can be employed by domain designers to select the most suitable design techniques and idioms in order to support these choices (what one could call Òmeta-design patternsÓ). In a practical environment, the choice of adaptation techniques and the idioms that support them is the result of a consensus between the domain and application engineers. The ROSE processes exhibit early traits of such an organization (although without the comprehensive bindings between design techniques and their adaptability) in that domain design activities are based upon the use of Òdesign feature cataloguesÓ that record good practices (with corresponding rationale) that have been shown to have value in the Domain Implementation and Application Design efforts. 2.1 Discussion Much of the current work on domain analysis and dual-lifecycle software processes centers around the design of processes that allow for the capture of domain information and make it available to builders of actual applications in the domain. A characteristic of domain products is their support for adaptation (through composition, inheritance or Ð if necessary Ð modification). Domain engineering efforts thus strive to employ consistent and effective means to support application-specific adaptation. One of the process designerÕs choices is to decide where these means are defined: they can be embedded in the process, left to the application engineerÕs choice or produced explicitly as part of domain engineering. These three views by themselves may be a little simplistic in that processes in the dual lifecycles have more influence on each other than implied by a simple producer-consumer relationship. Our views are driven by the observation of the design and enactment of a project using the dual-lifecycle approach: ROSE. The initial mindset of the process designers was for domain engineers to define the domain architecture and specify the means for its adaptation Ð a model where consumption of products bears no influence on the producer. In actual practice, the differences in outlook between the domain and application engineering teams imposed a more pragmatic compromise. Examination of domain engineering products led to an interesting question: what makes a domain product (analysis model, architecture design, etcÉ) ÒspecialÓ as opposed to the corresponding products in a point-solution lifecycle? In many instances, we found none: although they were the result of a different process, domain products tended to be expressed in a manner consistent with habitual products of their kind. This implies that domain engineering can be performed in a manner that does not automatically entail readily apparent domain engineering-specificity in the product set. This led us to a closer examination of the processes, where it became apparent that although they have separate foci, neither domain nor application engineering operates in a vacuum. For instance, Domain Design exhibits a pragmatic mix of influences on and by the Application Design process: on one hand, the design features present in the domain architecture are drawn from a feature catalog that is passed on to application designers with instructions as to their planned use but on the other, this catalog itself is built with input from the application engineers. In the current state of the process, this influence Ð although tangible Ð is not formalized. These observations upon the influences that the domain and application engineering lifecycles have upon each other do still hold (although with different manifestations) when domain engineering- aware notations and techniques are used. For instance, the layered design architecture presented by Becker and D’az-Herrera [2] is consistent with the culmination of an informal design feature selection procedure similar to that in the ROSE Domain Design process. Alternative formalisms for the representation of domain architectures (such as the formal architectural components proposed by Allen and Garlan [1]) present opportunities for treating some of the interactions between lifecycles in a disciplined manner, as they represent a common formal language for manipulating the composition of domain products. Identifying the interdependencies between the domain and application engineering processes also is a step towards their efficient management. For example, one problem that the ROSE domain engineers have had to cope with is that the division of the project into delivery increments precludes the analysis and modeling of the domain as a whole, domain and application engineering are executed in near-concurrency so that the planned increment can be produced on time. Such a ÒcondensedÓ execution of the processes taxes the ability of the domain engineers to model the domain broadly and for the application engineers to provide meaningful feedback. An overall model where the domain and application lifecycles operate in a vacuum does nothing to discourage this kind of schedule nor to understand its inherent couplings. References [1] Allen, R. and D. Garlan, ÒFormalizing Architectural Connection,Ó Proc. 16th International Conference on Software Engineering, Sorrento, Italy, May 16-21, 1994. [2] Becker, M. and J. L. D’az-Herrera, ÒCreating Domain Specific Libraries: a methodology and design guidelines,Ó Proc. Third International Conference on Software Reuse, Rio de Janeiro, Brazil, November 1-4, 1994. [3] Eichmann, D., ÒThe Repository Based Software Engineering ProgramÓ Proc. Fifth Systems Reengineering Technology Workshop, Monterey, CA, Feb. 7-9, 1995. [4] Eichmann, D., M. Price, R. Terry and L. Welton, ÒELSA and MORE: A Library and Environment for the Web,Ó Proc. 13th Annual National Conference on Ada Technology, Valley Forge, PA, March 13-16, 1995. [5] Rogers, K., M. Bishop, C. McKay, ÒAn Overview of the Clear Lake Life Cycle Model,Ó Proc. Ninth Annual National Conference on Ada Technology, U.S. Department of Commerce, National Technical Information Service, March 1991. Biographies David Eichmann is an Assistant Professor of Software Engineering at the University of Houston - Clear Lake and Director of Research and Development of the Repository Based Software Engineering Program (RBSE). Besides normal academic duties, his responsibilities include management of a fifteen person research and development group working in the areas of reuse repositories and reengineering. Funded by NASA through the RICIS cooperative agreement and working closely with Johnson Space CenterÕs Software Technology Branch, RBSE is collaborating with Rockwell Space Operations Company on the reengineering of a major portion of the Space Shuttle Flight Analysis and Design System. Carl Irving is a graduate student in the Software Engineering Program at the University of Houston - Clear Lake and a research assistant on the RBSE project. His responsibilities include domain modeling and process definition on the ROSE collaboration. * This work has been supported by NASA Cooperative AgreementRB02A. Software Process Reuse Craig Hollenbach & William Frakes Department of Computer Science Virginia Tech Falls Church, VA 22042 Tel: (703) 698-4712 Email: frakes@sarvis.cs.vt.edu Abstract This paper describes an in-progress study of software process reuse and reusabilityÑspecifically how to pragmatically and systematically standardize and replicate project-specific processes in an industrial software environment. Our working hypothesis is that by using domain engineering techniques, software reuse principles, process architecture research, and process modeling mechanisms, project- specific processes can be abstracted into reusable components that can be used by process engineers. The study includes: ¥ a notation for recording reusable processes, ¥ definition of processes in an industrial environment, ¥ creation of a repository of these reusable processes. ¥ an evaluation study aimed at demonstrating the effectiveness of our method for process reuse. The study is based upon process definition activities at PRC Inc. The study will measure the level of process reuse both before and after the application of the proposed process reuse improvement method. 1 Position 1.1 Introduction Many software organizations are actively pursuing software process maturity. Often they use measures like the SEI Capability Maturity Model to structure their process improvement initiatives. PRC Inc. has pursued software process maturity in various ways since 1987. One method often cited for accelerating process improvement within an organization is the standardization and replication of project- specific processes from a mature software organization to immature software organizations. Even though it is often proposed as an effective approach to increasing an organization's software maturity, there have been few documented instances of process reuse within the software process improvement program at PRC. A literature search showed that this situation is common in other organizations as well. Although there are instances of replicating processes within organizations, there are no reports of a systematic process reuse program. Only one study has addressed process reuse specifically [2], indicating that systematic process reuse is unrealized. One of the more daunting tasks of a process reuse program is the development and maintenance of quality process definitions which serve the entire organization. To meet this need, PRC has developed an Organization Process Definition (OPD) methodology used to define reusable processes. Since the scope of OPD encompasses all software projects within PRC, we deal with a diverse set of projects and project needs. To serve them better, we have developed a set of standard, generic process definitions, and have started using a standard process to develop, maintain, and manage those definitions. We have also created a Process Asset Library (PAL) which contains reusable processes and process-related assets. 1.2 The PRC OPD process The PRC OPD process is adapted from the process described at the 1994 National SEPG (Software Engineering Process Group) Meeting by Jim Over, and on other domain analysis methodologies [1]. The OPD process starts with PRC SEPG approval, feeds the development of organizational training and the instantiation/tailoring of the process and process training on PRC projects, and includes feedback from the projects for continuous process improvement. The process itself includes steps for planning, analysis, high-level design, implementation design, implementation of process automation, and testing and integration within the PRC process architecture. 1.3 Process Asset Library The Process Asset Library (PAL) is a corporate resource that contains reusable processes and process related assets from both corporate and project levels. It currently contains over 500 assets and uses a WWW browser as a front-end. A catalog of assets is maintained for simple perusal, searching, and maintenance. Plans are under way to integrate the PAL with corporate metrics and tools databases. PRC took the advice of other SPI efforts and began with a small and simple PAL prototype. The database was a simple file server with a spreadsheet acting as a catalog. Access problems, support over multiple platforms, and the need for various application output formats created a need for a prototype WWW browser as a front-end interface. We have also learned the lesson that small is beautiful in process definition and the importance of including more software practitioners in the definition process, as we transition from a centralized to a de-centralized approach to process definition. 1.4 Use of the OPD process and the PAL The PAL user base within PRC includes SEPG members at all hierarchical levels, proposal and project startup efforts, and members of software process improvement (SPI) working groups. Example uses of the OPD process include peer review, developmental CM, and subcontract management processes. 1.5 Experiments We will run several quasi-experiments to evaluate the effectiveness of the process reuse methods we propose. We are collecting data, over time, from several projects that have used the method. This data includes the number of reused processes and the percentage of reused processes. We will compare these number for projects before and after the introduction of the reuse process methods. References [1] Arango, G. (1994). Domain Analysis Methods. In W. Schaefer, R. Prieto-Diaz, & M. Matsumoto (Eds.), Software Reusability New York: Ellis Horwood. [2] Castano, S. and DeAntonellis, V. ÒReusing Process SpeicifcationsÓ, in N. Prakash et. al (Eds.) Information System Development Process: Proceedings of the IFIP WG 8.1, Working Conference on information System Development Process, Como Italy, 1-3 Sept. 1993: North Holland Pub.. Biographies Craig Hollenbach is principal computer analyst at PRC, Inc. He has over 14 years of software engineering experience and 6 years experience in software process improvement. He is currently working on software process improvement activities within PRC and PRC's Technology Center and is chair of the Technology Center SEPG. Craig has a B. S. degree from Lebanon Valley College and is pursuing a M. S. in Computer Science from Virginia Tech. Bill Frakes is associate professor and director of the computer science program at Virginia Tech, Falls Church, and president of the Software Engineering Guild. He has been manager of the Software Reuse Research Group at the Software Productivity Consortium, and supervisor of the Intelligent Systems Research Group at Bell Laboratories. He is author of Software Engineering in the UNIX/C Environment (Prentice-Hall, 1991), and Information Retrieval: Data Structures and Algorithms (Prentice-Hall, 1992). He is chair of the IEEE TCSE Committee on software reuse. Reuse Lessons Learned from Architecture and Building Systems Integration Marilyn T. Gaska Loral Federal Systems-Owego 1801 State Route 17C Owego, NY 13827 Tel: (607)751-4156 Email: mtgaska@lfs.loral.com Abstract A previous position presented at the WISR6 conference by the author ([1]) compared the similarities of the OSE and COTS integration research areas to those ofthe horizontal reuse research. This paper extends this concept outside the computer-based systems field to draw on comparisons to generic design and systems integration concepts from other disciplines such as architecture. These established disciplines may provide reusable process patterns for success to be applied to the "new" approaches in computer-based systems design: object-oriented methods, component-based design, and open systems. Keywords: Horizontal Reuse, Architecture, Computer-Based Systems, Generic Design, Patterns, Open Systems Environment (OSE) WorkshopGoals: To learn additional concepts and technology for transfer to industrial environment; to obtain inputs on position,particularly related to Ph.D. Dissertation topic in Systems Science at Binghamton University. WorkingGroups: Technology Transfer, Reuse Management, Domain Analysis. 1 Background Since February 1993,the author has held the position of Reuse Coordinator at Loral Federal Systems (LFS) in Owego,New York [2] where she also served as the local arrangements chair for WISR6 held in Owego in November,1993. Current reuse activities at Loral have expanded to include LFS Group-wide responsibilities. She is also the Principal Investigator for Open Systems Independent Research and Development (IRAD)tasks, including a task on Object Oriented Frameworks and Domain Specific Software Architectures for Management Information Systems (MIS). Previous papers presented by the author have focused on the commonalities among problems and application of solutions in the reuse, concurrent engineering, and open systems research are as [3, 1, 4]. This analysis has broadened to comparisons with approaches in areas outside of computer-based systems as part of the authors research interest in design [5]. Reuse is one of the design attributes included in this analysis. 2 Position Reuse is a design attribute of other established disciplines such as architecture. Architecture and building systems integration concepts can me mapped to computer-based systems to provide new design for reuse perspectives and lessons learned. Systems science teaches the benefits of cross-discipline learning, which is proposed as useful to research efforts in reuse. While [1] compared the similarities of the OSE and COTS integration research areas to those of the horizontal reuse research, the focus of this position paper is application of concepts from the field of architecture. Further analysis with respect to specific design attributes such as reuse can also provide additional lessons already learned in other fields. Since architecture has embraced component-based design andstandards concepts when dealing with physical building objects,it holds promise for useful patterns for application to parallel approaches in computer-based systems design. 2.1 Insight from Architect Alexander's Work Christopher Alexander's frequently referenced early work [6] does not directly address reuse concepts. Rather, conscious and indigenous / unconscious design, analysis and synthesis, and patterns are described. This book was followed by a six volume series [7, 8, 9, 10, 11, 12].[7] describes the timeless way of building in terms of a genetic process for creation of a whole organism,an analogy that has also been further described in [13]. The framework for the pattern language described in [8] is put in place. Patterns are similar to rules of thumb. Patterns of events give character to a place, and are interlocked with geometric patterns in space. These patterns are the atoms and molecules that make up a building or town, and the language gives users the powers to create an infinite variety of new and unique buildings appropriate to different circumstances. Constant use and feedback keeps the patterns in good order, and people and their feelings can't be separated from the language. In computer-based systems,this concept can be applied to the requirements, high-level design, detailed design or implementation/construction phases just as they scale from regional planning down to physical structure considerations in architecture. A total of 253 patterns are described in [8]. However, a project may defineits own language by selecting form those pre-defined patterns aswell as defining additional patterns appropriate to the domain of the project. The order in which the patterns are applied to a design will impact the result. Application of these concepts at the University of Oregon is described by [9]. All design and construction was guided by a collection of communally adopted planning principles called patterns. Other implementation principles included principles of participation, piecemeal growth, diagnosis, coordination and organic order. [11] describes the experience in building the Linz Cafe for an Exhibition in accordance with the pattern language principles. [10] define the building system in terms of the actions that are needed to produce a building,not in terms of the physical components. The system of operations required must have the property that each operation can be completed by itself, secure that the operations which follow can always be done. It is their nature to be able to adapt themselves to the results of the operation already performed. Alexander explains how the process is capable of allowing mass production of large numbers of houses which are all different, without increasing cost. [12] describes seven detailed rules of growth which include parallels for principles of incremental design. 2.2 Building Systems Integration Perspectives Books from the field of architecture that deal with integration theory among subsystem components more closely parallel experiences in large scale reuse. The remainder of this discussion will focus on a more recent compilation of works into a handbook on building systems integration. Rush has edited a book published by the American Institute of Architects that proposes a model for analysis of building systems integration that can be applied to computer-based systems design and architecture ([14]). This model provides an understanding regarding the ease of reuse of architectural components that parallels current experiences and directions in computer-based systems. These include directions in open systems, client server, commercial off the shelf (COTS) and object- oriented design. This includes a theoretical basis for the two and three- tier architecture of client-server computing. Rush documents a new shorthand for a clear concept of integration that reduces all buildings systems to a set of four overall systems- structure, envelope, mechanical and interior. Roundtable discussion of professionals from several disciplines resulted in a tetrahedron interrelation diagram for the four systems. A summary of the tetrahedron nodes and proposed parallels form computer based systems follows: Architecture Tetrahedron ProposedComputer-Based Systems of Major Systems Tetrahedron of Major Systems ENVELOP (Visible on exterior) Human Computer Interface (HCI) STRUCTURE (Creates equilibrium Platform (includes operating system necessary to allow and network) building to stand) INTERIOR (Visible from inside) Data Model MECHANICAL (Services to building Methods/functions and occupants) System/Business Logic/Rules A proposed diagrammatic method for visible integration is used to describe 11 possible combinations of systems,a 5 level scale of complexity, and 6 performance mandates. The result of the process has been called building systems integration,which is defined as the act of creating a whole functioning building containing and including building systems in various combinations. The success of a system, like that of integration, is evaluated by comparison of the intention (requirements and goals) with the result. The design for a building becomes the final integration - an order that includes systems but is not a system itself. The integration is complete when all of the links have been established. Similar to Alexander's patterns, Rush identifies 19 buildings actually built (with clients, sites, program requirements, costs andarchitects) as case studies. Aset of 15 generic examples are generated, each with principal applications and advantages listed along with key integration issues. He emphasizes that architects don't learn to design by reading books, and that every architect's learning process is by direct experience and takes a lifetime. The book explores building systems configurations in the context of the criteria (requirements) by which they are selected and available options. In general, a client's need for a building generates a choice to either select a building that has already been built or select an architect. This parallels the process of selecting COTS or custom development. Similar to software, part of the architect's responsibility / task is selecting from existing products and services,while another part is integrating and originating the system. On the integration continuum, maximum integration can minimize flexibility, while complete indep endence of parts can provide for greater interchangeability and evolution of use. In summary, these concepts can be used to explain current developments in computer science: 1. Ob ject-Orientation - integration of data and logic/methods 2. Client/Server - 3 tier architecture with separate HCI, logic and data servers 3. Open Systems - platform portability, scalability and interoperability 4. Reengineering - assessing reusability and options for moving in flexible and tightly integrated proprietary systems 5. COTS software - success of windows environment and spreadsheet applications 6. Small vs. Large Scale Reuse - individual vs. multiple nodes of tetrahedron impacted 2.3 Research Plans The key issue for reuse is a systems integration issue. What is the best architecture and system integration approach to optimize reuse? How do software system architects best synthesize systems built apart? What are the integration properties of the most easily reused tetrahedron nodes and combinations? How do concurrent engineering concepts apply that allow for design and integration of all components / disciplines so that system behaves as unified whole and meets performance goals and customer satisfaction?How can patterns be applied to requirements to assure that user needs met for each particular problem? An initial focus on user requirements has been selected to address the need for a smooth transition into design for the new computer systems paradigms [5]. Methodologies that support design for reuse, open systems, COTS, and object-oriented frameworks are needed. This analysis will be expanded to include other disciplines beyond architecture. These include systems science, computer science/software engineering, management information systems, product design and manufacturing, and science/health. Recommendations for user involvement and rapid prototyping with OSE and COTS constraints will be applied to case studies. 3 Comparisons Generic design books such as [15] have drawn from the field of architecture for many of the basic design concepts. Gause and Weinberg focus on the requirements step with involvement of all key user constituencies as crucial to successful design. However, application of additional guidance drawn from architecture may provide additional refinement to their framework for exploring requirements. Gamma et al. have cited Alexander's Pattern Language [8] as a basis for the "Design Patterns, Elements of Reusable Object-Oriented Software" [16]. They give credit to Alexander and his colleagues as "the first to propose the idea ofusing a pattern language to architect buildings and cities." These are some of the ideas that have taken root in the object- oriented community as a key to helping developers leverage the expertise of other skilled architects. However,a review of the complete six volume series by Alexander and colleagues may indicate a different intent than what one might think of as reuse in architecture. Alexander emphasizes user involvement in the design process [12] and customization during application of rules within the context of a unique specific sites. He expresses disdain for prefabricated modular components that constrain the design customization and adaptation [10]. Care must be takenin application of the pattern language concepts to assure that these concerns are addressed. Tracz and Coglianese ([17]) have focused on processes for domain specific software architectures (DSSA). [10] proposes replacement of the idea of a building system as a system of components to be assembled with a step-by-step system of building operations. Comparison and appropriate incorporation of these concepts into DSSA methodologies may be warranted. References [1]M. Gaska, "An Open Systems Perspective on Horizontal Reuse," in Sixth Annual Workshop on Institutionalizing Software Reuse, (Owego, New York), pp. Gaska1-7, In cooperation with the IEEE Computer Society Technical Committee on Software Engineering, November 2-4, 1993. [2]M. Gaska and J. Poulin, "Institutionalizing Software Tools and Methods," in IEEE Computer Society Workshop on Software Engineering Technology Transfer, (Dallas, Texas), pp.143-146, April,1994. [3]M. Gaska, "An Open Systems Profile for Concurrent Engineering," in Proceedings Second Workshop on Enabling Technologies (WET)- Infrastructure Collaborative Enterprises (ICE), (Morgantown, WV), IEEE, April 20-22, 1993. [4]M. Gaska, "Application of Reuse Concepts to Concurrent Engineering," in Proceedings from Concurrent Engineering Research and Applications (CERA) 1994 Conference, (Johnston, PA), pp. 255-266, Concurrent Technologies Corp., August 29-31, 1994. [5]M. Gaska, "General Principles of Requirements Engineering Across Disciplines: Patterns for Application to New Approaches to Computer- Based Systems Design,"Tech. Rep. Prospectus for Ph.D. Research, Binghamton University, June 1994. [6]C.Alexander, Notes on the Synthesis of Form.Cambridge, Mass.: Harvard University Press, 1964. [7]C. Alexander, The Timeless Way of Building. New York:Oxford University Press, 1979. [8]C. Alexander, S. Ishikawa, M. Silverstein with M. Jacobson, I. Fiksdahl- King, and S. Angel, A Pattern Language. New York: Oxford University Press, 1977. [9]C. Alexander, M. Silverstein, S. Angel, S. Ishikawa, D.Abrams, The Oregon Experiment. New York: Oxford University Press, 1975. [10]C. Alexander with H. Davis, J. Martinez, and D. Corner, The Production of Houses. New York: Oxford University Press, 1985. [11]C. Alexander, The Linz Cafe / Das Linz Cafe. New York:Oxford University Press, 1981. [12]C. Alexander, H. Neis, A. Anninou, I. King, A New Theory of UrbanDesign. New York: Oxford University Press, 1987. [13]D. Gause and E. Minch, "Design Processes: A State Space Perspective," in Praxiology: The International Annual of Practical Philosophy and Methodology,Volume3, (Rutgers University, New Jersey), Transaction Publishers, 1995. [14]R. Rush, ed., The Building Systems Integration Handbook. Boston: The American Institute of Architects,1986. [15]D. Gause and G.Weinberg, Exploring Requirements: Quality Before Design. New York: Dorset House,1989. [16]E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns. New York: Addison-Wesley, 1995. [17]W. Tracz and L. Coglianese, "Domain Engineering Process Guidelines," Tech. Rep. ADAGE-IBM-92-02, IBM Federal Sector Division, March 1992. 4 Biography Marilyn T. Gaska is an Advisory Programmer in Advanced Technology at Loral Federal Systems in Owego, New York. Her specific background in reuse and open systems IRAD tasks has already been described. Marilyn also has been involved in Open Systems Environment (OSE)standards and profiles on the Army Sustaining Base Information Services (SBIS) contract,as well as Commercial-Off the Shelf (COTS) software integration LFS-Owego tasks.Prior to joining the Federal Systems Integration business area, assignments involved concurrent engineering and computer aided design (CAD). Marilyn had experience in other fields such as health care before joining IBM Federal Systems Company,now part of Loral, in 1987. In addition, she is a Ph.D. candidate in the Industrial Engineering and Systems Science Department at Binghamton University. Research in the systems design area with Professor Donald C. Gause focuses on application of requirements principles across disciplines to new approaches to computer-based systems design [5]. These part-time studies follow her second Master of Science in Advanced Technology at Binghamton in 1985. However,she received her first Master of Science on a Cornell Fellowship in 1979 following completion of a Bachelor of Science degree at Cornell in 1978. She is also a member of the IEEE. The Architecture and Processes for a Systematic OO Reuse Factory Martin L. Griss Hewlett Packard Laboratories 1501 Page Mill Road Palo Alto, CA 94303 Tel: (415)857-8715 Fax: (415) 813-3668 Email:griss@hpl.hp.com Abstract This position paper describes the initial ideas of a new project, aimed at developing an Objectory-based Reuse Factory. This work is a research collaboration between Martin Griss and Ivar Jacobson, and several colleagues at HP and Objectory. We are combining the systematic reuse concepts of process, organization and kits, with the OO modeling and methods of Ob jectory's system engineering (OOSE) and business engineering (OOBE). Keywords: OO reuse, process, organization, architecture, methods Workshop Goals: Learning; networking; share and get feedback on initial ideas Working Groups:reuse process models, reuse architecture, domain- engineering 1 Background I have worked since 1988 in the area of systematic software process and technology at Hewlett-Packard, in both HP Corporate Reuse practice and in HP Laboratories research. I have described the evolution of my work at many reuse events: WISR[Gri92, GT93], IWSR[GJK+94], SRR[GJJ+95], SAC94[GW94 ] and OOPSLA[GAB+91 ], as wellas in other publications [Gri93,GW95b , Gri95b,Gri95a,GW95a , GK95a]. During this time Iand several colleagues (primarily Kevin Wentzel,James Navarro, Ruth Malan, Patricia Collins and Danielle Fafchamps) developed the concepts and explored several consequences of domain-specific kits and flexible software factories. Several ideas,such as reuse handbooks, domain-specific kit analysis frameworks and reuse maturity moels, were refined during working groups at WISR. Most recently, I have been exploring the integration of these ideas with OOmethods and technology, leading to a collaboration with Ivar Jacobson, started in Nov 1994[AG94, Gri95b, Gri95a,GJJ+ 95]. I and a sabatical visitor (Bob Kessler, University of Utah) have been applying these ideas to the development of an exemplary instrument systems kit, prototyped using Lego Dacta Control Lab parts[GK95a, GK95b ]. This is used as a test case for the Objectory modeling, and proposed for part of a new reuse-based software engineering course for delivery at the University of Utah. 2 Position Object technology (OT)is believed to be crucial to achieving the long sought after goal of widespread reuse. This goal is the most frequently stated reason for adopting OT. Unfortunately,many people naively equate reuse with objects, expecting it to"automatically" ensure reuse, but often do not get much reuse[Pit93]. Based on our experience with reuse at HP and Objectory, and with our many customers, we think that OT as used today will not succeed in giving users reuse. Without an explicit reuse agenda, and a systematic approach to the design and use of reusable assets, OO reuse will not succeed. In almost all cases of successful reuse, management support, simple architecture, a dedicated component group, a stable domain, standards and organizational support were the keys to success. These largely non-technical issues seem to be more important to successful reuse than the specific language or design methodology chosen. We believe that this architecture/process/organization question can be addressed systematically. Our work is exploring an exciting approach which applies Object-oriented Business Engineering (OOBE) and concepts of BPR to restructure a software development organization to offer reuse at a large scale. To obtain a true systematic OO reuse process, today's OT must be augmented with specific reuse-oriented processes, organizationstructures, guidelines, and training. OO methods must be extended to support domain engineering,with specific architecture and component factoring and clustering steps. Component and framework engineering should include explicit design and implementation guidelines, building on a catalog of architectures, patterns, designs and mechanisms. We need a better understanding of how to produce layered, modular architectures. We need to determine how and when to augment OO application frameworks with problem oriented scripting languages, builders, and systems and component generators to produce domain- specific kits that can handle the complexity inherent in frameworks with large numbers of classes and methods. Our work in progress explores how the principles of systematic reuse[Gri95b] and reuse processes, such as captured in the CFRP[STA93a, STA93b], can be used to augment traditional object-technology. In particular,we have tried to apply OO methods to the description and analysis of organization, process and reuse architecture and technology issues. As our OO method,we use the Use-driven approach of Ivar Jacobson. We useOOBE[JCJO92 ] and OOSE[JEJ94] to link the reuse organization and process with the reusable as sets (architectures, components and frameworks). We have augmented standard Objectory with the concepts of component systems,layered architectures,systems of interacting systemsand component system kits. 2.1 Reuse organization and processes We will use an OOBE model to describe the processes and organizations used in the design and evolution of reuse-oriented organizations. Here, use-cases are used to model the interaction of an actor (person or external organization) with the subject organization. Use-case and domain models (not the domain engineering model) help identify core processes within the organization. When these models are further refined to produce the Objectory robustness model (with interface, control and entity objects), we are able to map these onto processes (control objects),handlers (interface objects) and information systems (entity objects).Factoring and subsystem packaging techniques at the OOBE model allow us to introduce and model organizations. This organizational or business modeling technique is applied in two different ways: Development organization - it is applied to the software development organization to introduce and model reuse processes and organizations. This use is related the Objectory notion of "development cases." Business object extraction- it can also be used as part of the "organizational domain engineering process" applied to some target organization or system,to identify reusable business objects and processes. This could be called a "business-case." For example, we might start with a high-level of a company, and quickly identify software development and process improvement sub- organizations.Looking at the sub-system to subsystem interactions helps us model the roles of people such as reuse engineer,reuse manager, librarian, etc. 2.2 Domain engineering and component systemskits Here we believe strongly in an incremental, architectural, domain- specific approach. We are modifying the robustness analysis phase of the Objectory method to make explicit the commonality and variability required to carry out a systematic, OOdomain engineering. We are most influenced by the ideas of FODA[Kan90], ODM[Sim95] and Gomaa[Gom91 ]. As noted above, the OOBE phase is most like ODM, helping identify business objects. We have also found the need to introduce notation and methods to support application ssystems that are built in a layered or modular way from a combination of concrete and abstract components. Components are sets of models (Objectory thinks of code asyet another model) related to each other by refinement and tracebility links, and encapsulated by interface objects (which we will call "facade objects" or "contract objects",in the style of the pattern community[GHJV94]) based on other Objectory work on systems of interacting systems. We see the need to add some mechanisms for additional parameterization, in order to explicitly capture variability, and not just use the existing "uses" and "extends", via subclassing and aggregation. When a component system is adorned with domain-specific methods, tools, instructions and training, more suited to a special class of handler ( i.e, domain expert rather than s ftware engineer), we call this a "component system kit." 3 Conclusion We are quite excited about how well these ideas fit together, and how easily the concepts of use-case, robustness model and devlopment case can be extended with the OOBE and domain-engineering ideas. This work is still in its earliest phases, but we hope to produce a more detailed report by the end of the summer, and a tutorial for OOPSLA. References [AG94] Eric Aranow and Martin L. Griss. Systematic software reuse. (Tutorial: Object World San Francisco), July 1994. [GAB+91] Martin L. Griss, Sam S.Adams, Howard Baetjer, Jr., Brad J. Cox, and Adele Goldmics of software reuse (panel). In Proceedings of OOPSLA '91,Phoenix, Arizona, 6-11October, pages 264-270, November 1991. (Also as SIGPLAN Notices v26, 1, Nov 1991). [GHJV94] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns - Elements of Reusable Object-Oriented Software. Addison-Wesley Publishing Company, Reading, MASS, 1994. (ISBN 0-201- 63361-2). [GJJ+95]Martin Griss, Ivar Jacobson, Chris Jette,Bob Kessler, and Doug Lea. Panel: Systematic software reuse - objects and frameworks are not enough. In M. Samezadeh, editor, Proceedings of the Symposium on Software Reuse. IEEE, April 1995. [GJK+94] Martin L. Griss, Chris Jette, Voytek Kozaczinski, Robert Troy, and Anthony Wasserman. Panel: Object-oriented reuse. In W. B. Frakes, editor, Proceedings of theThird International Conference on Software Reuse, pages 209-213, Los Alamitos, California, November 1994. IEEE Computer Society Press. [GK95a] Martin L. Griss and Robert R. Kessler. Visual basic does lego. In VBITS '95. Visual Basic Programmers Journal, March 1995. [GK95b] Martin L. Griss and Robert R. Kessler.Visual basic does lego. Technical Report HPL-xx, HP Laboratories, April 1995. [Gom91] Hassan Gomaa. An object-oriented domain analysis and modeling method for software reuse. In Bruce Shriver, editor, Proceedings of the Twenty-Fifth Hawaii International Conference on System Sciences, pages 46-56, Los Alamitos, CA, January 1991. IEEE, Computer Society Press. [Gri92] Martin L. Griss. Amulti-disciplinary software reuse research program. In Martin Griss and Larry Latour, editors, Proceedings of the 5th Annual Workshop on Software Reuse, pages Griss-1:8. Department of Computer Science, University of Maine, November 1992. [Gri93] Martin L. Griss. Software reuse: From library to factory. IBM Systems Journal, 32(4):548-566, November 1993. [Gri95a] Martin L. Griss. Software reuse:A process of getting organized. Object Magazine, May 1995. [Gri95b]Martin L. Griss. Software reuse: Objects and frameworks are not enough. Object Magazine, pages 77-79, February 1995. [GT93] Martin Griss and Will Tracz. Wisr'92: 5th annual workshop on software reuse working groups report.Software Engineering Notes, 18(2):74-85, April 1993. [GW94] Martin L. Griss and Kevin Wentzel. Hybrid domain-specific kits for a flexible software factory. In Proceedings of SAC'94, pages 47-52, New York, New York, March 1994. ACM. [GW95a] Martin L. Griss and Kevin Wentzel. Hybrid domain-specific kits. Journal of Software and Systems, September 1995. (To appear. [GW95b] Martin L. Griss and Marty Wosser. Making reuse work at hewlett-packard. IEEE Software, 12(1):105-107, January 1995. [JCJO92]Ivar Jacobson, Magnis Christerson, PatrikJonsson, and Gunnar Overgaard. Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley Publishing Company, 1992. (Revised 4th printing, 1993). [JEJ94] Ivar Jacobson, Maria Ericsson, and Agneta Jacobson. The Object Advantage - Business Process Reengineering with Object Technology. Addison-Wesley Publishing Company, Menlo Park, CA, 1994. (ISBN 0-201- 42289-1. [Kan90] Kyo C. Kang. Feature-based domain analysis methodology. In L. Latour, editor, Third Annual Workshop: Methods & Tools for Reuse. CASECenter, Syracuse University, University of Maine, June 1990. [Pit93] Matthew Pittman. Lessons learned in managing object-oriented development. IEEE Software, 10(1):43-53, January 1993. [Sim95] Mark A. Simos. Organization domain modelling (odm): Formalizing the core domain modeling life cycle. In Proceedings of the Symposium on Software Reuse, April 1995. (To appear.). [STA93a]STARS. STARSConceptual Framework for Reuse Processes (CFRP): Volume I - Definition. Technical Report STARS-VC-A018/001/00, Paramax, October 1993. (Version 3.0 . See also volume II, applications.). [STA93b]STARS.STARS Conceptual Framework for Reuse Processes (CFRP): Volume II- Application. Technical Report STARS-VC-A018/002/00, Paramax, September1993. (Version 1.0 . See also volume I, definition). 4 Biography Martin L. Griss is a senior Laboratory Scientist at Hewlett-Packard Laboratories, Palo Alto, where he researches object-oriented reuse and measurement system kits. As HP's "reuse rabbi,"he led research on software reuse process, tools and software factories,the creation of an HP Corporate Reuse program,and the systematic introduction of software reuse into HP's divisions. He was past director of the Software Technology Laboratory and has over 20 years in software engineering research. He was previously associate professor of computer science at the University of Utah. He has authored numerous papers and reports on software engineering and reuse, writes a reuse column for the Object Magazine and is active on several reuse program committees. He has given several half-day and full-day tutorials on systematic reuse, and object-oriented reuse. Griss is a frequent invited or keynote speaker at numerous executive level software symposia and workshops, discussing software reuse as a strategic software activity. Enhancing the Use of Domain Analysis Ernesto Guerrieri Digital Equipment Corporation 151 Taylor Street, TAY1-2 Littleton, MA 01460 Tel: 508-952-4341 Fax: 508-952-4197 Email: guerrier@tay1.dec.com Abstract This position paper looks at what can be done to enhance the use of domain analysis. The position taken is that there is a need to standardize the representation of domain knowledge and to provide a mechanism to disseminate this domain knowledge (at least, within the organization that plans to benefit from domain analysis). This paper examines several notations (i.e., Technology Books and Design Patterns) for representing domain knowledge, and the use of the internet and World Wide Web (WWW)for disseminating the domain knowledge. Keywords: Software Reuse, Domain Knowledge, Technology Book, Design Pattern, World Wide Web, WWW, HTML Workshop Goals: Interact/discuss with others on how to institutionalize software reuse; Advance software engineering and reuse technology; Networking. Working Groups: Domain analysis/engineering, Design guidelines for reuse, Tools and environments, Reuse handbook 1 Background Ernesto Guerrieri, while at SofTech, Inc., was the lead designer of the RAPID (Reusable Ada Products for Information systems Development) Library Center (RCL) tool utilized by the RAPID Center. He also co- authored the original domain analysis method utilized within RAPID. He also developed a domain analysis tool for capturing dynamic, multi- dimension classification scheme vocabulary. At Digital Equipment Corporation, he has been involved on several reuse programs as well as investigating the reuse capabilities of the DECADMIRE product,a Rapid Application Development (RAD)environment. Currently, he is looking into how to introduce, unobtrusively, reuse concepts as a normal part of the software engineering processes. 2 Position In order to maximize the benefits of reuse, an organization needs to embrace the concept and methods of domain analysis. This is usually avoided due to the commitment, cost, and effort needed to perform domain analysis. Unless we address these issues, we will continue to narrow the scope of reuse to code and avoid benefiting from domain analysis. How can we address and eliminate these issues? Maybe we can't eliminate them, but, instead, incorporate some of the steps as part of other processes that are being performed currently. Futhermore, there have been technological advancements that have changed how developers do their job. One such area is the information superhighway. Another is the introduction of Design Patterns in the Object-Oriented community. How can these simplify, enhance, or promote the use of domain analysis? The combination of the solutions to the above issues should help enhance the benefits of reuse and the incorporation of reuse as a part of the software engineering processes. 2.1 Where is the domain knowledge? If we look at the people involved in a typical development project, we see that we have brought together, at appropriate times, experts from different areas to cover different facets of the project (such as Graphical User Interface (GUI) designers, testers, database programmers, architects, quality assurance, project planner, etc.). Some of these expertise will be embodied in a single individual (as if wearing multiple hats). This is similar to the situation in house construction where one employs electricians, plumbers, carpenters, brick layers, landscapers,interior decorators, architects, etc. These individuals bring onto the project their tools of their trade, their expertise, their knowledge of their domain. As these people move from project to project,a project gains and looses these expertise unless some of it is captured as part of the project (i.e., the requirement document,the design document, the development or test plan,etc.). What is captured by the project is only an instance (or minute piece) of the expertise of the experts that is relevant or pertinent to the project. On the other hand, these experts draw on their knowledge of their domain in order to provide their expertise on a given project. Consequently, we have: Project Domain Knowledge: This is knowledge about the development project.It may be for a single project or for a family of similar or related development projects. Expertise Domain Knowledge: This is knowledge about a specific expertise required by a development project. Note that this may include project domain knowledge of similar or related projects. Either type of knowledge may be vertical or horizontal depending on the applicability of the knowledge. How can we capture and represent these types of domain knowledge? 2.2 How is the domain knowledge represented? Arango in [1] provides a comparative survey of published domain analysis methods. The survey also provides a common domain analysis process, but it does not explicitly define what is the representation of the domain knowledge (i.e., the output from the process). Is the classification and the data analysis modeling output the only representation of the domain knowledge? What role does the raw data play? What about the filtered, clarified, abstracted, and organized data? What about the similarities and variations among applications and systems and their relevance? Arango describes in [2] the concept of a Technology Book as a means for capturing design information and the domain analysis. The semantic tags for the Technology Book include: ] Issue Definition Assumption Imported constraint Exported constraint Position Design decision Unresolved Result Recently, Patterns has shifted the reuse focus from code reuse to design reuse. Under the realization that "the reason there are reoccuring solutions is because there are reocurring problems. "A pattern is therefore a solution to a problem in a context and are described using a form that points out the solution, problem, and context. In [3], a Design Pattern is a description of communicating objects and classes that are customized to solve a general design problem in a particular context. A design pattern keyword template used in [3] includes the following sections: Also Known As Motivation Applicability Structure Participants Collaborations Consequences Implementation Sample Code Known Uses Related Patterns Coplien in [4] utilizes the following pattern template: Problem: Context: Forces: Solution: Resulting Context: Design Rationale: Whereas, the Portland Form collects and connects pattern paragraphs in a narrative form [5]. Other pattern templates notations exist and can be found at http://st-www.cs.uiuc.edu/users/patterns/patterns.html. Some examples of actual patterns are also available at this URL. These are only a few of the possible representations for domain knowledge. What are the advantages and disadvantages of these different representations? Do they encompass the various aspects of domain knowledge? How can we achieve a common representation of domain knowledge? 2.3 How is the domain knowledge disseminated? Today, a World Wide Web browser (such as Mosaic or Netscape) is a constantly open icon on my workstation and represents a common interface for accessing, among other things, documents and software that resides locally or across the world. The homepage (.html file) represents a set of knowledge (or references to knowledge) that are co-located based on some relationship (i.e., person's interest,subject focus, etc.). The concept of homepage could be used to contain domain knowledge in some structured fashion that can be widely accessible in a read-on ly manner. The technology books currently exist in a computing environment consisting of an object-oriented database, a modeling language, a user interface, and other ancillary tools. Currently, the design patterns exist in publications or in text files accessible over the internet. If we combine such tools with a standardized notation for the domain knowledge, we would be able to disseminate within the organization and facilitate design reuse. Are today's tools sufficient? Do we need to standardize the notation forthe domain knowledge? Can we build on the notations that are being proposed/utilized in communities such as the patterns community? 3 Comparison Other related approaches that may contribute or be relevant to this topic are: The Domain-Specific Kits [6, 7] The 3C Model [8, 9, 10, 11] The Domain-Specifoc Software Architectures (DSSA) [12,13, 14] References [1]G. Arango, "Domain Analysis Methods," in Software Reusability, pp.17-49, London, UK: Ellis Horwood, 1994. [2]G. Arango, E. Schoen, and R. Pettengill, "Design as Evolution and Reuse," in Advances in Software Reuse - Selected Papers from the Second International Workshop on Software Reusability, (Los Alamitos, CA), pp. 9-18, IEEE Computer Society Press, 1993. [3]E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software. Addison Wesley, 1994. [4]J. O. Coplien,"A Development Process Generative Pattern Language,"in Proceedings of PLoP/94 (First Annual Conference on Pattern Languages of Programming),1994. (Also available via www address http://www.research.att.com:80/orgs/ssr/people/cope/Patterns/Process/i ndex. html). [5]P.Group, Portland Pattern Repository Homepage. 1995. (Also available via www address http://c2.com/ppr/index.html). [6]M. L. Griss, "Bus-Based Kits for Reusable Software," in Proceedings of WISR-4, 1991. (Also available via www address ftp://gandalf.umcs.maine.edu/pub/WISR/wisr4/proceedings/ps/griss.ps). [7]M. L. Griss,"Towards Tools and Languages for HybridDomain-Specific Kits," in Proceedings of WISR-6, 1993. (Also available via www address ftp://gandalf.umcs.maine.edu/pub/WISR/wisr6/proceedings/ps/griss.ps). [8]S. Edwards,"The 3C Model of reusable Software Components," in Proceedings of the Third Annual Workshop: Methods and Tools for Reuse, 1990. [9]W. Tracz, "The Three Cons of Software Reuse," in Proceedings of the Third Annual Workshop: Methods and Tools for Reuse, (Syracuse, N.Y.), June 1990. [10]L. Latour and C. Meadow, "Scaling Up the3Cs Model - A Schema for Extensible Generic Architectures," in Proceedings of WISR-4, 1991. (Also available via www address ftp://gandalf.umcs.maine.edu/pub/WISR/wisr4/proceedings/ps/latour.ps ). [11]M. Sitaraman, "A Uniform Treatment of Reusability of Software Engineering Assets," in Proceedings of WISR-5, 1992. (Also available via www address ftp://gandalf.umcs.maine.edu/pub/WISR/wisr5/proceedings/ps/sitarama n.ps). [12]W. Tracz and L. Coglianese, "An outline for a Domain Specific Software Architecture Engineering Process,"in Proceedings of WISR-4, 1991. (Also available via www address ftp://gandalf.umcs.maine.edu/pub/WISR/wisr4/proceedings/ps/tracz.ps) [13]W. Tracz and L. Coglianese, "A CASE for Domain-Specific Software Architectures," in Proceedings of WISR-5, 1992. (Also available via www address ftp://gandalf.umcs.maine.edu/pub/WISR/wisr5/proceedings/ps/tracz.ps) [14]W. Tracz, S. Shafer, and L. Coglianese, "Design Records: A Way to Organize Domain Knowledge," in Proceedings of WISR-6, 1993. (Also available via ftp://gandalf.umcs.maine.edu/pub/WISR/wisr6/proceedings/ps/tracz3.ps ). 4 Biography Ernesto Guerrieri is a principal software engineer at Digital Equipment Corporation. He is the project leader of Digital's ACMSxp transaction pro cessing system and the team leader of Digital's DECADMIRE application development environment. He wasinvolved in Digital's corporate reuse initiatives. He is also an Adjunct Associate Professor in the Software Engineering program at Boston University. He was previously at SofTech, Inc. where he led the development of the RAPID (Reusable Ada Packages for Information system Development) Center Library (RCL). He received a Ph.D. in Electrical, Computer, and Systems Engineering from Rensselaer Polytechnic Institute in 1989. Accelerating Successful Reuse Through the Domain Lifecycle Scott Henninger Department of Computer Science & Engineering 115 Ferguson Hall, CC 0115 University of Nebraska-Lincoln Lincoln, NE 68588-0115 Tel: (402) 472-8394 Fax: (402) 472-7767 Email: scotth@cse.unl.edu Abstract The inability of software reuse to reach its full potential lies partially in the product-centric way in which we view software development. Methods are needed that help us reason about product families and degrees of support that can be offered for problem domains. Domain analysis techniques help, but often far too concerned with creating rules for domain inclusion and exclusion. We have been working on techniques that take a slightly different view of how increasing levels of formality can be provided as a domain matures. We call this process a domain lifecycle in which knowledge evolves from isolated problem solving instances to domain abstractions such as models, guidelines, and checklists, to design environments that automate significant parts of development within the domain. We are developing these techniques through empirical investigations of a software development. Currently we are in the process of demonstrating and refining our ideas by constructing prototypes using case-based technology to create an organizational memory for software development practices in the organization. Keywords: organizational memory, domain analysis, domain-specific software, case-based reasoning Working Groups: Domain analysis/engineering, Tools and environments, Reuse process models 1 Background My involvement in software reuse began with my dissertation which investigated methods for creating and using repositories of reusable components. The major focus of this work was with CodeFinder which supported the process of query construction and using a connectionist-based spreading activation method for retrieval. Empirical work with this system and subsequent involvement with a large development organization convinced me that repository systems are the least of the problems in software reuse. Current research, briefly described in this position paper, is focusing on a process in which organizations can develop domain-oriented reusable environments using case-based technology and domain analysis methods. This work is being both developed and verified through a collaborative effort with industry. 2 Position: An Organizational Learning Approach to Software Development There is a growing consensus that most successful reuse efforts have been achieved using collections of components within well-defined and well-understood domains. Recognizing the importance of domain knowledge to the development process, domain analysis techniques have been designed to systematically identify objects and relationships of a class of systems [2,8]. These techniques have been shown to be useful, but suffer from defining the domain too restrictively, burying important relationships deep in domain taxonomies or rules of inclusion and exclusion, prohibiting flexible identification of domains with common issues. Another issue is that domain analysis methods have been most successfully applied to mature domains. Biggerstaff's rules of three states that unless three real systems have been built in the domain, it is unlikely that the details required for successful reuse can be derived [10]. In many ways this is unfortunate as we are providing the largest degree of support for those problems that require the least amount of support. If the domain is mature, then people with the background and experience for the problem exist, reducing the need for sophisticated support models. A potentially larger return on investment lies in support for problems that have not yet matured, but for which some isolated solutions have been explored. Software development and reuse support is therefore needed for both mature and evolving domains. Our approach is to provide the means to support a domain lifecycle in which appropriate levels of support is provided as a domain matures from a couple of isolated instances to a well-understood domain with well-defined bounds. This process is supported with case-based tools that capture problem solving experiences within an organization to identify specific solutions to problems faced by software developers throughout the development lifecycle. As experiences accumulate, the organization collectively learns about the domains so people can begin to build a culture based on success, avoid duplicate efforts, and avoid repeating mistakes. This defines an organizational learning approach to software development [7] that naturally incorporates reuse into the product and domain lifecycles. Figure 1 depicts how an organizational learning approach to software development supports the domain lifecycle. As frequently encountered problem domains mature from novel problems to repeated problems to a fully mature domain, support is provided in increasing levels of automation. CASE tools supporting the three main steps in the domain lifecycle are identified: ¥ A case-based repository collects experiences from individual projects, tool experiences, and other artifacts generated to support the development infrastructure of the organization. Project experiences and design artifacts are collected through a process of issue management and design rationale that describes the problems that are addressed while creating an application. Tool experiences are how-to advice and descriptions of problems encountered while developers are using a tool to develop software. This provides solutions to organization-specific problems that are not found in manuals. Reusable artifacts can be in the form of procedures for approaching a problem (process models), software modules, specifications, requirement documents, algorithms, designs, test suites, and other items generated in the course of a project. ¥ Domain abstractions are domain-specific models of design problems, including domain models, design guidelines, value-added reusable artifacts, domain-specific handbooks, process models, design checklists, and other forms of knowledge. Domain-specific knowledge is created by a domain analyst refining knowledge contained in the case-based repository into forms that are more generally applicable to problems frequently encountered in the organization. ¥ Domain-specific design environments automate or provide knowledge-based support for the development of systems within a well-established domain. The environments are created by tool designers using accumulated knowledge from the domain models and specific cases and reusable artifacts in the case-based repository.  Figure 1: Organizational Learning Support for the Domain Lifecycle. These steps define increasing levels of automation and support mirroring the maturity of the domains. Problems that have yet to be analyzed are supported by searching for similar problems in a case- based repository of project and tool experiences. The cases will contain information that is specific to the original project and may need work to apply to the current context, but at least there are some prior experiences to help guide design decisions. As activities are repeated, case-based technology is employed to identify recurring development issues and support the process of generalizing from individual cases to domain-specific abstractions such as design guidelines, domain models and other formal structures. Using handbooks, guidelines, and domain models provides a higher level of support as the knowledge has been processed by domain analysts into a form that is applicable to general problems in the domain. As the domain matures, tool designers can use the synthesized knowledge and components to construct design environments that automate design and provide intelligent support for mature domains repeatedly encountered in the organization. 2.1 Support for Formal Domain Analysis While using a case-based approach to software reuse can provide a degree of reusability leverage [6], the main problem is that cases tend to represent isolated problems that need to be adopted from one set of specifics to another. Domain analysis methods are needed to generalize the knowledge into a more widely applicable form. This is precisely where organizational learning comes in. The process of synthesizing similar cases into knowledge that is applicable to a class of problems naturally supports the maturation of domain knowledge. The real issue of domain analysis is to find commonalties among systems to facilitate reusing software or other design artifacts. From this perspective, domain analysis is a process of identifying commonly occurring patterns across a number of development efforts. As patterns emerge, top-down domain analysis methods can be used to formalize the patterns, facilitating domain evolution from the identification of isolated patterns to formally defined domain knowledge. Identifying established patterns of effort reduces the risk of costly domain analysis efforts by ensuring that the cost of analysis can be amortized over many uses. The case-based repository supports this process by allowing users to query the repository to get a comprehensive picture of the issues and approaches used to solve problems in the domain [7]. For example, suppose an organization has a number of projects that have begun to struggle with issues of backup and recovery in a client- server architecture. The analyst begins by querying the system with terms such as ÒbackupÓ and ÒrecoveryÓ, finding characteristics such as ÒAutomatic backupÓ, ÒFile backupÓ, Disaster recoveryÓ, ÒBackup schedulingÓ, ÒUpdate frequencyÓ and others. Given this information, the analyst begins to construct facets [8] to help understand the domain and organize the software artifacts that have accumulated about backup and recovery issues. The repository provides a comprehensive and convenient mechanism for performing the analysis. It is precisely this kind of support for domain analysis that is necessary to provide the kind of reference handbooks that other engineering domain have benefited from. 2.2 Issue Tracking Since we are advocating that the mapping from problems to tools must be dynamically maintained to meet the changing needs of an organization, capturing project experiences is a crucial element of our approach. The system must quickly reach a critical mass of information to become an invaluable part of the design process and maintain that usefulness by evolving with the changing needs of the organization. We are in the process of developing tools to support an issue tracking methodology to monitor major issues and subproblems that arise in the course of the project that may have implications for subsequent projects. By integrating our efforts at the organizational and project levels, we hope to achieve a Òliving design memoryÓ [9] that emphasizes the development of domain knowledge, not just capturing or acquiring what already exists. 2.3 Conclusions and Future Directions Centering the information around a single repository through an ongoing process of capturing project experiences can prevent the duplication of efforts, avoid repeating common mistakes, and help streamline the development process. Similar projects have shown that such a system will be used by development personnel, provided it contains relevant, useful and up-to-date information [9]. A key question that exists for our work as well as work in the areas of domain analysis, design rationale, and organizational memory, is how the process of generating and using repositories of design information can be embedded in the everyday practice of software development so that the repository evolves with the ever-changing goals and accomplishments of the organization [9]. Our approach advocates using the repository to both track project progress and as an information resources to support design and decision making. Much more work is needed to accomplish this goal. We are approaching this problem in a user-centered or participatory design method in which we deploy prototypes to collect feedback and refine our model to fit the organizationÕs needs. Successful deployment of this system will not only help the software development process at UPRR, but will provide a crucial first step toward better understanding the software development process and how it can be improved. 3 Comparison Our work applies techniques from artificial intelligence and human- computer interaction to software engineering problems. In many respects our approach operationalizes the domain analysis prescription to identify reusable information in the problem domain, capture relevant information, and evolve the information to meet current needs [2]. Efforts in the software reuse community, especially experience factories [4] have similar concerns, although the focus is often exclusively on re-using source code. We wish to take a broader view to include any significant development issue. For example, one project at UPRR performed a study of screen ergonomics. While the project was eventually canceled, the screen ergonomics report is highly regarded and has been used by other projects. Our objective is to provide a formalized process by which such artifacts can be identified and disseminated for widespread use. Design rationale techniques, which advocate a process of deliberation in which design decisions are reached by consulting the design issues an alternatives stored in a repository [5], have also had a significant impact on our approach. Our goal will be not only to capture the rationale of why a system was designed a certain way, but also what occurred as a result of the decision, and how future efforts of a similar nature can be improved. The closest efforts to ours have focused on creating corporate repositories, often referred to as organizational memory. Answer Garden [1] was built to capture recurring questions in a central database using a branching network of multiple-choice questions and answers. The Designer Assistant integrated a repository with existing practices in a development organization at AT&T [9]. This strategy not only ensured that Designer Assistant was used, but also that it was modified as part of the development process, allowing it to evolve with changing organization needs. The primary difference is that our approach uses a repository of cases, whereas the Designer Assistant and Answer Garden are structured as an advice-giving systems. Part of the output of a domain analysis could be a structured set of questions leading to a piece of advice, but putting the knowledge in that form is labor-intensive, and it has been noted that some users prefer a more open-ended mode of interaction, especially when users want to find information on a subject area [9]. References [1] Ackerman, M.S., Malone, T.W., ÒAnswer Garden: A tool for growing organizational memoryÓ, Proceedings of the Conference on Office Information Systems, ACM, New York, 1990, pp. 31-39. [2] Arango, G., Domain Analysis: From Art Form to Engineering Discipline, Proceedings Fifth International Workshop on Software Specification and Design, (Pittsburgh, PA), ACM, pp. 152-159, 1989. [3] Arango, G. and Prieto-Diaz, R. Domain Analysis software system modeling, IEEE Computer Society Press, Los Alamos, CA, 1991. [4] Caldiera, G., Basili, V.R., ÒIdentifying and Qualifying Reusable Software ComponentsÓ, Computer, 24(2), Feb. 1991, pp. 61-70. [5] Fischer, G., Lemke, A.C., McCall, R. and Morch, A.ÒMaking Argumentation Serve DesignÓ, Human-Computer Interaction, 6(3-4), 1991, pp. 393-419. [6] Fouque, G., Matwin, S. ÒA Case-Based Approach to Software Reuse,Ó Journal of Intelligent Information Systems, 1, 1993, pp. 165- 197. [7] Henninger, S., Lappala, K., Raghavendran, A., ÒAn Organizational Learning Approach to Domain Analysis,Ó Seventeenth International Conference on Software Engineering (Seattle, WA), ACM, IEEE, Los Alamitos, CA, pp. 95-104, 1995. [8] Prieto-Diaz, R. ÒImplementing Faceted Classification for Software Reuse,Ó Communications of the ACM, 35(5), May 1991. [9] Terveen, L.G., Selfridge, P.G., Long, M.D., ÒÔLiving Design MemoryÕ - Framework, Implementation, Lessons Learned,Ó Human- Computer Interaction, 1995 (in press). [10]Tracz, W. Confessions of a Used Program Salesman: Institutionalizing Software Reuse, Addison Wesley, Reading, MA, 1995. Software Reuse - it's TEA - time! Elke Hochmuller Institut fur Informatik Universitat Klagenfurt Universitatsstr.65-67 A-9020 Klagenfurt, AUSTRIA Tel: ++43463 2700 574 Email: elke@ifi.uni-klu.ac.at Abstract Using CASE environments and utilizing software reuse are seen as promising and mandatory means to enhance software productivity. Unfortunately, with current technology, the combination of software reuse and CASE environments is hardly supported. On the basis of this observation, this position paper presents some criteria which can be useful in evaluation and assessment of tools and environments pretending to support software reuse. Keywords: tool evaluation, reuse process model, institutionalizing reuse Workshop Goals: Networking and exchanging ideas; common problem understanding; learning about reuse experiences in practice. Working Groups: tools and environments, reuse process models, reuse management, organization and economics. [TEA - Tool Evaluation and Assessment] 1 Background Elke Hochmuller is assistant professor at the University of Klagenfurt. She is member of Roland Mittermeir's research group which is particularly concerned with software reuse. Based on the software base approach, she developed the concept for AUGUSTA- a reuse-oriented software engineering environment for the development of Ada applications [1]. Furthermore, her Ph.D. thesis [2] contained some initial thoughts on ideal process models as well as organizational structures of reuse- oriented software developing companies. In [3] E. Hochmuller and R. Mittermeir propose a reuse augmentation to traditional process models requiring only minimal changes to an already implemented and approved software development process (Figure 1). This reuse process model can be considered as a meta model which can be refined according to the particular needs of each enterprise. Furthermore,it is rather independent of the software development process model applied so far. Thus, a software developing enterprise need not change all its approved methods and processes, but only enrich its applied development process together with some inevitable changes inits organizational structure (e.g. software library, software library administrator). The suggested reuse process model consists of two main subprocesses which are linked together in a "ping-pong" manner. The first subprocess deals with the development of reusable components according to development for reuse (DfR). These components are used within the second subprocess which deals with (system) development with reuse (DwR). Figure 1: Reuse Process Model (not in text-only form) 2 Position Software reuse cannot be institutionalized by a very radical change in traditional software development. The integration of software reuse into current organizational as well as process structures should take place smoothly. On the one hand, already approved software process models should not be thrown away but be enriched by planned software reuse. On the other hand,this should also be true for already well known and applied CASE tools. Thus, CASE tool vendors should focus on reuse requirements and adopt their tools accordingly. Hence, without demanding for completeness the following criteria (mainly resulting from the reuse process model previously presented) are proposed to be considered while evaluating tools regarding to their support of reuse. 1.Component Reuse Most CASE tools implement a phase driven, forward looking development model. Software development with reuse, however, is all but that linear. It follows rather a "Yoyo"-approach, where design sketches are followed by delving into the library of reusable components, evaluating some candidate components and then solidifying the high level sketches according to the already available integrable components. On the other hand,one should also consider development for reuse. This has many facets. Be it,that the development of highly generic, off-the-shelf components is promoted, or be it that the isolation of reusable components out of conventionally developed applications is supported. 2.Central Software Library A central software library containing software components of high reuse potential is an essential part of a reuse supporting CASE environment. While a common repository, which is a prerequisite for any integrated software engineering environment, will contain anything which has been produced during a particular development project, this software library should only contain components of approved quality with high potential for interproject reuse. 3.Software Library Administrator The CASE environment should support a new user role for the administration of the software library. This task could be fulfilled by a software library administrator whose competence, however, should exceed pure administrative activities. This person should particularly be responsible for the certification, classification and maintenance of software components. It is expected from a CASE tool to support the software librarian in the relevant activities. 4.Component Certification The inclusion of every software document into the software library without any checks would soon flood the library with components of little potential for reuse. Frustration of users of this library will be the consequence. To cope with this problem, a reuse library should provide clues on qualitative properties of components. The process of component certification could be a single-step activity or a rather sophisticated process depending on the specific situation of the development organization. In any case though,the certification of the candidate components should be supported by the CASE environment. 5.Retrieval Support and Classification Scheme It is required from a reuse supporting CASE environment to provide best automation of both storage and retrieval of components. In order to find specific components contained in the software library quickly and with acceptable effort, the software documents should be classified when they are stored. Therefore, an adequate classification structure is necessary. 6.Adaptation Support In case a software component which is only similar to the desired one could be identified during a search process, a CASE tool is expected to support the process of adaptation of such a component in order to fulfil precisely the specification demanded. While these modifications might encompass functional aspects as well as qualitative aspects, one might also consider those modifications, where the internals of a componentwould be adequate, but modifications have to be made to the interface in order to integrate it into the application under development. 7.Testbeds and Instrumentation Since component descriptions, how formal they ever might be, can naturally not cover all aspects which might be decisive for using a component in a new development project, a reuse supporting CASE tool should provide for testbeds, such that retrieved candidate components can be easily tested in isolation. In special cases,instrumentation of components for testing specific aspects might be desirable. 8.Integration Support After successful retrieval and adaptation of software components, they have to be glued together in order to achieve a complete software system. This integration of components should also be supported by the environment. With this integration support, one has usually to distinguish between prototype development and the more stringent requirements for the integration of production-quality versions. 9.Maintenance Propagation The requirement of maintenance propagation can be viewed from two perspectives: Vertical Maintenance Propagation During its development process a software component passes different stages of representation (from specification document to object code). In addition to the need of storing all these different documents, a reuse supporting CASE tool should provide for automatic update of all the different representations if a particular component is changed. Horizontal Maintenance Propagation A reuse supporting CASE environment should also provide the possibility to establish links between different software components of usually also different kinds of representation. These links should not only support the user in navigating between related components (which would again be another general requirementfor CASE tools) but also enable the propagation of operations applied to a particular software component triggering adequate operations on related components. 10.Reuse Success Evaluation Continuous control of the reuse success can help not only the software library administrator to react in time to reorganize the contents of the library. It also assists potential users, which might build their estimates on the benefit of reusing a particular component on the past "turnover" of this component. Furthermore, management might use such statist cs to reward project personnel for successful reuse or to encourage better reuse by establishing specific reuse incentives. Most necessary data can be easily collected and made available by the tool itself. 3 Comparison A whole bunch of general requirements for CASE tools and environments has been proposed in the literature (e.g. [4]). Full life cycle support, integrated CASE, multiuser and teamwork support, consistency and integrity support,evaluation support, versioning, and management support are only some of the most important criteria in this connection. However,as far as I know there have been no proposals covering specific criteria for CASE environments which focus particularly on reuse aspects in software engineering. The items presented here are far from being complete or detailed enough but are an excellent starting point for further research in this area. Regarding the nature of these requirements,they rather refer to entire CASE environments in the sense of [5] than to single CASE tools. Furthermore, the scope of the evaluation criteria presented here lies beyond thatof evaluation requirements tailored to reuse-specific tools (e.g. the evaluationof SoftKin [6] as a reuse supporting tool detecting similarities at code level). References [1]E. Hochmuller,"Process support for software reuse with AUGUSTA," in Proc. Software Systems in Engineering, (Houston), pp. 173-181, ASME, Jan. 1995. [2]E.Hochmuller, AUGUSTA - eine reuse-orientierte Software- Entwicklungsumgebung zur Erstel-lung von Ada-Applikationen. PhD thesis, Universitat Wien, May 1992. [3]E. Hochmuller and R. Mittermeir, "Improving the software development process by planned software reuse,"in Proc. Re-Technologies for Information Systems (ReTIS '95) (J. Gy|rk|s, M. Krisper, and H. C. Mayr, eds.), (Bled, Slovenia), pp. 27-39, OCG, June 1995. [4]A. duPlessis,"A method for case tool evaluation," Information & Management, vol. 25, pp. 93-102, Aug. 1993. [5]A. W. Brown,"Why evaluating case environments is different from evaluating case tools," in Proc. Third Symposium on Assessment of Quality Software DevelopmentTools (E. Nahouraii, ed.), (Washington, DC), pp. 4-13, IEEE, June 1994. [6]G. W. Hislop, "Evaluating a software reuse tool," in Proc. Third Symposium on Assessment of Quality Software Development Tools (E. Nahouraii, ed.), (Washington, DC), pp. 184-190, IEEE, June 1994. 4 Biography ElkeHochmuller is assistant professor at the Department of Informatics, University of Klagenfurt, Austria. She received her M.S. and Ph.D. degrees from the University of Vienna in 1988 and 1992, respectively. In 1994 she left the University of Klagenfurt for halfa year and developed an enterprise wide data model for an electric power supply company where she became aware of the very intricate managerial, social as well as psychological problems in practice which increased her interest in bridging the gap between research and practice. Her research interests cover various topics in the field of software engineering, particularly software reuse, process modelling, CASE, and requirements engineering. One Architecture Does Not Fit All: Micro-Architecture Is As Important As Macro-Architecture Joseph E. Hollingsworth Department of Computer Science Indiana University Southeast New Albany, IN 47150 Tel: (812)941-2425 Fax: (812) 941-2637 Email: jholly@ius.indiana.edu Bruce W. Weide Department of Computer and Information Science The Ohio State University Columbus, OH 43210 Tel: (614)292-1517 Fax: (614) 292-2911 Email: weide@cis.ohio-state.edu Abstract The field of study recently dubbed "software architecture" should be split into two sub-areas: micro-architecture and macro-architecture. Work to date under the name software architecture has concentrated primarily on macro-architecture. But micro-architecture, a.k.a. software component engineering, is at least of equal concern. Keywords: Component engineering, interface design, interface specification, patterns, software architecture Workshop Goals: Learning, networking, discussing/debating technical issues related to reuse Working Groups: Reuse and formal methods, reuse and OO methods, reusable component certification, design guidelines for reuse, education 1 Background Economists discovered some time ago that one view of economics cannot be made to fit all economic situations. They noticed that different analytical techniques and models were needed when looking at economics-in-the-small as compared to economics-in-the-large [1]. This is not to say that one is more important than the other, or that one deserves more or less attention. It simply admits that the understanding and analysis of these two different classes of economic situations require different approaches in order to capture and reason about their fundamental properties. Software engineers - especially those who subscribe to software component reuse - know that software, like hardware, has (or should have) an orderly arrangement of parts, or an "architecture" [2,3 ,4 ]. To date, most work on software architecture has focused on exploring a high-level view of the ways in which large systems are organized, e.g., domain-specific software architecture (DSSA). 2 Position We contend that software engineers are faced with a situation similar to that faced previously by economists: One view of software architecture cannot be made to fit all situations. Our position is that a useful approach to sort out the issues is to recognize a dichotomy in software architecture like the one in economics - to separate what we wish to call micro-architecture from macro-architecture. As with economics, this recognition does not imply that one kind is more important than the other, or that one deserves more or less attention. It simply admits that the understanding and analysis of qualitatively different software architecture situations require different approaches in order to capture and reason about fundamental properties. 2.1 Macro-Architecturevs. Micro-Architecture Most work in software architecture to date is what we call macro- architecture, because it deals with a high-level view of software systems and not with the detailed structure of the components in those systems, much less their detailed behavior. What comprises (or should comprise) work in micro-architecture? Micro-architecture is not synonymous with programming-in-the-small,i.e., with statement-level issues such as the use of structured programming techniques [5]. It also is not synonymous with what have become known as "design patterns" [6], i.e., with identifying, classifying, and explaining commonly-used program structuring techniques in problem contexts. Like the work on patterns, micro-architecture deals with important issues between the high-level view of software system architecture and low-level coding. But it focuses on the details of both the structure and the behavior of component interfaces and on the implementations of individual components, sets of components, and how they compose and "interoperate" with each other. At the macro-architecture level,a large system might be deemed to follow a general structural style, e.g., "hierarchical layering of abstract data type components". There might be some interesting things that can be concluded about a system by knowing just this much - or perhaps a little more - about it. But there are other interesting things about the system that can be understood only by taking a more careful view of the details, to ascertain precisely what design decisions have made it possible to construct a system with a certain macro-architecture, and to understand why components are interconnectable both structurally and behaviorally. 2.2 Some Issues in Micro-Architecture Micro-architecture,a.k.a. software component engineering, covers many important issues, including but not limited to the following: What are the best ways to achieve component composability and interoperability, i.e., the composition of components with little or no "glue code"? How can a component's structure and behavior be designed so the composition restrictions it places on other components, and vice versa, are likely to be met [7]? What are the best ways to design a component so that certifying that it possesses certain properties can be done just one time, i.e., when it is checked into a component library, instead of each time it is checked out and used in a client program [8, 9]? What are the best ways to achieve plug-compatibility between multiple implementations for the same abstract component, i.e., so that a client program requires little or no modification when unplugging one implementation and plugging in another [10]? What component-related programming language features are needed to best support multiple, different implementations for the same abstract component [11, 12]? What are the best ways to design a component so that client programmers have control over the component's performance, i.e., can easily tune the component with respect to space and time usage, without changing functionality [9]? Given a particular programming language (e.g., Ada, C++, Eiffel, ML) which language features should be aggressively used - and which should be avoided - when designing components to be composable, certifiable, efficient, reusable, tunable, etc.? For example, what are the best ways to use the enticing language mechanism of inheritance [13]? The notion that some language features should be used, while others should not, leads to the conclusion that even an individual software component has architectural characteristics; and that groups of components that are designed to be readily composable with each other share a micro-architecture. Here is a simple example of a very low-level micro-architecture issue. It is well known that one of the easiest mistakes to make during the development of code is to use a variable that has not been initialized. Many compilers try to detect this situation and issue a warning; there also are commercial tools that look for and warn against it (e.g., Purify). But warnings are reactive. Languages such as C++ with its constructor and destructor operations, and Ada95 with initialization and finalization operations [14], permit a component designer to take a proactive approach to this problem. Therefore, part of the micro- architecture of a component (or group of components) in C++, for example, lies in the consistency of use of constructor and destructor operations. 3 Comparison By comparison to previous adhoc work in macro-architecture and micro- architecture,we see at least three comparative advantages to studying software micro-architecture as an explicit question: possible development of new programming language constructs that support a particular micro-architecture; possible component design disciplines that specifically prescribe which features of a particular language to use (and howto use them), and which to avoid, when designing new components under a particular micro-architecture; and possible less-restrictive component design guidelines that convey general approaches to designing components within micro-architectural families. 3.1 New Language Constructs The example in the previous section illustrates how language support can be provided for a micro-architectural solution to the problem ofuninitialized variables. Advances in micro-architecture will lead to the need for other language-supported (or language-enforced) mechanisms that enable the design of high-quality software components [9]. Skeptics who think the ultimate programming language already exists and that further work in this direction is pointless should carefully consider the fine points of debate in the creation ofAda95, an ANSI standard for C++, Object Oriented COBOL, etc. Most of the suggested language changes derive directly from micro-architecture considerations. Similarly,much of the work on specification languages such as Larch, VDM, and Z deals with the need to clearly and unambiguously specify component behavior. No ne of these is the last specification language we will ever need. 3.2 New Component Design Disciplines Programming languages (at least,widely-used ones) tend to evolve slowly and in response to well-understood needs of software engineers. While the community explores micro-architecture issues and develops a clearer understanding of what language support is appropriate for various approaches, there is a need for stopgap measures. Component design disciplines can be prescribed that, when followed, give rise to a specific, unique, and easily identifiable micro-architecture. For example, the RESOLVE/Ada discipline [8] includes 41 principles that very specifically guide the software engineer when designing high-quality Ada components. 3.3 New Design Guidelines Design "guidelines" are less explicit than comprehensive design disciplines. When followed, though, they too can give rise to components that have easily identifiable micro-architectures. Some examples include guidelines suggesting the inclusion of component iterators and how to design them [15,16]; and the idea of recasting algorithms (e.g., sorting) as "machines" (e.g., a sorting machine component) [17]. 3.4 Conclusion To advance the ill-defined but intuitively important field now known as software architecture, we propose that the term be refined so there are two separate but related subfields: micro-architecture and macro- architecture. We base our argument on a convenient analogy with the field of economics, and on the observation that not just large systems but even much smaller-scale software components have their own architectural features. Furthermore, when viewed from this perspective, we see opportunity for micro-architecture research to contribute to the design of future programming languages and the individual reusable components found in common off-the-shelf libraries. References [1]G. Bach, R.Flanagan, J. Howell, L. Ferdinand, and A. Lima, Economics: Analysis, Decision Making, and Policy. Englewood Cliffs, NJ: Prentice-Hall, 1987. [2]D. Garlan and M. Shaw, "An Introduction to Software Architecture," in Advances in Software Engineering and Knowledge Engineering, vol. 1 (V. Ambriola and G. Tortora, eds.), World Scientific,1993. [3]R. Prieto-Diazand G. Arango, Domain Analysis and Software Systems Modeling. IEEE Computer Society Press, 1991. [4]W. Tracz, S. Shafer, and L. Coglianese, "Design Records: A Way to Organize Domain Knowledge," in Proceedings 6th Annual Workshop on Software Reuse, (Owego, NY), 1993. [5]F. deRemer and H. Kron, "Programming-in-the-Large vs. Programming- in-the-Small," IEEE Transactions on Software Engineering, vol. SE-2, pp. 80-86, June 1976. [6]E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison- Wesley,1995. [7]S. Edwards,"Common Interface Models for Reusable Software," International Journal of SoftwareEngineering and Knowledge Engineering, vol. 3, pp. 193-206,June 1993. [8]J. Hollingsworth, "Software Component Design-for-Reuse: ALanguage Independent Discipline Applied to Ada," Tech. Rep. OSU-CISRC-1/93- TR01, The Ohio State University, Columbus, OH,1992. [9]M. Sitaraman and B. Weide, "Special Feature: Component-Based Software Using RESOLVE," Software Engineering Notes, vol. 19, pp. 21-67, October 1994. [10]S. Edwards,"An Approach for Constructing Reusable Software Components in Ada," Tech. Rep. IDA Paper P-2378, Institute for Defense Analyses, Alexandria, VA, 1990. [11]M. Sitaraman,"A Class of Programming Language Mechanisms to Facilitate Multiple Implementations of the Same Specification," in Proceedings 1992 International Conference on Computer Languages, pp. 272-281, IEEE Computer Society, April 1992. [12]D. Dori and E.Tatcher, "Selective Multiple Inheritance," IEEE Software, vol. 11, pp. 77-85, May, 1994. [13]D. de Champeaux, D.Lea, and P. Faure, Object-Oriented System Development. Reading, MA: Addison-Wesley, 1993. [14]Ada95 Reference Manual (version 6.0) and Ada95 Rationale. Cambridge, MA: Intermetrics, Inc.,1995. [15]G. Booch, Software Components with Ada. Menlo Park, CA:Benjamin/Cummings, 1983. [16]B. Weide, S. Edwards, D. Harms, and D. Lamb, "Design and Specification of Iterators Using the Swapping Paradigm," IEEE Transactions on Software Engineering, vol. 20, pp. 631-643, August1994. [17]B. Weide, W. Ogden, and M. Sitaraman, "Recasting Algorithms to Encourage Reuse," IEEE Software, vol. 11, pp. 80-88, September 1994. 4 Biography Joseph E. Hollingsworth is Assistant Professor of Computer Science at Indiana University Southeast. He holds a B.S. from Indiana University and an M.S. from Purdue University, and he earned his Ph.D. in Computer and Information Science in 1992 from The Ohio State University. Professor Hollingsworth also has substantial industrial software engineering experience: at Texas Instruments working on a command and control expert system for the Navy Commander and Chief of the Pacific Fleet, 1984 to 1986; at Battelle Memorial Institute working on software maintenance of the Air Force's Mission Planning System (MSS-II), 1991 to 1992; and through Hollingsworth Solutions, developing and marketing a number of PC-based and Mac-based software packages,1987 to present. His latest product is a PC Windows application developed using the RESOLVE/C++ discipline. Bruce W. Weide is Associate Professor of Computer and Information Science at The Ohio State University in Columbus. He received his B.S.E.E. degree from the University of Toledo and the Ph.D. in Computer Science from Carnegie Mellon University. He has been at Ohio State since 1978. Professor Weide's research interests include various aspects of reusable software components and software engineering in general: software design, formal specification and verification, data structures and algorithms, and programming language issues. He is co-director of the Reusable Software Research Group at OSU, which is responsible for the RESOLVE discipline and language for component-based software. For more information see the URL http://www.cis.ohio-state.edu/hypertext/rsrg/. Professor Weide gratefully acknowledges financial support from the National Science Foundation (grant number CCR-9311702) and the Advanced Research Projects Agency (contract number F30602-93-C-0243, monitored by the USAFMateriel Command, Rome Laboratories, ARPA order number A714). A Domain Framework: A Basis for Enhancing Reuse Among Domains1 Anh D. Ta The MITRE Corporation 7525 Colshire Drive, MS-W624 McLean, VA 22102-3481 Tel: (703) 883-7467 Fax: (703) 883-1339 Email: ata@mitre.org Duane W. Hybertson The MITRE Corporation 7525 Colshire Drive, MS-W624 McLean, VA 22102-3481 Tel: (703) 883-7079 Fax: (703) 883-1339 Email: dhyberts@mitre.org Abstract The software engineering discipline has matured to the point where the notion that every new software system has substantially unique requirements and therefore a unique solution is giving way to the understanding that software systems within application areas (or domains) have much in common, and that this commonality can be exploited. This perspective is the motivation for domain-specific reuse (e.g., domain analysis). But experience in applying domain analysis indicates that defining and scoping a domain for analysis in many cases is not straightforward. Furthermore, there are variations in focus, terminology, types of models, and representations among the various methods. It is also useful to distinguish among types of domains such as application domains and software technology domains. The DoD is interested in a solution that can help define DoD domains in a way that will identify software commonality across existing domains and reduce arbitrary duplication. For these reasons, a domain framework is proposed that is intended to help characterize domains and product lines by tapping directly into existing informal but extensive domain knowledge to identify reuse opportunities. Initially, the framework will consist of a preliminary set of definitions and factors for identifying and scoping domains as a common front end to domain analysis. Keywords: domain-specific reuse, domain analysis methods, domain framework, product line Workshop Goals: Advocate importance of concept of domain framework; obtain feedback on preliminary domain framework Working Groups: Domain analysis/engineering; Reuse terminology standards; Reuse handbook 1 Background The authors have been involved in software reuse projects for the past several years. A primary area of work has been supporting the Department of Defense (DoD) Software Reuse Initiative (SRI). Recent projects include the DoD SRI Technology Roadmap [2], which is a two- volume document that identifies critical technologies enabling reuse and describes an implementation strategy for DoD investment in immature technologies. Current tasks in support of DoD SRI include the development of a domain framework that is the subject of this paper. Other current reuse work includes a domain definition/analysis task for the Navy. 2 Position The position of this paper is that a domain framework is both needed and feasible right now. The two subsections that follow present the need and a proposed solution, respectively. 2.1 Problem Context and Dimensions The software engineering discipline has matured to the point where the notion that every new software system has substantially unique requirements and therefore a unique solution is giving way to the understanding that software systems within application areas (or domains) have much in common, and that this commonality can be exploited [1; 8]. This understanding has shifted the focus of software reuse to domain-specific approaches. There are now multiple domain analysis / engineering methods available (see [1] and [8]). Various government R&D programs such as ARPA's Domain-Specific Software Architectures (DSSA) [3] and STARS demonstration projects [11], [12], and [13] have been in progress for several years. In addition, the integration of the domain-specific reuse approach into software system development is being realized through several proposed reuse-driven processes. Currently, the two life-cycle reuse process, consisting of Domain Engineering and Application Engineering (e.g., see [2] or [10]), is emerging as the preferred process. Experience in applying domain analysis indicates that defining and scoping a domain for analysis in many cases is not straightforward. The scope of a domain or product line is often determined more by the feasible scope of analysis (e.g., organization resources available) than by the scope of an existing body of knowledge [14]. Up front decisions that are made on selecting and bounding a domain can significantly affect the success of the domain analysis effort and the return on investment, yet the criteria for making these decisions are not uniform across the methods and in some cases are addressed only minimally. There are many questions and issues that need to be addressed in terms of the breadth and the maturity of a domain, such as: ¥ A domain can be so ÒwideÓ that it is not homogeneous (i.e., it has multiple models and architectures) or there are not enough resources within an organization to analyze it ¥ A domain can be so ÒnarrowÓ that it does not have a critical mass of problems to solve (i.e., leverage) ¥ A domain can be so volatile that it is not ready for abstractions such as domain models and architectures to be attempted ¥ A domain can be "inactive" in the sense that there is no market for a domain model or architecture because no future systems are planned or required. Furthermore, there are variations in focus, terminology, types of models, and representations among the various methods. Hence, there is a need for a common basis in capturing and conveying domain information such that it can be used by all stakeholders. What is needed is the following: 1. A common basis that provides a Òlevel playing fieldÓ for identifying and characterizing domains independent of domain analysis methods 2. A set of domain identification and scoping criteria or factors and usage guidelines to apply the factors to selected domains 3. An inexpensive way to obtain information on reuse potential of domains, based on available data, to help decide where and when to invest in domain analysis 4. A way to obtain information on reuse potential of domains within an organization or enterprise to help define product lines (or families of systems) 5. Criteria for decomposing large domains into appropriate constituent domains for analysis and acquisition support 6. Assistance in finding commonality across multiple domains, to help minimize overlaps and reduce acquisition cost 2.2 Ideas for a Domain Framework as a Solution Given the objectives stated above, the proposed solution must possess the following attributes: (1) be comprehensive in capturing different perspectives of domains (i.e., degree of generality), (2) capture common terms or relations among related terms (i.e., unifying concepts), and (3) be method independent (i.e., usable with multiple domain analysis methods). The DoD is interested in a solution that can help define DoD domains in a way that will identify software commonality across existing domains and reduce arbitrary duplication. MITRE is supporting the DoD Software Reuse Initiative in developing a domain framework intended to satisfy the objectives stated above. Because of the number and variety of DoD domains, this framework is expected to have applicability beyond DoD to the software community in general. The proposed domain framework will initially consist of two major components: common definitions of domain-related terms, and domain identification and scoping factors. Usage guidelines are also being developed for the proposed framework to illustrate its application for the purposes defined above. A snapshot of the initial two components is given below. 2.2.1 Common Definitions In recognizing that various domain analysis methods (with their own terms and interpretations) will be used in more detailed analysis of domains, this component of the framework will emphasize capturing common terms and overlap among terms defined as part of existing methods. Eventually, this component is intended to function as a meta-domain dictionary containing definitions of terms and usage context. Preliminary sources for this effort include [1], [8], and [14], which discuss domain analysis concepts and common themes, and [6] and [7], which define reuse terms. Key definitions include the following: Domain: A distinct functional area that can be supported by a class of software systems with similar requirements and capabilities. A domain may exist before there are software systems to support it. [6] Domain Boundary: A frame of reference for the analysis (i.e., the set of constraints that representing what is part of the analysis and what is outside the analysis). The domain boundary may change as more knowledge about the domain is gathered. [9p37] Product Line: A collection of (existing and potential) products that address a designated business area. [10] 2.2.2 Domain Identification and Scoping Factors Before initiating a domain analysis effort there exists a notion of a domain of interest representing some broad area (e.g., acoustic signal processing). Then, as part of the initial activity of a domain analysis effort the scope of the analysis is defined by considering the context of the domain of interest and the available resources. This transition in focus suggests that the proposed framework should contain factors that contribute to developing a profile of the domain of interest and factors that contribute to the decision on the scope of analysis. Also, since the software context is defined within the system context, the proposed framework should contain both system-level and software- level factors that play a role in defining a domain boundary. Given NeighborÕs description of domain analysis as being similar to systems analysis except that the scope of the analysis involves a set of systems within an application area versus a single system [5], successful techniques in bounding a problem space for system analysis should be adopted for bounding a domain. Hence, the category of constraints for system analysis should be incorporated into the proposed framework and refined for the perspectives of domain. Profile factors are intended to describe the domain itself and the dominant characteristics that distinguish systems (and supporting software) in the domain from systems not in the domain. Decision factors reflect the feasibility and potential benefit for an organization or enterprise to analyze a domain. Both of these groups of factors can potentially be used to characterize a domain or product line not only as it currently exists but as it might exist in the future - for example, the evolution of a domain or the characteristics of a proposed product line. Table 1 shows a proposed set of framework factors organized into these two groups (Domain Profile and Decision Support) and gives example values or elements of each factor.2 2.2.3 Usage Guidelines The usage guidelines for the proposed framework are currently being developed, but some discussion of the targeted usage contexts for the proposed framework can be given. Although the proposed domain framework can be used with any reuse-driven process model, the general context of the two life-cycle reuse-driven process model is assumed. The target audience for the framework comprises two categories of people: indirect users and direct users. Indirect users include DoD executives (e.g., Program Executive Officers (PEOs) and Program Managers) who make decisions on where to invest resources to increase reuse and efficiency. Direct users include technical personnel who will apply the framework to scope domains, determine reuse potential, characterize and compare domains, find commonality across domains, and use this collected information to support the DoD executives and managers in making their decisions. Example: In the context of software reuse, one objective for a PEO is to identify commonality areas among the acquisition efforts under his/her management and among areas of responsibility of other PEOs so as to minimize overlap and maximize benefits within the allocated resources. The framework and usage guidelines can be used to identify the boundaries of multiple domains at the PEO level while minimizing overlap. 3 Comparison Several domain analysis methods address some of the framework issues in a "domain characterization" process [1]. However, our work differs in the sense that we are attempting to capture what is common among the methods and to extend this to concepts such as characterizing types of domains. Thus, our work complements domain analysis methods. Table 1. Description of Identification and Scoping Factors Profile Factor Description Elements Domain Identity High-level or defining characteristics of the domain, and location in domain hierarchy ¥ Definition (name, primary terms defined, boundary) ¥ Relations/context (hierarchical, historical) ¥ Type (application domain, software technology domain) Functional System Requirements Dominant functions or features of systems in the domain ¥ Functions, features, objects, data, performance, interfaces System Characteristics Dominant subsystems, characteristics, constraints, and nonfunctional requirements of systems in the domain ¥ Quality (reliability, etc.), design constraints, organizational boundaries, physical boundaries, security classifications, domain technology, domain standards, system architectures Software Characteristics Dominant characteristics of software subsystems that support the domain ¥ Software architectures (types, DSSAs), languages, software technology, software standards System Deployment Where systems in the domain are deployed ¥ Airborne, ground-based, sea-based, transportable Decision Factor Description Elements Domain Assessment Extent to which existing domain knowledge and experience, software assets, homogeneity, and maturity provide reuse opportunities ¥ Existence and availability of expertise in organization, availability of existing software, quality of existing software assets, extent of similarity of systems ¥ Domain maturity Market Assessment Potential for making profitable use of domain knowledge ¥ Product expectation (expected new development or acquisition, major upgrades reengineering, consolidation/migration) ¥ Market expectation (current market share, expected market growth, expected return on reuse investment) Resource Constraints Organization or enterprise limits on extent of analysis and engineering possible ¥ Investment capital, schedule constraints, size of available staff (knowledge engineers, domain analysts) References [1] Arango, G., 1994, ÒDomain Analysis Methods,Ó in W. Schafer, R. Prieto-Diaz, and M Matsumoto (eds.), Software Reusability, Ellis Horwood, Chichester, England. [2] DoD Software Reuse Initiative, 30 March 1995, DoD Software Reuse Initiative Technology Roadmap; Version 2.2, Defense Information Systems Agency, Falls Church, VA. [3] Hayes-Roth, Frederick, 20 October 1994, Architecture-Based Acquisition and Development of Software: Guidelines and Recommendations from the ARPA Domain-Specific Software Architecture (DSSA) Program, Teknowledge Federal Systems (TFS), Teknowledge Corporation. [4] Meyer, M., and J. Utterback, Spring 1993, ÒThe Product Family and Dynamics of Core Capability,Ó Sloan Management Review, Spring 1993, pp. 29-47. [5] Neighbors, James M., 1980, Software Construction Using Components, Ph.D. dissertation, Department of Information and Computer Science, University of California, Irvine, CA, Technical Report TR-160. [6] Katz, S., C. Dabrowski, K. Miles, and M. Law, December 1994, Glossary of Software Reuse Terms, National Institute of Standards and Technology, Gaithersburg, MD. [7] Peterson, A. Spencer, April 1991, ÒComing to Terms with Software Reuse Terminology: A Model-Based Approach,Ó ACM SIGSOFT Software Engineering Notes, Vol. 16, No. 2, pp. 45-51. [8] Prieto-D’az, R. and G. Arango (eds.), Domain Analysis and Software Systems Modeling, IEEE Computer Society Press, Los Alamitos, CA, [9] Prieto-Diaz, Ruben, 26 July 1991, Reuse Library Process Model, Report No. 03041-002, Software Technology for Adaptable, Reliable Systems (STARS) Program. [10]Software Productivity Consortium, November 1993, Reuse-Driven Software Processes Guidebook, SPCÐ92019ÐCMC, Version 02.00.03, Software Productivity Consortium, Herndon, VA. [11]STARS, 25 August 1994, Experience Reports: The Navy/STARS Demonstration Project, Software Technology for Adaptable, Reliable Systems (STARS), CDRL Number A017R. [12]STARS, 24 February 1995, Army STARS Demonstration Project Experience Report, Software Technology for Adaptable, Reliable Systems (STARS), CDRL Number A011R. [13]STARS, 8 March 1995, Space Command and Control Architectural Infrastructure (SCAI) Air Force/STARS Demonstration Project Experience Report., Version 2.1, Software Technology for Adaptable, Reliable Systems (STARS), CDRL Number A011-002U. [14]Wartik, S., and R. Prieto-D’az, October 1992, ÒCriteria for Comparing Reuse-Oriented Domain Analysis Approaches,Ó Int. Journal of Software Engineering and Knowledge Engineering, Vol. 2, No. 3, pp. 403Ð431. Bibliography Anh Ta is a Lead Scientist in the Software Engineering Center at the MITRE Corporation in McLean, Virginia. Since joining MITRE he has been providing acquisition support to various command centers within the DoD and participated in research efforts relating to software reuse, safety-critical software, object-oriented technology, and COTS integration. He was previously a member of the technical staff at the Software Productivity Consortium involved in the prototyping of reuse environments for the Synthesis method. Prior to that, he worked as a software engineer at SofTech, Inc. and Honeywell Electro-Optics Division. He received a B.S. in Computer and Electronics Engineering in 1986 and a M.S. in Systems Engineering in 1990, both from George Mason University. He is currently pursuing a doctorate in Information Technology at George Mason University with special emphasis on approaches for developing and evolving domain models. Duane Hybertson is a Member of the Technical Staff in the Software Engineering Center at the MITRE Corporation in McLean, Virginia. Since joining MITRE he has been investigating software reuse technology for the Department of Defense and software safety standards for the Nuclear Regulatory Commission. He was previously a senior engineer with Lockheed on the Space Station Freedom Software Support Environment. Prior to that, he investigated the synthesis approach to reuse at the Software Productivity Consortium, where he had a two-year appointment. He received the B.A. in Mathematics from Northwest Nazarene College in 1970, the Ph.D. in Educational Research Methods from New Mexico State University in 1974, and the M.S. in Computer Science from the Johns Hopkins University in 1985. 1 This paper is based on work sponsored by the Defense Information Systems Agency (DISA) Software Reuse Initiative (SRI) Program. 2 These factors are based on an initial set of factors provided by Don Reifer, Program Manager of the DoD Software Reuse Initative (SRI). Support for systematic reuse Pertti Jauhiainen Ellemtel Telecommunication Systems Laboratories Box 1505 S-125 25 [lvsj| Sweden Tel: +46 8 727 4106 Email: Pertti.Jauhiainen@eua.ericsson.se Abstract This position paper describes a surveyof the mechanisms which we at Ellemtel Telecommunications Systems Laboratories try to integrate to support systematic reuse in the development of telecommunication systems. Reuse is approached from three different views, the system technology and techniques, the development processes and the organization point of view. The organizational structure focus on both support for development for and with reuse, where the needed roles and their responsibilities are defined to accomplish the benefits of systematic reuse. Keywords: Systematic reuse, development processes Workshop Goals: Learning, networking Working Groups: Reuse process models, Reuse management, Reuse technology standards 1 Background The implementation of systematic reuse at Ellemtel aims at supporting in solving the forecasting problems in the development of telecommunication systems. This through the creation of reusable software and hardware components on different abstraction and implementation levels, i.e. to support modularity and adaptability of the products during development and delivery. The systematic reuse influences the organization, system development process, and the basic system technology of the development organization. 2 Position The goal is to create a reuse environment where the development and maintenance of the system parts can be done by only a fraction of resources in relation to the total effort required to redevelop designs in a system product. This kind of systematic reuse is challenging and takes time and effort to introduce in a high technology environment as a telecommunication development organization, but it is important to have a vision, and a step-wise strategy to fulfil the vision. We have defined three main areas which must cooperate to achieve efficient support of reuse, system technology, development processes and organizational structure. Typical examples on system technology are for example system architecture, system structure, use of (standardized) interface techniques and object-oriented languages. You could say that the system technology defines the range of candidates of reusable components. The development process describes how reuse is performed during the system development. The support and management of development and the use of reusable components is integrated to be a natural part of the system development. An organizational structure is created where roles and responsibilities are defined with respect to the duties of project, product and system management, this to efficiently control the development and use of reusable components. 2.1 System Development Process In the system development a combination of standard development paradigms and methods are used, e.g. object-orientation, with guidelines and tools tightly coupled to Ericsson's AXE platform. The purpose of the development process is to: Collect and make visible, but also reusable, experience and knowledge in building telecommunication systems, Show the correct way to use the AXE platform, Provide a common language for communication between designers, Provide a measurable process that supports continuous improvements. The development process or processes, depending of the type of applications (e.g. telecommunication systems or support systems), are built according to a common architecture and using a common framework. All descriptions are modular and can be extended and adapted to new situations,i.e. the processes are built to be reusable. The development process provides a consistent chain of models that are created and refined during a development project. The system development process is based on such a sequence of models that describe the successive refinement of requirements into hardware or executable code. The possible form of the information created during the development of an application is defined by a information model. The concepts defined in the information model for the support of explicit reusable software components are, Source Code Component, which has the purpose to encapsulate source code information that can be used in different software items. Object Model Component, which has the purpose to encapsulate model and specification information for a group of object types. The software components have an interface part and a body part, where the different parts can be managed separately in different libraries. Two aspects of reuse are covered in the system development process, The development for reuse, i.e. reusable component development, The development with reuse, i.e use of components during the system development. In the development of reusable components the main phases cover domain analysis ,specification of general architectural component requirements (frameworks), design and certification, and support and maintenance of components. The management of reusable components as defined in the information model for the system development process is integrated in the general product and design information management systems, i.e. the components are treated as product and design information in general. A crucial step to support reuse in the information management system is to allow for a flexible implementation of the structure of the information in general, i.e. to give possibilities to structure the information according the actual product ordesign needs. A number of formalisms is used to represent the different process models.In general, standardized formalisms support reuse by giving the actors in the development process a common language to describe requirements and implementations, which then give more easily possibilities to create components that are more understandable and then also more reusable. The language and tool for conceptual modelling and behaviour specification at the analysis level in the development process is used for describing, analysing, specifying, and validating functional requirements. Tools used are for example Delphi and Objectory for early phases of system development, DELOS interface description language for design levels, and C++ for implementation level. 2.2 Organization The implementation of reuse in the organization include, definition of an organizational structure, i.e. to implement development for and with reuse, description of roles in the different organizational units in the company, the responsibilities on those roles, support to fulfill the responsibilities. i.e. integration in the development process roles. The roles identified support both the development for reuse (component development) and the development with reuse (system development), i.e. the roles need to support responsibility from a development and support view. The roles and responsibilities for reuse activities need to be divided between line management, product and system management. 3 Biography Pertti Jauhiainen works at Ellemtel Telecommunication Systems Laboratories in Stockholm, Sweden, a company which developes system platforms for telecommunication. He works at the department for system development support systems and is responsible for implementing support for reuse in the system development process. He has also been project manager for Ericsson Telecom AB in the European Commision RACE projects ARISE (A Reusable Infrastructure for Software Engineering) and SCORE (Service Creation in an Object-oriented Reuse Environment). Earlier he worked at Epitec, Inc.in Framingham, Mass. in U.S.Aand Epitec AB in Link|ping, Sweden with expert systems technology. He received a M.Sc in Computer Science from the University of Link|ping, Sweden in 1986. Why Doesn't the Reuse Community Talk About Reusable Software? Ralph E. Johnson University of Illinois Department of Computer Science Tel: (217)244-0093 Email: johnson@cs.uiuc.edu WWW: http://st-www.cs.uiuc.edu/users/johnson/ Abstract The reuse community spends too much time talking about reusable software in general and too little time talking about reusable software in particular. We need to study and compare the designs of particular reusable systems so that we can improve them (and so make reuse more valuable) and so that we can learn the principles of reuse. Workshop Goals: Learning; Finding kindred spirits. Working Groups: Domain analysis/engineering; Reuse and OOmethods and technology; Reuse handbook; Reusable architectures for business software. 1 Background I've been working with OO technology for 10 years, trying to see how objects change the way we develop software, especially how it impacts software reuse. I quickly noticed that reuse of code and small components was not what was important, but instead reuse of design in the form of larger components called frameworks. A framework is a reusable design expressed as a set of abstract classes and the way that instances of these classes interact. In one sense, the most important thing about a framework is the interfaces that it defines. Because a framework is made up of classes that can be represented in programming languages, it is reusable code. But it tells you how to decompose your program into objects, and in that sense is a design. Moreover, most of the code reuse comes not from inheriting from the abstract classes but from reusing concrete classes from a class library. The concrete classes reuse the standard interfaces defined by the framework, so they can be mixed and matched. Most of the reuse comes from being able to mix and match components, not from being able to define a new component using inheritance. I've worked on a number of frameworks, including the frameworks that come with Smalltalk-80 (VisualWorks), a framework for drawing editors called HotDraw, a framework for operating systems called Choices, a framework for code optimization and code generation, a framework for music synthesis,and a framework for accounting. While none of them have had large numbers of users (HotDraw probably has the most users, and that is probably 50-100), most of them have had a few users outside of my research group. Recently I have been working on documenting the software patterns that expert designers use. Not surprisingly, I have focused on the patterns that OO designers use to make software more reusable. 2 Position One of the distinguishing characteristics of computer people is the tendency to go meta at the slightest provocation. Instead of writing programs, we want to invent programming languages. Instead of inventing programming languages, we want to create systems for specifying programming languages. Instead of analyzing domains, we want to make methods for domain analysis. And instead of writing reusable software, or reusing software, we want to write about the principles of software reuse. There are many good reasons for this tendency, since a good theory makes it a lot easier to solve particular instances of the problem. But if you try to build a theory without having enough experience with the problem,you are unlikely to find a good solution. Moreover, most of the time spent building reusable software is on issues that are particular to the problem that the software is supposed to solve, not on generic reusability issues. We are in danger of attacking secondary problems and ignoring the most important ones. The software community has developed standard architectures for some kinds of software, such as compilers, operating systems, and user interfaces. Not surprisingly, these are the kinds of software for which we have the best reusable software; parser generators and table-driven code generators for compilers, and GUI frameworks and screen painters for user interfaces. But there are a lot more people building accounting systems or manufacturing systems than building compilers, and we have tended to ignore applications software, even though that is the most financially important kind. Although there are reuse success stories among this kind of software, I believe we are only seeing a fraction of what is possible. Whenever a standard architecture has developed in the past, it has been developed in a context of a community that can bring many perspectives to bear on it. The practitioners are from companies that are trying to build commercial software. Researchers are investigating narrow problems within the domain of the architecture. Textbook writers are trying to organize and systematize the material. Why hasn't this happened with accounting software or manufacturing software? One possible reason is that companies are afraid of losing trade secrets. But that reason didn't keep the system software venders from participating in conferences on compilers or operating systems. I think a more important reason is that reseachers have ignored these topics. If the researchers were holding exciting conferences on these topics,practitioners would come to find out what was going on, and they would figure out how to make the researchers want to talk to them. But without all the members of the community, it is much harder to make progress. What can practitioners do to attract the attention of researchers? One obvious technique is to support their research financially. Another is to helpconferences on the domain of interest get off the ground. When organizations have their own research department, practitioners can try to get some of the researchers interested in their problems. Regardless of which methods are used, changing other people's behavior is always hard. Is it worth trying to organize groups of people working on particular kinds of software? I think this is the only way to make good reusable designs. To be reusable,software has to be reused in many contexts, and there are very few companies that have the resources to do it. It can be difficult breaking though the parochialism that effects so many companies, but I think it is important if we are going to achieve our goals for reuse. 3 Biography Ralph Johnson is on the faculty of the Department of Computer Science at the University of Illinois. He was program chair of OOPSLA'93, and is a coathor of "Design Patterns: Elements of Reusable Object-Oriented Software" with Erich Gamma, Richard Helm and John Vlissides. Putting Reuse in its Place 10X Cycle Time Reduction Plan Rebecca L. Joos, Ph.D. Motorola 1501 W. Shure Drive Arlington Heights, Illinois 60004 Tel: (708)632-6904 Email: joos@cig.mot.com Abstract After several years of external benchmarking and internal pilots, the Motorola Cellular Infrastructure Group (CIG) has come to the conclusion that the greatest benefit of reuse is cycle time reduction. With Motorola's new campaign for 10X cycle time reduction,reuse has become the shining hope. We have two parallel activities, PDEand SCE, that have reuse as a common thread. PDE is a development environment for CIG's engineers whereas SCEis a development environment for CIG's customers. In the PDE activity reuse is one of fours key enablers (process ,architecture, tools, and reuse). In the SCE activity reuse is the primary enabler. Keywords: reuse, service creation environments, service independent building block, process Workshop Goals: learning, networking, advance state of theory and practice of reuse Working Groups: reuse process models, domain analysis/engineering , architectures 1 Background Becky has been working on software reuse since she finished her dissertation, "A Software Development Environment to Use and Create Reusable Building Blocks." She has campaigned for reuse in Motorola with training seminars, courses, and pilots. Her current work deals with performing domain analysis and building reusable cellular service structures. 2 Position 2.1 PDE We realize that reuse like other things is not the silver bullet but just one of the techniques that we will use to produce better products faster. Reuse must be combined with process, tools and product structure to achieve significant gains in productivity. With this understanding the PDE (Product Development Environment) team was established to create an environment that supports all these areas and is building a model similar to the megaprogramming and reuse model described by Solderitsch and Wickman []. The mission of the PDE activity is to achieve superior world-wide customer satisfaction by instituting a product development environment to successfully achieve 10X cycle time and improvement goals. The PDE team is focusing on 4 key areas: process, architecture, tools, and reuse. 2.1.1 Process CIG has experienced a continuous process improvement from the recognition of process to formally assessed at SEI Level 3. A tremendous organizational growth has also ensued (approximately 2500 software engineers across multiple locations). The team's goal is to make the organization Best in Class for software processes by continuing to provide evolutionary process improvement and introducing revolutionary improvement where needed. 2.1.2 Architecture Initial work will be concentrated in the vertical domain of cellular switching. External to CIG, the Motorola communication sectors are looking at horizontal domain structures. The goal is to create a common software (core) platform that enables rapid development and extensibility. 2.1.3 Tools To reap the real benefits of reuse and achieve 10X cycle time reduction, a tool set is needed to support product design and development. The goal of this group is to provide an integrated process-centered software engineering environment supporting all phases of the software lifecycle. 2.1.4 Reuse This reuse group's goal is to institute systemic architecture-centric reuse within CIGand support reuse efforts external to the organization. The reuse team is composed of members from each of the CIG development groups. They are responsible for developing the reuse processes, procedure, techniques and transferring them into their group. 2.1.5 Process The reuse processes are one aspect of the overall development process mentioned in section 2.1. The group is concerned with what to do to institute reuse, as well as techniques on how to create and use reusable software assets. These procedures and activitieswill be incorporated into the overall development process. 2.1.6 Support The group provides guidance and some resources i.e., people for technology transfer,domain engineering, tool integration, repository population and maintenance, assessment and measurements. 2.1.7 Pilot In parallel to the PDE effort a pilot is being conducted to build and populate a service creation repository. This effort is central to CIG's plans for the future and will provide much insight to the reuse program. 2.1.8 SCE Cellular providers i.e., CIG's customers, want to "invent" new services that they can provide to their customers faster than the competition. This objective requires rapid design and implementation of new services. Motorola's Service Creation Environment (SCE) will give cellular providers the tools to develop new cellular services themselves. The ultimate goal is to remove the developer from direct product delivery. Developers create the building blocks that are made available to customers who then design their own products from these reusable blocks. Development will become a proactive activity rather than a reactive activity with developers continually building new blocks to populate the SCE repository. 2.1.9 SIBs The Intelligent Network (IN)is an architectural concept for the creation and provisioning of telecommunications services. A service independent building block (SIB) is composed of a set of Functional Entity Actions that either independently, or in combination with other SIBs, are used to model service entities. SIBs are the reusable building blocks for the SCE repository. A reusable SIB will consist of several components: the requirements and functional description of the SIB, design, code, test suite, and user documentation. Each component of the SIB will be linked together and more than one SIB may link to a particular component thus forming a network of reusable blocks. 2.1.10 Economics Since creating reusable SIBs will not be an easy task, one of the key decisions will be whether or not it is financially advantageous to build any particular SIB. Although building the initial reusable SIBs will be more of a learning experiencethan a profit activity, subsequential SIBs must be profitable investments. The following metrics will be used for the business analysis of any new reusable SIB: cost - what will it cost to create the SIB, use - how many products will re-use this SIB, savings - what will this save in future developments, and, of course the most important calculation: profit - what did the reusable SIB earn CIG. This will actually be a sub-pilot within the SIB pilot. Although there are many good metrics available, they still require a lot of qualifiable input. A three month study will be conducted to help quantify the economic metrics and improve our ability to estimate the use and profit of reusable SIBs. Some of the information needed for the metrics is obtained through domain analyses. 2.1.11 Domain Analysis Much of the SIB functionality already exists so the domain analysis focused on both forward and backward analyses. This was a team effort with the reuse team providing the analysis expertise and the development engineers providing the domain expertise. From the domain analysis the reuse team was able to create a reusable SIB template that was used to produce reusable SIBs for the repository. 2.1.12 Repository The initial repository is a WEB based system with keyword search for retrieving components. As we create the service creation environments, it is assumed that we will needed added security for our repository and building blocks. 3 Comparison Several of the leading service vendors are working on service creation environments. Because of the competitive advantage, the vendors do not publish their implementation details. Since there are standard SIB structures, I am assume that everyone is following the standards. Jeff Poulin and Keith Werkman have implemented WEB based repositories at IBM/Loral. Weare working with Jeff to expand our prototype. 4 Biography Rebecca L. Joos is a Principal Staff Engineer/Scientist at the Motorola Cellular Infrastructure Group in Arlington Heights,IL. She is leading the effort on reusable Int elligent Network building blocks and domain analysis. She works closely with other Motorola groups to systematically introduce software reuse into Motorola 's software development processes. She was previously the Software Quality Assurance Manager for the Advanced Microcontroller Unit and RISCdivisions in the Semiconductor Sector instituting software process and quality assurance. Applying Lessons Learnt from Software Reuse to Other Domains T P Kelly, B R Whittle Rolls-Royce University Technology Centre Systems and Software Engineering Department of Computer Science University of York York, UK, YO1 5DD Tel: +44 1904432773 Fax: +44 1940 432708 Email: tpk/ben@minster.york.ac.uk Abstract The position this paper promotes relates to the applicability of software reuse techniques to other non-software domains: What lessons learnt from techniques developed primarily for software reuse, can be applied to reuse of artifacts in other disciplines? The prime motivation for this research comes from a project attempting to apply reuse and evolution to the arguments of a safety justification. A discussion of the issues from this domain,as well as from more traditional domains within software development are used as illustration. Our exploration of the issues relating to safety arguments has led us to recognise anew that the essential problem of reuse is one of matching contexts. Whatever the domain we must be able to recognise and abstract the essential technical and non-technical characteristics of the domain. The success of reuse depends upon our ability to support, communicate and exploit the context in which artifacts are built, used and hopefully reused. The paper uses the examples of domain analysis and component description to show how this problem has been tackled with software artifacts and sets forward the motivation for domain modelling that provides a unifying basis for component identification, storage and retrieval for any domain. Keywords: Software Reuse, Non-Software Domain, Context, Domain Analysis, Component Description, Reuse Model, Domain Model Workshop Goals: Discuss domain modelling, assess suitability of software reuse principles to non-software domains Working Groups: Domain Analysis / Engineering, Reuse process models, Reuse handbook. 1 Background Both authors work within the Rolls-Royce University Technology Centre for Systems and Software Engineering: Rolls-Royce established this research group within the University of York, England to examine systems and software development issues for the high integrity control systems,both in the aerospace and power generation industries, produced by Rolls-Royce plc. One of the major activities of the group has been in establishing a successful reuse strategy within the company. This work has been principally undertaken by Ben Whittle and has examined artifact reuse across all phases of system development, from requirements specifications to test plans. The work of Tim Kelly has been in extending the concept of reuse to another costly aspect of high integrity system production, namely safety case development. It is in this work that Tim has been examining the applicability of ideas and techniques from software reuse to wider domains. 2 Position The software industry has proclaimed the benefits of reuse for some time, for example: shorter development time, increases in reliability, economies of scale. This has led to an increasing number of domains being examined for their reuse potential. Candidate domains for this scrutiny are typified by the complexity of the artifacts produced being sufficiently great to outweigh the pickup effort associated with a 'reusable' artifact [1] and where some generality of type or application of the artifacts is suggested. Artifacts in these domains may already be reused on an ad-hoc basis. However, it is systematic reuse, as exemplified in the field of software reuse, that is being seen as having potential long- term benefit. The majority of existing reuse research has concentrated on software and software-related artifacts. Unlike physical artifacts, software artifacts are intangible and their concept, content and context highly variable. Because of this, software reuse research has been forced to deal in generalities and toaddress issues concerning reusable component identification, support and management. Although no panacea exists, the reuse problem has similarities across all domains and fundamental lessons can be learnt from software reuse research. The position this paper explores relates to the applicability of software reuse techniques to other, non-software, domains: What lessons learnt from techniques developed primarily for software reuse,to reuse of artifacts in other disciplines? Software is often generalised as a single domain. Of course this is not strictly true, it should be considered as a large number of domains. Authors active in software research come from a large number of organisations in differentparts of the world. The strategies and models they promote have been developed for their particular domain. Therefore,these models are suitable for their domain but probably not wholly appropriate for other domains. The exploration of reuse within non-software domains shows the need for an approach that recognises, supports and exploits the characteristics of the domain whether for software or not. 2.1 Issues in Promoting Systematic Reuse Regardless of domain, there are three issues associated with reuse: Development for Reuse How do we identify and develop potentially reusable assets within the domain? Development with Reuse How do we abstract these assets so that they can be stored,retrieved and reapplied in new situations? Managing reuse How do measure the costs and benefits, and reason about the tradeoffs involved in reusing assets? These three activities depend on sound modeling of the domain in which artifacts are initially produced and applied. We focus primarily on the first two activities given here. Management of reuse, being a vast subject in it's own right, cannot be adequately covered in a paper of this length. 2.1.1 Developing for Reuse When placed in a new environment andtold to instigate reuse, what do you do? Software reuse theory and practical experience tells us that the first thing should be to learn something about that environment or 'domain'. In the software domain our first step is to perform a domain analysis [2] - "The activity of identifying the objects and operations of a class of similar systems in a particular problem domain". The same is true for almost any domain. The resulting output from this activity should be an appreciation of the context in which domain products are developed and used, including: Product aspects Taxonomies and architecture of the products Functional models of the products Domain languages Properties of the component produced Process Aspects Life-cycle, methods used in the development of the products Standards used in the development of the products Resource used in the development of the products With domain information such as this we can start to determine those artifacts with reuse potential, e.g. by spotting common functions or a regular structure in the architecture of the product. It is only by assessment of the generality of application or content of an object, based upon their defining characteristics determined by the domain analysis, that we can estimate future reuse potential. Emphasis in domain analysis applied to software products has been primarily on appreciating and modeling the technical architecture and characteristics of the domain. To a certain extent, this has not mattered, the reusability of basic block software components can be crudely judged on technical content. However, inspection of the component content cannot reveal attributes such as the development integrity level. With other domains such as safety arguments we require a more complete understanding of the models, experience, assumptions and evidence on which the argument was based in order to appreciate the extent to which it could be usefully reapplied in a new context. In these cases, the context defines the product to a greater extent and without it the products purpose, generality and applicability is eroded. For example, without knowing the assumptions on which a safety argument depends it is impossible to determine the strength of the argument and whether the argument can be appropriately reused in a new context. It has been accepted that domain analysis is crucial to making the first steps in software reuse. Further, we argue that domain analysis is essential in any domain, provided it considers and identifies the most pertinent of all,technical and non-technical, influences over the potentially reusable assets in question. The domain analysis phases is crucial to 'pinning-down' the context, and therefore generality, of the initial development and application of components. 2.1.2 Developing with Reuse Storage and retrieval of components is only an issue to the extent that it influences successful application of 'reusable' component. When we wish to reapply a component developed in one context in a new context it is crucial that we fully understand the component domain and the component's relationship to that domain, in order that the component is appropriately used. For example,with a safety-critical software component we need to determinethe extent to which it has been developed and tested in order to justify its re-application it in a new safety-critical context. It is therefore essential that, whatever storage and retrieval mechanism is used, we capture or communicate a component's relationship to its development context by abstraction and relationship to a domain model that captures all aspects of that context. The central concern in storage and retrieval of components is that it is fast and intuitive to the reuse engineer. In the field of software reuse, faceted classification schemes [3] have been suggested as an approach. Using this method,classes of components are described by defining faceted lists of keywords. Components are stored with, or according to, their faceted classification by their particular grouping of keywords selected from the 'facets'. The principal benefit of this method is the extent which it sythesises a context in which the reusable components can be placed; by defining facets for classification we are modeling a context not too dissimilar to either the original or intended context. If the principle of faceted classification schemes were extended to wider domains,for storage and retrieval of components we would need to recreate a context in which the component can be 'understood'. This context should be derived from the key, technical and nontechnical, characteristics defined in the model produced from the initial domain analysis. Therefore, faceted scheme applied to new domains should also capture these attributes, as exemplified by the REBOOT [4] approach. 2.2 Examples We have argued that allthree of the fundamental concerns of reuse, namely: starting; supporting and managing, should, for any domain, be based upon a sound model, defining the key characteristics of the domain. In the field of software reuse, their has been much effort in defining the 'best' domain analysis technique or the 'best' faceted classification scheme. Generalising, software reuse principles to other domains, we can see that for any domain starting,supporting and managing reuse should be rooted from a model derived from analysis of the domain which abstracts the original technical and nontechnical context of the components in question. In software reuse, we often assume a common understanding of a components context or rely heavily upon the content of the component to communicate that context. For example, we have a common understanding of a particular programming language or development method and believe that, given time, we can work our the original purpose of a component by examining the code contained within. As the degrees of freedom in a domain, increase and we can rely upon less of a common understanding, modeling the domain context becomes increasingly important. To i lustrate this point, let us imagine 3 scenarios: Mathematical routine With a description that says it adds two number of type integer and returns an integer result. Signal validation component for a real-time systems that takes in a signal from a heat probe, validates and range checks the signal. If the signal is outside the acceptable range a model value is used. The software module that generates the model value is a separate subroutine, adhering to a coding standard, that provides a value when invoked,the value the model provides must also be subject to the range check. Safety case fragment which argues the reliability of a component from evidence given in a number of safety analyses, testing and operational evidence from similar components within the framework provided by company, government and industry codes and standards. In each case, when the component is reused it will form part of a system which is to be used in a safety critical application. We need to examine how the component meets the requirements placed upon it within the domain and the properties of those components that are pertinent to the domain. The software components will be used as part of the systems itself, the safety case fragment a part of the justification that the system is fit for its purpose, and has been developed to acceptable standards. There are a couple of questions we need to ask: What information do we need to know about the component? What would existing models like the 3C model [5] or the REBOOT model tell us about the component? Is there any way of knowing,from a domain model or domain modeling, the information that we will need to provide with a component in order to reuse it? If we are to reuse the mathematical routine in a safety critical application it would typically be the case that the component would have to be developed to an equivalent standard to the other components that we were using. Thus we need to know something about the development context of the component in order to infer the quality of the component. In searching for a component we may wish to prescribe standards for the components we search for; they must conform to a given programming standard. We require that reused components must have been developed to that standard. In order to reuse the signal validation component we must know about the associated hardware, the heat probe. We can use the knowledge about the heat probe to work out what kind of model we need if we are going to use a model value of the temperature instead. These can be regarded as the extended technical context of the component If we are going to reuse the safety case fragment we need to consider on what bases the justification is founded; the model, strategy, justifications and assumptions used need to be made explicit, and therefore, verifiable. For the new context we need to determine whether the model of the component, the strategy used, the justification for that strategy and the assumptions made are still valid. For example, it is common to justify a components claimed safety by reference to a good operational record. If however, between the time of creating the safety case fragment and wishing to reuse it, this operational record has been damned by numerous accidents the original justification is invalidated. Safety case fragments depend heavily upon their original application context. For there to be any case for successful reuse of safety case fragments, this context must be made explicit by means of an accurate domain model. The REBOOT component model, faceted classes and 'reusability' measures have been developed specifically for software components. The REBOOT abstractions would therefore be suitable for reasoning about the software components in our example, though possibly considered overkill for the simple component,but would fail to capture the contextual properties of the safety case fragment. The suitability of the 3C model depends upon the extent to which we further subdivide the broad categories of context,concept and content. The 3C model provides a suitable starting point for developing domain-specific models that could be realistically used for identification, storage and retrieval purposes. The strength of the REBOOTmodel is that it has defined a 'generic' model' for software component which captures most of the non-domain specific properties of software components. The strength of the 3C model is that it is suitably generic to be used as a basis for development of any domain model. However, it's failure is that without further definition we are left with vague notions of the domain with inscrutable implicit attributes. This brief example has illustrated that different properties are required to reason about components from different domains. While we could attempt to reapply models unchanged from the software reuse world or develop entirely new models, these would not be suitable for all domains. 3 Summary of Position The problem of reuse is one of matching contexts. Components are developed in one context and, hopefully, reused in another. The decisions we take in reusing a component depend on our appreciation of both of these contexts. We usually have a fair understanding of the context in which we work. However, we have difficulty in appreciating a context separated from our own. If the context of the component isn't recorded then we are required to assume a context ,as is commonly the case with vanilla software reuse. We have highlighted that for some domains ,such as safety justification, the assumption is potentially more damaging, and the information communicated by the component content becomes of less use. Mathematical routines have been successfully reused for some time. Their strength lies principally in well defined interfaces supported by the constructs of the implementation language. The functional dependencies and context of the component can be successfully bundled up as a neat set of parameters and return variables. The difficulty in reusing components such as the safety case fragment described lies in the many dependencies and contextuality that the component possesses. We have no well understood boundary or interface to the component. The underlying content andstructure of the component lends no support to defining this context. We therefore have to find a way of defining the boundary of the component and specifying those 'parameters' of dependency within the component's context. Between these two extremes lie a great many domains, each with varying levels of contextuality and support from their underlying content or technology. What is common to these domains, is that the context of the component has to be considered. The type and degree of context that is recorded should depend upon the domain in which the component is developed, applied and reapplied. We have used the techniques of domain analysis and faceted classification as an example of how software reuse has tackled a problem that has to be faced in any domain,that of comprehending and abstracting contexts. To capture the essence of these techniques developed for software reuse and apply them to other non-software domains we need to recognise and record the process and product characteristics most pertinent to the initial development and application context. The information that we require for successful component identification, storage, retrieval and management all derives from our comprehension of this context. By developing a single model of this context,on a per-domain basis we will maximise understanding of where components can be reused and be able to reason about how reuse can 'carry value' from one context to the other. References [1]P. Ireland,"Why is Software Reuse so Elusive?,"in Software Reuse: The Future, The BCS Reuse SIG 1995 Workshop, 1995. [2]R. Prieto-Diaz, "Domain Analysis: An Introduction," ACM SIGSOFT Software Engineering Notes, vol. 15, no.2, 1990. [3]R. Prieto-Diaz, "Classifying software for reusability," IEEE Software, vol. 4, no. 1, pp. 6-16, 1987. [4]J.-M. Morel,"The REBOOT Approach to Software Reuse," in Software Reuse: The Future, The BCS Reuse SIG1995 Workshop, 1995. [5]B. Frakes, L. Latour, T. Wheeler, "Descriptive and prescriptive aspects of the 3Cs model,"in Proceedings of the Third Annual Workshop, Methods and Tools for Reuse, CASE Centre Technical Report number 9014, 1990. 4 Biography Ben Whittle graduated in Agricultural Economics from UW Aberystwyth in 1989. He subsequently completed a masters in Computer Science. Foremost among Mr Whittle's research interests are component reuse and reuse education. Mr. Whittle is currently with the University of York, in the working within the Rolls-Royce sponsored Systems and Software Engineering University Technology Centre (UTC). His main task within the UTC is the introduction of advanced reuse techniques to the development ofreal-time systems within Rolls-Royce. Mr Whittle has recently been elected chairman of the British Computer Society Reuse Special Interest Group committee and was formerly the editor of the group newsletter. Tim Kelly graduated in Computer Science from the University of Cambridge, England in 1994. He is a research student working within the Rolls-Royce Systems and Software Engineering University Technology Centre (UTC). He is investigating the development and assessment of safety cases. In particular,he is looking at the reuse and maintenance of safety arguments as a means of supporting evolvable safety cases. Before joining the UTC, he was involved for a number of years with high- integrity systems and software research within the Rolls-Royce group, working particularly in the area of Integrated Project Software Environments. Deliberations of a Reusable Assets Broker W. (Voytek) Kozaczynski Center for Strategic Technology Research/SEL Andersen Consulting 100 South Wacker Dr., Chicago, IL 60606 Tel: (312) 507-6682 Fax: (312) 507-3526 Email: voytek@andersen.com Abstract The producer-broker-consumer (PBC) model of software reuse assumes a middleman, the broker, between the teams (or individuals) that create software assets and those that (re)use them. The modelÕs underlying principle is that the broker fills the gap between teams that fight to meat deadlines, and therefore have little time to think about potential future usefulness of their work product, and the future users of these products that may have not even come to being yet. This position paper briefly examines an issue that is at the very core of the brokerÕs existence: what kind of assets will project care to buy (after all, brokers have sell to exist) and when is the best time to make a sale? Keywords: Reuse process, reuse asset broker, reusable assets Workshop goals: Learning, exchange of experiences, shopping for ideas, verifying hypotheses Working groups: Reuse process models, reuse management, organization and economics 1 Background I am directing the Software Engineering Lab (SEL) at the Center of Strategic Technology Research (CSTaR). The mission of this applied research group is to ÒDramatically improve the quality and productivity of the Andersen ConsultingÕs software development processesÓ. One of the most promising ways of achieving this mission is via large-scale, institutionalized reuse. Because of this, the SEL has been working on a number of projects that can be directly linked to reuse. Until very recently, or interest concentrated mainly on production and/or recovery of reusable code products, for example: code understanding for recovery of reusable components, software specifications and automatic code generation, component specifications and component assembly environments. While working on the projects and on transferring their results to practice, it became clear that reuse of software solutions is difficult mainly because it comes late in the system development life cycle. Reuse of relatively small-grain solutions also has relative minor impact on projects. The most significant reuse opportunities seem to present themselves at the early stages of a projects, but they call for different (than pre-packaged solutions) reusable assets. Recently the SEL started working with a number of internal Andersen organizations and programs to establish a function, and an organizations associated with it, of a broker. The role of this function/organization is to acquire, refine, package, tailor and transfer all kinds of reusable assets. 2 Position The context setup Imagine the following situation: - A broker functions has been set up in a company that concurrently executes a large number of software development projects for external clients - The projects are independent of each other - The projects can be significantly different from each other in terms of clients, domains, scope, and contractual arrangements - On the other hand, the projects are similar in that they deliver systems in the same broadly understood category (letÕs say, for the sake of this argument, logistic systems) - Each project team has a large degree of freedom in deciding what is the best way of executing its project - Reuse decisions are based on economics of project execution and client satisfaction (as opposed to internal Òarm twistingÓ, for example) - The company uniformly trains its employees, has an excellent QA system, centrally tracks all projects, and strongly encourages project teams to share experiences (even has a central functions to facilitate such sharing, but does not award teams for it) Now, assume further that in this setup the broker function has been give initial monetary and human resources (which is a good indication of the managementÕs support) on the premise, that a very significant amount of otherwise reusable assets get simply wasted because of the disconnection (in time and space) between their producers and consumers. Also assume, that the management wants to apply strictly marketing approach to the broker functions and wants it to charge the consumers for its assets and services and eventually become self-supported. How should the broker invest its initial capital and build its services and a protfolio of assets. A ÒlawÓ of diminishing opportunities The law (strictly intuitive at this time) states that as project teams move forward, they become less and less flexible and an opportunity for significant impact from reuse diminishes. This is simply because: - Project managers, architects, designers and develpers sucessively, through their decisions, constrain the space into which the resable assets must be fitted, and - With progress of time the project decisions change from strategic, to tactical, to operational. The table below shows major phases of a project/system lifecycle (the phases may be executed concurrently and allow for local iterations) and the resusable assets that should be of interest to project teams at each phase. Phase Reusabls Assets Preliminary Requirements Acquisition and Analysis, Contrat Negotiations Estimation models, base development process models, process statistics, comparative frameworks, development cost records, architectural records, ... Detailed Requitements Acquisition and Analysis, System Architecteting Domain models, systems architecures, technical architectures, design tradeoff records , COTS solutions, ... Prototyping and Detailed Design Prototyping and development envirments, system designs, component specifications, design standards and guidelines, ... Component Development and Testing Rreusable components, component designs, solution frameworks, designs patterns, reusable code libraries, ... System Integration and System Testing Testing tools, testing processes models, configuration control systems, documentation tamplates, ... Deployment User training guidelines, systems support processes models The assets listed in the table above can be roughly divide into three categories: 1. Solutions that are things like designs, technical architectures, reusable components, and other artifacts that can be put into the new system or used to ÒshapeÓits form 2. Software tools such as design workbenches, code development tools, tesing tools, configuration management tools, etc., and 3. Software engineering processes and their components. Software tools are a special category. Their main contributions are that they: (a) provide a common language to capture reusable solutions (designs, architectures, code, etc.), and (b) improve the productivity and quality of software develpment tasks. Tools themselves, and the knowledge how to use tham effetivaly, are very much resuable assets. While looking at the table it is easy to notice, that most of the software resue attention (both academic and practical) so far has concentrated on the resue of software solutions during the phases 4 and 5 (Detailed design and Component development). Much less attention has been given to more process oriented and less formal assets usable in the early phases of a project. Reuse of these Òearly processÓ asstes, however, may present a larger opportunity for impact. Unfortunately, such reuse is also more difficult. The software reuse field has very little experience in capturing processes, process statistics, comparative models, software development cost models, systems architectures, design tradeoff records, etc. Moreover, codified experiances of such kind may be very context-dependent. For example, what works for a software division of a manufacturing company may not be at all applicable to the situation described here. The position ÒproperÓ The borker functions must be proactive. The broker team must invest in working with project teams to capture quality assets. The borkering process takes the form of a loop: -> capture -> analyze -> refine -> package -> identify opportunity -> tailor -> apply -> There is no clear starting point in this loop -- the broker actively works with selected projects to capture best experiences to then tailor and ÒsellÓ them to other projects. The broker is not just a librarian, but an informed investor. So what shold the broker invers in? The table above suggests that is should invest more in the process, tools and architecure-related rather than in solution-related assets. This, howeve, brings two interesting questions: 1. Will that be still software resue if a borker sells things like: team management guidelines, costing models, tailored process models, architecture records, etc., or is that a different type of reuse?, and 2. What kind of skills shoud a good broker have? I am hoping to address thes questions at the workshop. 3 Comparison The issues brought up here most resemble the work on Experiance Factories lead by Dr. Vick Basili [1,2 and 3]. The major differnce seems to be, that the work of the University of Maryland and NASA concentrated so far on large, stable development organizations with well-articulated software product lines. Many issues are also common to the SEIÕs work on the Capability Maturity Model [4]. References [1] V. R. Basili, H.D. Rombach, Support for compehensive resue, Software Engineering Journal, September 1991, pp. 303-316 [2] Victor R. Basii and Scott Green, Software Process Evolution at the SEL, IEEE Software, July 1994, pp. 58-66 [3] Victor Basili, Frank McGarry, The Experiance Factory: How toBuild and Run One, ICSE-16 and ICSE-17, Tutorial materials [4] Mark C. Paulk, Bill Curtis, Mary Beth Chrissis, Charles V. Webber, Capability Maturity Model, IEEE Software, July 1193, pp. 18- 27 Bibliography Dr. Kozaczynski is the Director of the Software Engineering Laboratory at the Andersen Consulting's Center for Strategic Technology Research which is an applied research organization working on multiple aspects of software development processes and tools. He is responsibility for the research directions and coordination of research initiatives and projects of the lab. He is also actively involved in projects as a scientist. His current research interests include reuse of domain-specific architectures and components, compositional approaches to system development, and distributed systems design. He is also interested in application of object-oriented software development approaches and techniques. Previously he has worked on automatic software analysis and understanding, software re-engineering, application of AI to software development, and database systems. He has a MS degree in Computer Science and a PhD in Organization and Management from the Technical University of Wroclaw, Poland. Prior to joining Andersen Consulting he was an Associate Professor at the Department of Information and Decision Sciences, University of Illinois at Chicago. He has published over 20 journal and conference papers and is a member of the Industrial Advisory Board of the IEEE Software Magazine. Functional Fixedness in the Design of Software Artifacts Larry Latour Liesbeth Dusink University of Maine Dept. of Computer Science 222 Neville Hall Orono, Maine, 04469 Tel: (207)581-3523 Fax: (207) 581-1604 Email: larry@gandalf.umcs.maine.edu & Delft University of Technology Dept. of Technical Mathematics and Computer Science Julianalaan 132 2624 BL Delft The Netherlands Tel: +31 15 781156 Fax: +31 15 787141 Email: E.M.Dusink@twi.tudelft.nl Abstract A common rule of thumb to make components reusable is to "make components generic". But software engineers tend to design in a way that solves the particular problem at hand, and in a way that they do not easily see opportunities to reuse existing components. We call such solutions "functionally fixed". Domain analysis prior to system design can help a great deal here, but for most software engineers fighting functional fixedness is still a constant and uphill battle. It seems to us that designers need more experience in recognizing functional fixedness when it is "staring them in the face", and in generalizing functionally fixed solutions to more (re)usable artifacts. In this paper we suggest how to uncommit design decisions from functionally fixed designs in such a way that their essence is kept. This uncommit process is done with the support of: reasoning by analogy, stating implications, challenging assumptions, and (of course) previous experience/ knowledge about the domain and other domains Keywords: Functional Fixedness, Generic software, Uncommitting Design Decisions Workshop Goals: To look for in-depth examples of good reusable artifacts, to discuss with other researchers what makes them good, and to validate/flesh out/adjust our ideas on the topic. Working Groups: Reuse Education, Domain Analysis/engineering, Generic Architectu res 1 Background We have both been independently exploring issues of reusable artifact design since the late 80's. Liesbeth has been approaching the problem from the direction of both cognitive psychology and software engineering [3], while Larry has been taking a more "traditional" route to the problem, relying strictly on previous software engineering literature [6]. Liesbeth has been "playing" with the concept of functional fixedness for a good while, while Larry has been independently exploring the effects of uncommitting design decisions. Our combined goal has been to take the cognitive psychology term functional fixedness and "operationalize" it. That is, we have attempted to show what functionally fixed software artifacts look like, and in the process to suggest how such artifacts could be avoided or undone. 2 Position Our position is simply that the cognitive psychology people have the right idea (functional fixedness), but that these ideas need to be "operationalized" in the reuse domain. A prior example of a successful "port" of an idea from another discipline is the work done by Ruben Prieto-Diaz in exploring the concept of faceted classification in the reuse domain ([9] - yes, boys and girls, 1987). We introduce some of these ideas of functional fixedness in this position paper. 2.1 Introduction Functional fixedness concerns the "fixed" nature in which humans solve problems [2]. Specifically, they tend to express solutions in a way that is very specific to the problem at hand,and in a way that is somewhat difficult to generalize to the solution of other, similar, problems. This causes both a difficulty in seeing that existing components can be used in one's problem solution and also a difficulty in designing reusable components for use by others. Our suggestions for designing for and with reuse involve systematically uncommitting design decisions from functionally fixed solutions in ways that the resulting solution(s) can be more easily applied to other problem solutions and that also leave the essence of the original solution intact. How this method is developed is described in [5]. It seems that the following four guidelines each play a major role in "optimizing" the uncommit process: 1. Always Challenge Assumptions: when a design decisionis made, make clear why such a decision is made, from where it is made, and what the properties are of the general class of design alternatives from which such a decision is made. 2. Make Implications Clear: when a design decision is made, make clear the other design decisions that affect the choice of this decision, and also make clear the design decisions that are affected by this design alternative. 3.Make Analogies Explicit: While humans express problems solutions in a functionally fixed manner, they are very good at reasoning by analogy, and find their fixed solutions in that way. Analogous design decisions have a common abstract description when uncommitted within a context and from a certain viewpoint, and these descriptions should be made explicit. 4. Value Previous Experience/Domain Knowledge Highly: The first three guidelines have to be followed within the context of experience, both in the domain of interest and in the understanding and use of good software engineering principles. The context of experience can also stretch to other domains of interest,e.g. knowledge about library reservation systems can be of an advantage when designing a seat reservation system for planes. The "Make Analogies Explicit" bullet raises an interesting point that we exploit. Humans do most of their "hard" reasoning by analogy in an informal, abstract, and many times unconscious, manner. What is left tends only to be the functionally fixed solution as formal residue. Part of the problem here tends to be one of awareness. Two interesting research studies support this claim. Maiden and Sutcliffe [8]. show in their work that software engineers use syntactic analogy instead of semantic analogy because they are not actually aware that they use syntactic analogy. When aware of the fact that one chooses by analogy one can also reason why the analogy holds and (subsequently) come up with the right (semantic) analogy. Compounding the problem is that humans tend to solve just the problem at hand with the help of analogy,and not the class of problems of which this specific problem is a part. This contributes to the "scale- up" problem, in that "super-problem solutions" of which the problem solution is a part tend to be not only solved in a functionally fixed manner but reasoned about in that manner also. It is interesting to note that our analysis when evaluating our uncommitments is similar to that used by Ted Biggerstaff in his "rule of 3s". That is,we take advantage of prior knowledge of alternatives and their common characteristics to properly construct our "decision graph". As we keep repeating,there is no substitute for this knowledge. The better it is,the more complete our decision graph will be. 2.2 The 3 Views of Functional Fixedness The definition of functional fixedness as taken from the cognitive psychology literature does not in itself help us in an operational sense. We need to explore the analogy between general knowledge and software engineering knowledge in order to apply this principle. But of course we immediately we see an analogy with reuse, where one has to use existing components not only in one application but also in other applications. In that case if knowledge of such components is tied closely to a former problem solution, it becomes difficult to see the applicability of that component to another problem. Specifically, (and paraphrasing our cognitive psychology definition) if a component is learned for the purposes of using it in one application then the (possibly) broad general properties of the component are learned as perceptions of specific, limited, functional characteristics. In fact, by massaging the definition a little bit, and using an analogous interpretation, we make the definition apply for reuse and software engineering in a more general sense. In this we derive three different "functional fixedness" definitions: 1. wrt the component: We can view functional fixedness with respect to the component itself. That is, the component is functional fixed if it only does one specific thing in one specific way in one specific context only. This relates to the genericity issue discussed earlier. 2. wrt a software engineer's view of the component: We can view functional fixedness wrt the view a software engineer has of the component. That is, does the software engineer view the component as only doing one thing in a fixed way and in a specified context, independent of its actual level of functional fixedness? This view of functional fixedness is the most faithful to the original cognitive science definition. 3. wrt a software engineer's view of the problem solution: We can view functional fixedness wrt the problem solution created by the software engineer. That is, does the solution focus on the specific problem or class of problems analogous to that problem solution. To some extent this argument is recursive (not circular,since we always start somewhere), since the problem solution itself can be considered to be a component. Consider first the functional fixedness inherent in a component. An example of a component performing only one (set of) task(s) in one way, and in one context is an abstract data type for sequences of integers. Such an ADT can easily be generalized into an abstract data type for sequences of any type of elements. But this generalization doesn't buy us too much, since most software engineers can easily re-write its implementation without invalidating the specification and implementation constraints. Even though this generalization allows us to use the component in more than one context, it still performs only one set of tasks in one way. Consider next functional fixedness from the software engineer's point of view. Suppose we need to implement a search tree,and choose a binary tree for the search tree structure. Focusing primarily on this application, we might not see that such a structure can also be used as an expression tree in a compiler. One might argue that we don't care at this point about expression trees for compilers. But this is exactly the point. We have solidified our view of a binary tree as a search tree because of the application, but we still have only a vague feel for a binary tree as an expression tree in a compiler, again because of our focus on the search tree application. Another example of user view functional fixedness, one that we are all too familiar with, is our frustration and inability to cope with the wide range of features provided by our word processing/ spread sheet/ paint/ draw/ programming environment/ etc. software on our PC (which of course we all have). We tend to assimilate this knowledge in a functionally fixed way, learning only what we need to learn to do our work. The above problem is compounded by the fact that in order to properly use more complex components/sub-systems/software packages, one has to have intimate knowledge of the usage patterns of applications using such facilities. Two examples, each at opposite ends of the "abstraction continuum" come to mind. The abstraction continuum meant here, is in terms of the top-to-bottom layering of a complex system implementation. One is the use by a photographer of a complex photographic image processing package, and the other is the use by a systems programmer of a complex device controller interface. In both cases a tremendous amount of domain knowledge is required to use the facilities as they were intended to be used. In the case of the image processing software, tools to hi-light, low-light, darken, or lighten an image make little sense to a novice, and in the case of the device controller interface, disk heads can be destroyed in the hands of a novice. Ways to alleviate such problems are to give courses for photographers, and provide pre- packaged device drivers for complex devices. Both of the first two "views" of functional fixedness focus on the components to be reused. The third interpretation of functional fixedness focuses on the framework, or architecture, in which components are reused. Specifically, when designing a framework for a problem solution, we tend to do so for that solution and not for the class of solutions of which it is a part. But we also need to deal with functional fixedness in the framework design of mid-size components. Often a great deal of functional fixedness analysis of small components is lost if they are then composed into a functionally fixed mid-sized component framework. As an example, a real-time feedback control module might be designed in a functionally fixed manner without an awareness that analogous feedback control modules are available for reuse. In this case the designer might not even be aware that the system is a control system, thus not being aware of the wide variety of analysis methods and tools available for such systems. The actual functional fixedness of a component is typically what most reuse literature focuses on when considering design for reuse, and the software engineer's view of the problem solution is typically focused on (although in a functionally fixed way) when considering design with reuse. The software engineer's view of a component is typically not considered, essentially because the literature focuses on the reuse product and not the process. What is also typically missed is that if one designs with reuse, the resulting product is also a component implementation, and needs to be analyzed with respect to design for reuse. Thus in order to achieve the elusive "scale-up" frequently alluded to in the literature, designing with reuse needs to always be done within the context of designing frameworks for reuse. 2.3 An Example 2.3.1 Undoing Functional Fixedness We now suggest how to undo functional fixedness in a component, thus how to uncommit. This approach of uncommitting can also be done after one stage of a top-down approach to check one's own results. We use as an example, the tried and true Quicksort algorithm (which we suppose is as trite an example as a stack is. So be it.) In this position paper we will specifically limit ourselves to one aspect of quicksort, the internal partition algorithm. For choices of partition algorithm we find among others: while not done if pivot > a[lwb] then lwb:= lwb+1 elsif pivot < a[upb] then upb:= upb-1 else swap(a,lwb,upb) endif end while not done while pivot < a[lwb] do lwb:= lwb+1 end while pivot > a[upb] do upb:= upb-1 end swap(a,lwb,upb) end while pivot < a[lwb] do lwb:= lwb+1 end while pivot > a[upb] do upb:= upb-1 end while not done swap(a,lwb,upb) while pivot < a[lwb] do lwb:= lwb+1 end while pivot > a[upb] do upb:= upb-1 end end Triggered by the different formats, we recognize the inner while-loops as searches for elements which are out of place. The fact that they always appear together triggers the thought that they together are a search for the swap-indices. We thus rewrite the algorithm now in "pseudocode"as: while not done search(swapIndices(pivot)) if search success then swapendif end We now see the reason for the algorithm that starts with the search for swap indices before starting the "not done" loop. It is optimized with respect to checking the condition. Search failure and done are the same test. Unfortunately, it is a "false" optimization, since the test for success is also incorporated in the search algorithm itself. From the perspective of good programming style this is "ugly", since the same work as done in the while-loop shouldn't also be done outside the loop. From the view of correct use of language constructs one should use a repeat as the search is done at least once. The if-statement then returns and the optimization is undone. From the viewpoint of reuse this"optimization" is also ugly. It takes more time to understand the algorithm, especially as the optimization is not documented and is an unfamiliar usage pattern to most naive programmers. Furthermore, it is not really necessary that the test of failure and done are the same. By keeping them apart, we can more freely choose a search algorithm and a stopping criterium. The algorithm in the form rewritten above is familiar. Triggered by associating the search and the search predicate we might begin to think about filters, which leads us in turn to think about folds and maps (knowledge from functional programming). We suddenly see that Partition is a map. Now the iterator has become implicit. Depending on whether we work in place or with help structures the iterator can be of importance. In summary,the concepts we recognize as determining the algorithm are: an iterator on the structure; a filter on the structure; and a map on the structure. Partition can be viewed as a framework for search, albeit one with few restrictions on the search. 2.4 Summary We have found it useful to define a more general interpretation of "functionally fixed" than that which appears in the cognitive psychology literature. We realized that the term itself was functional fixed, therefore only partially applicable to our problem area. Our three-view interpretation shifts the focus of attention and in doing so becomes a unifying concept that aids us in focusing on the hard problems of designing for reuse, with reuse, and scale-up. The issue of functional fixedness is NOTto remove it, but to control it in such a way that it captures the essence of the domain knowledge inherent in an algorithm, not more nor less. Furthermore, this control has to be done both during design"for reuse" and "with reuse" as they are two sides of the same issue as stated in the previous section. Knowing what to "fix on" in this way, and then capturing it formally is arguably the essence of design for and design with reuse. Since the systematic application of the four stated guidelines can be useful in both of these contexts, our work looks carefully at both issues, considering the effects of each side on the other. References [1]H.G. Birch. The Relation of Previous Experience to Insightful Problem- Solving. Journal of Comparative Psychology, 38:367-383, 1945. [2]H.G. Birch and H.S.Rabinowitz. The Negative Effect of Previous Experience on Productive Thinking.In Wason and Johnson-Laird [11], chapter 3. [3]Dusink,E.M. Software Engineering and Reuse. Proceedings of the Fourth International Workshop on Software Reusability, Reston, Virginia, 1991. [4]E.M. Dusink. Reuse is not done in a Vacuum. In Larry Latour et al., editor, WISR'92,5th Annual Workshop on Software Reuse, Palo Alto California, October 26-29 1992, 1992. [5]E.M. Dusink. The Reuse Process Refined. Technical Report to appear,Faculty of Mathematics and Informatics, TU Delft, The Netherlands, 1994. [6]Latour, L., and Johnson,E. Seer: A Graphical Retrieval System for Reusable A da Software Modules. Proceedings of the 3rd Int'l IEEE Conf. on Ada Applications and Environments, Manchester, NH, 1988. [7]Mitchell D. Lubars and Neil Iscoe. Frameworks versus Libraries: A Dichotomy of Reuse Strategies.In Larry Latour et al., editor, WISR'93, 6th Annual Workshop on Software Reuse, Owego, New York, November 2-4 1993. [8]Neil Maiden and Alistar Sutcliffe. The Abuse of Re-use: Why Cognitive Aspects of Software Reusability are Important, chapter 10, pages 109-113. Workshops in Computing. Springer Verlag, 1991. [9]Prieto-Diaz, R., and Freeman, P. Classifying Software for Reusability. IEEE Software,V 4 (1), 6-16, January, 1987. [10]P.Saugstadt and K. Raaheim. Problem-Solving, Past Experience and Availability of Functions. In Wason andJohnson-Laird [11], chapter 5. [11]P.C. Wason and P.N. Johnson-Laird, editors. Thinking and Reasoning, Selected Readings. Penguin Modern Psychology. Penguin Books, 1968. The Impact Of Technological Change On Domain Specific Software Architectures Sadie Legard & Bill Karakostas C25/Main Building Department of Computation UMIST Manchester M60 1QD United Kingdom Email: sl@sna.co.umist.ac.uk Abstract In this position paper we argue that research into domain specific software architectures [1] can benefit from the results of a discipline known as technology theory which is concerned with issues such as technological evolution. In this context a domain architecture encompasses a complex of technologies whose role and trajectories (possible future evolution) must be taken into account when assessing the stability and the evolution of the architecture itself Keywords: reuse, domain specific software architectures, reuse management, technology theory. Workshop Goals: to meet, discuss and refine ideas with fellow researchers and practitioners. Working Groups: Reuse management, organisation, economics, Useful and collectible metrics, Domain analysis/engineering. 1 Background Sadie Legard is about to complete a PhD in the area of software reuse and re-engineering. During the course of her research she has been investigating the maturation of software reuse as a technology, and the organisational, managerial, and technological issues related to the formulation, and subsequent introduction, of a new paradigm for software development based on reuse principles. In her thesis, Sadie describes Enterprise-Wide Software Reuse (EWSR) which incorporates the Reuse Profile technique. This paper describes some of the author's earlier work on reuse technology maturation in the area of change (user or technology-driven) and its implications. Dr. Karakostas has been developing industry specific architectures for the finance and banking industry with the purpose of exploiting such architectures in tasks such as business redesign, systems evolution and rapid application development. 2 Position Today there is probably only one characteristic shared by all technological domains, namely change. Large investments together with advances in Research and Development result in products and technologies becoming obsolete at an ever increasing pace. Despite this the paradigm of domain specific software architectures (DSSA) advocates reusable and long-lived designs which must withstand the volatility of their constituting technologies. An obvious criterion for establishing the suitability of a domain for developing a "change withstanding" architecture is the stability of the technologies employed in it. However this is not a trivial task since domains do not usually contain single or simple technologies but complexes of (interacting) technologies. Moreover as it will be explained in Section 2.1.3 there are many different types of technological changes; some of them, although affecting individual components, may have no impact on the overall stability of the domain. Additionally, change in a technology is not always entirely unpredictable. With the exception of radical (breakthrough) types of technological change it is sometimes possible to accommodate change in one of the domains constituent technologies by evolving (transforming) the domain architecture. In conclusion, we propose that any candidate domain for reuse should be examined from the perspective of the set (complex) of technologies of which it is composed, and the relationship between them and a suitable architecture defined. In so doing a more fine grained indication of a domain's stability from the perspective of its component technologies can be ascertained. This information can be used to gauge the suitability of the domain for reuse against certain reuse strategies, or it can be used to monitor or isolate areas of instability, for example by standardisation constraints. Dependent upon the stability of the technology, forecasting techniques may be applied to facilitate the creation of robust, or extensible, components. It could also be possible to measure the impact of change on the architecture from either new problems given by the environment or scenarios for domain improvement to increase market share, for example. In the following sections an overview of technology theory is presented. 2.1 Technology And Its Relationship To Domains A technology is defined as the set of solution-oriented knowledge concerned with solving practical problems. It may be embodied in products and processes, or hardware; it may be in the form of a technique. [2] suggests that since individual technologies typically serve little purpose on their own they may be combined to form a technological complex, a new technological area representing a service or an end-product. Complexes tend to be relatively long lived and will only change if the refinement or replacement of their constituent technologies causes a change in the relationship between them. Systems are described in this context as the highest level of technological organisation and are characterised as wide ranging in space as well as long lived in time. In addition, [3] describes a correlation between the technical features of a product and the service characteristics it displays. They identify similarities between this pattern of mapping and the concept of design. Using these ideas a domain may be conceived as a layered architecture of technologies where there is a mapping relationship between the service characteristics of the domain and the technologies of which it is composed. 2.2 Technological Development And Technological Discontinuities The process of technological development is composed of innovations, many of which are minor improvements on, or adaptations to, preceding innovations. An innovation will occur if it serves to increase the existing performance level or offers an equal level of performance but at a lower cost [4]. As a technology matures so the emphasis will move towards cost reduction. Technological development can be understood either in terms of a lifecycle [5] or by technological discontinuities [6], we describe the latter, figure 1. Technological Development. Era of Ferment Era of Incremental Change - Design Competition - Elaboration of Dominant - Substitution Design ____|_____________________________|_________________________|__ ___Time Technological Dominant Technological Discontinuity 1 Design 1 Discontinuity 2 Figure 1. Technological Development (from [6]) Technologies emerge as the result of a discontinuity when either an existing technological paradigm is no longer able to address "needs- driven" requirements, or a breakthrough technological innovation opens up a new seam of technical possibilities, a "technology push". The initial phase of the lifecycle is characterised by a period of ferment in which there is a rapid advance in the technology linked to a high number of competing designs in the paradigm. Towards the end of this phase the main characteristics of the dominant design begin to emerge. A dominant design [5], also referred to as a technological paradigm [7], is a single architecture that establishes dominance over competing solutions in a class and has powerful exclusion effects over which problems are possible and worth doing. Thenceforth future evolution of the technology consists of cumulative improvements where variation takes the form of elaborating the retained dominant design. Although a paradigm is known by all industry participants the technological directions which are pursued within it, technological trajectories [4], are specific to the organisation. The position of a product on a technology trajectory can be said to identify its market position vis-ˆ-vis its competitors. 2.3 Factors Which Precipitate Change And Their Impact There are several different kinds of problems which force change and technological progress [2]. They are classified using [8], [9] and [10] to be: 1. incremental: cumulative improvements to an existing dominant design 2. micro-radical: these are changes which both disrupt and continue a dominant design. There are 2 types: a. modular: caused by the functional failure of an existing technology, whilst not affecting the relationship between the technologies themselves b. architectural: caused by imbalances between related technologies, though not affecting the existent design of the technologies themselves 3. radical: occur rarely and are the result of a problem given by the environment which is not yet solved by any technology.  Figure 2. A Classification of Technological Progress Types, adapted from [10]. 3 Comparison We understand that the DSSA approach is an attempt, by standardisation of requirements, to evolve and promote a dominant design for a particular industry. To do so they have described two refinement architectures. Structure preserving architectures based on an object oriented layered model, are instantiated by refinement of detail corresponding to product variation within the domain. However, their definition of refinement and its relationship to incremental, modular, and architectural innovation is not clear. A second type of architecture defined is transformational, transformational architectures are said to be both elaborated at the same time as they are restructured and as such we suggest they are the result of a radical innovation. Such architectures are not supported by DSSA. Whilst architectures as layers of technology can facilitate: incremental, modular, and architectural innovation, apart from recognising a radical discontinuity they are unable to support it. We qualify this, however, by saying that a discontinuity may combine some of the technologies employed in the displaced paradigm. We prefer, at this stage, not to further refine the comparisons we have made since this would involve guesses on our part. Our reason for attending the workshop is to both clarify our understanding of DSSA and its relationship to architectures as layers of technology and for the purpose of feedback from other practitioners and researchers in the field. References [1] Hayes-Roth, F., "Architectural-Based Acquisition and Development of Software: Guidelines and Recommendations from the ARPA Domain Specific Software Architecture (DSSA) Program, Teknowledge Federal Systems, Version 2, October 20 1994. [2] Laudan, R., "The Nature of Technological Knowledge: Are Models of Scientific Change relevant", In R. Laudan, ED, Cognitive Change in Technology and Science. [3] Saviotti, P.P., Metcalfe, J.S., "A Theoretical Approach to the Construction of Technological Output Indicators", Research Policy, 13(3), (1984), 141-51. [4] Biondi, L., Galli, R., "Technological Trajectories", FUTURES, July/August 1992, 580-592. [5] Twiss, B., "Managing Technological Innovation", 4th Edition, Pitman Publishing, 1993. [6] Anderson, R., Tushman, M.L., "Technological Discontinuities and Dominant Designs: A Cyclical Model of Technological Change", Administrative Science Quarterly, 35 (1990), 604-633. [7] Dosi, G, "Technological Paradigms and Technological trajectories", Research Policy, 11, (1982), 147-162. [8] Albernathy, J.M., Utterback, J.M, "Patterns of Industrial Innovation", Technology Review, 50, (June-July 1978), 41-47. [9] Durand, T., "Dual technological trees: Assessing the intensity and strategic significance of technological change", Research Policy, 21, (1992), 361-380. [10] Henderson, R.M., Clark, K.B., "Architectural Innovation: The Reconfiguration of Existing Product Technologies and the Failure of Existing Firms", Administrative Science Quarterly, 35, (1990), 9-30. Bibliography Sadie Legard is an EPSRC-CASE PhD student in the Department of Computation at the University of Manchester, Institute of Science and Technology (UMIST), where she developing a paradigm for software development based on Enterprise-Wide Software Reuse. Sadie has worked on several collaborative projects with British Telecommunications PLC. in the areas of domain analysis and re- engineering, and is a member of the SER-ESPRIT project for reuse technology dissemination in Europe. Her research interests include, but are not limited to, software reuse, software architectures, business and software re-engineering, the strategic role of IT, knowledge acquisition for organisational learning, and technological evolution. Dr. Karakostas is a lecturer in the Department of Computation, UMIST. He has participated in many UK and European R&D projects on software reuse and evolution. He is currently the technical manager of a European (ESPRIT) project on software evolution in banks (EUROBANQUET) and also participates in a program for reuse technology dissemination in Europe (SER). His research interests include object oriented systems modelling, business and software re- engineering and the application of AI to software engineering. Applying Cluster Analysis to Software Reuse Wayne C. Lim 1535 Fairway GreenCircle San Jose, CA 95131 Email: lim@source.asset.com Abstract Cluster analysis, a method of classifying objects based upon specific features, has many potential benefits in software reuse. At the Manufacturing Productivity section of Hewlett-Packard, we applied such an analysis to a set of reusable assets and identified "include file" configurations that would minimize the maintenance effort of such files. In this paper,we define cluster analysis within the context of group technology and present an example of how this analysis was applied and utilized. Keywords: cluster analysis, group technology, manufacturing concepts, domain analysis. Workshop Goals: share perspectives on managerial and organizational aspects of reuse; profile interesting reuse academic and practitioner experiences in upcoming book. Working Groups: Reuse management,organization and economics; Reuse process models; Reuse maturity models; Reuse Metrics; Reuse Strategic Planning; Reuse Assessments. 1 Background The purpose of group technology in manufacturing is to utilize economies of scope by identifying and exploiting the similarities in the partsto be manufactured and the sequence of machines that are necessary for the processing of those parts. Parts are classified into families on the basis of characteristics such as size and geometry. Machines which are used to process the part families are situated in proximity to each other in "machine cells". Wemmerlov and Hyer [1] highlight three ways that group technology benefits are achieved: By performing similar activities together, less time is wasted in changing from one unrelated activity to the next By standardizing closely related items or activities, unnecessary duplication of effort is avoided By efficiently storing and retrieving information related to recurring problems, search time is reduced 2 Position One of the means for family identification in group technology is cluster analysis. Cluster analysis is "concerned with grouping of objects into homogeneous clusters (groups) based on the object features. [2]" Cluster analysis was applied to software reuse at the Manufacturing Productivity (MP) section of the Software Technology Division of HP to solve a problem concerning the maintenance of their reusable assets, called "utilities". The MP section produces large application software for manufacturing resource planning. The MP reuse program started in 1983 and continues to the present. The original motivation for pursuing reuse was to increase the productivity of the engineers to meet critical milestones [3]. MP has since discovered that reuse also eases the maintenance burden and supports product enhancement. Reuse was practised in the form of reusable assets (application/architecture utilities and shared files) and generated code. Total code size for the 685 reusable assets was 55 Thousand lines of Non-Commented Source Statements (KNCSS).The reusable assets were written in Pascal and SPL, the Systems Programming Language for the HP3000 Computer System. The development and target operating system was the Multi-Programming Environment (MPEXL). The utilities at MP are many (685 utilities) and small in size (lines of code range from 14 to 619 Non-Commented Source Statements). In manufacturing systems software developed by MP, a transaction constitutes a cohesive set of activities used for inventory management and is a subunit of the manufacturing systems software. Within each transaction,c alls are made to the appropriate utilities as required which are contained in an include file specific to the transaction. However, this has led to a proliferation of different include files since each transaction isusually created by a different engineer. When a utility is modified, all the include files which contain this utility need to be identified and updated with the new version. This has resulted in a tremendous amount of effort. In an effort to reduce the potential amount of effort required for future updates, an analysis using cluster analysis was conducted on the use of utilities by transactions. First, a 13 x 11 matrix was created by designating the rows as transactions and the columns as utilities. (Figure 1). A"1" indicates that a transaction makes a call to the particular utility, and a "0" indicates that a transaction does not make a call to the particular utility. Figure 1: Input Matrix: (Rows are transactions; columns are reusable assets) 1 0 1 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 1 0 0 1 0 0 1 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0 0 1 0 0 0 0 0 0 0 1 0 0 1 1 0 0 0 0 0 0 1 0 0 1 0 0 0 0 0 0 0 0 0 1 0 0 1 0 1 0 0 0 1 0 1 0 0 1 0 1 0 0 0 0 0 1 0 0 1 1 1 0 1 1 1 0 1 0 1 1 1 1 0 1 1 1 0 1 0 1 0 0 1 0 0 0 1 0 1 0 1 1 0 1 0 0 0 1 Columns (Reusable assets): 1=Adj-summary-qty 2=Autobofill 3=check'store'um 4=invalid-fld-check 5=potency-inv-qty 6=prep'for'pcm 7=print-document 8=report-neg-qty 9=send'to'pcm 10=update'pcm'buff 11=write-stock-file Rows (Transactions): 1=adjhand 2=issalloc 3=isseu 4=issord 5=issunp 6=issbo 7=move 8=recinloc 9=recinsp 10=recwo 11=recrun 12=recpopt 13=recpoit The matrix is then used as an input file to a clustering algorithm provided by Dr. Andrew Kusiak of the University of Iowa. The output solution, as shown in figure 2, reorders the reusable assets into "clusters". The results suggest that we place utilities (depicted by the columns) 1, 3 and 8 into a single include file for transactions 1 to 7. Utilities 2,5,6,7,9,10 should be placed into another include file for transactions 8,9,10,11,12,and 13. Utilities 4 and 11 can either be placed in both include files or a separate one may be created for them. Figure 2: Cluster Analysis Solution: (Rows are transactions; columns are reusable assets) 1 1 1 3 8 2 56 7 9 0 1 4 Row 1 1 1 2 11 1 3 11 4 1 1 5 1 1 6 1 1 1 7 1 8 1 1 1 1 9 1 1 1 10 1 1 1 1 1 1 1 11 1 1 1 1 1 1 1 1 12 1 1 1 1 13 1 1 1 1 1 Benefits of Cluster Analysis for Reuse Cluster analysis is useful in the creation of include files with specified utilities that would reduce the effort required to maintain the files. In our example with the MP section, prior to cluster analysis, thirteen individual include files were maintained; one for each transaction. By utilizing cluster analysis, we were able to identify the commonalities and differences within the thirteen include files and specify a core set of two include files. By reengineering the thirteen include files into two, the number of files to maintain can be reduced by 85 Cluster analysis also has further applications in software reuse. It may be used to identify"families of systems" i.e. those that share the same features. For example, we can apply cluster analysis to a matrix where the columns depict the features of software systems/products and the rows,the software systems/products. The analysis would cluster the features to the software systems/products, thereby helping to identify families of systems which share common features. This information may be useful in determining specific reusable assets to create. 3 Comparison Some researchers have utilized cluster analysis for the purpose of reuse classification. For example, Maarek and Kaiser [4] describe the useof conceptual clustering to classify software components. Taxonomies of software components are created "by using a classification scheme based on conceptual clustering,where the physical closeness of components mirrors their conceptual similarity." The objects are gathered into clusters where they are more 'similar' to each other than to the members of other clusters. 4 Acknowledgements My acknowledgements to Dr. Andrew Kusiak, Dr. Sylvia Kwan and Alvina Nishimoto for their help and input to this paper. References [1]U. Wemmerlov and N. Hyer, Chapter 17, Handbook of Industrial Engineering. John Wiley & Sons,1992. [2]A. Kusiak and W. Chow, " Decomposition of Manufacturing Systems," IEEE Journal of Robotics and Automation, vol. 4, October 1988. [3]A. Nishimoto,"Evolution of a Reuse Program in a Maintenance Environment," in 2nd Irvine Software Symposium, March 1992. [4]Y. Maarek and G. Kaiser,"Using Conceptual Clustering for classifying reusable Ada code," in Using Ada: ACM SIGAda International Conference, ACM Press, New York, December 1987. 5 Biography Wayne C. Lim specializes and consults in the strategic planning, economic, organizational, and metric issues of software reuse. His involvement in software reuse began in 1983 as a member of the Ford Aerospace Reuse Group researching reuse library issues. Mr. Lim completed his MBA degree at Harvard University, graduate engineering coursework at Stanford University, and an undergraduate degree in mathematics from Pomona College. He is the author of a forthcoming book, Managing Software Reuse, to be published by Prentice-Hall. Trade-off between Flexibility and Efficiency in Recombining Reusable Components Beat Liver and Dean T. Allemang Research & Development Swiss Telecom PTT 3000 Berne 29, Switzerland Tel. +41 31 338 f 50 64 j 44 72 g Email f liver j allemang g@vptt.ch Abstract We outline the framework ZD for constructing libraries of reusable software components. The approach is a formal one, in that the semantics of the representation is based on proofs of program correctness. The correctness of combinations of library components is the central issue of this paper. Modular correctness proving approaches exist and are computationally optimal. Our position is that these approaches are too inflexible to configure novel combinations using from library components. In the ZD framework, we resolve this problem with a method called proviso proving and propagating. Keywords: Reuse, formal verification, modular design and configuration Workshop Goals: Learning; networking; advance state of theory of reusable position papers. WorkingGroups: Reuse and formal methods, Reusable component certification, Reuse and OO methods and technology 1 Background Dean Allemang began his contribution to software reuse with his dissertation in 1990. Since that time, he and Beat Liver at Swiss Telecom PTT Research and Development have extended the method described there to include support for software configuration,diagnosis, debugging and repair [1, 2]. This work will culminate in Mr. Liver's dissertation, whichwill include an implementation of the software modeling language ZD. 2 Position For configuration and design, it is very important to formally reason about the correctness of recombinations of reusable components from a library of such components. Note that these components are not programs themselves, but they are functional models of programs, that is descriptions of the function of programs. In addition to the correctness of combinations,the computational efficiency of proving the correctness of combinations as well as the flexibility to recombine components is important. Our position is that: Combining local certifiable components is computationally optimal, but at the cost of flexibility. This flexibility can be achieved by paying with computational effort (theorem proving, in the worst case) at configuration time. We are implementing our representation (described in the next section), in which the trade-off between flexibility and design-time computational expense can be made, so that this trade-off can be more systematically studied, in the context of a growing library of reusable components. 3 Functional Representation ZD Our functional representation, called ZD (that stands for Zweckdarstellung and is pronounced`Zeddy') is a further development of Allemang's version [3] of FR [4]. A function consists of a specification, an implementation and requirements. A function specification is defined as an input and output partial state of the system being described, a partial state called additional result, and a condition called the proviso. A function achieves the output partial state (and the additional result), if and only if the proviso holds in the context of use. For example, a function that moves the content of a variable ?loc1 to the variable ?loc2 is defined by the function move of figure 1. Using Hoare semantics [5],move's input state is P(?loc1) and its output state P(?loc2), if the proviso empty(?loc2) is satisfied. In addition, move achieves empty(?loc1). The input and output state form the index of library functions. Both partial states are described in the same state description language. A state description language (SDL) provides the terms for partial state descriptions, as well as the semantics of the terms. Hence, SDLs are mathematical theories (or combinations of mathematical theories),like STRING, INTEGER, and so on, which are used in model-oriented software specification approaches (Resolve [6], Larch shared language [7]). In this paper, the formal properties of SDLs are not studied, because they are independent of ZD itself. A more detailed discussion of SDLs is given in [3, 8]. DevSpecRecord ParametersP;?loc1; ?loc2 FunSpecmove If P(?loc1) ToMake P(?loc2) Providedempty(?loc2) AddRes empty(?loc1) DevImpAssignment-Record Rep(x) : x Implementationmove P(?loc1) UsingFunction "?loc2:=?loc1" -? P(?loc2) ^ empty(?loc1) Figure 1: The Record. The main reason for the separation between the additional result and output state is that they might be described by different SDLs. In our example,the concept empty() is defined by the function move, i.e., a variable is empty if its value is moved to some other location. This function is applicable to data records that are indestructible values. The function move is a reusable representation of this intention, rather than any particular program code. Therefore, it is possible to represent in ZD information that is usually represented in documentation, wishful variable names, or not at all [3, 8]. A function implementation defines how its function specification is achieved by a combination of other functions. This description takes the form of a state-transition graph, where the states are partial state descriptions. A transition is labeled with the function that achieves this transition. This function is not necessarily known at implementation construction time; the function is really a function requirement. A function requirement is a specification of the function required by the implementation. In contrast to a function specification, a requirement does not have a proviso or an additional result. In figure 1,the implementation of move is a state-transition graph with a single transition. To be precise, ``?loc2 := ?loc1'' should be a function name that refers to the semantic description of an assignment operation (in Hoare semantics). A generic device is a reusable component in ZD and consists of a device specification, one or more device implementations, and device requirements. A device specification specifies the function of the device. A device implementation describes how this function is achieved using services provided by other devices. This description requires functions of otherdevices. The required services of another device are specified as a device requirement. A generic device specification consistsof a set of parameters and a set of functions. An example is the DevSpec Record in figure 1. Devices that maintain state information, like stacks,queues, and so on, also have a persistent abstract state. A generic device implementation consists of a representation function and function implementations for the function specified in the device specification. A representation function (Rep) [9] formalizes the change of abstraction levels and, hence, SDLs. The entities specification, implementation and requirement are common in component-oriented reuse approaches, because they make it possible to prove the correctness of a component at its construction time. In the next section, we show how ZD enables one to trade off configuration flexibility against computational complexity. 4 Comparison: Recombining Components A major desiderata for a recombination method is the verification of the correctness of a combination of software components. For this purpose, we would like to to associate with a component its correctness proof, so that software components as well as proofs would be reusable. The associated correctness proof is incomplete, because the proofs associated with subcomponents are not known at the construction time of the component. Simply associating these partial proofs to their corresponding components is not feasible, because proving recombinations using these partial proofs incurs, in general, the cost of recursive proof completion, and, hence, it is computationally intractable. In the sequel, we present and compare two more elaborate association approaches together with their implications for reuse, in particular with respect to flexibility and efficiency. Both approaches are supported by ZD and, hence, can be combined to achieve a better overall recombination method. A proof can be modularized,if one requires that the components cannot interfere with one another [10,11, 6]. To be more precise, a module is local certifiable if and only if the correctness of a module can be verified solely on the basis of its specification, its implementation and the specification of the modules used in its implementation. Local certifiability requires that the operations of the module (the interface) be leak-free abstractions (of the realization of the module). This condition is only satisfiable for modules that satisfy additional conditions [6]. Consequently, local certifiability restricts the granularity of reusable components to modules. We call devices that represent local certifiable modules local certifiable devices [8]. The computational complexity of proving the correctness of recombinations of local certifiable devices is optimal, because the correctness proof is just the combination of the correctness proofs associated with the local certifiable devices. But, there exists a trade-off between optimal efficiency of correctness proving and the flexibility to recombine devices. In [8],we show that it is not feasible to build libraries of powerful local certifiable generic devices. Local certifiability requires the designer to anticipate, specify, and prove all possible behaviors of such a component in advance. Consequently,the flexibility required to produce novel configurations of library components is not supported by local certifiable components. This missing flexibility is caused because local certifiability eliminates not only interferences that result from leaky abstractions but also interactions that are essential for achieving some functions. ZD supports contextualized devices proposed by Allemang [3]. Contextualized devices are devices that model interactions by provisos in a reusable way. An example is the Record given infigure 1. In contrast to local certifiable devices, contextualized devices enable one to configure existing devices in novel ways to achieve goals not foreseen at the time of their construction [8].This is possible, because, first, each device specifies (by provisos and additional results) under what conditions an interaction is acceptable but not the interaction itself; and, second, the correctness of interactions is verifiable by proviso proving and propagating. This flexibility has a price. First, proviso propagating and proving is necessary for handling interactions. This is more expensive computationally than simply comparing function specifications, but the successful modularization of large software indicates that such interactions are typically local. Second, a contextualized device has to be a `grey box', that is, a device implementation has to be provided that is sufficient for proving provisos. In contrast, a local certifiable device has to reveal only its requirements, so that it can be a black box. Naturally, black boxes are preferable in a commercial setting. Fortunately, the two granularites are complementary and both kinds of devices can be mixed. In the case of local certifiable devices, proviso proving and propagating is reduced to showing that the proviso of a service is implied by the initial state of therequirement. References [1]B. Liver,"Repair of communication systems by working around failures,"Journal of Applied Artificial Intelligence, vol. 9, no. 1, pp. 81-99, 1995. Special Issue on Function-Based Reasoning Part2. [2]B. Liver,"Modeling software systems for diagnosis,"in Working Notes of the 5th Int. Workshop on Principles of Diagnosis, (New Paltz, NY), 1994. [3]D. T. Allemang, Understanding Programs as Devices. PhD thesis, The Ohio State University, 1990. [4]Sembugamoorthy, V. and Chandrasekaran, B., "Functional Representation of Devices and Compilation of Diagnositc Problem-Solving Systems," in Experience, Memory and Reasoning (J. Kolodner and C. Riesbeck, eds.), pp. 47-73, Lawrence Erlbaum Associates, 1986. [5]C. Hoare, "An axiomatic basis for computer programming," Communications ACM , vol. 12, no. 10, pp. 576-580,583, 1969. [6]J. Hollingsworth, Software Component Design-for-Reuse: A Language Independent Discipline Applied to Ada. PhD thesis, Dept. of Computer and Information Science, The Ohio State University, Columbus, OH, 1992. [7]J. V. Guttag and J. J. Horning,Larch: Languages and Tools for Formal Specification. Texts and Monographs in Computer Science, Berlin: Springer, 1993. [8]B. Liver and D. T. Allemang,"A functional representation for software reuse and design,"Software Engineering and Knowledge Engineering, vol. Special Issue on Evolutionary Approaches to Software Engineering, 1995. in press. [9]W. Wulf, R. London, and M. Shaw, "Abstraction and verification in alphard: Introduction to language and methodology," in ALPHARD: Form and Content (M. Shaw, ed.), Computer Science Monograph, pp. 15- 60, Springer, 1981. [10]J. Krone, The Role of Verification in Software Reusability. PhD thesis, Dept. of Computer and Information Science, The Ohio State University, Columbus, OH, 1988. [11]G. W. Ernst, R. J. Hookway, J. A. Menegay, and W. F. Ogden, "Modular verification of Ada generics," Computer Languages, vol. 16, no. 3/4, pp. 259-280, 1991. 5 Biographies Beat Liver received the diploma in Informatics from the Swiss Federal Institute of Technology (ETH) in Zurichin 1989 with a specialization in communication networks, distributed systems and computer-aided tools for VLSI. He joined the research and development directorate of the Swiss Telecom in 1989. He is pursuing a Ph.D. on the topic of functional models for managing communication system software. His main area of interests are computer-aided tools for telecommunication network management. He is also a member of the ACM, and AAAI. Dean Allemang received his B.S from the Ohio State University, and a M.Sc. from the University of Cambridge. He completed his Ph.D. at Ohio State in 1990 on the topic of using Artificial Intelligence modeling techniques to model software. Since that time, he has pursued this and other knowledge modeling work in a series of postdoctoral appointments in Switzerland. He is currently working at Swiss Telecom PTT research and development on modeling telecommunications applications. Domain Engineering - Varying Rationales & Approaches Fred Maymir-Ducharme, PhD USAF CARDS / Loral Defense Systems 12010 Sunrise Valley Drive, Reston VA 22091 Tel: (703)620-7559 Fax: (703) 620-7916 Email: fredmd@cards.com Abstract Systematic reuse is not for everyone. The long term benefits of a thorough domain analysis that captures the requirements of previous, as well as future systems within the domain - and the development of a flexible architecture, engineered to maximize reusable components and support the application-specific variances of the domain - may not mean much to an organization only tasked with developing a single system for the government. It's generally far more economical for a contractor, for instance, to instead take the opportunistic reuse approach and focus on the short-term gains, minimizing the reuse costs to only those directly applicable (beneficial) to the specific system being developed. There are two major strategies to domain engineering: systematic and opportunistic. These strategies vary in both costs and benefits; hence they appeal to very different customers. Conflicts may arise in a government-contractor relationship, even when both sides agree on the benefits of reuse and commit themselves to implementing reuse - because of these conflicting strategies. The intent of this position paper is not to evaluate the two and convince the reader that one is better than the other; but rather, to illustrate that the two have different economic justifications and are geared towards different organizational frames of reference. The paper also suggests combined approach, which attempts to find a middle ground to meet the short and long term reuse needs of government-contractor relationships. The results of this workshop can be of considerable benefit to both,the DoD and private industry organizations that realize the benefits of domain engineering but don't understand the implications of selecting one approach/method over another. Keywords: Domain Engineering, Domain Analysis, Software Architectures, Reuse Method(s) Selection, Business Case Analysis for Opportunistic versus Systematic Reuse. Workshop Goals: Identify rationales for opportunistic domain engineering, identify rationales for systematic domain engineering discuss whether some methods support one approach more than the other, and develop a business case analysis template for selecting either approach. 1 Background The Sustaining Base Information Systems (SBIS) program has very ambitious reuse goals - short-term goals for Loral Federal Systems, the prime contractor, and long-term goals for the US Army Sustaining Base Automation (SBA) program. There are over seventy applications planned for development under the SBISprogram, and these are envisioned to fit into approximately ten domains. As part of a USAFComprehensive Approach to Reusable Defense Software (CARDS)/ SBIS Partnership, Fred M-D is leading the SBIS Domain Engineering Team efforts [1], using a hybrid of the ARPA/STARS Organization Domain Modeling (ODM) [2] and the Defense Information Systems, Software Reuse Program (DISA/SRP) Domain Analysis and Design Process (DADP)[3] methods, to realize both, short-term opportunistic reuse benefits and long-term systematic reuse benefits. 2 Position Systematic reuse is not for everyone - having a sports car doesnt help you get there any faster if you're stuck in rush-hour traffic. On the other hand, if you're in Germany and in a hurry - you're better off in a Porsche 911 Turbo Carrera on the Autobahn than in a Geo Metro. There are two major strategies to domain engineering: systematic and opportunistic. The long term benefits of a thorough domain analysis that captures the requirements of previous, as well as future systems within the domain - and the development of a flexible architecture, engineered to maximize reusable components and support the application-specific variances of the domain - may not mean much to an organization only tasked with developing a single system for the government. It's generally far more economical for a contractor, for instance, to instead take the opportunistic reuse approach and focus on the short-term gains, minimizing the reuse costs to only those directly applicable (beneficial) to the specific system being developed. The two major reuse strategies - systematic and opportunistic - vary in both costs and benefits; hence they appeal to very different customers. Conflicts may arise in a government-contractor relationship, even when both sides agree on the benefits of reuse and commit themselves to implementing reuse; these may be due to conflicting reuse strategies. The intent of this position paper is not to evaluate the two and convince the reader that one is better than the other; but rather, to illustrate that the two have different economic justifications and are geared towards different organizational frames of reference. The paper suggests a combined approach,which attempts to find a middle ground to meet the short and long term reuse needs of government-contractor relationships. The opportunistic approach is focused on the development of a single system. The major focus of the (opportunistic) domain analysis (e.g.,the DADP method) is to identifythe are as of greatest commonality within a domain, to facilitate the search and acquisition of applicable, reusable components. The goal is to maximize the use of existing components and minimize the development of new components. The next step, domain design and architecting, is driven by the goal of utilizing the maximum number of components identified during the domain analysis and found by searching numerous reuse libraries and repositories. The resulting architecture is "bent and tweeked" and made to conform to the maximum number of reusable software components as possible. The benefits are thereby realized in short-term - maximizing the reuse of components can save money and reduce the development time. Alternatively,the systematic approach is focused on the development of a family of similar systems (optimally, a product-line). Hence, the focus is just as much on the (context-sensitive) variances between the family of systems within the domain as on the commonalities. A more detailed domain analysis (e.g., the ODM method) may be desired, to ensure that the resulting domain analysis captures not only the current domain requirements (exemplified by associated legacy systems and the specific system being developed ),but also the anticipated future requirements of related systems. The ensuing software architecture and domain design are engineered to maximize the domain commonalities, and to support application-specific variances. A development organization (e.g.,a DoD contractor) or a program manager (e.g., a DoD PM) may be more inclined to select the opportunistic domain engineering approach for purely economic reasons - the task is limited to the development of a single system, within a given schedule and budget. The incentives and rationales for applying a systematic domain engineering approach make more sense to an organization such as AT&T, which has well defined domains (e.g., electronic switching systems) and product lines (e.g.,5ESS and 4ESS "generics").An organization's business model must be considered when selecting the domain engineering method(s) to be applied. In cases with multiple organizations as stake-holders, each organization's business model must be considered. The SBA model described in the background section is a good example where each organization's business model differs enough to each warrant a different reuse approach and method. The SBA program office stands to benefit from the systematic approach because of the size of the program (multiple domains and over seventy applications) and the longevity of the program (the program plans to define and develop future sustaining base systems to meet new needs, and to extend the SBIS applications developed to meet the evolving needs of the base in the next several decades.) Alternatively, the development organization needs to consider its bottom line - revenue - cost = profit. The opportunistic approach is more appealing to the contractor for obvious reasons,as cited earlier. The SBIS Domain Engineering Team took several factors into consideration in selecting the domain engineering methods to apply on the SBISprogram. One of the factors considered was each stakeholder's business model and strategic goals. In order to resolve the conflict described above and attempt to present a Win/Win solution,the team elected to select a hybrid- method approach, integrating DADP and ODM methods. The resulting method was then tailored to meet the project- specific needs (e.g., processes, environments and applications) of SBIS. [1] The DoD Software Reuse Initiative (SRI)Software Reuse Vision and Strategy (SRVS) [4] recognizes the value of applying Domain-Specific, Architecture-Centric, Process-Driven, Technology-Assisted techniques to develop and maintain DoD software systems. One of the strategies of the DoD is to change it's business model (and organizations) to better leverage off these Reuse Technologies. By having DoDcenters/organizations chartered to develop and manage domains (as opposed to single systems),the government expects to develop the necessary infrastructure and incentives to support the SRVS. As the government undergoes this transition, it will need guidance on which approach makes most sense and which methods will best support the approach selected. The results of this workshop can be of considerable benefit to both, the DoD and private industry organizations facing similar decisions. References [1]"Draft SBIS Domain Engineering Project Plan, Comprehensive Approach to Reusable Defense Software and Army Reuse Center," tech. rep., May 1995. [2]"Organization Domain Modeling (ODM) Guidebook (Version 1.0),STARS-VC-A023/01 1/00, ARPA Software Technology for Adaptable, Reliable Systems," tech.rep., March 1995. [3]"Domain Analysis and Design Process, (Version 1.0), DISA/JJIEO/CIM DISA Software Reuse Program," tech. rep., 1993. [4]"DoD Software Reuse Initiative Vision and Strategy Office Secretary of Defense (OSD)," tech. rep.,1992. 3 Bibliography Dr. Maymir-Ducharme has over 15 years of software engineering experience in industry and with the DoD. He has been involved with the development and application of advanced software technologies since the early 80s. He was the principal engineer on various AT&T Bell Lab's ISDN features, served on the OSDAdvisory Board on Ada, and was intimately involved with Ada9X as a member of the Ada Technical Advisory Group(TAG) and ANSI Canvassers Group. Fred worked at the SEI as a Resident Affiliate while on the ARPA STARS program, developing process models and guidebooks for the SEI/STARS Process Asset Library (PAL)project. He has numerous publications on Ada, Reuse and Software Engineering. Dr. Maymir-Ducharme worked for AT&T Bell Laboratories for several years before transitioning to the Department of Defense. He is now with Loral Defense Systems, working on the Air Force Comprehensive Approach to Reusable Defense Software (CARDS) Program. Fred's most recent focus has been on reuse technology transition, which entails the application and adoption of Domain Engineering Technologies (e.g., concepts, processes, methods and tools) to enhance the software engineering discipline. Fred is the technical leadand manager of the A.F. CARDS Partnership Implementations project, whose major thrust is to support reuse technology transition within DoD organizations. Dr. Maymir-Ducharme received his BS in Computer Science from the University of Southern California (USC) and his PhD in Computer Science from the Illinois Institute of Technology (IIT). As an adjunct professor at IIT, Fredtaught graduate Software Engineering and Ada courses. Conceptual Predesign: A Platform for the Reuse of Requirements Specifications Heinrich C. Mayr Institut fŸr Informatik UniversitŠt Klagenfurt UniversitŠtsstra§e 65-67 A-9020 Klagenfurt Email: mayr@ifi.uni-klu.ac.at Abstract Software reuse is not only a matter of recurring, within a software development process, to programs, modules, class definitions, etc. that have been stored in a software repository during former development projects. It also may be extended to the reuse of "higher" software documents like (parts of) logical or conceptual schemata or even informal requirement specifications. In this case reuse decisions are not only made by designers and developers but also by end users in their role of requirements providers. In order to set them into a position to do so economically we introduce, between requirements analysis and conceptual designer, an additional phase into the information system life cycle: the so called conceptual predesign. It comes with a glossary model, the vocabulary of which demands less abstraction abilities than semantic models as they are known from methods for conceptual design, resp. objected-oriented analysis. The contribution will illustrate the kind of design that is possible within such a framework. Keywords: Conceptual design, conceptual predesign, requirements analysis, glossary model, schema reuse, domain knowledge. Workshop Goals: Learning about other approaches to the reuse of results of earlier life cycle phases; a critical discussion of our approach with expert colleagues; identifying aspects of reuse process models and methods that are "generalizable" in the sense that they could form the basis of a comprehensive reuse methodology. Working Groups: Reuse process models, domain analysis/engineering, reuse and OO methods and technology, design reuse. 1 Background There are two main aspects of software reuse I am/was involved in so far: - Component reuse on the implementation level; as may be seen from my biography, before "coming back" to the university I was for nearly ten years engaged in a medium sized software company founded by myself and a colleague. Greatest possible reuse was our development philosophy there. The products of this (still running) company are branch specific multiuser information systems that are constructed (configured and customized) on the basis of a standardized, reuse oriented system architecture out of a module base of actually about 6000 components. - Reuse of domain knowledge: Back to the university one of my main research interests is to contribute to the definition of an object oriented conceptual design technique that really enables a cooperation between information providers (normally end users) and information collectors (system analysts and/or engineers), for details see the subsequent "position". Within this context, reuse again is an essential issue with substantial influences on the methodology and process model we propose. 2 Position Today, the notion of Software is used in a rather broad sense: It denotes program(s System)s that are written in a specific programming language as well as any kind of design documents produced in earlier phases of a system development process. As a consequence, software reuse is not only a concern of the implementational level but also of requirements analysis, conceptual design and logical design. We concentrate on the former two, that, compared to reuse in later development phases, come with the substantial difference that the end users/information providers have to participate in reuse decisions. They have to decide with respect to their requirements, what information should be entered into the new design, and which information should be changed or rejected. The actual state of the art in conceptual design is that of object oriented analysis (OOA). There are numerous OOA techniques "on the market" (see [3,5,6,9]) and they are mostly argued to be viable platforms for the communication with end users. My experiences from many projects in several business branches show, however, that end users are not willing or able to accept the level of abstraction that is induced by such approaches (and that has to be taken in order to reach the goals of conceptual design, namely completeness and disambiguity). Forcing them mostly leads to a rather naive use and, thus, to rough results that have to be completed by the analyst/designer without a chance for the end user to judge about the validity of such completions. Therefore, requirements analysis should be carried out on an informal, natural language level for supplying as much information and UoD facets as possible. On the other hand, when using natural language for requirements collection, designers pay a lot of work for the mapping of natural language descriptions into the notions of a conceptual model. For these reasons, we propose to introduce, between requirements collection and conceptual design, a phase that we call conceptual predesign [7,8] that is to bridge the gap between the informal level of requirements collection and the abstract level of conceptual design. Conceptual predesign again is conceptual because of the fact that it uses a semantic model, i.e., a controlled vocabulary with explained but not formally defined notions. The lower level of abstraction is gained by the choice of the particular notions of the vocabulary and of their representation, for which we use a glossary approach (based on the early work collected in [2]). The main notions are: thing, connection, operation, event, and constraint. Note that these notions are used in a generic sense (as is usual in semantic modeling), i.e., have instances (extensions) in a preschema, that again have instances in the UoD. For each notion a glossary is introduced with slots for a set of attributes that characterize aspects of the notion in question. In addition a so called sentence glossary is used as a repository for the natural language requirement statements and that is referenced by entries of the other glossaries. Each of these glossaries represents an important aspect of an UoD. Gloassaries form a basis for communication between end user and designer. This function makes it possible, to use glossaries not only for the documentation of requirements but also for the reuse of already documented requirements: They act as containers of knowledge from which information can be drawn as a starting point for discussion. The main question is, what kind of information can be reused? A schema of an UoD as a whole will certainly be something that is individual. But pieces of that schema might be invariant within a given application domain and thus being drawn into the new schema. Let us assume that things like "person", "manager", "employee", "customer", "representative", "name", "customer-number" are defined in a UoD X and that they are invariant. Then the designer can show these things (i.e., their glossary entries) to the end user and ask him if he agrees that they are part of the new schema Y. In the same way we might reuse connections and related information as well as information of the other glossaries. The connections which represent that "a customer is a person", "manager is a person", and "an employee is a person" may also be invariant over several UoD's. The same is true for connections like "a person has a name" or "customers buy products". For the specification of the contents of the operation glossary, it might be important to know which operations exist, the operation structure of these operations, just as information about the location of execution of an operation. Reusable kinds of information in the event glossary are again the operations involved in an event as well as general specifications of the pre- and postconditions of an event. Which kinds of information are reused and to what detail this is done is within the responsibility of the designer and his requirements providers. To support them, we propose a process model that starts with an initial glossary set called "knowledge base" that is an abstraction/generalization of glossaries from former projects. Its contents are the starting point of discussions with the end user, and therefore, for information reuse. The process model as well as the conceptual model will be presented at the workshop. 3 Comparison There is some work on the reuse of conceptual schemata, e.g., in the context of Chen's entity relationship model (ERM) and its derivatives [1,4]. As far as I know however, besides re-engineering approaches using former requirements specifications there is no comparable method of re-using glossaries in conceptual (pre-)design. References [1] Bellizona, R., Fugini, M.G., and de Mey, V. Reuse of Specifications and Designs in a Development Information System, 1993. [2] Ceri, S. (ed.) Methodology and Tools for Database Design. North Holland, 1983. [3] Coad, P. and Yourdon, E. Object Oriented Analysis. Prentice Hall, 1991. [4] Eder, J., and Welzer, T. Meta Data Model for Database Design. In (Marik, V., Wagner, R. eds.) Database and Expert Systems Applications. DEXA 93, Prague, Sept. 6-8, Springer Verlag, 1993. [5] Jacobson, I. Object-oriented software engineering: a use case driven approach. Addison-Wesley, 1993.. [6] Kaschek, R., Kohl, C., Kop, Ch., and Mayr, C. Characteristics of OOA Methods and Tools. A First Step to Method Selection in Practice. (to appear). [7] Kop, Ch., and Mayr, H.C. Reusing Domain Knowledge in Requirements Analysis. In (Gyšrkšs, J. et al. eds.) Proc. Re '94, Bled, 1994, pp. 133-147. [8] Mayr, H.C., and Schnattler, M. Vorkonzeptuelle und konzeptuelle Dynamik-Modellierung. In [SR 93], pp. 3-18. [9] Rumbaugh, J., Blaha, M., Premerlani, W., and Lorensen, W. Object Oriented Modeling and Design. Prentice Hall 1991. Biography Heinrich C. Mayr is Professor at the Department of Informatics of the University of Klagenfurt. He leads research on design methodologies for business information systems, on information system architectures and on computer aided support for the software supporter. Actually he also is the Dean of the faculty of management sciences and informatics of the university of Klagenfurt. He is a member of the board of the Austrian Computer Society and he is the speaker of the technical committee 2 (Software Technology and Information Systems) of the German Informatics Society (GI). Before coming to the University of Klagenfurt he was for about ten years the managing director of a medium-sized software company in Germany engaged in the design, development and support of turn- key branch specific information systems. From 83 to 84 he was guest professor at the technical university of Munich. He received his doctor degree in Applied Mathematics from the University of Grenoble, France, in 1975, after having studied at the universities of Karlsruhe and Klagenfurt. He had teaching and research stays at the universities of Kaiserlautern and Saarbruecken and he worked as an assistant professor for several years at the informatics department of the university of Karlsruhe. (SPHINCs) : Specification Reuse via Homogeneous Interpretation of Concepts Walaa-Eldeen A. Mohamed University of North London 2-16 Eden Grove London N7 8EA, UK Tel: +44 171 6072789 Fax: +44 171 753 7009 Email: 11MOHAMEDW%CLUSTER.NORTH-LONDON.AC.UK@clstr.unl.ac.uk Abstract One of the essential requirements for successful software reuse is the availability of a mechanism that allows developers to relate new situations to old ones. The take up of specifications reuse, as a feasible approach to software development, hinges on finding such a mechanism. This will facilitate the matching process between new and old situations at an early stage of the development process. Current software reuse approaches provide very limited support to specification reuse at the requirements analysis stage. In this research, Concepts Reuse is proposed as a new approach to specification reuse by providing a classification scheme that will aid the matching process. This will be developed as part of a new paradigm for software development that supports specifications reuse at the requirements analysis stage. The proposed approach, named SPecification reuse via Homogeneous INterpretation Of Concepts (SPHINCs), classifies the problem of a new system (as documented in its requirements) under one Concept which will be chosen from a proposed set of Concepts. Each of these Concepts represents a category of generic-reusable specifications which were developed for previous requirements. The proposed set of concepts capture the common patterns of problems that regularly occur in the description of software requiements. Each concept is an abstraction of a generic, well-repeated, problem pattern that occurs across different application domains. These Concepts are independent of software implementation environments as well as application domains knowledge. Keywords: Specification Reuse, Concepts of Reuse. Workshop Goals: To exhange ideas andpresent a new framework for reuse during the requirements analysis stage of the development process. Working Groups: Domain Analysis/Engineering. 1 Background Recent research and practices of software reuse have raised expectations of increasing productivity and improving quality of the software development process. The reported success of the Japanese software factories and the savings that they had achieved by reusing software components have attracted much attention. However, most software reuse efforts, including the Japanese experience, have been mainly focused on code reuse at the implementation level. Greater savings can be gained achieving specification reuse at the requirements analysis stage. Research in specification reuse is scant and reuse during the requirements analysis stage has rarely been practiced. This research focuses mainly on this area and attempts to provide a feasible method for reuse of requirements specifications. The problem of specification reuse does not only involve the discipline of Software Engineering but also stretches to reach to other disciplines such as Cognitive Psychology, Philosophy, and Systems Theory. Although, investigating these disciplines will be attempted carefully, the focus will be mainly on topics related to this research. System modelling and problem solving are two other topics which will be investigated in disciplines other than Software Engineering. Diagrammatic modeling techniques are powerful media of communicating concepts of problems and their proposed solutions. The application of these techniques in Software Engineering and Information Systems is still facing some obstacles. Some of these obstacles are due to problems inherit in their notations others are related to the nature of the continuing evolution of the subject area. Disciplines such as Architecture has employed diagrammatic techniques successfully to form a common language of specifying problems within its subject area. Diagrammatic techniques used in Architecture will be examined to identify those factors that led to their success in communicating architectural concepts and compare those with their counterparts in Software Engineering and Information Systems. 2 Position The main objective of this research is to develop a method with which reusable requirements specifications can be identified as well as introduced at an early stage of the development process. This method should be flexible enough to be incorporated within the system development process. To achieve this objective other sub-objectives will be attempted. These are: Examining ways of identifying common concepts, objects, structures and deliverables that can be reused at the analysis level. Examining representation techniques of requirements specifications within systems development methods in order to identify possible techniques that could support specifications reuse or develop a new one, if the current ones are proven inadequate. 3 Comparison As mentioned in the previous section,the early work of reuse was targeted towards code. The benefits gained from code reuse was constrained by the implementation environment in which the code was initially developed. Limitations faced code reuse include type of operating system, language in which the reusable code was first written and interface problems of the new system(s). The effect of some of these limitations was reduced by the development portable programming languages, e.g. C. However, problems such as poor documentation of previously written code made its reuse unfeasible in many instances. To overcome some of the problems facing code reuse attempts were made to achieve reuse on a higher level. Unfortunately, those attempts moved only a small step to provide not more than program designs which were again tied to a particular environment but easier to reuse. In some cases design specifications were reused more successfuly when they were restricted to a particular application domain [1]. Although some success was reported on domain analaysis research [2],[3] results were difficult to transfer fromone application domain to another. Also, in domain analysis the reused artefacts were only at the design level and were not suitable to reuse at the analysis level. The last decade has witnessed the introduction of many software development methods (e.g. SSADM, JSD, IE) designed to overcome some of the problems increasingly appreciated within the development process. These methods provided a variety of frameworks and techniques with which requirements specifications are documented, described and modelled. CASE tools supporting some of these methods provided repositories within which requirement specifications can be stored and later retrieved. These repositories are considered as a significant starting point for implementing reuse during the requirements analysis stage. However,current CASE tools and development methods rarely provide a methodical and systematic approach for incorporating specifications reuse during analysis. The reuse method (SPHINCs), proposed in this research, will be able to identify the reuse potential of previously developed specifications for new systems requirements. References [1]J. Neighbors,"The Draco Approach to Constructing Software from Reusable Components," IEEE Transactions on Software Engineering, vol. SE-10, pp. 564-576, September 1984. [2]P.Hall, DomainAnalysis, in Integrated Software Reuse: Management and Techniques, Walton, P., and Maiden, N., (editors), Ashgate, UK. 1993. [3]R. Prieto-Diaz, "Domain Analysis for Reusability," in 'Proceedings of COMPSAC '87, IEEE, 1987. Software Reuse by Model Reification F. Luis Neves and Jose N. Oliveira Inesc Group 2361 and Dep. Informatica, Universidade do Minho Campus de Gualtar, 4700 Braga, Portugal Tel: 351+53-604470 Fax: 351+53-612954 Email: fln@di.uminho.pt; Http: http://s700.uminho.pt/fln Email: jno@di.uminho.pt; Http: http://www.di.uminho.pt/jno Abstract This paper builds upon earlier work on systematically calculating implementations from model-oriented specifications based on abstract data types. The calculation process is called reification and is usually done by"hand", requiring some ingenuity and time. The adoption of model-oriented software specification encompasses the ability to classify and compare data structures. The reification of such data models (specifications of software data structures) also provides a powerful reuse mechanism up to isomorphic and in equational refinements. Following the underlying formal calculus (Sets), one can easily demonstrate that, for instance, a certain C++ class can be implemented by the composition of already available ones. Our aim is to develop an automatic "reificator", based on term-rewriting theory, which is intended to take the specification of a data structure, written in the Sets notation, and to refine it until a collection of reusable data models are identified. We also refer that genetic algorithms have the potential to support inequational term-rewriting, such as is required in animating the Sets calculus. This topic is briefly presented. Keywords: Software reuse, model-oriented specification, reification, rewrite, genetic algorithms. Workshop Goals: Learning; presenting reuse experiments. Workshop Groups: Reuse and formal methods, tools and environments. 1 Background The authors were involved in the Sour 1 project for comparing, classifying and retrieving information about large software systems. Sour attempts to improve software developers productivity by introducing techniques for reusing pre-existing software components. Related research on software component knowledge elicitation and classification using the Sets reification Calculus [2, 3] is reported in [4]. 2 Position This paper sketches the idea that software reification calculi such as Sets [2,3] can be of some help in formalizing a simple yet powerful software reuse discipline based on a mathematical notion of a software component. In the approach, a software component is understood as a specification of the component's internal state space (described by set- theoretical constructs) together with a pre-/post-condition pair for each action which can change or observe the component's internal state. A repository of such abstract components has been academically built up [5] which follows a classify by state structure partial-order based on the Sets-term instantiation ordering [4] 2. The Sets Calculus is based on set-theory up to isomorphism. A collection of =-equalities forms the so-called =-Subcalculus. When partial data- structure transformations are present, abstraction invariants arise according to the so-called --Subcalculus. (Informally,while A = B means that A and B are interchangeable data structures, A- B means that only B can replace (implement) A.) The Sets model-reification process uses the laws of these two subcalculi to derive new data models from existing ones, with correctness warranty. Attempts to animate the Sets Calculus have been made recently [6]. A "reificator" is expected soon made of two fundamental components: first, a description language for input of relevant data such as axioms, models, type of reificationand so on; second, the "engine"of the calculus which incorporates,in the current prototype, the hybridization of two theories: genetic algorithms [7] and rewriting systems [8]. 3 Instantiation and Reuse The notion of instantiation is closely related with the reuse problem. It exploits the capability of identifying expressions (in our case, Sets terms specifying software data structures) as particular cases of others. In this paper's setting, software reuse consists basically of applying rewrite rules obtained directly from the Sets laws, in order to rewrite (reify) a software model and decompose it in a collection of sub-models which instantiate pre-existent components (see also [9] in this respect). Sour is the acronym of Eureka 379 project "Software use andreuse" [1]. See [4] also for details on ER ("Entity-Relationship") diagram inversion and classification using this approach. 3.1 Instantiation We proceed to a brief illustration of our strategy, whereby an instantiation rule will be induced from the concrete example which follows. Suppose that we want to implement the following C++ class which associates to each OR (Object Reference) its type and a set of attribute values: #define MAX_A 3 // Cardinal of _A enum _A -OR1,OR2,OR3"; #define MAX_D 1 // Cardinal of _D enum _D -TYPE0"; #define MAX_B 3 // Cardinal of _B enum _B -ATT1,ATT2,ATT3"; #define MAXSTR 255 // String length typedef char _C[MAXSTR]; class X - private: struct - _A A; // A _D D; // D struct -_B B; _C C;" ffBtoC[MAX_B]; // B -> C " ffAtoDxffBtoC[MAX_A]; // A -> D x (B -> C) public: // ... "; In Sets, data structures of this class can be expressed by instatiating the Sets -term 3 A ,! D (B ,! C) Now, consider the following C++ class, which is presumed to be available in the repository 4: class Y - private: _A setA[MAX_A]; //2^A struct - _A A; // A _B B; // B _C C; // C " AxBtoC[MAX_A*MAX_B]; // (A x B) -> C public: // ... "; A B denotes the cartesian product of A and B; A ,!B denotes the set of all partial mappings from A to B. See [3] for details. As a software component implementation, the code of this class should include all the intrinsic functionality, which is omitted here for economy of space. The corresponding Sets specification is the following expression: 2A ((A B) , ! C). >From [3] we know that A ,! (B,! C) _ 2A ((A B ) ,! C) (1) holds, as a particular case of instantiating D = 1 in A ,! D (B ,! C) _ (A ,! D) ((A B) ,! C) (2) that is to say 5: A ,! 1 (B ,!C) _ (A ,! 1) ((A B) ,! C)by(2) _ 2(A1) ((A B) ,! C) by law A ,! B_ 2(AB) = 2A ((A B) ,! C) by law A 1= A which shows that Class Y can be reused in order to implement Class X. 3.2 Reuse The reuse concept may be compared to the resolution of a mathematic equation (or inequation). Suppose we have the following equation x + 2y z =0 (3) in which, given the values of y and z,we want to know the values of x which satisfy the equation. Using some basic mathematical rules, we can write x in function of y and z, i.e. , by rewriting (3) in the form x = f(y;z). In the above equation, this is equivalent to having x = 2y+z (4) >From this point on,we just have to use the well known arithmetical operations to finally obtain the x value. This is the approach we propose for reuse , in particular for data models reuse, i.e., the notion of writing something in function of. >From the "reificator" point of view, we will have that a set of Sets models may be kept in a repository, which is basically a store of reusable material [10]. This is much in the tradition of the classical handbooks in Mathematics, for example in helping to solve integral/differential equations. In the above example, reasoning will proceed by instantiating variables y and zin terms of available information in the repository. The striking difference is that we are dealing with discrete mathematics, a topic rarely found in traditional engineering curricula,which are too much concerned with the mathematics of continuity to leave room for the mathematics of discreteness [11]. This may explain why many "conventional" engineers are so bad software designers. Note that MAX_D = 1, which in Sets is equivalent to saying that _D =1. References [1]Systena and S.S. Software, "Integrated SOUR Software System_Demo Session Manual," tech. rep., SOUR Project, 1994. Ver.1.2, cflSystena & SSS, Via Zanardelli 34 , Rome & Via Fanelli 206-16, Bari, Italy. [2]J. N. Oliveira, "A reification Calculus for Model-Oriented Software Specification," Formal Aspects of Computing, Vol.2, 1-23, 1992. [3]J. N. Oliveira, "Software reification using the sets calculus," in Proc. of the BCS FACS 5th Refinement Workshop, Theory and Practice of Formal Software Development, London, UK, pp. 140-171, Springer-Verlag, 8-10 January 1992. [4]J. N. Oliveira and A. M. Cruz, "Formal Calculi Applied to Software Component Knowledge Elicitation,"Tech. Rep. C19-WP2D, DI/INESC,December 1993. IMI Pro jectC.1.9. Sviluppo di Metodologie, Sistemi e Servizi Innovativi in Rete. [5]J. N. Oliveira, Especificac"ao Formal de Programas. Univ of Minho, 1sted., 1991. Lecture Notes for the UM M.Sc. Course in Computing (in Portuguese; incl. extended abstract in English). [6]F. L. Neves, J. V. Ranito, and J. N. Oliveira, "Implementation Studies about Automatic Model Reification based on the SETS Calculus," 19?? (In preparation). [7]D. E. Goldberg, Genetic Algorithms in Search, Optimization and Machine Learning. Addison-Wesley, 1989. [8]G. Huet, "Confluent Reductions: Abstract Properties and Applications to Term Rewriting Systems," Journal of the ACM, 27(4):797-821, October 1980. [9]J. N. Oliveira and F. S. Moura, "Can Distribution Be (Statically) Calculated?," tech.rep., DI/INESC, 1995.(In preparation). [10]J. N. Oliveira, A Reification Handbook. 19?? (In preparation). [11]J. Cuadrado, "Teach Formal Methods," Byte, p. 292, December 1994. 4 Biography F. Luis Neves holds a degree in Mathematics and Computer Science from Minho University(1992). He is currently a research assistant at Inesc group 2361 (Programming and Formal Methods), sited at the University of Minho Campus, Braga, Portugal. For the last two years,he was fully engaged in the Inesc participation in the Sour Project (EU 379). His main interests are graphical environments, formal methods and genetic algorithms. Jose N. Oliveira is a senior lecturer at the Computer Science Department of Minho University at Braga, Portugal. He obtained his Msc degree (1980) and Phd (1984) in Computer Science from Manchester University, UK. His main research areas are formal specification of software and program calculi. He is also a senior member of Inesc and leader of Inesc group 2361. He was responsible for the Inesc partnership in the Sour project. Refactoring Object-Oriented Software to Support Evolution and Reuse William F. Opdyke AT&T Bell Laboratories 2000 N. Naperville ROAD Naperville, IL 60566-7033 Tel: (708) 979-0730 Email: william.opdyke@att.com Abstract Software often needs to be changed before it can be reused. In our research into refactoring (restructuring) object-oriented software, we have discovered four major reasons why people are reluctant to refactor their programs, even if they accept the reuse benefits. We briefly discuss our approaches for addressing each of these concerns. Keywords: Reuse, Object-oriented software engineering, addressing reuse barriers. Workshop Goals: Learning, networking, advance state of theory of software evolution and reuse. Working Groups: Reuse Process models; domain analysis/ engineering; reuse management; organization and economics; reuse and OO methods and technology, tools and environments. 1 Background During my years at AT&T Bell Laboratories I have been able to view the reuse issue from several different angles. For several years during the mid-1980's, I worked in an applied research department at AT&T Bell Laboratories, studying techniques for supporting large scale, multi-year software development projects. Then, during a four year doctoral research assignment at the University of Illinois, I worked with Ralph Johnson on issues regarding the process of change for object-oriented software. Currently I am part of an AT&T organization planning platform developments to support a range of telephony applications. My doctoral research focused on refactoring object-oriented software, to support evolution and reuse. Refactorings are behavior- preserving program restructurings that can be applied to, for example, separate out parts of a program (design abstractions, reuse components) to make the design of a program clearer and make it easier to add new features. Refactorings can also be applied in some cases to reduce or eliminate redundant parts of a program. The need for refactoring grew out of early experiences in reusing object-oriented software, particularly in the Smalltalk community, as discussed by Johnson and Foote in [1]. My research focused on refactoring C++ programs [2,3,4,5,6]. Currently, research is underway at the University of Illinois into refactoring Smalltalk programs [7]. Don Roberts and I will present a tutorial on refactoring at the OOPSLA '95 conference at Austin. The topics (briefly) described in sections three and four of this position paper are addressed in much further detail in that tutorial. 2 Position 2.1 Introduction Software often tends to be changed before it can be reused. Change is inevitable, as users request new features, external interfaces evolve and designers better understand the key elements of their application. Evolving software to support these changes is a tedious and error- prone process. This position paper focuses on the barriers that we have encountered in our research on supporting the change process for object-oriented software. These barriers are relevant to the general problem of encouraging reuse within an organization. 2.2 Applying Object-Oriented Techniques For at least some of us, an "ideal world" would consist of only fresh start projects, where we understood the domain, and where our funders would pay us until we were satisfied with the results. However, a more realistic scenerio might sound something like this: we are asked to use/extend an existing piece of software, we have a less-than-complete understanding of what we are doing, and we are under schedule pressure to produce! Should we re-write the program? We could apply our design experience, correct the ills of the past and, besides, it would be creative and fun! But, will the new program do all that the old program did, and who will foot the development bill? Should we copy and modify an existing piece of software? This might be expedient, and perhaps demonstrate reuse. But, will we really understand what we are using? Might errors propagate, programs get bloated, program designs get corrupted and the incremental cost of change escalate? In our refactoring research, we have investigated a middle ground: start with the existing software base, incrementally restructure the existing software to extract reusable abstractions and components, clean up class interfaces and inheritance hierarchies, and prepare the program to make subsequent additions of functionality easier. 2.3 Barriers and How We Addressed Them Suppose you accepted (in the abstract) that there would be benefits in refactoring your software. Why might you still be reluctant to refactor your program? We have found four key reasons why people are reluctant to refactor their software, which have implications on the general issue of software evolution and reuse: 1. "I don't understand how to refactor." 2. "If the benefits are long-term, why exert the effort now? In the long term, I may no longer be with the project." 3. "Refactoring code is an overhead activity; I'm paid to write new features." 4. "Refactoring might break the code." The issue of adapting existing code to support new applications is a difficult problem, with many technical and organization implications. While our research primarily focused on the technical concerns, we kept the organization issues in mind as we proceeded in our research. Our approach to addressing the first two of these objections was to characterize the refactoring process in a way that achieved both short term and long term benefits. We learned many insights from studying how versions of our and others' programs evolve over time, and learned from discussions with (and reaading the retrospectives of) experienced developers and researchers. From this, we defined a taxonomy of refactorings and incremental additions of functionalities. For example, when defining a new feature that is a variant on an existing feature, one can define classes (usually abstract classes) that capture the common behavior, and use subclassing to capture the feature differences. One benefit of this approach is that the abstract classes not only provide a way to leverage existing code for near- term benefits, but they may represent abstractions that will be useful in defining additional, similar features later. Our approach to addressing the latter two of these objections was to provide automated assistance, to help increase the speed (i.e., reduce the overhead) of program restructuring. Often, it is more difficult to determine whether a refactoring can be safely performed than it is to perform the refactoring once it is known to be safe. There can be many, sometimes subtle interdependencies within a program that making changing any part of the program difficult. The analysis of program dependencies, and checking that behavior is preserved across program restructuring, is a tedious and error-prone task and one where automated tools can help. 2.4 Some Conclusions In conclusion, while there are longer-term benefits that can be achieved by making existing software more evolvable and reusable, there are significant challenges to getting people to invest the effort to make their software more reusable. Learning from the past, motivating short-term benefits, providing automating assistance and addressing the backward compatibility (behavior preservation) issues are all important in motivating the acceptance of reuse approaches. Other issues, such as reward mechanisms and the opennesss of an organization to change, also influence the success of reuse efforts. 3 Comparison Casais [8] (Esprit Project) and Lieberherr et al [9] (Demeter project) have also studied issues on restructuring object-oriented software. Their efforts have considered issues such as increasing information hiding [9] or eliminating redundant definitions of variables [8]. Our focus has been upon providing a set of restructurings that clarify the design of a program to the designer, which sometimes but not always involves reducing code size or increasing information hiding. Work in object-oriented database schema evolution (eg: [10] has addressed similar issues to ours, although with a focus upon persistant data rather than upon programs. We applied many of the object-oriented design techniques embodied in the CRC approach [11], albeit for redesign rather than for the up front design task. Some of the relationships of design patterns and refactoring are discussed by Brian Foote and myself in [6]. References [1] R. E. Johnson and B. Foote. "Designing Reusable Classes." Journal of Object-Oriented Programming, 1(2):22-35, 1988. [2] W. F. Opdyke and R. E. Johnson. Refactoring: An Aid in Designing Application Frameworks and Evolving Object-Oriented Systems. In Proceedings of 1990 Symposium on Object-Oriented Programming Emphasizing Practical Applications (SOOPPA '90), Poughkeepsie, New York, September, 1990. [3] W. F. Opdyke. Refactoring Object-Oriented Frameworks. Ph.D. thesis, University of Illinois at Urbana-Champaign, 1992. Available as Technical Report No. UIUCDCS--R--92--1759. Postscript: /pub/papers/refactoring/opdyke-thesis.ps.Z on st.cs.uiuc.edu. [4] W. F. Opdyke and R. E. Johnson. "Creating Abstract Superclasses By Refactoring." In Proceedings of CSC '93: 1993 ACM Computer Science Conference, Indianapolis, Indiana, February, 1993. Postscript: /pub/papers/refactoring/refactoring-superclasses.ps on st.cs.uiuc.edu. [5] R. E. Johnson and W. F. Opdyke, "Refactoring and Aggregation." In Proceedings of ISOTAS '93: International Symposium on Object Technologies for Advanced Software, Kanazawa, Japan, November, 1993. Postscript: /pub/papers/refactoring/refactor-aggregation.ps on st.cs.uiuc.edu. [6] B. Foote and W. F. Opdyke, "Life Cycle and Refactoring Patterns that Support Evolution and Reuse." Presented at First Conference on Pattern Languages of Programs (PLOP '94), Monticello, Illinois, August, 1994. In "Pattern Languages of Programs" (James O. Coplien and Douglas C. Schmidt, editors), Addison-Wesley, May, 1995. [7] R. Johnson, J. Brant, and D. Roberts, "The Design of a Refactoring Tool." Presented at ICSE-17 Workshop on Program Transformation for Software Evolution, Seattle, WA., April, 1995. [8] E. Casais. Managing Evolution in Object Oriented Environments: An Algorithmic Approach. Ph.D. thesis, University of Geneva, 1991. [9] K. J. Lieberherr and I. M. Holland. "Assuring Good Style for Object-Oriented Programs." IEEE Software, pages 38-48, September, 1989. [10]W. Kim. Introduction to Object-Oriented Databases. MIT Press, 1990. [11]R. Wirfs-Brock, B. Wilkerson, and L. Weiner. Designing Object- Oriented Software, Prentice-Hall, 1990. Bibliography Bill Opdyke is a member of the technical staff at AT&T Bell Laboratories, where he has focused on intelligent network and decision support applications of object-oriented technology. He is currently involved in platform planning for telephony applications. He is on the editorial board for an AT&T internal publication devoted to software (and hardware) reuse issues. Bill's doctoral research at the University of Illinois focused on refactoring C++-based object- oriented frameworks, supervised by Ralph Johnson. Measuring the Level of Reuse in Object-Oriented Development Jeffrey S. Poulin Loral Federal Systems MD 0210, Owego, NY 13827 Tel: (607)751-6899 Fax: (607) 751-6025 Email: poulinj@lfs.loral.com Abstract Defining what software to count as "reused" software constitutes the most difficult and meaningful problem in reuse metrics. Experience reports routinely report impressive reuse levels and benefits due to reuse. However, the reader cannot trust the report without understanding what the report counted; e.g.,modified software, ported software, generated software,etc. To date, only one model exists for defining a consistent method of counting and reporting software reuse. Although this model applies equally to various development paradigms to include object- oriented programming, this paper clarifies the model with respect to objects and expands on issues related to object-oriented reuse metrics. Keywords: Software Reuse, Reuse Metrics, Object-Oriented Programming Workshop Goals: Learn and discuss current reuse issues and methods. Working Groups: Useful and collectible metrics; Domain analysis and engineering; Software Architectures 1 Background To date, only one model exists for defining a consistent method of counting and reporting software reuse [1]. This model methodically makes recommendations as to what to count as a Reused Source Instruction (RSI). The rationale for the model applies equally to the functional, procedural, and object-oriented (OO) paradigms because the rationale does not depend on any paradigm-specific methods. However, recent work in OO metrics often either fails to address this issue or the OO work identifies the need for a common counting model. As OO metrics mature and the community identifies the most meaningful metrics and ranges of values for each [2],the metrics must include consistent definitions to serve as a basis for comparing results. 2 Position The definition of Reused Source Instruction (RSI) applies to all programming paradigms. 3 Approach This paper describes the three primary OO reuse methods and briefly discusses the benefits and drawbacks of each. It compares each of these methods to the analogous practice in traditional procedural development. Finally, the paper presents some issues that an organization should address when instituting reuse metrics for OO development. 3.1 Reuse in the Object-Oriented Paradigm Expectations of high reuse levels provide one of the most important motivations for OOsoftware development. In fact, the OO paradigm provides three primary ways to support reuse: 1. Classes. The encapsulation of function and data provides for their use via multiple instantiation and in aggregation relationships with other classes. 2. Inheritance The extension of a class into subclasses by specializing the existing class allows subclasses to share common features. 3.Polymorphism The reduction of program complexity by providing thesame operation on several data types via several implementations for a common interface. Each of these reuse approaches involves some trade-offs in terms of application and desirability. These trade-offs include the "cleanliness" of the reuse; in other words, whether or not each component has a traceable heritage of evolution and consequently whether or not changes to a component will result in changes throughout the system [3]. For example,creating a subclass and overloading a method through polymorphism can cause unexpected results at execution time in the case of an unintentional name conflict. Modifying source code, whether for the method implementation or simply the interface, will propagate changes to all parts of the system using that method. Alternately, simple subclassing (without polymorphism) or use of a method without modification of source code provides for clean and safe reuse. This view of OO reuse corresponds to the subsequent testing requirements incurred by the implications of inheritance and polymorphism [4]. For testing purposes, each inherited methods requires retesting and each possible binding of a polymorphic component requires a separate test. The extent of testing depends on the "cleanliness" of the reuse. If the features of OOlanguages do not guarantee reuse [5],they certainly do not guarantee good programming. In traditional procedural development programmers should use language features such as macros, functions, and procedures when they must repeatedly execute the same operations. The programmer may use techniques (depending on the implementation language) such as variable macros (a method for overloading macro definitions) or generic packages (a method for overloading abstract data types in Ada). We consider the use of these language features and techniques"good programming" or "good design."Likewise, we expect OO programmers to use the language features at their disposal (e.g., classes, inheritance,and polymorphism) to abstract features common to objects and to minimize the amount of code they must write and maintain. In traditional development, we consider a component "reused" when the programmer avoided having to write software by means of obtaining it from "someplace else." Within small teams or organizations, we expect the use of macros, functions, and procedures for common functions. Repeated calls to these components do not count as reuse; calling components simply uses the features of procedural languages. However, if the organization obtains the software from another organization or product we count it as reuse. Likewise, a small team or organization may build a class hierarchy in which subclasses incrementally specialize the common aspects of parent classes. We expect subclassing, inheritance, and polymorphism in OO development. Of course, multiple instantiations of an object do not count as reuse for the same reason multiple calls to a function do not count. Reuse in OO programs comes from the use of classes and methods obtained from other organizations or products, thereby resulting in a savings of development effort. I call the issue of determining when an organization has saved effort by using software from another organization or product the boundary problem. In practice, however, boundaries become obvious due to the structure of the organization (the people) and/or the structure of the software (in most cases management structure maps to the software structure). On small projects, "reused" classes come from pre-existing class libraries, commercially licensed class libraries, or other projects. On large projects,the many organizations working on the project will reuse each other's software as well as reuse software from commercial sources and reuse software perhaps developed for that purpose by a team dedicated to building shared classes. 3.2 Issues One issue involves counting"extra" code in a reused class. In traditional development, generalizing a component may require additional code. Take the case of a variable macro instantiation. Do you count reuse based on: 1.the code produced in that instantiation. 2.the average code produced over all possible instantiations. 3.the maximum code produced of all possible instantiations. 4.the macro source code needed for that instantiation including error checking on input parameters and environment variables. 5.the total macro source, to include code for all possible macro instantiations and the error checking for each, in which case you may give reuse credit for a significant amount of software the programmer would not have written. Likewise, generalizing objects may require additional code to support many possible applications. Take the case of a reused class stack, which contains numerous methods for testing the status of and manipulating the stack. However, a developer may only need thepush and pop methods. Do you count reuse based on: 1.code used by the developer (push, pop) 2.total code in the reused stack class. In practice I have found that this occurrences happens rarely, in part because other constraints (such as on object code size) restrict the practical ability to include more code than a developer needs. In addition to encouraging the use of pre-existing classes, this realization supports the counting of the entire class versus trying to determine the subset of methods actually used. In fact, data collection affects reuse metrics because an analyst must usually work with available or easily obtainable data. For traditional development, the reuse analyst must know the size of each reused component, the total size of the software,and the developers and users of each component. Likewise,the OO analyst must know the size of each class, the total size of the program, and all the developers and users of each class. Currently, traditional metrics use "lines of code" for measuring component size; although this measure holds for OO, other measures of effort may include the total number of classes or the total number of methods. 3.3 How to quantify reuse in OO programs The definition of reuse and what should count as a Reused Source Instruction (RSI)(or reused objects) applies to all programming paradigms. The use of language features such as 1.functions, procedures, generics, and (variable) macros in the procedural paradigm 2.classes, inheritance, and polymorphism in the OO paradigm do not, by themselves, constitute "reuse" as much asthey represent a particular method to solve a problem. The rationale for defining reuse in any paradigm depends not on language features but rather on an assessment of whether someone saved effort through the use of software they obtained from someplace else; in short, software they did not have to write. The solution to determining reuse levels in programs lies in the boundary problem. Weexpect organizations to call procedures and inherit methods that the organization developed for its own use. When an organization avoided development by using software it obtained from someplace else,then we say it "reused" the software. 4 Comparison Numerous references cite reuse as a principal benefit of object-oriented technology. Kain admits the limited availability of quantitative evidence of reuse in object-oriented programming and observes that few experience reports say how they measure reuse [6]. Kain cites evidence that some reports count reuse as the use of classes and methods across applications (as explained above) and not, for example, inheritance within an application. Other reports count inheritance as reuse of the superclass; these differences prevent the comparison of OO experience reports. Although Kain recognizes the need to evaluate OO reuse in the context of multiple teams and organizations (not individual programmers), Henderson-Sellers claims reuse comes from subclassing via inheritance and from multiple instantiations of the same class [7]. Although he focuses on the reuse of classes from reusable class libraries, he includes references to the reuse of classes from one project to another and from classes built for reuse within the organization. Henderson-Sellers discusses OO reuse economics using a simple Cost-Benefit Model but he fails to compare the model to most other work done in the field. References [1]J. Poulin,"Issues in the Development and Application of Reuse Metrics in a Corporate Environment,"in Proceedingsof the 5th International Conference on Software Engineering and Knowledge Engineering, (San Francisco, CA), pp. 258-262,16-18 June 1993. [2]J. Poulin,"Panel: Metrics for Object-Oriented Software Development," in 6th IBM Object-Oriented Software Development Conference, (Toronto, CAN),19-23 July 1993. [3]A. Cockburn,"The Impact of Object-Orientation on Application Development," IBM Systems Journal, vol. 32, no. 3, pp. 420-444, 1993. [4]R. V. Binder, "Testing Object-Oriented Systems: A Status Report," Crosstalk, vol. 8, no. 4, pp. 16-20, April 1995. [5]M. Griss, "PANEL: Object-Oriented Reuse," in Proceedings of the Third International Conference on Software Reuse, (Rio de Janeiro, Brazil), pp. 209-213, 1-4 November 1994. [6]J. B. Kain, "Making Reuse Cost Effective," Object Magazine, vol. 4, no.3, pp. 48-54, June 1994. [7]B. Henderson-Sellers, "The Economics of Reusing Library Classes," Journal of Object-Oriented Programming, vol. 6, no. 4, pp. 43-50, July- August 1993. 5 Biography Jeffrey S. Poulin, works as a Senior Programmer with Loral Federal Systems (formally IBM Federal Systems Company) in Owego, NY. As a member of the Advanced Technology Group, he serves as the Principal Investigator and leader of research into new open systems standards- compliant technologies in the areas of distributed UNIX system management, networking, and object-oriented software development. His responsibilities in Owego include lead architect for the LFS reuse program, technical lead for a contract in support of reuse across the U.S. Army,and the reuse strategy for a major Army MIS development program. From 1991-1993 Dr.Poulin worked in the IBM ReuseTechnology Support Center (RTSC)where he led the development and acceptance of the IBM software reuse metrics and return on investment (ROI) model. He also organized, edited, contributed to, and published a complete library of resources on the IBM Reuse Method. Active in many professional activities, Dr. Poulin has published over 30 papers on software measurement and reuse. In addition to serving on numerous conference committees and panels, he chaired the IEEE Computer Society 6th Annual Workshop on Software Reuse (WISR'93) in November, 1993. A Hertz Foundation Fellow, Dr. Poulin earned his Bachelors degree at the United States Military Academy at West Point and his Masters and Ph.D. degrees at Rensselaer Polytechnic Institute in Troy, New York. Domain-specific Software Architecture Based on a Building Block Method Muthu Ramachandran Software Engineering Applications Group Philips Research Labs Redhill RH1 5HA, UK Email: ukrrama@prl.philips.co.uk Tel: +44-1293-815951 Fax:+44-1293-815500 Email: ukrrama@prl.philips.co.uk Abstract This paper discusses a method for designing domain-specific architectures for a family of telecommunication systems. This method has evolved to support reusability, configurability, testability, and conceptual integrity. Keywords: Reuse, Building Block Method, Software Architecture Workshop Goals: Networking Working Groups: Reuse process models, Design guidelines for reuse, Domain analysis, Reuse and OO methods. 1 Background Philips Kommunication Industry (PKI)has developed a method to describe the architectural needs for the telecommunication applications. We, in research,took their initial working level ideas and tailored to meet their architectural and reuse requirements. This method supports reuse in large scale in terms of subsystems. After tailoring the concepts, criteria and guidelines, PKI is able to achieve more than 60% reuse across the family. 2 Position After tailoring the method and concepts, the new method has a support for: 1.Architectural reuse 2.Reuse guidelines for design reuse 3.Conceptual integrity 4.Design for test, which has been ignored by the reuse community 5.Reuse by a large collection of construction set (group of objects and architecture that relate to the conceptual integrity of a family) and architectures. 2.1 Building Blocks Understanding the concepts behind a method is important when considering testing of reusable software. Basically focus your test principles based on the development concepts of a family of reusable systems. A Building Block (BB) is a collection of reusable object classes that represent a unit of system functionality. It is also a basic unit of a system architecture. Each BB's separates specification (its interfaces) and implementation. Furthermore there are two kinds of building blocks such as an application BB and a generic BB. Application BB's are createdfrom existing generic BB's to achieve high granularity of reuse. Each units of reusable components developed to achieve high granularity of reuse as well as configurability and conceptual integrity of the system. Configurability and conceptual integrity are the main attributes for achieving reuse in this application family. Our notion of quality attributes are high granularity of reuse (subsystems, architectures and product family), configurability and conceptual integrity, testing, and documentation. The Building Block Development Method is a development methodology adopted for this project. It is based on the principles of architecture- oriented decomposition and incremental layering, in addition to object- oriented concepts such as object class (building block), generics, information hiding, and run-time binding. This makes this method superior and rich in offering advanced concepts to support reuse. This method has improved PKI productivity by more than 60% increase in reuse across the family product line. 3 Comparison When we compare to existing work on architectural reuse such as SEI's work with DSSA and Loral Federal Systems, etc, we have achieved reuse and quality by various concepts of the method [1, 2, 3]. Our guidelines on reuse and design for test are comprehensive to Booch's notion of a reusable component. References [1]W. Tracz, "DSSA Frequently Asked Questions," in ACM SIGSOFT, SE Notes, 1994. [2]E. Mettala and M. Graham, "The domain specific software architecture program , CMU/SEI-92-SR-9," tech. rep., June 1992. [3]R. Hayes-Roth and W. Tracz, "DSSAtool requirements for key process functions ,version 1.0," tech. rep., October 1993. Biography Dr Muthu Ramachandran is currently a senior research scientist at Philips Research Labs, researching into reuse methods for DSSA, testing, OO reuse. Previously he was a senior lecturer at Liverpool John Moores University teaching specialist courses on reuse and has published more than 30 articles on reuse. He did his doctoral thesis on development for reuse at Lancaster University. A Fuzzy Query Language for a Software Reuse Environment Antonio Nestor Ribeiro Fernando Mario Martins Inesc/ Universidade do Minho Campus de Gualtar, 4700 Braga, Portugal Tel: +351 053604470 Fax: +351 053 612954 Email: fanr,fmmg@di.uminho.pt Abstract The effectiveness of the reuse based approach to software development is strongly dependent on the underlying classification scheme and retrieval mechanism. Based on the Prieto-Diaz faceted classification scheme, this paper proposes a logical representation for software components, called Abstract Objects (AO), and a non-strict, fuzzy comparison strategy which is the basis of a fuzzy query language. This strategy goes beyond the common strict comparison implemented in usual query languages because it expands the usual comparison bounds from a strict to a fuzzy reasoning method. This allows to find reusable software components which are at a certain semantical distance(similarity) from a given one. The measurement of similarity is based on a Conceptual Graph in which conceptual distances are defined. The presented strategy uses Prieto- Diaz faceted classification method. On the basis of a distance calculus metrics the end-user is able to make queries by using both enumerative, attributive and faceted descriptions. Keywords: Reuse environments, fuzziness, faceted classification, querying with uncertitude. Workshop Goals: Learning, presenting reuse experiences Working Groups: Reuse and formal methods, tools and environments 1 Background Reuse is a process whereby previously found software solutions are compared with new requirements. It is therefore mainly a comparison or analogical process. Two different problems then arise. On one hand, because it is not feasible to compare the "real", physical, software components, a logical representation must be found for them and the comparison will deal with these logical counterparts. The classification scheme has to provide for the mapping from physical software components to their logical representations. On the other hand, the retrieval mechanism will be based on the devised comparison algorithm. Since 1992 we have been involved in an Eureka software project,called Sour (Sour is the acronym of the Eureka 379 project which stands for "Software Use and Reuse") intended to develop a Meta-Case system based on a software classification and reuse strategy following the Prieto-Diaz faceted scheme. 2 Position 2.1 Introduction This paper describes the query mechanism used in the Sour system which used a fuzzy reasoning [1,2 ,3 ]. The Sour information model is based on an hierarchical object structure, resembling a semantic network. The abstract objects (Sour's unit of information) are instances of classes inheriting a set of attributes. This encompasses the usual attributive description used in many repository- based management systems. This attributive description doesn't support the human reasoning flexibility because it lacks the ability to cope with vagueness and analogy. These properties are of great value in a context where the user wants to find software components compliant to a set of desired properties[4]. Combining a faceted view of the repository with a conceptual graph relating the facets, a fuzzy reasoning mechanism over abstract-objects was implemented. Asa consequence of this classification strategy, the query system has to deal with both strict and fuzzy sentences of the query language. The query system is supported both by the conceptual graph and by the semantical distance calculus algorithm. In this paper we present a query language developed for the Sour system where it is possible to support the retrieval of software components that are similar at a given degree of similarity. 2.2 The Conceptual Graph Fuzziness is supported in the Soursystem by using a graph in which the possible values for the facets are related with each other through a specified distance. The facets are the leaves of the graph and are connected to concepts. Concepts are needed to calculate the distance between two facets. The Conceptual Graph, CG f(V1; V2; d) : V1; V22 V ^d 2 1::100g, is a set of nodes and a set of arcs weighted by the semantical distance between the two nodes. A path between two nodes V1 and V2, isdefined as a sequence of arcs starting at V1 reaching V2. The distance between two nodes is calculated by the following rule: if a path exists between them, the distanceis given by the minimum of the product of the weights of the arcs; if between two nodes V1 and V2 there isn't a path between them but a transitive successor VS may be found, let Dv1 and Dv2 be the distances from V1 and V2 to VS. The distance between V1 and V2 is given by (Dv1+ Dv2)=2. 2.3 Query Language The interaction between a user and the repository of reusable software components must follow a well defined language. This language will control both the visual layer and the access to the repository. The mechanism of fuzzy tuning allows for the construction of queries which result is a set of objects at a certain degree of similarity to a given object. This degree of similarity has to be specified by the user. Given a similarity value all the objects in the repository at a similarity measure greater or equal will be candidates for reuse (solutions). A low similarity level will result in a larger set of candidates. However, loose similarity requirement will select objects needing more adaptation effort,therefore less reusable. If the intended similarity level is near 100% then the kind of behaviour expected in the retrieved objects is similar to the one given by just a strict comparison. If the similarity frontier is near 0% the retrieved objects may not have significant resemblance with the desired result. The query language will accept sentences where it is possible to adjust the "grain" of similarity. The archetype[5] of a typical query sentence is GET ALL OBJECTS CLASS= "class" AND being = j = FACNAME= "facname" AND FACVALUE= "facvalue" [AND DIST= ] = ATTNAME= "attname" AND ATTVALUE= "attvalue" = [1..100] 2.3.1 Terminological Discrepancy Another problem that must be regarded is the one related to the terminological issue. The ability for an end-user to reason about the repository strongly dep ends on the query language [6]. It is thus desirable to guarantee that a query sentence may be made using different Lexical Thesaurus. The process of query synthesis will then be preceded by a terminological standardization one. This standardization process will be accomplished by using a Lexical Thesaurus System where grammatical declinations and synonymous are represented. 3 Comparison Our Meta-Case platform proposes a classification scheme based both on faceted and coarse attributive classification. The faceted classification is intended to be a a fine evaluator of cases in which coarser search- methods can not provide effective hints to latter reuse. A somehow similar strategy is proposed in Tellos[7]. Tellos also assumes two different classification strategies. The first one consists on a predefined set of features found adequate in order to describe objects within a given domain. The second one assumes that objects are instances of existing classes. Tellos reasoning is made upon a theoretical basis for the comparison and a distance model for similarity calculus. The approach described in [3]also assumes a faceted classification scheme. Queries in this system are seen as templates of objects with the desired facets values specified. The result of a query is a ranked list of similar objects. References [1]R. Prieto-Diaz and P. Freeman, "Classifying Software forReusability," IEEE Software, vol.4, no. 1, pp. 6-16, 1987. [2]R. Prieto-Diaz,"Implementing Faceted Classification for Software Reuse," Communications of the ACM, vol. 34, no. 5, 1991. [3]E. Ostertag, J. Hendler, R. Prieto-Diaz, and C. Braun, "Computing Similarity in a Reuse Library System: An AI-Based approach," ACM Transactions on Software Engineering and Methodology,vol. 1, pp. 205- 228, July 1992. [4]J. N. Oliveira, "Fuzzy Object Comparison and Its Application to a Self- Adaptable Query Mechanism," 1995. Invited paper, Sixth International Fuzzy Systems Association World Congress. [5]F. M. Martins and J. N. Oliveira, "Archetype-Oriented User Interfaces," Computer & Graphics, vol. 14, no. 1, pp.17-28, 1990. [6]H. L. Larsen and R. R. Yager, "The use of relational thesauri for classificatory problem solving in information retrieval and expert systems," tech. rep., Department of Computer Science, Roskilde University, Denmark and Machine Intelligence Institute, Iona College, USA, 1991. [7]G. Spanoudakis and P. Constantopoulos, "Similarity for analogical software reuse: A conceptual modelling approach," in Advanced Information Systems Engineering (C. Rolland, F . Bodart, and C. Cauvet, eds.), no.685, pp. 483-503, Springer-Verlag, 1993. Biography Antonio Nestor Ribeiro is an assistant lecturer at the Computer Science Department of the Minho University at Braga,Portugal. He is currently doing his Msc thesis upon the prototyping of concurrent interaction systems. He is an investigator of the Inesc group 2361, called Formal Methods of Programming, being a member of the team responsible for the Intelligent Query Sub-system of the Sour project. Fernando Mario Martins is a senior lecturer at the Computer Science Department of the Minho University at Braga, Portugal. His main research interests are human machine interface, object oriented systems and formal methods. He is a senior member of the Inesc group 2361. In that quality he was co- responsible for the Sour project. Supporting Framework Evolution with Refactorings Don Roberts John Brant University of Illinois Department of Computer Science Tel: (217)244-0431 Email: fdroberts,brantg@cs.uiuc.edu Abstract One of the major problems with reusable software is that modifications to the interface of any component become difficult. Both the design and code that uses the software must also be modified. Often, it is not possible to modify all uses since the person modifying a reusable component does not have access to every use of that component. In this paper we discuss a method for asynchronous updating source code by using refactorings. Keywords: Frameworks, Refactoring, Object-Oriented Programming and Design, Maintenance, Software Evolution Workshop Goals: Learning; Networking; Determining feasibility of proposed approach. Working Groups: Reuse management, organization and economics; Reuse and OO methods and technology; Tools and environments 1 Background One of the more successful approaches to producing reusable software is the development of object-oriented frameworks for particular application domains. Examples of this type of software include the HotDraw framework for graphical editors [1] and the Model-View- Controller framework for user interfaces[2]. Developing truly reusable frameworksis an iterative process. System designers develop several related applications and extract the commonalities, which become the key components of the framework. As the developers derive additional applications based on the framework, they discover shortcomings in the original design that they must correct. We have worked with several different frameworks and have recognized many similar transformations that are common to the framework development process. 2 Position Frameworks are a good way to reuse both design and code. However, as frameworks evolve and their interfaces change, the advantages of using a framework are lessened. Not only are the developers responsible for performing normal maintenance activities, they must also evolve their programs in accordance with the evolution of the framework. This adds overhead to using the framework. Currently, developers of frameworks take one of two approaches. In the first approach,the developer defines the interfaces to a framework when it is released. Once the interfaces are defined, they never change. This is the approach taken by Microsoft's Common Object Model. Any modifications to the framework must preserve the interface, drastically reducing the type of evolution that can occur. The benefit of this approach is that users of the framework do not have to update their software whenever a new version is released. The second approach to this problem is one adopted by ParcPlace with their Smalltalk programming environments. In this approach, the designer of the framework recognizes that the design will evolve and, hopefully, improve over time. To fully allow this to occur,the interface to the reusable code must change. The problem, of course, is that if interfaces change, user's code must be updated. This is a time consuming and, one might argue, unproductive task. The paradox that arises is that users want the framework to evolve, but they are not willing to devote the resources that are necessary to allow their program to stay synchronized with it. 2.1 Refactoring One technique that aids in the design of reusable frameworks is refactoring. William Opdyke defined a refactoring as a behavior- preserving transformation that improves the design of an object-oriented system [3]. Typically a refactoring consists of a transformation to be performed on the program along with a set of preconditions which, if satisfied, ensure that the behavior of the transformed program will be identical to the original. Examples of refactorings range from the low- level, such as rename a method, to the high-level, such as convert inheritance to aggregation. In addition to using refactorings to evolve frameworks, refactorings can also be used to convert applications to use updated versions of the frameworks. Currently, whenever a vendor updates a framework, customers who use that particular framework must spend time converting their applications that are based on the framework to work with the new framework. But with an integrated refactoring environment, when the vendor releases a new version of a framework, they would also include a set of refactorings that will transform programs based on the old framework to the new version. This would greatly ease the transition. An automatic refactoring system might not be able to convert the entire system since often functionality is added. However,even if it could convert 90% of an application, this would be 90% less work that the customer would have to perform. There are two extensions to this system that we are considering. First, since all the transformations cannot be performed by automatic refactorings, provide a mechanism that will notify the user of portions of their program that must be updated to match the new framework. Another solution to this problem is to allow the framework developer to include non-behavior-preserving transformations in addition to the refactorings. 3 Comparison Kingsum Chow has presented a method to handle interface modifications within reusable code [4]. In his paper, he defines two types of maintenance: synchronous maintenance, which is the maintenance activity that can be done at the time of the change to a piece of code, and asynchronous maintenance, which are maintenance activities that cannot be performed at the time of the change to a piece of code. If designers change the interface to a library that is being reused, asynchronus maintenance results. Chow developed his ideas with C++ in mind, although his research has not progressed to the point of a workable tool. In his approach, the changes that must occurin the user's code are embedded within the interface files (.h files inC++). In our system, which was developed with Smalltalk in mind, the refactorings are distributed separately from the code itself. Additionally, we have not addressed the problem of recompilation of the user's code since Smalltalk is a dynamically compiled environment. If either Chow's or our approach is implemented in C++, this concern must be addressed. Ira Baxter proposed another system that is similar to ours [5]. His system transforms designs, written in a specification language, into executable code. To reduce the costs involved in changing a design, he proposes that the derivation that transformed the original design be stored along with the executable program. Then, when the design changes, the system will reuse as many of the derivation steps from the original transformation as possible in the new derivation, reducing the amount of work required. Our system performs source-to-source transformations rather than design-to-source transformations. However, both systems consider transformations to be first-class entities that are to be stored and performed at an arbitrary point in the future. References [1]J. M. Brant, "Hotdraw," Master's thesis, University of Illinois, Jan. 1995. [2]G. E. Krasner and S. T.Pope, "A cookbook for using the model-view- controller user interface parface paradigm in Smalltalk-80," Journal of Object-Oriented Programming, vol. 1, no. 3, pp. 26-49, 1988. [3]W. F. Opdyke, Refactoring Object-Oriented Frameworks. PhD thesis, University of Illinois, 1992. [4]K. Chow,"Program transformation for asynchronous software maintenance,"in Proceedings ICSE-17 Workshop on Program Transformation for Software Evolution (W. Griswold, ed.), April 1995. [5]I. D. Baxter, "Design (not code!) maintenance," in Proceedings ICSE-17 Workshop on Program Transformation for Software Evolution (W. Griswold, ed.), April 1995. 4 Biography Don Roberts is doctoral student in the Deparment of Computer Science at the University of Illinois. His research interests in the object-oriented programming and design with an emphasis on refactoring. He is currently developing a tool for automatically refactoring Smalltalk programs. For his MS, Mr. Roberts developed register allocation algorithms for the Typed Small talk optimizing compiler. Mr. Roberts received both his MS (1992) and BS (1990) from the University of Illinois. John Brant is a doctoral student in the Department of Computer Science at the University of Illinois. His research interests are in object-oriented programming and design. He is currently working on a business model framework for Caterpillar, as well as a tool for automating source code transformations. For his MS, Mr. Brant worked on the HotDraw framework for structured drawing editors. Mr. Brant received both his MS (1995) and BS (1992) in computer science from the University of Illinois. Domain Modeling Techniques for Representing Commonality and Variability: Towards A Comparative Framework Mark A. Simos Organon Motives 36 Warwick Road Watertown MA 02172 Tel: (617) 625-2170 Fax: (617) 628-6010 Email: simos@media-lab.mit.edu Abstract Domain analysis (DA) is often described as analysis of commonality and variability across multiple systems or subsystems within a specific application domain. Developers and practitioners of DA methods have adopted diverse approaches to representing this commonality and variability in explicit models. Previous attempts to compare DA methods have focused on the methods in their entirety. This position paper proposes a useful and tractable first step: an initial comparative framework for commonality and variability representation strategies in DA. We first report on recent progress in structuring the Organization Domain Modeling (ODM) method to allow integration of a core domain modeling process with diverse domain modeling representations. We then suggest some general requirements for such representations. The proposed framework characterizes different approaches in terms of two major attributes: relative closeness of coupling between system and domain models, and in terms of semantic expressiveness. We hope to use the workshop as an opportunity to collaboratively review, refine and extend the framework to describe advantages, risks, and implementation issues for various approaches. Keywords: domain modeling, domain analysis, commonality, variability, representations, taxonomic modeling Workshop Goals: Opportunity to work intensively with researchers and practitioners in the field to develop useful consensus positions that will aid progress in the field. Working Groups: Domain analysis/engineering; Reuse process models; Reuse terminology standards; Reuse handbook 1 Background A major focus of the authorÕs recent work has been development of a systematic approach to domain engineering called Organization Domain Modeling (ODM). The ODM Guidebook Version 1.0 has recently been completed under the auspices of the ARPA STARS Program [10]. The guidebook was developed in collaboration with Richard Creps and Carol Klingler of Loral Defense Systems (formerly Unisys Government Systems Group), and Larry Levine (Organon Motives). A key innovation of the new formulation of ODM is to identify what we term the core domain modeling life cyle and to differentiate it from a number of supporting methods. The core domain modeling life cycle includes processes, workproducts and methods central and particular to the domain engineering mission. Supporting methods include a number of technical areas such as system engineering, reengineering, and process modeling, and non-technical areas such as market analysis and qualitative data acquisition methods. Each supporting area is essential to carrying out activities that are part of domain engineering, but involves techniques that are well- established outside the context of domain engineering, and for which a variety of alternative approaches are available. For example, steps for systematically scoping domains are included in the core life cycle; process modeling techniques, while employed in various portions of the life cycle, are not part of the core. Separation ofprocess and representational aspects is also fundamental to this structure. Process aspects deal with the formal or informal sequence of activities: planning the DA project, selecting, scoping and defining domains, gathering domain information from various sources, analyzing and representing domain information in some modeling representation, and (in the latter phase of domain engineering) using the domain model as a basis for engineering reusable software assets for applications in the domain. Representational aspects concern specific notations and associated semantics for the domain model itself, and other models (e.g., process models, system models) used at various stages in the DA process. Separating these aspects makes ODM more flexible and adaptable to needs of different organizations and domains, since the method can be tailored to allow use of different representations, even multiple, complementary representations for a single domain. Of course, these two aspects cannot always be strictly independent; some representations embed assumptions about the methods and processes for their construction and vice versa. 1.2 Representations of Commonality and Variability The taxonomic modeling supporting method is a critical technical area that must be addressed to perform domain engineering. By taxonomic modeling we refer, not exclusively to hierarchical and/or inheritance-based modeling techniques, but more generally to any representations used to model commonality and variability across applications in the domain. Isolating process from representational aspects of taxonomic modeling as a supporting method area has proved one of the most difficult parts of our restructuring effort. In our initial experience, distinguishing system from domain modeling representations seemed to be a major technology transfer obstacle for DA. If domain engineering is Òall aboutÓ modeling commonality and variability, how can we characterize taxonomic modeling representations as a supporting method? Our experience, however, suggests that it is feasible to enforce this separation. The major application of ODM to date has been with the Army/STARS Demonstration Project at CECOM SED, Ft. Monmouth, New Jersey [9, 12]. This project integrated the ODM method with use of the Reuse Library Framework (RLF) as a domain modeling tool. (RLF implements a structured inheritance network formalism for domain modeling, using capabilities related to but not identical to object-oriented modeling techniques [8].) Other small-scale pilot projects using an ODM-based approach have been performed under the leadership of Patricia Collins of the Hewlett-Packard Corporate Engineering Group [3]. Within HP, some groups resisted the idea of doing domain modeling using a structured inheritance-based representation such as that supported by RLF. Other groups had already shifted to an object-oriented (OO) development paradigm, and used OO-based representations. Each project has reported benefits to applying the ODM process model, for example, with respect to systematic techniques for scoping and bounding domains and documenting conceptual relations between domains. These benefits appear to be relatively independent of the modeling representation chosen. We have therefore written the ODM Guidebook in a way that does not assume use of a particular domain modeling representation, and believe the process as documented is robust enough to support diverse modeling approaches. We also intend to produce a more detailed document that describes recommended practice for performing ODM with the use of the RLF toolset. This has led to an interest in organizing the various alternatives for domain modeling representations themselves into a framework for comparison and selection. In the rest of this paper, we propose an initial cut at such a framework for taxonomic modeling representations in DA. 2 Position Modeling commonality and variability across multiple systems is an integral activity in domain engineering. A central issue is the ability to model conceptual relationships (similarity, distinguishing features, categorization) between artifacts and processes of systems that perform analogous missions in diverse contexts. This is distinct from the modeling of actual processing elements or data flows among components within a given system, or higher-level operational interactions among separate systems at the enterprise level. 2.1 Requirements Variability. Our starting position assumes it is useful for a domain model to document not just common but also variant features across a set of related systems. Some methods and informal approaches emphasize commonality only. This approach, in some domains, can identify high-level abstractions (e.g., generic architectures) that encapsulate useful invariant properties. However, if the representation formalism used is only rich enough to express commonality, it imposes this assumption on the modelers, which may not hold for some organizations and/or some domains. The need for modeling commonality and variability can arise in work products across the life cycle: in organization structure, process models, architectures, component functionality, or dynamic models of behavior. Feature Binding Time Problem. Beyond simple comparison across systems, in domain modeling it is important to distinguish combinations of features that must be "simultaneously satisfied" by a single application, vs. combinations where each feature individually must be supported by some application derivable from the domain model. Essentially, the notion is that a choice between variant features can be "bound" or committed at various points within the software engineering life cycle. Modelers must be able to distinguish between these cases, to note connections between the same "logical" feature as it occurs in different "binding contexts", and for the asset base to be able to produce variant systems that implement features at different binding times. Conventional system modeling representations (even object-oriented representations) may have inadequate means for distinguishing a system version that binds a choice at implementation vs. at run time; since what is modeled as a run-time operation in one system may appear as a design decision in another. A simple example would be the choice between tiled and overlapping window protocols in a window management system. Some systems are implemented in a way that "hard-wires" a specific choice of tiled or overlapping windows. Others might allow this to be specified in a configuration file that is read at start-up time. Still other systems might have a "preferences" switch that can be changed dynamically at run time by the user. 2.2 Proposed Framework Having discussed some requirements, we now explore a proposed framework for alternative techniques for representing domain commonality and variability. The proposed framework identifies the following approaches: 1) Use of single system models as "generic" domain models. The system model may be interpreted as a reusable component rather than a domain model; or it may be used as a abstract model representing only common features. With this strategy the representation used should be familiar and thus readily accepted by application engineers. Different exemplar systems may have been developed using different representations; some reverse engineering or conversion into a common format may be necessary. This approach can presume a domain architected with a layer of commonality (a "core" reusable component or set of components requiring little or no adaptation), separated from a layer tailored for each application. Not all domains fall neatly into this style of architectural style. In particular, this approach may fail to exploit significant commonality in lower-level structural elements (e.g., components used by a large subset of applications, but not all applications in the domain). 2) Use of multiple system models as implicit domain models. In this approach, the perceived differences or contrasts between models becomes the true (though implicit) domain model. There may need to be a distinction made between "generic" models and models that represent specific exemplar systems; but similar notations are used for both. Tools like CTA's CAPTURE that provide side-by-side views of analogous system diagrams help modelers visualize these differences [2]. Where the common/variant "divide" happens at a clear structural boundary, hierarchical decomposition techniques can be extended to encapsulate variability; e.g., alternative decompositions. For example, Yourdon data flow diagrams allow hierarchical decomposition of process bubbles in lower level diagrams; a domain model could include alternative decompositions of one common, higher-level process diagram. Variability can thus be introduced at arbitrary levels of system structure. Few conventional support tools manage such alternatives or variants, however. (Sufficiently sophisticated configuration management tools could represent variant application branches and thus manage the structure of alternatives.) This approach does not directly provide direct ways of expressing semantics of the relationships between system variants. In CAPTURE, such comparative insights can be documented by annotating application views with features, trade-offs and rationale. 3) Extensions to system representations to express variability. This allows for even more fine-grained representation of variability than structural decomposition, since variants need not fall only at hierarchical structural boundaries. That is, instead of representing a variant via an entire diagram, embedded notations for variability could be employed within a single diagram. For example, some analysts utilizing the FODA method have developed extended IDEF notations to show variant or alternative processes [6]. One drawback of this approach remains potentially weak or ambiguous semantics of the extensions to the notations, especially in terms of Òfeature binding timeÓ interpretations. 5) Use of representations with built-in variability semantics. By utilizing already supported constructs (e.g., inheritance mechanisms) it is possible to express commonality and variability across systems without inventing new notation or extending new tools. This could include entity-relationship diagrams, semantic data models, and object-oriented techniques [4,5]. Because system notational conventions are, in effect, overloaded to express domain semantics, developers can get confused as to what a given representation is intended to convey. Resolving this ambiguity might require careful convention of use, or possible use of meta- modeling techniques. 6) Separate variability representations, linked with system representations. In this approach, though semantic mechanisms such as specialization, generalization and inheritance may be used as in OO methods, interpretation of these relations is different than in a system model. Notations for system and domain modeling can be heterogenous; in fact, the domain model can reference system models that are themselves in heterogeous notations. The representations employed in this approach can cover a wide spectrum in formality and semantic expressiveness; e.g., faceted classification [7], AND-OR graphs [Kan90] and structured inheritance networks [8,9,12]. 2.3 Summary The techniques described above can be viewed within a framework that distinguishes two attributes: - The degree to which system and domain modeling representations are strongly or loosely coupled (in terms of which the list above is rank-ordered, with the strongest-coupled techniques listed first); - Semantic expressiveness of the modeling representations. This is just a preliminary proposal for such a framework. We hope to use the workshop as an opportunity to collaboratively review, refine and extend the framework to describe advantages, risks, and implementation issues for various approaches. 3 Comparison The main body of this position paper is really concerned with a comparative framework; to Òcompare our comparisonÓ to other surveys of DA methods is a bit more difficult. The major difference is that we have attempted to isolate one clear area of concern for fairly fine-grained comparison. Most other surveys or comparisons of DA methods have attempted to compare DA methods in their entirety, and to make specific recommendations about selection criteria would-be practitioners could apply [1,11]. Our approach is complementary, in that it focuses on a much narrower area. Our longer-range goal, however, it to synthesize a more general comparative framework from results of several more focused efforts for other supporting methods. The ultimate goal is to support the core domain modeling process with a set of decision aids for selecting, instantiating and integrating diverse supporting methods to create robust and tailored domain engineering capabilities. References [1] Arango, G., R. Prieto-Diaz: "Domain Analysis Concepts and Research Directions." Domain Analysis and Software Systems Modeling, ed. R. Prieto-Diaz and G. Arango, IEEE Computer Society Press, 1991. [2] Bailin, S. KAPTUR: Knowledge Acquisition for Preservation of Tradeoffs and Rationale. CTA, Rockville Maryland, 1992. [3] Collins, P., "Toward a Reusable Domain Analysis," Proceedings, 4th Annual Workshop on Software Reuse, Reston Virginia, Nov 1991. [4] DISA/CIM Software Reuse Program. Domain Analysis and Design Process, Version 1. Technical Report 1222-04-210/30.1, DISA Center for Information Management, Arlington VA, March 1993. [5] Gomaa, H. A Domain Requirements Analysis and Specification Method. Technical report, George Mason University, Fairfax, VA., Feb 1990. [6] Kang, K, S. Cohen, et al., Feature-Oriented Domain Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90-TR-21, Software Engineering Institute, Nov 1990. [7] Prieto-Diaz, R., Reuse Library Process Model. TR AD-B157091, STARS IBM 03041-002, 1991. [8] Solderitsch, J., K. Wallnau, J. Thalhamer., "Constructing Domain- Specific Ada Reuse Libraries," Proceedings, 7th Annual National Conference on Ada Technology, March 1989. [9] STARS. Army STARS Demonstration Project Experience Report, STARS-VC-A011/011/00, Dec 93. [10] * ibid., Organization Domain Modeling (ODM) Guidebook, Version 1.0, Unisys STARS Technical Report STARS-VC- A023/011/00, Advanced Projects Research Agency, STARS Technology Center, 801 N. Randolph St., Suite 400, Arlington VA, 22203, March 1995. [11] Wartik, S., R. Prieto-Diaz. "Criteria for Comparing Domain Analysis Approaches," Int'l Journal of Software Engineering and Knowledge Engineering, Sep 1992. [12] Wickman, G., J. Solderitsch, M. Simos, ÒA Systematic Software Reuse Program Based on an Architecture-Centric Domain Analysis,Ó Proceedings, 6th Annual Software Technology Conference, Salt Lake City, Utah, April 1994. Biography Mark Simos has been involved with reuse and domain analysis methods for the past decade. He is founder and principal of Organon Motives, a consultancy specializing in software reuse training, strategic consulting and research with particular focus on domain engineering. As a consultant, Mr. Simos worked extensively with the Hewlett-Packard Company and the ARPA STARS Program in developing the Organization Domain Modeling (ODM) method, and was a co-author of the STARS Conceptual Framework for Reuse Processes (CFRP). Formerly a research scientist for Unisys, he was initial technical lead for the Reuse Library Framework (RLF) toolset. Prior to his R&D work, Mr. Simos specialized in high-end photocomposition applications, and worked on the design and evolution of several special-purpose programming languages for typesetting applications. He holds an MS in Computer and Information Science from the University of Pennsylvania; he is also a well-known traditional fiddler and songwriter. Why (Not) Reuse (Typical) Code Components? Murali Sitaraman David Fleming John Hopkins Sethu Sreerama Dept. of Statistics and Computer Science West Virginia University PO Box 6330 Morgantown, WV 26506-6330 Tel: (304)-293-3607 Email: fmurali, fleming, jhopkins, sethug@cs.wvu.edu WWW: http://www.cs.wvu.edu/resolve/resolve/public_html/index.html Abstract There is much debate within the reuse community regarding the potential for productivity and quality gains from reusing different software lifecycle artifacts. Specifically, there is a growing belief that gains resulting from reusing artifacts in the earlier phases in the lifecycle (e.g., requirements/design documents) dominate the gains from reusing ones in later phases (e.g., code). This belief is indeed true and is based on "typical code artifact reuse" wherein key design decisions are hard- coded in the interfaces and implementations; here ,reuse does not necessarily translate into reusing the effort that has gone into producing that component. In the absence of better designs, non-code artifact reuse is from where reuse benefits could accrue. However, interfaces, implementations, and contexts of carefully-engineered components such as RESOLVE components are highly flexible, and reusing them results in implicit and explicit reuse of lifecycle artifacts and the efforts in creating them. Keywords: code reuse, effort reuse, flexibility, interface design, hard-coded decisions, lifecycle artifacts, parametrization Workshop Goals: to network. Working Groups: formal methods, role of objects in reuse, languages and frameworks, reuse education, technology transfer. 1 Position Typical code reuse is rightly criticized for lacking in reuse potential because design decisions are hard-coded and efforts in creating associated artifacts (if any) are not reused . However, when 3C "code" component interfaces, implementations, and contexts are designed to be reused - both for components that are small and that are large and layered - reuse can and will result in implicit reuse of lifecycle artifacts and the considerable efforts in creating those artifacts. 2 Background Sitaraman has been an active member of the software reuse community for the past several years. He has participated in WISR's regularly since 1990. He has served on WISR program committees and was the finance chair for WISR in 1993. He was the tutorial chair for the Third International Conference on Software Reuse. He has been on the steering committee of the Reuse Education/Training workshop series since its inception. Sitaraman currently serves as the program chair of the Fourth International Conference on Software Reuse. He is one of the principal investigators of the RESOLVE research effort. He has published a number of technical papers on various aspects of reuse. His researchis currently funded by ARPA grant DAAH04-94-G-0002, NASA grant 7629/229/0824, and NSF grants CCR-9204461 and DUE-9354597. Fleming, Hopkins, and Sreerama are PhD students with topic areas in software reuse. 2.1 Introduction The potential in software reuse for solving the productivity and quality problems facing the software industry has not been fully realized. The contention of Brooks that there is "no one silver bullet" (including reuse) [1] along with observations that relatively modest improvements have resulted from reuse have forced the software reuse research and practicing community to renew consideration of questions such as what and how to reuse [2]. Some attempts to answer these questions have led to suggestions that the potential in code component reuse is inherently limited, and hence, reuse of other software lifecycle artifacts must be explored. It is believed that reuse of artifacts that are produced in the earlier phases of the software lifecycle, such as requirements definition and design artifacts, can lead to more significant gains. In this paper, we explain that these claims are true only when based on typical reuse of code components that are highly inflexible and that do not necessarily result in reuse of efforts that have gone into producing the components. We use the term "code component" in this paper to denote a 3C-style component that includes an interface, implementation(s), and contexts [3, 4]. A code component may be small or large. Though we agree on the general need for research in reuse of non-code artifacts (for example, in [5], we have explained how the 3C framework can be generalized to permit a uniform treatment of reusability of software engineering artifacts), we contend that a majority of perceived limits of code component reuse are results of ad hoc attempts to reuse relatively poor code. Specifically, components carefully and systematically engineered, such as those using the RESOLVE discipline [6], can overcome the limitations. The interfaces and implementations of these components have been carefully designed and parameterized to permit functional and performance flexibility. Reuse of these components results in reusing the effort that has gone into the lifecycle phases in creation and certification of the component. Until designs with these characteristics are identified, specified, and implemented for a concept, it is certainly useful to try to reuse other artifacts associated with the concept. Ultimately, however, indirect reuse of domain and lifecycle artifacts (and the efforts that has gone into creating them) through well-designed and systematic component reuse may be where most reuse potential is waiting tob erealized. The rest of the paper is organized into the following sections. Section 2 contrasts typical code reuse with carefully-engineered code reuse, and explains why the former is rightly criticized for its shortcomings and how the latter remedies them. Section 3 provides a summary. 2.2 Case (against and) for (typical) code component reuse Development of a component involves at least the following phases: (i) problem requirements (or in general, domain) analysis, (ii) specification design, creation, and validation, (iii) implementation design, creation, and verification. While it is hard to quantify the effort that goes into each of these phases in general,it is widely acknowledged that a majority of the effort goes into analysis, design, and verification activities rather than in actual transliteration of designs into a concrete specification or implementation artifacts. Clearly any viable model aimed at reaping benefits of reuse must facilitate effort reuse. Most code components are neither designed for reuse nor do they lead to significant effort reuse, leading to the right conclusion that their potential is limited [2]. To illustrate the issues, we consider two variations of a reusable part where hard-coded decisions limit its functional and performance flexibility,and hence its reusability. We explain that if these defects cannot be remedied, few net gains are achieved by reusing code making a strong case for mainly reusing non- code artifacts (e.g., design decisions). However, the section concludes by observing that better designs can remedy the defects showing that inflexibility is not implied by code reuse. Issue 1: Hard-coded design decisions in the interfaces Most object-oriented textbooks include a component for graphs. Let us assume that some application of graphs requires finding a minimum spanning forest (MSF) of a given graph. Normally, the graph component would not include such an operation. Most object-based languages, how- ever, would permit extension of the graph component with an additional operation (or method) Find_MSF that produces an MSF of the given graph. If the graph component includes a sufficient set of operations, it might be possible to implement Find_MSF without violating information hidden in the graph component. For now, the implementation details of Find_MSF are largely irrelevant. The effort that has gone into developing Find_MSF is mainly in certifying its correctness; little effort has been spent on its interface design and implementation - which is a straightforward translation of an MSF finding algorithm. Now consider the following evolution in the functionality requirement of the above application or a new application: an MSF that is less than a specified weight W is needed; if the graph does not have an MSF with weight <= W, other actions may be needed. There are two less-than- perfect possible solutions to this changed problem. The first and most natural solution (from a black box reuse perspective) is to reuse the Find_MSF operation. In this case,a complete MSF for the given graph would be found and then its weight would be computed and compared against W. This solution suffers from a performance penalty because it is not always essential to compute a complete MSF to see if its weight exceeds W. Typically, only a few, but not all edges of an MSF are needed in determining if W is exceeded. The inflexible procedural interface is the obstacle in satisfying the changed functional requirements without introducing a performance penalty. In addition, though this solution reuses the interface and the implementation of Find_MSF (and Graph) "as is," the effort reuse is minimal: Little effort has been invested (and hence,reused) in the informal interface design and translation of a standard algorithm to an implementation; the certification is probably not modular and hence,is not strictly reusable in an altered client environment. In summary, this solution results in reuse of minimal effort and a performance penalty. A second solution to the evolution problem (likely from an algorithmic or white box reuse perspective) is to re-specify the interface, possibly with additional parameters, and re-code the Find_MSF operation so that it is suitable for the new situation. While this solution provides better performance, from a reusability perspective it has little merit. Once interface and implementation of the Find_MSFoperation have been altered, none of the effort that has gone into creating it including that in the certification of the existing implementation can be reused. What is being profitably reused here is the "algorithm" for finding an MSF of a graph. Though the translation of the algorithm to code can in fact be partially reused in this "white box reuse" solution, gains are insignificant. In the absence of better solutions, the potential for concrete code reuse, at least for the example at hand, is limited. Exploration of reuse of other artifacts would be in order. As explained in the rest of this section, however, there is a better design and solution to the present problem. In [7], we explain a solution to the spanning forest finding problem based on the general strategy of "recasting" algorithms as objects; this solution results in a component interface that provides functional flexibility without introducing a performance penalty for some applications (such as the one that needed an MSF with weight <= W). When the large-effect spanning forest finding operation is recast, the result is a component that provides (a family of) objects, and small- effect operations to insert an edge, change the phase, and extract an edge on these objects. This interface design permits a client application to selectively retrieve only some edges of a spanning forest of an input graph. The interface not only hides how a spanning forest is computed, but when it is computed. This design in turn permits alternative implementations of the same interface with performance behaviors suitable for different applications. When the Spanning_Forest_Machine _Template component is reused, important among the gains are the efforts that have gone into its formal and fully-abstract interface design. Details can be found in [7]. If the implementation is locally certified in a modular fashion [8, 9], then the certification effort is reusable as well. Issue 2: Hard-Coded Design Decisions in Implementations Supposing that a spanning forest component has been designed with an object-based interface, we now focus our attention on implementing this component. One class of implementations would use Kruskal algorithm [10]. This algorithm orders the edges of a graph in a non-descending order and then based on that order (beginning with the smallest one) chooses edges so that they do not form a cycle. One implementation of Spanning_Forest_Machine_Template would "hard code" the Kruskal algorithm from scratch. Such coding would involve identifying and using a prioritizing technique. The Kruskal-based implementation may provide appropriate performance some clients depending on the chosen prioritization algorithm, but may not be suitable for others. This raises the possibility that different applications may require changing the "prioritizing aspect" of the implementation without changing other details. As noted earlier,any changes to the implementation will immediately nullify all efforts that have gone into its certification with the result that implementation reuse benefits are resulting more from the "algorithmic and implementation design aspects" rather than the concrete code. The problem here is one of hard-coded implementation choice, and a possible solution involves a component-based construction [7] of the above implementation and constituent parameterization [11]. Rather than implementing Spanning_Forest _Machine_Template from scratch, it is possible to use Sorting_Machine_Template (an object-based component that has resulted from recasting sorting) and Equivalence_Relations_Template (an object-based component that captures the standard equivalence relations idea). To change the prioritizing aspect of this implementation, all that would be needed is to change the implementation of Sorting_Machine_Template that is being used; it is possible to allow the client to make this change and tune the performance by making an implementation of Sorting_Machine_Template as a performance parameter. Details of performance parameterization are in [11]. We have focused our attention on one specific example to highlight the issues in the paper. But the underlying strategies for flexible component design such as recasting and performance-tuning employed here are far more general. The abstraction facilitated by the specifications are crucial to permit modular and local reasoning. Research into such theoretical underpinnings and practical implementation of these ideas is crucial to make explicit and implicit lifecycle artifact reuse and effort reuse profitable. 3 Summary It is rightly being observed that typical code component reuse has limited potential. However, careful design can eliminate most critical limitations. When a component is designed to be reused, tremendous effort is involved indeveloping a formal and fully-abstract interface that is flexible. Designs of implementations also require considerable thought to avoid hard-coding key decisions; additional cost is involved if performance behavior is of interest. Development of these components in programming languages such as Ada and C++ also require a carefully conceived discipline to permit local certification, among others [9]. Components designed and developed such, when reused, lead to significant gains in productivity and quality in all lifecycle phases. References [1]F. P. Brooks, "No Silver Bullet: Essence and Accidents of Software Engineering,"IEEE Computer, vol.20, no. 4, pp. 10-19, 1987. [2]T. Biggerstaff, "The Library Scaling Problem and the Limits of Concrete Component Reuse," in Procs. Third Int. Conf. on Software Reusability,Rio de Janeiro, Brazil, pp. 102-109, IEEE Computer Society Press, 1994. [3]W. Frakes, L. Latour, and T. Wheeler, "Descriptive and Prescriptive Aspects of the 3C Model - SETA Working Group Summary," in Int'l Ada Tools and Environments Conference, Redondo Beach, CA, 1990. [4]W. Tracz, "Where Does Reuse Start?," ACM SIGSOFT Software Engineering Notes, pp. 42-46, 1990. [5]M. Sitaraman,"A Uniform Framework for the Reusability of Software Engineering Assets," in Fifth Annual Workshop on Software Reuse, Palo Alto, CA,1992. [6]"Special Feature: Component-Based Software Using RESOLVE," ACM SIGSOFT Software Engineering Notes, vol. 19, October 1994. [7]B. W. Weide, W. F. Ogden, and M. Sitaraman, "Improving Reusability By Recasting Algorithms as Objects," IEEE Software, September 1994. [8]G. W. Ernst, R.J. Hookway, J. A. Menegay, and W. F. Ogden, "Modular Verification of Ada Generics," Computer Languages, vol. 16, pp. 259-280, 1991. [9]J. Hollingsworth, "Software Component Design-for-Reuse: A Language- Independent Discipline Applied to Ada; available by anonymous FTP from acrchive.cis.ohio-state.edu in directory pub/tech-rep ort/TR1- 1993.," Tech. Rep. TR1-1993, Ph. D. Thesis, The Ohio State University, 1992. [10]T. H. Cormen, C. E. Leiserson, and R. L. Rivest, Introduction to Algorithms. Cambridge, Mass.,:MIT Press, 1990. [11]M. Sitaraman,"Performance-Parametrized Reusable Software Components," International Journal of Software Engineering and Knowledge Engineering, vol. 4, pp. 567- 587, October 1992. Standardized Software Classification in the World Wide Web Robert Haddon Terry Margaretha Price Louann Welton MountainNet Inc. 2816 Cranberry Square, Morgantown, WV 26505 Tel: (304)594-9075 Fax: (304) 594-9088 Email:frhterry,mprice,lweltong@rbse.mountain.net Abstract Where is the knowledge we have lost in information? T.S. Eliot By browsing and searchingthe World Wide Web (WWW) for reusable software, potential reusers encounter several different levels of cataloging and classification schemes. Some software repositories use more established methods while others use ad-hoc methods of classification. In this position paper, we suggest having a standardized cataloging method for WWW software repositories. Our goal is to provide potential reusers with a readily apparent profile of repository contents, eliminating user reliance on a full working knowledge of the specific repository classification type. This is becoming increasingly necessary with the proliferation of WWW software repositories and their expanding popularity. Keywords: Reusable software classification, World Wide Web Workshop Goals: Start promoting a standardized classification scheme; learn other cataloging/classification methods; listen to other ideas in promoting the sharing of software through the WWW. Working Groups: Reuse terminology standards, cataloging reusable software, reuse in the WWW, reuse handbook and reuse management, organization and economics. 1 Background Our reuse experience is gained through the operation of the NASA sponsored ELSA (formerly AdaNET) project, a fully functional WWW repository. Of ELSA's current population of 1100 assets, 670 are reusable software. These reusable assets are organized by class or information type and by content through a collection hierarchy. The collections represent facets of or subjects relevant to the Information Management, Software Development, Mission Critical Systems and WWW Information and Utilization domains. As software engineers/librarians in this environment, we are directly responsible for acquiring, evaluating, cataloging and qualifying software assets. In support of these tasks and in an effort to support sound reuse concepts and practices, our team participates in the identification, composition and evaluation of proposed interoperation and reuse standards through the Reuse Library Interoperability Group (RIG). This involvement impacts and prefaces our assumed position with respect to reuse classification systems. 2 Position A standard cataloging structure is necessary to fully explore the potential represented by WWW software libraries. We are not advocating a single classification scheme but rather, a convention or structure that provides a descriptive overlay or reference guide to the appropriate interpretation and utilization of classification schemes. Repositories can use all or part of the classification standard, and they can also expand to the lower levels of classification. To our knowledge, groups have developed candidate interoperation standards with respect to certification frameworks and the basic data models. These efforts do not satisfy or address issues inherent in cataloging methods. Below is a sample list of software repositories currently available on WWW. These servers do not just contain information on their projects, but in fact, make software assets accessible through the WWW. Argonne National Laboratory Mathematics and Computer Science Division (http://www.mcs.anl.gov/Projects/progtools.html) CMU Artificial Intelligence Repository (http://www.cs.cmu.edu/afs/cs.cmu.edu/project/airepository/ai/html/ai r.html) Electronic Library Services and Applications (http://rbse.mountain.net/ELSA/elsa_lob.html) Fortran 90 Software Repository (http://www.nag.co.uk:70/1/nagware/Example s) Guide to Available Mathematical Software(http://gams.nist.gov/) National HPCC Software Exchange (http://www.netlib.org/nse/home.html) Netlib at The Univ. of Tennessee and ORNL (http://www.netlib.org/liblist.html) Physics Software Repository (http://icemcfd.com/cfd/CFD_codes.html) Public Ada Library (http://wuarchive.wustl.edu/languages/ada/pal.html) Some of the above repositories catalog assets topically, while others arrange holdings alphabetically. Topical classification systems are typically presented as a hierarchy with variations given to subjective logic or order purpose. It is further observed that the variations extend to the inclusion of metadata or brief asset profiles. Metadata is often delivered as a prescribed set of attributes that briefly describe asset properties,or as separate WWW pages with no set attribute pattern. It is also noted that several repositories offer direct asset access without metadata. The discussion of metadata is related to classification schemes but outside the topic of this position paper. We propose that WWW reusable software providers choose one existing classification scheme most suitable for cataloging reusable components. There are several existing classification models from which to choose (i.e.the CR classification System of theACM). Although no one scheme can suffice in all applications, a basic cataloging structure can be determined and is necessary in today's reuse WWW environment. A classification scheme that is flexible enough which libraries can select only parts of the classification structure and/or they can also expand the lower levels of the structure for the more domain specific libraries. 3 Comparison Software classification can be compared directly to general library classification schemes such as the Library of Congress (LC) and Dewey Decimal Classification (DDC). Several participants of the Web4Lib listserv, a mailing list for issues relating to the creation and management of library-based World-Wide Web servers and clients, have addressed the issues of standardization of WWW library classification schemes. These discussions are continuing and working groups are being proposed in their domain. The software reuse community can start the same discussions, while also collaborating with those decisions made by the librarians. 4 Biography Robert Haddon Terry is a Sr. Software Engineer/Librarian in MountainNet, Inc., for the NASA/ELSA software library. He received a B.A. (1984) degree in Secondary Mathematics from West Liberty State College, West Liberty, WV, and a M.S. (1988) degree in Computer Science, from West Virginia University (WVU), Morgantown, WV. Since 1989, he has also been a Lecturer/Researcher at WVU. Margaretha Price is a Sr. Software Engineer/Librarian in MountainNet, Inc., for the NASA/ELSA project. She received B.S. (1990) and M.S. (1992) degrees in Computer Science from West Virginia University, Morgantown, West Virginia. Louann Welton is a technical writer for MountainNet, Inc and its divisions. She received a B.A. in English with a specialization in Library Science from Fairmont State College in 1983. A Conceptual Framework For Evaluating Domain-Specific Kits Kevin D. Wentzel Hewlett-Packard Laboratories 1501 Page Mill Road Palo Alto, CA 94303-1126 (415) 857-4018 wentzel@hpl.hp.com Abstract In a working group at WISR 6, in 1993, Martin Griss and Kevin Wentzel led an exploration of the notion of domain-specific kits. Kits are comprised of compatible, domain-specific components, frameworks and languages, supported by a variety of well- integrated technologies and tools, such as domain-specific languages, builders, generators and domain-tailored environments. The working group attempted to list what the parts of a kit could be with the purpose of allowing evaluation of software reuse systems as kits. The framework described and demonstrated in this paper is a result of our continuation of the group's work. Keywords: Reuse, kits, domain specific kits. Workshop Goals: Understanding how an analysis of domain specific kits can help promote successful software reuse. Working Groups: Reuse process, Reuse artifacts, Reuse measurement and metrics. 1 Background Our research program at Hewlett Packard Laboratories has performed experimental research on software reuse with the goal of improving Hewlett Packard Company's software processes. In this research we have learned that to get high levels of reuse and enable rapid application construction, with consequent high levels of benefits, one needs more than just code or object libraries. As part of our work, we have learned that careful consideration must be given to the way reusable workproducts must be designed and packaged. One needs to systematically deal with the careful design of reusable architectures and components that fit together, aided by well-integrated tools. A result of this research program is the concept of Domain-Specific Kits [2] and [3]. We define a domain specific kit as a set of compatible, reusable workproducts (software artifacts produced at a variety of points in the software lifecycle) that are architected to fit well together and are designed to make it easy to build a set of related applications. Our kit-oriented research agenda includes the development of: A philosophy of how and when to use domain-specific kits, with careful and useful definitions. Processes and methods to be used by kit developers and users, workproduct supporters and managers, such as kit-based domain engineering, kit engineering, and application engineering. A taxonomy and analysis framework of kit models to allow us to evaluate and compare different domain-specific kits, including kit- feature selection guidelines. A set of customizable tools and technology that can be used to define and develop kits, including domain analysis tools, language and generator kits, library and browsing tools, language interpreters and compilers, software-bus services, and user-programming and customizing language kits. A set of case studies which illustrate the principles, the practice and the tradeoffs, abstracting ideas from studies of reuse in several HP divisions, existing commercial kits or kit-like systems, and experiences in prototyping several experimental domain-specific kits. 2 Position We are evaluating several kits or kit-like development environments within a conceptual framework to gain a deeper understanding of kit features and mechanisms. This helps us explain the concept of a domain-specific kit, evaluate potential kits for completeness, determine the importance of the various kit elements, suggest improvements to kit-like software development systems, and identify candidate kit technologies. Analysis of kit-feature variability is a start toward a domain analysis of kit styles. As a way to determine which were the most important aspects of software reuse technology and to suggest the best directions for research, we began work on a kit evaluation framework. We applied an early version of the framework to several reusable software systems from libraries to highly configurable applications and looked for correlations which indicated features important in making the systems successful. We presented this early framework to a working group at the 1993 Workshop on Software Reuse [4]. Following this test run, we refined the model to produce the improved and expanded conceptual framework described below. This analysis framework can be used as a reference model to allow kit designers to pick mechanisms and styles appropriate for particular domain or user requirements. When the model is applied to a large number of kits, it can act as an outline for a catalog of kits. Potential kit users can compare kits based on the representation in the model. 2.1 A conceptual framework for evaluating domain-specific kits A successful kit is a complex collection of many kinds of workproducts, models and documents, which we call "kit elements." We chose a tabular form for the analysis since it makes side-by-side comparison of kit examples easy. A kit is represented by two tables. The first is a set of general factors describing the kit being analyzed, while the second analyzes several attributes of each element. Table 1 describes the general kit factors. These include factors which identify the kit as well as evaluative factors which can be used to gauge the advantages of using the kit and the overall value of the kit. Table 2 describes the assorted kit elements, while Table 3 describes the kit element attributes. While not all kits contain all elements, the use of the same set of factors in each analysis can point out differences in kits, thereby determining which elements are most effective in particular situations, and suggest elements that might be added to improve a particular kit. The attributes are standard questions to be asked about each element. We are interested in learning the effect these attributes have on successful use of a kit, and also in using these attributes to predict success in developing and using new kits. The absence or weakness of an element or attribute may suggest areas for improvement and extension of the kit. Each of these items relates to one or more questions or issues that were raised by ourselves, divisional partners or others trying to use kits. We have come to think of the collection and range of answers as representing assorted "best-in-class" options for kit elements, each of which can be considered during kit engineering when designing a new kit. For convenience in comparing kits, we summarize in the second kit table the analysis of a particular kit as a 2-D matrix with the kit elements as rows, and the attributes as columns, highlighting the presence of, and notes about, each attribute for each kit element. We find it important to understand and reveal where domain-specificity is located, and how openness and extensibility are accomplished. Notes indicate how the attributes apply to each kit element, or list questions yet to be answered. Table 1. Description of general kit factors Factor Description Kit name The name identifying this kit. Kit style How are applications built from the kit? Are components combined using a traditional computer language? Are applications designed in a domain-specific language and constructed using a generator for that language? Is this a hybrid kit showing a combination of componentry and generation? Is there a visual builder? Kit purpose Application construction? Application customization? Target kit user Who is expected to use the kit: application developers, system integrators, or end users? What is the expected skill level of the kit users? Target application user What are the characteristics of the end users of applications developed from this kit? Features of merit for this kit What makes this kit valuable? (coherence, ease of use, evaluability of results, distance from problem space, ... Òinput compressionÓ) Notes Interoperability with other kits, sub-kits used. Other tools Other tools, environment features Table 2. Description of kit elements Kit Element Description components Software components and component documentation. architecture Application architecture for applications developed from the kit. framework The application framework instantiates the common portion of the application architecture, provides common mechanisms, services and components which shape all applications built from the kit, and defines the API to which components and glue must conform. domain-specific language In some reuse situations, a problem oriented or domain-specific language is an appropriate kit element, allowing application specifications to be entered in the terminology of the domain. There are several levels of domain-specific languages. These domain-specific languages and the translators for them are often costly and difficult to develop but provide high payback. glue language A kit usually includes some way of connecting components to each other and to the framework. generator A tool that generates kit components, glue, configurations, parameters, or some other application specific element from application specifications. builder A tool, often graphical, which allows a kit user to develop applications by selecting and composing components, by filling in templates, or by editing specifications. tests A kit may include tests of kit elements and/or developed applications. end user docs A kit may include documentation for application end users. This can be component or tool documentation, generated documentation, or documentation on customizing applications. maint docs Documentation on kit maintenance. kit use docs Documentation on using the kit to develop applications. feature set rationale Reasons why particular features are included or clustered in a particular way in the kit. domain model Graphical or textual model of the application domain, usually a result of domain analysis. Used in application design and development using the kit. generic applications A kit may include several generic (pre-built) applications as examples developed from the kit, or as the bases which application developers can modify and extend to develop applications. Table 3. Description of kit element attributes Attribute Description presence in the kit Is this element a part of this kit? Is its absence noteworthy? completeness How complete is this element of the kit? Does it cover everything needed from it for development of the target applications? openness How easily can elements or new features be added to the kit or to the developed (sub-) applications? domain specificity How specific to the target application domain is this element of the kit? binding time When is this element bound into the application? source What is the source of this element? (provided in kit, created or generated, written by user, liked from external libraries, etc.) life-cycle stage How/when this element is used? (problem, solution, implementation, extension, element development) 2.2 Hewlett Packard Laboratories kit experiments We have prototyped a series of small domain-specific kits to help drive the development of our kit design, implementation methodology, and tools. Our first kit was in the domain of to-do list or task-list managers, using our software bus [1] for component integration. Following a minimal domain analysis and kit design, components were written in several languages (LISP, C++, Tcl/Tk) for item display, definition, time management, and task-list item storage management. Alternative components and options are selected, and data-structures are defined, using a simple (LISP-based) configuration language from which a complete application is generated. An alternative to the configuration language is a conversational rule-based tool (IBACON) which uses information derived from our domain analysis to present application requirement issues to the application builder. After the application is specified in this manner, the kit configuration file to match the answers to the issues is generated. 2.3 The framework applied to the To-do list manager kit We have applied our kit analysis framework to the kit described above. The most important deficiency we find in this kit is in the area of openness and completeness The kit only covers a limited portion of the domain but does not make it easy for application developers to add their own components to their applications. The kit is strong in generator and builder technology where it has offerings for users of very different backgrounds. Tables 4 and 5 summarize the kit and show how the framework is applied to a kit. Components: A collection of software components is included. Some are multiple (different capabilities) versions to fit a particular function, others are included or not included in the application depending on features required by the application developer/user. Components are written in a variety of programming languages: Lisp, C, C++, Tk/Tcl, Epoch Lisp. Framework: A software bus in included as a framework for assembling applications using the kit. The bus allows components to be included anonymously making application development adding flexibility to application construction. Languages: The kit includes a lisp-like domain-specific language for application specification. It also includes IBACON, a conversational builder which can generate the kit's language. The application is specified in a domain specific language. When the language is "compiled" via the generator appropriate customizations for the components are built, and components are selected for inclusion. Components are "glued" together when they connect to the bus. Environment: The kit works in the UNIX environment, however scripts and IBACON can shield the application developer from too much interaction with UNIX. The IBACON tool works within the CLIPS-5 environment but users do not need to know CLIPS-5 to use the IBACON. A generator is included for processing the domain specific language into component customizations and selections. Generic Applications: A generic application is included. It was expected to be a test for correct installation of the kit but quickly became the starting point for users application development. Completeness/Openness/Extensibility: For its limited portion of the domain, the kit is relatively complete. However, lack of openness makes it difficult to add anything that is missing. The kit was not designed for openness. One of the test users wanted to add a component and found it difficult to do so. Our survey of kit-like reuse inside and outside of Hewlett-Packard company has shown us that openness is more important than we originally thought. Other Tools: An "Application Controller" tool gives kit developers and sophisticated application developers much flexibility in starting-up and shutting-down application components. Bus monitoring tools assist in debugging the kit and applications developed via the kit. It is a kit goal to eliminate the need for tools such as the bus monitoring tools since kit users should not need detailed knowledge of these lower level support technologies. Notes: This kit was developed for research and experimentation in kit building and use techniques. It was never expected to be used to develop complete applications in the domain. Table 4. General kit factors for HP to-do list manager kit Factor Description Kit name Hewlett Packard Laboratories Prototype To-do list manager kit Kit style Components with a domain specific language or a conversational builder to specify and generate the application. Kit purpose Testing kit ideas in Hewlett-Packard Laboratories. Target kit user System/Application programmer. Target application user Any computer user. Features of merit for this kit Application architecture makes application development very flexible. Notes App-Controller and Bus Monitor tools aid in kit and application debugging. Table 5. Kit elements and attributes for HP to-do list manager kit Elements presence completeness openness domain specificity binding time source life-cycle stage components sets of alternative components for critical functions plus components for optional functions complete enough for the purposes of this kit. Some components are highly customizable but all customization is via the kit language. specific to to-do list management domain. generation, application start-up time. Hewlett Packard Laboratories Application specification and execution architecture components communicating via a software bus The bus architecture supports open ness but no tools or instructions provided. not domain specific primarily run time binding framework bus plus expectation for components covering a minimal set of functions bus architecture is very open quite domain specific domain spec. lang lisp-like language Complete for the limited functionality of the kit. not easily changed, no tools for extension. very domain specific. compiled HP Labs all glue language (see dsl above) generator Included for processing kit's domain specific language Complete for kit and language features Not easily extended Specific for the kit. generation and app startup. HP Labs Application specification and construction. builder IBACON conversational builder Covers all features of the kit Not easily extended. Knowledge in IBACON is very specific to to-do list domain Generates kit domain specific language. HP Labs Application specification tests Generic application included as an installation test. Tests kit installation only end user docs no maint docs no kit use docs brief manual and online documentation feature set rationale no domain model none generic application Generic application included with kit Many kit features not included in the application are included in comments. can be modified and saved as new application application specification 2.4 Summary and conclusions This model of kits and kit analysis framework helps us identify and characterize key elements and attributes of effective reuse kits, and points the way for improvements in several kits we have analyzed. The definition of domain-specific kit (components, framework, glue- language, generic applications and tools), generalizes previous notions of toolkit or kit, and highlights extensions we can make to enhance existing kit-like systems. For example, most object-oriented frameworks do not systematically include either generic applications or integrated problem-oriented languages , generators or builders. The analysis framework has been applied to several systems at HP labs and in HP divisions. It has also been used by participants in the WISR 6 reuse workshop. We believe that to effectively build, buy, and make use of domain specific kits, an organization must be able to analyze and compare kits using a framework such as this one. References [1] Brian W. Beach, Martin L. Griss, and Kevin D. Wentzel. Bus- based kits for reusable software. In Proceedings of ISS'92, UCI, Irvine, pp. 19-28, March 1992. [2] Martin L. Griss, Software reuse: from library to factory, IBM Systems Journal, 32(4), pp.1-23, November 1993. [3] Martin L. Griss and Kevin Wentzel, Hybrid domain-specific kits for a flexible software factory, Proceedings of SAC'94, pp. 47- 52, ACM, March 1994. [4] Martin L. Griss and Will Tracz, Workshop on software reuse, Software Engineering Notes, 18(2), pp. 74-85, April 1993. Biography Kevin Wentzel is a project leader in the Application Engineering Department of HP Labs' Software Technology Lab. For three years he lead a team performing experimental research in software engineering and domain specific reuse. Kevin's current role is leading research on extending Object Oriented Analysis and Design methods in toward distributed and concurrent application systems. Kevin has been with Hewlett-Packard for 17 years. Prior to joining HP Labs, Kevin worked in various engineering and management roles in several HP divisions developing software products. Kevin has BS and MS degrees in Computer Science from the University of Wisconsin. Reusing Requirement Specifications: Lessons Learnt B R Whittle Rolls-Royce University Technology Centre Systems and Software Engineering Department of Computer Science University of York York, UK, YO1 5DD Tel: +44 1904433375 Fax:+44 1940 432708 Email: ben@minster.york.ac.uk Abstract This paper is a summary of the experience gained by introducing a change in technology used to specify requirements for real-time systems. Whilst some of the experiences and techniques described in this paper are specific to the development of safety critical systems, many of the ideas are applicable across systems in a wide range of applications. Keywords: Software Reuse, System Reuse, Requirement Specification, Real- time Systems. Workshop Goals: Discuss domain modelling, assess suitability of software reuse principles to non-software domains Working Groups:Reuse management and Organisation, Domain Analysis / Engineering, Reuse Adoption and Technology Transfer. 1 Background Ben Whittle works within the Rolls-Royce University Technology Centre for Systems and Software Engineering: Rolls-Royce established this research group within the University of York, England to examine systems and software development issues for the high integrity control systems, both in the aerospace and power generation industries, produced by Rolls-Royce plc. One of the major activities of the group has been in establishing a successful reuse strategy within the company. This work has been principally undertaken by Ben Whittle and has examined artifact reuse across all phases of system development, from requirements specifications to test plans. 2 Position Detailed requirement specification is common in real-time systems. Reuse throughout the lifecycle is necessary to achieve significant cost savings, and there is a close relationship between the requirements, the design and implementation, and the testing phases. i.e. reuse of the requirements is a necessary, but not sufficient, factor, in the reuse of the code and test scripts. This paper abstracts some of the lessons that we have learned from changing the way that the requirements are specified to enable reuse. There are no examples in this paper as there is not sufficient space, however we have a paper in preparation which will describe our experiences in more detail [1]. Successful reuse is not only a matter of changing the requirements structure and the method that supports it, but also of establishing a culture that supports reuse. Whilst there are some changes to the method and the way that the requirements are specified, the greatest effect is likely to come from the changes in the non-technical factors. This section provides a brief resume of our experiences both in terms of the technical and non-technical issues. 2.1 TechnicalIssues The techniques described in this paper have moved requirements engineering for Rolls-Royce forward in a number of ways: requirements are considered as groups, 'requirements components', with the interconnection between the requirements specifically recorded. a 'requirements component' should exhibit high cohesion and low coupling. wherever appropriate, customer specific detail should be abstracted away. for similar systems the requirements document set forms an extensible generic structure which is used as the basis of a specification of a family of systems. in some cases a family of systems, or part of a family, is specified as a generic set of requirements and variants on that generic. In practical terms this has meant that we have reduced the total number of requirements on the system by removing duplication. For example, a recent case study in the area of signal validation we discovered that there were 17 approaches to signal validation, depending on the specific characteristics of the hardware and combinations of inputs. In a brain storming session with the engineers,followed by a more careful appraisal of the results, we reduced the number of approaches to signal validation to 5. This reduction will have a significant impact on subsequent coding and testing timescales and costs. 2.2 Process Issues The requirements engineering process needs to be focused on the concept of the family of systems, rather than the bespoke system generation that most methods support. This is a cultural change, and has involved encouraging engineers by showing them concrete benefits through examples. The key areas of process change are in Planning: ensuring that the engineer knows that similar requirements already exist,and that he must extend these requirements wherever possible. Project management: to ensure that reuse is properly budgeted, measured, and managed. Review: to ensure that the best possible use of existing components has been made. In addition, engineers must be encouraged to think of the activity of adding value through developing a generic or variant, as opposed to the creation of 'new' requirements. The reuse efforts have been gaining momentum over the last 18 months. The total effort on reuse in that time, both within the project and at the UTC has been approximately 2 man years. Afurther 2 man years has been spent by the project in developing reusable components for this engine series. In response to the actual successes on the current project and the perceived benefits for future projects Rolls-Royce have significantly increased the proposed effort on reuse for the next year with a particular aim of establishing a reuse culture and developing a library of reusable requirements components. 2.3 Management Issues Reuse has a significant impact on the way that requirements specification is carried out. This will be apparent in the reduced timescales because of the change from bespoke requirements specification to reuse and adaptation within an existing requirements framework. Managers must learn to exploit the reuse potential by considering the potential impact of reuse on project timescales and budgeting appropriately. A great deal of the management information needed to construct the project budget, the risk and impact analysis of changes, for example, can be used by the team leaders and requirements engineers as a driver for the scope of the requirements engineering task for a particular variant. Project management and budgeting must be backed up by systematic metrics collection. Three key metrics are: actual time/cost saving accrued to reuse effort spent in developing reusable components effort spent in reusing The first metric is used by the management to benchmark reuse, to provide a basis for evaluation of budgeting accuracy, and to provide a baseline for future budgeting.The other two metrics provide reuse management information that can be used to gauge the utility of particular components. The data for these metrics is being collected at the present time. The early stage of development of the current projects means that no meaningful results are currently available. 2.4 Tool Support Requirements specifications are often text based, together with tables and diagrams as appropriate. The better text editors can cope with the amount of elision, information hiding, etc. necessary to print a copy of a document with a certain view. In other words it can output the generic information plus that specific to an individual variant, without compromising the potentially sensitive information about other variants. The tool must also be able to handle configuration management issues because of the use of the requirements documents on more than one engine project. 3 Comparison Most of the research work in the area of requirement reuse has focused at a higher level of abstraction than the work presented in this paper. For example work by Maiden and Sutcliffe focuses on the use of analogy [2, 3]. There are a number of reasons for the difference between our work and the existing requirement reuse papers: in the real-time systems domain requirement specifications tend to be less abstract, indeed many people would consider the specifications to be more akin to design documents. Design reuse is considered by Biggerstaff and Richter [4]. we consider the way that we have structured the information in the requirements documents so that it can be reused rather than considering the type of information retrieval and use of techniques to retrieve the information the work described is very pragmatic, and intended to provide a basis for leverage of reuse later in the lifecycle. i.e. reuse of the requirements is only a partial goal. 4 Summary of Position In the domain that we are interested in, real-time systems, we believe that reuse of requirement specifications is necessary if we are going to achieve reuse in later stages of the lifecycle. This working paper has summarised the ways in which we have changed the structure of the requirements specifications to make them more reusable. There are a number of other factors that will enable reuse. The paper notes our approaches and the lessons learned in trying to adopt a reuse culture. References [1]B. Whittle, A. Vickers, J. McDermid, R. Rimmer, P. Essam, and J. Hill, "Structuring Requirements Specifications For Reuse," In Perparation, vol. The authors are with the Rolls-Royce UTC, University of York and Rolls Smiths Engine Controls Limited, 1995. [2]N. Maiden and A. Sutcliffe, "People-Oriented Software Reuse: The Very Thought," in[5], pp. 176-185, March 1993. [3]A. Sutcliffe, Analogy in Software Reuse, ch. 7 of [6], pp. 129-134. Chapman and Hall, 1992. [4]T. Biggerstaff and C. Richter, "Reusability framework, assessment, and directions.," IEEE Software, vol. 41, March 1987. [5]R. Prieto-Diaz and W. Frakes, eds., proceedings of the 2nd International Workshop on Software Reuse (REUSE'93), Lucca, Italy, IEEE Computer Society Press, ISBN 0-8186-3130-9, March 1993. [6]P.Hall, ed., Software reuse,reverse engineering,and re-engineering. Chapman and Hall,1992. 5 Biography Ben Whittle graduated in Agricultural Economics from UW Aberystwyth in 1989. He subsequently completed a masters in Computer Science and proceeded to study for a PhD in the area of Software Component Reuse. Mr. Whittle is currently with the University of York, working within the Rolls-Royce sponsored Systems and Software Engineering University Technology Centre (UTC). His main task within the UTC is the introduction of advanced reuse techniques to the development of real- time systems within Rolls-Royce. Mr Whittle has recently been elected chairman of the British Computer Society Reuse Special Interest Group committee and was formerly the editor of the group newsletter. How to convince the management? Aarne H. Yla-Rotiala Nokia Telecommunications P.O. Box 33 02601 Espoo, FINLAND Tel: (358) 0 5112 6542 Email: aarne.yla-rotiala@ntc.nokia.com Abstract Software reuse is a way to increase productivity and to get better quality. It seems that reuse is often stated as a goal for improvement programs, and that companies and other organizations feel the need to "do reuse". The order of steps is not predetermined, but then by keeping the actual goals - productivity, product quality, customer satisfaction - in mind one is able to travel towards a better software engineering solution. By improving the organization's state of the practice it is possible to finally stumble into reuse, but without having to bleed in the process. Doing the improvement in a planned manner with centralized resource allocations could be in some way more efficient than this Darwinian path, but the effect on customer-oriented and financially responsible units within a company can be negative. The conclusion of this presentation is that "It looks like having reuse as a goal is having the wrong goal", especially from the management perspective. The conclusion is followed by the question "What is wrong with this conclusion?". Keywords: Quality, productivity, investment, management. Workshop Goals:Practical experience exchange, counter arguments against my position. Working Groups: Tools and environments,Software engineering management and economics 1 Background I have been a practicing software engineer for several years now. As such, I have gotten more or less acquainted with several methods to achieve better quality and productivity. Among these methods, reuse has been and still is one of my favorites. During my active career I have written and used (re-)usable components, and tried to get a grasp of what reuse is all about. So far I am in the wilderness: there seems to be little difference between "Solid Software Engineering" and "Software Reuse". 2 Position Motorola [1] and IBM [2] have documented successful reuse programs. These and other efforts like STARS are specificly aimed at enhancing reuse in the organization's software engineering process. This requires a lot of management support and commitment, up to the CEO level. Investments are huge, and the pay-off time is usually several years. The positive effect of such a program is "enhanced reuse" and "better reusability"of the software products created in the organization. Eventually this is believed to result in lower overall costs, better quality and shorter time to market for new products, which are all desirable goals. These goals - and other similar ones - are what companies are actually looking for when they launch "quality", "productivity" or even "reuse" programs. Given the time-scale and investment required to start and run a successful reuse program , it is not very likely that the average manager is willing to authorize such a program. If the program's goal is set to enhance reuse, the connection between the bottom line - or harder-to- measure things like customer satisfaction - is very fuzzy at best. Fast programs with more concrete goals are likely to be easier to accept. Expensive initiatives that take years to complete should not focus on only one aspect or method to achieve better quality and larger profits, but on a holistic approach to the company's software engineering process and environments. The chain of deduction should go the other way round: Do something for better abstractions, create better tools, enhance communications, educate the engineers and preach about usability on all levels of you process and product, and eventually you'll get better quality, faster throughput, larger profits and even more (re-)usable software and more (re-)use of existing artifacts. My position is therefore that "reuse" is actually a synonym for several "Good Things" in Software Engineering, and that many software engineers and managers see it that way, and that to achieve these "Good Things" ne should concentrate on good software engineering process and methodology improvement in general. 2.1 The Case of Nokia Telecommunications The above position stems from a few observations made at Nokia Telecommunications.There has been an ongoing discussion about "reuse" and the necessity of it, which actually seems to have blinded us from the fact that in a sense we are already there. NTC's DX 200 product's internal architecture has been under scrutiny, and the results are being implemented. The product - and the organization - is organized into several platforms of different abstraction levels. New enhancements to common platforms are made partially by applying a standard procedure for generalizing specific features created initially for a narrow or even a customer-specific purpose. Different system and code generators have been built over the years, and the abstraction level for the average softare engineer is continuously getting higher and higher. All these - a common repository or a "platform"and the higher level tools - have been initiated as more or less independent projects. The end result from this drive towards clear goals is actually very similar to what is the cookbook approach toward reuse 1 . This is the observation that deserves some attention, since the word "reuse" has been mentioned only in the context that "we should be doing it", and usually it has been found out that "in a sense, we are already doing it", which revelation leads to either the conclusion that we are not doing enough or to the question about "where is the beef in reuse - do we need to think about it any more". The way process and methdology enhancements have usually started is that there has been a clear idea of what should be done and what benefits the improvement would bring with it. Thus, on the road to the current situation,the motivation has always been something else but reuse - better quality, better productivity or whatever. In the tough competition there seems to be little or no room for two-phased improvement paths forcing the organization first to invest to reach an intermediate state of "Great Expectations", and from there to proceed to financial success. It is possible to justify and start large investments with long pay-off times if the benefits are clear and large enough, but it seems unlikely that such investments can be done if the promised benefits have no direct consequences in the company's competitiveness. For this reason reuse should not be stated as a goal for an improvement program, and no company should make the error of believing that "doing reuse" is the goal of any of its actions 2 . 2.2 Planned company-level reuse can be bad for the company Some successful companies - including Nokia 3 - try to avoid too much centralized control, and favor more or less independent business units with clear customer-orientation and local authority for all business- related issues 4 . The business units are given responsibility of their customer accounts and products, they have precise profit goals, and therefore they have a large amount of authority. This implies that a company-wide program that affects the software production technology and the software engineering processes in the profit centers could disrupt the operations of the units. If a large-scale program is to be started, the program should be accepted both in the headquarters and in the units. Since the units usually have slightly different short-term and long-term goals, creating an agreement of what should be done, who pays for it and how much effort should be put in can be difficult. All this implies that large-scale reuse programs can be hard to start in some business environments. The necessary "CEO support" - or, at business unit level, the "unit manager support" - means that the CEO or the unit manager should start interfering with the operations of the units or the departments, which implies that the management philosophy has to be more or less centralized. If not, interfering with the local authority can disrupt the smooth local operations,which is usually not a good thing. In exceptional cases it can be done; for example, a quality system and the ISO9000 approval must be a company-wide effort. Implementing a similar program for an individual technique or set of techniques like reuse in the corporate level is somewhat unlikely since a corporate program interferes and disrupts the operations of the units, and therefore breaks the corporatemanagement culture,which is usually much more valuable than an independent implementation-level technology. In the unit - or "domain" - level such a program is easier to start, but the acceptable amount of resource expenditure is naturally much smaller. That means that investments are smaller and that the technology to be used must scale down, too, and that there should be a mechanism of building software engineering infrastructure in general and reuse technology in particular at least partially in a bottom-up manner. _______________________________ 1 Spend time and resources to get large common building blocks for application developers.Build system generators if you can. Take care of communications and quality control. 2 Excluding companies that try to sell reuse, naturally. 3 The CEOJorma Ollila has publicly stated that he is very happy with the distributed decision-making in the group and finds it a valuable asset. 4According to the sales people of e.g. Hewlett-Packard, HP has similar attitude towards local versus centralized decision-making. 3 Comparison with other work This position seems to contrast the positive results from e.g. IBM and Motorola. The described improvement method has a similarity with the Capability Maturity Model [3]. The difference can be only a superficial one: what has been said here is that the goals and motives for doing improvements should be suitable for the organization and that the goals should offer something measurable. This is in no contrast with what has been said in earlier work. On the other hand, the concept of having reuse as a goal for an organization is not believed to be universally true. While it is OK to have e.g. reuse as the initial theme for improvement, the goals should be connected to the company's business improvements. While the benefits of reuse programs cannot be denied, questions and doubts about the overall efficiency arises, and alternative what-if scenarios 5 would be very welcome to clarify the issues. [4] attempts to explain the problems IBM faced in the computer industry after the introduction of the IBMPC. The given explanation can be argued, but the authors continue to describe a "Silicon Valley model" of high technology management, which emphasizes fast actions, concentration on the core competence and architectural domination of the market. The model includes emphasis on loosely coupled small organizations with well defined interfaces, which means distributed control and command. The text implies that such an organization is "goo d", and claims that the pace of technology requires it or some other adaptive and slick organizational model. True or not,the Ferguson's and Morris's arguments have a similarity with this presentation,and it would indeed be hard to devise a way to implement a long-range reuse program in a fast setting they describe. The work about e.g. system generators [5] and other implementation level reuse technologies is in no contrast or agreement with this observation. The issue here is why and how should one run a reuse or other process improvement projects, not the actual steps in the potential projects. Work and opinions about Software Process Automation [6] are compatible with my alleged observation. Goals need to be defined, steps determined and results measured when one is trying to improve the performance of the organization. What might be left unsaid is that the organization needs to be aware of what it really needs, and should not concentrate on secondary or technological issues, at least not if the technology is not the business of the organization. _______________________________5 Such scenarios are naturally error-prone, and prove little, if nothing. They still present alternative lines of thinking, and are therefore valuable. References [1]R. L. Joos, "Software reuse at motorola," IEEE Software, vol. 11, September 1994. [2]A. Endres, "Lessons learned in an industrial software lab," IEEE Software, vol. 10, pp. 58-61, September 1993. [3]M. Paulk, B. Curtis,and C. et al., "Capability Maturity Model for Software," Tech. Rep. CMU/SEI-91-TR-24, Software Engineering Institute/Carnegie Mellon University, Pittsburgh, Pennsylvania, August 1991. [4]C. H. Ferguson and C. R. Morris, Computer Wars. Times Books, 1994. [5]D. Batory, V. Singhal, J. Thomas, S. Dasari, B. Geraci, and M. Sirkin, "The Genvoca model of software-systemgenerators," IEEE Software, vol. 11, September 1994. [6]A. M. Christie, Software Process Automation. Springer-Verlag, 1995. 4 Biography Aarne H. Yla-Rotiala is a software engineer at Nokia Telecommunications. He works at the software engineering department, and is currently involved in a project that is developing the software engineering environment in use at the development of DX 200 software. He received a M.Sc from the university of Helsinkiin 1990, and is enlisted as a Ph.D student at the department of computer science.