: Public Note
Created: 09/01/2011 19:20:59
Modified: 15/04/2016 14:45:26
Project:
Advanced:
[tk, 2011-01-09]<br/>(concentrate on upper half of the diagram - I've expanded here only the three classes that subtype Organisation and it's quite a mess...)<br/><ul>
<li>In DCIM10+, we have a "slim" normative IEC61968::Common::Organisation. Currently we have two normative subclasses (Customer and ServiceSupplier). We'll likely have also Bank as Organisation subtype, promoted to normative (for PaymentMetering). </li><li><font color="#0f0f0f">[c-034] WG16 has to figure out whether some previously present association has been used in normative profiles and is now missing, so WG14 and WG16 together can come to a solution suiting both groups. </font><font color="#008040"><b>Current model includes solution</b></font></li><li><font color="#0f0f0f">Associations Mkt_Organisation-CRR and SchedulingCoordinator-Bid: These relationships show exactly how it should work - <b><i>subtype of Organisation relates to a subtype of Document with a specific, concrete meaning</i></b> (instead of requiring the extremely generic inherited association Organisation-Document, which is not in DCIM anymore). </font> <font color="#008040"><b>Ok</b></font></li><li><font color="#0f0f0f">Mkt_Organisation: This is actually not a shadow class of Organisation, but is really an entity in itself - with all the associations specific to market concepts and not applicable in other contexts. So, rename Mkt_Organisation simply to MarketOrganisation (it deserves a better name). </font><font color="#008040"><b>Renamed to MarketParticipant</b></font></li><li><font color="#0f0f0f">Design note: Notice how (currently) SchedulingCoordinator and RTO inherit directly from Organisation and not from Mkt_Organisation. This certainly means that these two classes do not need associations of Mkt_Organisation. If this is not the case (i.e., if they need to navigate to any of associations of Mkt_Organisation), they should then inherit from Mkt_Organisation. -</font><font color="#ff0000"> </font><font color="#008040"><b>Updated Generalizations to use Mkt_Organisation (now MarketParticipant).</b></font> </li><li>SchedulingCoordinator: Its attribute 'scid' is a name, so you should probably remove this attribute and allow in the profile multiple instances of association IdentifiedObject-Name (CIM15). </li><li>SchedulingCoordinator and Trade have 2 pairs of similar associations - seems to me one pair should be removed. </li><li><font color="#0f0f0f">Mkt_Organisation: Attributes *TelephoneNumber are now redundant and should be removed (phone1 and phone2 are inherited). </font><font color="#ff0000">- </font><font color="#008040"><b>Removed</b></font> </li><li>Mkt_Organisation: Attributes recordVersion and repositoryVersion are implementation, not domain model, and should be removed (as noted previously for many classes from ReferenceData package). </li><li><font color="#ff0000">Mkt_Organisation: You could replace the attribute 'lastModifiedDate' with 'status' of type IEC61968::Common::Status - we use that construct in many places.</font> </li><li>Mkt_Organisation: Attribute organisationID sounds like implementation specific. It should probably be removed and association to Name could be used instead (name as custom, non-mRID identifier). </li></ul><p/>