Code Structural Analysis
•Download as PPTX, PDF•
3 likes•2,018 views
This document discusses principles of code structural analysis. It covers package cohesion principles like release reuse equivalency and common closure principle. It also discusses package coupling principles like the acyclic dependencies principle and abstractness of a package. Class design principles like the SOLID principles of dependency inversion and interface segregation are also summarized. It provides an example of analyzing structure using metrics like package instability and introduces the tool Stan4j for structural analysis.
More Related Content
Similar to Code Structural Analysis
Similar to Code Structural Analysis (20)
More from Dmitry Buzdin
More from Dmitry Buzdin (20)
Recently uploaded
Recently uploaded (20)
Code Structural Analysis
- 2. Speaker Eduards Sizovs 4finance | Software Architect linkedin.com/in/eduardsi eduards.sizovs@gmail.com 2
- 3. Agenda • Introduction to structural analysis • Package Cohesion principles • Package Coupling principles • Class design principles • Stan4j in action 3
- 4. Introduction to structural analysis 4
- 5. Software Artifact Application Design layer Libraries Packages Classes Code layer Members 5
- 6. Software Structure • How artifacts build into higher level artifacts • How artifacts depend on each other 6
- 7. Big ball of mud 7
- 8. Rotting structure symptoms • Rigidity • Fragility • Immobility • Viscosity • Opacity 8
- 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. Structural clarity 10
- 11. Package Cohesion principles 11
- 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. 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 is minimized. Group classes open to certain changes. lv.jug.domain.client lv.jug.dao.client lv.jug.domain.client lv.jug.service.client 13
- 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. Package Coupling principles 15
- 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. Abstractness of a package A(P) = AC(P) / TC(P) A(P) ∈ [ 0..1 ] …where P = package AC = abstract type count TC = total type count 17
- 18. Instability of a package I(P) = EC(P) / ( AC(P) + EC(P) ) A(P) ∈ [ 0..1 ] …where P = package EC (Efferent Coupling) = number of outgoing dependencies AC (Afferent Coupling) = number of incoming dependencies 18
- 19. Stable Abstractions Principle «A package should be as abstract as it is stable» Distance (D) Zone of uselessness D=A+I-1 Zone of pain 19
- 20. D-metric Plot 20
- 21. Stable Dependencies Principle «Depend in the direction of stability» 21
- 22. Class design principles (SOLID) 22
- 23. Dependency Inversion Principle «Depend on abstractions, as anything concrete is volatile» 23
- 24. Interface Segregation Principle «Many client specific interfaces are better than one general purpose interface» 24
- 25. Stan4j in action 25
- 26. More 26
- 27. 4finance Thank you! 27
Editor's Notes
- 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)