| Oreizy, P., Medvidovic, N., and Taylor, R.: "Architecture-Based Runtime Software Evolution," Proceedings of the 20 th International Conference on Software Engineering (ICSE), Kyoto, Japan, 1998, pp.177-186. |
....of Concerns and AOP. Although CBSE provides viable techniques to develop modularized software systems, the components are often designed and implemented from scratch rather than reengineering them from within a legacy system. Recent approaches to evolution within CBSE, such as ArchStudio [20], focus on evolving systems that are already designed and constructed from well defined components and connectors. The emerging discipline of Software Architecture as defined by Garlan and Shaw is concerned with a level of design that addresses structural issues of a software system, such as ....
P. Oreizy, N. Medvidovic, and R. Taylor, "Architecturebased runtime software evolution", Proceedings, 20 International Conference on Software Engineering, Kyoto, Japan, Apr. 1998, pp. 62-70.
....to that in Darwin is used for architectures implemented in the C2 style. The C2 framework introduces components and connectors as implementation entities. A component or connector corresponds to a class in the implementation language. At run time system maintainers use a shell like tool ArchTool [12, 13]. ArchTool implements a language where the manager can express modifications (e.g. add a component) and constraints. Applications in the C2 style are aware of the architecture, and the meta information is directly accessible from ArchTool. 3 The JDRUMS Environment The goal of JDRUMS is, as ....
P. Oreizy, N. Medvidovic, and R.N. Taylor. Architecture-Based Runtime Software Evolution. In Proceedings of the International Conference on Software Engineering 1998.
....Given a particular architectural style, there will typically be a set of natural operators for changing an architectural configuration and querying for additional information. In the most generic case, architectures can provide primitive operators for adding and removing components and connections [24]. However, specific styles can often provide higher level operators that exploit the restrictions in that style and the intended implementation base. In terms of our example, we define the following operators: addServer( This operation is applied to a server group component and adds a new ....
....and reflective middleware system, which in general do not have an explicit architectural model of the application. There has been some related research on architecture based adaptation. However, this research relies on specific architectural styles, and implementations that match these styles [13,24]. In this paper, we have concentrated on how architectural models can be used to guide adaptation in a pervasive system, and the extensions need to software architectures to make them useful in a dynamic setting. In our broader approach we decouple the style from the system infrastructure so that ....
Oreizy, P., Medvidovic, N., and Taylor, R.N. Architecture-Based Runtime Software Evolution in the Proceedings of the International Conference on Software Engineering 1998 (ICSE'98). Kyoto, Japan, April 1998, pp. 11 15.
....in the areas of software architecture and domain specific software. Numerous authors have suggested the use of architectures to guide the composition of software system out of components or modules (e.g. 16, 17, 7] Our specific approach to module interchange is similar to that suggested by [14] and [4] who propose the use of a defined architecture as the framework within which difing the Containment Unit architecture. As a result, our analyses are based on older versions of the Containment Units. ferent components can be interchanged. Containment Units extend this through the inclusion ....
P. Oreizy, N. Medvidovic, and R. N. Taylor. Architecture-based runtime software evolution. In Proceedings of the Twentieth International Conference on Software Engineering, pages 177--186, Apr. 1998.
....that has not yet been fully addressed by the software architecture community. Component adaptation is strongly related to Architectural Evolution, a research area concerned with the addition, removal, or replacement of components or connectors that comprise a component based application [23,26]. Adaptation techniques are differentsince they focus on creating an adapted component CA from 2 Selected Component Glue Code Requires Interface for Target Application LEGEND Target Application App C Figure 2: Adaption context an existing component C. Whether dynamic [3, 26]or static ....
....application [23,26] Adaptation techniques are differentsince they focus on creating an adapted component CA from 2 Selected Component Glue Code Requires Interface for Target Application LEGEND Target Application App C Figure 2: Adaption context an existing component C. Whether dynamic [3, 26]or static [15] architectural evolution is not a competing technology, but one that should be used in conjunction with component adaptation techniques. Overview In Section 2 wepresentasetofadaptation techniques drawn from the literature. We then describe in Section 3 the results of an ....
P. Oreizy, N. Medvidovic, and R. N. Taylor. Architecture-based runtime software evolution. In International Conference on Software Engineering, Kyoto, Japan, April 1998.
....there is no support mentioned for specifying behavior composition on a per collaboration basis. Research is however ongoing to make her co work with Karl Lieberherr about composing collaborations [16] 17] more dynamic [9] 18] 4.2. Dynamic software architecture In Regis [14] and ArchStudio [19], systems are constructed from a number of components and connectors that encapsulate the interactions between these components. The emphasis of these works is on the description, reconfiguration and evolution of the system s architecture. Connectors help to decouple components from one another ....
P. Oreizy, N. Medvidovic, and R.N. Taylor, "Architecture-based Run-time Software Evolution", in Proceedings of ICSE'98, 1998.
....these systems provide. They have high availability, adaptability and maintainability requirements, and, in order to remain useful, they have to cope with advances in technology, modifications of their operating environment and ever changing human needs [10] The aim of dynamic reconfiguration [8, 9, 7, 1, 4, 11, 2, 10, 14, 18] is to allow a system to evolve at ran time [8] as opposed to design time, while introducing little (or ideally no) impact on the system s execution. In this way, systems do not have to be taken off line, rebooted or restarted to accommodate changes. Changes can be classified with relation to the ....
....d operations on these entities, d e applied der the cono] of change managementfunctionali, mng the system evolve om its cuent confiration to a resulting confiration. Chge magement ctiona]i uses confiration information, which refers to the relationship beeen entities. Change management cfionali [11, 10, 8] consols the reconfiation process of a disbuted system. is ctiona]i must tee that (i) specified chges e evena] y applied to a system, ii) a (use] coect system is obtained, d, iii) reconfiation consaints e satisfied. Reconfiration constraints e predicates on the reconfiation process that resct ....
P. Oreizy, N. Medvidovic, R. Taylor. Architecture-based runtime software evolution, in Proceedings of the International Conference on Software Engineering, April 1998.
....system is determined by its downtime due to various types of maintenance. In practice, a reconfiguration implies that the system needs to be taken offline and restarted after installation of new software components. The downtime due to maintenance can be avoided by using dynamic reconfiguration [1, 3, 4, 5, 7, 9, 10 , 11 , 13 , 20 , 25], i.e. the system can be maintained or upgraded without being taken off line. The aim of dynamic reconfiguration is to allow a system to evolve at run time [9] as opposed to designtime, while introducing little (or ideally no) impact on the system s execution. In this way, the system does not ....
....process, i.e. the transfer from the current configuration (system S i ) to a resulting configuration (system S i 1 ) and use and produce configuration information. The configuration information defines the relationship between the system s entities. Change Management requires functionality [9, 11, 13] providing guarantees that (i) specified changes are eventually applied to the system, ii) a (useful) correct system is obtained, and, iii) reconfiguration constraints are satisfied. Performing reconfiguration on a running system is an intrusive process [11] Reconfiguration may imply, for ....
P. Oreizy, N. Medvidovic, R. Taylor. Architecture-based runtime software evolution, in Proceedings of the International Conference on Software Engineering, April 1998.
....these systems provide. They have high availability, adaptability and maintainability requirements, and, in order to remain useful, they have to cope with advances in technology, modifications of their operating environment and ever changing human needs [10] The aim of dynamic reconfiguration [8, 9, 7, 1, 4, 11, 2, 10, 14, 18] is to allow a system to evolve at run time [8] as opposed to design time, while introducing little (or ideally no) impact on the system s execution. In this way, systems do not have to be taken off line, rebooted or restarted to accommodate changes. Changes can be classified with relation to the ....
....applied under the control of change management functionality, making the system evolve from its current configuration to a resulting configuration. Change management functionality uses configuration information, which refers to the relationship between entities. Change management functionality [11, 10, 8] controls the reconfiguration process of a distributed system. This functionality must guarantee that (i) specified changes are eventually applied to a system, ii) a (useful) correct system is obtained, and, iii) reconfiguration constraints are satisfied. Reconfiguration constraints are ....
P. Oreizy, N. Medvidovic, R. Taylor. Architecture-based runtime software evolution, in Proeedings of the International Conference on Software Engineering, April 1998.
....one machine to another. It this case, the architecture must support the modification of the mapping of components to processors. C2, Darwin, and Rapide support dynamism. Darwin and Rapide support only constrained dynamic manipulation of architecture, i.e. the changes must be planned. In [22] and [23], we find a set of issues to be considered when trying to establish under what circumstances it is safe to remove and or add a component from to an architecture, change the filtering policy on a connector port, and rewire the architecture. 3 Formalizing Software Architectures Several formalisms ....
Peyman Oreizy, Nenad Medvidovic, and Richard N. Taylor. Architecture-Based Runtime Software Evolution. Proceedings of the International Conference on Software Engineering (ICSE'98), Kyoto, Japan, April 19-25 1998.
....is currently under development as the top layer of the OCP (shown in Fig. 2) will capture general mechanisms for managing configurations and reconfigurations. The OCP takes an architecture oriented approach to reconfiguration management, building on seminal work in runtime software evolution [6]. In this approach, generic architectural patterns that are common to similar software systems within a focused domain are captured and reused. We are extending this work to real time, mission critical applications such as extreme performance UAV control by identifying and exploiting system ....
....C Actuator Deflections Sensor Data Helicopter Flight Simulation Model (Fortran) Figure 9. Flight control configuration in the OCP demonstration prototype. Reconfigurations of control systems also follow standard strategies, analogous to what Oriezy et al. call change application policies [6]. These are strategies for making changes without violating reliability, safety, and consistency constraints. For example, they may dictate how quickly one algorithm can be switched for another or whether a redundant component needs to work concurrently with the component it is replacing before ....
P. Oreizy, N. Medvidovic, and R.N. Taylor, "Architecture-based runtime software evolution," in Proc. Int. Conf. Software Engineering (ICSE'98), pp. 117-186.
....rules, external product characteristics) for which the software was developed is likely to change. Adaptive maintenance results in modification to the software to accommodate changes to its external environment. 13] 10. Adaptive evolution changes the software to run in a new environment. [14]. Numerous techniques have been developed to deal with adaptation of software systems and each of these techniques has its own context of applicability. In this paper we present an overview of some of these techniques. However, very few of these techniques trace the solutions developed to their ....
Oreizy, P., Medvidovic, N. and Taylor, R.N. ArchitectureBased Runtime Software Evolution , Proceedings of the International Conference on Software Engineering , Kyoto, Japan, April 1998, pp. 177 - 186.
.... [27] Such an externalisation of the interconnections should allow for systems to be reconfigured, in a compositional, non intrusive way, by acting directly on the entities that capture the interactions between components, leading to an evolution process that follows the architecture of the system [12,30]. Whereas interactions relate two or more components, the technology that is required for externalising them is also meaningful when applied to the evolution of single components. Indeed, another class of changes often required on a system concerns the adaptation of individual components [10] ....
P.Oreizy, N.Medvidovic and R.Taylor, "Architecture-based Runtime Software Evolution ", in Proc. ICSE98, IEEE Computer Science Press 1998
.... [23] Such an externalisation of the interconnections should allow for systems to be reconfigured, in a compositional, non intrusive way, by acting directly on the entities that capture the interactions between components, leading to an evolution process that follows the architecture of the system [11,26]. Whereas interactions relate two or more components, the technology that is required for externalising them is also meaningful when applied to the evolution of single components. Indeed, another class of changes often required on a system concerns the adaptation of individual components [9] ....
P.Oreizy, N.Medvidovic and R.Taylor, "Architecture-based Runtime Software Evolution ", in Proc. ICSE98, IEEE Computer Science Press 1998
....focus primarily on the solution domain and therefore do not help to bridge the complexity gap because CBSE techniques often focus on constructing components from scratch rather than reengineering them from within the legacy code. Recent approaches to evolution within CBSE, such as ArchStudio [24], focus on evolving systems that are already designed and constructed from well defined components and connectors. The emerging discipline of Software Architecture as defined by Garlan and Shaw is concerned with a level of design that addresses structural issues of a software system, such as ....
P Oreizy, N Medvidovic, and R. Taylor, "Architecturebased runtime software evolution", Proceedings, International Conference on Software Engineering, Kyoto, Japan, Apr. 1998.
....gap because CBSE techniques often focus on constructing components from scratch rather Feature 1 Feature 2 Feature 3 Core Figure 7 : Example of System Core Relationship 8 than reengineering them from within the legacy code. Recent approaches to evolution within CBSE, such as ArchStudio [24], focus on evolving systems that are already designed and constructed from well defined components and connectors. The emerging discipline of Software Architecture as defined by Garlan and Shaw is concerned with a level of design that addresses structural issues of a software system, such as ....
P Oreizy, N Medvidovic, and R. Taylor, "Architecturebased runtime software evolution", Proceedings, International Conference on Software Engineering, Kyoto, Japan, 1998.
....a mobile In the WONDER architecture, the control, the storage of data, and the execution of the activities are all distributed over the hosts of an enterprise computer network. 4.1.7. Runtime Change of Software Software systems can be specially specified and configured to be changed at runtime [OMT98] In this context, software agents can be deployed conveying updates of modules and software configurations. Its intrinsic capability of conveying data and their ability to execute operations in the current machine can be used to control and coordinate the process of stopping, modifying, and ....
P. Oreizy, N. Medvidovic, and R. N. Taylor. Architecture-based runtime software evolution. In Proceedings of the International Conference on Software Engineering 1998 (ICSE'98), Kyoto, Japan, April 1998.
....Microsoft s component technologies (DCOM, COM ) 22] offer infrastructure for composing non functional services with a core application. However, none of these infrastructures addresses all three challenges of section 2.1. 5.4. Connectors and configuration languages In Regis [11] and ArchStudio [14], systems are constructed from a number of components and connectors that encapsulate the interactions between these components. The emphasis of these works is on the description, reconfiguration and evolution of the application s architecture. Connectors help to decouple components from one ....
P. Oreizy, N. Medvidovic, and R.N. Taylor, "Architecture-based Run-time Software Evolution", in Proceedings of ICSE'98, 1998.
....paper we have briefly introduced Mnage, a project geared towards creating a representation and environment for product line architectures. Much work still remains to be done. Two issues are at the forefront. First, we intend to integrate Mnage with a dynamic architecture framework such as C2 [3] in order to allow reconfiguration within product line boundaries in the field. Second, it seems that Mnage is ideally suited to formally capture the architecture of multi version systems, a capability that current architecture description languages lack. Acknowledgements The author wishes ....
P. Oreizy, N. Medvidovic, and R.N. Taylor. Architecture-based runtime software evolution. In Proceedings of the 1998 International Conference on Software Engineering, pages 177---186, Los Alamitos, California, May 1998. IEEE Computer Society Press.
....Architectural reconfiguration is charged to a configuration manager that resembles AR s meta entities. In their approach, nevertheless, the meta level has a limited visibility of the base level state (i.e. it only perceives whether base level entities are in a quiescent state) Oreizy et al. Oreizy 98] propose a small set of architectural modification primitives to extend a traditional (non dynamic) ADL, and also exploit connectors to let architectural information be explicit in running systems. With respect to AR, their approach is more related to defining what operations are useful at the ....
Per Oreizy, Nenad Medvidovic, and Richard N. Taylor. Architecture-based runtime software evolution. In Proceedings ICSE 98, pages 177-186, Kyoto, Japan, April 1998.
....component. Wright [Allen97] also offers support for dynamic change using events, e.g. when an event occurs it triggers some actions like unbinding and rebinding components. All these approaches require that architectural changes be expressed at design time. In contrast, the ArchStudio tool [Oreizy98], which is based on the C2 style, supports unplanned run time modifications. More specifically, this tool supports operations for the addition and removal of components. The tool also provides an architectural constrain mechanism that validates changes to leave the application in a consistent ....
P. Oreizy, N. Medvidovic, and R.N. Taylor, "Architecture-Based Runtime Software Evolution", Proc. 20 th Int' l Conf. Software Eng. (ICSE' 98), pp. 177-186, Apr. 1998.
....changes in one are propagated to the other. van der Hoek et al. 59] are studying the use of versioned software architecture as a possible forced mapping solution to the architecture implementation mapping problem. With the goal of achieving run time change for systems, the C2 architectural style [39] requires an inter level mapping. In the case of C2, changes at the architectural level should naturally be propagated to the implementation level. They assume that implementation level changes will be restricted by a preconceived set of application invariants . 6 System Generation System ....
P. Oreizy, N. Medvidovic, and R.N. Taylor. Architecture-Based Runtime Software Evolution. In Proceedings of the 1998 International Conference on Software Engineering, pages 177-186. Association for Computer Machinery, April 1998.
No context found.
P. Oreizy, N. Medvidovic, R. N. Taylor. Architecture-based runtime software evolution. Proceedings of the International Conference on Software Engineering 1998, Kyoto, Japan. April 1998.
No context found.
Oreizy P., Medvidovic N., and Taylor R. N., Architecture-Based Runtime Software Evolution in Proceedings of the 20th International Conference on Software Engineering, pp.177-186, Kyoto, Japan, April 1998.
....are both capable of modeling properties of dynamic architectures those that change at run time although they do so in different ways. New research issues continue to emerge from the architecture community. Areas of interest include distributed architectures [26] dynamic architectures. [34], integrating architectures with software deployment and maintenance [16] and product line architectures [11] Research in areas such as these indicates that it is reasonable to expect new ADLs, or at least ADL features, from the software architecture community. This exemplifies the need for our ....
....Table 2. We discuss each schema in detail below. 3.2.1 Separation of Run Time and Design Time Traditionally, ADLs have focused on design time aspects of a software system or have combined run time and design time aspects in a single model. However, research on dynamic software architectures [22][34] has revealed that it is useful to provide a separate architectural model of a software system at run time. Run time models capture aspects of a running software system that are different from aspects captured at design time. For instance, a design time model of a system might contain information ....
P. Oreizy, N. Medvidovic, and R. Taylor. Architecture-Based Runtime Software Evolution. In Proceedings of the International Conference on Software Engineering 1998.
....is no bound on the number of components or connectors that may be attached to a single connector. This decoupling of components greatly aids system flexibility and gradual evolution, where components can be added to or removed from an architecture with minimal impact on the rest of the system [19]. Components and connectors can have an internal architecture, such that they are composed of further components and connectors as long as they support the above C2 style rules. Figure 1 illustrates an architectural configuration in the C2 style. The C2 style does not make any assumptions about ....
....Distribution The framework should not make any assumptions about the number or location of address spaces in which a system s components will reside. Dynamism The framework should enable modification of a system s runtime architecture with minimal effect on the execution of existing components [ 19]. Efficiency The framework should impose minimal overhead on an application s execution. The goal is to enable efficient execution of applications on platforms with varying characteristics (e.g. speed, capacity, network bandwidth) Ideally, the framework should permit full use of the power of ....
[Article contains additional citation context not shown here]
P. Oreizy, N. Medvidovic, R. N. Taylor. Architecture-Based Runtime Software Evolution. In Proceedings of the 20th International Conference on Software Engineering, pp. 177-186, Kyoto, Japan, April 1998.
....coupling: a component is only aware of a single connector above and or a single connector below it. That means that components can be added, removed, replaced or reconnected in a C2 style architecture, even at runtime, without their neighbouring components ever needing to know about those changes [12]. One the other hand, the database centric style is not well suited to this case. Conversely, the database centric style is well suited to address the sharing data andcomponent backtracking mismatch , for which C2 is not as well suited. The automatic reconfiguration mismatch is addressable by ....
.... backtracking mismatch , for which C2 is not as well suited. The automatic reconfiguration mismatch is addressable by C2: the message based interaction of C2 230 components via connectors presents an ideal foundation for system adaptability, both offiine and at system runtime [12]. It is important to note that the fourth mismatch discovered by the AAA tool (response time due to onthe fly garbage collection) is well supported neither by C2 nor by the database centric style. As will often be the case, none of the three styles is the perfect fit to this problem. In such a ....
OREIZY, P., MEDVIDOVIC, N., and TAYLOR, R.: 'Architecture-based runtime software evolution'. Proceedings of the 20th international conference on Software engineering (ICSE), 1998
No context found.
P. Oreizy, N. Medvidovic, and R. N. Taylor. Architecture-Based Runtime Software Evolution. ICSE98, April 1998.
....the integrated system model to validate the consistency of any local changes within the broader framework of an entire architecture. Mae s integrated system model provides another benefit in the form of new capabilities in the domains of software deployment [12] and run time change management [8,25]. Specifically, the availability of explicit relations among the multiple versions of architectural elements in the model allows the creation of patches at the architectural level, instead of at the source code level. These patches, in turn, can be automatically added to and removed from installed ....
....generates templates for the components that make up the system, reuses standard implementations for the connectors, and automatically generates the component that represents and instantiates the system configuration. In doing so, Mae uses a version of the C2 implementation and execution framework [25]. Our prototype implementation of Mae is not yet complete as of yet. The integration between the two components (DRADEL and Mnage) can be made much tighter such that, for example, type checking occurs automatically and instantaneously rather than after the fact. Moreover, we intend to ....
[Article contains additional citation context not shown here]
Oreizy P., Medvidovic N., and Taylor R. N., ArchitectureBased Runtime Software Evolution in Proceedings of the 20th International Conference on Software Engineering, pp.177-186, Kyoto, Japan, April 1998.
....user downloads a new software add on using their Web browser, the add on s installation script is located and executed. We have used ArchStudio to implement two applications with several add ons each. More details regarding ArchStudio and a sample application implemented using it are described in [12]. We have implemented a simple end user tool for installing and removing software add ons, called the Extension Wizard, that is also deployed with the application. End users use a Web browser to display a list of downloadable software add ons, e.g. provided by the software vendor on their Web ....
P. Oreizy, N. Medvidovic, R. N. Taylor. Architecture-based runtime software evolution. To appear International Conference on Software Engineering 1998, Kyoto, Japan. April 1998.
No context found.
Oreizy, P., Medvidovic, N., and Taylor, R.: "Architecture-Based Runtime Software Evolution," Proceedings of the 20 th International Conference on Software Engineering (ICSE), Kyoto, Japan, 1998, pp.177-186.
No context found.
P. Oreizy, N. Medvidovic, and R. N. Taylor. ArchitectureBased Runtime Software Evolution. In Proceedings of the 20th International Conference on Software Engineering (ICSE '98), pages 177--186, Apr. 1998.
No context found.
P. Oreizy, N. Medvidovic, and R. N. Taylor. Architecturebased runtime software evolution. In Proceedings of the 20th international conference on Software engineering, pages 177-- 186. IEEE Computer Society, 1998.
No context found.
P. Oreizy, N. Medvidovic, and R. N. Taylor, "Architecture-based runtime software evolution," in Proceedings of the 20th international conference on Software engineering. IEEE Computer Society, 1998, pp. 177--186.
No context found.
P. Oreizy, N. Medvidovic and R.N. Taylor. Architecture-Based Runtime Software Evolution. Proc. of 20th International Conference on Software Engineering, 1998.
No context found.
P. Oreizy, N. Medvidovic, and R. N. Taylor. Architecture-based runtime software evolution. In Intl. Conf. on Software Engineering, Kyoto, Japan, April 1998.
No context found.
Oreizy, P., Medvidovic, N., and Taylor, R., "Architecture-based runtime software evolution". In Proceedings of the International Conference on Software Engineering 1998 (ICSE'98), Kyoto, Japan, April 1998.
No context found.
Peyman Oreizy, Nenad Medvidovic, and Richard N. Taylor. Architecture-based runtime software evolution. In Proceedings of the International Conference on Software Engineering 1998 (ICSE'98), pages 177--186, April 1998.
No context found.
P. Oreizy, N. Medvidovic, and R. N. Taylor. Architecture-based runtime software evolution. In Proc. of the Int. Conf. on Software Engineering, pages 177--186, Apr. 1998.
No context found.
Oreizy, P., Medvidovic, N., and Taylor, R.: "Architecture-Based Runtime Software Evolution," Proceedings of the 20 th International Conference on Software Engineering (ICSE), Kyoto, Japan, 1998, pp.177-186.
No context found.
P. Oreizy, N. Medvidovic, and R. Taylor. Architecture-based runtime software evolution. In Proceedings of the International Conference on Software Engineering (ICSE 98), Kyoto, Japan, April 1998.
No context found.
P. Oreizy, N. Medvidovic, and R. N. Taylor. Architecture-based runtime software evolution. In Proceedings of the 20th International Conference on Software Engineering, Kyoto, Japan, Apr. 1998.
No context found.
P. Oreizy, N. Medvidovic, R. Taylor. Architecture-based runtime software evolution, in Proceedings of the International Conference on Software Engineering, April 1998.
No context found.
Oreizy, P., Medvidovic, N., and Taylor, R., "Architecture-based runtime software evolution". In Proceedings of the International Conference on Software Engineering 1998 (ICSE'98), Kyoto, Japan, April 1998.
No context found.
Oreizy, P., Medvidovic, N., and Taylor, R., "Architecture-based runtime software evolution". In Proceedings of the International Conference on Software Engineering 1998 (ICSE'98), Kyoto, Japan, April 1998.
No context found.
P.Oreizy, N.Medvidovic and R.Taylor, "Architecture-based Runtime Software Evolution", in Proc. ICSE98 , IEEE Computer Science Press 1998.
No context found.
P. Oreizy, N. Medvidovic, and R. N. Taylor. ArchitectureBased Runtime Software Evolution. In Proceedings of the 20th International Conference on Software Engineering (ICSE'98), Kyoto, Japan, April 1998.
No context found.
P. Oreizy, N. Medvidovic, and R. N. Taylor. ArchitectureBased Runtime Software Evolution. In Proceedings of the 20th International Conference on Software Engineering (ICSE'98), Kyoto, Japan, April 1998.
No context found.
Oreizy, P., Medvidovic, N., and Taylor, R. (1998) "Architecture-Based Runtime Software Evolution," Proceedings of the 20th International Conference on Software Engineering.
No context found.
P.Oreizy, N.Medvidovic and R.Taylor, "Architecture-based Runtime Software Evolution", in Proc. ICSE'98, IEEE Computer Science Press 1998.
First 50 documents Next 50
Online articles have much greater impact More about CiteSeer.IST Add search form to your site Submit documents Feedback
CiteSeer.IST - Copyright Penn State and NEC