1. Architectural Mismatch

2. DAIMIHenrik Bærbak Christensen2 Literature [Bass et al. 2003] § 18 [Garlan et al., 1995] –Garlan, D., Allen, R., Ockerbloom, J. Architectural Mismatch or Why it’s hard to build systems out of existing parts. Proceedings of the Seventeenth International Conference on Software Engineering, Seattle WA, April 1995. [DeLine, 1999] –DeLine, R. A Catalog of Techniques for Resolving Packaging Mismatch. Proceedings of the 1999 symposium on Software reusability SSR'99. Los Angeles, California, United States. ACM Press 1999.

3. DAIMIHenrik Bærbak Christensen3 What is Reuse? Idea: Use existing software parts instead of building from scratch Simple, but elusive… Buy cheaper than build ! COTS: Commercial Off-The- Shelf Components

4. DAIMIHenrik Bærbak Christensen4 Lego bricks The Lego brick interface problem –it only works because knobs and holes fit together –... but we have to invent both the bricks, the knobs and the holes ! Component ZComponent YComponent X

5. DAIMIHenrik Bærbak Christensen5 Deutsch’s statement Interface design and functional factoring constitutes the key intellectual content of software and are far more difficult to create or re-create than code. Peter Deutsch Behaviour A1 C2Behaviour X Y Z Behaviour A B C More often than not, components appear like this…

6. DAIMIHenrik Bærbak Christensen6 Relations to QA An architecture defines resulting quality attributes… Thus, re-using any component X in an architecture will influence QAs! Example: –reusing public domain component may lower security because hackers have access to source code –interface mismatch handled by wrapping or bridging that costs performance

7. DAIMIHenrik Bærbak Christensen7 Architectural Mismatch The problems have a name: Architectural Mismatch Garlan et. al. ICSE-17, 1995. Problem: –Building Aesop an environment to support architectural design and analysis –Means: lower cost by reusing components OO database GUI toolkit event-based tool integration system remote procedure call system

8. DAIMIHenrik Bærbak Christensen8 Components Four public domain / commercial systems were chosen: –All in C++ or C –Source code available for all –Well-tested in many projects BUT: –no experience with making them work together

9. DAIMIHenrik Bærbak Christensen9 Architecture Deployment view: Components: OODB + GUI Connectors: RPC + Event mechanism

10. DAIMIHenrik Bærbak Christensen10 Problems After 5 man-years: –Excessive code size –Poor performance –Modifications to components necessary –Existing functionality had to be reinvented –Simple functionality had to be written in complex way –System construction (i.e. ”make”) error-prone I.e.: Reuse is elusive...

11. DAIMIHenrik Bærbak Christensen11 Architectural mismatch ”...all serious problems trace back to places where assumptions were in conflict.” Architectural mismatch categories: Failed assumptions on –Nature of components –Nature of connectors –Architectural style –Construction process

12. DAIMIHenrik Bærbak Christensen12 Assumptions: Component nature Three main areas –infrastructure – assumptions about how much support there is for the components in the environment –control model – assumptions about which components control the sequencing of computation –data model – assumptions about the way the environment will manipulate the data in a component

13. DAIMIHenrik Bærbak Christensen13 Assumptions: Connector nature Two main areas: –protocols – assumptions about the interaction patterns mediated through the connector –data model - assumptions about the kind of data that is communicated

14. DAIMIHenrik Bærbak Christensen14 Assumptions: Style Main area: –topology – assumptions about the topology of the system communications and about presence or absence of particular components and/or connectors.

15. DAIMIHenrik Bærbak Christensen15 Assumptions: Construction process Main area: –construction ordering – assumptions about the order in which pieces are instantiated and combined in an overall system

16. DAIMIHenrik Bærbak Christensen16 [Sidebar: Discussion] This is a classic example of the problems encountered when components from different (and unrelated) domains are broad together. Experience shows that the path to take is: To define not only the components but also the context these components must exist within! Product lines / Frameworks

