Jan 13, 1998 - University of Technology, Sydney. ... evolutionary software development: development and ..... franchised company and get their local office).
Submission type:
Original Research [Word count approx. 5800 words]
Title:
Defining systems evolvability - a taxonomy of change
Authors:
David Rowe, John Leaney, David Lowe Computer Systems Engineering Group Faculty of Engineering, University of Technology, Sydney. AUSTRALIA
Postal Address:
Computer Systems Engineering Group Faculty of Engineering University of Technology PO Box 123 Broadway, 2007 AUSTRALIA
Email:
{drowe | jrleaney | dbl}@eng.uts.edu.au
Phone:
D. Rowe J. Leaney D. Lowe
Fax:
61-2-9514-2435
Designated Contact: David Rowe
61-2-9514-2496 61-2-9514-2389 61-2-9514-2526
Defining systems architecture evolvability - a taxonomy of change David Rowe, John Leaney, David Lowe Computer Systems Engineering Group Faculty of Engineering University of Technology, Sydney [drowe | jrleaney | dbl]@eng.uts.edu.au
evolution, while evolution in regard to computer based systems (CBSs) is less well defined. The few definitions that do exist [###CITE?] range broadly in their focus, choice of words, and overall observed effect of evolution on a system. It is also obvious that each definition reflects quite clearly a specific perspective and domain of application. Despite this lack of consistent definition, the one all embracing concept regarding a system’s ability to evolve is reflected in its ability to change or to accommodate change. Change, and accommodating change, in CBSs is more an issue now than ever before. As the size, complexity and cost of systems grow to meet increasing demands, there is an expectation that these systems will be longer lived. However throughout the lifespan of a system, especially one which has a long lifetime, technologies, operating environments and user’s needs all change. A major goal is therefore to develop evolvable systems which can accommodate these changes. An evolvable system can result in decreased development risk, increased system lifespan and lower maintenance costs - huge financial benefits considering the high deployment, maintenance and replacement costs typical of most CBSs. We achieve these gains by explicitly building evolvability into systems. It is contended that satisfaction of evolvability, as a requirement of a system to be built, is best addressed during development of that system’s architecture. The architectural model best allows modelling and proof of satisfaction of high level functional and performance requirements [rech91, lean93, rowe96]. An architecture capable of accommodating change must be specifically designed for change [isaa94]. In developing an evolvable architecture, one may trade off between accommodating likely changes in the current architecture, providing facilities for the incorporation of implementation options that will rise to meet anticipated long term demands, or designing an architecture which can be modified in order to accommodate change elegantly (avoiding the perils of architectural drift and erosion [broo75, wolf92]). Each of these approaches call for a different philosophy of design, have a different
Abstract Evolvability is part of the alchemy of systems engineering. Designing a system that is evolvable is considered best practice in many industry domains. However, what does ‘evolvable’ mean? And in what context does a system evolve? Reviewing the many factors of system change and their associated definitions, we conclude that a single definition for ‘evolvability’ is not adequate. We assert that evolvability is a composite quality which allows a system’s architecture to accommodate change in a cost effective manner while maintaining the integrity of the architecture. In order to define evolvability as a composite, we propose a taxonomy which classifies the different aspects of evolvability. Using this taxonomy to select relevant systems architecting and design approaches, a systems architect can be confident in including those aspects of evolution most suitable to a particular application. The concepts introduced in this paper are applied to the Ericsson AXE telecommunications switching system for illustration and justification.
1. Introduction Evolution is a word most commonly associated with the concept of incremental change of an entity over time. The goals of a change process are rarely similar for any two entities, depending largely on the nature of the thing. This is well displayed in such expressions as: • man evolving from ape: genetic advancement of a species. • evolutionary software development: development and refinement of software systems over a period of time. • system evolvability: the ability of a system to adapt in response to changes in its environment, requirements and implementation technologies [rowe97]. Evolvability as a concept has its deepest roots in the biological and social sciences. These fields of study have established working (though controversial) definitions of
1
13-Jan-98
Continuing change is intrinsic to the nature of CBS’s. Accordingly the focus in systems development should not be exclusively on reducing the likelihood of change (such as systems maintenance and enhancements) but reducing the unit cost of change (both initially and as the system grows) [lehm80]. Reducing the cost of making ongoing changes may be facilitated by current maintenance practices which include automatic code generation from formal specification, tools for understanding large system and tools for performing impact assessment. These practices may help the effort of change, but they do not alleviate the problems of a system (or software) architecture unsympathetic to change. Essentially we need to develop systems which actively address the need for change - evolvable systems.
initial cost, and have significant consequences on the initial architecture. System architects must understand the nature of change, and the ways that change can be accommodated within the architecture they design. At present, current definition or discussions of CBS’s change and evolution fail to make these aspects of change explicit. In addressing the need to better understand the nature of systems evolution, this paper presents evolvability as a taxonomy of change1. Each category in the taxonomy is a distinct aspect of systems evolution. We assert that evolvability is a composite quality which allows a system’s architecture to accommodate change in a cost effective manner while maintaining the integrity of the architecture. Thus, the taxonomy presented provides a means of explicitly describing the different architectural factors that contribute to accommodating change. To illustrate and defend the taxonomy, we apply it to the Ericsson AXE telecommunications switching system. The AXE is a widely used switching system (in Europe and Australia) and has been heralded as one of the most evolvable CBS architectures developed [fob96].
2.2 Developing evolvable systems A system that is required to change must be designed for change [isaa94]. In designing for change, we recognise the need for a combination of engineering and evolutionary considerations which will provide an architecture capable of meeting current demands while also providing means of accommodating likely changes throughout its lifespan. Systems change and evolvability is most effectively addressed at the architectural level because the architecture defines the relations between components and their interfaces. Modifying an architecture can have wide spread effects on both system functionality and performance. Furthermore, the effect of change in a system’s architecture can form the biggest factor of cost in system change [horo91]. Studies have shown that when the architecture of a system is not maintained (i.e. architectural erosion), the system becomes difficult to modify (resulting in a ‘brittle’ architecture) [wolf92] increasing the cost of change. The key to evolvability is the ability to make changes in a cost effective manner [isaa94], while maintaining the system’s original architectural philosophy [broo75]. The above points would indicate that if we are to consider how a system architecture can be developed to accommodate change, then we need to consider how the requirements may change. We begin this by looking at change in biological systems, as this is a field traditionally associated with the concept of evolution.
2. A review of change and evolution In this section we consider the need for CBSs to be able to evolve and accommodate change. We show that various sources and definitions of change and evolution exist and consider their suitability for describing CBS change and evolution.
2.1 The need for evolvability in CBSs Computer Based Systems typically are required to change over time in response to changes in their environment. According to the standing definitions, a system is affected by change in a number of areas: stakeholder’s requirements (both functional and performance requirements); operating environment; and implementation technology. All of these are types of requirements, and can be represented as such. ∆Environment ∆Technology
∆Req's
∆System Solution
∆Stakeholder’s Needs
The resultant changes in a system solution, as it accommodates changes in requirements, is often described as the evolution of a system. Horowitz [horo91] has demonstrated that accommodating these change accounts for a major component of system maintenance costs. 1
2.3 Biological change and evolution The term ‘evolution’ is prone to controversy amongst biologists. Douglas J. Futuyma, one of the most respected evolutionary biologists, defines evolution as follows: “In the broadest sense, evolution is merely change, and so is all-pervasive; galaxies, languages, and political systems all evolve.
A taxonomy is a classification of things according to their relations or laws.
Submitted ECBS’98
2
13-Jan-98
Biological evolution... is change in the properties of populations of organisms that transcend the lifetime of a single individual. The ontogeny of an individual is not considered evolution; individual organisms do not evolve.” [futu86] We agree wholeheartedly with the first point in Futuyma’s definition of evolution, but must consider the other implications of this view in respect to CBSs. Although there are parallels between biological systems and CBSs, there are also differences, especially in the way in which they change. Firstly, CBSs are typically large, one-off systems, rather than a member of a relatively homogeneous population. The focus of evolution for CBSs is change and adaptation of an individual system over its lifespan (i.e. within a single generation), rather than change of a population over many generations. Since Darwin, biologists have progressively elaborated a reasonable though incomplete picture of the mechanism that drives evolution in the natural world, namely natural selection. The theory of natural selection rests on a view of evolution as a tinkerer which cobbles together ad hoc (but often remarkable) solutions to design problems [kauff90]. Successive cullings then accumulate useful variations. This view is also not applicable to CBSs. Evolution of a CBS is driven by specific ‘misfits’ between the system and its environment, and the changes in a system must be in a direction that results in resolution of the misfits [alex64]. This ensures that the system continually meets its operational objectives. The analogy between the evolution of organic forms and the evolution of systems is further argued to be inappropriate in other literature [dasg91, jaco77].
to changes in the systems requirements and environment [lehm80]. Swanson, also a pioneer in maintenance study, coined the terms corrective, adaptive and perfective maintenance [swan76]. Further, we present two well respected definitions for the system quality associated with maintenance: maintainability: 1) The ease with which a hardware system or component can be retained in, or restored to, a state in which it can perform its required functions [ieee90]. 2) The ability of an item to be retained in or restored to a specified condition when maintenance is performed [nist94]. When considering the difference between maintenance and evolution, it is important to distinguish between retaining the system in a state in which it can perform its required functions, and accommodating changes in requirements not previously specified. The following figure aims to illustrate the separation of concepts between maintaining a system and changing a system. MAINTENANCE STABLE REQT’s correcting
perfecting
CHANGING REQT’s adapting extending
Figure 1: Maintenance and change
Changing (adapting or extending) a system is currently recognised as a significant portion of maintenance activities [horo91], and it this aspect of maintenance that should be explicitly addressed when considering evolvability in a system.
2.4 CBS change and evolution If biological definitions of change are not appropriate, then we need to consider alternatives. Many terms and definitions exist for concepts related to system change. These tend to focus not on systems evolution or evolvability, but rather on concepts related to specific forms of change such as maintainability, flexibility, adaptability and extensibility (to name a few). These terms however are still ill-defined. In considering these terms we first look at maintenance, as the first studies of system change came from maintenance data [lehm76].
2.4.2 Current definitions of change in CBSs In CBS literature, many terms refer to a system’s ability to accommodate change. It is worth visiting these existing terms as the first step towards establishing a taxonomy is to understand existing terms and definitions: • adaptability: 1) the ease with which a system or component can be modified for use in applications or environments other than those for which it was specifically designed. Also known as flexibility. [ieee90] 2) the ability to modify or add modules without having to modify other components or their integration solution [mowb95]. • changeability: 1) the ability to meet changing situations and diversified operations with minimum disruption or delay [mcca96]. 2) the ease with which changes may be incorporated into artifacts [dasg91]
2.4.1 System change and system maintenance Once a system is released, the maintenance process begins. Belady and Lehmann studied the IBM/360 operating system and concluded that for large software systems the term maintenance refers to all changes after release, which can be split up into: repairs - fixes in code, design and arch; improvements - increase in performance, useability, maintainability etc.; and adaption - responding
3
13-Jan-98
• flexibility: 1) the ability to meet changing situations and diversified operations with minimum disruption or delay [mcca96]. 2) the ability to provide different arrangements of system modules in order to suite a number of applications [eric95]. • extensibility: 1) The capability of being extended resulting in easier, faster, and less costly upgrade in capability [bens95]. 2) The expansion of (robot) architectural capabilities in regards to number of sensors, or micro-processors in order to carry an increased load [broo86]. 3) the characteristic of an architecture to support unforeseen uses and adapt to new requirements [mowb95] • enhanceability: 1) the ease with which new functionality can be added to a system [dasg91]. Though this list of change based qualities is not exhaustive, it is significant enough to demonstrate that the major means of accommodating requirements change is by modifying the existing system via either adaption or extension. Other definitions are discounted because they do not define how the term (such as changeability) is achieved in relation to the system and its components - at best they stipulate the broad requirements of the term. We now look towards existing definitions of evolvability.
While all the definitions presented agree that accommodation of change is important to the quality of evolvability, a number of questions arise. Firstly, what is the stimulus for the changes that must be accommodated (environment, user needs or technology)? At what level of system abstraction should the quality of evolvability be addressed (architecture, system or subsystem)? And thirdly (in reference to the last set of definitions) while scalability and generality explicitly state how change is accommodated, what makes evolvability significantly different when it does not? We shall address these questions in the following section.
3. Evolvability: a taxonomy of change There are a number of ways that a system can adapt to changes in its requirements. We propose that the best form of evolution is one that does not change a system’s architecture - here change is accommodated within the current design. If change can’t be met by the current design, the next best scenario is assimilation - changing the systems design within the bounds of the architecture (either adding designed for components or upgrading existing components) in order to meet new demands. Finally, if this cannot meet the needs of changing requirements, the system’s architecture must be modified in order to satisfy new constraints, but still maintain the architectural integrity.
2.4.3 Existing definitions of evolvability in CBSs We have previously published the following working definition of evolvability: Evolvability: the ability of a system to adapt to, or cope with change in requirements, environment and implementation technologies [rowe97]. Other definitions include:
3.1 A taxonomy of change We propose that evolvability (at a high level) be simply “a system’s ability to accept change”. However we have shown that change can take numerous forms. It is therefore appropriate to develop a taxonomy of change which then defines evolvability. Construction of such taxonomies is common in the analysis of software systems ([hine95], [kitch96]) as it aids in the understanding of how quality characteristics relate to each other, and which factors contribute to those qualities. We would also like to refer to the work on quality attribute models, particularly IEEE standard 1061 [ieee93]. Utilising the framework of a quality attributes model, we can identify categories of change, and hence architectural qualities which address these categories. These qualities, which contribute to evolvability as an overall system quality, can in turn form the taxonomy of change. Table 1 lists and defines the terms of the taxonomy. Factor Description
• System evolvability is a trait of a system that allows the system to be easily modified due to changes in the environment [perc94]. • Evolvability is the degree of changeability required to meet new user or client needs, and may be adapted to new, unanticipated missions, while preserving the integrity of the original architecture [hill97]. In discussing the importance of a system’s ability to accommodate change, Isaacs and McConaughy [isaa94] list the following three important architectural attributes (of which evolvability is one): • scalability: accommodating change by incremental changes in system capability. • generality: accommodating change within existing design or implementation. • evolvability: accommodating change in requirements and implementation technologies throughout development and operation.
Submitted ECBS’98
Generality
4
Accommodating change within existing architectural design and implementation.
13-Jan-98
Adaptability
Accommodating change through exchange of system components within current architecture without having to modify other components or their integration solution.
Scalability
Accommodating change via incremental changes in system capability by inclusion of components that have been planned for and included in architectural design.
Extensibility
Accommodating the need for extra functionality or new system properties through major architectural change.
3.2.2 Reducing the cost of change The taxonomy presented indicates the methods of accommodating change, and it is up to the architect to design a system that achieves the correct balance of each method in order to develop a system that is most cost effective for both anticipated and unexpected change. As stated, generality is the easiest way to accommodate change. This requires over-designing the system for immediate purposes by building in capabilities that will satisfy future scenarios. A drawback of this method is the extra cost incurred in ‘covering all bases’. Another drawback is the possibility that a general architecture may not be evolvable in terms of changing to cope with requirements outside it’s architectural state space. In solving the problem of cost, it would be best to optimise the system solution such that it fits the anticipated evolution path (as illustrated in Figure 5). Considering the changes a system is likely to encounter is a critical step in the development of its architecture [hark92], but designing for unanticipated change is also critical.
Table 1: A taxonomy of change
From this we can now state a refined definition of evolvability. Evolvability: An attribute that bears on the ability of a system to accommodate change in its requirements throughout the system’s lifespan with the least possible cost while maintaining architectural integrity. Creating an evolvable system requires use of best practice to deliver a system which will accommodate change at the minimum cost by incorporating each of the aspects of change in the most feasible manner (this is discussed further in the next section). Maintaining an evolvable system requires consideration of previous architectural decisions, and adherence to the original architectural style (or philosophy). Changes to the system should be made such that architectural integrity is not compromised, and systems evolvability maintained.
Figure 3: Implications of the taxonomy.
Beyond generality, change may be designed for via adaptability (allowing the exchange of hardware components and/or their controlling software as the hardware evolves) or scalability (architecture able to accommodate the integration of additional, planned for components). In order to facilitate extensibility, and make an architecture change more easily under unforeseen circumstances, engineering practice calls for well defined interfaces, use of standards, utilisation of ‘information hiding’ [parn85] and designing around islands of architectural ‘stability’ [kauff90]. While many of these design guides may be applicable to adaptability and scalability, it is the stringency of their application which allows extensibility.
3.2 Implications of the taxonomy Within limited space, we would like to highlight design practices that incorporate the taxonomy during system development. Table 2 illustrates and describes the taxonomy in terms of an example architecture and its architectural state space. 3.2.1 Architectural state space In a previous paper [rowe97] we have considered the capabilities of a system’s architecture in terms of its ontological state space. These diagrams are also useful in illustrating concepts associated with the taxonomy. Referring to Figure 5, Architecture A is illustrated as an architectural state space - the possible systems which are consistent with the architecture. The trajectory in field A represents the changes in system properties over time. The axes are architectural properties which reflect key system requirements.
Submitted ECBS’98
4. Investigating the AXE switch This section examines the evolvability aspects of the Ericsson AXE telecommunications switching system. The AXE is heralded as one of the most successful switching systems ever designed. Its success has been largely due to an ability to accommodate the fast paced changes typical of the telecommunications domain. Designed in the early 1970’s as a ‘set’ of architectures -
5
13-Jan-98
embodying the ‘system-of-systems’approach - the AXE has proved to be one of the most long lived systems today (25 Basic architectural view (CCC) G E N E R A L I T Y
A D A P T A B I L I T Y S C A L A B I L I T Y
E X T E N S I B I L I T Y
years to the current AXE 10 switch). The AXE is anticipated to be in service for another 15 years.
Description
Architectural state space view
Figure 4 illustrates a basic Dominant Feature: Any change capability is architecture represented as internal to a component or the architecture design. components and connections. Effect on Architecture: No change to topology. No change to the architectural state space. Comments on Figure 5: If a system’s requirements change maps to the indicated path, then Architecture A is the most general. Intuitively, A is more general than B as it covers a greater area in the architectural space.
Figure 4: A basic architecture.
Design Guide: Perform requirements forecasting [hark92] and design for anticipated change, etc.
For example:
Figure 5: Generality
Dominant Feature: Interchange of components. Effect on Architecture: No change to topology. Increase in the system’s architectural space. Comments on Figure 7: If a systems requirement change maps to the path in , then the area B’ represents the extra architectural space introduced by the new component.
Figure 6: Interchange of components
Design Guide: Well defined interfaces, layering, use of standards, modularity [parn72], i‘nformation hiding’[parn85], etc. Dominant Feature: components.
Increase
in
number
of
Effect on Architecture: Topology may change, though the essential architecture remains unchanged. Increase in the system’s architectural space. Comment on Arch. state space: See next cell. Design Guide: Requirements forecasting, modularity, generality at component interfaces, generality in the architectural design, use of standards [kowa97], etc.
Figure 8: Increase components
Figure 7: Adaptability Architectural state space consequences are similar to those shown in Figure 7 above. Addition of components to the architecture increase that system’s capability in the desired properties, which results in an increase in architectural state space as long as the essential architecture can handle the extra demands.
Dominant Feature: Suitable components retained, others changed, others added. Additional connections made.
For example:
Effect on Architecture: Major change to the essential system architecture’s topology. Major change to the architectural space (new dimension).
Figure 9: Critical change of structure
Comments on Figure 10: Major change in the architecture resulting in a qualitative change (a new property). If system requirements map to the indicated path, then a 3-space represents the extra architectural dimension introduced by the change. Design Guide: Modularity, use of standards, designing around islands of architectural s‘ tability’ [kauff90], etc.
Figure 10: Extensibility
Table 2: Implications and illustration of the taxonomy of change
6
13-Jan-98
CP-A
CP-B
architectural components e.g. development of a mobile telephony switching subsystem (APT MTS). • Adapting to increased demands - Customers can start with an APZ 211 11 central processor (CP) of small to medium capacity and “grow into” a larger capacity CP (APZ 212 11) which is about three times more powerful. CP’s are target-code and regional processor bus (RPB) compatible which enables the customer to retain other initial software and hardware investments.
AP
RP Bus
RP
RP
APT H/W Devices
SP
SP
I/O Devices
CP - Central Processor RP - Regional Processor SP - Support Processor AP - Application Processor
4.3 Scalability
Figure 12: AXE processor system structure [eric95]
• Scalable system capacity - One component’s generality often contributes to system scalability e.g. the APZ 211 11 handles a maximum of 512 regional processors (RP’s). To increase the capacity of the exchange, extra RP’s can be purchased and installed in turn. Scalability also depends on the hierarchy of components e.g. a time switch is extended in steps of 512 ports, which is the capacity of one time switch module (TSM). • Scalable systems services - Extra services/lines can be bought and installed provided it is within the capacity of the existing system blocks. E.g. a subscriber switch is built from up to 16 Line Switch Modules (LSM), each of which has a capacity of 128 analog accesses, 64 basic ISDN accesses (2B+D), or 4 primary ISDN accesses (30B+D).
The success of the AXE design is largely attributed to a philosophy of modularity, which is an accepted key to continuous systems development and fundamental to achieving an open ended, “future-proof” system. Modularity is evident at all layers of design and implementation including architecture, software and hardware. Other “best practice”design principles evident in the AXE include well defined interfaces, use of industry standards for external (line) interfaces, use of locality principles (allowing a manageable balance between distributed and local functionality between components). Regarding the taxonomy presented, the following aspects of evolvability are evident in the latest generation of the AXE [eric95]:
4.4 Extensibility • Growing to meet new demands - The AXE switch utilises its modular structure and implementation in order to allow new components and services to be added easily. For example, in Australia, the AXE was initially unable to meet the processing demands of a new service associated with 131 numbers (which allow a caller to dial a common number for a nationally distributed or franchised company and get their local office). The amount of processing required for this service was beyond the scope of the AXE, so the database queries and relevant number supply mechanism was offloaded to an application processor (AP) that was integrated onto the RP Bus (as illustrated in Figure 11). This was possible due to factors such as the inherent modularity, the strict use of standards, etc., resulting in the AXE’s ability to change elegantly. More services are now offloaded to the APs (including 1-800 numbers) which allows the CPs to do their original job, and the AXE to grow further into its future requirements.
4.1 Generality • Generality in components - inherent production capacity of most components provide facilities for a set number of lines, processor capacity, etc. For example, a time switch module in the APT has capacity for 512 ports; the APZ 211 11 central processor is a 32 bit processor designed to handle small to medium sized applications thus having the capability to accommodate medium to long term growth of a small exchange. • Generality in services - AXE provides a number of services that go beyond the basic services required by a PSTN subscriber (including call forward, call waiting and (malicious) call identification). These services are often paid for by the subscribers, and can be activated from the AXE switch when requested at no real cost to the telecommunications company.
4.2 Adaptability • Adapting to new functional needs - High modularity and a standard block decomposition allows adaption to new technology without redesign (or with minimum redesign). Facilitated via change or upgrade of
Submitted ECBS’98
5. Conclusions Evolvability is part of the alchemy of systems engineering. We have attempted to further differentiate the biological and systems definitions of evolvability. We
7
13-Jan-98
[ieee93]
IEEE 1061, I“EEE Standard for a Software Quality Metrics Methodology”, IEEE Computer Society, March 1993 [isaa94] Isaac, D., McConaughy, G., T “ he Role of Architecture and Evolutionary Development in Accommodating Change”, Proc. NCOSE’94, pp. 541-545. [jaco77] Jacob, F., E “ volution and Tinkering”, Volume 196, Number 4295, June, 1977, pp. 1161-1166 [kauf90] Kauffman, S.A., R “ equirements for evolvability in complex systems: orderly dynamics and frozen components”, Physics D, volume 42, number 1, pages 135-152, June, 1990 [kitch96] Kitchenham, B., and Pfleeger, S.L., S “ oftware quality: The elusive target”, IEEE Software, January 1996, pages 12-21 [lean93] Leaney, J.R., Drane, C.R., A “ rchitects and the Architecture Phase in the Software Engineering Lifecycle”, Proc. ASWEC’93, 1993 [lehm76] Lehman, M.M., Belady, L.A., A “ model of large program development”, IBM Systems Journal, Vol. 15, No. 3, 1976, pp. 225-251. [lehm80] Lehmann, M.M., P “ rogram, Life Cycles, and Laws of Software Evolution”, IEEE Transactions on Software Engineering, Vol. 68, No. 9, 1980, pp. 1060-1076. [mcca96] McCay, B.M., S “ ome Thoughts on the Quality of a Computer-Based System’s Architecture”, Proc. ECBS’96, pp. 228 - 234 [mowb94] Mowbray, T.J., Zahavi, R., T “ he essential CORBA : systems integration using distributed objects”, John Wiley and Sons, 1994 [nist94] G “ uide on Open System Environment (OSE) Procurements”, NIST Special Publ. 500-220 by Mr G. Fisher, Systems and Software Technology Division, Computer Systems Laboratory, NIST, May 1994. [parn72] Parnas, D.L., O “ n the Criteria to be Used in Decomposing Systems into Modules”, CACM, Vol 15, Number 12, December 1972 [parn85] Parnas, D.L., Clements, P.C., "The modular structure of complex systems", IEEE Trans. on Soft. Eng. Vol SE-11 Number 3, March 1985 , pp 259-266 [perc94] Percivall, G.S., S “ ystem Architecture for Evolutionary System Development”, Proc. NCOSE’94, pp [perr94] Perry, D.E., D “ imensions of Software Evolution”, International Conference on Software Maintenance, 1994, Victoria, Canada, pp. 296-302 [rech91] Rechtin, E., S “ ystems Architecting : creating and building complex systems”, Prentice Hall, 1991 [rowe96] Rowe, D., Leaney, J.R., Lowe, D., D “ evelopment of a Systems Architecting Process for Computer Based Systems”, Proc. ICECCS’96, Montreal Canada, 1996 [rowe97] Rowe, D., Leaney, J.R., E “ valuating evolvability of computer based systems architectures - an ontological approach”, Proc. International Conference on the Engineering of Computer Based Systems, 1997. Available on http://www.ee.uts.edu.au/~drowe/ publications/ecbs97/ecbs97.htm [swan76] Swanson, E.B., discussed in Pressman, R.S., S “ oftware Engineering: A practitioners approach”, 3rd Ed., McGraw-Hill, 1992
have argued that accommodating change is the basis of systems evolution. We conclude that evolvability is a composite quality which allows a system’s architecture to accommodate change in a cost effective manner while maintaining the integrity of the original architecture. The taxonomy presented clarifies and explicitly defines the aspects of accommodating system change, therefore augmenting the definition of systems evolvability. We further conclude that this taxonomy is a scientific step towards understanding systems evolution.
6. Acknowledgments This work was funded partly by ATERB (Australian Telecommunications and Electronics Research Board) and APA scholarships. The authors would like to thank Prof. Fergus O’Brien (Software Engineering Research Centre) for ideas and discussions on topics presented in this paper.
7. Bibliography [alex64] [bens95]
[broo75] [broo86]
[dasg91]
[eric95] [fob96]
[futu86] [hill97]
[hine95]
[horo91]
[ieee90]
Alexander, C., N “ otes on the Synthesis of Form”, Cambridge, MA, Harvard University Press, 1964. Bensley, E., et al, "Evolvable Real-Time C3 Systems, Proc. 1995 IEEE Complex Systems Conference, pp. 151-166, Nov 1995 Brooks, F.P., T “ he Mythical Man-month”, AddisonWesley, 1975 Brooks, R.A., A “ Robust Layered Control Systems For a Mobile Robot”, IEEE Journal of Robotics and Automation, Vol. RA-2, No. 1, March 1986 Dasgupta, Subrata, D “ esign theory and computer science : processes and methodology of computer systems design”, Cambridge University Press, 1991 AXE System description, Ericsson report LZT 101 1858-R1, 1995 F. Obrien, D “ esigning Systems for Future Chaos”, Internal report SERC-0024, Software Engineering Research Centre, Carlton University, Australia Futuyma, D.J, E “ volutionary Biology”, Sinauer Associates, 1986 Hilliard, R.F., Kurland, M.J., Litvintchouk, S.D., “MITRE’s Architecture Quality Assessment”, (To appear) 1997 Software Engineering and Economics Conference Hines, M.L., Goerner, A.A., S “ oftware quality: attributes and modalities.”, Software Quality Management III, UK: Comput. Mech. Publications, Southampton, 1995. p.137-46 vol.2 of 2 Horowitz, B.M., "The Importance of Architecture in DOD Software", The MITRE Corporation, Report M91-35, July 1991. IEEE 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology, 1990
Submitted ECBS’98
8
13-Jan-98
[wolf92] Engineering Notes, 17:4, pp40-52, Oct 1992
Submitted ECBS’98
9
13-Jan-98
