In computer science and software engineering, reusability is the use of existing assets in some form within the software product development process; these assets are products and by-products of the software development life cycle and include code, software components, test suites, designs and documentation. The opposite concept of reusability is leverage, which modifies existing assets as needed to meet specific system requirements. Because reuse implies the creation of a , it is preferred over leverage.
Subroutines or functions are the simplest form of reuse. A chunk of code is regularly organized using modules or namespaces into layers. Proponents claim that objects and software components offer a more advanced form of reusability, although it has been tough to objectively measure and define levels or scores of reusability.
The ability to reuse relies in an essential way on the ability to build larger things from smaller parts, and being able to identify commonality among those parts. Reusability is often a required characteristic of platform software. Reusability brings several aspects to software development that do not need to be considered when reusability is not required.
Reusability implies some explicit management of build, packaging, distribution, installation, configuration, deployment, maintenance and upgrade issues. If these issues are not considered, software may appear to be reusable from design point of view, but will not be reused in practice.
Software reusability more specifically refers to design features of a software element (or collection of software elements) that enhance its suitability for reuse.
Many reuse design principles were developed at the WISR workshops.
Candidate design features for software reuse include:
Adaptable
Brief: small size
Consistency
Correctness
Extensibility
Fast
Flexible
Generic
Localization of volatile (changeable) design assumptions (David Parnas)
Modularity
Orthogonality
Parameterization
Simple: low complexity
Stability under changing requirements
Consensus has not yet been reached on this list on the relative importance of the entries nor on the issues which make each one important for a particular class of applications.
Cette page est générée automatiquement et peut contenir des informations qui ne sont pas correctes, complètes, à jour ou pertinentes par rapport à votre recherche. Il en va de même pour toutes les autres pages de ce site. Veillez à vérifier les informations auprès des sources officielles de l'EPFL.
En informatique, la programmation modulaire reprend l'idée de fabriquer un produit (le programme) à partir de composants (les modules). Elle décompose une grosse application en modules, groupes de fonctions, de méthodes et de traitement, pour pouvoir les développer et les améliorer indépendamment, puis les réutiliser dans d'autres applications. Le développement du code des modules peut être attribué à des (groupes de) personnes différentes, qui effectuent leurs tests unitaires indépendamment.
En informatique, et plus particulièrement en développement logiciel, un patron de conception (souvent appelé design pattern) est un arrangement caractéristique de modules, reconnu comme bonne pratique en réponse à un problème de conception d'un logiciel. Il décrit une solution standard, utilisable dans la conception de différents logiciels. Un patron de conception est issu de l'expérience des concepteurs de logiciels. Il décrit un arrangement récurrent de rôles et d'actions joués par des modules d'un logiciel, et le nom du patron sert de vocabulaire commun entre le concepteur et le programmeur.
Explore la programmation modulaire, en mettant l'accent sur la séparation de l'interface et de l'implémentation dans les modules et l'utilisation de make et Makefile pour gérer les dépendances.
Couvre la décomposition modulaire dans les projets logiciels, en mettant l'accent sur la réduction des dépendances et les avantages de la programmation modulaire.
This paper introduces CoopnTools, a tool set allowing the support of object-oriented specifications written by means of the language CO-OPN/2, based on synchronised algebraic Petri nets. In particular, this paper shows how concrete mechanisms dealing with ...
In this paper, we describe Teapot, a domain-specific language for writing cache coherence protocols. Cache coherence is of concern when parallel and distributed systems make local replicas of shared data to improve scalability and performance. In both dist ...
This article considers the software problems of reuse, interoperability and evolution in the context of Ambient Intelligence. A novel approach is introduced: the Environment, Application, Adaptation (EAA) is streamlined for Ambient Intelligence and is evol ...