Attribute-Based Software Evolution: Patterns and Product Line Forecasting Davor Svetinovic
Michael Godfrey
Software Architecture Group University of Waterloo Waterloo, Ontario, N2L 3G1, CANADA
Software Architecture Group University of Waterloo Waterloo, Ontario, N2L 3G1, CANADA
[email protected]
[email protected]
ABSTRACT This paper presents a new systematic approach for the study of software evolution. The approach is based on the use of functional and quality attributes to recover, document, and apply knowledge about how and why software systems evolve. In the first part of paper, we discuss how the study of software evolution in terms of attributes makes it possible to draw parallels between software evolution and other types of evolution, such as natural evolution. This allows us to analyze their similarities and to map some of the results and methodologies from these other fields to software evolution. In the second part of paper, we discuss how the use of attributes can make knowledge about how a system has evolved more easily applicable to other attribute-based techniques of software engineering, including goal-driven requirements engineering processes [1, 19], Architecture Tradeoff Analysis Method (ATAM) [11], and Attribute-Based Architectural Styles [13]. In particular, we emphasize attribute-based evolution patterns as a practical form of preserving and applying knowledge about how a software system evolves, and we describe their use in product line design and forecasting. Finally, we present an abbreviated example history of the Linux SCSI device driver subsystem.
Keywords software evolution, software architecture, software product lines, attribute-based modelling
1.
INTRODUCTION
Theodosius Dobzhansky wrote “Nothing in biology makes sense except in the light of evolution” [6], which reflects the level of importance and use of knowledge about evolution in other sciences. Although an analogous statement about the importance of evolution in software engineering would probably be too strong, we consider that many of the existing methodologies and techniques in software engineering would be greatly improved by taking into account a large body of software systems evolution knowledge.
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. ICSE ’02 Buenos Aires, Argentina Copyright 2001 ACM 0-12345-67-8/90/01 ...$5.00.
Previous research in software evolution [8, 9, 12, 15, 16, 17] has shown that software often evolves differently than one plans and expects. In order to deal with the problems that arise due to this unpredictability, one has to find a way to capture and reuse knowledge about these uncontrolled changes and what causes them. The goal of our current study is to build a systematic process and framework for preserving and applying knowledge about evolution in attribute-based techniques in the other software engineering areas (e.g., goal-driven requirements engineering processes [1, 19], Architecture Tradeoff Analysis [11]). Our approach is based on the use of attributes to capture evolution. The applications of the approach will extend existing attribute theory, and facilitate the unification and transitions among different techniques. The study and use of attributes has made many contributions to software engineering practice. Goal-oriented requirement engineering processes have helped capture and model a wider range of requirements than previously possible, improve requirements traceability, and facilitate the process in general [19]. AttributeBased Architecture Styles (ABAS) have allowed qualitative reasoning about the use of a particular architectural style [13]. Architecture Tradeoff Analysis (ATA) method relies upon the use of quality attributes to analyze and express the architectural tradeoffs [11]. Quality attributes are the initial artifact for several architecture design processes, including the Architecture-Based Design Method [1]. Besides providing the driving force, quality attributes also serve as the connection among all these techniques and methods [10]. All of the previously mentioned techniques are based upon a solid understanding of the interdependencies among attributes, especially conflicting ones. Several studies have tackled the problems of complex dependencies between the attributes and how to manage them [3, 14]. In order to optimize the qualities of the system, it is not enough to consider only the quality attributes and their priorities at one moment in time: The qualities of the system change, and the stakeholders’ quality priorities change. We need a way to prioritize and estimate changes in quality attributes. The systematic study of these changes, and how and why they have occurred, will help us achieve this. The approach that we are taking to solve the problem is to find an initial set of attributes, the relationships among them, the forces that act upon them, and to capture changes that occur frequently in a pattern format. Several evolution case studies for different product families are conducted during which the theory and format are refined. The goal is to obtain an efficient reconstruction process, attribute theory, and format that will allow routine study and documentation of software evolution and efficient application of the
results in other areas. Currently, it is a well known that the majority of software development projects either fail completely or result in a system that does not satisfy its original budget, schedule, feature set, or nonfunctional requirements. Studying evolution can show us the forces that participate in the development, selection, and evolution of a system. A deep understanding of all these forces will help us concentrate our efforts on producing systems that will be successful and widely accepted. The paper consists of three parts. In the first part, we discuss the theoretical aspects of the approach, including a definition of software evolution that emphasizes the similarities between natural evolution and attribute-based software evolution. In the second part, we present the practical process for the evolution recovery and documentation through the use of patterns and stories. In the third part, we present an example of evolution patterns, and the application of attribute-based evolution patterns, together with other attribute-based techniques, to facilitate the design and forecasting of product lines.
2.
THE DEFINITION
To study software evolution, we must first define what, precisely, software evolution is. Several questions immediate present themselves: What constitutes evolutionary change in a software system, and what is merely “phenotypic” change? What is a software phenotype? How ought we to classify changes in software? How is software evolution distinct from software maintenance? Since biological evolution has a long history and is a well-established science, we should try to reuse from it some ideas, concepts, and principles that have broader applicability, that is, those that capture changes and behaviors that are not only specific to living beings. This will help us find answers to previously mentioned questions, many others, and help us study software evolution more efficiently. Chris Colby writes [5]: Evolution can occur without morphological change; and morphological change can occur without evolution. Humans are larger now than in the recent past, a result of better diet and medicine. Phenotypic changes, like this, induced solely by changes in environment do not count as evolution because they are not inheritable; in other words, the change is not passed on to the organism’s offspring. Phenotype is the morphological, physiological, biochemical, behavioral and other properties exhibited by a living organism. An organism’s phenotype is determined by its genes and its environment. Most changes due to environment are fairly subtle, for example size differences. Large scale phenotypic changes are obviously due to genetic changes, and therefore are evolution. The author of the previous paragraph tried to clarify misconceptions about evolution in biological evolution. Laypersons often confuse phenotypic changes, introduced solely by the effects of environment on the species, for more essential, evolutionary changes, which are transferred from a generation to the other. In the biological context, evolution is a change in the gene pool of a population over time. (A gene is a hereditary unit that can be passed on unaltered for many generations. The gene pool is the set of all genes in a species or population.) To further explore the parallel between biological and software evolution, we must define what a “software population” is. For our purposes, the most appropriate and logical parallel between population or species, in biological terms, and the ones in software terms,
is to consider later ones to be equivalent to types of software, or software families like operating systems, compilers, word processors, etc. This implies in turn that the notion of an individual living being, in biological sense, is analogous to the notion of a particular product in software world (for example, Linux as an operating system, Microsoft Word as a word processor, etc.). Based on previous reasoning and conventions, one could define evolutionary changes as the ones occurring at the level of a product family, and affects more or less, all its members. These changes are usually essential, since they are incorporated in all members of the family, and the ones that do not incorporate them become more or less extinct. For example, in the case of operating systems, incorporating the support for 32-bit processors was one of the changes that has been cause of “death” for some operating systems, and most of the ones that have survived run on 32 bit machines. The other example is the support for virtual memory. The first change, is the one invoked by the changes it the “environment” — hardware on which OS runs, and the other one is an “internal” change which could be compared to drifts in genes not provoked by environmental forces. On the other hand, phenotypic software changes are defined as the changes that occur and affect one product through its lifetime, and do not belong to previously mentioned group of changes. This group consists mostly of changes that are not so crucial to be incorporated into the product, but give it some competitive edge when compared to the other products from same family. Evolutionary changes consists mostly of changes that must be incorporated into the system in order for the system to stay in widespread use. The natural way for detecting and tracking the evolutionary changes is through the study of essential attributes and their changes. Therefore, our working definition of software evolution is: Software evolution is change in essential properties (attributes) of a product family over time. Essential properties are the ones that, with minor differences, exist in all products of a family. A product family is a set of products that provide same functionality with minor differences, and are used for the same purpose. Many phenotypic software changes have been studied, either directly or indirectly, as part of studies in software maintenance. These studies give us insight in how a product changes over time, but usually ignore why and how more essential changes appear and affect product families. The results of these studies contribute to the improved development of that and similar products and may improve the processes involved. On the other hand, detailed studies of evolution in terms of changes that we cover by our definition would, in addition, contribute to the improvement of software business, software technology forecasting, etc. For example, by knowing what forces acted on the selection of changes that were incorporated into the software and types of these changes, we can estimate more precisely what kinds of changes will the architecture of the system need to support later, so we can concentrate on making the architecture amenable to these kind of changes.
3. COMPARISON AND PRINCIPLES In this section, we explore the core principles of software evolution through a comparison between natural and software evolution. We emphasize evolution mechanisms, since they directly influence the evolution recovery process and applications to other software engineering fields. Before we start the discussion about forces that are responsible for provoking and managing the evolution, we should discuss necessity of software systems and the continuity in the appearance of new types of software.
3.1 Necessity, Continuity, and Diversity
3.2 Evolution Mechanisms
It is a popular belief that technology exists to help us fulfill our fundamental needs; this in turn leads to the belief that the forces that drive technological invention and evolution are based, at their core, on the need to fulfill these fundamental needs. Although one could argue that this is an accurate view for more basic technologies, such as those related to agriculture, it is much harder to argue that this is the case for most computer-related technologies. On the other hand, software is pervasive and unavoidable in modern society. In fact, almost all aspects of our lives today are dependent directly or indirectly on software technology. In some aspects, it is of crucial importance today even for the fulfillment of the fundamental needs. So, in some sense, even the force to fulfill fundamental needs affects software evolution today. Therefore, in the software field, we have the situation that has been observed in some other industries too (such as the automotive industry), and that is the emergence of the software technology and its incorporation in our lives has provoked the necessity for it. This has had effect that the number and type of participants that affect software evolution have increased over time, which has led to faster evolution and improvement of software technology. Since we have seen much of improvement in the field, and many new discoveries, we naturally wonder if all that is due to the heroic efforts of a few individuals or if it is due to something else. If the former, then we can conclude that evolution depends completely on these “heros” and that there are not so many things that we can gain by studying that evolution and applying the results that we have derived from these studies. Although some believe that innovation and evolution depend only on heroic individuals, it is not true. The evolution of technology in general, and software technology in particular, is not discontinuous. Continuity in discovery and technological evolution is one of the basic facts. These larger contributions, from especially talented and creative individuals, are only a small contribution to overall evolution of software technology. In fact, there is no single advance in technology that does not have a root in something already existing [2]. This is of crucial importance to our comparison of natural and software evolution, since evolution in the natural world is also continual, and all the results and observations about natural evolution are based on that fact. The prerequisite for continual evolution in the natural world is the existence of the genetic variation. An analogous prerequisite must exist in the technological world in order to have the continual evolution. Since all inventions are rooted in something already existing, the larger diversity should give us a greater chance of coming up with something new by combining different artifacts, finding inspiration in the artifacts from another field and similar. Also, the sophistication and complexity of the new technologies depends on the sophistication and maturity of the existing ones. Analyzing technological evolution in the Stone Age and comparing it with today, it is easy to conclude it. The same holds with the advances in software technology in its beginnings and today. Now, when we have the necessary preconditions for the comparison of natural and software evolution, how should we proceed? One must immediately ask how, and if it is possible to compare something in technological evolution with concepts of reproduction and massive extinction in natural evolution? How should we compare the evolution of something that is not controlled by anyone in particular in natural evolution to the evolution of something that is under control of human in the software evolution?
In this section we examine basic evolutionary mechanisms that exist in both, natural and software world. There are two kinds of these mechanisms: Mechanisms that increase variation in the population, and Mechanisms that decrease variation in the population.
3.2.1 Variation Increase In natural evolution, mechanisms that increase variation are mutation, recombination, and gene flow. Mutations are caused by mistakes that occur during DNA replication. The gene sequences are altered by these mistakes, giving the new characteristics to the being that carries it. These mutations can have positive and negative effects. Recombination is basically gene shuffling. It occurs during reproduction, when different combinations of alleles are formed. It occurs both between genes and within a gene. It contributes to the variation since these new alleles and their combinations are introduced into the gene pool. Gene flow is the mechanism that acts in such a way that genes from one population enter the gene pool of another. This occurs rarely between distant populations. Also, gene flow from one part of population to the other, which were separated for a long time so that changes were incorporated in both, contribute to the variation since it can produce new changes. If we want to make a parallel between these mechanisms and mechanisms that exist in software evolution, one cannot help but to remark upon the first difficulty: all three include reproduction. Almost all possible mechanisms that introduce variation in the software world are introduced by intentional human actions. So how do they relate? We take the stand that it does not matter at all. The important fact is that there exist the mechanisms that introduce change and variation in both. Who or what is the reason for this change and variation, and how they get incorporated into the population is not of great importance. The methodology and consequences stay the same as long as the whole process is the same. Even in the natural world, the reproduction ways are radically different and yet treated the same from the evolutionary point of view. Mechanisms that contribute to variation in software technology include: psychological factors, intellectual factors, social and cultural factors, economic factors, environmental forces, and product combinations. The first four are factors that drive humans to invent, which in turn leads to a greater variety of products. These are the general forces that drive invention [2]. Dreams, fantasies, and visions are the psychological factors that motivate invention. They are the primary driving forces, and without them progress would be much slower. There are numerous cases in software world where this is obvious. For example, the vision of a computer on every desktop, dreams about worlds led by robots, etc. Although psychological factors are not of primary and immediate interest in the study of
the software evolution, it is important to recognize their existence, and to give them credit for acting as a driving force. Knowledge and human intellect are also of crucial importance in the innovation process, and are therefore responsible for the variation. Although scientific knowledge was not of great importance for some types of technologies (technology is older than science [2]), in software it plays the primary role. The appearance of software technology is due to advances in scientific knowledge, which is also the factor that makes all improvements and innovations possible. It is therefore important to note the correlation between evolution in science with the evolution of software. There is a vast array of social and cultural factors that influence the variation and evolution of software. For example, if we study the evolution of computer viruses as a kind of software, we discover different social and cultural issues that have contributed to their appearance and spreading. It is one of the instances where relatively unsophisticated pieces of technology have appeared in socially unacceptable groups and affected the rest of society; viruses have brought out some negative sides of computer technology, provoking revolt in the other social groups. The open source software development community is another example where social and cultural phenomena have played a mojor role in the evolution of software systems [9]. Economic factors have been a driving force behind innovation and evolution since the very beginning of the software industry. For example, business competition stimulates innovation, which contributes to the amount of variation. Environmental factors are driven by the hardware technology used to support software. There are many ways in which this influences software evolution. For example, the emergence of the emulators as a software family has been directly driven by hardware technology. The difference in an operating system that is ported to different platforms is another example. Also, advances in hardware technology allow for new ideas to be applied; for example, faster processors and cheaper memory have catalyzed research in model checking and intelligent search engines. Product combination is a force that introduces variation. For example, integration of word processors, spreadsheets, etc. into the office suites, has invoked the appearance of the software used for these product bindings, collaborations, and synchronizations. This is the way that more complex systems are built from less complex ones. If one wants to make the parallel between natural and software evolution, one could argue about the similarity of mutation to the incorporation of new relatively original features into the product. Recombination could be treated similar to the product combinations and gene flow could be compared to the improvements due to the flow of knowledge or similar.
3.2.2 Variation Decrease The second group of evolution mechanisms, in natural evolution, consists of natural selection and genetic drift. Natural selection is the difference in reproductive capability. Some populations reproduce and evolve much faster than others. There are different positive and negative factors that contribute to this. What is common to all of them is the requirement for them to act is diversity in the population. Natural selection acts on an individual level; that is, individuals are somehow selected, and their genes propagate into the next generations of the population. There are different kinds of natural selection, such as sexual selection, environmental selection, etc. The important fact to remark is that natural selection may not lead towards “improvements” in the population; it works in order to improve the population in the short
term and not in the long term. Since the short-term conditions may be “false” ones (i.e., local greedy optimization or short-lived ones), the population can be badly adapted to what comes in the future. There is also the misconception that natural selection “pushes” the population into some more adapted state, but this is not true since selection operates only on the variation produced by mechanisms that we mentioned earlier. Genetic drift is the change in the frequency of alleles in the population. Usually these changes are due to chance. Also, fast drops in the population size contribute to the genetic drift. So, both natural selection and genetic drift decrease the variation in the population. The basic mechanism is evident; some mechanisms introduce variation and others select which variations will propagate and become a representative characteristic of that population. Since most of these variations and selection forces are random, it is not possible to expect that the population is moving towards some utopian ideal. The best chance for a population to improve is if there is an unlimited amount of variation supplied, and mechanisms that act upon that variation are severe and of the same kind that will be present in the future. Sudden changes in external forces that act as selection forces can lead to mass extinction in the natural world. Mass extinction does not seem to occur often in the context of technology [2] or software. Even so, we concede that it might have occurred in the past, but we consider it of no great importance since it seems to be infrequent and represents extreme behavior. In the software world, there are several groups of factors that selectively act upon variation: economic factors, military factors, social and cultural factors, environmental forces, and internal forces. Economic factors also act indirectly as a selection force. There are a number of cases when financial support was of critical importance for the future of some newly discovered technology. Marketing is also one aspect that contributes to the propagation of some kind of novelty. Economic factors work in the collaboration with all the other ones, and in some cases their presence is a necessity for others to act. For example, economic factors have recently led to the extinction of many dot-com initiatives. Although military factors are not usually of great importance for most software technology today, they were the primary ones responsible for its selection at the beginning of the software industry. Social and cultural factors are present in almost all selection processes. One example of how the social and cultural factors shape the evolution of technology is the attitude of followers of open source movement towards commercial technologies. The non-acceptance from their side of commercial technologies limits the propagation of those technologies and their evolution. Environmental forces perform selection both directly and indirectly. For example, if some software product needs a lot more processing power than is commonly available, it will not be used widely, which will directly affect its ability to spread. In the meantime, another superior technology may appear and when there is enough of processing power, the other one will evolve faster and be accepted more widely than the first one. As Lehman remarked, internal forces are rooted in the inherent complexity of software development [15, 16, 17]. These are the
Architecture
Quality Attributes
4.
ATTRIBUTES AND PATTERNS
Quality and functional attributes are descriptions of system’s qualities and functionality. Quality attributes are mainly achieved through the selection of an appropriate software architecture. The main relationships between the attributes and how they are achieved in the system are shown in Figure 1. As observed previously, the evolution of a system is very often different from the way we plan [4, 9]. Many forces act on the development of the system and we need to understand them in order to keep the development under the control. We are using the main groups of these forces to classify the quality attributes (Figure 2). The main purpose of this division is to identify the major conflicts among quality goals. This division is also useful for the evolution pattern categorization, as we will see later. Business goals are the primary driving force for the development of most systems. They are usually very high level goals, such as quick time to market, and they are achieved through project management and architecture goals. Project management goals include individual goals. These often contradict general management and architecture goals, and are often not taken into account by managers
ensured by
operationalized
Constraints
ensured by
influence
Functional Attributes
Operations
achieved by
Figure 1: Attribute Relationships
3.3 How to Proceed? How can one apply and profit from the study of selection factors? For example, studying different selection factors and how they have acted over time can help us estimate how they will act in the future. This can be useful if we have, for example, ten new features that we wish to incorporate into our software product. Suppose that every one of these features radically changes the architecture of the product. The estimate and knowledge about these different selection forces can help us estimate which one of these features we should include, that is, which one will allow the product to evolve more successfully. The knowledge about the factors that introduce new variations will help us estimate which other features we will be able to incorporate in the distant future. All this in turn helps us to design the system today so that it will be flexible enough to accommodate all these changes later. It is very hard to make the system open to all kinds of possible changes; it is much easier to concentrate and make it open to a “right” subgroup of these changes. The selection factors and their effects can be best studied and presented using attributes, since the attributes represent the essence of the software. In the next section, we present the basics of the attribute theory and attribute-based evolution patterns and stories as the format that makes it feasible to preserve and apply the knowledge about how attributes change, and the selection forces that act upon them.
influence
Quality Goals Non-System
Business
Project Management
System
Architecture
Design
Run-Time
Non-Run-Time
Figure 2: Quality Goals Classification and architects. Architecture goals are the high level system goals, which are often decomposed to and achieved through design goals. The general relationships among groups of goals are depicted in Figure 3.
by ust adj eved hi c a
Business Goals ac
hi adj eved ust by
Architecture Goals
inf
lue
nc
influence
forces that can slow down the evolution of a product. Some tasks are very hard to complete, and products that support them are very complex; this complexity slows down the evolution, and products that are more manageable are much more likely to evolve. So far we have considered mechanisms that act on one population or product family at a time; this is microevolution. The evolution that makes difference on the larger level that is the evolution that deals with questions how whole product families or populations appear and disappear is called macroevolution. We can again draw the parallel between natural and software evolution. The mechanisms that act at the software macroevolution level are the same as the ones at the microevolution level. One example of the macroevolution in software is the movement from assemblers to compilers. Different factors have acted and the compiler technology has advanced much more than the assembler technology. This can also be seen with the appearance of RDBMSs compared to the other forms of storage.
Project Management Goals
e
Design Goals e
nc
lue
inf
Figure 3: Main Goal Group Relationships One particular goal can exist in several groups simultaneously. The problem arises since that goal can have different priorities within different groups. Even different stakeholders that influence one goal group can give the goal a different priority, so the differences arise even within the group. For example, users and buyers have business goals, but users can emphasize usability over cost. These priorities change over time, and new goals emerge. This augments the size of an already existing problem — it is very hard to optimally support all goals and satisfy all stakeholders. One approach is to study common changes that have occurred in already existing product families. The crucial component that is needed for a successful attributebased analysis of system evolution is a detailed understanding of
the relationships and forces among sources of attributes, techniques used to achieve them, and selection forces that act upon them. It is hard to establish these relationships without a large amount of accumulated evolution knowledge. This knowledge is also needed to establish efficient recovery and application processes. Later in the paper, we present an initial recovery process. This process will be refined as more experience and practical evolution knowledge is accumulated. It is useful to make the distinction between evolutionary changes that are common to all software systems, and those that are peculiar to a particular product family. In our work, we are working with evolution stories to capture the evolution of a particular product, and evolution patterns [9] to capture changes common to many systems. Attribute-based evolution stories and attribute-based evolution patterns are their subsets that emphasize the changes in terms of attributes. The scope of stories is similar to the scope of reference architectures. It emphasizes the changes particular to a product family and has wider scope than patterns. The scope of patterns is similar to the scope of the architecture styles. Patterns capture common changes that occur in most systems. In our work, we are concentrating on three quality attribute groups: business, project management, and architecture. The focus of our current study is on documenting the evolution stories for several product families. We will use the results obtained for the stories to produce a set of the patterns observed. We use the following format for attribute-based stories and patterns:
Patterns are built by extracting commonalities from stories. The format will evolve and the attribute set will stabilize, as more and more existing systems are analyzed. In our approach, the first step in the reconstruction of the evolution of the product is to recover the architecture of the system. We use the Portable Bookshelf (PBS) tool [20] (Figure 4), to recover and visualize the architecture of the system. Product documentation is studied in order to recover the conceptual architecture of the system and gather the initial set of goals. Next, the architecture of all the product releases is recovered. The documentation is studied and, if possible, interviews are conducted in order to recover the intentional goal changes. Finally, the recovered architectures are analyzed in order to recover the actual goal evolution. For the last step, we use the intentional goal changes as the reference evolution model, and use concepts of Architecture Tradeoff Analysis Method (ATAM) and Attribute-Based Architectural Styles (ABAS) to recover from the extracted architectures which goals have actually been satisfied. Figure 5 summarizes the approach.
Product Name(s) and Characteristics Product Family and Characteristics Development Process — the characteristics of the development process used, number of developers, tools used, etc. Target Market — the product market including types of users, market characteristics, etc. Stakeholders and Attributes — the relationships among stakeholders and attributes. Architecture — an architecture description. Measurement Method — a listing of considered attributes, time intervals when observations are taken — most often a stable release, etc. Business Attributes — during every measurement, for every business attribute we capture which attributes support it, which attributes act as an obstacle, for which attributes it acts as an obstacle and which ones it supports. The priority of the attribute is estimated compared to the other attributes. The techniques for achieving that quality attribute are described. Graphs are often used to represent results. Project Management Attributes — discussion of project management attributes in similar format to above. Architecture Attributes — discussion of architecture attributes in similar format to above. Conflicts — the main conflicts that have occurred over time and their resolution. Selection Factors — the main selection factors and their effects through the lifetime of the product.
Figure 4: PBS: Architecture of Linux Operating System In the next two sections, we present an example of an attributebased evolution story, and an example where evolution knowledge fits within other disciplines. Then, we present a sample process for forecasting changes in product lines, and how it affects the product line architecture.
5. AN EXAMPLE: EVOLUTION OF LINUX SCSI DEVICE DRIVERS In this section, we present a sample attribute-based evolution story. Due to the space limitations, we present for every section only the most interesting part. We use an informal approach to present the pattern; the aim of our current study is not to write patterns in a form that can be used for different computations. We present a Linux SCSI Device Driver story, which is an instance of a general plug-in architecture pattern. We have analyzed 38 stable releases and 67 development releases of the subsystem — SCSI device drivers is the subsystem of the Linux device drivers subsystem. One of the interesting aspects of this evolution study is that one can consider the evolution both of the whole subsystem as monolith, and of device drivers as separate entities. The story is con-
Project Documentation
Source Code (for all releases)
– Device Manufacturer — high quality, quick time to market, low cost production (community production), low cost maintenance(community support) – Linux Developer — assurance, portability, reusability, performance , manufacturers support
Interviews & Domain Knowledge
– User — usability, reliability, performance , manufacturers support – Open Source Activist — high quality, user satisfaction
Conceptual Architecture and Goal Set Changes
Concrete Architecture Extraction (PBS)
Concrete Architecture (for all releases)
Recovery of Actual Goal Set Changes Evolution Patterns & Stories
Figure 5: Attribute Evolution Reconstruction Approach cerned with the evolution of device drivers separately, but it includes some information about the evolution of the whole subsystem, where relevant. Since its first official release, the SCSI subsystem has grown approximately tenfold in size. This is the indication of the increasing popularity of Linux that has resulted in more and more devices supported. This popularity is among the users of the system since in the stable release 2.2.16, 29 files out of 211 originated from the companies while Linux community developed the rest. The open source community maintains almost all the drivers. Such a small percentage, approximately 14%, indicates that Linux is still not so accepted by the industry and that there is still a long way to go before an average user can get all the support that she gets by buying commercial operating systems. The SCSI subsystem of release 2.2.16 consists of 80 low-level device drivers, 254,953 lines of code and 2,512 functions. The average size of the driver is approximately 3,000 lines of code; large, multi-card drivers have up to 15,000 lines of code. The latest release, 2.4.9, has 321,834 lines of code, which shows the steady increase in size. Name — Linux SCSI Device Drivers Product Family and Characteristics — Device driver; implements the interface imposed by the plug-in architecture of the system. Development Process — Open Source Development. Most of the developers are individuals volunteers; some development done by SCSI device manufacturers (14%). Target Market — Support for the users using Linux operating system. Stakeholders and Attributes — A simplified set of stakeholders with corresponding attributes:
Architecture — The Linux SCSI subsystem consists of three distinct layers: The Upper Layer is responsible for converting requests made to the SCSI subsystem and passing them through Middle Layer to the actual driver that executes commands. It has four subsystems depending on the type of the device. Disk subsystem is responsible for hard disks, CD-ROM subsystem is responsible for CD-ROMs, Tape for tape drives and Generic for other devices such as scanners. All the requests by the operating system to the devices go through this layer. The Middle Layer contains data structures and other functionality that provide as a connector between Upper Layer and Low Level Drivers. The Low Level Drivers are responsible for initialization and interaction with actual devices and execution of commands received from Middle Layer. The functions that a driver must implement are defined in Scsi Host Template interface. The main ones, which all drivers must implement, are: – int proc info (char , char , off t, int, int, int) – int detect (struct SHT ) – const char info (struct Scsi Host ) – int command (Scsi Cmnd ) – int queuecommand (Scsi Cmnd , void (done)(Scsi Cmnd )) – int abort (Scsi Cmnd ) – int reset (Scsi Cmnd , unsigned int) – int bios param (Disk , kdev t, int []) For example, queuecommand executes the command encoded in the Scsi Cmnd structure, but the system does not wait for it to finish. When the command is done, driver sends a message to the system. In addition to the main functions, a low-level driver may also have locally visible functions and data fields that provide support for main functionality and handle driver specifics (get command, show command, etc.). These functions are used exclusively at the low level since they are not part of the interface to the rest of the system. None of these functions should be used directly by the code outside of SCSI subsystem, instead they are invoked by the Upper Layer. The main architectural change that has occurred during the studied period is the incorporation of new error handling functions. Measurement Method — see “Stakeholders and Attributes” section and the discussion prior to the pattern.
Business Quality Attributes — As an example of business quality attributes we consider low cost production and maintenance. From the manufacturers perspective, in the beginning it was not profitable to develop and maintain Linux device drivers due to the small number of users. Over time, the Linux market has become more interesting to manufacturers because of increased number of users, so it became profitable to develop drivers. Some of the manufacturers still did not find it profitable to provide maintenance and support for these drivers. This change in priority of a business goal has provoked conflict with efficient use of resources goal, since many of open source developers developed separate drivers for products of that manufacturer previously. This change also causes conflicts with architectural goals such as reusability — a manufacturer would probably like to use product line concept for the development of all its drivers, while the existing drivers are developed separately by a separate programmers. One solution is to discard previously existing drivers, which further causes conflicts with other business and project management goals. Project Management Quality Attributes — example shown in previous and next sections Architecture Quality Attributes — As an example of architecture quality goal changes, we consider the assurance goal, which is partially achieved through fault tolerance. When 2.0.x development branch of Linux started, new error handling methods were introduced. The goal was for old drivers to switch to the new way of error handling, and for the new ones to be developed using it. This has provoked the conflicts with project management attributes, such as resistance to change, which has resulted in the fact that none of the drivers changed error handling routines until release 2.4. Conflicts — example conflicts discussed in previous sections Selection Factors — The quality of the device driver is directly responsible for the competitivity of Linux and related device in the respective markets.
6.
FORECASTING PRODUCT LINES
The estimation and prioritization of goals is especially difficult in the case of product lines. This difficulty arises from very essence of the product lines, that is, the fact that the core product line architecture is designed without knowing all the goals of the products it will support. Therefore, the problem is to forecast as closely as possible which qualities the core of the product line will have to support in the future. As with software evolution today, there is no structured methodology to study and base upon the forecasting of software technology. In other branches of technology, some work has been done, but it is still very far from the state that we can estimate with high precision on what and how technological advances will occur and be shaped. To be successful with some predictions, we must make them based on patterns that have occurred before. It is not possible to talk about general technological forecasting since every kind of technology has its own characteristics and distinct forces that shape it. We need a mature understanding of these forces in order to make the decisions. By being able to predict with more precision about what is coming, we will be able to improve all our existing development processes and activities, products will be more competitive on the market and more adaptable, decision making will be improved, etc.
A typical general technology forecasting methodology is Theory of Inventive Problem Solving (TRIZ) [18]. Altshuller started studying the process of the innovation, during the 1940s, by studying over 200,000 patents, how they have evolved throughout the time and concentrating especially on their innovation. A lot of people have continued the study, which have led to evolution patterns, forecasting techniques, and approach to innovation. These results and techniques have been gained from the analysis of more than 2,000,000 patents. The steps in the TRIZ technology forecasting are [7]: 1. Analysis of the evolution of the system. 2. Application of the Laws and Lines of the Technological Systems Evolution towards what the system is evolving. 3. Formulation of problems whose solution will lead us to the goal obtained in step two. 4. Solving of problems found in step three. As we can see, the study of the evolution is the first step towards complete understanding of the system, and its dynamics and environment, which give us the ability to make the estimates of how it will change in the future. These estimates are made by use of the laws mentioned in the second step. The Laws of Technological System Evolution are evolutionary patterns observed throughout the study of different technological systems and that repeat over and over. The Lines of the Technological System Evolution are specific descriptions of the stages of the system development. With a small number of modifications, the process can be applied to the forecasting of product lines. In the terms of the attribute-based evolution, product lines can be viewed as an architectural and management technique to satisfy a new set of business and project management goals. The difficulty of converting several existing products into a product line is simply due to the fact that these products are often built without consideration of the set of goals that are accomplished by the introduction of product line. The reconstruction of existing products and the formation of the product line is the process of identifying commonalities and variabilities among these products. The commonalities can be viewed as the set of common functional and quality attributes. These attributes are supposed to support the variabilities of all the existing products plus the envisioned ones. In the same way, product line goals have made the task of unifying the separate products into the product line difficult, the goals of envisioned product can be hard to achieve if not taken into the account during the initial product line construction. To reduce the difficulty of this problem, the following process can be used: 1. Represent every product as a set of functional and quality attributes. 2. Find the intersection of these sets. The architecture that supports these goals represents the core of the product line. 3. Use evolution patterns to estimate the conflicts that can arise from the need to support the future goals of the already existing products. 4. Refine the core architecture to accommodate possible future goals of already existing products. 5. Use evolution stories for products similar to envisioned products to estimate possible future conflicts. Also, use evolution
patterns to estimate possible future goals based on the already existing set of goals.
[10] D. Gross, and E. Yu. From Non-Functional Requirements to Design Through Patterns. http://www.hkkk.fi/ mrossi/refsq/f113.pdf [11] R. Kazman, M. Klein, and P. Clements. ATAM: Method for Architecture Evaluation. CMU/SEI-2000-TR-004. [12] C. F. Kemerer and S. Slaughter. An empirical approach to studying software evolution. IEEE Trans. on Software Engineering, 25(4), (July/August 1999). [13] M. H. Klein, R. Kazman, L. Bass, J. Carriere, M. Barbacci, and H. Lipson. Attribute-Based Architecture Styles. Proceedings of the First Working IFIP Conference on Software Architecture (WICSA1), San Antonio, TX, 225-243, (February 1999). [14] A. van Lamsweerde, and E. Letier. Handling Obstacles in Goal-Oriented Requirements Engineering. IEEE Transactions on Software Engineering, Vol. 26, No. 10, (October 2000). [15] M. M. Lehman and L. A. Belady. Program Evolution: Processes of Software Change. Academic Press, 1985. [16] M. M. Lehman, D. E. Perry, and J. F. Ramil. Implications of evolution metrics on software maintenance Proc. of the 1998 Intl. Conf. on Software Maintenance (ICSM98), Bethesda, Maryland, (November 1998). [17] M. M. Lehman, J. F. Ramil, P. D. Wernick, D. E. Perry, and W. M. Turski. Metrics and laws of software evolution - the nineties view. Proc. of the Fourth Intl. Software Metrics Symposium (Metrics97), Albuquerque, NM, 1997. [18] G. Mazur. Theory of Inventive Problem Solving (TRIZ). http://wwwpersonal.engin.umich.edu/ gmazur/triz/index.htm . [19] J. Mylopoulos, L. Cheung, and E. Yu. From Object-Oriented to Goal-Oriented Requirements Analysis. Communications of ACM, Vol. 42, No. 1, (January 1999). [20] PBS: The Portable Bookshelf. http://swag.uwaterloo.ca/pbs/ .
6. Decide if it is feasible to support envisioned goals using the proposed product line, and if it is, then refactor the architecture of the common assets to form the core of the product line and to optimize the common attributes. The core idea of the process lies in the optimization of commonalities that are expressed in terms of functional and quality attributes, and in the estimation of future quality attributes. Evolution stories and patterns are basic tools to perform such analysis — they provide codified knowledge based on which one can forecast which goals will have to be supported by the core product line architecture.
7.
CONCLUSION
We have presented core concepts of attribute-based evolution research that is currently in progress. The emphasis of the paper was on the presentation of the similarity of attribute-based software evolution and evolution in other disciplines, and the practical use of patterns. We consider that attribute-based evolution has the potential of contributing to and improving several state-of-the-art methodologies. It is particulary useful in the area of reconstruction, construction, and forecasting of product lines. We are currently analyzing the evolution of Linux operating system.
8.
FUTURE WORK
Future research directions include attribute-based evolution recovery of several systems, development of a more efficient process and tools in order to automatize evolution recovery, and the tighter integration of the developed theory with other attribute-based techniques. We will also use stories and patterns to analyze appropriateness of decisions for several already existing product lines.
9.
REFERENCES
[1] F. Bachmann, L. Bass, G. Chastek, P. Donohoe, and F. Peruzzi. The Architecture Based Design Method. CMU/SEI-2000-TR-001. [2] G. Basalla. The Evolution of Technology. Cambridge University Press, (1988). [3] B. Boehm, and H. In. Identifying Quality-Requirement Conflicts. IEEE Software, Vol. 13, No. 2, (March 1996). [4] I. T. Bowman, R. C. Holt, and N. V. Brewster. Linux as a Case Study: Its Extracted Software Architecture. ICSE ’99: International Conference on Software Engineering, Los Angeles,California, (May 1999). [5] C. Colby. Introduction to Evolutionary Biology. http://www.talkorigins.org/faqs/faq-intro-to-biology.html [6] T. Dobzhansky. Nothing in Biology Makes Sense Except in the Light of Evolution The American Biology Teacher, Vol. 35, 125-129, (March 1973) [7] V. R. Fey, R. I. Eugene. Guided Technology Evolution. http://www.trizgroup.com/article2.html [8] H. Gall, M. Jazayeri, R. Kloesch, and G. Trausmuth. Software evolution observations based on product release history. Proc. of the 1997 Intl. Conf. on Software Maintenance (ICSM97), Bari, Italy, (October 1997). [9] M. W. Godfrey, and Q. Tu. Evolution in Open Source Software: A Case Study. Proc. of the 2000 Intl. Conference on Software Maintenance, San Jose, California, (October 2000).
