![Page 1: Mid-term Presentation Validation of Architecture Rules & Design Patterns 25 th May](https://reader036.vdocuments.site/reader036/viewer/2022062423/5681492d550346895db669c0/html5/thumbnails/1.jpg)
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
![Page 2: Mid-term Presentation Validation of Architecture Rules & Design Patterns 25 th May](https://reader036.vdocuments.site/reader036/viewer/2022062423/5681492d550346895db669c0/html5/thumbnails/2.jpg)
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
![Page 3: Mid-term Presentation Validation of Architecture Rules & Design Patterns 25 th May](https://reader036.vdocuments.site/reader036/viewer/2022062423/5681492d550346895db669c0/html5/thumbnails/3.jpg)
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.
![Page 4: Mid-term Presentation Validation of Architecture Rules & Design Patterns 25 th May](https://reader036.vdocuments.site/reader036/viewer/2022062423/5681492d550346895db669c0/html5/thumbnails/4.jpg)
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.
![Page 5: Mid-term Presentation Validation of Architecture Rules & Design Patterns 25 th May](https://reader036.vdocuments.site/reader036/viewer/2022062423/5681492d550346895db669c0/html5/thumbnails/5.jpg)
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.
![Page 6: Mid-term Presentation Validation of Architecture Rules & Design Patterns 25 th May](https://reader036.vdocuments.site/reader036/viewer/2022062423/5681492d550346895db669c0/html5/thumbnails/6.jpg)
Approach
Class Diagrams GEBNFDesign Pattern
Catalogue
Developing Predicates
Formal Specification
Tool Development
Purely Informal, English like Semi Formal
Fully Formal
![Page 7: Mid-term Presentation Validation of Architecture Rules & Design Patterns 25 th May](https://reader036.vdocuments.site/reader036/viewer/2022062423/5681492d550346895db669c0/html5/thumbnails/7.jpg)
Preparation of Catalogue
• Textual specification of 6 design patterns.• Design patterns described by Philips.• Informal representation of the rules.
![Page 8: Mid-term Presentation Validation of Architecture Rules & Design Patterns 25 th May](https://reader036.vdocuments.site/reader036/viewer/2022062423/5681492d550346895db669c0/html5/thumbnails/8.jpg)
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..
![Page 9: Mid-term Presentation Validation of Architecture Rules & Design Patterns 25 th May](https://reader036.vdocuments.site/reader036/viewer/2022062423/5681492d550346895db669c0/html5/thumbnails/9.jpg)
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
![Page 10: Mid-term Presentation Validation of Architecture Rules & Design Patterns 25 th May](https://reader036.vdocuments.site/reader036/viewer/2022062423/5681492d550346895db669c0/html5/thumbnails/10.jpg)
Dispose Pattern
![Page 11: Mid-term Presentation Validation of Architecture Rules & Design Patterns 25 th May](https://reader036.vdocuments.site/reader036/viewer/2022062423/5681492d550346895db669c0/html5/thumbnails/11.jpg)
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
![Page 12: Mid-term Presentation Validation of Architecture Rules & Design Patterns 25 th May](https://reader036.vdocuments.site/reader036/viewer/2022062423/5681492d550346895db669c0/html5/thumbnails/12.jpg)
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.
![Page 13: Mid-term Presentation Validation of Architecture Rules & Design Patterns 25 th May](https://reader036.vdocuments.site/reader036/viewer/2022062423/5681492d550346895db669c0/html5/thumbnails/13.jpg)
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)
![Page 14: Mid-term Presentation Validation of Architecture Rules & Design Patterns 25 th May](https://reader036.vdocuments.site/reader036/viewer/2022062423/5681492d550346895db669c0/html5/thumbnails/14.jpg)
Presentation Flow
Tool SurveyArchitecture of
ToolImplementation
Planning
![Page 15: Mid-term Presentation Validation of Architecture Rules & Design Patterns 25 th May](https://reader036.vdocuments.site/reader036/viewer/2022062423/5681492d550346895db669c0/html5/thumbnails/15.jpg)
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.
![Page 16: Mid-term Presentation Validation of Architecture Rules & Design Patterns 25 th May](https://reader036.vdocuments.site/reader036/viewer/2022062423/5681492d550346895db669c0/html5/thumbnails/16.jpg)
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.)
![Page 17: Mid-term Presentation Validation of Architecture Rules & Design Patterns 25 th May](https://reader036.vdocuments.site/reader036/viewer/2022062423/5681492d550346895db669c0/html5/thumbnails/17.jpg)
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
![Page 18: Mid-term Presentation Validation of Architecture Rules & Design Patterns 25 th May](https://reader036.vdocuments.site/reader036/viewer/2022062423/5681492d550346895db669c0/html5/thumbnails/18.jpg)
Presentation Flow
Tool Survey Implementation
Planning
Architecture of the tool
![Page 19: Mid-term Presentation Validation of Architecture Rules & Design Patterns 25 th May](https://reader036.vdocuments.site/reader036/viewer/2022062423/5681492d550346895db669c0/html5/thumbnails/19.jpg)
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.
![Page 20: Mid-term Presentation Validation of Architecture Rules & Design Patterns 25 th May](https://reader036.vdocuments.site/reader036/viewer/2022062423/5681492d550346895db669c0/html5/thumbnails/20.jpg)
Implementation
Tool Survey
Planning
ImplementationArchitecture of
the tool
![Page 21: Mid-term Presentation Validation of Architecture Rules & Design Patterns 25 th May](https://reader036.vdocuments.site/reader036/viewer/2022062423/5681492d550346895db669c0/html5/thumbnails/21.jpg)
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
}
}
}
![Page 22: Mid-term Presentation Validation of Architecture Rules & Design Patterns 25 th May](https://reader036.vdocuments.site/reader036/viewer/2022062423/5681492d550346895db669c0/html5/thumbnails/22.jpg)
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
![Page 23: Mid-term Presentation Validation of Architecture Rules & Design Patterns 25 th May](https://reader036.vdocuments.site/reader036/viewer/2022062423/5681492d550346895db669c0/html5/thumbnails/23.jpg)
Output
• Many visual styles available.
![Page 24: Mid-term Presentation Validation of Architecture Rules & Design Patterns 25 th May](https://reader036.vdocuments.site/reader036/viewer/2022062423/5681492d550346895db669c0/html5/thumbnails/24.jpg)
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.
![Page 25: Mid-term Presentation Validation of Architecture Rules & Design Patterns 25 th May](https://reader036.vdocuments.site/reader036/viewer/2022062423/5681492d550346895db669c0/html5/thumbnails/25.jpg)
Report Generation
Report Generation
Fact Extractor
Rule Builder
Plug-in
DXCore
Visual Studio
CodeRush
![Page 26: Mid-term Presentation Validation of Architecture Rules & Design Patterns 25 th May](https://reader036.vdocuments.site/reader036/viewer/2022062423/5681492d550346895db669c0/html5/thumbnails/26.jpg)
Report Generation
• Console application.
• Report for the nightly batch build.• Verify entire solution.
• Locations where Violations detected.
• Summarizing all violations caught.
![Page 27: Mid-term Presentation Validation of Architecture Rules & Design Patterns 25 th May](https://reader036.vdocuments.site/reader036/viewer/2022062423/5681492d550346895db669c0/html5/thumbnails/27.jpg)
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
![Page 28: Mid-term Presentation Validation of Architecture Rules & Design Patterns 25 th May](https://reader036.vdocuments.site/reader036/viewer/2022062423/5681492d550346895db669c0/html5/thumbnails/28.jpg)
THANK YOU