1. 1 Planning for Reuse (based on some ideas currently being discussed in LHCb ) m Obstacles to reuse m Process for reuse m Project organisation for reuse m Project phases m Plans for immediate future m Points for discussion John Harvey CERN EP-ALC

2. 2 Obstacles to Reuse m Engineering â poor design and implementation â lack of flexibility in components â too broad functionality in components â poor access to component libraries m Process â role of architect not defined â technical review procedures fail to address reuse â from existing software, identify what could be packaged for reuse

3. 3 Obstacles to Reuse m Organisational â reuse requires a broad overview we tend to split into separate domains…divide and conquer each project tends to be managed independently of the others â culture don’t trust others to deliver what we need fear of dependency on others fail to share information with others developers fear loss of creativity Reuse is a management activity - need to provide the process and organisation to make it happen

4. 4 Process for Reuse Manage Plan, initiate, track, coordinate Set priorities and schedules, resolve conflicts Support Support development processes Manage and maintain components Certify, classify, distribute Document, give feedback Assemble Design application Find and specialise components Develop missing components Integrate components Requirements Existing software systems Build Develop models, Evaluate toolkits Architect components and systems Choose integration standard Engineer reusable components

5. 5 Project Organisation Support Facilities CPU farms Desktop Storage Network System Man. Vendors IT-IPT.. Vendors IT-PDP Vendors IT-ASD Support Software SDE Process Quality Librarian Training Webmaster M Data Management Event, Geometry M M Build Architecture Components Frameworks, Glue A Toolkits GUI, visual,…... M Reconstruction M Simulation M Analysis M Controls M Control Room M Assemble DAQ M Manage Steering Group MM C Technical Review EM A LHCb Computing... Arch. Review MA E... M A C E Coordinator Architect Project Manager Project Engineer

6. 6 Online Coordinator Offline Coordinator DAQ Hardware DAQ Software Slow Controls SimulationAnalysisEvent Display Detector Description Event Display Detector Description Detector Description Traditional Project Organisation

7. 7 Project Phases Preparatory Phase activities : OO migration, prototyping, technology evaluation, requirements analysis, maintain production software deliverables : functional specifications, architectural design, software process and development environment, organisational structure, decisions on technologies Implementation Phase select, build and test components develop applications stand-alone tests Commissioning Phase Install and integrate applications to make working systems, test in production environment Operation Phase Bring all systems into production 6 months before datataking ‘98 ‘00 ‘02 ‘04 ‘06

8. 8 Strategy for next two years m Dilemma â have to keep existing software in production â update practices, use new technology for future development m OO Migration â migrate people as soon as possible â minimise ‘legacy’ code â need to setup a process and environment now â train - ‘just-in-time’, CERN training programme â algorithm development ongoing wrap to be able to use in existing FORTRAN environment â evaluate new toolkits â start component development (event model, geometry, ….) m Share ideas, designs, components etc. with other experiments m Don’t start too many activities, exploit what has been done so far

9. 9 Schedule for next two years 19981999

10. 10 For discussion? m Is reuse sufficiently important to put in place a specific process and organisation that support it? m Should all aspects of Computing be treated in one project structure? m Should there be a role for architects and for architectural review? m What components are out there (other experiments, commercial….) that we can start to use e.g. event model, geometry model,….?

11. 11 Architecture m Definition â principles, mechanisms and patterns that define and communicate the structure of a system m Notation â designs communicated using a modeling notation e.g. OOA and OOD m Benefits of architecture-driven development â allows development of understandable systems that are easier to maintain â allows applications and components to evolve gracefully â enables developers to achieve a significant level of reuse â enables components to work well together

12. 12 Widely used terms m Component â is a piece of software engineered to be reusable â should be cohesive i.e. perform well-defined function â have a stable public interface m Component systems â groups of related components providing more complete set of functionality m Layering â components can be built from lower-level components m Frameworks â implements core functionality of domain architecture, provides mechanisms to shape all applications developed using it m Interface Glue (Integration Technology) â user’s view of a component system â should conform to an appropriate architecture/industry standard â should not expose too much to permit future evolution â involves negotiation between architect, engineer and user

13. 13 Industrial Figures on Components m Must be used at least 3-5 times to cover cost of creating and supporting m costs ~ twice as much to create and support a re-usable component as opposed to implementing it in a given application m costs ~a quarter as much to reuse a component as it does to develop one from scratch m takes ~3 years before benefits of reuse become significant

14. 14 Lego ® bricks Component (building block) Interface glue (integration technology) ® proprietary Fischer Technik

15. 15 Application Domains