1. Architectural Transformations Architectural Transformations Vincenzo Ambriola Alina Kmiecik Javier Reyes COMP 685 Professor Lingard Fall 2007

2. Introduction The software development process can be described as a set of transformations that convert less specified documents and diagrams into more formal and detailed ones.

3. Architectural transformations change the software structure and directly influence system properties like quality and functionality. They construct the software architecture, which is the input of the next development stage. They can provide good mechanisms for early- stage software quality management because of their influence on software quality.

4. It can decrease software production costs and speed up time-to-market. Makes software architect responsible not only for functional decomposition, but also for non- functional requirements fulfillment.

5. Architectural Transformations There are two general groups of transformations: for change and for explanatory purposes. Change transformations are used to modify and improve the software architecture. Explanatory purposes transformations are applied for architecture analysis and understanding.

6. Change Transformations The software architect can use several transformations to improve a software architecture. They can be classified into three groups: highest level transformations middle level transformations lowest level transformations

7. At a first glance this classification seems to separate operations performed at particular levels of the structure and suggests that they are independent. Transformations applied in one diagram force changes to upper and lower levels of the structure.

8. Architecture Description Language It is impossible to provide any analysis or architectural change without adopting a formal architecture representation. Almost every ADL concentrates on some particular aspects of software architecture and it is not easy to find a language that can represent all architectural perspectives.

9. Architectural transformations cannot be defined before all nuances of the software architecture are well described in a unified and formalized manner.

10. UML is a description language on its own, but it cannot model every feature of a software architecture. UML is more popular than any ADL and is used during software development from early phases to detailed design.

11. Performing or even presenting the results of architectural transformations in UML would make them comprehensible to everyone, not only to the specialists acquainted with a specific description language. For this reason it is worth to look for a description language integrated with UML, which closes the gap between architectural design and other development stages.

12. Non-functional requirements vs. software architecture Nonfunctional requirements refer to the whole software and thus they cannot be presented in software architecture as components or functions offered by the system, as it is the case with functional requirements. Non-functional requirements determine the architectural style and influence software structure and system properties.

13. Software architecture drives the quality characteristics of the system which are the measure aspects for non-functional requirements satisfaction.

14. Architectural Styles Architectural styles influence the frequency and the number of links between components, and force some implementation solutions like component replication and data access.

15. Process Automation An automation mechanism could be provided to perform architectural transformations. An automation mechanism could be provided to perform architectural transformations.

17. Software Architecture Transformation Jan Bosch Professor of Software Engineering University of Groningen, Netherlands Jan.Bosch@cs.rug.nl http://www.cs.rug.nl/~bosch Copyright © 2001 Jan Bosch

18. Overview ARCS/ADM requirement specification functionality-based architectural design application architecture OK architecture assessment QA optimizing solutions architecture transformation not OK FR QR

19. Method three main phases: functionality-based design functionality-based design assessment of QAs assessment of QAs architecture transformation architecture transformation

20. Architecture Transformation architecture transformation process: architecture transformation process: identify unfulfilled quality attributes identify unfulfilled quality attributes for each quality attribute for each quality attribute identify locations where QA is inhibited identify locations where QA is inhibited select the most appropriate transformation select the most appropriate transformation perform the transformation on the architecture perform the transformation on the architecture

21. Architecture Transformation transformations (primarily) change the structure of the architecture transformations (primarily) change the structure of the architecture affect quality attributes, but not application domain functionality affect quality attributes, but not application domain functionality

22. Architecture Transformation transformation techniques transformation techniques impose architectural style impose architectural style impose architectural pattern impose architectural pattern apply design pattern apply design pattern convert QR to functionality convert QR to functionality

23. Example: Fire Alarm System

24. Impose Architectural Style reorganize functionality according to architectural style reorganize functionality according to architectural style architectural style predominant in (sub)system architectural style predominant in (sub)system each style has an associated suitability for different QAs each style has an associated suitability for different QAs example example layered architecture for HW dependent and independent functionality layered architecture for HW dependent and independent functionality blackboard in fire-alarm system blackboard in fire-alarm system

25. Impose Architectural Style pipes and filters pipes and filters layers layers blackboard blackboard object-orientation object-orientation implicit invocation implicit invocation performance maintainability reliability safety security

26. Example

27. Impose Architectural Pattern not predominant, but affects complete (sub)system not predominant, but affects complete (sub)system deals with aspects of a system (AOP), e.g. concurrency, distribution deals with aspects of a system (AOP), e.g. concurrency, distribution example example concurrency, e.g. periodic objects concurrency, e.g. periodic objects transaction management transaction management

28. Impose Architectural Pattern concurrency concurrency operating system processes operating system processes operating system threads operating system threads non-preemptive threads non-preemptive threads application-level scheduler application-level scheduler persistence persistence database management system database management system application-level persistence and transaction handling application-level persistence and transaction handling

29. Impose Architectural Pattern distribution distribution brokers brokers remote method invocation remote method invocation graphical user interface graphical user interface model-view-controller model-view-controller presentation-abstraction-control presentation-abstraction-control

30. Example

31. Apply Design Pattern affects a limited number of classes affects a limited number of classes traditionally focussed on development QAs, e.g. flexibility and reusability (now extending) traditionally focussed on development QAs, e.g. flexibility and reusability (now extending) example example strategy pattern (flexibility ++, performance --) strategy pattern (flexibility ++, performance --) abstract factory (extensibility++, performance-) abstract factory (extensibility++, performance-)

32. Apply Design Pattern Façade Façade Abstract factory Abstract factory Strategy Strategy Observer Observer performance maintainability reliability safety security

33. Example

