ArticlePDF Available


Software engineers are increasingly relying on object-oriented (OO) technology to develop adaptable software systems. However, the use of OO does not guarantee adaptability. Designers need to engineer adaptability into the software, even with OO. They should also consider the different factors that software systems require to be adaptable, namely, extensibility, flexibility, performance tunability and fixability.
4. Booch, G. Object Oriented Design with Applications.
Benjamin/Cummings, 1991.
5. Borghi, G. and Brugali, D. Autonomous map learning for a
multi-sensor mobile robot using diktiometric representation
and negotiation mechanism. In Proceedings of ICAR’95 (Sant
Feliu de Guixols, Spain, Sept. 20–22, 1995), pp. 521–528.
6. Brooks, R.A. A Robust layered control system for a mobile
robot. IEEE J. Robotics and Automation, RA-2, 1 (Mar. 1986).
7. Chin, R.S. and Chanson, S.T. Distributed object-based pro-
gramming system. ACM Comput. Surveys 23 (Mar. 1991), 91–124.
8. E., Helm, R., Johnson, R., Villisides, J. Design Patterns: Elements
of Reusable Object Oriented Software. Addison-Wesley, NY, 1994.
9. Johnson, R. Documenting frameworks using patterns. In Pro-
ceedings of OOPSLA ‘92 (Vancouver, B.C., Oct. 1992).
10. Minoura, T., Pargaonkar, S., Rehfuss, K. Structural active
object systems for simulation. In Proceedings of OOPSLA ‘93
(Washington D.C., Oct. 1993).
11. Object Management Group. The Common Object Request Broker:
Architecture and Specification. September 1992.
AMUND AARSTEN is a Ph.D. candidate at the Politecnico di Tori-
no in Torino, Italy; email:
DAVIDE BRUGALI is a Ph.D. candidate at the Politecnico di Tori-
no in Torino, Italy; email:
GIUSEPPE MENGA is a professor and chair of Automatic Con-
trols at the Politecnico di Tornino in Torino, Italy; email:
Permission to make digital/hard copy of part or all of this work for person-
al or classroom use is granted without fee provided that copies are not made
or distributed for profit or commercial advantage, the copyright notice, the
title of the publication and its date appear, and notice is given that copying
is by permission of ACM, Inc. To copy otherwise, to republish, to post on
servers, or to redistribute to lists requires prior specific permission and/or a
© ACM 0002-0782/96/1000 $3.50
58 October 1996/Vol. 39, No. 10 COMMUNICATIONS OF THE ACM
INtoday’s rapidly changing busi-
ness environment, adaptability is a
critical weapon for survival. Busi-
nesses must be adaptable in order
to meet increasingly narrow mar-
ket windows. This need for adapt-
ability at the business level has
changed the focus in many business-
es from efficiency to opportunity,
from reducing costs to generating
revenue. For example, an efficient
but inflexible system might reduce
costs, but might also make it impos-
sible for the business to engage in a
new revenue-generating opportuni-
ty. Those businesses that desire this
adaptability are redoubling their
efforts to make their underlying peo-
ple- and software-systems adaptable,
particularly for those systems that
could inhibit business-level adapt-
Because of these forces, software
developers need to deal with change
like never before. This need for
adaptable software systems is driving
the move toward object-oriented
(OO) technology in many circles.
Certainly one of the promises of OO
has been its ability to make software
more adaptable.
Using OO, however, does not
guarantee that the resulting software
will be adaptable. Adaptability must
be explicitly engineered into the
software, even with OO. Further-
more, adaptability is not a generic
quality of the software system as a
whole: Software systems are adapt-
able in specific, designated ways, if at
all. Therefore the adaptability must
not only be explicitly engineered
into the software, it must be engi-
neered into the software in places
where it will do the most good to the
It is no longer acceptable if a soft-
ware system is correct and solves the
problem for which it was designed.
Ideally the system will be able to
grow and change to solve slightly dif-
ferent problems over time. This cor-
responds to the three stages of the
evolution of software development:
Build the right thing, build the thing
right, and support the next thing.
Build the right thing corresponds to
validation. The requirements must
be accurately understood. There
continues to be a great deal of effort
spent trying to figure out what the
right thing really is. In today’s
world, however, the definition of
“right” changes between the time
when the perceived sponsor says
what they want and the time the
software is delivered.
Because the notion of “the right
thing” is a moving target, the only
way to satisfy the sponsor’s desires is
to make the software adaptable.
Only if the software is adaptable will
it be reasonable to change the thing
that gets built (which will be
“wrong” by then) into the thing that
the sponsor wants at that time.
Build the thing right corresponds to
verification, correctness, and defect
rate. Although everyone has always
been concerned with reliability and
faithful translation of the require-
ments into a solution, the market
was not always willing to pay a lot of
extra money for reliability.
Although there still is not a general
willingness to pay extra for low
defect rates, there seems to be an
increasing intolerance for defects.
In cases where standards have creat-
ed a level playing field, customers
today appear to have less brand loy-
Aspects of Software Adaptability
Mohamed Fayad and Marshall P. Cline
COMMUNICATIONS OF THE ACM October 1996/Vol. 39, No. 10 59
alty than ever, and are increasingly
willing to buy a competitor’s prod-
uct if that will be more reliable.
There are probably many reasons
for this shift in attitude, among
them the fact that software current-
ly runs core business functions
rather than just being a tool for
finance, and because the average
software customer is less technical
due to the huge increase in the
market breadth. But whatever the
reasons, customers are demanding
simpler interfaces and more reli-
able results.
Because fixing defects invariably
means changing the software, the
best way to build the thing right is to
engineer adaptability into the sys-
tem. Only if the software is adaptable
will it be reasonable to introduce
changes and/or fix defects with a
low probability that the new changes
will introduce new defects.
Support the next thing. There are
several ways that today’s software can
provide significant value when build-
ing tomorrow’s software. One such
approach is to build reusable parts
that are viewed as “Lego” pieces that
can be snapped together later to
build something different. This
approach clearly works in the small
(e.g., with simple class libraries) and
in relatively low-level areas such as
GUI and database frameworks. How-
ever, in our experience it has less
success at the higher levels in busi-
ness applications. There are many
reasons for this, but the simplest is
the general tension between
reusability and usability: The more
reusable something is, the more
dials and knobs it needs, and this in
turn makes it less easy to use.
On the other hand, making
something easier to use typically
reduces its ability to be reused in a
different domain or for a different
purpose (single-purpose tools are
usually easier to use than multipur-
pose tools). Because of this and
other factors, the high-level compo-
nents in one product are not gener-
ally reusable when building a
different product, and making
these high-level components more
reusable across problem domains
typically increases the cost of using
them at all.
The other way to leverage cur-
rent software investment is engi-
neer adaptability into the system,
which makes it feasible to adapt the
existing system to fit tomorrow’s
needs. This is slightly different than
the reusable parts approach, since
the asset in this second approach is
the adaptable system, whereas in
the reusable parts approach the
asset is the pile of parts with which
the systems are built. Another way
to look at the difference between
these approaches is to notice that
the reusable parts approach relies
on programmers to build tomor-
row’s systems from today’s parts,
whereas the adaptable system
approach is like building a spread-
sheet: The adaptable system can be
customized by end users, or at least
by a lower caliber of developer.
Spreadsheets were an early
example of adaptable systems that
were completely customizable by
end users. The most recent exam-
ple is the Web browser, since, in
combination with the Web author-
ing tools, normal users can publish
static content in a complex distrib-
uted application with a simple
WYSIWYG editor.
There are four factors systems
generally need to be adaptable; two
imply high-level changes (extensi-
bility and flexibility), and two imply
low-level changes (tunability and
Extensibility means it is easy to
change the system’s capabilities in
amount, but not in kind. For exam-
ple, a system is extensible if it is easy
to add another graphical device, or
another drawing shape, or another
of what it already has.
Flexibility means it is easy to
change the system’s capabilities in
kind. For example, taking some-
thing that was a graphical system
and making it sensory- or sound-
based. Flexibility is often harder
than extensibility, especially when
on-the-fly changes are desired.
Performance tunability can also be
thought of as a change activity. A
tunable system can be easily
changed in ways that affect perfor-
mance. For example, CORBA
objects are location-independent,
which allows objects to be physically
moved around on the network (e.g.,
to reduce network traffic) without
impacting very much, if any, code.
Java is even more extreme in this
aspect, since the objects can be
moved to any machine on the net-
work on the fly. Naturally none of
this negates the need to do up-front
performance engineering work [1].
However the complexity of current
systems makes it more and more
unlikely that this performance engi-
neering work will be perfect, if for
no other reason than the fact the
software has changed since the per-
formance engineering work was
done, therefore it is increasingly
necessary to engineer tunability into
today’s system.
Fixability is defined as the ability
to fix one thing without breaking
two other things. This can be very
difficult in large systems. It requires,
among other things, separation of
interface from implementation,
and fairly tight specification of the
behavior of each component. How
design patterns fit in: The most
powerful design patterns exist to
support some kind of change. Each
of these patterns provides a specific
axis of change, a specific hinge,
where the system will be adaptable.
Very generally speaking, use a
design pattern wherever you need
such a hinge.
1. Berg, B., Cline, M., Girou, M. Lessons
learned from the OS/400 OO project.
Commun. ACM 38, 10 (1995), 54--64.
2. Cline, M. and Fayad, M. Object-Oriented
Design Patterns. (1995) Course notes, 800
Mohamed Fayad ( is an
associate professor at the University of Neva-
da, Reno. Marshall P. Cline (cline@parashift.
com) is the president of Paradigm Shift, Inc.,
Potsdam, N.Y.
©ACM 0002-0782/96/1000
... Além disso, um sistema de software dito adaptável pode tolerar mudanças em seus ambientes sem a necessidade de intervenção externa. Segundo Fayad e Cline [41] existem quatro fatores que normalmente tornam um sistema adaptável: extensibilidade, flexibilidade, tunability e fixability. Os dois primeiros implicam em mudanças de mais alto nível e os dois últimos implicam em mudanças de baixo nível. ...
... Tunability é característica da capacidade de melhorar aspectos relacionados a performance. E por fim, a Fixability é a como a capacidade de consertar uma IndoLoR -An Adaptable Platform for Indoor Location Figura 6. Visão Arquitetural de Componentes e Conectores coisa sem quebrar outras duas outras coisas [41]. ...
... Adaptation has been mentioned in several occurrences of research work, and garnered interest among researchers for some time: (Fayad and Cline 1996); (Yarvis, Reiher et al. 1999); (Narayanan, Flinn et al. 2000); (South, Lenaghan et al. 2000); (Efstratiou, Cheverst et al. 2001); (Aksit and Choukair 2003); (Keeney and Cahill 2003). Adaptation is still of interest in the pervasive computing field. ...
Full-text available
Depuis son introduction par Mark Weseir, l’informatique omniprésente ne cesse de solliciter de l’intérêt croissant dans la sphère de l’innovation technologique. Soutenue par l’évolution technologique des systèmes embarqués, la miniaturisation et l’intégration de divers dispositifs communicants dans les applications informatiques, cette vision d’une technologie invisible, distribuée et intelligente devient de plus en plus concrète. Dépassant ainsi, les systèmes classiques vers des systèmes omniprésents sensibles à leurs contextes assistant d’une manière active et intelligente ses usagers. En leur apportant aide et commodité dans l’accomplissement des activités quotidiennes, et ce dans différents domaines. Mettre en place ces systèmes omniprésents proactifs, intelligents et permettant une utilisation adaptée, naturelle et conviviale soulève encore beaucoup de défis pour assurer une proactivité sensible au contexte et adéquate au besoin de l’utilisateur. La majorité des travaux sur l’omniprésence se sont concentrés sur le contexte actuel. Par contre une nouvelle tendance appuie l’idée de l’importance de prendre en considération l’évolution du contexte pour prévoir un contexte futur et permettre de fournir une adaptation active et rapide à des situations futures. Montrant aussi l’importance de développer un cadre formel et général pour le contexte et la prédiction, sauf que jusque-là les approches formelles de la prédiction du contexte général sont manquantes. Ce travail s’inscrit dans ce cadre. Et il porte sur le formalisme du contexte et la prédiction du contexte dans les systèmes omniprésents proactifs. Il vise à spécifier et modéliser le contexte et la prédiction du contexte futur dans un cadre formel tenant compte de l’évolution temporelle logique de l’espace de service. En premier lieu, nous avons défini le contexte sous une vision multidimensionnelle respectant une logique d’évolution spatiotemporelle. En second lieu, nous avons spécifié et modélisé le contexte dans un cadre formel logique intégrant la dimension spatiotemporelle. À la fin, nous avons spécifié et modélisé la prédiction de contexte futur dans un cadre formel et logique et sous une vision multidimensionnelle, dynamique et non déterministe basée sur la logique PCTL et le modèle de vérification stochastique.
... Having an adaptable learning system will result in more coverage of different user requirements, targets and available resources. During the preliminary work in this domain, Fayad and Cline (1996) discuss four factors which are generally required when working on developing an adaptable system. These are extensibility, flexibility, tunability and fixability. ...
Conference Paper
Full-text available
Purpose – This paper will focus on the limitations distance learning students encounter when they are required to access virtual learning environments (VLEs) from developing countries. Ideally, every student accessing a VLE should share the same experience regardless of their geographical location or broadband connectivity strength. Currently, the main limitation is the ability of information systems to adapt to the users depending on their technological platform, broadband quality and geographical location. Design/methodology/approach – The aim of this research paper is to work towards optimising the use of information systems within distance learning to mitigate the current elements of the digital divide. Firstly, we will be introducing the digital divide and its implications on distance learning students. Secondly, we will be considering and criticizing current delivery of VLEs and assessing the current restraints based on broadband standards, geographical location and device compatibility. Finally, based on these findings we will amalgamate all insight gained in order to come up with a viable solution. Findings – The findings of this paper will present a number of alterations undertaken at both client and server side which can augment the student experience in learning via virtual environments. Research limitations/implications – Based on the proposed findings, the paper presents a solution which can assist in mitigating the digital divide for students undertaking technologically enabled distance learning. Practical implications – This solution proposed is based on the hurdling of previously identified impediments within literature. Thus, the solutions highlighted in the paper aim at enhancing the student's virtual learning experience when using online platforms. Originality/Value – The technologies adopted within the paper address the various constraints presented by telecommunication systems within developing countries by customising the manner in which virtual learning environments are employed. Making further use of novel technologies being adopted for educational aspects, the paper presents a unique solution to lessen the digital divide experienced between students utilizing information systems for learning within dissimilar infrastructures.
Often, changing market dynamics require business applications to quickly and efficiently adapt to the needs of the ensuing business environment. Business Rules excel in delivering software solutions that are implicitly adaptable to changing business requirements; thus they can prove to be an effective tool to provide necessary flexibility and control for rapidly deploying changes across a wide array of business operations. When a proper design is employed, business rules provide a robust and capable way of enabling enterprise software that adapts to changing business needs. In other words, business rules find varied applications and ways of use, for example, managing a pending problem, using it as production rules and for facilitating collaboration between various systems, etc. However, despite a plethora of tools and technologies available, most organizations still find it difficult to define or model workable business rules explicitly. Furthermore, from a macroscopic point of view, rules are important and inseparable artifacts in governing a software application to make it comply with the system goals. In this paper, the current ways to manage business rules along with their pitfalls are discussed, and therefore, a new approach for developing rule-based business architectures is proposed. The proposed approach allows for both managing and reusing business rules.
Purpose The purpose of this paper is to theorize the social dynamics of modifiable off-the shelf software (MOTS) configuration process. We do so by formulating theoretical propositions about the configuration process. Design/methodology/approach We have conducted a comprehensive review of the literature on MOTS configuration and the associated challenges to draw on the properties of MOTS. We then examined these properties through the lens of Social Construction of Technology (SCOT) to formulate our theoretical propositions. Findings We formulate theoretical propositions about the configuration process. We also develop four scenarios based on our theoretical propositions for managing the configuration process of MOTS. These scenarios categorize the difficulty level of the configuration by two theoretical groups: malleability and interpretive flexibility. Practical implications Our findings especially the scenarios can guide practitioners when managing configuration processes. Originality/value We synthesize the literature on MOTS. The theoretical contributions emphasize the social dynamics in configuring this type of software which is an angle that has not been developed in previous literature.
Full-text available
Ubiquitous (or Pervasive) Computing is a new domain in Computer Science resulting from the emergence and evolution of both distributed systems and mobile computing. Technology is moving beyond the personal computer towards a growing trend of embedded microprocessors in everyday objects and is demanding an unobtrusive connectivity between them in order to serve users at anytime and anywhere. The main objective of a ubiquitous computing system is to provide adaptive services proactively, without explicit user intervention and according to the user's current context. Despite interesting previous research works, there is still a lack of software tools and related research in terms of comprehensive context modeling, architecture of context-aware ubiquitous systems, and dynamic adaptation approaches in ubiquitous service computing environments. This chapter proposes a conceptual architecture to provide dynamic adaptability in ubiquitous services based on context-awareness and user preferences. As part of this proposal, the authors detail an ontology-based context modeling approach, a multi-agent architecture to support the development of ubiquitous computing applications, and a case-based reasoning method for service adaptation.
Conference Paper
Reputation is the opinion (more technically, a social evaluation) of the public towards a person, a group of people, or an organization. In other words, reputation is the general estimation that the public has for a person or an institution. It is an important factor in many fields, like business, online communities or social status. It is also a subject of study in social, management and technological sciences. Its influence may range from competitive settings like markets to cooperative ones like firms, organizations, institutions and communities. Furthermore, reputation also acts on different levels of agency, individual and supra-individual. At the supra-individual level, it concerns groups, communities, collectives and abstract social entities (such as firms, corporations, organizations, countries, cultures and even civilizations). It affects phenomena of different scale, from everyday life to relationships between nations. Reputation is a fundamental instrument of social order, based upon distributed, spontaneous social control. As can be seen, there is nothing different in the way reputation is handled in any of those areas of application. In fact, reputation is the same in all of them. Therefore, the reason for the analysis of this concept, with the sole purpose of extracting its core knowledge, it is a worthwhile reason, especially if you are planning to reuse it in numerous applications, while still maintaining a cost effective nature.
A survey is presented of hardware and software structural adaptation in control systems to take account of application details, the environment, and faults. Dynamic adaptation is possible in real-time systems, including multiprocessor and distributed ones. Factors are identified that govern the static adaptation stages.
On the basis of an analysis of different types of redundancy in dynamic and structure adaptation of single- and multi-node real-time systems, a number of methods for quantitative estimation of the adaptiveness of these systems are proposed. The following factors are taken into account; degree of rigidity (hardness) of the time constraints; potential for discrepant decisions and variations in the deadlines, reconfigurability of hardware structures; heterogeneity of the load of processors in multi-node systems, and the use of modular hardware and software facilities.
Programming in a distributed environment is a complex activity. Programmers need to be aware of issues unrelated to their domain of problem, and are often unprepared for the challenges the concurrent programming brings. The interaction of their components becomes more complex, and makes it difficult to validate the design and correctness of the system. Supporting separation of concerns in the design and implementation of operating systems can provide a number of benefits such as comprehension, reusability, extensibility and adaptability in both design and implementation. We have tackled this problem by adopting the technique of separation of concerns in concurrent programming. In this paper we demonstrate an Aspect- Oriented Framework (ACL) that can be used for system software such as operating systems. We also show how the separation of system aspectual properties from components. Readers/Writers problem is demonstrated using our framework. Our framework, which is based on aspect- oriented technology as well as language and architecture independence, is a component based model.
Full-text available
This article describes some of the lessons learned when a team of 150 developers with a minimal prior exposure to object-oriented (OO) technology undertook a large development project. Team members became proficient in OO design, using C++ as an OO language rather than just using C++ as a better C, and developed IBM's RISC version of the AS/400 and System/36 operating systems from 1992 to 1994 in Rochester, Minnesota. The project contains 14,000 thousand classes, 90,000 thousand methods, and 2 million lines of C++ integrated into 20 million lines of total code. The result of their efforts was the development of a product that is being used daily by a substantial international customer base.
A new architecture for controlling mobile robots is described. Layers of control system are built to let the robot operate at increasing levels of competence. Layers are made up of asynchronous modules that communicate over low-bandwidth channels. Each module is an instance of a fairly simple computational machine. Higher-level layers can subsume the roles of lower levels by suppressing their outputs. However, lower levels continue to function as higher levels are added. The result is a robust and flexible robot control system. The system has been used to control a mobile robot wandering around unconstrained laboratory areas and computer machine rooms. Eventually it is intended to control a robot that wanders the office areas of our laboratory, building maps of its surroundings using an onboard arm to perform simple tasks.
Conference Paper
A structural active-object system (SAOS) is a transition-based object-oriented system suitable for rapid development of various concurrent systems. A SAOS consists of a collection of interacting structural active objects (SAOs), whose behaviors are determined by the transition statements provided in their class definitions. Furthermore, SAOs can be structurally and hierarchically composed from their component SAOs like hardware components. These features allow SAOs to model components to be simulated more naturally than passive objects used in ordinary object-oriented programming. Also, we can easily create new kinds of components by using the inheritance mechanism. Executions of transition statements may be eventand/or time-driven, and hence discrete, continuous, and mixed-mode simulation is possible. Prototype simulation programs were developed as SAOS programs for such diverse applications as queuing systems, digital/analog/mixed-mode circuit simulation, process control, manufacturing control, road network traffic simulation, computer networks, and elevator systems. Graphical user interfaces can be added to SAOS programs with minimal extra effort, or executable SAOS programs can be graphically created.