As systems grow, many of the overarching architectural principles become less obvious to developers. It is important to preserve these principles intact and visible to all folks that interact with the code base. In this session, we will review a number of static code analysis tools, starting with localized analysis of code snippets; create strategies for catching violations of application-wide design patterns; and review tools for automating and hooking the static code analysis to source control and build systems.

2. Enforcing
Architecture
PaBerns
with
StaEc
Code
Analysis
JDD
2014,
Krakow
-­‐
PL
Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
Pablo
Barros
ApplicaEons
Architect
October
13,
2014

3. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
• The
opinions
and
views
expressed
in
this
talk
are
my
own,
and
do
not
necessarily
reflect
the
opinions
or
views
of
my
employer.
3

4. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
About
me
4

5. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
About
me
5

6. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
Giveaway
• Lean
Architecture
by
Coplien
&
Bjornvig
6

7. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
Agenda
The
Problem:
“Architectural
Decay”
The
SoluEon:
“Architectural
Agility”
Defining
your
RelaEonships
Tracking
and
Enforcing
in
AcEon
Q&A
7
1
2
3
4
5

8. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
“Architectural
Decay”
The
Problem
8

9. What
is
So_ware
Architecture?
Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
• IEEE
1471-­‐2000
defines:
“So_ware
architecture
is
the
fundamental
organizaEon
of
a
system,
embodied
in
its
components,
their
relaEonships
to
each
other
and
the
environment,
and
the
principles
governing
its
design
and
evoluEon.”
9

10. What
is
So_ware
Architecture?
Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
• IEEE
1471-­‐2000
defines:
“So_ware
architecture
is
the
fundamental
organizaAon
of
a
system,
embodied
in
its
components,
their
relaAonships
to
each
other
and
the
environment,
and
the
principles
governing
its
design
and
evoluAon.”
10

11. Architecture
Degenerates
Over
Time
“As
a
system
evolves,
its
complexity
increases
unless
work
is
done
to
maintain
or
reduce
it.”
Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
-­‐-­‐Lehman’s
Laws
of
So.ware
Evolu4on
(1980)
11

12. Architecture
Work
as
Systems
Grow
Major
Features
Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
12
Architecture
Work
Time/Growth
Sefng
up
foundaEon
Rewrite

13. Reasons
for
“Architecture
Decay”
Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
• Increased
system
complexity
• Architecture
is
not
documented
• Developers
don’t
know
or
don’t
understand
• “Shortcuts”
caused
by
Eght
deadlines
• Division
of
work
on
different
disperse
teams
13

14. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
“Architectural
Agility”
The
SoluAon
14

15. Defining
“Architectural
Agility”
Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
15
• “Just
Enough”
Informed
AnEcipaEon
– Dependency
Analysis
– Real
OpEon
Analysis
– Technical
Debt
Management

16. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
Dependency
Analysis
• Cost
of
Change
PropagaEon
• Visibility
of
likely
affected
areas
16
Spring
3.0
Module
Dependencies
hBp://www.ogrigas.eu/spring/2009/12/diagram-­‐of-­‐spring-­‐3-­‐0-­‐module-­‐dependencies

17. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
Technical
Debt
Management
• Refactoring
of
relaEonships
between
components
is
expensive
• Lack
of
“Architecture
Agility”
compromises
“Enhancement
Agility”
17

18. Defining
your
RelaEonships
Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
18

19. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
RelaEonships
• Layers
– Horizontal
Slices
of
the
System
• Examples:
Controller,
Service,
DAO,
Model,
View.
– How
different
layers
can
interact?
– And
cannot
interact?
• Modules
– VerEcal
Slices
of
the
System
• Examples:
Catalog,
Inventory,
Ordering,
ReporEng.
– How
different
modules
can
interact?
And
cannot
interact?
19

20. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
Layers
• Organized
in
Package-­‐based
hierarchy
• Layers
of
a
same
“Module”
are
built
together
in
a
single
JAR
• How
do
we
prevent
introducing
unwanted
dependencies
between
layers?
20

21. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
Modules
• Few
opEons:
– OSGi
Bundles
– Jars
– Packages
• How
do
we
prevent
introducing
unwanted
dependencies
between
modules?
• How
big/small
should
a
module
be?
21
Spring
3.0
Module
Dependencies
hBp://www.ogrigas.eu/spring/2009/12/diagram-­‐of-­‐spring-­‐3-­‐0-­‐module-­‐dependencies

22. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
Packages
You
want
to
be
able
to
slice
and
dice
them
22
• Adopt
a
package
convenEon
and
sEck
with
it!
• Package-­‐by-­‐feature
vs.
Package-­‐by-­‐Layer
• For
example:
com.company.product.module.layer!
com.company.product.layer.module!

23. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
Packages
Compare
these
approaches:
23
• Package-­‐by-­‐layer
• Package-­‐by-­‐feature

24. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
AnE-­‐PaBerns
Not
just
your
average
“code
smell”
• Big
ball
of
Mud
• Circular
Dependency
• Jumble
• Object
cesspool
• Object
orgy
• SequenEal
coupling
24

25. Tracking
and
Enforcing
in
AcEon
Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
25

26. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
StaEc
Code
Analysis
(SCA)
• Cheaper
and
more
efficient
to
find
certain
types
of
bugs
than
code
reviews
– Not
meant
to
replace
them
• Reduce
need
for
knowledge
of
large
frameworks
• Allow
for
excepEons
(as
opposed
to
a
compiler)
• Good
at
Enforcing
Standards
and
Best
PracEces
• Can
be
Automated
• Early
in
the
Development
Process
26

27. StaEc
Code
Analysis
and
the
“Big
Picture”
javac!
Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
27

28. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
Common
Usage
of
SCA
28
• Finding
bugs
and
code
smells
• Security
vulnerabiliEes
(certain
types)
• Unit
test
coverage

29. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
Tools
• General
– NaEve
IDE
Support
• Eclipse,
IntelliJ,
Jdeveloper
– FindBugs
– Coverity
• Dependency-­‐analyzer
– Dependency
Finder
– JDepend
29
• Architecture-­‐focus
– Sonargraph
– Lafx
Architect
– Structure101

30. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
Demo
Spring
Petclinic
Sample
ApplicaAon
• Define
Layers
and
Slices
• Plugging
into
the
IDE
• Image
Credit:
hBps://speakerdeck.com
/michaelisvy/spring-­‐petclinic-­‐sample-­‐applicaEon
30

31. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
Making
it
Work
• Integrate
into
Build
System
• Define
Owners
• Maintain
and
Grow
set
of
Rules
– New
Rules
come
out
of
Code
Reviews
findings
and
discussions
– Rules
are
categorized
in
different
Severity
Levels
• Define
AcEons
required
depending
on
different
Severity
Levels
• Follow
through
31

32. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
Measuring
Quality
• Not
every
warning
needs
to
be
“Fixed”
• Keep
a
pulse
on
overall
number
of
warnings
• Focus
on
High
Priority
warnings
• Monitor
– Overall
number
of
warnings
– Code
fragmentaEon
– Code
coverage
(Unit
tests)
32

33. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
Final
Thoughts
1. Take
the
first
step,
download
and
evaluate
different
tools
2. Look
at
your
current
system
3. Define
basic
structures
to
“stop
the
bleeding”
4. Integrate
into
your
build
system
5. Incrementally
tackle
and
solve
problems
as
you
work
on
different
areas
of
your
applicaEon
Be
smart
around
your
package
structure!
33

34. Also
checkout
session:
Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
Q&A
Thank
you!
34
MulAtenant
Search
Tomorrow
–
17:00
<Sputnik
Track>

35. References
and
Further
Reading
• hBp://www.crosstalkonline.org/storage/issue-­‐archives/
2010/201011/201011-­‐Brown.pdf
• hBp://www.ksi.edu/seke/Proceedings/seke11/166_Lei_Zhang.pdf
• hBp://www.infoq.com/arEcles/architecture-­‐and-­‐agility-­‐good-­‐friends
• hBp://www.sonarqube.org/evaluate-­‐your-­‐technical-­‐debt-­‐with-­‐sonar/
Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
35

36. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
36