[KEYWORDS: CASE, computer aided software engineering function point analysis, object-based development, programming productiviq, repositories, reuse, sojhare costs, software engineering economics, software metrics.] F'orthcoming:

A serious problem in the classification of software project artefacts for reuse is the natural partitioning of classification terms into many separate domains of discourse. This problem is particularly pronounced when dealing with requirements artefacts that need to be matched with design components in the refinement process. In such a case, requirements can be described with terms drawn from a problem domain (e.g. games), whereas designs with the use of terms characteristic for the solution domain (e.g. implementation). The two domains have not only distinct terminology, but also different semantics and use of their artefacts. This paper describes a method of cross-domain classification of requirements texts with a view to facilitate their reuse and their refinement into reusable design components. Keywords Requirements Refinement, Reuse, Information Retrieval 1. Introduction Reuse of development work-products in the earliest phases of software life-cycle, e.g. requirements engine...

We present an enrichment of the Anna specification language for Ada aimed at dealing not only with functional specification of packages but also with non-functional information about them. By non-functional information we mean information about efficiency, reliability and, in general, any software attribute measuring somehow the quality of software (perhaps in a subjective manner). We divide this information into three kinds: definition of non-functional properties, statement of non-functional behaviour and statement of non-functional requirements; like Anna annotations, all of this information appears in Ada packages and package bodies and their syntax is close to Ada constructs. Non-functional information may be considered not only as valuable comments, but also as an input for an algorithm capable of selecting the "best" package body for every package definition in a program, the "best" meaning the one that fits the set of non-functional requirements of the package in the program.

L oosely coupled distributed systems are characterised by a separation of resources and a consequent need for a facility to aid in the location of those resources. Traditionally, this role of resource location has been fulfilled by a name service i.e. a facility which maps the name of a resource to its location at a given network address. As the size of the resource name space grows, however, additional support for resource location is required, in the form of support for the discovery of the name of the resource that is to be located. A trading facility implements an approach to resource location which eliminates the need to know the name of a resource in order to locate it and instead allows specification of a required service in an abstract manner. Resources (or services) are classified by type, and the location of such services is guided principally by a specification of the required service type, with requests for services being mapped directly to services of an appropriate type...

Growing competition in the investment banking industry has given rise to increasing demand for high functionality software applications that can be developed in a short period of time. Yet de-livering such applications creates a bottleneck in software development activities. This dilemma can be addressed when firms shift to develop-ment methods that emphasize software (eusabili-ty. This article examines the productivity implications of object and repository-based in-tegrated computer-aided software engineering (ICASE) software development in the context of a major investment bank's information systems strategy. The strategy emphasizes software

Software systems are characterised both by their functionality (what the system does) and by their non-functionality (how does the system behave with respect to some observable attributes like performance, reusability, reliability, etc.). Both aspects are relevant to software development. However, non-functional issues have received little attention compared to functional ones. In this position paper we highlight the role of non-functionality, and we claim for a notation to deal with them. We enumerate some design principles for such a notation, and then we make a proposal, which allows to define non-functional attributes of software, non-functional behaviour of components with respect to these attributes, and also non-functional requirements over implementations. Keywords: Component, Non-Functional Attribute, Non-Functional Behaviour, Non-Functional Requirements. Workshop Goals: learning; to highlight a particular problem not always perceived as such; to propose a concrete...

Reuse of software components emerged as an industry goal subsequent to a NATO conference in 1969 where Doug McIlroy first introduced the concept. Over the two decades since, reuse remained a topic of much discussion and some research; and, although different views exist on the degree of success enjoyed by software developers in today's industry, most students of the state of software development practice agree that McIlroy's original vision has yet to be achieved and that increased reuse of software components is possible and remains a goal worth pursuing.

Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.5.4 Special Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.6 Semantics of Programming Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.6.1 Semantics of Ada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.6.2 Action Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.7 Specification Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.7.1 Early Algebraic Specification Languages . . . . . . . . . . . . . . . . . . . . . . . . 53 4.7.2 Recent Algebraic Specification Languages . . . . . . . . . . . . . . . . . . . . . . . 55 4.7.3 The Common Framework Initiative. . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5 Methodology 57 5.1 Development Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.1.1 Applica...

Abstract. Open Source Software (OSS) communities have not yet taken full advantage of reuse mechanisms. Typically many OSS projects which share the same application domain and topic, duplicate effort and code, without fully leveraging the vast amounts of available code. This study proposes the empirical evaluation of source code folders of OSS projects in order to determine their actual internal reuse and their potential as shareable, fine-grained and externally reusable software components by future projects. This paper empirically analyses four OSS systems, identifies which components (in the form of folders) are currently being reused internally and studies their coupling characteristics. Stable components (i.e., those which act as service providers rather than service consumers) are shown to be more likely to be reusable. As a means of supporting replication of these successful instances of OSS reuse, source folders with similar patterns are extracted from the studied systems, and identified as externally reusable components. The intended users are members of the OSS development community. Based on the empirical study of the OSS systems and observations made during the study, four practical courses of action are recommended in order to enhance the reusability of current folders that have not been identified as potentially reusable, both from an internal and external standpoint. 1

Part 1 – Establishing a Software Reuse Program