Mid-term Presentation

Validation of Architecture Rules & Design Patterns

25th 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

• 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 Diagrams GEBNFDesign Pattern

Catalogue

Developing Predicates

Formal Specification

Tool Development

Purely Informal, English like Semi 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 SurveyArchitecture of

ToolImplementation

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

ImplementationArchitecture 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 BuilderPlug-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

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