Architecture Nuts

1
ArchitectureNuts Bolts

• Vincenzo Innocente
• CMS

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
3
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
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
4
Architecture Overview
Data Browser
Generic analysis Tools
GRID
Distributed Data Store Computing Infrastructure
Analysis job wizards
Objy tools
ORCA
COBRA
OSCAR
FAMOS
Detector/Event Display
CMS tools
Federation wizards
Software development and installation
Coherent set of basic tools and mechanisms
Consistent User Interface
5
Simulation, Reconstruction Analysis Software
System
Uploadable on the Grid
Physics modules
Specific Framework
Reconstruction Algorithms
Data Monitoring
Event Filter
Physics Analysis
Grid-enabled Application Framework
Calibration Objects
Event Objects
Configuration Objects
Generic Application Framework
Grid-Aware Data-Products
adapters and extensions
Basic Services
C standard library Extension toolkit
ODBMS
Geant3/4
CLHEP
Paw Replacement
6
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
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)
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

8
Examples

• Exceptions
• throw internal exception
• (avoid inheriting from stdexception?)
• 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

9
Package Metrics

• Size total amount of source code (roughlynot
  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 toolkits NCCD will be close to 1.0
• independent packages)
• 1.0 structure is more strongly coupled
  (vertical or cyclic)
• Aim Minimise NCCD for given software/functionalit
  y

10
Metrics NCCD vs Cycles
ATLAS
ROOT
ORCA
G4
COBRA
Anaphe
IGUANA
Toolkits Frameworks
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