Talk:De-blue MessageCommunicationsControl
This page documents a Resolved, but not fully actioned MnM Hot Topic, i.e. a methodology issue requiring a resolution from Modeling and Methodology.
Contents
Use, but remove from RIM
Dan Russler (in an e-mail, paraphrasing) suggests not to include the blue classes in the RIM anymore (but to keep on using them)
Replace by RIM classes
Replacing the blue classes by RIM classes is an option. This adds some abstraction (Structural Attributes) which will show at the XML level.
There is a secundary motivation for doing this: it will allow for requirements analysis to be (re)done. The existing blue classes were mostly ported from v2 and are based on requirements that may not exist for v3. The fact that INM has already removed attributes from the blue classes because of a "lack of underlying use-case" is a symptom of the need to do a requirements analysis.
A mapping is feasable:
- Message is an act,there is a participation/role/entity for for CommunicationFunction
- Attachment is just message.txt
- There is an ActRelationship for Acknowledgement to another message or transmission
- Batch has an ActRelationship to batches or messages.
- Acknowledgement detail is another act relationship/act?
- QueryByParameter is the act of querying. ParameterList is some kind of collection Act.
- ParameterItem is a problem if one attempts to fully model it - it can be any of the 6 base classes or an attribute. Only real options are to either stick with blue for parameter, or to be creative and use a "creative" act (the act of "selecting a subset") which is essentially a key/value pair.
WGM Sept2006, 20060911
At the joint MnM/INM meeting the issue was discussed. Rene reviewed the contents of the Wiki page (as of 20060911), and showed the mockup model. Grahame: another reason for doing this is related to ITS problems, because blue classes are different, no structural attributes. Initial response awful, but looking at it there may be good reasons. Woody: a RIM question. Will it lead to greater clarity. Document is a precedent, unfortunately. Grahame: initially felt the same, spent time working on what it would look like. More expressive, if you understand RIM more naturally, not convinced that its particularly worse. Craig: if redone, through ballot process, let it go ahead, go to ballot. Lloyd: any specific questions that INM should answer? Woordy: Can all of the concepts be expressed? Would some UML transport standards not be more appropriate? Charlie: mutiple options there. Grahame: grey zone advanced/simple transport.
Woody felt that moving the communications information into the backbone would obscure the content. He feels that the RIM backbone should be focused on Acts, and that communications concerns should not pollute the backbone. He suggested that finding an external approach that is commonly accepted may be preferable to spending significant effort maintaining our own.
There is some question as to the mappability from the existing model to the proposed model. However, this may be an opportunity to clean up the communications model.
Lee Coller expressed a reluctance to make significant changes to the transmission infrastructure based on the number of existing implementations of these. However, he also expressed a desire to have the query infrastructure revamped.
Lee C: There are R1 implementations, this is a radical change.
Charlie: slight disquite, not a methodlogical objection.
2006911: While there were some concerns MnM sees no functional objection and request a proposal (to represent the existing structures based on analysis supported by requirements) to do a mapping to RIM backbone. Evaluation of this more proposal [outcome by MnM to see if there is no methodlogical misfit] (Charlie/Woody, 21-0-3)
Jan2007 WGM
- Committee agrees to "de-blue" the current models. Some problems are expected with parameterItem.
- Motion: committee feels we should move forward and de-blue the models as a strategy. Has a number of advantages. (Mark/Rene, 6-0-0)
An advantage which has not yet been explicitely documented: de-blueing would allow the use of templates in queries.
Getting there gracefully
I am glad that this subject finally gets momentum. I've been wanting this change to happen for many years. Here is a proposal to get there gracefully, with something very close to backward compatibility. Here is how we can get there:
1. color the classes, which is pretty straight forward
2. make these classes into subclasses of their appropriate parents, as is
2.1 Transmission is-a Act
2.2 CommunicationFunction is-a Participation (with a little bit of role stuff pulled in)
2.2.1 fix the association from CommunicationFunction to Transmission to many-to-one, and not many-to-many
3. re-route the 3 associations that went from a Participation direct to an Entity
3.1 this is easy for the Device connection, as the Role "Agent" is already there.
3.2 for the other class, also use the Agent role
4. make TransmissionRelationship subtype of ActRelationship
5. Lave the direct relationships between Act-like classes for now.
5.1 But fix the the association from Message to ControlAct to be Message:0..*::0..1:ControlAct, rename the wrong "payload" UML association role to "message".
6. do some mild attribute shuffling, nothing major
6.1 fix Act moodCode to EVN of course
This is pretty straight forward. Of course there would be much more to do to make it really nice, but we need something sooner that can be adopted with mild changes only, just to get us out of the mud. Gschadow 04:42, 12 August 2009 (UTC)
Woody: IMHO the timing of this is awful:
- In a period when there is finally action going on to revise the behavioral model and adopt a new (SA) Enterprise Architecture Framework, this would seem to be the worst possible time to re-cast the the Blue Classes.
- It isn't even clear to me that there is ANY advantage to shoe-horning these apparently-orthogonal concepts into the RIM backbone space, but I should probably not have added that to this note. GWBeeler
Discussion at the September 2009 WGM
Grahame points out that the blue message classes may be pulled anyway as part of the SAEF work. Rene points out that not all technology frameworks have the capability to carry such data (e.g. MLLP), so he still sees a requirement for this type of data. Grahame doesn't see the need for them, but would like to see a full fledged proposal.
