Vincenzo Innocente, BluePrint RTAGNuts & Bolts1 Architecture Nuts & Bolts Vincenzo Innocente CMS

Vincenzo Innocente, BluePrint RTAG Nuts & Bolts 2 No Flames It is very difficult to use as (good/bad) example any of those marvelous frameworks and toolkits that never made it into a popular product All my respect goes to those who developed products that have the misfortune to be daily used by thousand of people and are easy target for my (positive/negative) criticisms… AHisto.fill TObject.draw ~G4RunManager Please accept my apologies

Vincenzo Innocente, BluePrint RTAG Nuts & Bolts 3 CMS Data Analysis Model Detector Control Online Monitoring Environmental data store Request part of event Simulation store Data Quality Calibrations Group Analysis User Analysis on demand Request part of event Request part of event Store rec-Obj and calibrations Quasi-online Reconstruction Request part of event Store rec-Obj Persistent Object Store Manager Database Management System Event Filter Object Formatter PhysicsPaper

Vincenzo Innocente, BluePrint RTAG Nuts & Bolts 4 Federation wizards Detector/Event Display Data Browser Analysis job wizards Generic analysis Tools ORCA FAMOS Objytools GRID OSCAR COBRA Distributed Data Store & Computing Infrastructure CMStools Architecture Overview Consistent User Interface Coherent set of basic tools and mechanisms Software development and installation

Vincenzo Innocente, BluePrint RTAG Nuts & Bolts 5 Simulation, Reconstruction & Analysis Software System Specific Framework ODBMS Geant3/4 CLHEP Paw Replacement C++ standard library Extension toolkit Reconstruction Algorithms Data Monitoring Event Filter Physics Analysis Calibration Objects Event Objects Configuration Objects Generic Application Framework Physics modules adapters and extensions Basic Services Grid-Aware Data-Products Grid-enabled Application Framework Uploadable on the Grid LCG

Vincenzo Innocente, BluePrint RTAG Nuts & Bolts 6 Framework Dynamics Customized Extension (client plug-in) Client API Framework API Flow of control Call backs Framework: Controls flow of execution Defines object interaction (implementing design patterns) Calls client (plug-in) functions May offer a traditional “client API” for integration in more specialized frameworks Clients specialize framework behavior: Inheriting from framework classes Overwriting their methods Instantiating other framework classes Interacting directly with other, more general, frameworks

Vincenzo Innocente, BluePrint RTAG Nuts & Bolts 7 Devil is in the Details Build independent components: Avoid Dependencies among components at the same level Gratuitous and exaggerated re-use One hammer does not fit all screws global states (even cout) Exposure of internal relationships (a->b()->c(i)->d(“b”)) assumptions on higher level behavior (lent pointers) Interfaces that force your environment on user code Balance inheritance (white box) vs composition (black box) Distinguish Framework API, Client API and User API These are Architectural issues NOT coding guidelines I do not mind of “#define int float” in your.cc, I mind if in a.h

Vincenzo Innocente, BluePrint RTAG Nuts & Bolts 8 Examples Exceptions throw internal exception (avoid inheriting from std::exception?) Catch it in the framework adapter and throw appropriate framework exception Algorithms do not throw a CARFSkipEventException deep inside No one even think of inheriting from Python exceptions Do not hardcode cout CobraOut G4out If really critical, implement a proper messanger: Every package implement one based on some “pattern” An adapter takes care of the communication with the framework Use envelops (not Proxies) and facades toward the user Stick to the standard and the language (avoid being smarter) In CMS we could add Architecture.h (config.h) on the fly at each.cc just before compiling Do not use Cint or Python where native C++ suffices

Vincenzo Innocente, BluePrint RTAG Nuts & Bolts 9 Package Metrics Size = total amount of source code (roughly—not normalised across projects!) ACD = average component dependency (~ libraries linked in) CCD = sum of single-package component dependencies over whole release Indicates testing/integration cost NCCD = Measure of CCD compared to a balanced binary tree A good toolkit’s NCCD will be close to 1.0 < 1.0: structure is flatter than a binary tree (= independent packages) > 1.0: structure is more strongly coupled (vertical or cyclic) Aim: Minimise NCCD for given software/functionality

Vincenzo Innocente, BluePrint RTAG Nuts & Bolts 10 Metrics: NCCD vs Cycles Toolkits & Frameworks ATLAS ORCA Anaphe IGUANA COBRA G4 ROOT

Vincenzo Innocente, BluePrint RTAG Nuts & Bolts 11 Toward a Project Praxis Define the global software model Granularity, role and nature of “Modules” Physical vs logical modules (yesterday at CMS plenary M.Livny concluded asking for staticly linked, check-pointable executables…) Reuse model of sub-components Which “glues” have to be used, where and how Define THE set of basic components Agree on Metrics to measure modularity Not only Frameworks, also applications based on them