1 G4MICE Design Iteration Malcolm Ellis Imperial College Saturday 3 rd April 2004

2 Tasks for this workshop Saturday - Complete User Requirements Monday - Architectural Design – people should think about it over Sunday however! Tuesday - Detailed design rationale and CRC workshop Wednesday – Finalise interfaces and documentation, agree on responsibilities, coding “rules” and testing procedures Everyone returns home and starts detailed design

3 Some coding suggestions 7 ± 2 Rule – methods should not have too many lines! Methods which have no or very little functionality should be inline after the class declaration. Do not pass parameters by copy, prefer in order: const reference, reference, pointer All methods that can be declared const should be. Each package should have a clear policy on the ownership of newed objects (perhaps even for the whole software?) Be sure not to return pointers or references to temporary objects. Doxygen comments as you write the code!

4 More ideas… Use prefix ++ on iterators If method needs to return a class, and you would normally return a NULL pointer to indicate failure – consider instead using an “unhappy object”. Always give a concrete definition for the copy constructor, assignment operator and destructor (even for virtual classes). If you don’t want to define one, then at least declare it as private! When using pointers, always set them to NULL immediately after deleting them. Be careful not to have return with no argument in non- void functions.

5 In Addition How keen are we to do things in an Object Oriented manner? I’ve assumed that we are, but maybe there are other opinions? If we are doing this OO, then by definition there shall be no public or friend variables in classes, nor shall there be any global variables. We should definitely avoid making the classes de-facto C structs with set/get methods: Triplet point(); point.setVhit( h1 ); point.setXhit( h2 ); point.setWhit( h3 ); Triplet point( h1,h2, h3 );

6 Possible requirements for code acceptance Compiles with no warnings (exceptions may be necessary due to external packages, e.g. GEANT4). Passes all reference tests (Unit and System) for the package. Does not contain any hard-coded constants. Code containing new functionality should be supplied with reference tests whenever possible.

7 User Requirements Purpose is to describe the features and capabilities of our software. They will help to formalise the meaning and tasks of the various objects. We do not need to drag this process out, but should ensure that we cover all the areas listed in the Use Cases

8 Architectural Design Not enough time for detailed design, however the definition of the subsystems and in particular the interfaces between them is crucial. Keep references between requirements and subsystems of the domains diagram. Avoid discussions of implementation or similar detail – that is for the detailed design stage, which will be started at the end of the workshop. Detailed design will be done by everyone after the workshop.

9 Possible New Domains Persistent implementation of whatever transient classes we end up with (maybe similar to the HARP iDST system?) G4Beamline? Detector/Experiment Modelling and Representations Any others? We shall find out on Monday!

10 CRC Workshop Class Responsibility Collaboration Role-play where we all pretend to be instances of candidate objects Use cards to record details of the class and its responsibilities. Methods are visible to everyone, state (variables) are not. Three principle aims: –Refuse responsibilities (with justification!) –Minimise workload (delegate) –Empower collaborators Usually part of detailed design – still useful now

11 Example Sci Fi Diagram SciFiDoubletCluster SciFiDoubletCluster( const SciFiDigi& ) const ScidiFigi& digi() const int tracker() const Hep3Vecor position() const Hep3Vector direction() const const SciFiDigi& m_digihit … 1 SciFiDigi SciFiDigi( ??? ) int tracker() const int station() const int plane() const int fibre() const int adc() const int m_tracker int m_station …

12 Refuse Responsibilities For each request, each object should ask itself: –Should I? (that is, does this request fall outside of the “thing” that I am supposed to represent) –Could I? Have I been given enough information Am I clear exactly what is needed Do I have the information (state) to perform the task –These questions test the Interface and Implementation of the class.

13 Delegate Tasks Just because you (the class) have accepted the responsibility, it does not mean that you have to do everything! If you have access to another object (or objects) which are suitable to perform the task (or some part of it) then forward the request. Simple example – SciFiDoubletCluster::tracker() method could ask the SciFiDigi class what the tracker number is

14 Empower Collaborators It should not be necessary to know how classes work, and it is preferable not to access classes which are too far away (along links). Prefer: –SciFiKalTrack.addPoint( SciFiSpacePoint ) Over: –( SciFiKalTrack.points() ).add( SciFiSpacePoint )

15 Next Step We should now take the Use Cases and derive the relevant User Requirements from them and enter them into the document in real time…