Architecture nuts bolts l.jpg
This presentation is the property of its rightful owner.
Sponsored Links
1 / 11

Architecture Nuts & Bolts PowerPoint PPT Presentation


  • 117 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

Architecture Nuts & Bolts

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Architecture nuts bolts l.jpg

ArchitectureNuts & Bolts

Vincenzo Innocente

CMS

Nuts & Bolts


No flames l.jpg

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 l.jpg

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 l.jpg

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


Simulation reconstruction analysis software system l.jpg

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


Framework dynamics l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

Metrics: NCCD vs Cycles

ATLAS

Nuts & Bolts

ROOT

ORCA

G4

COBRA

Anaphe

IGUANA

Toolkits &

Frameworks


Toward a project praxis l.jpg

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


  • Login