1. DAIMIHenrik Bærbak Christensen1 Architectural Design Tactics, Patterns Prototyping

2. DAIMIHenrik Bærbak Christensen2 A Simplified Development Process ?

3. DAIMIHenrik Bærbak Christensen3 Architectural Design The process of designing a software architecture that meets quality attribute requirements –And enables implementation of functional requirements Characteristics of the process –Creative –Iterative (and incremental) Functional decomposition Quality decomposition –Experimental Architectural Prototyping –Based on experience Styles/architectural patterns Tactics

4. DAIMIHenrik Bærbak Christensen4 Quality-Based Design Need basic architectural qualities –Conceptual integrity –Correctness and completeness –Buildability Enable required system quality attributes –… and business qualities

5. DAIMIHenrik Bærbak Christensen5 Tactics

6. DAIMIHenrik Bærbak Christensen6 Literature [Bass et al., 2003] §5, 7 [Bardram et al., 2004] [Bass et al., 2003] §6, 8. (cursory)

7. DAIMIHenrik Bærbak Christensen7 Architectural Tactics Tactic –A design decision that influences the control of a quality attribute response –E.g., Heartbeat to control availability Architectural strategy –Collection of tactics Characteristics –Capture what architects do in practice –Tactics may refine other tactics –Tactics may influence more than one quality attribute Since quality attributes are interdependent

8. DAIMIHenrik Bærbak Christensen8 Categories of Tactics Classified according to (main) quality attribute concern –Availability –Modifiability –Performance –Security –Testability –Usability

9. DAIMIHenrik Bærbak Christensen9 Availability Tactics (1)

10. DAIMIHenrik Bærbak Christensen10 Availability Tactics (2) Fault detection –Ping/echo One component pings Expects response within predefined time –Heartbeat (dead man timer) One component emits heartbeat message periodically Other components listen for it –Exceptions Raise exception when fault class is encountered Omission, crash, timing, response fault Fault recovery – repair –Voting Redundant processes and processors Voter process check responses – fail if deviant –Active redundancy (hot restart) Maintain redundant, parallel components Only use one response –Passive redundancy (warm restart) Primary component responds, informs standbys of updates to make Resume standby if primary fails –Spare Standby computing platform Boot and initialize state when needed Fault recovery – reintroduction –Shadow operation Previously failed component runs in “shadow mode” Restore when sure that it works –State resynchronization Redundancy requires restoring after downtime –Checkpoint/rollback Create checkpoint recording consistent state at points in time Rollback to previous checkpoint if inconsistent state detected Fault prevention –Removal from service (Periodically) remove component to prevent anticipated failure –Transactions Bundling sequential steps Undo all if necessary

11. DAIMIHenrik Bærbak Christensen11 Modifiability Tactics (1)

12. DAIMIHenrik Bærbak Christensen12 Modifiability Tactics (2) Assumption –Restricting modifications to small set of module will reduce cost of change Localize changes –Semantic coherence Ensure responsibilities of a module are coherent Low coupling + high coherence + measured against scenarios of change –Anticipate expected changes Make decomposition so that considered changes affect minimal number of modules Based on assumptions of what changes will be –Generalize module Make module compute broader range of functions E.g., constants -> input parameters –Limit possible options Reduce options for modifications Prevention of ripple effect –Hide information Decompose responsibilities Choose which to make public, hide others –Maintain existing interface Mask variations –Restricts communication paths Restrict the number of module with which a component shares data –Use an intermediary Create module handling dependencies between components (e.g., Adapter) Defer binding time –Runtime registration –Configuration files –Polymorphism –Component replacement –Adherence to defined protocols

13. DAIMIHenrik Bærbak Christensen13 Performance Tactics (1)

14. DAIMIHenrik Bærbak Christensen14 Security Tactics

15. DAIMIHenrik Bærbak Christensen15 Testability Tactics

16. DAIMIHenrik Bærbak Christensen16 Usability Tactics

