Mid-term Presentation Validation of Architecture Rules & Design Patterns 25 th May

1. Mid-term PresentationValidation of Architecture Rules & Design Patterns25th May Shravan Shetty & Vinod J Menezes Supervised by, Prof. Dr. M. v. d. Brand Company Supervisors, Albert Faber Kasper Van Wouw

2. Research Question?? • Kick-off presentation: • Basics of Design Patterns • Few example patterns • Ideas for a formal specification • Possible toolset • Mid term presentation: • Recap • Recap • First order Predicate logic • CodeRush • Architecture of the tool • Demo Implementation • Planned Activities Analyzing and verifying architectural rules and design patterns for medical imaging software.

3. Introduction What are Architectural rules & Design Patterns?? • Reusable solution to a commonly occurring problem. • Provides a template to solve a particular problem. • Architectural rules are at system level. • Design patterns are at the component level. Advantages: • Simplifies a complex system. • Easy to extend and implement unforeseen requirements. • Easy to debug & analyze and maintain. • Already proven solution. • Consistency.

4. WPF (Windows Presentation Foundation) • XAML • Declarative language • Decoupling presentation aspects from application logic. • Provides a data binding mechanism to couple the UI logic with the application logic.

5. MVVM design pattern • View Layer • UI Logic. Does not have any application logic or state. • View-Model Layer • Application logic and state. • Philips specific rule: Depends only on Model layer interfaces and not on objects. • Model Layer • Business logic.

6. Approach Purely Informal, English like Semi Formal Design Pattern Catalogue Class Diagrams GEBNF Tool Development Formal Specification Developing Predicates Fully Formal

7. Preparation of Catalogue Textual specification of 6 design patterns. Design patterns described by Philips. Informal representation of the rules.

8. GEBNF notion • Interface ::= • name : String, • namespace : String, • attrs : Property*, • meth : Methods*, • modifier : Modifier • Property ::= • name : String, • type : Type, • modifier : Modifier, • Methods ::= • name : String, • inParams : Parameter*, • returnParam : Parameter, • modifier : Modifier, • isLeaf : Boolean • Etc.. • CD ::= classes : Class+, inters : Interface*, deps : (Classifier, Classifier)*, calls : (Operation, Operation)* • Classifier ::= Namespace | Class | Interface • Class ::= name : String, namespace : String, attrs : Property*, meth : Methods*, modifier : Modifier, isAbstract : Boolean

9. First order Predicate logic • Façade DP: • A facade is an object that provides a simplified interface to a larger body of code, such as a class library. • This can be formalized by using the following predicates: • classes denotes the set of classes in the system. • deps denotes a binary relation on classes Then the DP can be specified as: ∀y ⊂ classes. ∀C ∈ y. ∀CL ∈ classes. CL ⇢*C ∈ deps → ∃façade ∈ classes. facade ∉ y.CL ⇢ façade ∈ deps ∧ façade ⇢* C ∈ deps

10. Dispose Pattern

11. Example DP Dispose Pattern: Part I: For any class implementing the IDisposable interface, Dispose() method must not belong to the View Layer.   ∀c ∈ classes. isViewClass(c) → ∀m ∈ meth. m ∈ c ∧ name(m) ≠ “Dispose” Part II: Dispose() method definition with parameter in any class, must either be virtual or overridden. ∀m ∈ meth. ∀c ∈ classes. m ∈ c. name(m) = “Dispose” ∧ inParams(m) ≠ ∅ → modifier(m) = override ∨ modifier(m) = virtual

12. iXR specific Notation • Methods ::= • isDispose : bool. More Abstraction by using predicates for most common patterns. E.g: class ::= classLayer : Layer, parentImpl : String. classLayer ::= View | ViewModel | Model classLayer(c) = View ≡ ∀c ∈ classes. ∀d ∈ classes. c ⇢ d ∈ assocs → (names(d) = “Interactors” | “Animations”) ∨ namespace(c) = “View” parentImpl(c) = “IDisposable” ≡ ∀c ∈ classes. ∃i ∈ inters. c ⇢ i ∈ assoc → name(i) = ”IDisposable”∨ ∀c’ ∈ classes. c ⇒ c’ ∈ geners ∧ parentImpl(c’) isDispose(m,c) = true ≡ ∀c ∈ classes. ∃m ∈ meth. m ∈ c. name(m) = “Dispose”

13. Abstract Pattern Specification Dispose Pattern: Part I: For any class implementing the IDIsposable interface, Dispose() method must not belong to the View Layer.   ∀c ∈ classes.classLayer(c) = View → ∀m ∈ meth. ¬isDispose(m,c) Part II: Dispose() method definition with parameter in any class, must either be virtual or overridden. ∀c ∈ classes. ∀m ∈ meth. isDispose(m,c) ∧ inParams(m) ≠ ∅ → isOverride(m) ∨ isVirtual(m)

14. Presentation Flow Tool Survey Architecture of Tool Implementation Planning

15. Tool Selection • Requirements for a Tool • Tool that can handle C# code. • On the fly static code analysis. • Allows to build plug-in for Visual studio. • Ease of use and programming. • Lifetime. • Licensing.

16. Limitations of tools • NDepend • On the fly static code analysis • Resharper • Lifetime. • Ease of use. • Philips patterns and ReSharper errors may look similar, chances of ignoring few pattern violations. • Ease of programming. • DXCore & CodeRush. • Licensing (But XPress edition is free.)

17. CodeRush CodeRush DXCore • DXCore • Built in parser. • Allows to build console application. • Unit testing. • Flexible • Can be used with ReSharper also with a help of few API’s. • CodeRush • APIs and events to create a plug-in to visual studio. • Different outputs available.

18. Presentation Flow Tool Survey Architecture of the tool Implementation Planning

19. Architecture Of the Tool • Rules for each pattern. • Uses functions from fact extractor. • Plug-in uses these rules. Visual Studio CodeRush Plug-in • Basic function to extract information. • Basis for rule formulation • Functions are reusable • Built in parser • Basic C# elements Rule Builder Fact Extractor DXCore

20. Implementation Tool Survey Architecture of the tool Implementation Planning

21. Implementation • For any class implementing the IDisposable interface, Dispose() method must not belong to the View Layer. DisposeViewLayer( CurrentClass) { If(GetLayer(class)==VIEW) { If(IDisposable ∈ GetImplementedInterfaces(class)) && Dispose ∈ GetMethods(class)) { return false; //Pattern violation } } }

22. Implementation Plug-in Rule Builder Fact Extractor GetLayer(class) {……} GetMethods(class) {……} GetImplementedInterfaces(class) {…} DisposeViewLayer( CurrentClass) { If(GetLayer(class)==VIEW) { If(IDisposable ∈ GetImplementedInterfaces(class)) && Dispose ∈ GetMethods(class)) { return false; //Pattern violation } } }

23. Output Many visual styles available.

24. Planned Activities • Work on different outputs • Severity of pattern • Provide links to documentation during pattern violation. • Additional methods and classes for fact extractor. • Testing: • Unit Testing. • Few test samples to verify pattern violations. • Test for false positives. • Report generation. • Refining the rules based on testing.

25. Report Generation Visual Studio CodeRush Report Generation Plug-in Rule Builder Fact Extractor DXCore

26. Report Generation • Console application. • Report for the nightly batch build. • Verify entire solution. • Locations where Violations detected. • Summarizing all violations caught.

27. Conclusion Prepared a design pattern catalogue. Formalization of patterns using first order logic. Implementation of pattern using CodeRush. Three level plug-in architecture. Flexible Architecture aids future extensions

28. THANK YOU