Home
A major challenge lying ahead is how to build dependable systems from existing undependable components and systems that were not originally designed to interact with each other. These components and systems might not provide access to their internal designs and implementations, and they can evolve independently of the overall system. Based on these limitations, the delivery of correct service, and the justification of this ability, has to be obtained from the interfaces and interactions of these components and systems. Architectural representations of systems are effective in understanding broader system concerns by abstracting away from system details, hence the trend for reasoning about dependability at the architectural level, rather than late in the development process.
The reasoning about dependability at the architectural level can be addressed from different perspectives.
- Architectural description languages, or a combination of different notations, can be employed for modelling systems' architectures in terms of their components and connectors, which might also include adaptors for preventing architectural mismatches.
- For the provision of assurances that indeed faults have been removed from the architectural representation, techniques like model checking and theorem provers are employed together with more traditional approaches, such as architectural inspections. Tests and fault injection are also performed to check whether the implementation fulfils the architectural specification.
- Since it is difficult to rid all the faults from a system, provisions have to be made at the architectural level to tolerate residual faults. However, to avoid increasing the architectural complexity of systems, abstractions are usually employed that incorporate fault-tolerant techniques.
- Architectural evaluation of systems should analyse the impact that architectural decisions might have upon system failure.