1. Logical architecture refinement

2. Background information
Formal verification methods based on theorem proving techniques and model­checking
to prove the absence of errors (in the formal model)
to reason about the behaviors of programs
No known generic software verification
Involves complicated proving
Generally cannot be easily and cost-effectively integrated to software and hardware development cycles

3. Major Verification Topics
Specification Verification
Architecture Verification
General practical issues

4. Architecture Verification
Correctness of architecture refinement
a methodology for the correct stepwise refinement of software architectures
using the approach of architecture refinement patterns that are correctness preserving and compositional

5. Common architecture Issues
From abstract level to concrete level
Simple architecture: box - arrows, representing data component and connections
Large architecture: Hierarchical approach

6. Common architecture problem
Limited utility of architecture hierarchy results from the current level of informality
Ambiguity in architecture allows unintended interpretations. May cause erroneous interrepretation

7. Architecture Refinement
From a abstract architecture to a concrete (lower-level) architecture
lead to:
fewer architectural design errors
extensive and systematic reuse of design knowledge and proofs

8. Refinement pattern approach
A pair architecture schemas (homogenous or heterogeneous)
proven to be relatively correct with respect to the given mapping schema

9. Refinement pattern Requires a special correctness criterion
a special mapping between architectures
extensive translation:
the representation of components, interfaces, and connections
aggregated, decomposed, or eliminated

10. Completeness assumption
Prove that a concrete architecture has all required properties
No new properties can be inferred from the concrete architecture
All components, interfaces, and connections intended to be true of the architecture at its level of detail
If a fact is not explicit in the architecture, assume that it is not intended to be true

11. Completeness assumption
Standard way to proof relative correctness
show that the concrete specification logically implies the abstract specification under a given mapping
allow additional and specified behaviors, as long as the specified behavior is implemented
no guarantee that negative properties are preserved under refinement
Alternative:
faithful interpretation
hard and no general proof technique
Use preproved refinement patterns

12. Example Use only logical theories for simplicity
To show how to systematically and incrementally transform a abstract architecture to its lower-level form
Approach: combining small and local refinement to form the larger composite

13. Example Lexical Analyzer Lexical Parser Analyzer Optimizer
toks
ast
ast
Lexical Parser
Analyzer Optimizer
Code Generator
chars
code
bindings

14. Example: abstract sub-architecture to concrete sub-architecture
Lexical Parser
ast
Analyzer Optimizer
From simple dataflow to shared syntax tree:

15. Architecture as Theories
Architecture Styles
Operations & axioms
Translation to Logic
Patterns  logic (theory generation rules)
Mapping
Name mapping
Style mapping
Interpretation mapping

16. Architecture styles Dataflow style:
Axioms example -- Every function must at least have one port:

17. Translation to Logic An instance of function declaration schema:
f: Functional_Style!Function [  op: t]
The underlying theory contains the same instance of first order sentences:

18. Mapping Name mapping: Style mapping:
c | m
op | w
Style mapping:
Accepts (_, _) | Gets (_, _)
Connects (_, _, _) | Writes (_,_) ^ Reads(_,_)
Interpretation mapping = name + style mapping

19. Proving
Criterion
all intended to do
not intended to do

20. Composition Horizontal Vertical
compose instances of refinement patterns to form one large composite refinement
Vertical
most concrete architecture in a hierarchy is correct with respect to the most abstract
justified since faithful interpretation is transitive

21. problem example Concrete architecture 1 Concrete architecture 2
A  B (dataflow connection)
Concrete architecture 2
B  C (dataflow connection)
the composition of 1 and 2 is not faithful!
need new abstract dataflow from A to C

22. Specification Correctness issue
Complete specification of program is in terms of hierarchical structure of module specifications
Module external specification are abstract, about module behavior
Module internal specifications are descriptions of internal implementations

23. Concurrent System Verification
Program is a set of events
Interpreted and verified with a formal proof system
Internal specification classified as composite or simple
Composite: composed of linked sub-modules, each with external and internal specification

24. External Specification
External specification consist of three parts:
behavior: module delivers to the environment
provide: how modules synchronizes with the environment
require: synchronization cooperation the module expects from environment

25. Composite internal specification
Internal specification of a composite module associates events described in the external specification of the module with events described in the external specifications of the sub-modules.
Ports: a set of single direction communication channels between the module and its environment
Network link: sub module ports are connected together to form communication channels

26. Composite module verification
Verification of composite module:
1. External behaviors of the sub-modules plus the network and interface links must imply the external behavior of composite module
2. Provides and requires of the sub modules and composite module must be mutually supportive and complete.
“mutual support: sub module provides imply the sub- module requires.
“ complete:composite require and provide represent the sub module requires and provides accurately and completely.

27. Composite module

28. Simple module specification verification
Internal specification of a simple consists of three parts:
program: internal specification as example
performance: whether the program is cyclic or terminates and contains an assert statement that describe the history
interpret: identify ports with subsequences on the history

29. Simple module internal specs

30. Simple module specification verification
Verification of specifications of a simple module:
1. Performance and interpret statements must imply the external behavior
2. Performance and external provide must be established using following axioms :
History Sequence Axiom
Statement block Axiom
Process history Axiom