1. Object Networks—ATLAS' Future Control Framework For Offline?
Object Networks—ATLAS' Future Control Framework For Offline?
Lassi A. Tuura
CERN/EP Division
Software Architecture WG
Lassi A. Tuura, CERN/EP Division
Lassi A. Tuura, CERN

2. Presentation Overview
Presentation Overview
What Is It?
Strategic Design Decisions
Other Design Goals
Example Network
Implementation Details
Lassi A. Tuura, CERN/EP Division
Lassi A. Tuura, CERN

3. What Is It?
The control framework is the part of the infrastructure that makes sure that
the right piece of software
runs
at the right time
with the right inputs and
the outputs go to the right place
Lassi A. Tuura, CERN/EP Division

4. Strategic Design Decisions #1
Fully object-oriented design, mainly in C++
Modular core infrastructural domains
Mutually independent (orthogonal) in design
As toolkits—collections of co-operating classes for app or app framework construction
Will not try to take over and dominate application design, data or execution
Code movability among analysis, offline reconstruction and event filter
Lassi A. Tuura, CERN/EP Division

5. Strategic Design Decisions #2
Separation of computational and data objects
Use a component model
Package computational units (algorithms) as replaceable components
Components have well-defined interfaces
Communication across component boundaries only in ways provided by the control framework
Recognise data-flow nature of the problem
Lassi A. Tuura, CERN/EP Division

6. Strategic Design Decisions #3
Event is not a scratch pad storage
Global knowledge ("everybody knows that…") gets quickly out of hand—no different from global variables or COMMON blocks
Components name true data dependencies
Framework reasons about the dependencies
When accompanied by wise component design, significantly improves reusability
Lassi A. Tuura, CERN/EP Division

7. Strategic Design Decisions #4
Treat all data types the same
Attach no meaning to any type
Event is not special to the framework
Note: Code reuse is not limited to component reuse—code can be shared across components in non-component form
Lassi A. Tuura, CERN/EP Division

8. Other Design Goals Instant gratification
Framework separate from the components
Dynamically load and unload components
Visual feedback in interactive environment
Spy on data as it "flies by"—components will not notice anything, spies are components too
Allow application to be described as a script that is read, verified, components loaded, initialisation carried out, and network executed
Lassi A. Tuura, CERN/EP Division

9. Example Network Colors = data types Modules = behaviour
Whole network = component
Input-Output dependency
Lassi A. Tuura, CERN/EP Division

10. Implementation Details #1
Framework holds onto data objects via facets
Kind of a handle that can reduce to a pointer
A type can have any number of facets: transient, reference counting, database, …
Data does not flow anywhere
Outputs hold objects
Inputs observe the outputs they are connected to, methods observe their inputs
Notifications are sent when data changes
Lassi A. Tuura, CERN/EP Division

11. Implementation Details #2
Notifications do not result in immediate execution, only an action is scheduled for execution
Action queue ordered by data dependencies
Actions pulled from the queue and executed
More actions may be queued as a result of executing the most recently chosen action
Spontaneously generated actions can be queued by GUIs, network components
Queues can be stacked  loops, recursion
Lassi A. Tuura, CERN/EP Division

12. Implementation Details #3
Methods are notified if their inputs have changed
Only if the inputs have changed
If any of the inputs have changed
Required inputs must have values when the call is delivered
Networks can be packaged as components
Reuse as-is in a larger application
Reconfigure: alter parameters but do not change the network
Tear apart and reconfigure: reuse constituents
Lassi A. Tuura, CERN/EP Division

13. Implementation Details #4
Networks can execute in any context
A normal method can be internally a network
A network can run inside another network
Runs till no more actions to execute and then returns to the caller
Lassi A. Tuura, CERN/EP Division