17. DAIMIHenrik Bærbak Christensen17 Discussion Tactics help make quality attribute decisions –Does it make sense to divide tactics according to quality attributes – cf. interdependence? Do tactics make sense regardless of domain? Are the tactics really just design ideas? –Cf. patterns…

18. DAIMIHenrik Bærbak Christensen18 Styles / Architectural Patterns

19. DAIMIHenrik Bærbak Christensen19 Literature POSA books: Patterns of Software Architecture.

20. DAIMIHenrik Bærbak Christensen20 Patterns The design pattern community has made a great impact on software engineering. Design pattern: A solution to a problem in a context Architectural patterns (or styles) in the same manner defines a solution to an architectural problem in a given context.

21. DAIMIHenrik Bærbak Christensen21 Architectural pattern is determined by –a set of element types e.g. server, data repository, memory, function –a topology: layout of elements and relations e.g. one server connects multiple clients –a set of semantic constraints e.g. clients are stateless, server contains state, –a set of interaction mechanisms e.g. protocols for communication between server and clients

22. DAIMIHenrik Bærbak Christensen22 Example MVC –Model-View-Control Architectural pattern –Name: MVC –Problem: Structuring graphical applications –Solution: should be known –Consequences: should be known Literature: –Pattern-Oriented Software Architecture Buschmann, Meunier, Rohnert, Sommerlad, Stal, Wiley 1996.

23. DAIMIHenrik Bærbak Christensen23 Structure:

24. DAIMIHenrik Bærbak Christensen24 CRC: Model

25. DAIMIHenrik Bærbak Christensen25 CRC: View

26. DAIMIHenrik Bærbak Christensen26 CRC: Controller

27. DAIMIHenrik Bærbak Christensen27 Dynamics

28. DAIMIHenrik Bærbak Christensen28 Conclusion More concrete than tactics –may involve severat tactics Lot of ’best practices’ to draw upon –the POSA books –Shaw and Garlan 1995 Inspiration and templates May be combined –heterogeneous styles

29. DAIMIHenrik Bærbak Christensen29 Architectural Prototyping When in doubt, what do we do ?

30. DAIMIHenrik Bærbak Christensen30 Literature [Bardram et al., 2004] –Bardram, J., Christensen, H. B., and Hansen, K. M. (2004). Architectural Prototyping: An Approach for Grounding Architectural Design and Learning. In Proceedings of the 4th Working IEEE/IFIP Conference on Software Architecture (WICSA 2004), pages 15–24, Oslo, Norway

31. DAIMIHenrik Bærbak Christensen31 Prototyping? Executable systems that “involve an early practical demonstration of relevant parts of the desired software”.

32. DAIMIHenrik Bærbak Christensen32 A Metaphor (1) Mars Global Surveyor Mars Orbiter Camera Reality from a distance… Nirgal Vallis

33. DAIMIHenrik Bærbak Christensen33 A Metaphor (2) Mars Exploration Rover Mission –Opportunity Reality close up –Nothing beats being there… Endurance Crater

34. DAIMIHenrik Bærbak Christensen34 The Point Building a new large scale software system is like boldly venturing into unexplored territory… The architecture is one of the great unknowns… Powerful analysis methods exists – looking a the architecture from a distance… … but nothing beats being there – to see the architecture execute …

35. DAIMIHenrik Bærbak Christensen35 So – What is an Architectural Prototype? An architectural prototype consists of a set of executables created to investigate architectural qualities related to concerns raised by stakeholders of a system under development Architectural prototyping is the process of designing, building, and evaluating architectural prototypes.

36. DAIMIHenrik Bærbak Christensen36 Example (Ongoing Work) Palpable Computing Project (EU project) –Open architecture for “next generation pervasive computing” Connectivity Scenario GPRS Bluetooth USB Web Server Web Browser

37. DAIMIHenrik Bærbak Christensen37 Example Continued Failure situation is difficult to diagnose  Scenario as case for Palpable Computing –But how to research the architectural design space? ? GPRS Bluetooth USB Web Server Web Browser ? ? ? ?

