Code Structural Analysis

524 views

Published on

Code structural analysis

  • Be the first to comment

  • Be the first to like this

Code Structural Analysis

  1. 1. Code structural analysis
  2. 2. Speaker Eduards Sizovs4finance | Software Architect linkedin.com/in/eduardsi eduards.sizovs@gmail.com 2
  3. 3. Agenda• Introduction to structural analysis• Package Cohesion principles• Package Coupling principles• Class design principles• Stan4j in action 3
  4. 4. Introduction to structural analysis 4
  5. 5. Software Artifact ApplicationDesign layer Libraries Packages Classes Code layer Members 5
  6. 6. Software Structure• How artifacts build into higher level artifacts• How artifacts depend on each other 6
  7. 7. Big ball of mud 7
  8. 8. Rotting structure symptoms• Rigidity• Fragility• Immobility• Viscosity• Opacity 8
  9. 9. Goals of structural analysis• Early fixing design violations• Keeping code complexity on a manageable level under constant change rain• Getting the «big picture» 9
  10. 10. Structural clarity 10
  11. 11. Package Cohesion principles 11
  12. 12. Release Reuse Equivalency «The unit of reuse is the unit of release»Criterion for grouping artifacts is convenience for reuse and release Component lv.jug.api lv.jug.logic 12
  13. 13. Common Closure Principle «Classes that change together belong together» If classes that change together are in the same Package, then the impact on other packages isminimized. Group classes open to certain changes. lv.jug.domain.client lv.jug.dao.client lv.jug.domain.client lv.jug.service.client 13
  14. 14. Common Reuse Principle «Classes in a package are reused together»A dependency upon a package is a dependency upon everything within the package. 14
  15. 15. Package Coupling principles 15
  16. 16. Acyclic Dependencies Principle«The dependencies between packages must not form cycles»Can be solved by:• Splitting packages (CRP)• Reorganizing packages• DIP & Interface Segregation 16
  17. 17. Abstractness of a package A(P) = AC(P) / TC(P) A(P) ∈ [ 0..1 ]…whereP = packageAC = abstract type countTC = total type count 17
  18. 18. Instability of a package I(P) = EC(P) / ( AC(P) + EC(P) ) A(P) ∈ [ 0..1 ]…whereP = packageEC (Efferent Coupling) = number of outgoing dependenciesAC (Afferent Coupling) = number of incoming dependencies 18
  19. 19. Stable Abstractions Principle «A package should be as abstract as it is stable»Distance (D) Zone of uselessnessD=A+I-1 Zone of pain 19
  20. 20. D-metric Plot 20
  21. 21. Stable Dependencies Principle«Depend in the direction of stability» 21
  22. 22. Class design principles (SOLID) 22
  23. 23. Dependency Inversion Principle«Depend on abstractions, as anything concrete is volatile» 23
  24. 24. Interface Segregation Principle«Many client specific interfaces are better than one general purpose interface» 24
  25. 25. Stan4j in action 25
  26. 26. More 26
  27. 27. 4financeThank you! 27

×