Code Structural Analysis


Published on

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • What our software comprises of
  • StructurereflectsourdesignStructureisourdesignArchitecture?
  • Rigidity(tverdostjmonolitnostj) – monolith, difficult to change, cascade to dependent modulesFragility – breaking in many places with no conceptual relationshipImmobility – inability to reuse components, decompose system, big transitive dependency tailViscosity (vjazkostj) –when “normal” change is harder to employ than a hack due to design (unclear dependency) or environment (compilation 1H)Opacity – can’t understand the purpose of the class/package
  • Avoiddevelopment interference, forexampleServe as a foundationforfuturemodularization
  • Imagine that every change increments version and makes class unsuitable for clients of the previous version
  • Reason:Minimizeimpact on the client with different releasecycleЕсли я положу в библиотеку или пакетто, что сложно реюзать или то что нежелательно реюзать, это непосредственно влияет на клиента и мою необходимость релизить повторноОдиночные классы часто не реюзаются. Необходимо создавать набор крассов (потенциально формирующий связный компонент)Either all of the classes in a package are reusable or non of them are.
  • Reason:the more packages change in any given release, the greater work to rebuild, test and deploy the releasemimimize the number of packages that are changed in any givenreleaseIf the code in an application must change, where would you like those changes tooccur: all in one package, or distributed through many packages?ModularContinuity – whensmallrequirementchangeyieldssmallchangeintheresult
  • Reason:Ifclass changes, its package changes (and classesinside).If a package is being releasedbecause of changes to a class that I don’t care about, then I will not be very happy abouthaving to revalidate my application.Every time the used package (P2) is released, the using package (P1) must be revalidated
  • Cycled = only can be used & understood togetherNo dependency cycles within the design layerGraph is acyclic if and only if it has no tanglesBreak minimum feedback arc
  • 1 класс и не абстрактный = 01 класс и абстрактный = 12 класса пополам = 0,5
  • Responsible class – a lot of incoming dependenciesDependent class – a lot of outgoing dependencies0,5для пакетов с одинаковым количеством входящих и выходящих связей
  • Stable = hard to change, Unstable – easy to change, butfragile. We don’t want all packages to be stableBy sticking to this principle we avoid getting packages which are used heavily by the rest of the application and which, at the same time, have a low degree of abstraction
  • Stable = hard to change, Unstable – easy to change, butfragile. We don’t want all packages to be stableBy sticking to this principle we avoid getting packages which are used heavily by the rest of the application and which, at the same time, have a low degree of abstraction
  • Stan4j: Acyclic dependencies forming Tangles
  • Enforcing rules with MackerScreenshot of rotting structure (DC)Screenshot of clean structure (Deposits)
  • Code Structural Analysis

    1. 1. Code structural analysis
    2. 2. Speaker Eduards Sizovs4finance | Software Architect 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