From Dependable Architectures To Dependable Systems

1. From Dependable ArchitecturesTo Dependable Systems Nenad Medvidovic Center for Systems and Software EngineeringComputer Science DepartmentViterbi School of EngineeringUniversity of Southern CaliforniaLos Angeles, U.S.A.neno@usc.edu

2. Goals of the Talk • Identify some challenges • Suggest some solutions • Motivate future research • Invite dissenting opinions

3. Goals of the Talk The problem is this bigand sometimes ill-defined

4. Goals of the Talk I will talk to youabout this much of it

5. Goals of the Talk I will suggest a solutionfor this much of it

6. But, hopefully, we will havethis much fun! Goals of the Talk

7. What Is Dependability? • Degree of user confidence that the system will operate as expected • Key dimensions • Availability • Reliability • Security • Safety • But also • Repairability • Maintainability • Survivability • Fault tolerance

8. What Is Architecture? • A high-level model of a system • The system’s “blueprint” • Represents system organization • Data • Computation • Interaction • Structure • Embodies system properties • Communication integrity, performance, throughput, liveness, . . . • Can/does it embody dependability? • (how) Can those properties be transferred to the system itself?

9. A “Traditional” Architectural Model

10. A “Traditional” Architectural Model What/where is the dependability?

11. A “Standard” Architectural Model

12. A “Standard” Architectural Model

13. A “Standard” Architectural Model What/where is the dependability?

14. But, We Can Model Anything • Meta-H, ROOM, UniCon, etc. can help ensure real-time properties in models • Markov chains can help ensure reliability in models • Multi-versioning connectors can help ensure fault tolerance • Code/data mobility and replication formalisms can help ensure availability • . . .

15. But, We Can Model Anything • Meta-H, ROOM, UniCon, etc. can help ensure real-time properties in models • Markov chains can help ensure reliability in models • Multi-versioning connectors can help ensure fault tolerance • Code/data mobility and replication formalisms can help ensure availability • . . . So then the problem is solved, right?

16. Why the Problem Isn’t Solved

17. Why the Problem Isn’t Solved Architecture (ADL)

18. Why the Problem Isn’t Solved Architecture (ADL) Design (UML)

19. Why the Problem Isn’t Solved Architecture (ADL) Design (UML) Java Java Beans Visual Basic D/COM Implementation Object-Oriented Programming Language (OOPL) CORBA (middleware, bus C++ JEDI technolgies) C2

20. Why the Problem Isn’t Solved

21. Why the Problem Isn’t Solved W

22. Why the Problem Isn’t Solved W W2 W1 W3

23. Why the Problem Isn’t Solved W W2 W1 W3 W21 W13 W11 W31 W12 W22 Q

24. From Models to Systems

25. From Models to Systems

26. From Models to Systems

27. The remainder of this talk will focus on two key questions:

28. 1. How do we get from

29. 1. How do we get from and

30. 1. How do we get from to and

31. 1. How do we get from to and to ?

32. 2. How do we know

33. 2. How do we know

34. 2. How do we know is “better” than ?

35. Outline • From architectures to systems • Ensuring dependability • Problem definition • Proposed solution • Concluding remarks

36. Outline • From architectures to systems • Ensuring dependability • Problem definition • Proposed solution • Concluding remarks

37. How Do I Dependably Implement an Architecture? • Architectures provide high-level concepts • Components, connectors, ports, events, configurations • Programming languages provide low-level constructs • Variables, arrays, pointers, procedures, objects • Bridging the two often is an art-form • Middleware can help “split the difference” • Existing middleware technologies • Support some architectural concepts (e.g., components, events) • but not others (e.g., connectors, configurations) • Impose particular architectural styles

38. How Do I Dependably Implement an Architecture? • Architectures provide high-level concepts • Components, connectors, ports, events, configurations • Programming languages provide low-level constructs • Variables, arrays, pointers, procedures, objects • Bridging the two often is an art-form • Middleware can help “split the difference” • Existing middleware technologies • Support some architectural concepts (e.g., components, events) • but not others (e.g., connectors, configurations) • Impose particular architectural styles What is needed is “architectural middleware”

39. Architectural Middleware • Natively support architectural concepts as middleware constructs • Include system design support • Typically via an accompanying ADL and analysis tools • May support explicit architectural styles • Support round-trip development • From architecture to implementation and back • Support automated transformation of architectural models to implementations • i.e., dependable implementation • Examples • ArchJava • Aura • c2.fw • Prism-MW

40. Dependable Implementation Architecture (ADL) Design (UML) Java Java Beans Visual Basic D/COM Implementation Object-Oriented Programming Language (OOPL) CORBA (middleware, bus C++ JEDI technolgies) C2

41. Dependable Implementation Architecture (ADL) Java Java Beans Visual Basic D/COM Implementation Object-Oriented Programming Language (OOPL) CORBA (middleware, bus C++ JEDI technolgies) C2

42. Dependable Implementation Architecture (ADL) Java Java Beans Visual Basic D/COM Implementation Object-Oriented Programming Language (OOPL) CORBA (middleware, bus C++ JEDI technolgies) C2

43. Example: Prism-MW

44. Example: Prism-MW

45. Example: Prism-MW

46. Example: Prism-MW

47. Example: Prism-MW

48. Example: Prism-MW

49. Using Prism-MW

50. Using Prism-MW class DemoArch { static public void main(String argv[]) { Architecture arch = new Architecture ("DEMO"); Architecture - DEMO