SYSML — Part-specific type metamodel - Section: Blocks

Part-specific type metamodel. Was reviewing the thread below and there seemed to be agreement that part-specific types needed a metamodel representation. Otherwise, there would be nothing in the repository linking the property to the part-specific type, and it will be lost in XMI interchange. ----Original Message---- From: Eran Gery [mailto:erang@ilogix.co.il Sent: Friday, March 24, 2006 7:06 AM To: 'Moore, Alan'; 'Branislav Selic'; Burkhart Roger M Cc: anders.ek@telelogic.com; 'Laurent L Balmelli'; 'Carolyn B Boettcher'; conrad.bock@nist.gov; 'Cory Bialowas'; Diego.Tamburini@gatech.edu; Dwayne.Hardy@2asc.com; 'Eldad Palachi'; 'Fredrick A Steiner'; 'Baker, James D (US SSA)'; jlow@ilogix.com; 'Chonoles, Michael J'; 'Friedenthal, Sanford'; 'Tim Weilkiens' Subject: RE: Anonymous types I agree. Not sure if a meta-association is needed or a Boolean tag would suffice. ----Original Message---- From: Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com Sent: Monday, March 27, 2006 1:54 PM To: Eran Gery; Moore, Alan; Branislav Selic Cc: anders.ek@telelogic.com; Laurent L Balmelli; Carolyn B Boettcher; conrad.bock@nist.gov; Cory Bialowas; Diego.Tamburini@gatech.edu; Dwayne.Hardy@2asc.com; Eldad Palachi; (Fredrick A Steiner; Baker, James D US SSA); jlow@ilogix.com; Chonoles, Michael J; Friedenthal, Sanford; Tim Weilkiens Subject: RE: Anonymous types In the V1.0 spec, we've kept the notations for the two forms of property-specific "types" for an internal property on an internal block diagram: a type enclosed in square brackets to specialize an existing type, or a name without a colon to indicate a property that has its entire type constructed for the local usage (which Eran correctly pointed out had been included in the SST and post-merge specs.) While we've included these user-visible notations, I agree with Alan that we need more explicit ways in the metamodel to identify the types that are automatically created as a result of these mechanisms, or the properties that hold them. UML refers to these as "anonymous classes" but I agree with Bran that they're not likely to remain implicit as design proceeds, and I wonder if we should consider assigning a default name to them along with any metamodel identification. I had proposed previously that they could be given the same name as the property for which they supply the type, and a stereotype such as <propertySpecific> applied to them (which I think is the same as a boolean tag such as Eran said might be all that's needed). A related issue I think we'll need to raise in the FTF, since it's not in the current spec, is how these property-specific types can be shown in a properties compartment on a block definition diagram. Following the UML spec, which allows for the "name without a colon" case as a presentation option only on a composite structure diagram, we hadn't included the notation in our diagram extensions for a block definition diagram. That's probably an oversight; we should probably allow the same square-bracket qualification for the type of a property on a bdd just like we allow on an ibd. For the case of the entire type constructed from scratch, however, the simple name without a colon case seems to me entirely inappropriate to carry over to a bdd, so perhaps we could still allow the [ ] without a type name inside like we originally had on the ibd as well. Of course, the motivation that Eran (and Michael) have expressed to start building your design on an internal structure diagram prior to a block definition diagram means you may not care at that stage about a bdd at all, but we should adopt some way to show the same properties consistently across the diagrams regardless of likely interest or usage. For now, I just wanted to highlight the status of this issue as reflected in the draft V1.0 spec, so we can switch over to the FTF for any further resolution that may be needed. --Roger

No Data Available