VIEWS: 7 PAGES: 40 POSTED ON: 9/15/2011
Dynamic Software Architecture Feng Yaodong PKU-Bell Lab Software Technologies Joint Lab 2002.10.22 Outline • Introduction. • Current Research. • Thoughts. • Conclusion. • Reference. Introduction • Dynamic Configuration. – Originally the demand of Time critical systems. – Increasingly become important in general distributed systems, especially in pervasive computing. – Even Desktop applications and OS allow upgrades without shutting systems down. • Self-Adaptation, self-repairing, self-healing Software architectures are not static, they are changing dynamically. Introduction • Most exist approaches of dynamic configuration is: – Per-system, ad hoc. – Embedded the mechanisms in code. – Focusing on runtime reconfiguration. • So, making the knowledge difficult to – Transfer or reuse in other systems. – Reason about or analyze to ascertain whether the configuration will result in proper-running systems. – Change. • A systematic approach is needed. – Dynamic Software Architecture. Introduction Long run, time-critical systems require changes without shutting them down. Dynamic Configuration Notations, models, approaches of analysis and validation of SA Dynamic Software Architecture Introduction • Dynamic configuration of systems is not directly a software architecture problem, and configuring systems are not required to be “architecture- aware”. But the technique is a primitive support component for all applications with dynamic architecture. • The main aim with dynamism is to allow applications to introspect and evolve at run-time. E.g., – Provide mechanisms for automatic updates of components – Flexibility. – Enable system administrators to add/remove functionality – manageability. Introduction • Dynamic Software Architecture provides an abstract model: – Abstract the runtime architecture and provide a global perspective on the system to increase understandability. – Make “integrity” constraints explicit, helping to ensure the validity of any changes. – Suitably-designed architectures permit flexible evolution of systems by providing loose coupling between component. – Architectures encapsulate the design knowledge, and thereby provide a basis for principled adaptation. – By “externalizing” the monitoring and adaptation of a system using architectural models, it is possible to engineer adaptation mechanisms, infrastructure and policies independent of any particular application, thereby reducing the cost and improving the effectiveness of adding self-adaptation to new systems. Introduction • Dynamic restructuring (software): – The process of changing software components or structure while a system is running. – IEEE Standard Dictionary. • Luckham and Vera define dynamicism in the Rapide language as – the capability of modeling architectures in which the number of components, connectors, and bindings may vary when the software system is executed. Introduction • Medvidovic and Taylor describe – Evolution refers to “off-line” changes to an architecture and the resulting system. – Dynamism refers to modifying the architecture and enacting those modifications in the system while the system is executing. Current Research • UCI. • CMU. • Linkopings University, Sweden. • Munich University of Technology, Germany. Current Research – UCI • Architecture-Based Runtime Software Evolution. • C2. – support dynamic manipulation without any restrictions on the types of permitted changes. – arbitrary modifications are allowed in principle; their consistency is ensured at system runtime. – AML describes the set of operations that must be performed to modify the architecture. – ACL describes the constraints under which architectural modifications must be performed. Current Research – UCI • Change management: – Helps identify what must be changed, – Provides context for reasoning about, specifying, and implementing change, and – Controls change to preserve system integrity. • Distinguish two types of changes: – Changes to system requirements – Changes to system implementation that do not alter requirements. Current Research – UCI • Several critical aspects to change management: – Change application policy. • Controls how a change is applied to a running system. – Change scope. • The extent to which different parts of a system are affected by a change. – Separation of concerns. • Separate functional behavior from runtime change. – Level of abstraction. Current Research – UCI • Runtime architectural change. – Runtime component addition. – Runtime component removal. – Runtime component replacement. – Runtime reconfiguration. • Connectors must remain discrete entities in the implementation to support their runtime addition and removal. Current Research – UCI • Component replacement. – Retain the state – the state of the executing component must be transferred to the new component. – Both components must not be simultaneously active during the change. – utilize transaction to ensure. ??? Current Research – UCI • Tool Support – Approach • Explicit architectural model. • Describing runtime change. • Governing runtime change. • Reusable runtime architecture infrastructure. – Three parts: • Argo – graphical depiction of architectural model. • ArchShell – textual, command-driven interface for specifying runtime modification. • Extension Wizard – deploy the modification to end- users. Current Research – UCI Current Research – CMU • Software Architecture-based Adaptation. • Dynamic Wright. – Configurator. • When should the architecture be reconfigured? • What should cause the architecture to reconfigure itself? • How should the reconfiguration be made? Current Research – CMU • Approach is based on three-layer architecture. – Runtime Layer. • Application, operating environment, monitoring infrastructure. – Model Layer. • Architecture model, architecture manager. – Task Layer. • Responsible for setting overall system objectives. Current Research – CMU Current Research – CMU • Tool Support. – AcmeStudio. • Depiction. – Armani. • Constraints analysis, strategy. – Gauge infrastructure. – Tailor Repair. Current Research – CMU Current Research – Linkopings • Four major steps in changing architecture configuration dynamically: – Initiation of dynamic change. • How the dynamic updates and reconfigurations are initiated. – Selection of transformation. • Process of selecting an appropriate configuration and how to reconfigure a system. – Implementation. • How the actual change is carried out. – Assessment. • Assess the architecture qualities after a change. Current Research – Linkopings • Three types of dynamism. – Constructible Dynamism. • A description language, a modification language, a dynamic updating system. – Adaptive Dynamism. • Based on a set of predefined configurations. – Intelligent Dynamism. • Dynamically construct candidate configuration, automatic assess qualities of the configuration. Current Research – Linkopings • Constructible Dynamism. Current Research – Linkopings • Adaptive Dynamism. Current Research – Linkopings • Intelligent Dynamism. Current Research – Munich • Four main areas should be considered. – Types of dynamic changes. • Implementation changes. • Interface changes. • Connector changes. • Mobile changes. – Component moves from one location to another. – Mutual relationships. – Appropriate formalisms to express. – Appropriate description techniques. Current Research – Munich • Carp. – A monitoring tool for dynamic distributed systems. – Based on Sun’s Jini technology. – Different services (components) are dynamically discovered, allocated and binded in an application observed by Carp. Current Research • Other ADLs supporting Dynamic Architecture. – Repide. • supports conditional configuration: its where clause enables architectural rewriting at runtime, using the link and unlink operators. – Darwin. • allows runtime replication of components via dynamic instantiation, as well as deletion and rebinding of components by interpreting Darwin scripts. – Weaves. Thoughts • Software Architecture: – “...beyond the algorithms and data structures of the computation: designing and specifying the overall system structure emerges as a new kind of problem. Structural issues include gross organization and global control structure; protocols for communication, synchronization, and data access; assignment of functionality to design elements; physical distribution; composition of design elements; scaling and performance; and selection among design alternatives. This is the software architecture level of design.” – by Garlan and Shaw. Thoughts • Architectural changes: – Component addition. – Component removal. – Component replacement. – Connector addition. – Connector removal. – Connector replacement. – The changes of topology. – The changes of architectural constraints. Thoughts • Dynamic Software Architecture concerns: – Sources inducing architectural changes. – Architectural changes description. – The changes in architecture model. – The analysis and validation of changes in architectural model. – The propagation of changes to runtime. – Runtime infrastructure support. – The changes in runtime architecture. – The analysis and validation after modification. – Visualization of software architecture. Thoughts • SA support. – Descript changes. – Produce modification strategy according to changes. – Descript modification. – Ensure the modification within high-level constraints. – Analyze, reason about the impact of modification at high-level. Thoughts • Runtime infrastructure support. – Maintain the system’s architectural model. – Ensure that architectural modifications are within modification constraints. – Provide the information of runtime, e.g., runtime architecture, states of components, etc. – analyze the modified architecture to ensure its desirable properties, – correctly map the changes expressed in terms of architectural constructs to the implementation modules, – ensure continuous execution of the application’s vital subsystems and preservation of state during the modification, – and analyze and test the modified application while it is executing. Thoughts • Incorporate DSA to extend ABC. – Original ABC: • Descript architectural changes. • Descript modification. • Analyze, reason, and validate. • Visualization. – PKUAS • Runtime infrastructure. Thoughts Thoughts • What should do in the future. – Augment the capability in ABC/ADL of describing architectural changes and modifications. – Enhance the capability in ABC of analysis and validation of changes and modifications. – Enhance the PKUAS – reflective mechanism. Conclusion • Dynamic Software Architecture: – Provides a systematic approach for managing dynamic configuration of systems. – Immature. Reference •  Peyman Oreizy, Issues in the Runtime Modification of Software Architectures. •  Jesper Andersson, Issues in Dynamic Software Architecture. •  Jesper andersson, Employing Dynamic Architectures. •  Nenad Medvidovic and Richard N. Taylor, A classification and comparison framework for software architecture description languages •  Peyman Oreizy, Nenad Medvidovic, Richard N. Taylor, Architecture-based Runtime Software Evolution. •  Shang-wen Cheng, David Garlan, Bradley Schmerl, et cl. Software Architecture-based Adaptation for Pervasive Systems. •  Shang-wen Cheng, David Garlan, Bradley Schmerl, et cl. Software Architecture-based Adaptation for Grid Computing. •  Bradley Schmerl, David Garlan. Exploiting Architectural Design Knowledge to Support Self-repairing Systems. •  Chris Salzmann, Maurice Schoenmakers. Dynamics and Mobility in Software Architecture.
Pages to are hidden for
"Dynamic Software Architecture"Please download to view full document