17. DAIMIHenrik Bærbak Christensen17 But… What do you do when you have –Architecture X that is the one you must use ? –Element Y that is the component you must use ? You need techniques to handle mismatch…

18. DAIMIHenrik Bærbak Christensen18 Bass et al. What can we do? –[Avoid] Avoid it by specifying and inspecting components –[Detect] Detect cases that you have not avoided by qualification of components –[Repair] Repair detected cases by adapting components

19. DAIMIHenrik Bærbak Christensen19 Repair Three basic categories [see also DeLine] –Wrapping Adapter design pattern. Encapsulate component with adaptation code that makes it fit into architecture Example: X library running on Win32 –Bridging ‘Connector’ between components makes translation of data and control flow Example: PostScript to PDF converter –Mediator Planning and controlling component makes components cooperate [like Mediator design pattern]

20. DAIMIHenrik Bærbak Christensen20 Detecting Qualification means ‘fitness for use’. A component –provides services under some assumptions –assumes services under some assumptions Thus qualification is the process of clarifying and investigating these assumptions. Odds are that most are not documented! Typical process: –Making hypotheses and testing them using prototypes!

21. DAIMIHenrik Bærbak Christensen21 Avoiding Bass et al. devotes a section to ‘avoiding’ techniques. I think this is a rather academic discussion

22. DAIMIHenrik Bærbak Christensen22 Looking at Ensembles Bass et al. stress that components cannot be viewed in isolation. It is the ensemble of components for the architectural challenge at hand that must be qualified: In the end they have to work together for the system to make sense…

23. DAIMIHenrik Bærbak Christensen23 Exploration process Process [scientific ] –Model problem description of design context functionality spec and constraints QA specification –Model solution prototype situated in the design context –Evaluation criteria will solution be accepted or rejected Iterative process !

24. DAIMIHenrik Bærbak Christensen24 Case Study: ASEILM Example: –ChartWorks did not handle secure HTTP –Introduced PerlProxy as wrapper

25. DAIMIHenrik Bærbak Christensen25 DeLine: Package Mismatch In the spirit of design pattern catalogs DeLine wants to classify different techniques for resolving package mismatch Package mismatch: –any software component consists of two parts functionality provided (like e.g. spell checking) packaging provided (i.e. how to get access to the spell check)

26. DAIMIHenrik Bærbak Christensen26 Packaging aspects Data representation –must agree on sharing a common type system, agree on types agree on bit-level representation data item’s format and syntax Examples: –file formats –big-endian versus little-endian integer encoding Data representations may be lossy (e.g. jpeg)

27. DAIMIHenrik Bærbak Christensen27 Packing aspects Data and control transfer –must agree on direction and mechanism

28. DAIMIHenrik Bærbak Christensen28 Packing aspects Transfer protocol –agreement on the protocol for transferring data and control Examples: –HTTP, E-mail, FTP, etc. defines the interaction between client and server

29. DAIMIHenrik Bærbak Christensen29 Packaging aspects State persistence –agreement on how components maintains state between interactions Examples: –computational activities in health care in a pervasive computing environment –Java SessionBeans –Web Servers

30. DAIMIHenrik Bærbak Christensen30 Packaging aspects State scope –must agree on the scope of data that can be manipulated Examples: –’save’ in a document editor can only affect whole document, not a single page –Garlan et al. describe manipulation problems with InterView’s hierarchical structures

31. DAIMIHenrik Bærbak Christensen31 Packaging aspects Failure –must agree on degree of failure tolerance Examples: –method invocation is bullet proof within the same address space but remote method invocations easily fail.

32. DAIMIHenrik Bærbak Christensen32 Packaging aspects Connection establishment –must agree on how interaction mechanism are set up and torn down — and in what order Examples: –connection between component and a file interactive dialog? parameter? hard-coded name? –JHotDraw cannot handle images before its IconKit component is initialised which is done late. Thus you must code in a certain way if we need images ”early”