Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Analyzing Java Projects and Architectures

This presentation from JAX 2013 shows how Java projects and architectures can be analyzed.

Eberhard Wolff

on 2 January 2017

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Analyzing Java Projects and Architectures

Analyzing Java Projects and Architectures Eberhard Wolff
Architecture and Technology Manager
adesso AG About me Eberhard Wolff
Architecture & Technology Manager at adesso
Responsible for architect training @ adesso
adesso is a leading IT consultancy in the German speaking regon
Author (e.g. first German Spring book)
Blog: http://ewolff.com
Twitter: @ewolff
http://prezi.com/user/ewolff Architecture - What Is It? The software architecture .. is
the set of structures needed to reason about the system
which comprise software elements
relations among them, and
properties of both Warehouse Power Point Architecture Manufacturing Purchasing Materials Management Order Global Financial Management ERP CRM Sales Web Store Service Customer History Layers
Packages by technical responsibility
e.g. persistence, services, gui
Not too hard to get right Slices
Packages by functionality
e.g. order, warehouse...
Alien to some
Software is about the functionality! Layers seem to be the primary concern
Slices are seldom done
Worse: Layers and slices mixed What do you think about the PowerPoint Architecture? Architecture
We are using a standard Java EE architecture
JSF for web
EJB for services
JPA for persistence
JBoss application server
Oracle DB What do you think about this architecture? Just a list of technologies
Important and relevant - but no architecture
Technologies must also cover:
Continuous Integration
Code review / metrics
Bug tracker
... Not too bad
Units of functionality / components
Dependencies in layers (?)
Not clear what the components look like Which structure will the code have? Let's take a look... Tip (@olivergierke)
Components = packages
Public classes can define interface
Default visibility for "internal" classes
Dependency management with the Java compiler Base architecture on functionality Avoid complex methods / classes / package
Hard to understand
Hard to modify
Increase maintenance costs
IMHO central to technical debt
Need to measure it! Care about Size! Usually large classes & method also show other issues Need to talk to original developer. process What should depend on what? model util framework Components in Java
Might be deployment units
WAR files, JAR files, OSGi bundles ... + Clear separation: no unwanted dependencies - Effort: additional projects, build files, complex deployment etc
truly independent deployment in Java EE hard (WAR+SOAP)
OSGi hasn't really succeeded (yet) What could the components be? Components in Java
Might be packages Less effort + - How do you manage dependencies? Warehouse Manufacturing Purchasing Materials Management Order Global Financial Management ERP Do you know the dependencies in your system? process What is really looks like... model util framework Example: Open Source project
Business software
Many Java projects are similar 94 303 2387 For a true assessment you need to understand the functionality
Hard, complex and time consuming 17 103 1047 10990 3933 46 5 7 307 Circular dependencies / tangles
Everything depends on everything
No part can be changed independently
Hard to understand: Too many parts Too many dependencies
Too many large parts
Now what? Technical Debt Pay the debt back
...if it will pay off in the future
i.e. how often will the code be changed?
how hard are changes in the code?
Restructure accordingly
managing-technical-debt Talk to developers Fat methods
Fat classes
Fat leaf packages
Fat design Tangles (design)
as graph / matrix Can you see the dependencies? Tangles vs. Fat
Levelized Structure Map
Basic Restructuring
Fight Fat with auto grouping Suggest new package structure:
Auto levelize Levelized Structure Map:
compact view
Not just analysis - support for restructuring
Game changer: Makes structure easily changeable
Won JAX Innovation Award 2012 You can fix your architecture! Technologies are kewl
...but often functionalities are not reflected in the architecture
This is what pays us
New requirements will change the functionality Technical Debt Can enforce dependencies
Keeps the system clean
e.g. jdepend, Structure 101, SonarJ
Full transcript