0
Building Modular Software with
OSGi
Ulf Fildebrandt
Some words before
This presentation should…
• …give some insights in big software products
• …and how the structure of the...
About the presenter
•
•
•
•
•

Ulf Fildebrandt
Studied computer science
Works for SAP since 1998
Starting with C++ and COM...
Agenda
Problem
statement

Goals

Implementation
of Modularity

Measurement of
Modularity
„In every phenomenon the beginning remains
always the most notable moment.“
Thomas Carlyle

Findbugs Analysis by Structure...
Findbugs Analysis
• Famous analysis done by Ian Sutton
• Can be found at
http://structure101.com/blog/2008/11/softw
are-er...
Findbugs 0.7.2
Findbugs 0.8.6
Findbugs 0.8.7
Findbugs 1.0.0
Findbugs 1.3.0
Findbugs 1.3.5
Server Analysis
• SAP Java server’s own analysis tool
• It shows the structure of the current
Netweaver server
• In contra...
Structure of Complex System – I
Overview of product

http://pwdfm295.wdf.sap.corp:9090/makeresults/ce.lc.reporting/NW730EX...
Structure of a Complex System – II
Basic Scenario
Structure of a Complex System – III
Detailed dependencies
„...it is almost always incorrect to begin the
decomposition of a system into modules on the
basis of a flowchart. We prop...
Software Development Goals
Modules
Manage complexity of software
systems by „divide and conquer“
(see
http://firstround.co...
Software Development Goals
Principles
Extensibility

Substitutability

A module is a self-contained component of a system,...
Software Development Goals
One Product

One system can evolve over time and modules can be replaced without impacting
the ...
Software Development Goals
Multiple Products

Product 1

Product 2

Common modules
Multiple systems can be assembled in di...
Demo
„Programming without an overall architecture
or design in mind is like exploring a cave with
only a flashlight: You don't ...
Process to define modular software
Select modular
runtime

Definition of
modules

Measurement of
metrics

Decoupling
•SOLI...
Definition of
modules

Decoupling
•SOLID
•Design Pattern

Measurement
of metrics

Select modular
runtime

Active
definitio...
Package Dependencies of a Bundle
Bundle
(internal packages)
Imported
Package

Imported
Package

Exported
Package

Exported...
Lifecycle of a Bundle
install
installed

start

starting

resolve
uninstall

resolved
uninstall
uninstalled

active
stop
s...
How to achieve modularity...
• OSGi is a framework on top of Java
• Complements Java very good
• ...but not suffient, beca...
Subsystems
• Subsystems bundle many
OSGi bundles
• Defined in OSGi R5
Enterprise Specification
• Reference
implementation ...
Definition of
modules

Decoupling
•SOLID
•Design Pattern

Measurement
of metrics

Select modular
runtime

Active
definitio...
Factory – I
A factory is an object for creating other objects. It is an abstraction of a constructor.
http://en.wikipedia....
Factory – II
Apply on component level
• Externalization of creation of objects is a general pattern
How can OSGi help:
• S...
Facade – I
A facade is an object that provides a simplified interface to a larger body of code,
such as a class library.
h...
Facade – II
Apply on component level
• Access to a component as a general pattern
How can OSGi help:
1. Services are Java ...
Definition of
modules

Decoupling
•SOLID
•Design Pattern

Measurement
of metrics

Select modular
runtime

Active
definitio...
Dependency Injection – I
Dependency injection involves at least three elements:
• a dependent consumer,
• a declaration of...
property
method

method

property
method

method

method

property
method

Class 1

method

property
method

Dependency In...
Dependency Injection – III
Apply on component level
• Reverse the dependency is a general pattern
How can OSGi help:
• Ser...
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 whe...
Definition of
modules

Decoupling
•SOLID
•Design Pattern

Measurement
of metrics

Select modular
runtime

Active
definitio...
Architecture Layer – I
•
•
•

…
Package

…

Module
Sub system
System Layer

System
Platform

•

…
…

•
•
•

A platform (in...
Architecture Layer (as is) – II

Package

Module = Subsystem = Bundle
Package analysis of web application
Uses Structure 1...
Architecture Layer (to be) – III
Data Display
(Servlet)

Data
Aggregator 1

Aggregator

Data Source 1

Data
Aggregator 2

...
Architecture Layer – IV
ConQAT (to-be diagram)
• ConQAT (https://www.conqat.org)
• Compared to Structure 101: extensible b...
Demo ConQAT – I
Demo ConQAT – II
Definition of
modules

Decoupling
•SOLID
•Design Pattern

Measurement
of metrics

Select modular
runtime

Active
definitio...
Demo ConQAT – III
Modularity Metrics – I
Coupling: determines the coupling of this component to other
components and is computed based on in...
Modularity Metrics – II
Relational Cohesion: a component should consist of cohesive
elements, otherwise, it should be spli...
Modularity Metrics – III
Encapsulation: Components should encapsulate knowledge and
offer a slim interface.
– ep = pt / T ...
SUMMARY
Key take-aways
• Big software systems have to be structured, but more highlevel than packages
– Concrete implementation: O...
Upcoming SlideShare
Loading in...5
×

Building modular software with OSGi - Ulf Fildebrandt

1,607

Published on

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

ABSTRACT

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,607
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
60
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Transcript of "Building modular software with OSGi - Ulf Fildebrandt"

  1. 1. Building Modular Software with OSGi Ulf Fildebrandt
  2. 2. Some words before This presentation should… • …give some insights in big software products • …and how the structure of these products is managed
  3. 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. 4. Agenda Problem statement Goals Implementation of Modularity Measurement of Modularity
  5. 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. 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. 7. Findbugs 0.7.2
  8. 8. Findbugs 0.8.6
  9. 9. Findbugs 0.8.7
  10. 10. Findbugs 1.0.0
  11. 11. Findbugs 1.3.0
  12. 12. Findbugs 1.3.5
  13. 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. 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. 15. Structure of a Complex System – II Basic Scenario
  16. 16. Structure of a Complex System – III Detailed dependencies
  17. 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. 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. 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. 20. Software Development Goals One Product One system can evolve over time and modules can be replaced without impacting the other modules.
  21. 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. 22. Demo
  23. 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. 24. Process to define modular software Select modular runtime Definition of modules Measurement of metrics Decoupling •SOLID •Design Pattern Active definition of system
  25. 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. 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. 27. Lifecycle of a Bundle install installed start starting resolve uninstall resolved uninstall uninstalled active stop stopping
  28. 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. 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. 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. 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. 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. 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. 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. 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. 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. 37. property method method property method method method property method Class 1 method property method Dependency Injection – II Class 2
  38. 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. 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. 40. Definition of modules Decoupling •SOLID •Design Pattern Measurement of metrics Select modular runtime Active definition of system Architecture Layer SYSTEM ARCHITECTURE
  41. 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. 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. 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. 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. 45. Demo ConQAT – I
  46. 46. Demo ConQAT – II
  47. 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. 48. Demo ConQAT – III
  49. 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. 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. 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. 52. SUMMARY
  53. 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
  1. Gostou de algum slide específico?

    Recortar slides é uma maneira fácil de colecionar informações para acessar mais tarde.

×