From owner-shlaer-mellor-users@phoenix.projtech.com Wed Mar 21 11:00:54 2001 Received: from phoenix.projtech.com ([209.234.139.66]) by saturn.cs.uml.edu (8.11.0/8.11.2) with ESMTP id f2LG0rS491082 for ; Wed, 21 Mar 2001 11:00:54 -0500 (EST) Received: (from majordom@localhost) by phoenix.projtech.com (8.9.3+Sun/8.9.1) id IAA02660 for s-m-users-outgoing; Wed, 21 Mar 2001 08:27:47 -0700 (MST) X-Authentication-Warning: phoenix.projtech.com: majordom set sender to owner-shlaer-mellor-users@projtech.com using -f From: erick.hagstrom@webmd.net Subject: (SMU) Dead object instances To: shlaer-mellor-users@projtech.com Cc: X-Mailer: Lotus Notes Release 5.0.1b September 30, 1999 Message-ID: Date: Wed, 21 Mar 2001 09:26:24 -0600 X-Priority: 3 (Normal) X-MIMETrack: Serialize by Router on Gadwall/Nashville/Envoy(Release 5.0.1b|September 30, 1999) at 03/21/2001 09:26:26 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-shlaer-mellor-users@projtech.com Precedence: bulk Reply-To: shlaer-mellor-users@projtech.com Errors-To: owner-shlaer-mellor-users@projtech.com X-Status: Status: RO erick.hagstrom@webmd.net writes to shlaer-mellor-users: -------------------------------------------------------------------- The CASE tool that I use has a "select" statement that's used to get one or more references to object instances based on various criteria, including participation in a relationship and/or attribute values. The selected object instances can be and frequently are active objects, i.e. they have a state model. Some of them have a born-and-die lifecycle, meaning they can dynamically be created and destroyed within the context of the analysis. I have the added complication of having my models translated into a multi-threaded executable using the concurrent view of time running on a multi-processor machine, so more than one state action (in different object instances) can be executing at the exact same time. It follows that any of these born-and-die object instances can potentially disappear at any moment. Makes for some interesting potential race conditions. So, finally, here's the question that I need answered: Is it the analyst's responsibility to ensure that no dead (or dying, i.e. currently executing the action in their final delete state) (or about to die, i.e. can be expected to enter their final delete state in the immediate future) object instances are requested in a select? Or is it the architecture's responsibility to ensure that 1) select statements only return live object instances, and b) no selected object instance gets deleted during the lifetime of the the action which performed the select? Or is it actually some combination of the two? Any insights would be appreciated. Thanks. From owner-shlaer-mellor-users@phoenix.projtech.com Wed Mar 21 12:00:54 2001 Received: from phoenix.projtech.com ([209.234.139.66]) by saturn.cs.uml.edu (8.11.0/8.11.2) with ESMTP id f2LH0rS496099 for ; Wed, 21 Mar 2001 12:00:54 -0500 (EST) Received: (from majordom@localhost) by phoenix.projtech.com (8.9.3+Sun/8.9.1) id JAA05478 for s-m-users-outgoing; Wed, 21 Mar 2001 09:21:21 -0700 (MST) X-Authentication-Warning: phoenix.projtech.com: majordom set sender to owner-shlaer-mellor-users@projtech.com using -f From: "Peter J. Fontana" To: Subject: RE: (SMU) Dead object instances Date: Wed, 21 Mar 2001 11:21:35 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: Sender: owner-shlaer-mellor-users@projtech.com Precedence: bulk Reply-To: shlaer-mellor-users@projtech.com Errors-To: owner-shlaer-mellor-users@projtech.com X-Status: Status: RO "Peter J. Fontana" writes to shlaer-mellor-users: -------------------------------------------------------------------- > Is it the analyst's responsibility to ensure that no dead (or dying, i.e. > currently executing the action in their final delete state) (or about to > die, i.e. can be expected to enter their final delete state in the > immediate future) object instances are requested in a select? Or is it the > architecture's responsibility to ensure that 1) select statements only > return live object instances, and b) no selected object instance gets > deleted during the lifetime of the the action which performed the select? > Or is it actually some combination of the two? The simple academic world tends to like this type of question to be decided so the Analyst can freely/blindly go do anything they want, and it's the Architecutre's responsibility to make it all work. While it is *possible* to accomplish this in the Architecture, your organization needs to make a business decision that it wants to incur the expense of developing this level of sophistication. Or make the decision that is instead will publish a restriction to Analysts that they must inspect their models (including the actions) to verify that this condition does not occur. There is also the consideration of code size/speed impacts of implementing this type of general architectural capability. "Big Architecture" is a very difficult problem for many organizations. The real answer is that you need to examine your application characteristics, overall product architecture strategy, and performance constraints. Your final strategy could be a compromise, where the Analyst must be prepared to operate on a snapshot of data, where some of the references retrieved may be invalid. The Architecture steps up with safeguards if the Analyst tries to dereference a reference to an already-deleted instance. _________________________________________________ Pathfinder Solutions www.pathfindersol.com We Make UML Work. 888-662-PATH Peter J. Fontana voice: +01 508-384-1392 peterf@pathfindersol.com fax: +01 508-384-7906 _________________________________________________ From owner-shlaer-mellor-users@phoenix.projtech.com Wed Mar 21 12:44:57 2001 Received: from phoenix.projtech.com ([209.234.139.66]) by saturn.cs.uml.edu (8.11.0/8.11.2) with ESMTP id f2LHiuS494882 for ; Wed, 21 Mar 2001 12:44:56 -0500 (EST) Received: (from majordom@localhost) by phoenix.projtech.com (8.9.3+Sun/8.9.1) id KAA06089 for s-m-users-outgoing; Wed, 21 Mar 2001 10:00:30 -0700 (MST) X-Authentication-Warning: phoenix.projtech.com: majordom set sender to owner-shlaer-mellor-users@projtech.com using -f Message-Id: From: "Lynch, Chris D. SDX" To: "'shlaer-mellor-users@projtech.com'" Subject: RE: (SMU) Dead object instances Date: Wed, 21 Mar 2001 10:55:41 -0600 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-shlaer-mellor-users@projtech.com Precedence: bulk Reply-To: shlaer-mellor-users@projtech.com Errors-To: owner-shlaer-mellor-users@projtech.com X-Status: Status: RO "Lynch, Chris D. SDX" writes to shlaer-mellor-users: -------------------------------------------------------------------- There was a thread awhile back which discussed this extensively but inconclusively. Your architect cannot possibly be expected to deal with this, unless you contemplate some sort of global "freeze" during actions with Select operations. The problem you refer to applies to not only the existence of the instances but the values of their attributes used in the selection (e.g., a fuel tank goes to zero lbs. during the course of the action, after a Select statement has asked for tanks with weight greater than zero.) As an analyst, I would look for ways to reason about how the targets of my Select might change, and handle the potential errors in my state action. You may need help from your architect in dealing with deleted instances (e.g., he probably shouldn't throw a malfunction if you send a message to a deleted instance.) Good luck! -Chris ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Christopher D. Lynch, Sr. Software Engineer Abbott Ambulatory Infusion Systems San Diego, CA 92128 email: LYNCHCD@HPD.ABBOTT.COM voice: (858) 485-7474 x261 fax: (858) 485-7709 > -----Original Message----- > From: erick.hagstrom@webmd.net [SMTP:erick.hagstrom@webmd.net] > Sent: Wednesday, March 21, 2001 7:26 AM > To: shlaer-mellor-users@projtech.com > Subject: (SMU) Dead object instances > > erick.hagstrom@webmd.net writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > The CASE tool that I use has a "select" statement that's used to get one > or > more references to object instances based on various criteria, including > participation in a relationship and/or attribute values. The selected > object instances can be and frequently are active objects, i.e. they have > a > state model. Some of them have a born-and-die lifecycle, meaning they can > dynamically be created and destroyed within the context of the analysis. I > have the added complication of having my models translated into a > multi-threaded executable using the concurrent view of time running on a > multi-processor machine, so more than one state action (in different > object > instances) can be executing at the exact same time. It follows that any of > these born-and-die object instances can potentially disappear at any > moment. Makes for some interesting potential race conditions. So, finally, > here's the question that I need answered: > > Is it the analyst's responsibility to ensure that no dead (or dying, i.e. > currently executing the action in their final delete state) (or about to > die, i.e. can be expected to enter their final delete state in the > immediate future) object instances are requested in a select? Or is it the > architecture's responsibility to ensure that 1) select statements only > return live object instances, and b) no selected object instance gets > deleted during the lifetime of the the action which performed the select? > Or is it actually some combination of the two? > > Any insights would be appreciated. Thanks. From owner-shlaer-mellor-users@phoenix.projtech.com Wed Mar 21 15:21:35 2001 Received: from phoenix.projtech.com ([209.234.139.66]) by saturn.cs.uml.edu (8.11.0/8.11.2) with ESMTP id f2LKLYS456232 for ; Wed, 21 Mar 2001 15:21:34 -0500 (EST) Received: (from majordom@localhost) by phoenix.projtech.com (8.9.3+Sun/8.9.1) id MAA12579 for s-m-users-outgoing; Wed, 21 Mar 2001 12:41:30 -0700 (MST) X-Authentication-Warning: phoenix.projtech.com: majordom set sender to owner-shlaer-mellor-users@projtech.com using -f From: erick.hagstrom@webmd.net Subject: (SMU) Atomicity of actions To: shlaer-mellor-users@projtech.com Cc: X-Mailer: Lotus Notes Release 5.0.1b September 30, 1999 Message-ID: Date: Wed, 21 Mar 2001 13:41:22 -0600 X-Priority: 3 (Normal) X-MIMETrack: Serialize by Router on Gadwall/Nashville/Envoy(Release 5.0.1b|September 30, 1999) at 03/21/2001 01:41:25 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-shlaer-mellor-users@projtech.com Precedence: bulk Reply-To: shlaer-mellor-users@projtech.com Errors-To: owner-shlaer-mellor-users@projtech.com X-Status: Status: RO erick.hagstrom@webmd.net writes to shlaer-mellor-users: -------------------------------------------------------------------- Part of the problem is that there is no such thing as "atomicity of actions". Under the concurrent view of time--which is a recognized option and absolutely essential for my application--there is no guarantee that a) an action will execute to completion in one continuous timeslice, b) no other action will be executing either at the same time or interleaved with our action. The only analysis rule that applies here is that a single state machine which is executing an action cannot undergo a state transition until the executing action completes. Yes, that complicates the picture, but that's the picture I'm dealing with. Carolyn Duby cc: Subject: RE: (SMU) Dead object instances 03/21/01 09:57 AM Please respond to shlaer-mellor-user s "Carolyn Duby" writes to shlaer-mellor-users: -------------------------------------------------------------------- The design should not return any deleted instances when doing a select. In addition, the design should enforce the atomicity of actions so that the objects referenced in the select are not deleted during the time the action is executing. From owner-shlaer-mellor-users@phoenix.projtech.com Wed Mar 21 15:56:23 2001 Received: from phoenix.projtech.com ([209.234.139.66]) by saturn.cs.uml.edu (8.11.0/8.11.2) with ESMTP id f2LKuMS520181 for ; Wed, 21 Mar 2001 15:56:22 -0500 (EST) Received: (from majordom@localhost) by phoenix.projtech.com (8.9.3+Sun/8.9.1) id NAA15358 for s-m-users-outgoing; Wed, 21 Mar 2001 13:14:20 -0700 (MST) X-Authentication-Warning: phoenix.projtech.com: majordom set sender to owner-shlaer-mellor-users@projtech.com using -f Message-ID: <27449627AC42D311AD7C00A0C9EBECA4013A327D@BXNT4S9> From: "Levkoff, Bruce" To: "'shlaer-mellor-users@projtech.com'" Subject: RE: (SMU) Dead object instances Date: Wed, 21 Mar 2001 15:12:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-shlaer-mellor-users@projtech.com Precedence: bulk Reply-To: shlaer-mellor-users@projtech.com Errors-To: owner-shlaer-mellor-users@projtech.com X-Status: Status: RO "Levkoff, Bruce" writes to shlaer-mellor-users: -------------------------------------------------------------------- Since actions of different state machines can be operating simultaneously but the object cannot receive an event if it is executing an action (the Bible, page 47), your problem has both architectural and analytic issues. Architecturally, you would prevent your system from crashing if an event was posted to an object that was no longer in existance. Also, your system should not try to execute an accessor of an object that no longer exists. We accomplished this by the use of a signature attribute (like Java's CAFEBABE) which is zeroed when the object is deleted. Carolyn's reference count suggestion can be implemented in the architecture or in analysis. I like the idea of doing it in the models, since a developer (in my experience) should understand when and why an object is leaving us. If this is really not known with certainty, then modeling the behavior becomes more difficult, since you would have to continually check the existance of the target object. If you don't have access to the code on the remote processors and can't update the architecture, you could use timeouts for all interprocessor communication. The client object on the local processor would have a callback for timed-out requests in case the target object was no longer there. Bruce -----Original Message----- From: erick.hagstrom@webmd.net [mailto:erick.hagstrom@webmd.net] Sent: Wednesday, March 21, 2001 10:26 AM To: shlaer-mellor-users@projtech.com Subject: (SMU) Dead object instances erick.hagstrom@webmd.net writes to shlaer-mellor-users: -------------------------------------------------------------------- I have the added complication of having my models translated into a multi-threaded executable using the concurrent view of time running on a multi-processor machine, so more than one state action (in different object instances) can be executing at the exact same time. It follows that any of these born-and-die object instances can potentially disappear at any moment. From owner-shlaer-mellor-users@phoenix.projtech.com Wed Mar 21 17:16:09 2001 Received: from phoenix.projtech.com ([209.234.139.66]) by saturn.cs.uml.edu (8.11.0/8.11.2) with ESMTP id f2LMG8S02086 for ; Wed, 21 Mar 2001 17:16:08 -0500 (EST) Received: (from majordom@localhost) by phoenix.projtech.com (8.9.3+Sun/8.9.1) id OAA24572 for s-m-users-outgoing; Wed, 21 Mar 2001 14:37:35 -0700 (MST) X-Authentication-Warning: phoenix.projtech.com: majordom set sender to owner-shlaer-mellor-users@projtech.com using -f Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Wed, 21 Mar 2001 15:31:32 -0600 From: "Dana Simonson" To: shlaer-mellor-users@projtech.com Subject: Re: (SMU) Atomicity of actions Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by phoenix.projtech.com id OAA24565 Sender: owner-shlaer-mellor-users@projtech.com Precedence: bulk Reply-To: shlaer-mellor-users@projtech.com Errors-To: owner-shlaer-mellor-users@projtech.com X-Status: Status: RO "Dana Simonson" writes to shlaer-mellor-users: -------------------------------------------------------------------- 1) OL p 106 "It is the responsibility of the analyst to ensure that the data required by an action is consistent..." 2) The analysis is at a different level of abstraction from the architecture. A single analysis of a problem space should work, without modification, on both a single and multi-threaded architecture. I would, at a minimum, place the requirement on the architecture to provide some mechanism, such that once I touch an instance of an object, that instance will remain locked until the entire action completes. This basic requirement must be in place to allow the analysis to "leave the system consistent." Without this support, no analysis could ever claim consistency under the simultaneous view of time without also analyzing the separate problem space of data locking. A more advanced architecture could provide smarter locking and achieve better performance. The architecture may also need to deal with the potential of deadlock. If you want the data locking issue analyzed, do it and then include that domain as an architectural support domain for the real problem you are trying to solve. >>> 03/21 1:41 PM >>> erick.hagstrom@webmd.net writes to shlaer-mellor-users: -------------------------------------------------------------------- Part of the problem is that there is no such thing as "atomicity of actions". Under the concurrent view of time--which is a recognized option and absolutely essential for my application--there is no guarantee that a) an action will execute to completion in one continuous timeslice, b) no other action will be executing either at the same time or interleaved with our action. The only analysis rule that applies here is that a single state machine which is executing an action cannot undergo a state transition until the executing action completes. Yes, that complicates the picture, but that's the picture I'm dealing with. Carolyn Duby cc: Subject: RE: (SMU) Dead object instances 03/21/01 09:57 AM Please respond to shlaer-mellor-user s "Carolyn Duby" writes to shlaer-mellor-users: -------------------------------------------------------------------- The design should not return any deleted instances when doing a select. In addition, the design should enforce the atomicity of actions so that the objects referenced in the select are not deleted during the time the action is executing.