Mid-term Presentation Validation of Architecture Rules & Design Patterns 25 th May Shravan Shetty &Vinod J Menezes Supervised by, Prof. Dr. M. v. d. Brand Company Supervisors, Albert Faber Kasper Van Wouw

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

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.

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.

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.

Approach Class DiagramsGEBNF Design Pattern Catalogue Developing Predicates Formal Specification Tool Development Purely Informal, English likeSemi Formal Fully Formal

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

GEBNF notion 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 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..

First order Predicate logic 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 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

Dispose Pattern

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

iXR specific Notation 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” Methods ::= isDispose : bool.

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)

Presentation Flow Tool Survey Architecture of Tool Implementation Planning

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.

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.)

CodeRush 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. CodeRush DXCore

Presentation Flow Tool Survey Implementation Planning Architecture of the tool

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

Implementation Tool Survey Planning Implementation Architecture of the tool

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 }

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

Output Many visual styles available.

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.

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

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

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

THANK YOU