code structural analysis

Code structural analysis

2

Speaker

Eduards Sizovs

4finance | Software Architect

linkedin.com/in/eduardsi

eduards.sizovs@gmail.com

3

Agenda

• Introduction to structural analysis

• Package Cohesion principles

• Package Coupling principles

• Class design principles

• Stan4j in action

4

Introduction to structural analysis

5

Software Artifact

Application

Libraries

Packages

Classes

Members

Design layer

Code layer

6

• How artifacts build into higher level artifacts

• How artifacts depend on each other

Software Structure

7

Big ball of mud

8

• Rigidity

• Fragility

• Immobility

• Viscosity

• Opacity

Rotting structure symptoms

9

• Early fixing design violations

• Keeping code complexity on a manageable level under constant change rain

• Getting the «big picture»

Goals of structural analysis

10

Structural clarity

11

Package Cohesion principles

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

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.service.client

lv.jug.domain.client

14

Common Reuse Principle

«Classes in a package are reused together»

A dependency upon a package is a dependency upon everything within the package.

15

Package Coupling principles

16

Can be solved by:

• Splitting packages (CRP)

• Reorganizing packages

• DIP & Interface Segregation

Acyclic Dependencies Principle

«The dependencies between packages must not form cycles»

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

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

19

Stable Abstractions Principle

«A package should be as abstract as it is stable»

Distance (D)

D = A + I - 1

Zone of pain

Zone of uselessness

20

D-metric Plot

21

Stable Dependencies Principle

«Depend in the direction of stability»

22

Class design principles (SOLID)

23

Dependency Inversion Principle

«Depend on abstractions, as anything concrete is volatile»

24

Interface Segregation Principle

«Many client specific interfaces are better than one general purpose interface»

25

Stan4j in action

26

More

27

Thank you!

4finance