OSGi Community Event 2013 (http://www.osgi.org/CommunityEvent2013/Schedule) ABSTRACT

1. Building Modular Software with
OSGi
Ulf Fildebrandt

2. Some words before
This presentation should…
• …give some insights in big software products
• …and how the structure of these products is
managed

3. About the presenter
•
•
•
•
•
Ulf Fildebrandt
Studied computer science
Works for SAP since 1998
Starting with C++ and COM
Development in Java for Java EE server and Eclipse
(even Eclipse 2.x)
• Product architect of SAP Netweaver Composition
Environment (Java stack)
• Program architect of SAP Netweaver 7.30
• Program architect of Integration on Java on demand
stack

4. Agenda
Problem
statement
Goals
Implementation
of Modularity
Measurement of
Modularity

5. „In every phenomenon the beginning remains
always the most notable moment.“
Thomas Carlyle
Findbugs Analysis by Structure 101
SAP Netweaver Structure
PROBLEM STATEMENT

6. Findbugs Analysis
• Famous analysis done by Ian Sutton
• Can be found at
http://structure101.com/blog/2008/11/softw
are-erosion-findbugs/
• Used Structure 101 (see also JAX 2012
innovation award for Restructure 101)

7. Findbugs 0.7.2

8. Findbugs 0.8.6

9. Findbugs 0.8.7

10. Findbugs 1.0.0

11. Findbugs 1.3.0

12. Findbugs 1.3.5

13. Server Analysis
• SAP Java server’s own analysis tool
• It shows the structure of the current
Netweaver server
• In contrast to Structure 101 it does not only
show Java dependencies (packages) but also:
– Usage Types
– Software Components
– Packages

14. Structure of Complex System – I
Overview of product
http://pwdfm295.wdf.sap.corp:9090/makeresults/ce.lc.reporting/NW730EXT_SP_COR/gen/dbg
/java/packaged/full/_doc_pkg/content/index.html

15. Structure of a Complex System – II
Basic Scenario

16. Structure of a Complex System – III
Detailed dependencies

17. „...it is almost always incorrect to begin the
decomposition of a system into modules on the
basis of a flowchart. We propose instead that
one begins with a list of difficult design
decisions or design decisions which are likely to
change. Each module is then designed to hide
such a decision from the others.“
David Parnas
Substitutability
Extensibility
GOALS

18. Software Development Goals
Modules
Manage complexity of software
systems by „divide and conquer“
(see
http://firstround.com/article/Th
e-one-cost-engineers-andproduct-managers-dontconsider#)
A module is a self-contained component of a system, often interchangeable, which
has a well-defined interface to the other components.
http://en.wiktionary.org/wiki/module

19. Software Development Goals
Principles
Extensibility
Substitutability
A module is a self-contained component of a system, often interchangeable, which
has a well-defined interface to the other components.
http://en.wiktionary.org/wiki/module

20. Software Development Goals
One Product
One system can evolve over time and modules can be replaced without impacting
the other modules.

21. Software Development Goals
Multiple Products
Product 1
Product 2
Common modules
Multiple systems can be assembled in different products and do not have to be
implemented again and again.

22. Demo

23. „Programming without an overall architecture
or design in mind is like exploring a cave with
only a flashlight: You don't know where you've
been, you don't know where you're going, and
you don't know quite where you are.“
Danny Thorpe
Process in development
MODULARITY BY INTENTION

24. Process to define modular software
Select modular
runtime
Definition of
modules
Measurement of
metrics
Decoupling
•SOLID
•Design Pattern
Active definition
of system

25. Definition of
modules
Decoupling
•SOLID
•Design Pattern
Measurement
of metrics
Select modular
runtime
Active
definition of
system
Packages
Services
Lifecycle
BASIC MODULARITY WITH OSGI

26. Package Dependencies of a Bundle
Bundle
(internal packages)
Imported
Package
Imported
Package
Exported
Package
Exported
Package
(internal packages)
Bundle
• Bundle exports only
defined packages
• Packages can be
imported from other
archives (bundles)
• All other packages are
only visible inside the
bundle

27. Lifecycle of a Bundle
install
installed
start
starting
resolve
uninstall
resolved
uninstall
uninstalled
active
stop
stopping

28. How to achieve modularity...
• OSGi is a framework on top of Java
• Complements Java very good
• ...but not suffient, because complex system
require higher-level structure
 OSGi subsystem specification

29. Subsystems
• Subsystems bundle many
OSGi bundles
• Defined in OSGi R5
Enterprise Specification
• Reference
implementation in
Apache Aries
(http://apache.aries.org)
http://coderthoughts.blogspot.de/2013/04/osgi-subsystems.html

30. Definition of
modules
Decoupling
•SOLID
•Design Pattern
Measurement
of metrics
Select modular
runtime
Active
definition of
system
Facade
Factory
PRINCIPLES AND PATTERNS
- DESIGN PATTERN (GOF)

31. Factory – I
A factory is an object for creating other objects. It is an abstraction of a constructor.
http://en.wikipedia.org/wiki/Factory_(software_concept)
• A factory externalizes the
creation of objects
• Creation and usage of
objects is decoupled
• Pattern definition works for
coding
Without factory:
DataAggregator da = new
DataAggregator();
With factory:
IDataAggregator aggregator =
DataAggregatorFactory.getInstance();

32. Factory – II
Apply on component level
• Externalization of creation of objects is a general pattern
How can OSGi help:
• Service registry provides an abstraction between provider
and consumer of a service (object instance)
• Creation of instances of a service can be handled by
frameworks:
– Declarative services
– Blueprint

33. Facade – I
A facade is an object that provides a simplified interface to a larger body of code,
such as a class library.
http://en.wikipedia.org/wiki/Facade_pattern
Facade:
public interface IDataAggregator {
public List<IDataItem> get();
}
Implementation of facade:
final class IdentityDataAggregator extends DataAggregator {
@Override
public ArrayList<IDataItem> get() {
List<IDataItem> itemList = new ArrayList<IDataItem>();
...
return itemList;
}
}

34. Facade – II
Apply on component level
• Access to a component as a general pattern
How can OSGi help:
1. Services are Java interfaces
1.
Service implementations are accessed via interface = facade
2. Exported packages are the only external visible entities of a
bundle
1.
2.
Not exported packages are not accessible
Clear definition of a facade of the bundle

35. Definition of
modules
Decoupling
•SOLID
•Design Pattern
Measurement
of metrics
Select modular
runtime
Active
definition of
system
Dependency Injection (SOLID)
Liskov (SOLID)
PRINCIPLES AND PATTERNS
- SOLID

36. Dependency Injection – I
Dependency injection involves at least three elements:
• a dependent consumer,
• a declaration of a component's dependencies, defined as interface
contracts,
• an injector (sometimes referred to as a provider or container) that creates
instances of classes that implement a given dependency interface on
request.
The dependent object describes what software component it depends on to do its
work. The injector decides what concrete classes satisfy the requirements of the
dependent object, and provides them to the dependent.
http://en.wikipedia.org/wiki/Dependency_injection

37. property
method
method
property
method
method
method
property
method
Class 1
method
property
method
Dependency Injection – II
Class 2

38. Dependency Injection – III
Apply on component level
• Reverse the dependency is a general pattern
How can OSGi help:
• Service registry provides an abstraction between provider
and consumer of a service (object instance)
• Injecting dependencies can be handled by additional
frameworks
– Declarative services
– Blueprint

39. Liskov
Let q(x) be a property provable about objects x of type T. Then q(y) should be
provable for objects y of type S where S is a subtype of T.
http://en.wikipedia.org/wiki/Liskov_substitution_principle
Facade = T:
public interface IDataAggregator {
public List<IDataItem> get();
}
Implementation of facade = S:
final class IdentityDataAggregator extends DataAggregator {
@Override
public ArrayList<IDataItem> get() {
List<IDataItem> itemList = new ArrayList<IDataItem>();
...
return itemList;
}
}

40. Definition of
modules
Decoupling
•SOLID
•Design Pattern
Measurement
of metrics
Select modular
runtime
Active
definition of
system
Architecture Layer
SYSTEM ARCHITECTURE

41. Architecture Layer – I
•
•
•
…
Package
…
Module
Sub system
System Layer
System
Platform
•
…
…
•
•
•
A platform (in terms of runtime framework)
hosts a system and is a versioned artifact
A system consists of a set of sub-systems and is
a versioned artifact running on a platform
A system layer groups sub-systems providing
structure and direction in terms of
dependencies and is a layer which has no
associated versioned artifact
A system layer incarnation is the bill of
materials or assembled sub-systems of a
system layer relevant for a specific use case
A sub-system consists of a set of modules and is
a versioned artifact
A module contains packages and is a versioned
artifact
A package contains components
–
–
A component is a File
A file is of type resource or source

42. Architecture Layer (as is) – II
Package
Module = Subsystem = Bundle
Package analysis of web application
Uses Structure 101 (see also JAX 2012 innovation award for Restructure 101)
System Layer

43. Architecture Layer (to be) – III
Data Display
(Servlet)
Data
Aggregator 1
Aggregator
Data Source 1
Data
Aggregator 2
Data Source 2
Data Provider
Data Aggregator
Interface
Data Aggregator Interface
Data Source Interface
UI
Data Source
Interface

44. Architecture Layer – IV
ConQAT (to-be diagram)
• ConQAT (https://www.conqat.org)
• Compared to Structure 101: extensible because of
open source
– Used to implement modularity metrics
• Easy integration in build process (Maven) 
automatic check of to-be and as-is

45. Demo ConQAT – I

46. Demo ConQAT – II

47. Definition of
modules
Decoupling
•SOLID
•Design Pattern
Measurement
of metrics
Select modular
runtime
Active
definition of
system
ConQAT structure check
Metrics
MEASUREMENT OF MODULAR
SOFTWARE

48. Demo ConQAT – III

49. Modularity Metrics – I
Coupling: determines the coupling of this component to other
components and is computed based on instability (Robert C.
Martin).
– I = Ce / (Ca+Ce) 1..0 (Ce (efferent) = outgoing, Ca (afferent) = ingoing)
– Consequence: the more components THIS component depends upon, the
more instable it is (0= stable, 1=instable)
Ca = usages of exported packages
Exported
Package
Exported
Package
(Internal Packages)
Imported
Package
Bundle
Imported
Package
Ce = imported classes in packages

50. Modularity Metrics – II
Relational Cohesion: a component should consist of cohesive
elements, otherwise, it should be splitted. Average number of
internal relationships per type.
– rc = Td / T (Td.. type relationships that are internal to this component; T..
number of types within the component)
As classes inside an assembly should be strongly related, the cohesion should
be high. On the other hand, too high values may indicate over-coupling. A
good range for RelationalCohesion is 1.5 to 4.0. Assemblies where
RelationalCohesion < 1.5 or RelationalCohesion > 4.0 might be problematic.
Therefore rcI is the normalized RC, having value 1 for 1.5 to 4, decreasing to 0
outside this range based on gaussian bell curve.

51. Modularity Metrics – III
Encapsulation: Components should encapsulate knowledge and
offer a slim interface.
– ep = pt / T (pt = private Types, T = all types)
pt = types in internal packages, T = types in internal packages +
types in exported packages
Exported
Package
Exported
Package
(Internal Packages)
Imported
Package
Bundle
Imported
Package
The Overall Modularity Score is now defined as:
– M = ((1-I) + rcI + ep) / 3.0

52. SUMMARY

53. Key take-aways
• Big software systems have to be structured, but more highlevel than packages
– Concrete implementation: OSGi sub systems
• Use iterative process to structure software during the whole
lifecycle of the product
• Implementation best practices support modularity
– Facade
– Factory
– Dependency Injection
• Modularity can be measured by metrics