Alternatives to Dynamic
Software Architectures

There are a wide variety of techniques for supporting runtime software change. Some of the most popular techniques are listed below. It should be noted, however, that designers have traditionally sought alternatives to runtime change altogether. Several reasons account for this:

  1. It is usually avoidable. Runtime change is not a critical aspect of many software systems and several techniques have been devised to circumvent the need for runtime change altogether. Regularly scheduled downtimes, functional redundancy or clustering, and manual overrides are all examples of such techniques.
  2. It increases risk. System integrity, reliability, and robustness are more difficult to ensure in light of runtime change.
  3. It increases cost. There is typically a marked performance overhead associated with supporting runtime change. Additionally, few techniques have limited expertise and a lack of proven techniques for supporting runtime change exasperate engineering costs.

Programming Language Based Approaches

[GJB96] describe an approach to modeling changes at the statement- and procedure-level for a simple imperative programming language.

Dynamic Programming Languages

Many dynamic programming languages, such as Lisp, Smalltalk, and Haskel [PHL97] have supported runtime software change for decades.

Dynamic Linking Mechanisms

Dynamic link libraries have been available in operating systems such as UNIX, Microsoft Windows, and the Apple Macintosh for some time. New approaches to dynamic linking [Fra97] hope to significantly reduce the runtime performance overhead associated with using such mechanisms.

Dynamic Object Technology

CORBA [OMG96] and COM [Broc94] support the runtime locations, loading, and binding of software objects or components.

Also see the May 1997 special issue of Communications of the ACM.


Return to the Dynamic Software Architectures home page.
These pages are maintained by Peyman Oreizy. Send comments via e-mail.

ÿ