1. Software Architecture in Practice A few notes on H1

2. Overall Good efforts and hard work on applying the techniques Lots of critique in the details ”Why do we fall, Master Wayne? – So we can learn to pick ourselves up.” –Alfred, in the Batman movie CS@AUHenrik Bærbak Christensen2

3. ”High Disregard of Originality!” CS@AUHenrik Bærbak Christensen3 Home made notation for a package (and WRONG by the way)

4. Avoid Reinvented Wheels CS@AUHenrik Bærbak Christensen4

5. UML Syntax means Something Does Spark-java really spawn a new thread for every request? –|| :object ||means a thread/process CS@AUHenrik Bærbak Christensen5

6. UML Syntax The Syntax is there to mean something, not for the teacher to whack you over the head! CS@AUHenrik Bærbak Christensen6 Broker depends on Client!

7. Devil in Detail CS@AUHenrik Bærbak Christensen7 Method ‘command’ is called ‘command’ is called, but asynchroneous Method does not return, but makes a backcall asynchroneous So – authors have expressed complex sequencing? Or just been sloppy in their making of this diagram? Numbers? Undefined in Seq Diagrams

8. Naming! How can I find Magnus if you call him Pernille? CS@AUHenrik Bærbak Christensen8 cs.saip.appserver?

9. Maps are for navigation Why call it Randers if it is Aarhus??? CS@AUHenrik Bærbak Christensen9 Randers Århus

10. Noise! Keep Focus Document TM16. Not Broker! CS@AUHenrik Bærbak Christensen10

11. Please contrast: Architecture – not implementation CS@AUHenrik Bærbak Christensen11 Low level impl detail

12. Architecture is NOT… Architecture is abstraction Abstraction = Reality, irrelevant details removed! Abstraction ≠ Something completely different CS@AUHenrik Bærbak Christensen12 Exercise: Why is this wrong?

13. Cross View Consistency CS@AUHenrik Bærbak Christensen13 If called X in CC then why call it Y in Deploy view? How can I map between views? If called X in CC then why call it Y in Deploy view? How can I map between views?

14. Less is More Coarse grained map of everything – nice! CS@AUHenrik Bærbak Christensen14

15. The Act of Balance Nice balance in abstraction… CS@AUHenrik Bærbak Christensen15

16. What is Broker, anyway? In several hand-ins I object that Broker is not architectural Please disregard that statement! Broker greatly influence modifiability with respect to –Marshaling format –Choice of IPC Other IPC choices may again influence –Performance (?) + Availability (!) E.g. a MQ solution as IPC Conclusion: Broker influences architecture a lot! CS@AUHenrik Bærbak Christensen16

17. But… Still, all the gory details of Broker is way too much implementation, and way too little architecture CS@AUHenrik Bærbak Christensen17

18. Broker is a Connector I would view Broker pattern as a Connector Connector: Broker –Broker pattern implements remote method invocation –Using HTTP as IPC JSON as marshalling format CS@AUHenrik Bærbak Christensen18

19. Responsibilities Generally you all do a fine job stating the responsibilities of the elements –Less so on relations And some forget all together –Shame on you CS@AUHenrik Bærbak Christensen19 Ex: from POS

20. Concluding Remarks Architecture = Abstraction Question: What to abstract and what not? Architecture = decisions that influence QA –Builder does not really Implementation detail as HL7 format is fixed… CS@AUHenrik Bærbak Christensen20

21. Concluding Remarks Documentation is generally –Not very sexy –Easily gets out-of-date –Done infinitely close to ‘never’ –Falls for the ‘criticized for incorrectness’ trap My best advice –Less is more I am more inclined to actually do it. Little is better than nothing –”Keep it abstract, but not too abstract” Avoids constant required modifications CS@AUHenrik Bærbak Christensen21

22. Until next time H2 continues in the same report template. Thus – Adjust to my (hardest) comments in the next delivery CS@AUHenrik Bærbak Christensen22