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

[Colin.Haddow at esa.int]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic26439.gif
Type: image/gif
Size: 44476 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20150121/db357126/attachment.gif>