38. DAIMIHenrik Bærbak Christensen38 Design Space Approach 1: –Hook into existing technology Windows explorer, socket API, Bluetooth stack, mobile phone, … –Problems Costly in terms of technical challenges, resources Focus often far from architectural issues Not looking forward towards new solutions Approach 2: –Architectural prototyping…

39. DAIMIHenrik Bærbak Christensen39 Architectural Challenge? What is the architectural challenge of scenario? –Dataflow Bi-directional byte streams –Components: Laptop web client, mobile phone, Bluetooth dongle, web servers –Connectors Sockets over different transport media: Bluetooth, GPRS, wire Irrelevant –HTTP, HTML, GUI, …

40. DAIMIHenrik Bærbak Christensen40 Connectivity Architectural Prototype Approach: AP –Step 1: Build simulator – sockets, components GUI representing mobile phone allows simulating turning off the phone; GUI representing GSM connection allows slow connection and high charges compared to GPRS connection; etc. –Step 2: Experiment with failure diagnostics on top A: model-building B: exception mechanisms C: ???

41. DAIMIHenrik Bærbak Christensen41 Main advantages The advantages of AP approach –Inspiration flows from work at the code level –“Cheap” in resources / man hours –Any failure condition can be simulated –Basis for experimentation with different approaches for “palpable failure handling” –Open for introducing new ideas into, say, the mobile phone component without asking Nokia, etc… (Dangers… ) –Have to ground simulator in real technology… –Requires fidelity The extent to which the prototype give same responses to stimuli as final system

42. DAIMIHenrik Bærbak Christensen42 Prototyping Seminal paper by Floyd [1984]. –executable systems that “involve an early practical demonstration of relevant parts of the desired software”. –“a learning vehicle providing more precise ideas about what the target system should be like.” –“the discussion focuses on software intended as direct support for human work.”

43. DAIMIHenrik Bærbak Christensen43 Characteristics of Architectural Prototypes –Architectural prototypes are constructed for exploration and learning of the architectural design space. –Architectural prototyping addresses issues regarding architectural quality attributes in the target system. –Architectural prototypes do not provide functionality per se. –Architectural prototypes typically address architectural risks. –Architectural prototypes address the problem of knowledge transfer and architectural conformance.

44. DAIMIHenrik Bærbak Christensen44 Case Studies The paper discusses three case studies –Closed-loop process control Embedded real-time engine control QA: performance and modifiability –Dragon project Customer service system for globally distributed shipping company QA: buildability, modifiability, integrability –Activity Based Computing project Research in pervasive healthcare QA: portability, pervasiveness

45. DAIMIHenrik Bærbak Christensen45 Classification Two basic types of architectural prototypes –Exploratory prototypes Clarify architectural requirements with stakeholders Explore aspects of target system Discuss alternative solutions –Experimental prototypes Gauge adequacy of proposed architecture Quantitative measurements of quality attributes like performance i.e., finding proposals i.e., evaluating proposals

46. DAIMIHenrik Bærbak Christensen46 In the Development Process Architectural prototyping is useful in various phases of software development Take (Rational) Unified Process as an example –Process framework –Able to model agile as well as traditional processes

47. DAIMIHenrik Bærbak Christensen47 Architectural Prototyping and Phases Inception –Understanding what to build –Focus on major risks and qualities that are essential to whether the system should be built – exploratory architectural prototypes Elaboration –Understanding how to build it –Experimental prototypes may play major role –“Skeletal system” as goal Construction –Incrementally building a complete system –Investigating detailed architectural concerns, experimenting with new architectural requirements Transition –Building the final version of a system –(Most useful if transition results in new cycles of phases)

48. DAIMIHenrik Bærbak Christensen48 Discussion The concept “Prototype” in architecture –Executable architectural prototype [RUP] eliminate major risks, skeletal systems supporting incremental construction of system –Skeletal system [Bass et al., 2003] Once an architecture is sufficiently designed […], a skeletal system can be constructed. That is – emphasis on skeletal system to grow in the construction phase… In contrast, APs are proposed as learning vehicles and technique also in the analysis phase… Mostly for behavioral qualities?