Object Networks—ATLAS' Future Control Framework For Offline? 1998-09-03 Object Networks—ATLAS' Future Control Framework For Offline? Lassi A. Tuura CERN/EP Division Software Architecture WG Lassi A. Tuura, CERN/EP Division 1999-06-24 Lassi A. Tuura, CERN

Presentation Overview 1998-09-03 Presentation Overview What Is It? Strategic Design Decisions Other Design Goals Example Network Implementation Details Lassi A. Tuura, CERN/EP Division 1999-06-24 Lassi A. Tuura, CERN

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 1999-06-24

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 1999-06-24

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 1999-06-24

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 1999-06-24

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 1999-06-24

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 1999-06-24

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

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 1999-06-24

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 1999-06-24

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 1999-06-24

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 1999-06-24