[Smwg] RE: SOS and common header -- follow up re class diagram

[Barkley, Erik J (3970)]

Colin,

Okay. The point about using MagicDraw is a good one. However that does imply that whoever picks up being the book boss for the other recommendations that need to make use of the standard header etc. will have access to and use MagicDraw. Or at a minimum it implies that someone within the working group will always be the MagicDraw "provider". Nonetheless I think this is all workable and I think we should proceed with the diagram as you have updated it.

Best regards,

-Erik


-----Original Message-----
From: Colin.Haddow at esa.int [mailto:Colin.Haddow at esa.int] 
Sent: Wednesday, January 21, 2015 4:33 AM
To: Barkley, Erik J (3970)
Cc: CCSDS Service Mgmt WG
Subject: Re: SOS and common header -- follow up re class diagram

Hi Erik,
               I don't think that the stereotype route is the way to go, partly because I've spend most of this morning wading thru' my UML books and fighting MagicDraw and, after a brief discussion with Anthony, have come to the conclusion that stereotypes don't really provide the capabilities to do what you suggest. Also I think that showing the instantiation of the specific data entities from the abstract Service Management Data Entity classes in each book is not a bad thing, as it makes it clear that these are derived from standard data structures. Since we're now using MagicDraw as the modelling tool I don't see any real problem with possible inconsistencies between the books.

However I've tweaked the diagram a bit (to make the abstract classes more
obvious) and added some explanatory text to make things clearer and this is attached below. Comments appreciated.

Cheers for now,

Colin

(Embedded image moved to file: pic26439.gif)


---------------------------------------------------------------------------------------------------------

Dr. Colin R. Haddow,
HSO-GI, European Space Agency,
European Space Operations Centre,
Robert-Bosch-Str 5,
64293 Darmstadt,
Germany.

Phone; +49 6151 90 2896
Fax;      +49 6151 90 3010
E-Mail;  colin.haddow at esa.int
---------------------------------------------------------------------------------------------------------





From:       "Barkley, Erik J (3970)" <erik.j.barkley at jpl.nasa.gov>
To:         "Colin.Haddow at esa.int" <Colin.Haddow at esa.int>,
Cc:         CCSDS Service Mgmt WG <smwg at mailman.ccsds.org>
Date:       13/01/2015 23:29
Subject:    SOS and common header -- follow up re class diagram



Colin,

To follow up a bit more and perhaps maybe along the lines of John’s comments at the telecon earlier today, it strikes that we may want to take more of the “encapsulated” approach re the common header definition.  We obviously are putting the parameter table in a normative annex for use/reference by other CSSM info entity recommendations and it strikes me what we probably want to do the same thing with the UML.  In particular if we consider other info entity books, will they end up having to repeat the same diagramming technique re the more general service management entity/header/body construct?  It seems that this could be error prone and somewhat tedious re subsequent maintenance.  So perhaps it makes more sense to introduce an abstract stereotype for the service management info entity and then have the “main” SOS UML have a singleton inheritance with the abstract stereotype definition now also part of the normative annex?  What do you think?

Best regards,

-Erik
This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.