Download to read offline
![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](https://image.slidesharecdn.com/jug4financestructuralanalysis-120926152517-phpapp02-121025130806-phpapp02/85/Code-Structural-Analysis-17-320.jpg)
![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](https://image.slidesharecdn.com/jug4financestructuralanalysis-120926152517-phpapp02-121025130806-phpapp02/85/Code-Structural-Analysis-18-320.jpg)
Uploaded byEduards Sizovs
Code Structural Analysis
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.
![[아꿈사/110903] 도메인주도설계 4장](https://cdn.slidesharecdn.com/ss_thumbnails/110903-110903003107-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
Code Structural Analysis
- 1.
- 2. Speaker Eduards Sizovs 4finance | Software Architect linkedin.com/in/eduardsi eduards.sizovs@gmail.com 2
- 3. Agenda • Introduction tostructural analysis • Package Cohesion principles • Package Coupling principles • Class design principles • Stan4j in action 3
- 4. Introduction to structuralanalysis 4
- 5. Software Artifact Application Design layer Libraries Packages Classes Code layer Members 5
- 6. Software Structure • Howartifacts build into higher level artifacts • How artifacts depend on each other 6
- 7. Big ball ofmud 7
- 8. Rotting structure symptoms •Rigidity • Fragility • Immobility • Viscosity • Opacity 8
- 9. Goals of structuralanalysis • Early fixing design violations • Keeping code complexity on a manageable level under constant change rain • Getting the «big picture» 9
- 10.
- 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.
- 16. Acyclic Dependencies Principle «Thedependencies between packages must not form cycles» Can be solved by: • Splitting packages (CRP) • Reorganizing packages • DIP & Interface Segregation 16
- 17. Abstractness of apackage 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 apackage 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.
- 21. Stable Dependencies Principle «Dependin the direction of stability» 21
- 22. Class design principles(SOLID) 22
- 23. Dependency Inversion Principle «Dependon abstractions, as anything concrete is volatile» 23
- 24. Interface Segregation Principle «Manyclient specific interfaces are better than one general purpose interface» 24
- 25.
- 26. More 26
- 27.
Editor's Notes
- #6 What our software comprises of
- #7 StructurereflectsourdesignStructureisourdesignArchitecture?
- #9 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
- #10 Avoiddevelopment interference, forexampleServe as a foundationforfuturemodularization
- #12 Imagine that every change increments version and makes class unsuitable for clients of the previous version
- #13 Reason:Minimizeimpact on the client with different releasecycleЕсли я положу в библиотеку или пакетто, что сложно реюзать или то что нежелательно реюзать, это непосредственно влияет на клиента и мою необходимость релизить повторноОдиночные классы часто не реюзаются. Необходимо создавать набор крассов (потенциально формирующий связный компонент)Either all of the classes in a package are reusable or non of them are.
- #14 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
- #15 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
- #17 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
- #18 1 класс и не абстрактный = 01 класс и абстрактный = 12 класса пополам = 0,5
- #19 Responsible class – a lot of incoming dependenciesDependent class – a lot of outgoing dependencies0,5для пакетов с одинаковым количеством входящих и выходящих связей
- #20 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
- #21 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
- #26 Stan4j: Acyclic dependencies forming Tangles
- #28 Enforcing rules with MackerScreenshot of rotting structure (DC)Screenshot of clean structure (Deposits)