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, ZD retains much of the flexibility of freely combinable modules, while retaining capability to provide provably correct software.

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.

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.

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.

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.

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 CSCUs RAM Process (RAMP) which is based on the best practices among System Sciences DivisionUs most successful reuse projects and on the current research and development that is taking place throughout the software reuse community.

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.

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.

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.

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.

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.

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.

Abstract

This position paper reports on the work being carried out by the Application of Software Models project at the Software Engineering Institute. The activities of the project serve two primary purposes: (1) to contribute to our understanding of domain engineering and systematic reuse, and (2) to support transition to other organizations. The project is now working to transition the domain engineering approach piloted and documented over the past several years, and in the pilot testing of our new method for systematic reuse strategic planning. Our approach is fundamentally based on the notion that successful practices in mature engineering disciplines are based on the use of models and architectures, systematic quantification, analysis and prediction of system properties (quality attributes),and decisions on trading off various attributes. We present our two-tier process for systematic reuse: the product line approach and the model-based software engineering framework.

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.

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.

Abstract

DARE (Domain Analysis and Reuse Environment) is a tool we are developing to help users perform domain analysis, the activity of identifying and documenting the commonalities and variabilities in a set of related software systems. A DARE domain analysis is captured in a collection of domain models, which are views of a domain. DARE also supports the collection of domain assets in a database, and provides a library search facility. The library and search engine together form an asset repository.

DARE users produce a Domain Analysis Book that contains all domain analysis inputs, outputs, and supporting material (table of contents, index, glossary, citations, and so forth).

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.

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.

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 Objectory's system engineering (OOSE) and business engineering (OOBE).

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.

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.

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.

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 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.

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.

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.

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.

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.

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?

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

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.

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.

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.

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.

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.

Abstract

Domain analysis often is performed by studying examples of existing systems and models for the domain. However, this approach, which is purely bottom-up, gives a view of the domain that is limited to what has been developed in the past. We also need a view of what is to be developed in the future to determine which components offer the greatest strategic benefits. To obtain a view of the future we can analyze enterprise models as part of the domain analysis process. This changes domain analysis into a combination top-down,/bottom-up process.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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?".