1. Software Architecture in Practice Architectural Prototyping

2. Patterns and Tactics … However, what do we do when... –we are uncertain whether one or the other style / pattern / tactic is the better to choose? –when we are uncertain whether the favourite architecture will have the right balance of conflicting quality attributes? –when we are uncertain that the specs of the third party vendor are real and not just empty sales talk? –when we want to explore the design space for learning – and becoming better architects? CS@AUHenrik B Christensen2

3. 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.” CS@AUHenrik B Christensen3

4. Prototyping Prototyping has mainly been used in the user interface community –“the discussion focuses on software intended as direct support for human work.” But why is building executable systems that involve an early practical demonstration of relevant parts of the desired software only interesting for HCI folks? Why not for software architects? CS@AUHenrik B Christensen4

5. So – what is an architectural prototype? Definition: 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. Bardram, Christensen, Hansen: WICSA 2004 CS@AUHenrik B Christensen5

6. Characteristics –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. CS@AUHenrik B Christensen6

7. No functionality –architectural prototypes do not provide functionality per se. I.e. no business logic and no user interface Example: Performance –Pump data from one end to the other fast enough –Simulate “business algorithms” by delays Example: Availability –Measure ‘reintroduction’ time but no real functionality CS@AUHenrik B Christensen7

8. Classes of APs Explorative –Constructed in order to explore design space Experimental –Constructed in order to evaluate specific architectural decisions, typically trade-offs between qualities Evolutionary –Constructed one after another to produce a skeletal system CS@AUHenrik B Christensen8

9. Example 1: Performance Media Content Browser: The best architecture? –Require High fidelity user experience Qualities: performance (response time!), availability (power management), reliability (survive out-of-range, etc.)… A performance verifying AP: –Dummy components sending 50KByte data chunks over real connectors –Measure round-trip times –No need for GUI nor real album data CS@AUHenrik B Christensen9

10. Discussion How can the Media Content Browser AP –Reduce risk? –Evaluate balance between QAs? –Ensure knowledge transfer of the architecture? CS@AUHenrik B Christensen10

11. Example 2: Net4Care AP06 Net4Care: Support telemedicin for SMBs –Questions: Is Forwarder/Receiver a solid communication pattern? Is KronikerDataSet a solid foundation as storage format? Is BaseX a solid database system? Is a compositional Observation flexible enough? Is a manual serialization method easy enough? AP06: –End-to-end testing (very similar to TM16) –Crude GUI, no error handling,... Total staff hours: 23.5 hours CS@AUHenrik B Christensen11

12. Example 2: Net4Care AP06 Net4Care: Support telemedicin for SMBs The output –Questions: Is Forwarder/Receiver a solid communication pattern? Is KronikerDataSet a solid foundation as storage format? Is BaseX a solid database system? Is a compositional Observation flexible enough? Is a manual serialization method easy enough? CS@AUHenrik B Christensen12

13. Anatomy of an AP So – how do we code them?

14. Keypoints Some key goals dictate how to code them –Potentially evolutionary prototype which will transition into the real system: produce high quality code!!! –Answers an architectural question (hypothesis) and nothing else: include only enough code to answer the question! –The found answer must be applicable to the target system: the code context must be ”true” to the target system –The answer must be found quickly: the development process must be fast, code should be minimized CS@AUHenrik B Christensen14

15. Key techniques Techniques/tactics to achieve this are –Modifiability tactics Semantic coherence + defer binding times –Testability tactics Separate interface from implementation (In PaSOOS terms...) –Flexible design (Gamma et al. §1.6/Christensen §16) Encapsulate what varies, program to interface, favour object composition –Test doubles (Meszaros (online)/Christensen § 12) Test stubs, fake objects –Fake it ‘till you make it (Beck / Christensen §5) CS@AUHenrik B Christensen15

16. Example 3: Net4Care AP09 Questions –Generate HL7 –Encapsulate XDS –Reflective serialization CS@AUHenrik B Christensen16 Semantic Coherence: Well-defined Services

17. Christensen: 3-1-2 Encapsulate what varies –We need to store and query from XDS –We need to vary which XDS to interact with Program to an Interface –public interface XDSRepository Favour object composition CS@AUHenrik B Christensen17

18. FakeObject implementation...and not much more... CS@AUHenrik B Christensen18

19. AP09: Key coding goals Key goals –produce high quality code!!! Strong semantic coherence / encapulation of core services –include only enough code to answer the question! FakeObject impl of XDS as this was not the question! –the code context must be ”true” to the target system The XDSRepository interface is defined after carefull inspection of the IHE profiles to ensure the interface is correct! –the development process must be fast, code should be minimized FakeObjects require no setup (DB start, rollback, etc.) CS@AUHenrik B Christensen19

20. AP09: A full end-to-end test CS@AUHenrik B Christensen20

21. AP09 output Questions –Generate HL7 A PHMRBuilder class impl and verified –Learned about PHMR format –Fed back on the type of data the client must know! –Encapsulate XDS Yes –Reflective serialization Experiment with JacksonSerializer... CS@AUHenrik B Christensen21

22. Example: Fast AP implementation From TM16 –What does it do? –How long time does it take to start a server? CS@AUHenrik B Christensen22

23. Another player of the role... CS@AUHenrik B Christensen23

24. What are the risks of APs? Describe some scenarios in which the use of an AP gives us the wrong answers Ex –AP says “It will perform OK” but in reality it does not –AP says “Availability is OK” but it is not –Etc. CS@AUHenrik B Christensen24

25. Summary AP is one of the architect’s tools to verify architectural designs APs are good when we are uncertain –Explore new tactics, learn as architects –Experiment with tradeoffs between Qas CS@AUHenrik B Christensen25

26. Summary APs require a good programming toolbox –Strong focus on variability and semantic coherence ‘roles, responsibilities, and behaviour’ –Strong focus on test doubles –Coding practices - Agile development –speed+quality –keep focus –stay true to context AP validated hypotheses live on in new evolutionary APs –Coming up next: AP processes... CS@AUHenrik B Christensen26