1 G4MICE Design Iteration Malcolm Ellis MICE Video Conference 21 st April 2004

2 Iteration Process Collect Use Cases Determine User Requirements Identify components (that become classes) Group components into categories (that become domains) Test some of the design (CRC workshop) Detailed design Begin coding, testing and release procedure… Advertisement for a software course

3 Use Cases Use Cases list the things that the users (i.e. the collaboration) would like to do with the software (e.g. fit tracks, simulate RF background, etc…) Use Cases were solicited via and a web interface, results available here: – A few more Use Cases were added during the lead up to the software meeting to try to increase the coverage of the software to include a reasonable set of tasks.

4 User Requirements User Requirements list the specific functionality that the software must have in order to be able to perform all the tasks identified in the Use Cases. These were identified in the lead-up to the Software Workshop and finalised during the start of the workshop. Both Use Cases and User Requirements can be found on the design iteration page, which is linked from the software page:

5 Component Identification During the software workshop, everyone was assigned an area of responsibility and made a first pass at identifying the components (classes) that are needed. Many of these are the same, or similar, to classes already existing in G4MICE, others are new.

6 Domains Diagram Components that are related, and have similar relationships with other components are grouped into categories, which become domains (e.g. Reconstruction, Visualisation, etc…) The result of this is a domains diagram, which explicitly shows for a given domain what it depends on and what depends on it. This has implications for compilation and testing. The domains diagram can be seen on the design iteration page in GIF and PS formats.

7 Domains Diagram DetModel – model of the experiment EventModel – the classes that are needed to make simulation look like real data DetRep – representations of the experiment Analysis – classes/code to perform useful tasks Applications – where the executables are built

8 CRC Workshop At this stage, we had a rough design for most of the software and a slightly more detailed design for some of the components. We wanted to test the design of the particle ID related classes that we had at that point, and so conducted a CRC workshop. This allowed us to test the interfaces between classes and the implementation of various tasks, and allowed us to improve on the original design. I hope it also helped to give a better idea for how objects interact in an Object Oriented manner.

9 Workshop Results By the end of the workshop, we had achieved the following: – Completed Use Cases and Requirements – Determined components and categories – Started detailed design process – Documented all work done so far A design document can be found here: –

10 Detailed Design This process is now being carried out in parallel by the software group. Each person is to give a report on their design for the scrutiny of the group in coming software phone meetings (SciFi related code is the first, at next week’s meeting) As additions and modifications are approved, they will be incorporated into the design documents and diagrams available on the web

11 Coding, testing and release The detailed design should be completed by the summer. Yagmur has already prepared CVS areas for the new code (so that it can grow separately from the current version) and as designs are approved, the corresponding code will be added to the repository. In the lead-up to the change over to the new software, tests will be written to cover all Use Cases, and the correct release procedure will be used for all subsequent releases.

12 Software Course Simone Giani is a software engineering and project management expert whose expertise has been invaluable to HARP and who has already helped MICE a lot. Simone and I are currently putting together a hands-on course to cover the full software cycle from specifications and design, through implementation and testing, to delivery and operation of a product. The idea is that there would be two 1 week courses (the first at the end of August) where the theory and execution of best-practise software engineering will be studied. At the moment, it looks like the best time is outside of term (due to teaching commitments), but just before or after, to catch people before they go on holiday.

13 Software Course At the moment, we are considering several UK locations for the two weeks (e.g. Brunel and Glasgow). Anyone (students, post-docs, professors) who can contribute to the MICE software effort and who would like to learn about software engineering as we would like to implement it in MICE is encouraged to let me know. Although we will hold it in the UK, it will not be restricted just to UK participation. Please let me know if you are interested, and how many people from your institute may be able to come.