1 SMWG Service Management Book Refactoring Report Anthony Crowson Colin Haddow October 2009, ESTEC October 15, 2008

2 SMWG Book Refactoring TM TC Bilateral Core Split current book into Core and Services  Prepare to add new services without changing Core

3 SMWG Book Refactoring  How did we change Nicolas’ model? Not much! Moved some details down to Forward / Return books - E.g. Carrier parameters - Which meant add placeholders in Core Rationalised (we think) parallel structures - Space Link Events Started introducing stereotypes to formalise the colour- coding

4 SMWG What did we do?  Cut & paste text to one of the new books  Replace diagrams with Magicdraw And a couple of new ones  Minor rewording, not fully consistently Remove > Consistency with new model  “Template” extension book not worked out

5 SMWG Examples

6 SMWG Service Books Collation  Core as B1 with deletions  Service Books: Table contents moved No new text written

7 SMWG Conclusions  Yes, the approach is feasible  No major problems But plenty to discuss  Core remains large Can we reduce repetition?

8 SMWG Suggestions  Consider re-arranging chapters e.g. Information Structures: common to Configuration Profile, Service Package, Service Agreement - Carrier Profile - RetrievalTsProfile - Event Sequence - etc Service Specs - Common structures within service e.g. identical / similar between Request and Return - Operations Move Document Exchange Protocol to own book? - Supported by idea of alternative mechanisms - All of it? Or are message patterns still fundamental?

9 SMWG Future Discussions  How prescriptive can / should we be about where model can be extended? We have «extensionPoint» Should all others be non-extensible? Should some specific ones be non-extensible?  Decisions on what level things should be at - Retrieval in general – currently only applies to return services, but could apply in future to e.g. ranging Parameters duplicated between R and F services. BUT in some cases constrained by different SA parameters. General approach policy needed.

10 SMWG Future discussions  Section numbering: try to preserve 1:1 match?  Requirements Numbering E.g. ASCSPU-FW-1 for forward service book  Namespace / naming convention for extended diagnostic sets Lower level adds diagnostics specific to the service Impact on schema needs to be taken into account.  Multiple inheritance Will probably all go anyway  Modelling tool & version Magicdraw 16.5 used so far 16.6 now out, some useful improvements claimed

11 SMWG Book Refactoring: Pages  Blue-1 (Chapter 4, 5, 6, 7) – 322  Core – 268 Only 17% reduction! Fully formatted as B-1  Service Books just the bits cut out of core no new / copied text  Forward – 23  Return – 36  Bilateral – 14  Final ratios will be less extreme!

12 SMWG Repetition  BB is a BIG book  After refactoring, Core is still large  Yes, there is lots to say, but… Some of it gets said rather often!  Repetition adds to the perception of complexity  Can we make it more DRY ? DRY Don’t Repeat Yourself

13 SMWG Repetition  Example: 3-Phase Operations  NOT an attack on current approach!  Illustration of one aspect to examine

14 SMWG Repetition Example  Every 3-Phase Operation says

15 SMWG Repetition Example  Every 3-Phase Operation says ? ? ?

16 SMWG Repetition Example  Every 3-Phase Operation says

17 SMWG Repetition  Other aspects of repetition include UML relationships described in text More generally: does expressing syntax rules as requirements add to perceived complexity of spec? Is there a better way to textualise the UML? +

18 SMWG Repetition  For repetition Everything spelt out where it’s used Less need for cross-referencing, looking up  Against repetition  More to read and recognise as “the same as last time”  Repeated edit on change  Opportunities for inconsistency  Size  Can we find clear but less repetitive approach?