Issue 13260: Parametrics and Depletable Stores (sysml-rtf) Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org) Nature: Uncategorized Issue Severity: Summary: Though we recently changed SysML to allow depletable stores, there appears to be some open issues about what they are and how to handle them with Parametrics properly. Is the name of the depleteable store that property of the owning block whose values change? (and can be used in Parametrics) Or does the depleteable store have a property (perhaps with a standard name) that is the changing value. Is the depleteable store a variable property or a part with a variable property? Resolution: Revised Text: Actions taken: January 15, 2009: received issue Discussion: This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred End of Annotations:===== te: Thu, 15 Jan 2009 06:06:19 -0500 From: "Chonoles, Michael J" Subject: SysML: Parametrics and Depletable Stores To: issues@omg.org Thread-Topic: SysML: Parametrics and Depletable Stores Thread-Index: Acl3AUmD4wa108nyReSsQqbebyOQLA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 15 Jan 2009 11:06:24.0198 (UTC) FILETIME=[4DE02E60:01C97701] Though we recently changed SysML to allow depletable stores, there appears to be some open issues about what they are and how to handle them with Parametrics properly. Is the name of the depleteable store that property of the owning block whose values change? (and can be used in Parametrics) Or does the depleteable store have a property (perhaps with a standard name) that is the changing value. Is the depleteable store a variable property or a part with a variable property? Michael Jesse Chonoles Lockheed Martin From: "Chonoles, Michael J" Subject: Concern with 13260 resolution To: "sysml-rtf@omg.org" Perhaps the terminology of .Depletable. store came from an earlier version of SysML, but in 1.3 page 181 Figure C.25 we use a .store.. This is the box labeled Fuel in the lower right corner. While it is difficult to tell from the diagram, if you magnify it, you.ll see it is a dashed box. The description of the diagram and this store is found on the previous page C.4.6.5. .The Fuel store represents a quantity of fuel in the FuelTankAssy, which is drawn by the FuelPump for use in the engine, and is refreshed, to some degree, by fuel returning to the FuelTankAssy via the FuelReturnLine. And in C.4.5.5 .The dashed borders on Fuel denote a store, which keeps track of the amount and mass of fuel in the FuelTankAssy. This is also depicted in Figure C.18. . Note that in Figure C.18, the store is not dashed (though the diagram is). I believe these are the only 2 references to .store. in this context in the specification. In section 8.3.1.2 Internal Block Diagram we have the following. .A part or value property is always shown on an internal block diagram with a solid-outline box. So, Is Fuel a value property or a store?. What is a store? Is the Fuel a property of the Fuel Tank Assembly? It certainly seems to be so. So, if this a .store., we need to connect them to parametrics. If this is just a mistake, we need to clean up the spec. Michael LM Michael Jesse Chonoles Principal Member of Engineering Staff LM co-POC to OMG / coChair OMG ADTF Lockheed Martin, MS2 Moorestown, NJ 08057 199 Borton Landing Road, Bldg 780, 2nd Fl, C408 Telephones: Work 856-359-1383 Cell: 267-315-2410 Home and Work 610-644-8404 Fax: 215-790-2976 Co-author: UML 2 For Dummies michael.j.chonoles@lmco.com mjchonoles@yahoo.com From: "Sanford Friedenthal" To: "'Chonoles, Michael J ...snip... lmco.com>, Subject: RE: Concern with 13260 resolution Michael I am jumping in but have not looked at this recently. A common pattern that I have used, and I think is being used in the auto example is to define a stored item as a reference property with a user defined stereotype <> applied to it. For example, Fuel is an item that is stored by a fuel tank. It is not part of the fuel tank, but is referenced by it. Sandy From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Thursday, February 09, 2012 5:57 PM To: sysml-rtf@omg.org Subject: Concern with 13260 resolution Perhaps the terminology of .Depletable. store came from an earlier version of SysML, but in 1.3 page 181 Figure C.25 we use a .store.. This is the box labeled Fuel in the lower right corner. While it is difficult to tell from the diagram, if you magnify it, you.ll see it is a dashed box. The description of the diagram and this store is found on the previous page C.4.6.5. .The Fuel store represents a quantity of fuel in the FuelTankAssy, which is drawn by the FuelPump for use in the engine, and is refreshed, to some degree, by fuel returning to the FuelTankAssy via the FuelReturnLine. And in C.4.5.5 .The dashed borders on Fuel denote a store, which keeps track of the amount and mass of fuel in the FuelTankAssy. This is also depicted in Figure C.18. . Note that in Figure C.18, the store is not dashed (though the diagram is). I believe these are the only 2 references to .store. in this context in the specification. In section 8.3.1.2 Internal Block Diagram we have the following. .A part or value property is always shown on an internal block diagram with a solid-outline box. So, Is Fuel a value property or a store?. What is a store? Is the Fuel a property of the Fuel Tank Assembly? It certainly seems to be so. So, if this a .store., we need to connect them to parametrics. If this is just a mistake, we need to clean up the spec. Michael LM Michael Jesse Chonoles Principal Member of Engineering Staff LM co-POC to OMG / coChair OMG ADTF Lockheed Martin, MS2 Moorestown, NJ 08057 199 Borton Landing Road, Bldg 780, 2nd Fl, C408 Telephones: Work 856-359-1383 Cell: 267-315-2410 Home and Work 610-644-8404 Fax: 215-790-2976 Co-author: UML 2 For Dummies michael.j.chonoles@lmco.com mjchonoles@yahoo.com From: "Chonoles, Michael J" Subject: RE: RE: Concern with 13260 resolution To: Sanford Friedenthal...snip... rtf@omg.org" Perhaps it.s not noncontroversial Michael From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: Monday, February 13, 2012 4:06 AM To: Chonoles, Michael J; sysml-rtf@omg.org Subject: Re:RE: Concern with 13260 resolution Michael Comments below: Sandy From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Sunday, February 12, 2012 10:35 PM To: Sanford Friedenthal; sysml-rtf@omg.org Subject: RE: EXTERNAL: RE: Concern with 13260 resolution Thanks Sandy, I figured that was the source of the error, Unfortunately, 1. The «store» stereotype is not defined in the spec [sf] the store stereotype is a user defined stereotype, which is a legitimate use of the spec. However, the same modeling approach can be used without the stereotype. 2. The fuel is nowhere in the spec indicated with that stereotype [sf] I am not sure any of the user defined stereotypes are defined in the example. That can be fixed by adding them, or the stereotype can be removed. 3. It.s hard to really get a handle on the thinking that the fuel is external to the fuel tank. [sf] A bolt may be a .part of. the Fuel Tank. The fuel is referenced by the Fuel Tank but not .part of. the tank. Similarly, water is not part of the glass that holds it. 4. Most people would model the fuel as a property of the fuel tank, which then should not use the dashed line [sf] Disagree. I am not sure why you would say most people would do that. I for one, would not model it as a part per my note above. 5. While the box is dashed, it is almost impossible to see it unless the diagram is at maximum zoom. [sf] That is a separate issue with the diagram and not an issue with the approach. Closing this issue 13260, would cause several of the above to be issues instead. [sf] I think we should close it per my original response. Michael From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: Saturday, February 11, 2012 10:35 PM To: Chonoles, Michael J; sysml-rtf@omg.org Subject: EXTERNAL: RE: Concern with 13260 resolution Michael I am jumping in but have not looked at this recently. A common pattern that I have used, and I think is being used in the auto example is to define a stored item as a reference property with a user defined stereotype <> applied to it. For example, Fuel is an item that is stored by a fuel tank. It is not part of the fuel tank, but i s referenced by it. Sandy From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Thursday, February 09, 2012 5:57 PM To: sysml-rtf@omg.org Subject: Concern with 13260 resolution Perhaps the terminology of .Depletable. store came from an earlier version of SysML, but in 1.3 page 181 Figure C.25 we u se a .store.. This is the box labeled Fuel in the lower right corner. While it is difficult to tell from the diagram, if you magnify it, you.ll see it is a dashed box. The description of the diagram and this store is found on the previous page C.4.6.5. .The Fuel store represents a quantity of fuel in the FuelTankAssy, which is drawn by the FuelPump for use in the engine, and is refreshed, to some degree, by fuel returning to the FuelTankAssy via the FuelReturnLine. And in C.4.5.5 .The dashed borders on Fuel deno te a store, which keeps track of the amount and mass of fuel in the FuelTankAssy. This is also depicted in Figure C.18. . Note that in Figure C.18, the store is not dashed (though the diagram is). I believe these are the only 2 references to .store. in this context in the specificat ion. In section 8.3.1.2 Internal Block Diagram we have the following. .A part or value property is always shown on an internal block diagram with a solid-outline box. So, Is Fuel a value property or a st ore?. What is a store? Is the Fuel a property of the Fuel Tank Assembly? It certainly seems to be so. So, if this a .store., we need to connect them to parametrics. If this is just a mistake, we need to clean up the spec. Michael LM Michael Jesse Chonoles Pr incipal Member of Engineering Staff LM co-POC to OMG / coChair OMG ADTF Lockheed Martin, MS2 Moorestown, NJ 08057 199 Borton Landing Road, Bldg 780, 2nd Fl, C408 Telephones: Work 856-359-1383 Cell: 267-315-2410 Home and Work 610-644-8404 Fax: 215-790-2976 Co-author: UML 2 For Dummies michael.j.chonoles@lmco.com mjchonoles@yahoo.com From: "Chonoles, Michael J" Subject: RE: Concern with 13260 resolution To: Sanford Friedenthal...snip... rtf@omg.org" Well, rethinking. Ok Close It.s clear that there is no concept of .Depletable store. as I mentioned in my issue and therefore the specific problem from the issue can be closed. And just to show I.m not crazy. .depletable store. was a term in SysML. Here.s a quote from the SysML V1 Glossary stored item [UML for SE RFP]246 SysML Specification v. 0.98 An item that persists over time, which may be depletable or non-depletable. Note: Non-depletable stores may include data store in computer memory, and depletable stores may include energy in a battery, or fluid in a tank. Physical stores obey the conservation laws (only take out what is put in). A non-depletable store, such as a data store, is not constrained by the conservation laws. The stored item should be differentiated from the storage device, which stores the item. See central buffer node, storage device. Note: This was previously a system store. Now the other issues I still believe there is a remaining, and different, diagram problem (as the box being dashed in nearly invisible). There is also a problem with the concept of store as being undefined There is also a problem with the claiming that the Fuel is a referenced store, when it is from C.4.6.5 when it just represents a quantity, which just probably be represented by a value property (and then a solid box). \Though in C.4.5.5 it appears to be more BTW, in OOSEM as indicated in your book. «store» applies to a property. SysML shows properties with a solid box. I don.t believe we have a concept of a referenced property. In your book, in the IBD.s, you have «stores» indicated as solid boxes within their owner. Michael From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: Monday, February 13, 2012 4:06 AM To: Chonoles, Michael J; sysml-rtf@omg.org Subject: Re:RE: Concern with 13260 resolution Michael Comments below: Sandy From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Sunday, February 12, 2012 10:35 PM To: Sanford Friedenthal; sysml-rtf@omg.org Subject: RE: EXTERNAL: RE: Concern with 13260 resolution Thanks Sandy, I figured that was the source of the error, Unfortunately, 1. The «store» stereotype is not defined in the spec [sf] the store stereotype is a user defined stereotype, which is a legitimate use of the spec. However, the same modeling approach can be used without the stereotype. 2. The fuel is nowhere in the spec indicated with that stereotype [sf] I am not sure any of the user defined stereotypes are defined in the example. That can be fixed by adding them, or the stereotype can be removed. 3. It.s hard to really get a handle on the thinking that the fuel is external to the fuel tank. [sf] A bolt may be a .part of. the Fuel Tank. The fuel is referenced by the Fuel Tank but not .part of. the tank. Similarly, water is not part of the glass that holds it. 4. Most people would model the fuel as a property of the fuel tank, which then should not use the dashed line [sf] Disagree. I am not sure why you would say most people would do that. I for one, would not model it as a part per my note above. 5. While the box is dashed, it is almost impossible to see it unless the diagram is at maximum zoom. [sf] That is a separate issue with the diagram and not an issue with the approach. Closing this issue 13260, would cause several of the above to be issues instead. [sf] I think we should close it per my original response. Michael From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: Saturday, February 11, 2012 10:35 PM To: Chonoles, Michael J; sysml-rtf@omg.org Subject: EXTERNAL: RE: Concern with 13260 resolution Michael I am jumping in but have not looked at this recently. A common pattern that I have used, and I think is being used in the auto example is to define a stored item as a reference property with a user defined stereotype <> applied to it. For example, Fuel is an item that is stored by a fuel tank. It is not part of the fuel tank, but i s referenced by it. Sandy From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Thursday, February 09, 2012 5:57 PM To: sysml-rtf@omg.org Subject: Concern with 13260 resolution Perhaps the terminology of .Depletable. store came from an earlier version of SysML, but in 1.3 page 181 Figure C.25 we u se a .store.. This is the box labeled Fuel in the lower right corner. While it is difficult to tell from the diagram, if you magnify it, you.ll see it is a dashed box. The description of the diagram and this store is found on the previous page C.4.6.5. .The Fuel store represents a quantity of fuel in the FuelTankAssy, which is drawn by the FuelPump for use in the engine, and is refreshed, to some degree, by fuel returning to the FuelTankAssy via the FuelReturnLine. And in C.4.5.5 .The dashed borders on Fuel deno te a store, which keeps track of the amount and mass of fuel in the FuelTankAssy. This is also depicted in Figure C.18. . Note that in Figure C.18, the store is not dashed (though the diagram is). I believe these are the only 2 references to .store. in this context in the specificat ion. In section 8.3.1.2 Internal Block Diagram we have the following. .A part or value property is always shown on an internal block diagram with a solid-outline box. So, Is Fuel a value property or a st ore?. What is a store? Is the Fuel a property of the Fuel Tank Assembly? It certainly seems to be so. So, if this a .store., we need to connect them to parametrics. If this is just a mistake, we need to clean up the spec. Michael LM Michael Jesse Chonoles Pr incipal Member of Engineering Staff LM co-POC to OMG / coChair OMG ADTF Lockheed Martin, MS2 Moorestown, NJ 08057 199 Borton Landing Road, Bldg 780, 2nd Fl, C408 Telephones: Work 856-359-1383 Cell: 267-315-2410 Home and Work 610-644-8404 Fax: 215-790-2976 Co-author: UML 2 For Dummies michael.j.chonoles@lmco.com mjchonoles@yahoo.com From: Burkhart Roger M To: "Chonoles, Michael J ...snip... rtf@omg.org" Subject: RE: Concern with 13260 resolution Michael-- I agree that your new issues below, about stores in the sample problem, below should be addressed. On being clear when the Sample Problem relies on user-defined stereotypes, we already have an issue, 16112, "Where have stereotypes been defined?" We could include «store» if it's used anywhere as an actual user-defined stereotype, but so far found I haven't found an actual stereotype in the example, only use of the term store in the description text. The statement in C.4.5.5 that "The dashed borders on Fuel denote a store, which keeps track of the amount and mass of fuel in the FuelTankAssy." is clearly in error since Fuel only shows up as a box in the preceding C.18 where it does not have a dashed-outline boundary. If you, Sandy, or Rick want to discuss any fixes to the store examples in Annex C, and raise an issue as appropriate to fix them, that would be welcome. I'd like to keep the current proposed resolution of Closed, no change for 13260, which is about how to handle depletable stores within parametrics, since I think that specific issue can still be closed. --Roger From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Monday, February 13, 2012 9:23 AM To: Sanford Friedenthal; sysml-rtf@omg.org Subject: RE: Concern with 13260 resolution Well, rethinking. Ok Close It.s clear that there is no concept of .Depletable store. as I mentioned in my issue and therefore the specific problem from the issue can be closed. And just to show I.m not crazy. .depletable store. was a term in SysML. Here.s a quote from the SysML V1 Glossary stored item [UML for SE RFP]246 SysML Specification v. 0.98 An item that persists over time, which may be depletable or non-depletable. Note: Non-depletable stores may include data store in computer memory, and depletable stores may include energy in a battery, or fluid in a tank. Physical stores obey the conservation laws (only take out what is put in). A non-depletable store, such as a data store, is not constrained by the conservation laws. The stored item should be differentiated from the storage device, which stores the item. See central buffer node, storage device. Note: This was previously a system store. Now the other issues I still believe there is a remaining, and different, diagram problem (as the box being dashed in nearly invisible). There is also a problem with the concept of store as being undefined There is also a problem with the claiming that the Fuel is a referenced store, when it is from C.4.6.5 when it just represents a quantity, which just probably be represented by a value property (and then a solid box). \Though in C.4.5.5 it appears to be more BTW, in OOSEM as indicated in your book. «store» applies to a property. SysML shows properties with a solid box. I don.t believe we have a concept of a referenced property. In your book, in the IBD.s, you have «stores» indicated as solid boxes within their owner. Michael From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: Monday, February 13, 2012 4:06 AM To: Chonoles, Michael J; sysml-rtf@omg.org Subject: Re:RE: Concern with 13260 resolution Michael Comments below: Sandy From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Sunday, February 12, 2012 10:35 PM To: Sanford Friedenthal; sysml-rtf@omg.org Subject: RE: EXTERNAL: RE: Concern with 13260 resolution Thanks Sandy, I figured that was the source of the error, Unfortunately, 1. The «store» stereotype is not defined in the spec [sf] the store stereotype is a user defined stereotype, which is a legitimate use of the spec. However, the same modeling approach can be used without the stereotype. 2. The fuel is nowhere in the spec indicated with that stereotype [sf] I am not sure any of the user defined stereotypes are defined in the example. That can be fixed by adding them, or the stereotype can be removed. 3. It.s hard to really get a handle on the thinking that the fuel is external to the fuel tank. [sf] A bolt may be a .part of. the Fuel Tank. The fuel is referenced by the Fuel Tank but not .part of. the tank. Similarly, water is not part of the glass that holds it. 4. Most people would model the fuel as a property of the fuel tank, which then should not use the dashed line [sf] Disagree. I am not sure why you would say most people would do that. I for one, would not model it as a part per my note above. 5. While the box is dashed, it is almost impossible to see it unless the diagram is at maximum zoom. [sf] That is a separate issue with the diagram and not an issue with the approach. Closing this issue 13260, would cause several of the above to be issues instead. [sf] I think we should close it per my original response. Michael From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: Saturday, February 11, 2012 10:35 PM To: Chonoles, Michael J; sysml-rtf@omg.org Subject: EXTERNAL: RE: Concern with 13260 resolution Michael I am jumping in but have not looked at this recently. A common pattern that I have used, and I think is being used in the auto example is to define a stored item as a reference property with a user defined stereotype <> applied to it. For example, Fuel is an item that is stored by a fuel tank. It is not part of the fuel tank, but i s referenced by it. Sandy From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Thursday, February 09, 2012 5:57 PM To: sysml-rtf@omg.org Subject: Concern with 13260 resolution Perhaps the terminology of .Depletable. store came from an earlier version of SysML, but in 1.3 page 181 Figure C.25 we u se a .store.. This is the box labeled Fuel in the lower right corner. While it is difficult to tell from the diagram, if you magnify it, you.ll see it is a dashed box. The description of the diagram and this store is found on the previous page C.4.6.5. .The Fuel store represents a quantity of fuel in the FuelTankAssy, which is drawn by the FuelPump for use in the engine, and is refreshed, to some degree, by fuel returning to the FuelTankAssy via the FuelReturnLine. And in C.4.5.5 .The dashed borders on Fuel deno te a store, which keeps track of the amount and mass of fuel in the FuelTankAssy. This is also depicted in Figure C.18. . Note that in Figure C.18, the store is not dashed (though the diagram is). I believe these are the only 2 references to .store. in this context in the specificat ion. In section 8.3.1.2 Internal Block Diagram we have the following. .A part or value property is always shown on an internal block diagram with a solid-outline box. So, Is Fuel a value property or a st ore?. What is a store? Is the Fuel a property of the Fuel Tank Assembly? It certainly seems to be so. So, if this a .store., we need to connect them to parametrics. If this is just a mistake, we need to clean up the spec. Michael LM Michael Jesse Chonoles Pr incipal Member of Engineering Staff LM co-POC to OMG / coChair OMG ADTF Lockheed Martin, MS2 Moorestown, NJ 08057 199 Borton Landing Road, Bldg 780, 2nd Fl, C408 Telephones: Work 856-359-1383 Cell: 267-315-2410 Home and Work 610-644-8404 Fax: 215-790-2976 Co-author: UML 2 For Dummies michael.j.chonoles@lmco.com mjchonoles@yahoo.com From: "Chonoles, Michael J" Subject: RE: RE: Concern with 13260 resolution To: Burkhart Roger M Yes, I.m ok with closing. Michael From: Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] Sent: Monday, February 13, 2012 1:33 PM To: Chonoles, Michael J; Sanford Friedenthal; sysml-rtf@omg.org Subject: Ex: RE: Concern with 13260 resolution Michael-- I agree that your new issues below, about stores in the sample problem, below should be addressed. On being clear when the Sample Problem relies on user-defined stereotypes, we already have an issue, 16112, "Where have stereotypes been defined?" We could include «store» if it's used anywhere as an actual user-defined stereotype, but so far found I haven't found an actual stereotype in the example, only use of the term store in the description text. The statement in C.4.5.5 that "The dashed borders on Fuel denote a store, which keeps track of the amount and mass of fuel in the FuelTankAssy." is clearly in error since Fuel only shows up as a box in the preceding C.18 where it does not have a dashed-outline boundary. If you, Sandy, or Rick want to discuss any fixes to the store examples in Annex C, and raise an issue as appropriate to fix them, that would be welcome. I'd like to keep the current proposed resolution of Closed, no change for 13260, which is about how to handle depletable stores within parametrics, since I think that specific issue can still be closed. --Roger From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Monday, February 13, 2012 9:23 AM To: Sanford Friedenthal; sysml-rtf@omg.org Subject: RE: Concern with 13260 resolution Well, rethinking. Ok Close It.s clear that there is no concept of .Depletable store. as I mentioned in my issue and therefore the specific problem from the issue can be closed. And just to show I.m not crazy. .depletable store. was a term in SysML. Here.s a quote from the SysML V1 Glossary stored item [UML for SE RFP]246 SysML Specification v. 0.98 An item that persists over time, which may be d epletable or non-depletable. Note: Non-depletable stores may include data store in computer memory, and depletable stores may include energy in a battery, or fluid in a tank. Physical stores obey the conservation laws (only take out what is put in). A non-depletable store, such as a data store, is not constrained by the conservation laws. The stored item should be differentiated from the storage device, which stores the item. See central buffer node, storage device. Note: This was previously a system store. Now the other issues I still believe there is a remaining, and different, diagram problem (as the box being dashed in nearly invisible). There is also a problem with the concept of store as being undefined There is also a problem with the claiming that the Fuel is a referenced store, when it is from C.4.6.5 when it just represents a quantity, which just probably be represented by a value property (and then a solid box). \Though in C.4.5.5 it appears to be more BTW, in OOSEM as indicated in your book. «store» applies to a property. SysML shows properties with a solid box. I don.t believe we have a concept of a referenced property. In your book, in the IBD.s, you have «stores» indicated as solid boxes within their owner. Michael From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: Monday, February 13, 2012 4:06 AM To: Chonoles, Michael J; sysml-rtf@omg.org Subject: Re:RE: Concern with 13260 resolution Michael Comme nts below: Sandy From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Sunday, February 12, 2012 10:35 PM To: Sanford Friedenthal; sysml-rtf@omg.org Subject: RE: EXTERNAL: RE: Concern with 13260 resolution Thanks Sandy, I figured that was the source of the error, Unfortunately, 1. The «store» stereotype is not defined in the spec [sf] the store stereotype is a user defined stereotype, which is a legitimate use of the spec. However, the same modeling approach can be used without the stereotype. 2. The fuel is nowhere in the spec indicated with that stereotype [sf] I am not sure any of the user defined stereotypes are defined in the example. That can be fixed by adding them, or the stereotype can be removed. 3. It.s hard to really get a handle on the thinking that the fuel is external to the fuel tank. [sf] A bolt may be a .part of. the Fuel Tank. The fuel is referenced by the Fuel Tank but not .part of. the tank. Similarly, water is not part of the g lass that holds it. 4. Most people would model the fuel as a property of the fuel tank, which then should not use the dashed line [sf] Disagree. I am not sure why you would say most people would do that. I for one, would not model it as a part per my note above. 5. While the box is dashed , it is almost impossible to see it unless the diagram is at maximum zoom. [sf] That is a separate issue with the diagram and not an issue with the approach. Closing this issue 13260, would cause several of the above to be issues instead. [sf] I think we should close it per my original response. Michael From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: Saturday, February 11, 2012 10:35 PM To: Chonoles, Michael J; sysml-rtf@omg.org Subject: EXTERNAL: RE: Concern with 13260 resolution Michael I am jumping in but have not looked at this recently. A common pattern that I have used, and I think is being used in the auto example is to define a stored item as a reference property with a user defined stereotype <> applied to it. For example, Fuel is an item that is stored by a fuel tank. It is not part of the fuel tank, but i s referenced by it. Sandy From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Thursday, February 09, 2012 5:57 PM To: sysml-rtf@omg.org Subject: Concern with 13260 resolution Perhaps the terminology of .Depletable. store came from an earlier version of SysML, but in 1.3 page 181 Figure C.25 we u se a .store.. This is the box labeled Fuel in the lower right corner. While it is difficult to tell from the diagram, if you magnify it, you.ll see it is a dashed box. The description of the diagram and this store is found on the previous page C.4.6.5. .The Fuel store represents a quantity of fuel in the FuelTankAssy, which is drawn by the FuelPump for use in the engine, and is refreshed, to some degree, by fuel returning to the FuelTankAssy via the FuelReturnLine. And in C.4.5.5 .The dashed borders on Fuel deno te a store, which keeps track of the amount and mass of fuel in the FuelTankAssy. This is also depicted in Figure C.18. . Note that in Figure C.18, the store is not dashed (though the diagram is). I believe these are the only 2 references to .store. in this context in the specificat ion. In section 8.3.1.2 Internal Block Diagram we have the following. .A part or value property is always shown on an internal block diagram with a solid-outline box. So, Is Fuel a value property or a st ore?. What is a store? Is the Fuel a property of the Fuel Tank Assembly? It certainly see ms to be so. So, if this a .store., we need to connect them to parametrics. If this is just a mistake, we need to clean up the spec. Michael LM Michael Jesse Chonoles Pr incipal Member of Engineering Staff LM co-POC to OMG / coChair OMG ADTF Lockheed Martin, MS2 Moorestown, NJ 08057 199 Borton Landing Road, Bldg 780, 2nd Fl, C408 Telephones: Work 856-359-1383 Cell: 267-315-2410 Home and Work 610-644-8404 Fax: 215-790-2976 Co-author: UML 2 For Dummies michael.j.chonoles@lmco.com mjchonoles@yahoo.com From: "Sanford Friedenthal" To: "'Chonoles, Michael J ...snip... lmco.com>, Subject: RE: Concern with 13260 resolution Michael In Figure 17.18 of second edition, it is shown as a reference. Also, from pg 131, Another use of reference properties is to model stored items (e.g., water stored in a tank). The water is not part of the tank in the same way that a valve is a part of the tank. For this case, the water may be owned by another block and shown as a reference property of the tank. Sandy From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Monday, February 13, 2012 10:23 AM To: Sanford Friedenthal; sysml-rtf@omg.org Subject: RE: Concern with 13260 resolution Well, rethinking. Ok Close It.s clear that there is no concept of .Depletable store. as I mentioned in my issue and therefore the specific problem from the issue can be closed. And just to show I.m not crazy. .depletable store. was a term in SysML. Here.s a quote from the SysML V1 Glossary stored item [UML for SE RFP]246 SysML Specification v. 0.98 An item that persists over time, which may be depletable or non-depletable. Note: Non-depletable stores may include data store in computer memory, and depletable stores may include energy in a battery, or fluid in a tank. Physical stores obey the conservation laws (only take out what is put in). A non-depletable store, such as a data store, is not constrained by the conservation laws. The stored item should be differentiated from the storage device, which stores the item. See central buffer node, storage device. Note: This was previously a system store. Now the other issues I still believe there is a remaining, and different, diagram problem (as the box being dashed in nearly invisible). There is also a problem with the concept of store as being undefined There is also a problem with the claiming that the Fuel is a referenced store, when it is from C.4.6.5 when it just represents a quantity, which just probably be represented by a value property (and then a solid box). \Though in C.4.5.5 it appears to be more BTW, in OOSEM as indicated in your book. «store» applies to a property. SysML shows properties with a solid box. I don.t believe we have a concept of a referenced property. In your book, in the IBD.s, you have «stores» indicated as solid boxes within their owner. Michael From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: Monday, February 13, 2012 4:06 AM To: Chonoles, Michael J; sysml-rtf@omg.org Subject: Re:RE: Concern with 13260 resolution Michael Comments below: Sandy From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Sunday, February 12, 2012 10:35 PM To: Sanford Friedenthal; sysml-rtf@omg.org Subject: RE: EXTERNAL: RE: Concern with 13260 resolution Thanks Sandy, I figured that was the source of the error, Unfortunately, 1. The «store» stereotype is not defined in the spec [sf] the store stereotype is a user defined stereotype, which is a legitimate use of the spec. However, the same modeling approach can be used without the stereotype. 2. The fuel is nowhere in the spec indicated with that stereotype [sf] I am not sure any of the user defined stereotypes are defined in the example. That can be fixed by adding them, or the stereotype can be removed. 3. It.s hard to really get a handle on the thinking that the fuel is external to the fuel tank. [sf] A bolt may be a .part of. the Fuel Tank. The fuel is referenced by the Fuel Tank but not .part of. the tank. Similarly, water is not part of the glass that holds it. 4. Most people would model the fuel as a property of the fuel tank, which then should not use the dashed line [sf] Disagree. I am not sure why you would say most people would do that. I for one, would not model it as a part per my note above. 5. While the box is dashed, it is almost impossible to see it unless the diagram is at maximum zoom. [sf] That is a separate issue with the diagram and not an issue with the approach. Closing this issue 13260, would cause several of the above to be issues instead. [sf] I think we should close it per my original response. Michael From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: Saturday, February 11, 2012 10:35 PM To: Chonoles, Michael J; sysml-rtf@omg.org Subject: EXTERNAL: RE: Concern with 13260 resolution Michael I am jumping in but have not looked at this recently. A common pattern that I have used, and I think is being used in the auto example is to define a stored item as a reference property with a user defined stereotype <> applied to it. For example, Fuel is an item that is stored by a fuel tank. It is not part of the fuel tank, but i s referenced by it. Sandy From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Thursday, February 09, 2012 5:57 PM To: sysml-rtf@omg.org Subject: Concern with 13260 resolution Perhaps the terminology of .Depletable. store came from an earlier version of SysML, but in 1.3 page 181 Figure C.25 we u se a .store.. This is the box labeled Fuel in the lower right corner. While it is difficult to tell from the diagram, if you magnify it, you.ll see it is a dashed box. The description of the diagram and this store is found on the previous page C.4.6.5. .The Fuel store represents a quantity of fuel in the FuelTankAssy, which is drawn by the FuelPump for use in the engine, and is refreshed, to some degree, by fuel returning to the FuelTankAssy via the FuelReturnLine. And in C.4.5.5 .The dashed borders on Fuel deno te a store, which keeps track of the amount and mass of fuel in the FuelTankAssy. This is also depicted in Figure C.18. . Note that in Figure C.18, the store is not dashed (though the diagram is). I believe these are the only 2 references to .store. in this context in the specificat ion. In section 8.3.1.2 Internal Block Diagram we have the following. .A part or value property is always shown on an internal block diagram with a solid-outline box. So, Is Fuel a value property or a st ore?. What is a store? Is the Fuel a property of the Fuel Tank Assembly? It certainly seems to be so. So, if this a .store., we need to connect them to parametrics. If this is just a mistake, we need to clean up the spec. Michael LM Michael Jesse Chonoles Pr incipal Member of Engineering Staff LM co-POC to OMG / coChair OMG ADTF Lockheed Martin, MS2 Moorestown, NJ 08057 199 Borton Landing Road, Bldg 780, 2nd Fl, C408 Telephones: Work 856-359-1383 Cell: 267-315-2410 Home and Work 610-644-8404 Fax: 215-790-2976 Co-author: UML 2 For Dummies michael.j.chonoles@lmco.com mjchonoles@yahoo.com From: "Chonoles, Michael J" Subject: RE: EXTERNAL: RE: Concern with 13260 resolution To: Sanford Friedenthal...snip... rtf@omg.org" Thanks Sandy, I figured that was the source of the error, Unfortunately, 1. The «store» stereotype is not defined in the spec 2. The fuel is nowhere in the spec indicated with that stereotype 3. It.s hard to really get a handle on the thinking that the fuel is external to the fuel tank. 4. Most people would model the fuel as a property of the fuel tank, which then should not use the dashed line 5. While the box is dashed, it is almost impossible to see it unless the diagram is at maximum zoom. Closing this issue 13260, would cause several of the above to be issues instead. Michael From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: Saturday, February 11, 2012 10:35 PM To: Chonoles, Michael J; sysml-rtf@omg.org Subject: EXTERNAL: RE: Concern with 13260 resolution Michael I am jumping in but have not looked at this recently. A common pattern that I have used, and I think is being used in the auto example is to define a stored item as a reference property with a user defined stereotype <> applied to it. For example, Fuel is an item that is stored by a fuel tank. It is not part of the fuel tank, but is referenced by it. Sandy From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Thursday, February 09, 2012 5:57 PM To: sysml-rtf@omg.org Subject: Concern with 13260 resolution Perhaps the terminology of .Depletable. store came from an earlier version of SysML, but in 1.3 page 181 Figure C.25 we use a .store.. This is the box labeled Fuel in the lower right corner. While it is difficult to tell from the diagram, if you magnify it, you.ll see it is a dashed box. The description of the diagram and this store is found on the previous page C.4.6.5. .The Fuel store represents a quantity of fuel in the FuelTankAssy, which is drawn by the FuelPump for use in the engine, and is refreshed, to some degree, by fuel returning to the FuelTankAssy via the FuelReturnLine. And in C.4.5.5 .The dashed borders on Fuel denote a store, which keeps track of the amount and mass of fuel in the FuelTankAssy. This is also depicted in Figure C.18. . Note that in Figure C.18, the store is not dashed (though the diagram is). I believe these are the only 2 references to .store. in this context in the specificat ion. In section 8.3.1.2 Internal Block Diagram we have the following. .A part or value property is always shown on an internal block diagram with a solid-outline box. So, Is Fuel a value property or a store?. What is a store? Is the Fuel a property of the Fuel Tank Assembly? It certainly seems to be so. So, if this a .store., we need to connect them to parametrics. If this is just a mistake, we need to clean up the spec. Michael LM Michael Jesse Chonoles Principal Member of Engineering Staff LM co-POC to OMG / coChair OMG ADTF Lockheed Martin, MS2 Moorestown, NJ 08057 199 Borton Landing Road, Bldg 780, 2nd Fl, C408 Telephones: Work 856-359-1383 Cell: 267-315-2410 Home and Work 610-644-8404 Fax: 215-790-2976 Co-author: UML 2 For Dummies michael.j.chonoles@lmco.com mjchonoles@yahoo.com From: "Sanford Friedenthal" To: "'Chonoles, Michael J ...snip... lmco.com>, Subject: RE: EXTERNAL: RE: Concern with 13260 resolution Michael Comments below: Sandy From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Sunday, February 12, 2012 10:35 PM To: Sanford Friedenthal; sysml-rtf@omg.org Subject: RE: EXTERNAL: RE: Concern with 13260 resolution Thanks Sandy, I figured that was the source of the error, Unfortunately, 1. The «store» stereotype is not defined in the spec [sf] the store stereotype is a user defined stereotype, which is a legitimate use of the spec. However, the same modeling approach can be used without the stereotype. 2. The fuel is nowhere in the spec indicated with that stereotype [sf] I am not sure any of the user defined stereotypes are defined in the example. That can be fixed by adding them, or the stereotype can be removed. 3. It.s hard to really get a handle on the thinking that the fuel is external to the fuel tank. [sf] A bolt may be a .part of. the Fuel Tank. The fuel is referenced by the Fuel Tank but not .part of. the tank. Similarly, water is not part of the glass that holds it. 4. Most people would model the fuel as a property of the fuel tank, which then should not use the dashed line [sf] Disagree. I am not sure why you would say most people would do that. I for one, would not model it as a part per my note above. 5. While the box is dashed, it is almost impossible to see it unless the diagram is at maximum zoom. [sf] That is a separate issue with the diagram and not an issue with the approach. Closing this issue 13260, would cause several of the above to be issues instead. [sf] I think we should close it per my original response. Michael From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: Saturday, February 11, 2012 10:35 PM To: Chonoles, Michael J; sysml-rtf@omg.org Subject: EXTERNAL: RE: Concern with 13260 resolution Michael I am jumping in but have not looked at this recently. A common pattern that I have used, and I think is being used in the auto example is to define a stored item as a reference property with a user defined stereotype <> applied to it. For example, Fuel is an item that is stored by a fuel tank. It is not part of the fuel tank, but is referenced by it. Sandy From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Thursday, February 09, 2012 5:57 PM To: sysml-rtf@omg.org Subject: Concern with 13260 resolution Perhaps the terminology of .Depletable. store came from an earlier version of SysML, but in 1.3 page 181 Figure C.25 we use a .store.. This is the box labeled Fuel in the lower right corner. While it is difficult to tell from the diagram, if you magnify it, you.ll see it is a dashed box. The description of the diagram and this store is found on the previous page C.4.6.5. .The Fuel store represents a quantity of fuel in the FuelTankAssy, which is drawn by the FuelPump for use in the engine, and is refreshed, to some degree, by fuel returning to the FuelTankAssy via the FuelReturnLine. And in C.4.5.5 .The dashed borders on Fuel denote a store, which keeps track of the amount and mass of fuel in the FuelTankAssy. This is also depicted in Figure C.18. . Note that in Figure C.18, the store is not dashed (though the diagram is). I believe these are the only 2 references to .store. in this context in the specificat ion. In section 8.3.1.2 Internal Block Diagram we have the following. .A part or value property is always shown on an internal block diagram with a solid-outline box. So, Is Fuel a value property or a store?. What is a store? Is the Fuel a property of the Fuel Tank Assembly? It certainly seems to be so. So, if this a .store., we need to connect them to parametrics. If this is just a mistake, we need to clean up the spec. Michael LM Michael Jesse Chonoles Principal Member of Engineering Staff LM co-POC to OMG / coChair OMG ADTF Lockheed Martin, MS2 Moorestown, NJ 08057 199 Borton Landing Road, Bldg 780, 2nd Fl, C408 Telephones: Work 856-359-1383 Cell: 267-315-2410 Home and Work 610-644-8404 Fax: 215-790-2976 Co-author: UML 2 For Dummies michael.j.chonoles@lmco.com mjchonoles@yahoo.com