This document discusses the concepts of modularity and dynamism in software systems. It provides three examples from 1970-1976 that describe modularity as developing systems in separate and distinct modules that can be independently tested and replaced without disassembling the entire system. The document then contrasts modularity with dynamism, which allows for asynchronous updates and changes in applications and their environments. It argues that dynamism breaks traditional assumptions and requires approaches like components, interfaces, dependency injection and lifecycles to enable adaptable and flexible systems.

1. Modularity & Dynamism
A Tale of Two Sisters
Dr. Clement Escoffier

2. Time Travel

3. –R. Gauthier and S. Pont, Designing Systems Programs, 1970.
“Each task forms a separate, distinct program
module. At implementation time each module
and its inputs and outputs are well-defined. At
checkout time the integrity of the module is
tested independently. Finally, the system is
maintained in modular fashion.”

4. –D. Parnas, On the Criteria to Be Used in Decomposing Systems into
Modules, 1972.
“The major advancement in the area of
modular programming has been the
development of coding techniques and
assemblers which
(l) allow one module to be written with
little knowledge of the code in another
module, and
!
(2) allow modules to be reassembled and
replaced without reassembly of the whole
system.”

5. –R.S. Fabry, How to design a system in which modules can be changed on
the fly, 1976.
If the module does manage permanent
data structures which must be modified
and the system is one which is expected to
continue operation throughout the
change, the problem is more difficult, but
it can be solved. This paper discusses a
solution.

6. Modularity
a (not that) simple idea

12. The
trend…

14. Dependencies

15. Compatibility

16. Boot Sequence
&
Stabilization

17. Reuse / Generic
vs.
Performance

18. Dynamism
The forgotten sister

19. Dynamism
(Asynchronous)
Update
Event in the
surrounding
environment
Change in the
application
context

20. Very specific and
limited to
particular domains

22. Ubiquitous
Computing
Machine
to
Machine
Internet
of
Things
Pervasive
Environment

23. Application
Servers
Set-top
Box
Enterprise
Server
(JavaEE)
Custom
App
Servers

24. Enterprise
Applications
Heavily
Distributed
Managed
by many
stakeholders
Malleable
Topology

25. Cloud, Mobile…
Ever-Changing Dynamic Resources
Disruptions

27. Dynamism breaks the
simplest assumptions
if (service != null) {
service.serve();
}

30. Simplification
of the development
model
All types
of dynamism
Adaptable ,
Flexible and
Customizable

31. Components

32. Interfaces
Required
Provided

33. Dependency
Injection

34. Lifecycle

35. Dynamic Availability

36. Dynamic Availability
X! X!

37. On the role of the Service Registry
Registry
1 - Publication
2 - Lookup,
Notifications,
Selection
3 - Binding

38. The new super-powers

39. Constructor injection
public Component (
@Requires ApplicationConfiguration configuration,
@Property(name="p",value="d") String prop,
@Context BundleContext ctx) {
//…
}

40. Temporal => Timeout
Hold the line,
back in a sec

41. @Configuration
@Configuration
public class MyConfiguration {
!
Instance businessA =
instance()
.named("A")
.of(BusinessImpl.class)
.with("name").setto("A");
}

42. Context-Sources
filter=
“(version=${my.version})”

43. Stereotypes &
Manipulator Modules
@Controller
@Component
@Provides
@Instantiate

44. Interceptors

45. iPOJO 2.x
Roadmap

46. Manip@Runtime

47. Inheritance

48. New Manipulation
Machine
Interceptor Chains Indy ?

49. Intra-Bundle
Injection

50. End Of
File