110 likes | 351 Views
Architecture Nuts & Bolts . Vincenzo Innocente CMS. 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
E N D
ArchitectureNuts & Bolts Vincenzo Innocente CMS Nuts & Bolts
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… Nuts & Bolts AHisto.fill TObject.draw ~G4RunManager Please accept my apologies
CMS Data Analysis Model Quasi-online Reconstruction Environmental data Detector Control Online Monitoring store Request part of event Store rec-Obj Request part of event Event Filter Object Formatter Request part of event Nuts & Bolts store Persistent Object Store Manager Database Management System Store rec-Obj and calibrations Physics Paper store Request part of event Data Quality Calibrations Group Analysis Simulation User Analysis on demand
Architecture Overview Data Browser Generic analysis Tools GRID Distributed Data Store & Computing Infrastructure Analysis job wizards Objy tools ORCA COBRA OSCAR Nuts & Bolts FAMOS Detector/Event Display CMS tools Federation wizards Software development and installation Coherent set of basic tools and mechanisms Consistent User Interface
LCG Simulation, Reconstruction & Analysis Software System Uploadable on the Grid Physics modules Specific Framework Event Filter Reconstruction Algorithms Physics Analysis Data Monitoring Nuts & Bolts Grid-enabled Application Framework Generic Application Framework Calibration Objects Configuration Objects Event Objects Grid-Aware Data-Products adapters and extensions Basic Services C++ standard library Extension toolkit ODBMS Geant3/4 CLHEP Paw Replacement
Client API Flow of control Framework API Call backs Framework Dynamics 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 Nuts & Bolts Clients specialize framework behavior: Inheriting from framework classes Overwriting their methods Instantiating other framework classes Interacting directly with other, more general, frameworks Customized Extension (client plug-in)
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 Nuts & Bolts
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 Nuts & Bolts
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 Nuts & Bolts
Metrics: NCCD vs Cycles ATLAS Nuts & Bolts ROOT ORCA G4 COBRA Anaphe IGUANA Toolkits & Frameworks
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 Nuts & Bolts