34. Convert QR to Functionality each QR has several possible solutions each QR has several possible solutions select one solution and extend architecture functionality with QR related functionality select one solution and extend architecture functionality with QR related functionality example example introduce redundant objects introduce redundant objects mutual consistency checking algorithm mutual consistency checking algorithm

35. Convert QR to Functionality self-monitoring self-monitoring top-level monitoring layer top-level monitoring layer entity-based monitoring entity-based monitoring redundancy redundancy N-version programming N-version programming recovery blocks recovery blocks acceptance tests acceptance tests

36. Example

37. Example

38. Distribute Requirements decompose system requirement to requirement for multiple components decompose system requirement to requirement for multiple components example example fault-tolerance divided into FT-communication and FT-computation fault-tolerance divided into FT-communication and FT-computation response-time requirement divided into shorter component response times response-time requirement divided into shorter component response times

39. Example

40. Conclusion transformation techniques transformation techniques impose architectural style impose architectural style impose architectural pattern impose architectural pattern apply design pattern apply design pattern convert QR to functionality convert QR to functionality

41. Conclusion

43. Architectural Transformations for Improving the Efficiency of Object- Oriented Systems Tom Tourwé Programming Technology Lab Vrije Universiteit Brussel

44. Overview What problem are we trying to tackle exactly? What problem are we trying to tackle exactly? What are the requirements for the solution? What are the requirements for the solution? How do we combine these different requirements? How do we combine these different requirements?

45. Reasons for loss of performance Objectifying all kinds of things Objectifying all kinds of things operations (e.g. Visitor DP) operations (e.g. Visitor DP) state (e.g. State DP) state (e.g. State DP) algorithms (e.g. Strategy, Command DP) algorithms (e.g. Strategy, Command DP) interactions (e.g. Mediator DP) interactions (e.g. Mediator DP) Favor aggregation over inheritance Favor aggregation over inheritance “Programming to Interfaces” approach “Programming to Interfaces” approach

46. Reasons for loss of performance This can not be tackled by existing techniques This can not be tackled by existing techniques only focus on statically binding messages only focus on statically binding messages no knowledge about abstractions and indirections no knowledge about abstractions and indirections can not convert aggregation into inheritance can not convert aggregation into inheritance not able to “specialize” the program for a specific usage pattern not able to “specialize” the program for a specific usage pattern

47. Example ImplA

48. Example

49. Example

50. Solution Use an open precompiler Use an open precompiler has detailed knowledge about a system. This knowledge is provided by the developer through annotations in a special purpose language has detailed knowledge about a system. This knowledge is provided by the developer through annotations in a special purpose language can use this knowledge to transform a system. How this should be done is specified in another language can use this knowledge to transform a system. How this should be done is specified in another language

51. Annotation Language Enables the developer to express “facts” about the system Enables the developer to express “facts” about the system embedded in the code in the form of comments embedded in the code in the form of comments Should be (based on) a logic language Should be (based on) a logic language

52. Annotation Language /** ConcreteVisitor(PrettyPrintVisitor). operationname(PrettyPrintVisitor, prettyprint). acceptname(PrettyPrintVisitor, accept). */ public class PrettyPrintVisitor implements Visitor { … } /** VisitedElement(IfStatementNode). */ public class IfStatementNode implements Node { … }

53. Transformation Language Specifies how the compiler should transform a system Specifies how the compiler should transform a system specified separately from that system specified separately from that system can be seen as an aspect language can be seen as an aspect language should be able to use the information provided in the annotation language should be able to use the information provided in the annotation language should be as expressive and as simple as possible should be as expressive and as simple as possible

54. Transformation Language A mix of functional and logic language A mix of functional and logic language Logical: specifies WHEN to transform Logical: specifies WHEN to transform use the logic facts provided by the programmer use the logic facts provided by the programmer use the matching capabilities of a logic engine use the matching capabilities of a logic engine Functional: specifies HOW to transform Functional: specifies HOW to transform specify easily which transformations should be performed specify easily which transformations should be performed

55. Transformation Language Available transformations are limited Available transformations are limited only high-level transformations only high-level transformations addclass, addmethod, delete, changename, addformal, changetype, … addclass, addmethod, delete, changename, addformal, changetype, … low-level transformations are handled by a special “replace” function low-level transformations are handled by a special “replace” function Use refactorings to actually perform the transformation Use refactorings to actually perform the transformation

56. Simple Example package test; spec Simple { ?returntype m(?Formal) { deleteformal(?Formal), move(?Formal.type). } Move method m from class Test Move method m from class Test

57. Typical Example class PrettyPrintVisitor { void visitIfStatementNode(IfStatementNode x) { this.print(“if(“); x.itsCondition().accept(this); this.print(“)”); x.itsThenPart().accept(this); x.itsElsePart().accept(this); } class IfStatementNode { void prettyprint(PrettyPrintVisitor x) { x.print(“if(“); this.itsCondition().prettyprint(x); x.print(“)”); this.itsThenPart().prettyprint(x); this.itsElsePart().prettyprint(x); } VS.

58. Typical Example package test.visitors; spec VisitorSpec { ?returntype ?method (?Formal) { changetype(?Formal.type, ?Visitor.type), replace(“this”, ?Formal.name), replace(?Formal.name, “this), replace(“?rec.” + ?acceptname + “(?x)”, “?rec.” + ?operationname + “(?x)”), move(?Formal.type), changename(?operationname). } :- VisitedElement(?Formal.type), operationname(?Visitor, ?operationname), acceptname(?Visitor, ?acceptname). } :- ConcreteVisitor(?Visitor).

59. Implementation

60. To Be Done Finish implementation of the SpecParser Finish implementation of the SpecParser Perform some benchmarks on small systems Perform some benchmarks on small systems Perform some benchmarks on real systems Perform some benchmarks on real systems Develop more formal notation for assessing the performance gains Develop more formal notation for assessing the performance gains