Systems are represented by a continuum of notations ranging from highly informal descriptions of functional requirements to the (fully specified) executing system. “Architectures” occupy a space in this continuum. They are more explicit than requirements, since they describe components and component interactions. They may be less explicit than detailed designs, since they do not describe specifically how the building blocks function. However, the separation between architecture and design is fuzzy at best.
According to Garlan and Shaw, [6] [Software architecture] goes beyond the [design of] 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. One adds to this, the explicit representation of constraints on or boundaries of a system. Much of system integration requires understanding constraints (e.g., with respect to data access, event sequencing and timing, resource utilization, allowable parameter values, allowable topologies, fault tolerance, real time, survivability, redundancy, and replication) of components that are composed in the context of a hardware and software architecture.
An architecture is said to represent a family of systems rather than a single instance. If this is to be useful, we must have some way of representing what the boundaries of the family are; what is “inside”and what is “outside” the architecture. The constraints can provide explicit boundaries on implementation variability and dynamic modification.
One way of defining architecture (or Architecture Description Languages (ADL) or architectural styles) is by the functions they perform. Figure 1 describes them by analogy with language typing.
Enable automatic analysis and early detection of errors. We can analyze architectures to prevent errors and to generate automated runtime checks.
Enable reuse and product line development. We can use architectures to formalize component interrelationships in families of related systems tailored to a specific domain.
Support incrementality. Architectural specifications allow us to do the minimum work required to accommodate change.
Support optimization (non-functional attributes). We can use architectures as the basis for optimizing component placement and partitioning with respect to “non-algorithmic” attributes such as performance, reliability, security, and safety.
Architecture provides abstractions adequate for modeling a large system, while ensuring sufficient detail for establishing properties of interest. The abstractions encompass multiple views, varying in level of detail and properties represented (e.g., data or control flow views, timing, and resource use). They need to support both static and dynamic analyses.
Static analysis includes internal consistency checks, such as whether appropriate components are connected and their interfaces match. Certain concurrent and distributed aspects of an architecture can also be assessed statically, such as the potential for deadlocks and starvation, performance, reliability, security, and so on. Finally, architectures can be statically analyzed for adherence to design heuristics and style rules.
Examples of dynamic analysis are testing, debugging, assertion checking, and assessment of the performance, reliability, and schedulability of an executing architecture.
Specific languages provide different types of checks. Thus, for example:
Wright [3] detects mismatches between parts that fail to agree on protocols of interaction. It identifies race conditions and potential deadlocks.
Aesop [2] provides facilities for checking type consistency, cycles, resource conflicts, and scheduling feasibility.
C2 [13] establishes adherence to style rules and design guidelines.
Rapide [7, 9] simulates architectures in terms of Partially Ordered Sets of Events (POSETS) and animates their execution. It provides tools for viewing and filtering events generated by the simulation (or an executing system).
MetaH [15] analyzes schedulability, reliability, fault handling, and, security errors.
A product line is a group of applications that share a common architecture (e.g., a standard set of applications for Missile Guidance, Navigation and Control (MGN&C)). Large-scale reuse is possible because the applications share a set of generic components and employ common interaction protocols.
An architectural style is a recurring pattern of system organization. It defines a standard vocabulary of components and connectors and rules for their use. The use of architectural styles can promote design reuse by clarifying the context of applicability of particular solutions. It can also promote code reuse by permitting shared implementations of invariant aspects of an architectural style.
The use of composition/generation based on architecture, run-time constraint checking, architecture generated testing, and architecture recovery (for legacy systems) can help assure that the implementation is a valid instantiation of architecture.
All ADLs unambiguously specify the important interfaces in a system and provide tool support for using/checking these interfaces. This is critical for enabling the reuse and easy reconfiguration of subsystems/components.
Some specific language examples include:
Wright [1] was used to model and analyze the Runtime Infrastructure (RTI) of the Department of Defense (DoD) High-Level Architecture for Simulations (HLA). The original specification for RTI was over 100 pages long. Wright was able to substantially condense the specification and reveal several inconsistencies and weaknesses in it. It is now being used as (one) tool to determine if implementations conform to the HLA product line.
SADL [14] was applied to an operational power-control system, used by the Tokyo Electric Power Company. The system was implemented in 200,000 lines of Fortran 77 code. SADL was used to formalize the systemĄs reference architecture and ensure its consistency with the implementation architecture.
Rapide [8] has been used in several large-scale projects thus far. A representative example is the X/ Open Distributed Transaction Processing (DTP) Industry Standard. The documentation for the standard is over 400 pages long. Its reference architecture and subsequent extensions have been successfully specified and simulated in Rapide.
Incrementality means reuse, rather than redevelopment, in the face of change. It allows us to do the minimum work required to accommodate change. Architectural representations and analyses can support incrementality in four ways. They can provide:
Assurances that properties can be relied upon while the system evolves, with these properties expressed at an architectural, rather than code, level;
Automated code development / evolution, where architecture modification triggers code modification;
Automated support to test and analysis, where the architecture is a basis for specifying / deriving test and analysis plans (or plan modifications); and
Dynamic (run-time) modification by specifying and controlling change mechanisms.
Some examples:
In Integrated Modular Avionics (IMA) systems, global architectural constraints can ensure that no defects in partitions at lower levels of certification could interfere with the proper operation of more highly certified partitions. Enforcement of such laws has been coded in MetaH.
Rapide’s Constraint Checker analyzes the conformance of a Rapide simulation to the formal constraints defined in the architecture. A Rapide model of the architecture of a Chip Fabrication Line control system is now installed in TIBCO Software’s demonstration facility. It uses an event hierarchy to quickly zero in on a low-level error.
Darwin [11] allows deletion and rebinding of components by interpreting Darwin scripts. C2 specifies a set of operations for insertion, removal, and rewiring of elements at runtime [10]. C2’s ArchShell tool enables arbitrary interactive construction, execution, and runtime-modification of C2-style architectures by dynamically loading and linking new architectural elements.
MetaH [15] includes a feature called a mode, which allows the set of processes, or the connections between those processes, to be changed dynamically by the application during system operation.
Architecture is the way in which non-functional requirements such as performance, fault tolerance, and security/safety concerns are expressed and analyzed. If we were only interested in functional requirements, we could write a formal spec in Z, automatically convert it to Prolog and let it run (slowly). Performance-related properties are important determinants of design. Carnegie Mellon University’s Acme-based performance analyzer uses stochastic models to calculate latency, throughput, and bottlenecks for systems that use asynchronous message passing. Aesop analyzes resource conflict, and checks scheduling feasibility. MetaH optimizes the generated glue code/middleware for each application, significantly reducing the time and space requirements for communication, dynamic reconfiguration, etc. It supports analyses of schedulability, reliability, and security.
Architecture (or architecture-centered systems) is key to DARPA’s Evolutionary Design of Complex Software (EDCS) concept of evolution. The ability to define and analyze system designs and to specify and analyze changes at the architecture level are important notions for evolution. In addition, the ability to evolve systems through generation and composition technologies based on architecture makes evolution more affordable and increases the confidence associated with system change.
Research is going on to improve our ability to represent, evaluate, and analyze architectures, and to use these architectures to generate or compose systems. Projects are attempting to identify and quantify the benefits provided by various architectural representations. We are emphasizing architectural languages and analysis tools that describe systems in terms of component interactions and legal and illegal sequences of events, as contrasted with more traditional design tools that emphasize component topology and configurations. The EDCS program is adding notions of constraints [4], dynamic configurations, and standard representation [5].
Medvidovic provides an excellent summary of language features. [12]
About the AuthorDr. John Salasin has conducted information processing research for his entire professional career -- on systems ranging in size from the encoder mechanism of a single cell in the Limulus (horseshoe crab) eye to the World Wide Military Command and Control (WWMCCS) system. His education includes a Ph.D. in Computer Science (1972), a M.S. in Neurophysiology (1969) from the University of Minnesota,, and a B.S. in Zoology from George Washington University (1964) |
Contact InformationDr. John SalasinDARPA / ITO 3701 North Fairfax Drive Arlington, VA [email protected] URL: www.darpa.mil/ |
 |
 |
 |