Software Architecture in Practice A few notes on H1

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 Bærbak Christensen2

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

Avoid Reinvented Wheels Bærbak Christensen4

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

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

Devil in Detail 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

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

Maps are for navigation Why call it Randers if it is Aarhus??? Bærbak Christensen9 Randers Århus

Noise! Keep Focus Document TM16. Not Broker! Bærbak Christensen10

Please contrast: Architecture – not implementation Bærbak Christensen11 Low level impl detail

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

Cross View Consistency 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?

Less is More Coarse grained map of everything – nice! Bærbak Christensen14

The Act of Balance Nice balance in abstraction… Bærbak Christensen15

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! Bærbak Christensen16

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

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 Bærbak Christensen18

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 Bærbak Christensen19 Ex: from POS

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… Bærbak Christensen20

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 Bærbak Christensen21

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