Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

Dynamic Software Architecture

VIEWS: 7 PAGES: 40

									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
• [1] Peyman Oreizy, Issues in the Runtime Modification of Software
  Architectures.
• [2] Jesper Andersson, Issues in Dynamic Software Architecture.
• [3] Jesper andersson, Employing Dynamic Architectures.
• [4] Nenad Medvidovic and Richard N. Taylor, A classification and
  comparison framework for software architecture description
  languages
• [5] Peyman Oreizy, Nenad Medvidovic, Richard N. Taylor,
  Architecture-based Runtime Software Evolution.
• [6] Shang-wen Cheng, David Garlan, Bradley Schmerl, et cl. Software
  Architecture-based Adaptation for Pervasive Systems.
• [7] Shang-wen Cheng, David Garlan, Bradley Schmerl, et cl. Software
  Architecture-based Adaptation for Grid Computing.
• [8] Bradley Schmerl, David Garlan. Exploiting Architectural Design
  Knowledge to Support Self-repairing Systems.
• [9] Chris Salzmann, Maurice Schoenmakers. Dynamics and Mobility
  in Software Architecture.

								
To top