'archive.9701' -- Subject: (SMU) Happy New Year Phil Ryals writes to shlaer-mellor-users: -------------------------------------------------------------------- I hope you all had a relaxing and enjoyable holiday season. The shlaer-mellor-users mailing list is once again open for business. We did a few things to improve robustness of the list while it was down, including the application of a number of filters that should help prevent the insidious mail loops we sometimes encounter with misbehaving mailers and vacation programs. The only change that should be directly visible to you has to do with the digest archive files. They have been renumbered to reflect the year in the volume number. I'm looking forward to your continued participation on this mailing list. Best wishes for the New Year, Phil Ryals majordomo-owner@projtech.com Subject: (SMU) Self-Generated Delayed Event Delivery Dana Simonson writes to shlaer-mellor-users: -------------------------------------------------------------------- OOA96 Rule: "If an instance of an object sends an event to itself, that event will be accepted before any other events that have yet to be accepted by the same instance." For the purpose of event ordering, is a delayed event sent to yourself considered a self-generated event? In other words: Since self-generated events are received before any other pending events, and delayed events are not generated until after the delay time, it is possible to have processed several self-generated and external events, and have other self-generated and external events pending when the delayed event is generated. Is this delayed event processed before other pending internal and/or external events? Subject: (SMU) Happy New YearHey! I'm not here right now... Mark Lilley writes to shlaer-mellor-users: -------------------------------------------------------------------- Hi, this is an automated email reply. I am on leave until 13/1/97. If you need to contact me urgently try the following places: Home: ph 3228 347 Pohara Beach Camp (site A36) (probably 27/12/96 - 67/1/96) Golden Bay Mark. Subject: (SMU) Self-Generated Delayed Event DeliveryHey! I'm not Mark Lilley writes to shlaer-mellor-users: -------------------------------------------------------------------- Hi, this is an automated email reply. I am on leave until 13/1/97. If you need to contact me urgently try the following places: Home: ph 3228 347 Pohara Beach Camp (site A36) (probably 27/12/96 - 67/1/96) Golden Bay Mark. Subject: (SMU) Happy New YearHey! I'm not here right now...Hey! I'm Mark Lilley writes to shlaer-mellor-users: -------------------------------------------------------------------- not here right now... Hi, this is an automated email reply. I am on leave until 13/1/97. If you need to contact me urgently try the following places: Home: ph 3228 347 Pohara Beach Camp (site A36) (probably 27/12/96 - 67/1/96) Golden Bay Mark. Subject: (SMU) Self-Generated Delayed Event DeliveryHey! I'm Mark Lilley writes to shlaer-mellor-users: -------------------------------------------------------------------- Hi, this is an automated email reply. I am on leave until 13/1/97. If you need to contact me urgently try the following places: Home: ph 3228 347 Pohara Beach Camp (site A36) (probably 27/12/96 - 67/1/96) Golden Bay Mark. Subject: (SMU) Mark Lilley's auto responder Mike Morrin writes to shlaer-mellor-users: -------------------------------------------------------------------- Phil, I have turned it off. So if you haven't bounced Mark already, you shouldn't need to. regards, Mike | ____.__ | Mike Morrin (mike_morrin@tait.co.nz)| | //||| | Research Coordinator | | //_||| | Advanced Technology Group | | // ||| | Tait Electronics Ltd | Subject: (SMU) Happy New Year... Brion Wikes writes to shlaer-mellor-users: -------------------------------------------------------------------- Happy New Year to all... wishing everyone a healthy and prosperous ' 97. If this year includes a career change, check out this new job board... limited to an exclusive group of companies in the silicon valley doing some nifty leading edge development.. http://www.geocities.com/SiliconValley/Heights/1409/spotlight.html brion brion@intertrust.com staffing manager\ InterTrust technologies.... http://www.intertrust.com ...developing solutions for internet commerce and digital rights management over the web... Subject: (SMU) filter test Phil Ryals writes to shlaer-mellor-users: -------------------------------------------------------------------- This is a test for a majordomo taboo header filter. If it makes it out to the mailing list, my apologies. Please discard it. Thanks, Phil Subject: RE: (SMU) Happy New YearHey! I'm not here right now... "John Harby" writes to shlaer-mellor-users: -------------------------------------------------------------------- I'm getting mail-bombed with these automated replies. Anyone else? ---------- From: owner-shlaer-mellor-users@projtech.com on behalf of Mark Lilley Sent: Monday, January 06, 1997 2:16 PM To: shlaer-mellor-users@projtech.com Subject: (SMU) Happy New YearHey! I'm not here right now... Mark Lilley writes to shlaer-mellor-users: -------------------------------------------------------------------- Hi, this is an automated email reply. I am on leave until 13/1/97. If you need to contact me urgently try the following places: Home: ph 3228 347 Pohara Beach Camp (site A36) (probably 27/12/96 - 67/1/96) Golden Bay Mark. Subject: RE: (SMU) Self-Generated Delayed Event Delivery "John Harby" writes to shlaer-mellor-users: -------------------------------------------------------------------- But wouldn't the lifecycle of the delayed event really begin upon it's occurance and not with the beginning of the delay? For example, a common instance might be a UNIX cron table. If I enter a job to back up the system weekly, I would presume that the actual event of the backup would be when the cron daemon kicks off the job, not when I enter it as pending. I think the OOA rule assumes that the event is in an active state. ---------- From: owner-shlaer-mellor-users@projtech.com on behalf of Dana Simonson Sent: Monday, January 06, 1997 12:55 PM To: shlaer-mellor-users@projtech.com Subject: (SMU) Self-Generated Delayed Event Delivery Dana Simonson writes to shlaer-mellor-users: -------------------------------------------------------------------- OOA96 Rule: "If an instance of an object sends an event to itself, that event will be accepted before any other events that have yet to be accepted by the same instance." For the purpose of event ordering, is a delayed event sent to yourself considered a self-generated event? In other words: Since self-generated events are received before any other pending events, and delayed events are not generated until after the delay time, it is possible to have processed several self-generated and external events, and have other self-generated and external events pending when the delayed event is generated. Is this delayed event processed before other pending internal and/or external events? Subject: Re: (SMU) Self-Generated Delayed Event Delivery Tony Humphrey-Lewis writes to shlaer-mellor-users: -------------------------------------------------------------------- On Mon, 6 Jan 1997, Dana Simonson wrote: > Dana Simonson writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > OOA96 Rule: "If an instance of an object sends an > event to itself, that event will be accepted > before any other events that have yet to be > accepted by the same instance." > > > For the purpose of event ordering, is a delayed > event sent to yourself considered a > self-generated event? > No it isn't. This is because the mechanism by which the event is delayed is to use OOA timers (Object Lifecycles p.52). To get the delayed event you send a TIM1 event to the Timer object with supplemental data of :- time remaining event label instance ID When the delay expires then the *Timer object* sends the specified instance the specified event. +----------------------------------------------------+ | Anthony Humphrey-Lewis Software Development | | GPT Ltd. | | email: hlewisa@ncp.gpt.co.uk Business Systems | | Technology Drive | | Beeston | | Notts. NG9 1LA | | United Kingdom | | Telephone: +44 115 943 4290 Fax: +44 115 943 3805 | +----------------------------------------------------+ Subject: Re: (SMU) Self-Generated Delayed Event Delivery fontana@world.std.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 09:33 AM 1/7/97 +0000, shlaer-mellor-users@projtech.com wrote: >Tony Humphrey-Lewis writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >On Mon, 6 Jan 1997, Dana Simonson wrote: > >> Dana Simonson writes to shlaer-mellor-users: >> -------------------------------------------------------------------- >> >> OOA96 Rule: "If an instance of an object sends an >> event to itself, that event will be accepted >> before any other events that have yet to be >> accepted by the same instance." >> >> >> For the purpose of event ordering, is a delayed >> event sent to yourself considered a >> self-generated event? >> > >No it isn't. This is because the mechanism by which the event is delayed >is to use OOA timers (Object Lifecycles p.52). > >To get the delayed event you send a TIM1 event to the Timer object ... I think we must be very careful when asking questions about OOA96, and then referring to "Object Lifecycles" to clarify. While it is not stated explicitly in OOA96, I believe one intent of Delayed Events is to obsolete the TIM object. If your architecture has TIM still, then this may be how your project may implement the Delayed Event, but it is not a universal approach. I do agree that the "self-ness" of the event should not become evident until it is actually being queued - after the delay, but this is just my opinion - OOA96 does not clarify. _________________________________________________ Peter Fontana Pathfinder Solutions Inc. | | effective solutions for OOA/RD challenges | | fontana@world.std.com voice/fax: 508-384-1392 | _________________________________________________| Subject: (SMU) Self-Generated Delayed Event Delivery [Without Timers] Dana Simonson writes to shlaer-mellor-users: -------------------------------------------------------------------- OOA96 replaced the timer with delayed events: "Timers, as prescribed in OOA91 [Lifecycles book], required the analyst to combine information from the domain under consideration with the domain of the formalism itself. This situation has been remedied in OOA96, wherein the functionality previously ascribed to a timer is now associated with a new concept: a delayed event." -section 9.4, The OOA96 Report. Since the timer is no longer part of the analysis, it cannot be the source of the event. The event is sourced by the originator. The problem comes in only on the consideration of whether a self-generated delayed event gets dispatched before other events already in the queue. >>> Tony Humphrey-Lewis 01/07/97 03:33am >>> Tony Humphrey-Lewis writes to shlaer-mellor-users: -------------------------------------------------------------------- On Mon, 6 Jan 1997, Dana Simonson wrote: > Dana Simonson writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > OOA96 Rule: "If an instance of an object sends an > event to itself, that event will be accepted > before any other events that have yet to be > accepted by the same instance." > > > For the purpose of event ordering, is a delayed > event sent to yourself considered a > self-generated event? > No it isn't. This is because the mechanism by which the event is delayed is to use OOA timers (Object Lifecycles p.52). To get the delayed event you send a TIM1 event to the Timer object with supplemental data of :- time remaining event label instance ID When the delay expires then the *Timer object* sends the specified instance the specified event. +----------------------------------------------------+ | Anthony Humphrey-Lewis Software Development | | GPT Ltd. | | email: hlewisa@ncp.gpt.co.uk Business Systems | | Technology Drive | | Beeston | | Notts. NG9 1LA | | United Kingdom | | Telephone: +44 115 943 4290 Fax: +44 115 943 3805 | +----------------------------------------------------+ Subject: (SMU) Message Information Model Andrew Nortje writes to shlaer-mellor-users: -------------------------------------------------------------------- Hi Everyone We have been using the Shlaer Mellor method for approx a year. I am now trying to model a message system and am having some trouble - have any of you some ideas on the following problem. The problem is essentially this - I have a system that receives a number of messages. The messages are all the same size ( have the same number of bytes), have a type descriptor to destinguish messages, and obviously each carry different data. The type descriptor gives an indication of what group of data the message carries. I need to track certain (but not all) data in various of the messages. The problem I have is how to describe the different messages with their differnet data in the information model elegantly without having a specification object for each message - which I am currently considering. Currently I have say 20 specification objects, each which have between 20 and 30 attributes to describe the data in each message . This looks ugly and does'nt feel right. I have also considered having one message object and creating a whole lot of instances of the message a start up (run) time for each different type of message. This is also no good because even though each message has the same amount of data, how the data is broken up in the message i.e. the domain of each attribute describing the message, is differnet for different messages i.e. it appears to me I can't have a generic message object because the data contained in the message is too different. I have a feeling I am confusing either domains ( application and architecture) or analysis and design. Any help will be appreciated Thanks Andrew Subject: (SMU) Cancel Robert naiditch writes to shlaer-mellor-users: -------------------------------------------------------------------- I am moving to another company soon. Until then, please cancel my subscription. Thank you, Robert Naiditch Subject: Re: (SMU) Message Information Model David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: -------------------------------------------------------------------- > [message is set of bytes; tag-field gives type; SM model feels wrong] I don't know the precise details of what you are doing but I suspect that the use of multiple domains would simplify it. At the most fundamental level theree are two domains: one that knows how to push round blocks of bytes and other that knows about messages. The bridge between them would do any marshalling, etc needed to convert between the two. (application domain)------>(messaging domain) The may be information from many domains within a single message. For example, there may be information for a router. Then the messaging domain would be split: (application)---->(messaging)<----(routing) Obviously there are many more possible combinations. In our system we have a concept of hardware control registers that are composed of bitfields. Some domains view these as 8/16/32 entities for bus accesses (the Bus and DMA domains are examples). Others see the bitfields within their registers and others don't even realise that the registers exist (The bits are distributed in the attributes of many objects). This can lead to quite complex bridging requirements. It is only recently that we have been able to do this type of thing and I'm not sure that the new Wormhole definitions allow it - we might need to look again. To summarise, to solve your problem in an aesthetically pleasing way requires an interaction between architectural domains and application domains. You bridges need to give you different views of the same physical data. Not all case tools allow you to do this easily. Dave. -- David P. Whipp. Not speaking for: ------------------------------------------------------- G.E.C. Plessey Due to transcription and transmission errors, the views Semiconductors expressed here may not reflect even my own opinions! Subject: Re: (SMU) Message Information Model dave (Dave Wanner) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 04:14 PM 1/7/97 +0200, you wrote: >Andrew Nortje writes to shlaer-mellor-users: Andrew, A good thing to do is ask yourself what is it that you are trying to model and what will you be using it for. For example, if you need to receive messages and track some of there data, then you will need to understand the format of the message so that you can get to the data you need to track. This might call for two types of objects (each type will probably contain several objects). First, specification objects that address understanding a messages format (so you can get to the data you need to track). Secondly, instances of actual objects (in this case, instances of actual message objects that your software receives). 1. Specification Objects You might try to abstract a generic object to represent a message. I'll call it Message_Specification. This object would certainly have an attribute named Message_Type. Now, what about all that data within the message. Recall, that since you need to track some of the data you need to understand the format of the message data. A way to do this is to define an object to represent the types of data you receive in messages. Not, data-types, but, real-world types -- like Train_ID, Train_Speed in a Train Management application. I'll call this object Message_Field. And, also the length of the Message_Field would be needed. You may have certain messages that contain the same Message_Field in the same positions, or, the same Message_Field in different positions of the message. Thus, you may need to abstract an associative object that ties together a Message_Specification with all of its Message_Fields. I'll call this object Message_Field_In_Specification_Message. It would probably contain both identifiers from each associated object (i.e. from Message_Specification and from Message_Field) to make up its identifier. Yes, you would have an instance of Message_Field_In_Specification for each Message_Field in a particular Message_Specification. And, it would contain additional information about where the particular Message_Field starts in this particular Message_Type. And, lastly it might contain an attribute that describes if this Message_Field needs to be tracked. 2. The Real Message Object Now, the real message is a different type of object. It contains the actual data that you want to track, however, the only way that you can get the data is through something you've called a type descriptor. That type descriptor is what I've attempted to make the Message_Type of the Message_Specification object. Thus, with this mapping of an actual message type descriptor to the specification object Message_Specification you now have enough information to parse the data you care about (it's represented in instances of Message_Field_In_Specification_Message). But, the real messages may have more things associated with it. Many times it will have a message header (usually a fixed format for all messages) which can be expressed as attributes in an object like Incoming_Message. It might also have a data portion of the message where all the variable data resides. This can be handled again as an attribute such as Message_Data. And, perhaps your messages have a message trailer. This is where you need to really use you analysis skills to understand the actual messages being received. Is there a generic way to abstract Incoming_Messages so if suddenly you have messages of differing lengths you analysis model won't break? Well, I hope that some of these ideas help. I'm not saying this is the only way to parse messages, but, I've seen it work in many application. It's good in that it expresses the structure of messages in data and relationships rather than in subtypes of messages. If a message format changes then all that might be required is the creation of a new Message_Specification object, its related Message_Field_In_Specification_Message instances and maybe some new Message_Field instances. These can be pre-existing instances or can be created during run-time. As to your question about domains. Usually I see a domain entitled Message Receiver -or- Message Decoder -or- Message Wrapper. It's mission is take a received message, unpack data and forward the data. This is where the above mentioned analysis objects would reside. Another domain usually like TCP/IP Communications is the actual domain which deals with transport and error control. Usually, this domain is a purchased product. Good Luck... Dave E. Wanner Project Technology Technical Staff Subject: Re: (SMU) Self-Generated Delayed Event Delivery [Without Timers] "Stephen R. Tockey" writes to shlaer-mellor-users: -------------------------------------------------------------------- > > Dana Simonson wrote: > > > -------------------------------------------------------------------- > > > > OOA96 Rule: "If an instance of an object sends an > > event to itself, that event will be accepted > > before any other events that have yet to be > > accepted by the same instance." > > > > > > For the purpose of event ordering, is a delayed > > event sent to yourself considered a > > self-generated event? > > to which Tony Humphrey-Lewis responded: > -------------------------------------------------------------------- > > OOA96 replaced the timer with delayed events: > "Timers, as prescribed in OOA91 [Lifecycles > book], required the analyst to combine > information from the domain under consideration > with the domain of the formalism itself. This > situation has been remedied in OOA96, wherein the > functionality previously ascribed to a timer is > now associated with a new concept: a delayed > event." -section 9.4, The OOA96 Report. > > Since the timer is no longer part of the > analysis, it cannot be the source of the event. > The event is sourced by the originator. The > problem comes in only on the consideration of > whether a self-generated delayed event gets > dispatched before other events already in the > queue. > then Steve Tockey adds: --------------------------------------------------------------------- I think this thread is a good real-world example of the issue of essence vs. incarnation that I was talking about before the holidays. Basically, I see there being a conflict between making a clear statement of the business policy/business process (the essence) and deciding on a reasonable mechanism to automate (incarnation, aka design) that essence. The quote from section 9.4 of the OOA96 report highlights exactly this situation. The conditions under which the processing is to continue is a "domain under consideration" issue whereas timers (and their use as event recognition mechanisms) are rightfully "domain of the (execution) formalism" artifacts. In a pure "describe the business and only the business" world we ought to only need to make statements of the form, "this happens, then, later, that happens" where (later) is specified in relative (e.g., 5 seconds later) or absolute (e.g., at 6:45 pm) terms. Assuming that Dana Simonson is really after a relative time delay (e.g., wait 5 seconds) then an "essential" OOA ought only to say something like, "the event that gets us out of this state is the passage of 5 seconds after the time at which we entered this state". IMHO, this is a sufficiently precise statement of the business process that both the customer and the designer can correctly interpret the requirement in exactly one way (this is goodness). But notice that nothing at all was stated about the mechanism for recognizing that business event (the "5 seconds later..."). Timers, marktimes, delay loops, etc. are all potential mechanisms for recognizing the fact that 5 seconds has passed. It is the designer's responsibility (and privelege) to choose one or more of these mechanisms based on their plusses and minuses (like portability, accuracy, allowing other processing to take place concurrently, simplicity, etc.) in light of the needs of the rest of the design. We ought to be able to define the needs of the business (essence) in the OOA, simply and precisely. Being able to define OOA events in terms of relative time (e.g., "E47: 5 seconds later") and absolute time (e.g., "E48: at 6:45 PM every day") could suffice to precisely specify the needs of the business. Of course (as I said before), unless you have a more complex translator this spoils the ability to directly translate from the OOA model. But this is exactly where the proposed notion of "overlays" comes in. Overlay "A" could define that E47 is to be recognized using a timer and that E48 is to be recognized using a marktime. Overlay "B" could define different event recognition mechanisms, such as delay loops and chron jobs instead. As long as a given translator, say translator "X" handled timers and marktimes, it could translate the original essence using overlay "A". Similarly translator "Y" could translate the essence using overlay "B" if it handled delay loops and chron jobs. Translator "Z" could translate the essence with either overlay if it handled all of timers, marktimes, delay loops, and chron jobs. In summary, I hope this real-world example brings out the following points: 1) The pure statement of the business will (probably) always be as precise but simpler than a fully translatable S-M OOA. This is good because both the customer and the designer will be able to understand unambiguously what is needed. 2) The pure essential model is probably untranslatable as-is and requires some "assistance" (the "overlay). But that's not that bad in the long run because it brings in the capability to mix and match translators and overlays leading to a (potential) combinatoric explosion in the number of end implementations generatable from the same essential OOA model. 3) These "overlays" are little more than a more elaborate means of coloring OOA models where multiple colorings for the same OOA model are supported. 4) The combination of an essential OOA model and one of its overlays ought to be exactly equivalent in content to an S-M OOA spec of today. Best to all, -- steve Subject: (SMU) Message Information Model -Reply Mike Morrin writes to shlaer-mellor-users: -------------------------------------------------------------------- Andrew, I have seen Dave Whipp's response, and I mostly agree with it, but I think I have a slightly different perspective. >Andrew Nortje writes to shlaer-mellor-users: >The problem is essentially this - >I have a system that receives a number of messages. The messages > are all the same size ( have the same number of bytes), have a type > descriptor to destinguish messages, and obviously each carry > different data. The type descriptor gives an indication of what group of > data the message carries. My approach to this problem would be to split the problem into 2 domains, a service domain which deals with message transport and an application domain which deals with message contents. Note that neither of these is an architecture domain. The transport domain has 1 message object which might have the attributes: TRANSPORT DOMAIN MESSAGE ___________________________ *message_ID -message_type -address -message_data The attribute "message_data" may need to be a special data type, as it must hold the contents of the rest of the message. Consider using a data type which has behaviour similar to that of a character string. The mission of this domain is to carry out the functions associate with delivery of generic messages, perhaps do CRC checking and that sort of thing. No object in this domain has any knowledge of the coding or meaning of the attribute "message_data". The application domain has a different object for each type of message. The decoding and tracking rules re embodied in the message objects here. Common behaviour could be abstracted into supertype objects. APPLICATION DOMAIN MESSAGE -TYPE1 ___________________________ *message_ID -destination_address -source_address -user_data_item1 -user_data_item2 APPLICATION DOMAIN MESSAGE -TYPE2 ___________________________ *message_ID -destination_address -source_address -user_data_item3 -user_data_item4 When the transport domain has done its stuff, it passes the message through a bridge to the application domain. A message object of the correct flavour gets created in the application domain. One of the key points is that the information which was in the attribute "message_data" in the transport domain get transformed as it goes through the bridge and probably turns into several other attributes which are meaningful in the application domain. To quote from "Object Lifecycles" section 7.3, "...the client and server domains may have different views of the same event: the event may have one set of event data when viewed from the client's perspective and a different label and set of event data when viewed from the server." In this case the difference in view is that the client domain knows what the "message_data" means, but the transport (server) domain does not. >I need to track certain (but not all) data in various of the messages. The > problem I have is how to describe the different messages with their > different data in the information model elegantly without having a > specification object for each message - which I am currently > considering. Currently I have say 20 specification objects, each which > have between 20 and 30 attributes to describe the data in each > message . This looks ugly and does'nt feel right. > I do not think that specification objects are very helpful in this sort of situation. I hope this clarifies rather than confuses matters for you. best regards, Mike | ____.__ | Mike Morrin (mike_morrin@tait.co.nz)| | //||| | Research Coordinator | | //_||| | Advanced Technology Group | | // ||| | Tait Electronics Ltd | Subject: Re: (SMU) Message Information Model -Reply David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: -------------------------------------------------------------------- Mike Morrin wrote: > I have seen Dave Whipp's response, and I mostly agree with it, but I think > I have a slightly different perspective. > > >I have a system that receives a number of messages. The messages > > are all the same size ( have the same number of bytes), have a type > > descriptor to destinguish messages, and obviously each carry > > different data. The type descriptor gives an indication of what group of > > data the message carries. > > My approach to this problem would be to split the problem into 2 domains, > a service domain which deals with message transport and an application > domain which deals with message contents. Note that neither of these > is an architecture domain. I agree with Mike's comments. Let me clarify where the architectural issues occur. We have a situation where the same data is used in two or more different domains. In many situations this is not a problem and it is acceptable to duplicate the information in memory several times. However, in some situations, especially in deeply embedded systems, this might not be desirable. You may want to ensure that the same physical memory is used for the data storage for each domain. This is an architectural issue. This leads to some serious communication questions. If one domain writes data then all the others will be effected. In the proposed Wormholes mechanism this would not be allowed. I would have to define synchronous services from each domain to access the shared data pool. But one of the domains would have to "own" the data - it would not use sync-services to access it (though may need to inform other domains that it has changed). It is not always clear who should own the data in such situations. Is it the application domain that provides the content or the messages domain that provides the routing? My opinion is that this is an implementation issue. An analysis of each domain must either assume that it is the owner (i.e. all use attributes that are shared) or all assume that someone else owns it (in which case an additional data-store domain is needed) Dave. -- David P. Whipp. Not speaking for: ------------------------------------------------------- G.E.C. Plessey Due to transcription and transmission errors, the views Semiconductors expressed here may not reflect even my own opinions! Subject: (SMU) Static State Information Allen Theobald writes to shlaer-mellor-users: -------------------------------------------------------------------- Hello S-M Gurus! I am working on a project where an Object will be reading bytes from a UART, find start of frame, accumulate bytes till end of frame, and then process the frame. I am having trouble with my state model. The reason? The object can be reading bytes as ASCII, or binary. The ASCII/Binary option is static information. That is, when the Object powers up, it will be in one of these two modes. The state model for each mode is different (different start of frame, and different end of frame). Is there any way to indicate "modeness" in a state model? Or do I just have two state models? Thanks, Allen Subject: Re: (SMU) Static State Information "Stephen R. Tockey" writes to shlaer-mellor-users: -------------------------------------------------------------------- > Allen Theobald writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > I am working on a project where an Object will be reading bytes > from a UART, find start of frame, accumulate bytes till end of > frame, and then process the frame. I am having trouble with my > state model. The reason? The object can be reading bytes as ASCII, > or binary. The ASCII/Binary option is static information. That is, > when the Object powers up, it will be in one of these two modes. > > The state model for each mode is different (different start of frame, > and different end of frame). Is there any way to indicate "modeness" > in a state model? Or do I just have two state models? Just a suggestion, but I'd start by sketching the state model of each situation separately, i.e., sketch the just-ascii-mode model and then sketch the just-binary-mode version. Then look for similarities and differences. I'd base the decision on how to model it on just how similar or different the are. If they are very different (little or nothing in common), I'd be tempted to model them as two different objects that happen to have the same interface. Initialization then becomes simply a question of which kind of object gets instantiated. If they are mostly the same (a state or two different), I'd be tempted to model them as "alternative paths" in the state model of one object with a preceeding decision of which "path" to take based on an attribute value. In this case, initialization into a mode is accomplished by setting the attribute value on instantiation. If they are somewhat the same and somewhat different (say, about 50% identical) then I'd look at putting the common stuff in a supertype object and specializing the differences in two separate subtypes. In this case, initialization into a mode is a question of which subtype gets instantiated. Some other questions you might want to ask about your system are: 1) Does frame-building (from UART input) and frame processing really belong in the same domain? i.e., Is the vocabulary of frame recognition the same as the vocabulary of the frame content? If the vocabularies are different then the task ought to be split across two separate domains (frame recognition/construction separate from frame content processing). 2) Is a state model really the most appropriate way of describing the problem (and/or its solution)? Consider the possibility that the frame building algorithm could be expressed entirely within the action of a single state. I don't know the answer in your case, or even if you asked the question. My point is simply to consider whether other, possibly more appropriate, alternatives for representing your situation exist. 3) You might consider asking whether or not the object(s) ought to be allowed to "change mode" (ascii<->binary) on the fly. You might end up with a more powerful/general case solution if you allow mode changing at run-time rather than requiring re-initialization. I certainly don't know enough about your situation to say one way or another, but sometimes just asking the question helps result in a better product. Hope this helps, -- steve Subject: Re: (SMU) Static State Information Ken Cook writes to shlaer-mellor-users: -------------------------------------------------------------------- Allen Theobald wrote: > > I am working on a project where an Object will be reading bytes > from a UART, find start of frame, accumulate bytes till end of > frame, and then process the frame. I am having trouble with my > state model. The reason? The object can be reading bytes as ASCII, > or binary. The ASCII/Binary option is static information. That is, > when the Object powers up, it will be in one of these two modes. > > The state model for each mode is different (different start of frame, > and different end of frame). Is there any way to indicate "modeness" > in a state model? Or do I just have two state models? > Since all instances of an object must share the same behavior (and participate in the same relationships, and have the same attributes) it sounds like you have two objects. Therefore two state models. The relationship between these two objects, lets call them ObjectAscii and ObjectBinary, will depend on your application. They might be two subtypes of the same supertype, or they might be related in some other way. If the objects are two subtypes of a supertype, then you may want to take advantage of polymorphic events - events can come into a supertype object, and be "routed" to the appropriate subtype. -Ken Subject: (SMU) Messge Information Model Andrew Nortje writes to shlaer-mellor-users: -------------------------------------------------------------------- To everyone who responded to my resquest for help on the message information model - thanks very much. Just some feed back on how I have proceeded. Regarding domains - We do have two domains 1. A message communication/transport domain which we already have and which was written in the bad old days before OOA. 2. A message handling/decoding domain which is the one I have been wrestling with. >Mike Morrin Wrote. >The application domain has a different object for each type of message. >The decoding and tracking rules re embodied in the message objects >here. Common behaviour could be abstracted into supertype objects. > > APPLICATION DOMAIN MESSAGE -TYPE1 > ___________________________ > *message_ID> > -destination_address > -source_address > -user_data_item1 > -user_data_item2 > > > APPLICATION DOMAIN MESSAGE -TYPE2 > ___________________________ > *message_ID > -destination_address > -source_address > -user_data_item3 > -user_data_item4 >When the transport domain has done its stuff, it passes the message >through a bridge to the application domain. A message object of the >correct flavour gets created in the application domain. Mike what you suggested is what I had initailly, but the problem here is that if you have too many different types of messages the Information Model explodes becomes messy. Dave Wanner had a good suggestion which I have based my IM on and which allows for one messageSpecifation object with a 1:M relationship to a messageField object. So for every different message one can create an instance of messageSpecification with instances of messageField. Dave thanks for your help, I think I now have an IM I am more comfortable with. To Bob Dodd - Bob I would stilll appreciate the model fragment which you think will help solve my problem, in postcript format please. Thanks Andrew Nortje Subject: Re: (SMU) Static State Information Allen Theobald writes to shlaer-mellor-users: -------------------------------------------------------------------- Stephen R. Tockey wrote: > [SNIP!] > > Just a suggestion, but I'd start by sketching the state model of > each situation separately, i.e., sketch the just-ascii-mode model > and then sketch the just-binary-mode version. Then look for similarities > and differences. I'd base the decision on how to model it on just > how similar or different the are. Done! Thus my confusion. Once done, I saw some similarities...and differences. > If they are very different (little or nothing in common), I'd be > tempted to model them as two different objects that happen to have > the same interface. Initialization then becomes simply a question of > which kind of object gets instantiated. > > If they are mostly the same (a state or two different), I'd be > tempted to model them as "alternative paths" in the state model of > one object with a preceeding decision of which "path" to take based > on an attribute value. In this case, initialization into a mode > is accomplished by setting the attribute value on instantiation. > > If they are somewhat the same and somewhat different (say, about 50% > identical) then I'd look at putting the common stuff in a supertype > object and specializing the differences in two separate subtypes. > In this case, initialization into a mode is a question of which > subtype gets instantiated. In ASCII mode there is a very distinct start of frame (SOF), and a very distinct end of frame (EOF). If the characters arrive more than a second apart (some timer object fires), then the frame is trashed and I start over. In binary mode the SOF is an amount of elapsed time (say 3 secs) between bytes received. Three seconds between bytes indicates a SOF (and incidentally an EOF). If all the bytes have not been collected, the frame is trashed, etc. So, other than framing and timing (and whether ASCII/BINARY), the collection of bytes _AND_ the processing is pretty much the same. > Some other questions you might want to ask about your system are: > > 1) Does frame-building (from UART input) and frame processing really > belong in the same domain? i.e., Is the vocabulary of frame recognition > the same as the vocabulary of the frame content? If the vocabularies are > different then the task ought to be split across two separate domains > (frame recognition/construction separate from frame content processing). Good question! But i'm confused as to whether they are in different domains or just different objects of the same domain (i.e., Upstream Processing). "Upstream Processing" reads bytes from the UART, translates into internal payload, then gives it the RF transceiver, which in turn transmits it over a radio. Any comments? > 2) Is a state model really the most appropriate way of describing the > problem (and/or its solution)? Consider the possibility that the > frame building algorithm could be expressed entirely within the action > of a single state. I don't know the answer in your case, or even if > you asked the question. My point is simply to consider whether other, > possibly more appropriate, alternatives for representing your situation > exist. Interesting, I thought the state model would look something like this (for ASCII and Binary), with the timing left off. If the timer fires in any state (other than Idle), it moves back to "Searching for Frame": ---- |Idle|<-----EventInitializeFromStartup ---- | | Ascii Mode (in this case) V ------------------- +--->|Searching For Frame|<-----EventCharAvailableFromUART | ------------------- | | | | SOF received | V | ------------ | |Reading Data|<-----EventCharAvailableFromUART | ------------ | | | | EOF received | V | ------------- | |Process Frame| | ------------- | | | | | ------+ > 3) You might consider asking whether or not the object(s) ought to > be allowed to "change mode" (ascii<->binary) on the fly. You might > end up with a more powerful/general case solution if you allow mode > changing at run-time rather than requiring re-initialization. I > certainly don't know enough about your situation to say one way or > another, but sometimes just asking the question helps result in a > better product. Yes, but for various reasons this idea has been axed. > Hope this helps, Yes! This has been very helpful. Thanks, Allen Subject: Re: (SMU) Static State Information David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: -------------------------------------------------------------------- Allen Theobald writes to shlaer-mellor-users: >[...] > In ASCII mode there is a very distinct start of frame (SOF), and a very > distinct end of frame (EOF). If the characters arrive more than a > second apart (some timer object fires), then the frame is trashed and I > start over. > > In binary mode the SOF is an amount of elapsed time (say 3 secs) between > bytes received. Three seconds between bytes indicates a SOF (and > incidentally > an EOF). If all the bytes have not been collected, the frame is > trashed, etc. > > So, other than framing and timing (and whether ASCII/BINARY), the > collection > of bytes _AND_ the processing is pretty much the same. >[...] > Interesting, I thought the state model would look something like > this (for ASCII and Binary), with the timing left off. If the timer > fires in any state (other than Idle), it moves back to "Searching for > Frame": > > [diagram cut] Your state model seems reasonable, though incomplete - it doesn't allow for a frame to be trashed. You just need a way of determining the start and end of the frame. This is almost certainly a different object. If you consider the definition of an object then you will see that an object can represent events and interactions as well as tangible things. So I would consider having an object "ASCII_FRAME" to which you send an event when you enter your "Searching For Frame" state. It is then responsible for sending the "SOF received" event to the DATA_FRAME object (similarly, it would send the EOF event). One problem with this is that the character-available event would need to go to two objects. This can't happen (though a bridge could send 2 events). However, looking at your state diagram, I see that the event is improperly used - it does not cause a state transition. I would question whether it even needs to go to the frame object. Presumably, the data-frame is represented as an ordered set of instances (there is a next/prev relationship betweeen the instances). Building this frame, and timing the delay between characters, can be independent acts. You could have a predicate (boolean attribute) on the Frame object that is set when it is in the "Reading Data" state. The frame boundary object would always want to know when a character is available, but it doesn't do anything with it - it just notes its existence and resets timers, generates SOF, EOF events, etc. The data's availability also needs to go to something that builds frames if the reading_data predicate is set (this could be the creation event of a "Character" object). The state machine that you showed should not care when characters are recieved. It is only concerned with frames. Let another object deal with the characters. Its difficult to discuss these things without a whiteboard, but hopefully my ramblings will be helpful. Dave. -- David P. Whipp. Not speaking for: ------------------------------------------------------- G.E.C. Plessey Due to transcription and transmission errors, the views Semiconductors expressed here may not reflect even my own opinions! Subject: (SMU) Implementation in OOA; case 1 LAHMAN@DARWIN.dnet.teradyne.com writes to shlaer-mellor-users: -------------------------------------------------------------------- He's baaaaack! Recently we came across two situations where implementation issues appear to have an affect on the OOA. Both are related to performance. This note represents one of those cases; the second is in a second missive for convenience. The first situation has to do with navigation of relationships. The prototypical situation is: objA <---------------->> objB ^ R1 ^ | | | | | R2 | R3 V V V R4 V C objC <-----------------> objD In the ADFD (or ASL) one has a choice about how to navigate from objA to objD through all the 1:M relationships. Let us assume that it is known that if one navigates R1 one always gets several thousand instances of objB for each objA but due to the nature of the conditionality one reaches only 2 instances of objD along R3 from that set of objB. Let us further assume that navigating R2 will always yield exactly 2 objC instances and each of these yields one objD instance. Thus either path yields exactly 2 objD instances from a given objA instance. If the OOA is independent of the implementation, then one should be indifferent to the choice of path in the ADFD. However, there is likely to be a very large performance hit if one traverses R1->R3 in the ADFD relative to traversing R2->R4 and translates on that basis. Now one could argue that since referential integrity demands that one be indifferent to which data model path is taken, the translation is free to override the ADFD and select the other path. Theoretically I suppose one could have a really smart optimizing translator that would recognize the equivalence of the choice from the graph and select the correct one. To do this it would have to know what the actual cardinalities of the relationships were and this is not provided in the OOA, though it could be provided to the translator as part of colorization. I am uncomfortable about this because the translation is not doing what the ADFD said. That is, if the OOA specifies a complete, abstract solution to the problem, then the algorithm (i.e., flow of control and data access) is specified in the ADFD (among other model components). Yet the translation selects another algorithm (i.e., it moves through different processes and accesses different data stores). It seems to me the translation should only be free to select mechanisms for OOA constructs, not substitute other OOA constructs. Any comments? H. S. Lahman "There's nothing wrong with me that Teradyne/ATB wouldn't be cured by a capful of Draino." 321 Harrison Av L51 Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) Implementation in OOA; case 2 LAHMAN@DARWIN.dnet.teradyne.com writes to shlaer-mellor-users: -------------------------------------------------------------------- This is the second of two situations we have recently encountered where implementation issues necessarily intrude into the OOA. (The other case is in another missive.) In a digital tester one executes test vectors against a set of tester pins. Each test vector represents a slice in time and it contains the state of each pin in that time slice. In the worst case there could be 10**3 tester pins and 10**6 test vectors for a single test. One way to think of this is a matrix with one axis being time (vectors) and the other being pins where each cell is a particular pin state. In addition things like pins, vectors, and pin states have some interesting properties that seem to be worth modeling. For example, vectors have timing information associated with them, as well as hardware control attributes that define the bounds of loops, synching with external signals, etc. Also, it is very inefficient to load a truth table format for pin states; one wants to load a particular pin's pin state only if it changed from the last vector. Thus there is processing associated with a particular Pin State. This makes it quite natural to model the Pin, Vector, and Pin State as objects. The problem is that there could be on the order of 10**6 Vector instances and 10**9 Pin State instances. It would be a performance disaster to actually implement using separate instances for these entities. Now there are basically two ways to deal with this problem. You can abstract out the pin/vector matrix in some fashion into a non-OOA domain and let that domain worry about all the details of processing the data. Unfortunately there is a lot of processing that would disappear from the OOA if one does this. One could argue that one would be extracting the heart of a tester's logic in doing this, which leads one to wonder why one is bothering with an OOA to begin with if most of the code is going to be traditional procedural processing. But my main problem with this approach is that you do the model the natural way with the individual objects and then change it by abstracting the Vector and Pin State objects for performance reasons. The other approach is to leave the models the way they are and let the translation do the abstraction. This is feasible and might not even be very complicated if all the objects are passive. However, if one or two are active it starts to get a tad bizarre. So it gets real tempting to shift the functionality around to make all the relevant objects passive -- again for performance reasons. [I am prepared to argue that you probably never want objects with high instance counts to be active for performance reasons, but that is a separate issue.] Even if one doesn't change anything the translation is going to produce something that will be hardly recognizable in the context of the original models. The translation process itself will be complicated and possibly error prone while all the model-based debugging paradigms go out the window. While I believe such translation is feasible, I question whether one really wants to do it that way. Given that one always has to do at least some debugging with the translated code in practice, I suspect that it would be better to use the first option just so that one has more control over the implementated code (rather than also having to deal with the quirks of the translator). Any comments? H. S. Lahman "There's nothing wrong with me that Teradyne/ATB wouldn't be cured by a capful of Draino." 321 Harrison Av L51 Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Implementation in OOA; case 2 fontana@world.std.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 05:47 PM 1/16/97 -0500, shlaer-mellor-users@projtech.com wrote: >LAHMAN@DARWIN.dnet.teradyne.com writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >Now there are basically two ways to deal with this problem. You can >abstract out the pin/vector matrix in some fashion into a non-OOA domain >The other approach is to leave the models the way they are and let the >translation do the abstraction. Of course there are (at least) two answers - what I might like "like" and what's "possible". If you've got reasonably flexible translation support, and have the ability to readily construct alternate object storage mechanisms (as opposed to structs or classes) - such as putting associative object instances that formalize a M:M in a matrix - then I'd select that approach. The debugging issue is a real factor, but I don't believe it is much different from a high-level than tucking it away in a realized service domain. Losing the detail of these abstractions from their proper domain and using the realized service domain may be the only choice you have if you're struggling with translation or architectural flexibility. I consider this a less than optimal choice, but still much better than a system that can't get within 3 orders of magnitude of it performance requirements. In either case, it is essential that the debugging issue be properly respected and dealt with head on - perhaps with a little extra time dedicated to developing scaffolding or instrumentation that may help in this area. _________________________________________________ Peter Fontana Pathfinder Solutions Inc. | | effective solutions for OOA/RD challenges | | fontana@world.std.com voice/fax: 508-384-1392 | _________________________________________________| Subject: (SMU) New Job Listings jrwolfe@projtech.com (John R. Wolfe) writes to shlaer-mellor-users: -------------------------------------------------------------------- On our web page (http://www.projtech.com), there are some new job listings for positions available within PT's development group. Subject: Re: (SMU) Implementation in OOA; case 1 Ken Cook writes to shlaer-mellor-users: -------------------------------------------------------------------- LAHMAN@DARWIN.dnet.teradyne.com wrote: > The first situation has to do with navigation of relationships. The > prototypical situation is: > > objA <---------------->> objB > ^ R1 ^ > | | > | | > | R2 | R3 > V V > V R4 V C > objC <-----------------> objD > > In the ADFD (or ASL) one has a choice about how to navigate from objA to > objD through all the 1:M relationships. It's probably worth mentioning that when using BridgePoint Action Language, one avoids this problem. In the action language, I am asked to specify which path to traverse. SELECT MANY myset RELATED BY objA->R1[objB]->R3[objD]; or SELECT MANY myset RELATED BY objA->R2[objC]->R4[objD]; I know this doesn't help you, but I wonder if this means that there is more "design" in Action Language than in ADFD's? You might optimize a translator by coloring your ADFD with chaining statements like those above. I don't know much about ADFD translators - how is it that the translator can make an arbitrary choice of the two paths? Won't you be specifying the path somehow in your ADFD? Would the slow and fast path change during runtime, so that you would not know at code generation time? -Ken Subject: Re: (SMU) Implementation in OOA; case 1 Tony Humphrey-Lewis writes to shlaer-mellor-users: -------------------------------------------------------------------- On Thu, 16 Jan 1997 LAHMAN@DARWIN.dnet.teradyne.com wrote: > > Recently we came across two situations where implementation issues appear to > have an affect on the OOA. Both are related to performance. This note > represents one of those cases; the second is in a second missive for > convenience. > > The first situation has to do with navigation of relationships. The > prototypical situation is: > > objA <---------------->> objB > ^ R1 ^ > | | > | | > | R2 | R3 > V V > V R4 V C > objC <-----------------> objD > > In the ADFD (or ASL) one has a choice about how to navigate from objA to > objD through all the 1:M relationships. Let us assume that it is known that > if one navigates R1 one always gets several thousand instances of objB for > each objA but due to the nature of the conditionality one reaches only 2 > instances of objD along R3 from that set of objB. Let us further assume > that navigating R2 will always yield exactly 2 objC instances and each of > these yields one objD instance. > > Thus either path yields exactly 2 objD instances from a given objA instance. > If the OOA is independent of the implementation, then one should be > indifferent to the choice of path in the ADFD. However, there is likely to > be a very large performance hit if one traverses R1->R3 in the ADFD relative > to traversing R2->R4 and translates on that basis. I'm don't believe the choice of path in the above has much to do with implementation but rather more with efficiency, and whilst I would agree that the OOA should be indifferent to implementation issues I do think that models should be efficient. If you know that going one way will have to iterate over many more instances than another (because that's the way it is) then the analyst needs to consider the efficiency of the model and hopefully choose the more efficient navigation path. So in your example I'd definitely go via R2->R4. > Now one could argue that since referential integrity demands that one be > indifferent to which data model path is taken, the translation is free to > override the ADFD and select the other path. Theoretically I suppose one > could have a really smart optimizing translator that would recognize the > equivalence of the choice from the graph and select the correct one. To > do this it would have to know what the actual cardinalities of the > relationships were and this is not provided in the OOA, though it could be > provided to the translator as part of colorization. > > I am uncomfortable about this because the translation is not doing what the > ADFD said. That is, if the OOA specifies a complete, abstract solution to > the problem, then the algorithm (i.e., flow of control and data access) is > specified in the ADFD (among other model components). Yet the translation > selects another algorithm (i.e., it moves through different processes and > accesses different data stores). It seems to me the translation should only > be free to select mechanisms for OOA constructs, not substitute other OOA > constructs. I don't think the translation should change what was defined by the ADFD. By all means optimise the OOA contructs used, but change it for another one, that sounds like an optimising compiler that says "he's used a bubble sort and a quick sort would be better so I'll change it" no thanks. +----------------------------------------------------+ | Anthony Humphrey-Lewis Software Development | | GPT Ltd. | | email: hlewisa@ncp.gpt.co.uk Business Systems | | Technology Drive | | Beeston | | Notts. NG9 1LA | | United Kingdom | | Telephone: +44 115 943 4290 Fax: +44 115 943 3805 | +----------------------------------------------------+ Subject: Re: (SMU) Implementation in OOA; case 1 fontana@world.std.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- >I know this doesn't help you, but I wonder if this means that there >is more "design" in Action Language than in ADFD's? My recent experience with 3 different "popular" action languages, I would have to say for many things (such as formalizing a relationship and iterating over a set of instances) the action language takes the analyst closer to the implementation that ADFDs do - closer than I like to see. For many aspects of process modeling the action language is semantically equivalent. I say this from the perspective of our company, where we've got years of experience with automatic code generation from ADFDs in developing our own tools and with our major clients. We also have some other clients who use various state action languages from popular CASE tools. > >You might optimize a translator by coloring your ADFD with chaining >statements like those above. Only to the extent that the coloring doesn't specify something DIFFERENT from the actual topology of the ADFD itself. > >I don't know much about ADFD translators - how is it that the translator >can make an arbitrary choice of the two paths? No - (as far as I know) there is no difference between ADFDs and action language on this issue. Once the analyst specifies a path, a DIFFERENT path through analysis-level information is not possible. >Won't you be specifying >the path somehow in your ADFD? Yes - you specify a CONCEPTUAL path by flowing formalizing attribute values into a find bubble. However, it may be possible/desirable for the underlying implementation to capture and maintain relationship information in a form that does not necessarily mirror the IM. For instance, the designer could recognize a composed relationship and implement it differently. The ability of the Recursive Design architect to map the OOA to an architecture that is not tightly constrained by the apparent mechanical form of OOA is a significant feature of Shlaer-Mellor OOA/RD. > Would the slow and fast path change >during runtime, so that you would not know at code generation time? Now you're stretching my ability to validate in the abstract, but it is possible to make a run-time optimization decision. Say we want to get from an instance of A through R1 to an instance of B. Now say that for the most part, our hypothetical architecture is fundamentally a direct mapping of OOA into implementation, so relationships are implemented as linked lists of instances, and finds across a relationship are a sequential searches of these lists. Now let's say we do performance testing and discover for the most part this approach meets our performance requirements, but in the A->R1->B case, sometimes we find over if we have over 10,000 B's, this blows away response time for a particular find accessor of B. Now we can OPTIMIZE: color R1 to use the linked list AND a hash table. Let's say that if we've got <10,000 instances, we don't want to waste the space of the extra data structures. But once we create the 10,000th B, we can take a few milliseconds and create a hash table to mirror the linked list. From then on, all writes of the attributes that formalize R1 not only affect R1's linked list, but also populate the hash table. Here is what the find might look like: // If there are few B's, go through the linked list, else use the hash if (number of instances of B visible across R1 < 10,000) linked_list_access B across R1 from A else hash_access B across R1 from A Of course detailed performance requirements from our Application System-Level Requirements Document help us know exactly when we need to get involved in such gyrations. __________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com| | effective solutions for OOA/RD challenges | | Peter Fontana voice: 888-OOA-PATH | fontana@world.std.com fax: 508-384-1392 | __________________________________________________| Subject: (SMU) 3 Qs about S-M methodology Allen Theobald writes to shlaer-mellor-users: -------------------------------------------------------------------- Greetings S-M Users, I am new to the S-M methodology, and have three questions: 1. What is Coloring? 2. How does "Action associated with states, not with the transitions" affect code generation? I believe what I've been most exposed to is "actions associated with transitions". While generating code action "actions associated with states" seems unnecessarily complex, whereas "actions associated with transition seems easier. Comments? 3. Here is part of a state model, courtesy of myself and Stephen R. Tockey. "Waiting..." is the initial state of the model. Char available is an external event generated by the UART when a character is available for reading. How do I turn this fragment into code, based on the example on page 190 of "Object Lifecycles: Modeling the World in States"? I have no code generator, but plenty of ideas. --------------- | Waiting for | +--| start of frame|<---+ | --------------- | | | Char Avail Not Start From UART of Frame | | | ----------------- | +->| Candidate start |--+ +--| of frame arrived| | ----------------- | [1] ch = Get Char from UART | [2] if ch .EQ. Start of Frame | generate "Got Start of Frame" | else | generate "Not Start of Frame" | Got Start of Frame | | V Any light/help you can shed on this is warmly appreciated. Thanks, Allen Subject: (SMU) Date: Fri, 17 Jan 1997 07:51:00 -0600 "Lynch, Chris D. SD" writes to shlaer-mellor-users: -------------------------------------------------------------------- H.S. Lahman wrote: >Recently we came across two situations where implementation issues appear to >have an affect on the OOA. Both are related to performance. This note >represents one of those cases; the second is in a second missive for >convenience. > >The first situation has to do with navigation of relationships. The >prototypical situation is: > >objA <---------------->> objB > ^ R1 ^ > | | > | | > | R2 | R3 > V V > V R4 V C >objC <-----------------> objD > >In the ADFD (or ASL) one has a choice about how to navigate from objA to >objD through all the 1:M relationships. Let us assume that it is known that >if one navigates R1 one always gets several thousand instances of objB for >each objA but due to the nature of the conditionality one reaches only 2 >instances of objD along R3 from that set of objB. Let us further assume >that navigating R2 will always yield exactly 2 objC instances and each of >these yields one objD instance. > >Thus either path yields exactly 2 objD instances from a given objA instance. >If the OOA is independent of the implementation, then one should be >indifferent to the choice of path in the ADFD. However, there is likely to >be a very large performance hit if one traverses R1->R3 in the ADFD relative >to traversing R2->R4 and translates on that basis. > >Now one could argue that since referential integrity demands that one be >indifferent to which data model path is taken, the translation is free to >override the ADFD and select the other path. Theoretically I suppose one >could have a really smart optimizing translator that would recognize the >equivalence of the choice from the graph and select the correct one. To >do this it would have to know what the actual cardinalities of the >relationships were and this is not provided in the OOA, though it could be >provided to the translator as part of colorization. >I am uncomfortable about this because the translation is not doing what the >ADFD said. That is, if the OOA specifies a complete, abstract solution to >the problem, then the algorithm (i.e., flow of control and data access) is >specified in the ADFD (among other model components). Yet the translation >selects another algorithm (i.e., it moves through different processes and >accesses different data stores). It seems to me the translation should only >be free to select mechanisms for OOA constructs, not substitute other OOA >constructs. >Any comments? After being amazed by this translation trick and satisfying myself that it always Did The Right Thing I might eventually get over my suspicions and come to like it. But I don't think it's a violation of any Shlaer/Mellor rule (written or not). I think it should be acceptable, if the shortcut comes up with the same instances of objD that your ADFD did via the objB population. I view it as not "substituting other OOA constructs" but reading your intent and accomplishing that intent more efficiently. You asked for instances of objD and you got the ones you wanted, albeit via a different route. (I am assuming that in your example the translator produced a functionally equivalent solution to a "direct" translation.) This is analogous to some of the very aggressive optimizations now performed by compilers and linkers. There are several such optimizations do not implement anything resembling the source code, but they DO work. I guess the question is how much magic can you tolerate? Subject: Re: (SMU) 3 Qs about S-M methodology Allen Theobald writes to shlaer-mellor-users: -------------------------------------------------------------------- A followup to my own question: > > 3. Here is part of a state model, courtesy of myself and Stephen > R. Tockey. "Waiting..." is the initial state of the model. > Char available is an external event generated by the UART when a > character is available for reading. How do I turn this fragment > into code, based on the example on page 190 of "Object > Lifecycles: Modeling the World in States"? I have no code > generator, but plenty of ideas. > > --------------- > | Waiting for | > +--| start of frame|<---+ > | --------------- | > | | > Char Avail Not Start > From UART of Frame > | | > | ----------------- | > +->| Candidate start |--+ > +--| of frame arrived| > | ----------------- > | [1] ch = Get Char from UART > | [2] if ch .EQ. Start of Frame > | generate "Got Start of Frame" > | else > | generate "Not Start of Frame" > | > Got Start of > Frame > | > | > V > Just as a followup, this is the code I came up with: typedef enum { _EvCharAvailableFromUART, _EvTimerExpired, } ExternalEventGroup_t; typedef enum { _EvGotSOF, _EvNotSOF, } PrivateEvents_t; typedef enum { _waitingForStartOfFrame, _candidateStartOfFrameByteArrived, } FramingStates_t; static unsigned int gFrameState = _waitingForStartOfFrame; FramingStates_t DoEvent(int Event) { switch ( gFrameState ) { case _waitingForStartOfFrame: switch ( Event ) { case _EvCharAvailableFromUART: gFrameState = _candidateStartOfFrameByteArrived; } break; case _candidateStartOfFrameByteArrived: switch ( Event ) { case _EvGotSOF: /* gFrameState = whatever */ break; case _EvNotSOF: gFrameState = _waitingForStartOfFrame; } break; return gFrameState; } void TakeEvent_GotSOF() { gFrameState = DoEvent(_EvGotSOF); /* assume not further processing, just changes state */ } void TakeEvent_NotSOF() { gFrameState = DoEvent(_EvNotSOF); /* assume not further processing, just changes state */ } void TakeEvent_CharFromUART() { extern Queue_t gRcvFrameBufferChannel1; int incomingData; static unsigned int gByteCount = 0; static int *gStreamPtr; static int *gStream; /* Get a buffer to store incoming data in */ if ((gStreamPtr = gStream = (int*)malloc(17)) == NULL) { /* We got a serious problem now */ } gFrameState = DoEvent(_EvCharAvailableFromUART); switch ( gFrameState ) { case _candidateStartOfFrameByteArrived: /* Reset timer */ gNumBytesReceived++; if ( GetQueueItem( &gRcvFrameBufferChannel1, (void**)&incomingData ) != _queueEmpty ) { if ( (incomingData & 0xff) == 0 /* SOF */) { /* Save the information */ *(gStream+gByteCount) = incomingData & 0xff; gByteCount++; TakeEvent_GotSOF(); } else { TakeEvent_NotSOF(); } } break; default: break; } } void TaskProcessInput() { ExternalEventGroup_t ExternalEvent; for (EVER) { ExternalEvent = GetMessage(); switch ( ExternalEvent ) { case _EvCharAvailableFromUART: TakeEvent_CharFromUART(); break; } FireTimer(); } } But what happens (how does my state model change) if _EvByteAvailableFromUART signifies more than 1 byte available? That is, the UART is a FIFO, and can hold more than one char. If bursty traffic comes in, then 1 _EvByteAvailableFromUART may mean more than one byte there. Then if ( GetQueueItem( &gRcvFrameBufferChannel1, (void**)&incomingData ) != _queueEmpty ) { ... } becomes while ( GetQueueItem( &gRcvFrameBufferChannel1, (void**)&incomingData ) != _queueEmpty ) { ... } But, how does my state model change to reflect this? Oh, also, what kind of processing goes into FireTimer()? Struggling in Cincinnati! Allen Subject: Re: (SMU) Implementation in OOA; case 1 Andy McKinley writes to shlaer-mellor-users: -------------------------------------------------------------------- Tony Humphrey-Lewis wrote: > > On Thu, 16 Jan 1997 LAHMAN@DARWIN.dnet.teradyne.com wrote: > > > > > Recently we came across two situations where implementation issues appear to > > have an affect on the OOA. Both are related to performance. > > > > objA <---------------->> objB > > ^ R1 ^ > > | | > > | | > > | R2 | R3 > > V V > > V R4 V C > > objC <-----------------> objD > > > > In the ADFD (or ASL) one has a choice about how to navigate from objA to > > objD through all the 1:M relationships. Let us assume that it is known that > > if one navigates R1 one always gets several thousand instances of objB for > > each objA but due to the nature of the conditionality one reaches only 2 > > instances of objD along R3 from that set of objB. Let us further assume > > that navigating R2 will always yield exactly 2 objC instances and each of > > these yields one objD instance. > > > > Thus either path yields exactly 2 objD instances from a given objA instance. > > If the OOA is independent of the implementation, then one should be > > indifferent to the choice of path in the ADFD. However, there is likely to > > be a very large performance hit if one traverses R1->R3 in the ADFD relative > > to traversing R2->R4 and translates on that basis. > > So in your example I'd definitely go via R2->R4. What if the problem is stated more generically, and we say that over time the intermediate populations produced by R1->R3 and R2->R4 fluctuate; ie. there is a cycle of sorts which says that sometimes R1->R3/R2->R4 has the above characteristics, and some time later it has the opposite characteristics, and sometimes R1->R3 and R2->R4 have virtually the same characteristics... Andy McKinley Teradyne 179 Lincoln St. Boston, MA 01890 > > > > Now one could argue that since referential integrity demands that one be > > indifferent to which data model path is taken, the translation is free to > > override the ADFD and select the other path. Theoretically I suppose one > > could have a really smart optimizing translator that would recognize the > > equivalence of the choice from the graph and select the correct one. To > > do this it would have to know what the actual cardinalities of the > > relationships were and this is not provided in the OOA, though it could be > > provided to the translator as part of colorization. > > > > I am uncomfortable about this because the translation is not doing what the > > ADFD said. That is, if the OOA specifies a complete, abstract solution to > > the problem, then the algorithm (i.e., flow of control and data access) is > > specified in the ADFD (among other model components). Yet the translation > > selects another algorithm (i.e., it moves through different processes and > > accesses different data stores). It seems to me the translation should only > > be free to select mechanisms for OOA constructs, not substitute other OOA > > constructs. > > I don't think the translation should change what was defined by the ADFD. > By all means optimise the OOA contructs used, but change it for another > one, that sounds like an optimising compiler that says "he's used a bubble > sort and a quick sort would be better so I'll change it" no thanks. > > +----------------------------------------------------+ > | Anthony Humphrey-Lewis Software Development | > | GPT Ltd. | > | email: hlewisa@ncp.gpt.co.uk Business Systems | > | Technology Drive | > | Beeston | > | Notts. NG9 1LA | > | United Kingdom | > | Telephone: +44 115 943 4290 Fax: +44 115 943 3805 | > +----------------------------------------------------+ Subject: (SMU) Re: Implementation in OOA; case 1 LAHMAN@DARWIN.dnet.teradyne.com writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Lynch... >After being amazed by this translation trick and satisfying myself that >it always Did The Right Thing I might eventually get over my suspicions >and come to like it. But I don't think it's a violation of any >Shlaer/Mellor rule (written or not). > > > >This is analogous to some of the very aggressive optimizations now performed >by compilers and linkers. There are several such optimizations do not >implement anything resembling the source code, but they DO work. > >I guess the question is how much magic can you tolerate? I kind of agree, particularly with the analogy of compiler optimizations. I still think there is a technical issue when the translator accesses different data stores (which it has to do to navigate by a different path) than you specified in the solution. However, compilers routinely update values in registers rather than storing them to memory after every write. Translaters that smart just makes me uncomfortable. I guess my real problem is that is no translator currently available that is even close to being able to perform such optimization. This is a seriously complicated thing to do in an arbitrary graph! The reality is that you would have to go in and manually do something real cute in the translator to get it to use the other path. Given this, it seems much simpler and less risky to let the analyst simply choose the right path in the ADFD or ASL based upon the performance issues. In fact, this is exactly what we do; we have just archived a Practice Note that provides guidelines for selecting among alternative navigation paths to improve performance when writing ASL. H. S. Lahman "There's nothing wrong with me that Teradyne/ATB wouldn't be cured by a capful of Draino." 321 Harrison Av L51 Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) Re: cyclic multiple references Don White writes to shlaer-mellor-users: -------------------------------------------------------------------- >Subject: Re: (SMU) Implementation in OOA; case 1 >Andy McKinley writes to shlaer-mellor-users: >Tony Humphrey-Lewis wrote: >> On Thu, 16 Jan 1997 LAHMAN@DARWIN.dnet.teradyne.com wrote: >> > objA <---------------->> objB >> > ^ R1 ^ >> > | | >> > | | >> > | R2 | R3 >> > V V >> > V R4 V C >> > objC <-----------------> objD > >What if the problem is stated more generically, and we say that over time the >intermediate populations produced by R1->R3 and R2->R4 fluctuate; ie. there is a cycle >of sorts which says that sometimes R1->R3/R2->R4 has the above characteristics, and >some time later it has the opposite characteristics, and sometimes R1->R3 and R2->R4 >have virtually the same characteristics... Are you suggesting that the architecture should keep track of cardinalities and pick the path of least resistance or am I reading too much into your addition? PS. Hi Andy! Long time no see! -- donw - donw@atwc.teradyne.com Subject: (SMU) Re: New Job Listings jrwolfe@projtech.com (John R. Wolfe) writes to shlaer-mellor-users: -------------------------------------------------------------------- I must apologize for my misuse of this mailing list by posting the pointer to the new job listings on our web page. I was unaware that such use of the list is prohibited. Subject: Re: (SMU) Re: Implementation in OOA; case 1 fontana@world.std.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- >I guess my real problem is that is no translator currently available that is >even close to being able to perform such optimization. With archetype-based translation, given an archetype notation of reasonable flexibility, the archetype is not the limiting factor. The real hold back is the underlying mechanisms you have to work with. > This is a seriously >complicated thing to do in an arbitrary graph! Agreed - the arbitrary "completely self-optimizing" approach is probably too complex for the "real world". However, judicious clues left in the form of coloring by the analyst/designer could make this quite a solvable problem. (We could cover this in more detail offline if you'd like.) > The reality is that you >would have to go in and manually do something real cute in the translator to >get it to use the other path. Rather than "go in manually", use the coloring mentioned above. I think we could quickly conceive of a simple set of relationship properties and resulting implementation templates that could yield an automatically generated solution. I strongly resist any alternatives that require the manual diddling with any generated code. I maintain the "model compiler" mental model to manage and understand the OOA/RD code production/management/maintenance process. __________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com| | effective solutions for OOA/RD challenges | | Peter Fontana voice: 888-OOA-PATH | fontana@world.std.com fax: 508-384-1392 | __________________________________________________| Subject: (SMU) Re: Implementation in OOA; case 1 LAHMAN@DARWIN.dnet.teradyne.com writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Humphrey-Lewis >I'm don't believe the choice of path in the above has much to do with >implementation but rather more with efficiency, and whilst I would agree >that the OOA should be indifferent to implementation issues I do think >that models should be efficient. > >If you know that going one way will have to iterate over many more >instances than another (because that's the way it is) then the analyst >needs to consider the efficiency of the model and hopefully choose the >more efficient navigation path. So in your example I'd definitely go via >R2->R4. I certainly agree that it is an issue of efficiency. The issue becomes whether there is such a thing as OOA efficiency or should all performance issues should be relegated to the RD. To decide which path is more efficient one needs to know more about the cardinality of the relationships than the models describe. In my mind this implies another question: is it fair to use explicit cardinality information when constructing and OOA? My understanding is that it is not. Such information is at least potentially implementation dependent. For example, though unlikely, it is conceivable that if I build the application in two different environments, the cardinality might reverse between the two paths simply because the end users would use the system differently. The analogy of a general purpose memory manager comes to mind. One user might only need to manage fixed sized blocks while another always has variable sized blocks. A smart memory manager might use different algorithms and this might affect the cardinality. Regarding the translator overriding the ADFD: >I don't think the translation should change what was defined by the ADFD. >By all means optimise the OOA contructs used, but change it for another >one, that sounds like an optimising compiler that says "he's used a bubble >sort and a quick sort would be better so I'll change it" no thanks. If it is acceptable to use explicit cardinality to the OOA, then I would certainly agree with you. Especially if it was C's qsort. H. S. Lahman "There's nothing wrong with me that Teradyne/ATB wouldn't be cured by a capful of Draino." 321 Harrison Av L51 Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) Re: 3 Qs about S-M methodology II LAHMAN@DARWIN.dnet.teradyne.com writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Theobald... I did not have time to look closely at your code -- just enough misinterpret it -- but my impression is that you are mixing functionality that is more properly placed in the architecture with that of the object managing the frames. I gave a skeleton of how things might be translated in my response to your other message, so I won't repeat it here. >But what happens (how does my state model change) if >_EvByteAvailableFromUART signifies more than 1 byte available? That >is, the UART is a FIFO, and can hold more than one char. If bursty >traffic comes in, then 1 _EvByteAvailableFromUART may mean more than >one byte there. > > >But, how does my state model change to reflect this? I don't think it does. The frame itself should be processed by the state that Got-Start-of-Frame transitions to. If it needs the character that also indicated the start of frame, then that character would be passed in the Got-Start-of-Frame event's data packet. That next state should read the rest of the characters in the frame and process them until an end-of-frame is detected. [This might need to be spread over multiple states if the processing is complex.] [There is an issue about how the UART knows to send another Char-Avail-From-UART. There has to be some clearing mechanism so an event is issued only once when the UART queue goes from empty to having one or more entries. This would probably require multiple states to process the frame since the queue might become empty before the frame was complete and the state machine would have to wait for another Char-Avail-From-UART to finish the frame.] >Oh, also, what kind of processing goes into FireTimer()? I don't think you need polling at all. I would think that somebody (the bridge to the UART hardware?) places the Char-Avail-From-UART event onto the event queue. In due time this event is processed by an Event Manager in the architecture and is forwarded to the object with the state machine shown where processing proceeds per the state machine. [If the architecture is a Good Citizen it will release system resources by ensuring, through threading or some other mechanism, that the Event Manager goes to sleep if the queue is empty and wakes up when an event goes on the queue.] H. S. Lahman "There's nothing wrong with me that Teradyne/ATB wouldn't be cured by a capful of Draino." 321 Harrison Av L51 Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) Re: Implementation in OOA; case 1 LAHMAN@DARWIN.dnet.teradyne.com writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Cook... First, let me say I should have made it clear I was talking about *theoretical* translator capabilites when I referred to translator optimization. None on the market come close to this level of sophistication. >It's probably worth mentioning that when using BridgePoint Action >Language, one avoids this problem. In the action language, >I am asked to specify which path to traverse. > > SELECT MANY myset RELATED BY objA->R1[objB]->R3[objD]; > >or > > SELECT MANY myset RELATED BY objA->R2[objC]->R4[objD]; > > >I know this doesn't help you, but I wonder if this means that there >is more "design" in Action Language than in ADFD's? I don't think you avoid the problem -- you have to choose one path or the other when you decide which version of the SELECT MANY construct to use in the ASL. In the ADFD you do have to make the same choice. You use the objA ID to extract a set of objB IDs and then use those to extract a set of objDs. Or you use the objA ID to extract a set of objC IDs and then use those to extract a set of objDs. >You might optimize a translator by coloring your ADFD with chaining >statements like those above. Colorization is usually used to indicate what specific mechanism should be used for the OOA construct *in hand*. This is a little different in that you would have to colorize the ADFD equivalent of the SELECT MANY that you specified so that it would actually implement the ADFD equivalent of the *other* SELECT MANY form. >I don't know much about ADFD translators - how is it that the translator >can make an arbitrary choice of the two paths? Won't you be specifying >the path somehow in your ADFD? Would the slow and fast path change >during runtime, so that you would not know at code generation time? My point was not so much about ADFD translators as translators in general. In terms of Bridgepoint, if you specified the first SELECT MANY option, the translator would have to recognize that the *other* form of the SELECT MANY should actually be used. This would require extensive graph analysis on the part of the translator. H. S. Lahman "There's nothing wrong with me that Teradyne/ATB wouldn't be cured by a capful of Draino." 321 Harrison Av L51 Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) Re: 3 Qs about S-M methodology LAHMAN@DARWIN.dnet.teradyne.com writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Theobald >I am new to the S-M methodology, and have three questions: All that changes with experience is one's perception of one's capabilities. > 1. What is Coloring? This is essentially a means for overriding the translator's translation rules in specific cases. The basic idea is that you "color" a particular model construct, such as a relationship, so that the translator will implement it in a particular way. For example, you might color a 1:M relationship to force the translator to use a container of pointers that employed a balanced tree for searches. Alas, the specific techniques are a bit vague and are left as an exercise for the translator developers. In principle the mechanism should not show up explicitly in the OOA. Rather it should be an adjunct to it, such as an clear overlay that you lay over the model hardcopy and color with crayons -- hence the name. > 2. How does "Action associated with states, not with the > transitions" affect code generation? I believe what I've been > most exposed to is "actions associated with transitions". > > While generating code action "actions associated with states" > seems unnecessarily complex, whereas "actions associated with > transition seems easier. Comments? My *personal* view is that it really doesn't make a whole lot of difference in practice when communicating with events, but I probably don't properly understand all the theoretical nuances as far as code *generation* is concerned. In either case there is an atomic function that must be executed in a consistent manner. Whether this is done as an event is sent to a state or after the state receives the event does not make too much difference; the generated code will probably look very similar. Where I see the significance is in general consistency with message-based OO encapsulation. If you are going to use events to communicate, then having a state execute an action when it receives an event seems more natural to me for an encapsulated object. Associating the action with the transition is more consistent with dynamic polymorphism where the action replaces the event and the state is merely the end result. > 3. Here is part of a state model, ... > >Any light/help you can shed on this is warmly appreciated. When implementing this in code, the interesting stuff is for code not related to your model. That is, the real code here is the event manager, which is part of the architecture and the bridge to the UART hardware. Assuming a C++ implementation, the only non-architecture and non-bridge code to produce is the two state action routines. Waiting-for-start-of-frame is a NOP; the only thing set is the Current State attribute of the instance and this is supposed to be handled by the architecture. [Your architecture might even have some way of coloring NOP functions so they are not even called from the event manager; only Current State is set via an accessor.] The Candidate-start-of-frame-arrived (which should probably be named something like Checking-for-frame-start to be more descriptive) contains whatever code is needed to get a character and generate the appropriate event. Getting the character is probably a bridge function, so it would appear as a single function call. [Since it is known to be available, I am assuming the bridge is synchronous.] Then an IF to dispatch the event. The fun stuff is in the architecture. There are lots of ways to do this, so I will only sketch one; don't take it too seriously. The architecture will define a mechanism for keeping track of instances in a object -- often a static class method that manages a container for all instances. This stuff is probably inherited from some base Object that is sire to all objects in the architecture's scope. The class constructor and destructor will update the container. [There will usually be a static Find function for each class as well. The sophistication of the search and container algorithms can be colored for pesky performance issues.] The Event Manager manages a queue of events. When someone generates an event they actually invoke an Event Manager method to append the event onto the queue. When the Event Manager pops an event to be processed, it uses the event identifiers and the target class' Find to get an instance handle. [If you cared little about performance! In practice the architecture will be smarter and be passing around instance handles rather than identifiers.] The Event Manager then invokes the state action, which is a method of the target class, with the event data as parameters. The only other object-specific thing you would have to provide is a table to tell the Event Manager about the object's events and what action functions they cause to be invoked -- essentially the state transition table. In summary, to turn your state machine into code is pretty trivial. The real work is in the architecture that is reusable across all the objects. That work is effectively templates or inheritance for the classes and the Event Manager code. H. S. Lahman "There's nothing wrong with me that Teradyne/ATB wouldn't be cured by a capful of Draino." 321 Harrison Av L51 Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) Re: Implementation in OOA; case 1 LAHMAN@DARWIN.dnet.teradyne.com writes to shlaer-mellor-users: -------------------------------------------------------------------- From: FRED::A1GATE::IN%"shlaer-mellor-users@projtech.com" 17-JAN-1997 15:38:47.02 Subj: RE: (SMU) Re: Implementation in OOA; case 1 fontana@world.std.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- >I guess my real problem is that is no translator currently available that is >even close to being able to perform such optimization. With archetype-based translation, given an archetype notation of reasonable flexibility, the archetype is not the limiting factor. The real hold back is the underlying mechanisms you have to work with. > This is a seriously >complicated thing to do in an arbitrary graph! Agreed - the arbitrary "completely self-optimizing" approach is probably too complex for the "real world". However, judicious clues left in the form of coloring by the analyst/designer could make this quite a solvable problem. (We could cover this in more detail offline if you'd like.) > The reality is that you >would have to go in and manually do something real cute in the translator to >get it to use the other path. Rather than "go in manually", use the coloring mentioned above. I think we could quickly conceive of a simple set of relationship properties and resulting implementation templates that could yield an automatically generated solution. I strongly resist any alternatives that require the manual diddling with any generated code. I maintain the "model compiler" mental model to manage and understand the OOA/RD code production/management/maintenance process. __________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com| | effective solutions for OOA/RD challenges | | Peter Fontana voice: 888-OOA-PATH | fontana@world.std.com fax: 508-384-1392 | __________________________________________________| Subject: (SMU) MODEL HACKING Andrew Nortje writes to shlaer-mellor-users: -------------------------------------------------------------------- Hi Everyone We have recently bought "How to Build Shlaer Mellor Object Models" by Leon Starr. A point that came out of the book, which I believe we are doing, is MODEL HACKING. I think what we need to do to stop, or minimise model hacking, is a more formal pre IM stage - CRC's or something similar. Currently our pre IM stage is very adhoc and informal. I would be interested to know what Shlaer Mellor Model Builders out there doing to structure their pre IM stage. Thanks Andrew Nortje Subject: Re: (SMU) MODEL HACKING fontana@world.std.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 10:04 AM 1/20/97 +0200, shlaer-mellor-users@projtech.com wrote: >Andrew Nortje writes to shlaer-mellor-users: >-------------------------------------------------------------------- > ... I would be interested to know what Shlaer Mellor Model >Builders out there doing to structure their pre IM stage. This is a key area of the software development process - and it is one that you must extract (to some degree) from your pre-OOA process structure. Basically, you need a clear product statement or product definition (at a high level), and then you must define a set of System-Level Requirements. This docuement's goal is to define all requirements on the system visible from the outside, all performance requirements, and any true requirements in terms of packaging, extensability, etc. that are true "requirements" - not simply suggestions. Typically this document has reasonably complete paragraph descriptions of what's needed, even diagrams or screen shots if available - all interspersed with detailed requirement statements them selves. These "requirement statements" are: - detailed: to the point where you track them by number (avoid embedding section numbers in requirement numbers to enhance movability through the document). - atomic: they attempt to specify a single detailed aspect of the system - requirements: explaining *what* is required - not *how* to do it. - phrased properly with "shall": eg: "The system SHALL [1013] notify the operator with the dialog in figure 2.34 when the speed of the vehicle exceeds the speed of light..." Once the requirements are to the draft stage, your primary system scenarios are used to verify the detailed concepts defined in the System-Level Requirements are valid. As you proceed to IM for the application domain, each requirement statement that directly pertains to this domain is indicated as such via a Domain Requirements Matrix - referring simply to requirements numbers. Now your IM has something solid to model against. For domains with clients, the Domain Requirements Matrix also refers to its published bridge services. __________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com| | effective solutions for OOA/RD challenges | | Peter Fontana voice: 888-OOA-PATH | fontana@world.std.com fax: 508-384-1392 | __________________________________________________| Subject: (SMU) Re: Model Hacking LAHMAN@DARWIN.dnet.teradyne.com writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Nortje ... >I think what we need to do to stop, or minimise model hacking, is a more >formal pre IM stage - CRC's or something similar. Currently our pre IM stage >is very adhoc and informal. I would be interested to know what Shlaer Mellor >Model Builders out there doing to structure their pre IM stage. FWIW, our process looks something like this: (1) We start from a fairly detailed functional specification of the end user's view of the system (as a black box). This is a text document. At the other end we have the hardware bitsheets and whatever else the hardware people can provide. (2) We define the domain chart and rough bridge descriptions. (3) We do an object blitz. We have a reasonably formal process for this. (4) We build the IM. We have an advantage in that most of the stuff we are currently building we have done before; essentially we are simply replacing a '79-vintage system with an updated design. Thus we know the subject matter extremely well. I am not sure that there is a whole lot that preprocessing can do to prevent model hacking. The two things needed to avoid this are experience and a solid knowledge of the subject matter. Therefore the Motherhood answer would be that *anything* you do to understand the subject matter better is useful. I believe the key to avoid model hacking is to have a clear view of the abstractions that are appropriate for a domain. This is particularly true in a larger project. Coincidently we just had to address this issue with one of our domains so I have a nice example. We do digital testers. So one tends to have objects like Test, Pin, Vector (a time slice specifiying pin states in that time), and Pin State. One would think that a domain called Digital Test, which is supposed to manage an entire digital test, would care about these things. However, this would be an incorrect level of abstraction. The Digital Test domain manages the *overall* test. It really doesn't care about individual Pin States because these never affect a decision made in the domain. In fact, in our current abstraction, the domain doesn't even care about Vectors. The abstraction it needs to process is a Vector Block, which is an aggregate of Vectors and Pin States in a matrix (Pins X Vectors) of values. Since the Digital Test domain just moves these data without caring about their semantics, the Vector Block becomes the proper abstraction and it has attributes like Starting Vector, Vector Count, and Data Handle (a handle to the abstract matrix aggregate). Any processing of the Pin State data is done by a transform on the ADFD. [It also has a 1:M relation to Pin to identify the relevant Pins.] Other domains do care about things like Vectors and Pin States. These domains take the Data Handle from the Digitial Test bridge input and map the data properly for that domain. For example, our Digital Test Instrument, which abstracts that tester hardware at a high level, needs to know about Vectors, but it could care less about Tests or Pin States. In this domain a Vector is actually an active object. At a lower service level we have a Hardware Interface domain that cares about individual Pin States but has no real knowledge of the semantics of Vectors or Tests. You no doubt noticed a pattern of successively more detailed abstractions as I marched down the hierarchy of service domains. This is a fairly typical behavior. In a large system it is very important to decide what levels of abstraction are appropriate for each domain. If you think you are model hacking a domain, the first thing I would look for is a way to move detail out to a service domain while leaving a higher level abstraction behind. The key question to ask is: is any decision in this domain made based upon a value of any attribute of this object? If the answer is No, then the object probably doesn't belong there and you are being essentially procedural. If the answer is No to most of the attributes, then you might want to check whether there is a higher level abstraction that is more appropriate. Another useful clue to improper abstractions is the appearance of essentially the same object in two domains. If they are not clearly different views of the same entity (i.e., the abstractions are not inherently different), then one of the domains is improperly abstracted. Bottom line: a domain should have a unique subject matter *and* a unique level of abstraction. [Some people would equate unique abstraction to subject matter, but I happen to find the distinction useful.] H. S. Lahman "There's nothing wrong with me that Teradyne/ATB wouldn't be cured by a capful of Draino." 321 Harrison Av L51 Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) So when is the book on Recursive Design going to be done? Steve Maring writes to shlaer-mellor-users: -------------------------------------------------------------------- I'm anxious to get a more extensive treatment of Recursive Design. Does anyone know when we can expect this book to hit the shelves? -Steve Maring GTE Enterprise Solutions Application Development Subject: Re: (SMU) MODEL HACKING dave (Dave Wanner) writes to shlaer-mellor-users: -------------------------------------------------------------------- Andrew, Looks like you are getting some excellent advise from Mr. Fontana and from Mr. Lahman. I would like to throw in my two cents worth and try to clarify some of the ideas brought forth. Point #1: Preliminary Analysis Work Can Help Stop Or Slow Analysis Hacking Preliminary analysis work needs to be conducted to understand the scope and nature of the problem trying to be solved. If the preliminary work is not done then you can expect analysis hacking as one attempts to understand the scope and nature of the problem through analysis models. As Peter discussed there are two driving preliminary needs: 1. A document that describes a high-level system scope, 2. A set of requirements that describes what the system will do. Peter also discusses the need for developing requirements that are "atomic". While I support Peters thought process, the experience I have with most organizations is that they do not produce "atomic" requirements. In fact most organizations develop functional requirements that usually span several subject matters. Point #2: Prior To Analysis A Software Development Framework Needs To Be Defined This is the point where the requirements are looked at carefully for the subject matter contents and a domain chart is developed based on the discovered subject matter. Along with the domain chart graphic, mission statements and bridge descriptions are written. Also, at this point I totally agree with H.S. when he describes that clarity is based on experience and subject matter expertise. The mission statements develop the concept of what each domain will do, while, the bridge statements describe what the client domain will be utilizing in the way of services from the server domains. Also, as H.S. points out it is very important, once the domain chart deliverable is complete, to start to develop the concept of each domain from the view point of entities that belong there. I see that when a client spends time in a brain storming session (such as the object blitz) that their concepts of what entities belong to what domains are carefully crafted rather that crafted in an ad hoc manner. But, also be warned that everything is not clear when starting in to analysis modeling. Regardless of how much upfront work is done the process usually feels very uncomfortable (this is to be expected). As the process continues and a clearer understanding is gained by the analysis team model hacking should stop. By clearly understanding the abstraction from the point of view of the domain (as H.S.points out) this will help minimize the encroachment of model hacking in analysis. Point #3: There are good analysts and there are good subject matter experts, rarely are the two the same person. As both Peter and H.S. elude to, the most important factor during the analysis process is the gathering of information. This information comes from many sources (past projects, products that exist today, user interfaces, technical documentation, technical people, non technical people, etc. and so on). A good analyst understands how to get important information, understands how to assimilate it and understands how to learn from the information. But, the analysts also understands that the only validation point to a clear understanding of the subject matter is through the subject matter experts eyes. Thus, from a project point of view subject matter experts are required as team members. Through interaction and feedback from the subject matter expert model hacking can be minimized. Basically, what is happening, is the analyst is using the expert knowledge of the subject matter expert in continuing to understand what the requirements are for meeting the expectations of the end users of the system. Well, I'm getting wordy, so I'll be stopping now. Hope that this helps. Again good luck sorting out all the aspects of your project. Dave Wanner Project Technology Technical Staff Subject: Re: (SMU) Implementation in OOA; case 1 Tony Humphrey-Lewis writes to shlaer-mellor-users: -------------------------------------------------------------------- On Fri, 17 Jan 1997, Andy McKinley wrote: > Andy McKinley writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Tony Humphrey-Lewis wrote: > > > > On Thu, 16 Jan 1997 LAHMAN@DARWIN.dnet.teradyne.com wrote: > > < snip > > > > Thus either path yields exactly 2 objD instances from a given objA instance. > > > If the OOA is independent of the implementation, then one should be > > > indifferent to the choice of path in the ADFD. However, there is likely to > > > be a very large performance hit if one traverses R1->R3 in the ADFD relative > > > to traversing R2->R4 and translates on that basis. > > > > So in your example I'd definitely go via R2->R4. > > What if the problem is stated more generically, and we say that over time the > intermediate populations produced by R1->R3 and R2->R4 fluctuate; ie. there is a cycle > of sorts which says that sometimes R1->R3/R2->R4 has the above characteristics, and > some time later it has the opposite characteristics, and sometimes R1->R3 and R2->R4 > have virtually the same characteristics... I'd say that you've introduced a change in the rules the subject matter follows and as such would need to be analysed. It may well be that the analyst(s) need to specify that the alternatives are used and when. Unless you're suggesting that the architecture takes this on by monitoring relationship colloection sizes, which IMHO is not a good idea, as we're talking about real world relationship dynamics of the domain subject matter. +----------------------------------------------------+ | Anthony Humphrey-Lewis Software Development | | GPT Ltd. | | email: hlewisa@ncp.gpt.co.uk Business Systems | | Technology Drive | | Beeston | | Notts. NG9 1LA | | United Kingdom | | Telephone: +44 115 943 4290 Fax: +44 115 943 3805 | +----------------------------------------------------+ Subject: Re: (SMU) 3 Qs about S-M methodology "Stephen R. Tockey" writes to shlaer-mellor-users: -------------------------------------------------------------------- > Allen Theobald writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > I am new to the S-M methodology, and have three questions: > > 1. What is Coloring? It means annotating the pre-translated model in some way to indicate to the translator that an alternative translation is desired. In other words, the translator will assume a default translation for every construct unless an alternative translation is indicated through coloring. In programming language terms, coloring is like having compiler directives (such as "inline" and "escape to assembly language") to help get more desireable output from the translator(s). > 2. How does "Action associated with states, not with the > transitions" affect code generation? I believe what I've been > most exposed to is "actions associated with transitions". > > While generating code action "actions associated with states" > seems unnecessarily complex, whereas "actions associated with > transition seems easier. Comments? According to Finite Automata Theory (the basis of state machines), there is *no difference* between actions on states ("Moore machines") and actions on transitions ("Mealy machines"). In fact, the first homework assignment in my first finite automata theory class was to write the algorithms for converting between the two. Neither is inherently more difficult to translate from than the other (IMHO). It's just a matter of what you are already used to. The worst-case that you would have to deal with would be to take one form and convert it to the other form then do code generation from that. I'm going to put words into Steve & Sally's mouths here, but here's my conclusion. S-M OOA's interpretation of Moore machines (actions on states) is that the action is executed once, on entry into that state. Note: this is easilly mimicked in actions-on-transitions form by simply requiring all transitions into a given state to have identical actions. The reasoning seems to be that most everyday modelling situations are easilly representable with a very small number of modelling constructs. Since they (S-M) intend to translate from the start, having to define translations for a smaller number of constructs is desireable. I believe that there's a bit of a trade-off here in sacrificing some amount of expressive power in the modelling language in order to simplify the construction of the translator(s). But I'll go on to say that I think it's a value judgement as to how much worth you ascribe to expressive power in the modelling language vs. simplicity of the translator. > 3. Here is part of a state model, courtesy of myself and Stephen > R. Tockey. "Waiting..." is the initial state of the model. > Char available is an external event generated by the UART when a > character is available for reading. How do I turn this fragment > into code, based on the example on page 190 of "Object > Lifecycles: Modeling the World in States"? I have no code > generator, but plenty of ideas. > > [diagram cut out] The good news/bad news is that there is no one single answer. There are many, many different possibilities. As part of an analysis/design class I taught at Seattle U, we tried to characterize different possibilities in terms of "architectural" differences. For example: * Is the event-responding object a client of, or a server to, the object(s) that recognize or generate the event (i.e., does the frame-builder drive the UART by asking it to "get me the next event" or does the UART drive the frame-builder?) * Are you dealing with a single instance or a collection of instances? * Do the instances get created and deleted on-the-fly or are they more statically constructed? * Do you want the model translated into hard code or into data table(s) that are executed by an interpreter? and so on. Note: the nature of Recursive Design seems to be to make decisions like these on a system-wide basis and apply them uniformly across the entire system rather than to treat each object in the original OOA model differently. But either way, such decisions need to be made and they clearly have a major impact on the resulting code. -- steve Subject: Re: (SMU) MODEL HACKING Ken Cook writes to shlaer-mellor-users: -------------------------------------------------------------------- Andrew Nortje wrote: > > Andrew Nortje writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Hi Everyone > > We have recently bought "How to Build Shlaer Mellor Object Models" by > Leon Starr. A point that came out of the book, which I believe we are > doing, is MODEL HACKING. I had the opportunity to use Leon as a consultant on a project (and thus the opportunity to see my model hacking and other bad habits show up as examples of what *not* to do in his book!) Others have given good advice about the pre-IM work. Personally, I would like to see how a more formal method like CRC, or others, worked as a prelude to the IM. FWIW, here is what Leon asked us to do... We already had an extensive requirements document, but we still tended to hack at IM's. He asked us to write "technical description" documents, which he describes in chap 9 of his book "Why write model descriptions?" This seems to be an antidote to the #1 symptom of model hacking: I would drop a big model on Leon's desk and say, "I'm having a problem with the alignment translations, what to think I should do?" Of course, Leon did not know what alignment translations were, and asked me to write a model description, with *lots* of pictures, showing diagramatically what the model should do. Model descriptions were presented to the group for review and comment. Leon also asked each modeler to have a "back-up" modeler. You must review your model description and your model with your back-up before you ever go to the group for review. Your back-up was also the person you asked first when you were having problems with the model. The back-up person was important to help put the brakes on before run-away hacking started. We tried to make sure the back-up was the more experienced analyst. These model descriptions are **very** powerful. Some time ago, a few of us put about 3 days into modeling a small subsystem. It soon became clear that we would not need to implement this in the first revision. Before I forgot what the model meant, I wrote a 4 page model description, with lots of pictures. Four years later, an engineer comes to me and says, "that was a great analysis you did on wafer maps". "You mean what I wrote 4 years ago?", I replied. "Yeah, it's just what we need to implement now." he said. I knew the attached reproduction of the IM was barely readable - but it was the model description and the pictures that told him what he needed to know, without having to ask once "why is this object here?" That could not be done with just a cold IM. -Ken Subject: Re: (SMU) MODEL HACKING fontana@world.std.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 08:57 AM 1/20/97 -0800, shlaer-mellor-users@projtech.com wrote: >dave (Dave Wanner) writes to shlaer-mellor-users: >-------------------------------------------------------------------- >Peter also discusses the need for developing requirements that are >"atomic". While I support Peters thought process, the experience I >have with most organizations is that they do not produce "atomic" >requirements. In fact most organizations develop functional >requirements that usually span several subject matters. Thanks for catching this point Dave. I did gloss over this too much. An atomic requirement is meant to define a single functional aspect of the system from the external perspective. This was mentioned in the context of numbering requirements, and is meant to direct the requirements author away from numbering something like "the system shall [120] implement configurable communication protocols" as a single atom. It is certain that many well structured and properly decomposed atomic requirements statement will span more than one domain. __________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com| | effective solutions for OOA/RD challenges | | Peter Fontana voice: 888-OOA-PATH | fontana@world.std.com fax: 508-384-1392 | __________________________________________________| Subject: Re: (SMU) Implementation in OOA; case 1 Neil Lang writes to shlaer-mellor-users: -------------------------------------------------------------------- At 05:46 PM 1/16/97 -0500, >LAHMAN@DARWIN.dnet.teradyne.com writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >He's baaaaack! > >Recently we came across two situations where implementation issues appear to >have an affect on the OOA. Both are related to performance. This note >represents one of those cases; the second is in a second missive for >convenience. > >The first situation has to do with navigation of relationships. The >prototypical situation is: > >objA <---------------->> objB > ^ R1 ^ > | | > | | > | R2 | R3 > V V > V R4 V C >objC <-----------------> objD Before we proceed too fast with this IM fragment I'd like to point out an aspect or two about loops of relationships that has not been explicitly mentioned in any of the discussion in this thread. (I'm sure many, if not all of the, participants are aware of the issues but I'd like to expose them explicitly so others have a more complete view of the modeling issues here.) So here it goes: R1, R2, R3, and R4 make up a loop of relationships and in any loop the set of relationships may be independent or dependent. If the relationships in a loop are independent example follows ----- Person<---------------->> Doctor ^ R1 ^ | | | | | R2 | R3 V V V R4 V C Child <-----------------> School where R1 = treated by R2 = raises R3 = earned MD at R4 = attends and please forgive the multiplicity/conditionality This is most likely a loop of independent relationships as I would not expect The school that a person's child attends to be the same as the schools that a person's doctors graduated from. --------------------- then the query path R2,R4 need not produce the same result as R1,R3. In this case the analyst must specify the query path -- based on the semantics of the problem -- and the architecture better not decide to substitute the other query path. On the other hand if the relationships in the loops are dependent, ---------------------------- example follows (based on the HS's inspirational restaurant model :-) Restaurant<----------->> Patron ^ R1 ^ | | | | | R2 | R3 V V V R4 V C Menu item <------------->Cooked food where R1 = serves food to R2 = has available R3 = consumes specific R4 = is served as and please forgive the multiplicity/conditionality This is a loop of dependent relationships (and quite contrived I must say) since the cooked food that a patron can consume must corrrespond to menu items availble at that restaurant. ---------------------------------- then the query paths between any two pairs of objects must produce the same instance(s). (And I'm assuming that this is the case in HS's model) Now the analyst must understand the real world enough to determine what the loop depedenncy is and must declare so in the model. To declare a loop to independent we simply formalize each relationship separately. To declare a loop to be dependent, there are a number of options (see the OOA96 report for a thorough treatment of loops) some of which may allow make eliminate the issue of choice of path. For instance one way to declare a loop to be dependent, is to formalize one of the relationships by composition; this effectively forces all queries to proceed in one (analyst specified) direction and the architecture would implement that path always. Now before HS jumps on me too quickly, let me point out that there are techniques to declare a loop as dependent that still allow for choice in query path. The discussion that followed from HS's posting is relevant and thought-provoking, but I did want to make sure that everyone in the esmug was aware of the issues about loops of relationships. ......remainder of HS's posted deleted. Neil ---------------------------------------------------------------------- Neil Lang nlang@projtech.com Project Technology, Inc. 510-845-1484 2560 Ninth Street, Suite 214 Berkeley, CA 94710 http://www.projtech.com ---------------------------------------------------------------------- Subject: (SMU) Re: Implementation in OOA; case 1 LAHMAN@DARWIN.dnet.teradyne.com writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Lang ... Neil, you make a good point in that I should have been a bit more explicit about my assumption of dependency. Most of our relationship loops are dependent so I tend to think in those terms. I should also have mentioned that we tend to encounter these situations where there are a lot more objects (half a dozen or more) involved in a particular path so that the example was simplified for presentation. We also routinely collapse referentials and employ composed relationships. >...To declare a loop to be dependent, there are a number of options (see >OOA96 report for a thorough treatment of loops) some of which may allow >make eliminate the issue of choice of path. ... > >Now before HS jumps on me too quickly, let me point out that there are >techniques to declare a loop as dependent that still allow for choice in >query path. ... This is where you lose me, though. As I read this you seem to be saying that the OOA96 notation can determine which path to select for the ADFD navigation. OOA96 introduced some new notation to clarify the relationships, but I didn't read it to say one could eliminate relationships. So long as the dependent relationship loop exists, it seems to me that the analyst must *always* choose which path to use in the ADFD (or ASL) for the navigation. What an I missing here? H. S. Lahman "There's nothing wrong with me that Teradyne/ATB wouldn't be cured by a capful of Draino." 321 Harrison Av L51 Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) IM Request Allen Theobald writes to shlaer-mellor-users: -------------------------------------------------------------------- Greetings! I am in the process of doing analysis for a integrated development environment (project manager), such as an environment like Visual C++, Borland, or Metrowerks Codewarrior. In Leon Starr's words, I am in the "Finding, Collecting and organizing data" stage of analysis. However, I would also like thoughts on "generalizing, simplifying, abstracting" these three environments to come up with a first draft of the object model, and more importantly domains, for an integrated development environment/project manager. Anyone want to throw ideas my way? Thanks in advance, Allen Subject: Re: (SMU) Re: Implementation in OOA; case 1 Neil Lang writes to shlaer-mellor-users: -------------------------------------------------------------------- At 08:26 AM 1/21/97 -0500, you wrote: >LAHMAN@DARWIN.dnet.teradyne.com writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >Responding to Lang ... > >Neil, you make a good point in that I should have been a bit more explicit >about my assumption of dependency. Most of our relationship loops are >dependent so I tend to think in those terms. I should also have mentioned >that we tend to encounter these situations where there are a lot more >objects (half a dozen or more) involved in a particular path so that the >example was simplified for presentation. We also routinely collapse >referentials and employ composed relationships. > >>...To declare a loop to be dependent, there are a number of options (see >>OOA96 report for a thorough treatment of loops) some of which may allow >>make eliminate the issue of choice of path. ... >> >>Now before HS jumps on me too quickly, let me point out that there are >>techniques to declare a loop as dependent that still allow for choice in >>query path. ... > >This is where you lose me, though. As I read this you seem to be saying that >the OOA96 notation can determine which path to select for the ADFD >navigation. OOA96 introduced some new notation to clarify the relationships, >but I didn't read it to say one could eliminate relationships. So long as >the dependent relationship loop exists, it seems to me that the analyst must >*always* choose which path to use in the ADFD (or ASL) for the navigation. >What an I missing here? > Your observations about OOA96 are correct. And the analyst MUST still indicate which query path is to be executed. My point was actually directed at what the architecure may be able to do during translation. Consider a loop of relationships R1, R2, R3 in which we've formalized R3 by composition to indicate the loop as a dependent loop. How is a traversal across R3 expressed in process models? In text based action languages I'd expect to see the analyst still say something like: Select one/many B_inst related by A_inst ->B[R3] and have the architecture recognize that this query has to be implemented by traversing R1 and R2. In ADFDland (OOA96 version), once the analyst recognizes the composed relationship, s/he will have to directly specify the traversal of R1 and R2. But imagine a more abstract graphical process modeling language with a relationship traversal process. Then I'd expect the analyst to draw a Traverse R3 process with the identifier of A as input and the identifer of the related instances of B as output, and let the architecture/translator figure out that the real query has to be made via R1 and R2. Of course this only applies to one type of dependent loops.( I haven't thought very much about what could be done when we formalize dependent loops with collapsed referentials ) Hope this makes things a little less murky. Neil ---------------------------------------------------------------------- Neil Lang nlang@projtech.com Project Technology, Inc. 510-845-1484 2560 Ninth Street, Suite 214 Berkeley, CA 94710 http://www.projtech.com ---------------------------------------------------------------------- Subject: (SMU) Spliced State Models J.W.Terrell@nortel.co.uk writes to shlaer-mellor-users: -------------------------------------------------------------------- Greetings! I'm working on a project where the use of spliced state models for subtype and supertype objects could prove very beneficial. However, I'm not sure how to represent them in the analysis. For example, how does the supertype object indicate that the next part of its lifecycle is defined by one of its subtypes? The only way I could think of was to add a dummy state (in effect, a hierarchical state) to the supertype object to indicate where the subtypes takeover. And as for the subtype objects, they could shadow the supertype states to which their lifecycles are connected. I guess any representation needs to carry sufficient information to enable an automatic code generator to support the event rules described on p60 of book 2. If anyone's had experience of spliced state models, I'd be most grateful to hear from them. Regards, Jeff. -- Jeff Terrell Nortel, London Rd, Harlow, Essex, UK. +44 (0)1279 405870 J.W.Terrell@nortel.co.uk Subject: Re: (SMU) Spliced State Models David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: -------------------------------------------------------------------- > J.W.Terrell@nortel.co.uk writes to shlaer-mellor-users: > I'm working on a project where the use of spliced state models for > subtype and supertype objects could prove very beneficial. > However, I'm not sure how to represent them in the analysis. My feeling is that there is nothing special about spliced lifecycles. You can view the supertype and subtype as different objects, each with their own state models, that communicate using events. Normally, the state in which the subtype is doing the work is a naturally occuring state. Often there is no need to explicitly transfer control between the two - events can be generated by other objects in the system that either are directed at the subtype or delivered polymorphically (or accepted by the supertype at the end of a "splice". PT often talk about all the instances in a subtype tree as being a single instance. I find that this introduces conceptual problems that simply do not exist if you view the tree as a set of independent objects. They also say that the "single instance" should not have more than one lifecycle, which is where the idea that a splice is something special arises. I view a splice as a pattern of communication/sychronisation. If you think about it, all cooperating lifecycles could be described using splicing. Dave. -- David P. Whipp. Not speaking for: ------------------------------------------------------- G.E.C. Plessey Due to transcription and transmission errors, the views Semiconductors expressed here may not reflect even my own opinions! Subject: (SMU) Re: Spliced State Models LAHMAN@DARWIN.dnet.teradyne.com writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Terrell... >I'm working on a project where the use of spliced state models for >subtype and supertype objects could prove very beneficial. >However, I'm not sure how to represent them in the analysis. > >For example, how does the supertype object indicate that the next >part of its lifecycle is defined by one of its subtypes? The only >way I could think of was to add a dummy state (in effect, a >hierarchical state) to the supertype object to indicate where the >subtypes takeover. And as for the subtype objects, they could shadow >the supertype states to which their lifecycles are connected. Unfortunately different tool vendors support splicing in different ways, so I will take the low road and ignore that issue. To do sub/super state model splicing you simply need to have a super type state machine and individual subtype state machines. Events directed to these state machines use the appropriate event IDs. That is, if a subtype needs shared supertype functionality it issues a supertype event. The trickier part is, as you point out, the supertype issuing the subtype event in a generic way. Here OOA96 comes to the rescue. It allows you to build a translation table for supertype events. The table indicates a corresponding subtype event for each subtype. This table essentailly allows the event manager to re-direct the "supertype" event to the current subtype's state model as an event in that state model. In the splicing case the table would not provide translations for the true supertype events that are not to be redirected. Clearly, the "supertype" events that are generated in the supertype and are intended for subtypes cannot appear as transitions on the supertype state model because they really aren't directed at that model. Also, each subtype must expect the same data packet for the "supertype" event. Other than that, it is pretty straight forward, assuming your architecture and code gnerator can handle the OOA96 polymorphic events properly in a splicing situation. In practice the vendors usually have some alternative means for doing the splicing that is pretty close to this, so your vendor should be able to provide the details. H. S. Lahman "There's nothing wrong with me that Teradyne/ATB wouldn't be cured by a capful of Draino." 321 Harrison Av L51 Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) Re: IM Request LAHMAN@DARWIN.dnet.teradyne.com writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Theobald... >I am in the process of doing analysis for a integrated development >environment (project manager), such as an environment like Visual C++, >Borland, or Metrowerks Codewarrior. In Leon Starr's words, I am in the >"Finding, Collecting and organizing data" stage of analysis. However, I >would also like thoughts on "generalizing, simplifying, abstracting" these >three environments to come up with a first draft of the object model, and >more importantly domains, for an integrated development environment/project >manager. Anyone want to throw ideas my way? We generally create a detailed Functional Specification for any project. In the future we will carry this further by also creating a functional spec for each domain as a result of recent process improvement analysis. The functional spec effectively formalizes the "Finding, Collecting, and Organizing data". We write functional specs from the user's view. In particular, we treat the subject software as a black box in this spec. (We tend to regard the OOA as the white box specification.) The spec is quite detailed; every screen is mocked up, every error message described, every API function is described in the programmatic interface, and the behavior for every user action is described. (The behavior is described in terms of system outputs where the behavior would be manifested.) For the project I am currently working on -- a device driver for a digital tester that will probably end up around 100K NCLOC -- the total relevant functional spec ran to close to 1000 pages. At this point we have a pretty good idea of What we wanted to build. The end user for a service domain when writing a domain functional spec would be primarily the client domain that defines the services required. The available services (other domains whose services will be used) also play a part because one needs views of them. That is, a domain functional spec would specify the interaction with other service domains because that interaction is part of the domain's black box I/O. The application domain's functional spec is the project functional spec because that domain's client is the end user. If a good job is done writing such a detailed functional spec, it becomes fairly easy to find abstractions in the functional spec because of the level of detail. One reason we are going to domain functional spec was that the connection between the user's abstractions at the system level are sometimes not easy to relate to service domains. In our case the end user really doesn't care much about how we build our hardware but our service domains care a whole lot. We use the project level functional spec for identifying domains. Our initial cut is usally made based upon three criteria. The main criteria is reuse. If we see abstractions in the functional spec that obviously will encapsulate a large amount of processing (e.g., a Test Vector Editor) that could concevably be Plug&Played into another application, we will make a domain of it. The next most important criteria is modularity. We will tend to make domains to shield large scale subsystems. For example, we would normally have a Hardware Interface domain that shields the overall, generic digital test logic from the details of particular hardware implementation (i.e., register fields). The domain firewall is execellent for this. A third criteria is the recognition of patterns of related functionality in the spec. We will generally try to encapsulate related functionality in a domain. Generally there is a second pass at domains where other abstractions are recognized during the development of the IMs. One of our goals in doing domain level functional specs is to describe the domains in sufficient detail that we can recognize these before starting the domain IMs and update the domain chart accordingly. Thus we see the Domain Chart as being kind of interwoven with the development of detailed functional specifications for the system. Bottom line: describe the black-box What of what you need to do in detail and the white-box abstractions will tend to follow naturally. H. S. Lahman "There's nothing wrong with me that Teradyne/ATB wouldn't be cured by a capful of Draino." 321 Harrison Av L51 Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) Re: Implementation in OOA; case 1 LAHMAN@DARWIN.dnet.teradyne.com writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Lang... >Your observations about OOA96 are correct. And the analyst MUST still >indicate which query path is to be executed. My point was actually >directed at what the architecure may be able to do during translation. Ah, but the point of the original example was that the decision is being made in the OOA and that decision is based upon performance issues. >In ADFDland (OOA96 version), once the analyst recognizes the >composed relationship, s/he will have to directly specify >the traversal of R1 and R2. But imagine a more abstract graphical >process modeling language with a relationship traversal process. >Then I'd expect the analyst to draw a Traverse R3 process >with the identifier of A as input and the identifer of the related >instances of B as output, and let the architecture/translator >figure out that the real query has to be made via R1 and R2. Hmmm. I am not sure I understand *why* the analyst needs to specify R1/R2. In fact, I would think that R3 would usually be the more efficient path since I would not have to iterate over the elements of the intermediate set. This is admittedly a marginal benefit since the total number of instances processed would be the same if all relationships are unconditional, but there is still initialization and other overhead. In addition it is easy for the architechture to be a pig if it just does brute force processing of multi-leg paths. BTW, another thing I didn't make clear in the original example is that the performance issue in the choice usually only becomes highly significant if at least one relationship leg is conditional. The conditionality makes it possible for one path to have an intermediate object with a very large number of mostly irrelevant instances that need to be processed. If all legs are unconditional in all paths, then the number of instances processed should be the same in both directions. In that case the only performance gain would be in selecting the path that had the fewest objects to reduce the overhead of the previous paragraph. Assuming a composed relationship where R3 = R1 + R2, if the ADFD rules force one to use R1/R2, then you can get badly trashed if R2 is conditional because R1 might yield a huge number of instances to process for the R2 relationship. However, if one goes by R3 directly the instance count processed is limited to the end set count. H. S. Lahman "There's nothing wrong with me that Teradyne/ATB wouldn't be cured by a capful of Draino." 321 Harrison Av L51 Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Spliced State Models J.W.Terrell@nortel.co.uk writes to shlaer-mellor-users: -------------------------------------------------------------------- > David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > > J.W.Terrell@nortel.co.uk writes to shlaer-mellor-users: > > > I'm working on a project where the use of spliced state models for > > subtype and supertype objects could prove very beneficial. > > However, I'm not sure how to represent them in the analysis. > > My feeling is that there is nothing special about spliced lifecycles. > You can view the supertype and subtype as different objects, each with > their own state models, that communicate using events. What events do you have in mind? If a state model is split into two, why should the two parts necessarily communicate? I think they'll only communicate when a self-directed event from the original state model spans the supertype subtype portions. My view is that spliced state models are different and that they require special treatment. > Normally, the state in which the subtype is doing the work is a > naturally occuring state. Often there is no need to explicitly > transfer control between the two - events can be generated by other > objects in the system that either are directed at the subtype or > delivered polymorphically (or accepted by the supertype at the end > of a "splice". But what state is the supertype object in when the subtype is "in control" of the lifecycle? This gets back to my original question regarding representation. Regards, Jeff. -- Jeff Terrell Nortel, London Rd, Harlow, Essex, UK. +44 (0)1279 405870 J.W.Terrell@nortel.co.uk Subject: Re: (SMU) Re: Implementation in OOA; case 1 Neil Lang writes to shlaer-mellor-users: -------------------------------------------------------------------- At 09:27 AM 1/22/97 -0500, you wrote: >LAHMAN@DARWIN.dnet.teradyne.com writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >Responding to Lang... > >>Your observations about OOA96 are correct. And the analyst MUST still >>indicate which query path is to be executed. My point was actually >>directed at what the architecure may be able to do during translation. > >Ah, but the point of the original example was that the decision is being >made in the OOA and that decision is based upon performance issues. But I noticed that the followup discussion did discuss what an architecture can do in such circumstances. > >>In ADFDland (OOA96 version), once the analyst recognizes the >>composed relationship, s/he will have to directly specify >>the traversal of R1 and R2. But imagine a more abstract graphical >>process modeling language with a relationship traversal process. >>Then I'd expect the analyst to draw a Traverse R3 process >>with the identifier of A as input and the identifer of the related >>instances of B as output, and let the architecture/translator >>figure out that the real query has to be made via R1 and R2. > >Hmmm. I am not sure I understand *why* the analyst needs to specify R1/R2. >In fact, I would think that R3 would usually be the more efficient path >since I would not have to iterate over the elements of the intermediate >set. This is admittedly a marginal benefit since the total number of >instances processed would be the same if all relationships are >unconditional, but there is still initialization and other overhead. In >addition it is easy for the architechture to be a pig if it just does brute >force processing of multi-leg paths. > Remember when a relationship is formalized by composition, there are NO referential attributes in the IM for that relationship. And since in ADFDland we traverse relationships by retrieving referential attributes directly, it seems to me the only way an analyst could traverse R3 is by retrieving the R1 and R2 referentials. >BTW, another thing I didn't make clear in the original example is that the >performance issue in the choice usually only becomes highly significant if >at least one relationship leg is conditional. The conditionality makes it >possible for one path to have an intermediate object with a very large >number of mostly irrelevant instances that need to be processed. If all >legs are unconditional in all paths, then the number of instances processed >should be the same in both directions. In that case the only performance >gain would be in selecting the path that had the fewest objects to reduce >the overhead of the previous paragraph. > >Assuming a composed relationship where R3 = R1 + R2, if the ADFD rules force >one to use R1/R2, then you can get badly trashed if R2 is conditional >because R1 might yield a huge number of instances to process for the R2 >relationship. However, if one goes by R3 directly the instance count >processed is limited to the end set count. Again if R3 is composed, then there are no referentials for R3 and no way to traverse R3 directly. Also the issue of conditionality was something that took us at PT a long time to appreciate. One can only use composed relationships if the other path yields an instance or set of instances. In the above example if R3 is unconditional and R2 is conditional then you can't formalize the relationship by composition since you can't always use the R1+R2 path to get to the related instance of R3. There are awful lot of subtle details in composed relationships, and I'd suggest that those interested in pursuing this take a look at chapter 3 in the OOA96 report. Neil ---------------------------------------------------------------------- Neil Lang nlang@projtech.com Project Technology, Inc. 510-845-1484 2560 Ninth Street, Suite 214 Berkeley, CA 94710 http://www.projtech.com ---------------------------------------------------------------------- Subject: Re: (SMU) Spliced State Models David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: -------------------------------------------------------------------- > J.W.Terrell@nortel.co.uk wrote > > But what state is the supertype object in when the subtype is "in > control" of the lifecycle? This gets back to my original question > regarding representation. Can an object ever said to be "in control" of its lifecycle? A lifecycle defines what happens to an object, not what it does. It gets kicked around and will respond in an appropriate manner. The proportion of self-directed events in a system is usually fairly small. Lets take a specific (contrived) example. A BUS_ACCESS object has a lifecycle that progresses from requesting the bus, through accessing memory, to releasing the bus. Subtypes READ_ACCESS and WRITE_ACCESS are different because the direction and timing of the data transfer differ. The lifecycle of the BUS_ACCESS is * | V [waiting for bus] = assert b_req | | V [doing access] = send address, size, prot, etc. info. | = send polymorphic "start_access" event to subtype | | -- from subtype V [releasing bus] = deassert b_req X Here, the subtype is "in control" when the master is in the "doing access" state. When the subtype has completed the access, it sends the access_complete event to the supertype (this could be indirectly sent, via another object or domain). In this scheme, the subtype would determine the end of the cycle by monitoring the bus signals. When it completes, it signals the supertype. A slightly different model would be to have the supertype monitoring the bus signals and telling the subtype when it can complete. This would not require any additional states and would break the splice into two parts. When I use the phraze "monitor bus signals", what I really mean is "can accept events from the bus (via wormhole?)". There is no active monitoring in the object. Indeed, whatever generates events from the bus does not need to know where the events are consumed because they would either be accepted by the supertype or would be passed polymorphically to the subtype. There is no difference externally. The splice is never explicitly defined. It emerges in the communication pattern because the supertype doesn't recieve any events until the subtype has done whatever it does. If the splice was in the supertype then it would be the subtype that doesn't recieve any events. There is no enforcement of splicing. If you have a bug then it is possible that the waiting object may transition before the splice has completed (this can be trapped by using pre-conditions in the next-state). As an aside, we could consider the effect of introducing guard clauses on transitions. It is not uncommon to require conditional generation of events - often the test is the same in many places, and tests the state of the reciever. A cleaner technique may be to associate the test with the transition, not the generator. This might also facilitate checking the correctness of splices, Dave. -- David P. Whipp. Not speaking for: ------------------------------------------------------- G.E.C. Plessey Due to transcription and transmission errors, the views Semiconductors expressed here may not reflect even my own opinions! Subject: Re: (SMU) Spliced State Models hogan@lmtas.lmco.com (Bary D. Hogan) writes to shlaer-mellor-users: -------------------------------------------------------------------- > > David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > > J.W.Terrell@nortel.co.uk writes to shlaer-mellor-users: > > > I'm working on a project where the use of spliced state models for > > subtype and supertype objects could prove very beneficial. > > However, I'm not sure how to represent them in the analysis. > > My feeling is that there is nothing special about spliced lifecycles. > You can view the supertype and subtype as different objects, each with > their own state models, that communicate using events. You could view it this way, but wouldn't that be a direct violation of the methodology? > > Normally, the state in which the subtype is doing the work is a > naturally occuring state. Often there is no need to explicitly > transfer control between the two - events can be generated by other > objects in the system that either are directed at the subtype or > delivered polymorphically (or accepted by the supertype at the end > of a "splice". I disagree. There is a need to explicitly transfer "control" between the supertype and subtype *parts* of the state model. As splicing is defined, each instance of the supertype/subtype is in only one state at a time, whether it be a state from the supertype splice or the subtype splice. > > PT often talk about all the instances in a subtype tree as being > a single instance. I find that this introduces conceptual problems > that simply do not exist if you view the tree as a set of independent > objects. They also say that the "single instance" should not have > more than one lifecycle, which is where the idea that a splice is > something special arises. I view a splice as a pattern of > communication/sychronisation. If you think about it, all cooperating > lifecycles could be described using splicing. I believe that there are good reasons for the methodology to be defined such that a *thing* represented by an instance in a supertype/subtype tree is really a single instance, and only has one lifecycle. In the real world, it is a single thing. If you find that the thing has multiple, independent state models, then possibly there really more objects there, or maybe more domains (differing views of the same thing). As for the original question, representation of splicing is a big problem. We have not used it for that very reason. For instance, what if an event could cause a transition in either the supertype or subtype splice of the state model depending on which part the instance is currently in. You don't want the object that generates the event to know which part of the state model the instance is currently in. You would need a *special* polymorphic event that can be accepted by the supertype or the subtype, depending on which part of the state model is active. Sounds rather nasty. I'm wondering if PT has given much thought to this, and whether they are planning to support splicing at some point in Bridgepoint. Bary Hogan Lockheed Martin Tactical Aircraft Systems Subject: Re: (SMU) Spliced State Models randyp@primenet.com (Randy D. Picolet) writes to shlaer-mellor-users: -------------------------------------------------------------------- >hogan@lmtas.lmco.com (Bary D. Hogan) writes to shlaer-mellor-users: >As for the original question, representation of splicing is a big >problem. We have not used it for that very reason. For instance, what >if an event could cause a transition in either the supertype or subtype >splice of the state model depending on which part the instance is >currently in. You don't want the object that generates the event to >know which part of the state model the instance is currently in. You >would need a *special* polymorphic event that can be accepted by the >supertype or the subtype, depending on which part of the state model is >active. Sounds rather nasty. > I have implemented state model splicing and strongly prefer it over subtype migration for both conceptual and architectural reasons. The primary implementation issues I encountered were resolved by adopting a view that considers a state model to be part of the type model specifications that form the type heirarchy. Thus all elements of a state model (events, states, transitions, and actions) are inherited by subtypes in a manner similar to the usual inheritance of methods and data attributes (i.e. overlaying the components top-down thru the type heirarchy according to rules for extending and/or overriding the inherited components). OOA96 explicitly defines the rules for event polymorphism, and indirectly the rules for their inheritance (same data structure/signature, different labels/semantics) but I can only infer rules for states and transitions from the brief discussion and examples in OOA91. What I have found to work quite well is to allow, at each node in the tree, extension of the state model by adding a new event, state, or transition, but not elimination/override of those inherited from the supertype. This is seems to be philosophically in line with the commonly accepted understanding of generalization/specialization. >From an STD perspective, this corresponds to adding new nodes or arcs to the partial diagram of the parent, but not erasing any that are already there. From an STT perspective, this can be viewed as adding a new row (event) or column (state) of CANT HAPPEN entries, or changing an existing entry from CANT HAPPEN to IGNORE or (from either of those) to a valid state ID, but nothing else. Likewise, I prefer to allow (only) extension of the actions as well. This effectively means that any action in a subtype must invoke/embed the corresponding action of its parent in its definition. [Note that such action extension or nesting is not currently addressed in the method, however, so there is no notation for ADFD "splicing".] This allows a subtype to generate additional output in a given state, even if the structure of the STD itself doesn't change. In actual code implementation, I favor applying all of this "overlaying" at translation time, so that every instantiable type has its own complete state model defintion structures statically available at runtime (just as the method tables and physical data representation are precompiled). This is both more time efficient and (to me) easier to comprehend than a lot of runtime "communication" between different "instance components". This approach has been quite flexible, allowing the capture of abstract partial types, independent introduction of events, states, and (within the above constraints) transitions anywhere in the type heirarchy, and specialization of actions. While some of these uses may be less constrained than is currently specified or allowed by the method, it is nonetheless sufficient to implement state model splicing. I have not implemented multiple inheritance, but I believe it should be conceptually similar, although mechanically more difficult. Inheritance of two parent state models would correlate to merging their STTs into a single table that maintains all inherited transitions, and introduces CANT HAPPEN entries for all new combinations of each parent's states with the other's events. Subject: Re: (SMU) Spliced State Models David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: -------------------------------------------------------------------- > hogan@lmtas.lmco.com (Bary D. Hogan) writes to shlaer-mellor-users: > David.Whipp@gpsemi.com (Dave Whipp) wrote: > > My feeling is that there is nothing special about spliced lifecycles. > > You can view the supertype and subtype as different objects, each with > > their own state models, that communicate using events. > > You could view it this way, but wouldn't that be a direct violation of > the methodology? I don't think so - the method provides no explicit rules for splicing, so I assume that the normal rules apply. The method is meant to have a minimal number of concepts and I see no need for any additional ones here. > I disagree. There is a need to explicitly transfer "control" between > the supertype and subtype *parts* of the state model. As splicing is > defined, each instance of the supertype/subtype is in only one state at > a time, whether it be a state from the supertype splice or the subtype > splice. An object cannot be _not in a state_. Even passive objects can be considered to have a single state. And an object cannot be in more than one state at a time. The problem occurs when you start to treat two objects, related by a supertype relationship, as a single object. Then, the single compound instance has a state that is a superposition of the state of all the objects in the tree (but its still a single state). Such parallel state machine flattenning is not a problem for translation, it just increases the number of states. One issue that arises in a spliced situation is that specific states in the subtype can only occur for a subset of the supertype's states. This is a constraint that is not currently shown in the OOA. Implementation efficiency could be impoved by supplying this information but the behaviour would not be effected. Hense you might consider colouring states in the subtype (or subertype) to constrain the combinatorial explosion of the state model flattenning process. > As for the original question, representation of splicing is a big > problem. We have not used it for that very reason. For instance, what > if an event could cause a transition in either the supertype or subtype > splice of the state model depending on which part the instance is > currently in. You don't want the object that generates the event to > know which part of the state model the instance is currently in. You > would need a *special* polymorphic event that can be accepted by the > supertype or the subtype, depending on which part of the state model is > active. Sounds rather nasty. OOA96 does not allow an event to be polymorphic in some states but not in others. A polymorphic event can only be directed at the supertype and can never be consumed by the supertype. Non-polymorphic events can only be directed at, and consumed by, the supertype. Hence your scenario cannot occur. Different tools interpret this differently. KC's IOOA makes an event available to all objects in the tree, always. SES makes it abailable to the lowest level object that can consume it - hence polymorphism is dependent on which subtypes are currently instantiated. I don't know what bridgepoint does but I would assume it is consistant with OOA96. Dave. -- David P. Whipp. Not speaking for: ------------------------------------------------------- G.E.C. Plessey Due to transcription and transmission errors, the views Semiconductors expressed here may not reflect even my own opinions! Subject: (SMU) What is a valid S-M Analysis? Allen Theobald writes to shlaer-mellor-users: -------------------------------------------------------------------- Greetings S-M Users! I didnt' get a whole lot of response to my prior post "IM request". So if anyone would care to comment, I would appreciate advice. Thanks to H.S. Lahman, who provided me with good background information. Now, to the next questions: What exactly makes Shlaer-Mellor a methodology? That is, to provide a complete and executable description of the problem, these models must be produced: information model, state models, and process models. But what must criteria must be satisfied to make it a valid Shlaer-Mellor analysis? The reason I ask this, is because, we must provide to our client evidence of Shlaer-Mellor formal methodology. How is this done? What documents must be produced? What do they look like? What are their contents? Thanks in advance for your information. This group has been very informative, and the advice much appreciated. Allen Subject: (SMU) Re: Implementation in OOA; case 1 LAHMAN@DARWIN.dnet.teradyne.com writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Lang... Regarding composed relationships: >Remember when a relationship is formalized by composition, there >are NO referential attributes in the IM for that relationship. >And since in ADFDland we traverse relationships by retrieving >referential attributes directly, it seems to me the only way an analyst >could traverse R3 is by retrieving the R1 and R2 referentials. Oh, really? It would have been nice if OOA96 had been a tad more clear that the referential attributes are not instantiated. I missed the subtlety of there being no R3 in Fig. 3-9. Also, the text implied the relationship was instantiated by making the point that it (R3) was not intended to mean the same thing as R1 and R2. Now that I know this, I don't like it. I would prefer that the notation merely provided a clue to the translator about the equivalence of the paths rather than dictating which path should be used. Since the translator needs a lot of freedom in implementing referentials anyway (i.e., data is rarely accessed using referentials literally in practice), this seems overly constraining. If the notation merely provided information, it would be helpful to the optimizing translator that was hypothesized in the thread without constraining it. Regarding conditionality: >Also the issue of conditionality was something that took us at PT a long >time to appreciate. One can only use composed relationships if the other >path yields an instance or set of instances. In the above example if R3 is >unconditional and R2 is conditional then you can't formalize the >relationship by composition since you can't always use the R1+R2 path to get >to the related instance of R3. Excluding conditionality severely restricts the application of composed relationships because most referential loops tend to have at least one conditional leg. Since the model must support the general case of dependent loops that have conditional legs, it is not clear to me why the special case of a composed dependent loop with conditionals is excluded. It seems to me the basic constraint on any dependent loop is that alternate paths between two objects must yield identical sets. If any legs are conditional the fact that the paths are dependent places some constraints on the conditionality of the paths: +--------------------------+ | R1 | | V V R2 R3 V X<--------->>Y<----------->Z If R2 and R3 are not conditional (on the right in all cases), then it would be an error to make R1 conditional. Similarly, if R2 is conditional, then R1 must be conditional. And if R1 is conditional at least one of R2 and R3 must be conditional. Also, if R1 is conditional, then traversal of either path may yield an empty set of Z. However, R1 may be unconditional if R3 is conditional. In this case the dependence of R1, R2 and R3 constrains the set of Y obtainable from any X so that at least one must have a relation to a Z. It is not clear to me why saying that R1 is composed from R2 and R3 specifically would change any of this. This leads me to think that PT has a different purpose for the composed relationship. I had assumed that it was merely a means of making dependent relationships in the model explicit. In particular, it would highlight the implied constraint on the set of Y reached via R2 when R3 alone is conditional. By explicitly excluding conditionality in a composed relationship, you clearly have something else in mind for it. Care to share? [In anticipation of someone objecting to R3 alone being conditional, consider: X = Bar & Grill Y = Customer (who may eat or drink or both) Z = Dinner Selection R2 = X serves Y R3 = Y may select Z R1 = X prepares Z (owner's freeloading brother-in-law always eats there).] H. S. Lahman "There's nothing wrong with me that Teradyne/ATB wouldn't be cured by a capful of Draino." 321 Harrison Av L51 Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) Re: Spliced State Models LAHMAN@DARWIN.dnet.teradyne.com writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Whipp... Regarding "flatenning" of spliced FSMs: I see splicing as more of a subroutining process than an inheritance process. In this view the spliced FSM is a union of all of the states from the subtype and the supertype(s); no more and no less. That is, the spliced FSM structure would be indistinguishable from a pure subtype FSM built to provide the same behavior without splicing. The increase in states when forming the spliced state machine is additive rather than combinatorial, which suggests to me that you have a different model in mind for the mechanics of splicing. In addition, I don't understand your reference to "specific states in the subtype can only occur _for a subset of the supertype's states_". This seems to imply some sort of correspondence mapping of states in the subtype to states in the supertype. Finally, is it possible you are using "state" in the sense of the overall state *of* the FSM rather than a state *within* the FSM? H. S. Lahman "There's nothing wrong with me that Teradyne/ATB wouldn't be cured by a capful of Draino." 321 Harrison Av L51 Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) What is a valid S-M Analysis? "Stephen R. Tockey" writes to shlaer-mellor-users: -------------------------------------------------------------------- > What exactly makes Shlaer-Mellor a methodology? That is, > to provide a complete and executable description of the > problem, these models must be produced: information model, > state models, and process models. > > But what must criteria must be satisfied to make it a valid > Shlaer-Mellor analysis? In my opinion, a method(-ology) is defined in terms of four characteristics: Concepts: the "words" available in the modeling language, and what those "words" mean, i.e., what kinds of things about a system get modeled and how do I interpret a well-formed model. In S-M OOA, the concepts are things like Object, State, Transition, Event, Attribute, Relationship, Domain, ... together with the definitions of those things (e.g., "An Object represents a set of things that exhibit the same characteristics and are subject to the same constraints", "A state is ...", etc.). Rules: the criteria that define whether a given model is well-formed or not. For example, in S-M OOA, attributes are only allowed to take on atomic values. A model that had attributes that took on complex structures as values would not be considered a valid S-M OOA model. This is but one example rule. A number of other rules are sprinkled thru the S-M OOA books and the OOA96 report. Notations: a set of conventions about how the concepts are recorded on some medium (e.g., paper or graphics display) so that they can be communicated to other people. S-M OOA notations include the overall set of diagrams (IMs, State Models, Event Trace/Communication diagrams, ADFDs, ...) together with the specific symbols used on the diagrams (states are shown as rectangles on a state diagram, transitions are shown as directed lines, ...). Strategies: the heuristics, guidelines, step-wise procedures, etc. that guide developers through to the completion of the model (e.g., build the IM first, follow this with state models then build ADFDs, ...). Insofar as S-M OOA exhibits all of these characteristics, I'd safely call it a method(-ology). In contrast, Pete Coad's OOA book (IMHO) would not qualify because all it really offered was a notation. Coad's book never really defined the concepts, never said anything about rules for determining the validity of models, and offered nothing in the way of strategy. Maybe he had more solid notions along these lines, but they certainly did not come out in his book. In its current state, and per my definition, the 3 amigos' UML is not yet a complete method(-ology). It proposes Concepts and Rules (in the so-called meta-model) and Notations, but intentionally avoids Strategy (as was requested by the OMG RFP). Specifying one or more strategies would make UML a complete method(-ology). As far as I am concerned, however, it's really the Concepts and Rules that constitute the important parts of any method(-ology). I may want to use different Notations to highlight different aspects of the model for different purposes. I would also want a variety of Strategies for attacking different kinds of systems (e.g., the infamous top-down vs. bottom-up debate in SA). Clearly there's an interplay between Concepts and Notations (we shouldn't have notations for which there are no underlying concepts and every concept should have at least one notation). But I'm also suspecting that there is an interesting interplay between Strategies and Notations, e.g., a notation for "event lists" is handy if one is following an event-partitioned style (a kind of top-down) strategy but may be less useful under other (more bottom-up) strategies. However this is drifting off of the topic. So, to directly answer your questions: Q: What makes S-M OOA a method(-ology)? A: The fact that it has a particular set of explicitly defined Concepts, Rules, Notations, and Strategies Q: What criteria must be satisfied to make some model a valid S-M OOA? A: The model uses only concepts that are defined by S-M OOA and that it complies with the rules in S-M OOA that define well-formed models I'd like to add that some may feel that the model must also use the S-M notation and have been built following (one of?) the S-M suggested strategy(s), but I'm less concerned with this aspect The questions you didn't ask were: Q: How is S-M OOA different than other OOAs? A: It uses a different set of Concepts, Rules, Notations, and Strategies. IMHO, the important differences between methods are in Concepts and Rules, *not* in Notations and Strategies Q: How and/or why is S-M OOA better or worse than other OOAs? A: Stay tuned to S-M-Users-Group and OTUG, the debate goes on... -- steve Subject: (SMU) Re: Spliced State Models LAHMAN@DARWIN.dnet.teradyne.com writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to hogan... Regarding control transfer in splicing: >As for the original question, representation of splicing is a big >problem. We have not used it for that very reason. For instance, what >if an event could cause a transition in either the supertype or subtype >splice of the state model depending on which part the instance is >currently in. You don't want the object that generates the event to >know which part of the state model the instance is currently in. You >would need a *special* polymorphic event that can be accepted by the >supertype or the subtype, depending on which part of the state model is >active. Sounds rather nasty. I am not convinced that splicing is a bad problem in general -- provided one satisfies four conditions: (1) OOA96 applies insofar as supporting polymorphic events is concerned. (2) All external events are directed to the supertype. (3) The instance maps only one state as active at a time and that state may be in either the subtype or the supertype. (4) Any self-directed events generated by the supertype are targetted to the supertype (i.e., if they are meant to transition to the subtype, they must be redirected there through the polymorphic mechanism). I believe a spliced state machine that is constructed in a manner that satisfies the FSM rules and these constraints should Just Work. [There is an implicit 5th condition, but that relates to one's view of spliced state machines -- see my response to Whipp in this thread.] H. S. Lahman "There's nothing wrong with me that Teradyne/ATB wouldn't be cured by a capful of Draino." 321 Harrison Av L51 Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) Paper on Recursive Design Steve Mellor writes to shlaer-mellor-users: -------------------------------------------------------------------- Everyone: In the January '97 issue of IEEE Software (a US magazine) you will find a paper by Sally and me called "Recursive Design of an Application-Independent Architecture". As you might imagine from the title, it's an end-to-end description of the Recursive Design part of the method. If you don't have access to the magazine, you can download the paper from PT's Web page at: http://www.projtech.com/cgi/rd_survey.cgi Alternatively, you can contact IEEE directly to order reprints at: Copyright and Permissions Dept IEEE Service Center 445 Hoes Lanes Piscataway, NJ 08855-1331 U. S. of A. We hope you enjoy the paper and find it useful. -- steve and sally http://www.projtech.com PS Happy New Year! Subject: Re: (SMU) Re: Spliced State Models fontana@world.std.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 01:42 PM 1/23/97 -0500, shlaer-mellor-users@projtech.com wrote: >LAHMAN@DARWIN.dnet.teradyne.com writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >I am not convinced that splicing is a bad problem in general -- provided one >satisfies four conditions: > >(1) OOA96 applies insofar as supporting polymorphic events is concerned. This is fine. > >(2) All external events are directed to the supertype. I don't see why this is necessary. > >(3) The instance maps only one state as active at a time and that state may >be in either the subtype or the supertype. This is also fine. > >(4) Any self-directed events generated by the supertype are targetted to the >supertype (i.e., if they are meant to transition to the subtype, they must >be redirected there through the polymorphic mechanism). What does "targetted" mean? Do I have to use the supertpe keyletters in the event label? Or are you simply reaffirming that an event's destination must be "correct"? Gee - this last rule seems somewhat arbitrary to me, and would seriously detract from the flexibility of the slicing mechanism. Maybe I misunderstood? __________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com| | effective solutions for OOA/RD challenges | | Peter Fontana voice: 888-OOA-PATH | peterf@pathfindersol.com fax: 508-384-1392 | __________________________________________________| Subject: Re: (SMU) Re: Spliced State Models David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: -------------------------------------------------------------------- LAHMAN@DARWIN.dnet.teradyne.com writes to shlaer-mellor-users: > I see splicing as more of a subroutining process than an inheritance > process. In this view the spliced FSM is a union of all of the states from > the subtype and the supertype(s); no more and no less. That is, the spliced > FSM structure would be indistinguishable from a pure subtype FSM built to > provide the same behavior without splicing. The increase in states when > forming the spliced state machine is additive rather than combinatorial, > which suggests to me that you have a different model in mind for the > mechanics of splicing. > > In addition, I don't understand your reference to "specific states in the > subtype can only occur _for a subset of the supertype's states_". This > seems to imply some sort of correspondence mapping of states in the subtype > to states in the supertype. I don't see that our positions are in conflict. Let me try an clarify what I was saying. In general, if you combine two independent state machines into a single state machine then the number of states in the compound will be the product of the number of states in the components. As you said, this is not necessarily true when a lifecycle is spliced, becuase there is a set of states in the subtype are only entered when the supertype is in a specific state. Thus you can add the states rather than multiplying them. Thus the term "splicing" is used to describe the specific case when parallel state machines machines can be combined additively. To go back to the original question of this thread, there is no way for the analyst to specify this within an OOA, thus the achitecture should assume the general case unless colorations are provided. It could be argued that these mapping constraints should be made an explicit part of the method (in much the same sense as looped relationships can be specified). Personally I don't see much advantage, but I realise that some architectures could utilise such information. > Finally, is it possible you are using "state" in the sense of the overall > state *of* the FSM rather than a state *within* the FSM? For a single state machine, the current state of the FSM is the value of its current_state attribute. I do not see how this is different to its current state within the FSM (Please explain). When you combine FSMs, the state of the compound is defined by the vector of values of the current_state attribute of the components. (You can argue with these definitions on the grounds that an object's state is the value of all its attributes, bit just one, but that doesn't add anything) > (3) The instance maps only one state as active at a time and that state may > be in either the subtype or the supertype. What do you mean by an "active state"? My understanding is that a state is only active at the time that it is entered - i.e. when its action is executed. After that, the object does nothing (is passive?) until it recieves another event. Transitions can occur in the subtype without causing transitions in the supertype (and visa-versa). Dave. -- David P. Whipp. Not speaking for: ------------------------------------------------------- G.E.C. Plessey Due to transcription and transmission errors, the views Semiconductors expressed here may not reflect even my own opinions! Subject: (SMU) Re: Spliced State Models LAHMAN@DARWIN.dnet.teradyne.com writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to fontana... First, let me preface with the comment that I should have mentioned that the rules were intended to keep the modelling process simple and to avoid pitfalls rather than reflecting some Arcane Theoretical Truth. Pontification is a habit that grows on one. >>(2) All external events are directed to the supertype. > >I don't see why this is necessary. Not necessary but it makes things more maintainable since the external interface is centralized. For one thing, if you decide to change what state the event goes to in the subtype, which is not unlikely in the more complex splicing case, you don't have to change the sending object's state machine. One of the problems with splicing is that external events going to subtypes tend to get forgotten and produce state changes that are unexpected when one is focused on forming the Grand Plan for how the spliced FSMs interact. It is by no means foolproof, but having a central table to check for side effects when dealing with separate FSM diagrams just makes life easier. >>(4) Any self-directed events generated by the supertype are targetted to the >>supertype (i.e., if they are meant to transition to the subtype, they must >>be redirected there through the polymorphic mechanism). > >What does "targetted" mean? Do I have to use the supertpe keyletters in the >event label? Or are you simply reaffirming that an event's destination must >be "correct"? Sorry, there was a typo. It should have read "...targetted to the subtype (i.e.,..". I meant that if a supertype state action generates a subtype event it should not directly use the subtype nomenclature. Instead it should generate a supertype event that is translated to the subtype event by the polymorphic event table. This is just a variation on the external event issue that is appropriate for the splicing situation. I think it is better to have all events from outside the subtype FSM go through the polymorphic event table. >Gee - this last rule seems somewhat arbitrary to me, and would seriously >detract from the flexibility of the slicing mechanism. Maybe I misunderstood? I don't think this restricts the flexibility splicing mechanism, so hopefully you misunderstood because of the typo. I grant that any maintainability gains for the last rule are pretty marginal and mostly subjective (i.e., it works for me). As a general comment on both rules, I tend to agree with Whipp that it is easier to develop the flow of control if one thinks about the FSMs as being in separate objects. By its nature splicing implies intimate communications between the two FSMs, which tends to make one think of them as a single, merged state machine. The trap is that one then tends to forget about true external events when organizing the splicing interface. That is, you start to think of the splicing as a synchronous sequence of events. (OOA96's priority on self-directed events alleviates this problem, assuming it is extended to include sub/super type transitions, but it doesn't cure it because of the Current State floating between FSMs.) By forcing all events that transition between FSMs to go through the polymorphic event table, there is a reminder that the FSMs are separate entities that must field *anyone's* event rather than just their sub/supertype's. In particular, it is a reminder that events are often issued by multiple clients and so an internally generated event that transitions between super/sub may also be issued (at an inconvenient time) by a truly external object. It also becomes a mental checklist item to verify that the Current State floating between FSMs will still work correctly. The other side of this coin is that events that transition between super/sub types tend to be useful for true external objects as well. So if your subtype is designed to treat the event as external, it can be transparently accessed at a later date by another object. H. S. Lahman "There's nothing wrong with me that Teradyne/ATB wouldn't be cured by a capful of Draino." 321 Harrison Av L51 Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) Re: What is a valid S-M Analysis? LAHMAN@DARWIN.dnet.teradyne.com writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Theobald... > >The reason I ask this, is because, we must provide to our client >evidence of Shlaer-Mellor formal methodology. How is this done? >What documents must be produced? What do they look like? What >are their contents? This is really a topic that is too broad to cover in a couple of E-Mail messages. I think your starting point should be the basic texts on the methodology: Object Oriented Systems Analysis, Sally Shlaer and Steve Mellor, Prentice-Hall, 1988 Object Lifecycles, Sally Shlaer and Steve Mellor, Prentice-Hall, 1992 How to Build Shlaer-Mellor Object Models, Leon Starr, Prentice-Hall, 1996 The first two provide the core methodolgy with some description of work products. The last deals only with Information Modeling. Sally and Steve also have some technical papers that you can probably get from Project Technologies. > What exactly makes Shlaer-Mellor a methodology? That is, > to provide a complete and executable description of the > problem, these models must be produced: information model, > state models, and process models. The various OOA models provide a notation for a complete abstract description of the problem and its solution that is sufficiently rigorous and unambiguous to support automatic code generation. The methodology lies in application of the notation to specific problems and translating the produced models into a working system. The books mentioned above provide the guidelines for properly applying the OOA notation. The Long Awaited RD Book will provide the techniques for translation of the OOA to code. (These are currently provided by training courses from PT and others.) > But what must criteria must be satisfied to make it a valid > Shlaer-Mellor analysis? This depends upon what you mean by "valid". The notation is unambiguous and rigorous so, by definition, code can be generated that correctly does what the models say. Also, the rigor allows simulators to be built that will verify that the models are logically correct. Whether the models say the right thing is another issue. S-M starts with a set of requirements that are assumed to provide a correct and complete view of what is to be built. Getting such a set of requirements is beyond the scope of the methodology. Given such a set of requirements, the methodology provides the guidelines for converting them into a valid representation of a solution. But that is all any methdology currently provides because at the current level of technology this is still an intellectual exercise on the part of the developer. (The only exception I know of is Atlas, which compiles test specifications directly into an executable that can be run on a tester -- but Atlas is a formal requirements language, not a methodology.) Therefore to validate that the analysis is correct at this level you still have to test it via a simulator at the model level or system test at the code level. H. S. Lahman "There's nothing wrong with me that Teradyne/ATB wouldn't be cured by a capful of Draino." 321 Harrison Av L51 Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) Re: Spliced State Models LAHMAN@DARWIN.dnet.teradyne.com writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Whipp... >In general, if you combine two independent state machines into a single state >machine then the number of states in the compound will be the product of the >number of states in the components. As you said, this is not necessarily true >when a lifecycle is spliced, becuase there is a set of states in the subtype >are only entered when the supertype is in a specific state. Thus you >can add the states rather than multiplying them. OK, you were at the First Principles Theoretician level and I was at the Hacker Engineer level. >Thus the term "splicing" is used to describe the specific case when parallel >state machines machines can be combined additively. To go back to the original >question of this thread, there is no way for the analyst to specify this >within an OOA, thus the achitecture should assume the general case unless >colorations are provided. But doesn't the OOA analyst provide this be defining the events that transition between the sub/super types? Also, the architecture knows that it is dealing with FSMs in sub/super type objects. Therefore it should know that the splicing case is in effect. >> Finally, is it possible you are using "state" in the sense of the overall >> state *of* the FSM rather than a state *within* the FSM? > >For a single state machine, the current state of the FSM is the value of >its current_state attribute. I do not see how this is different to its >current state within the FSM (Please explain). Not relevant anymore. Misconceptions within misconceptions. I don't know what the overall "state" of an FSM might be either; I was just checking to see if you did. >> (3) The instance maps only one state as active at a time and that state may >> be in either the subtype or the supertype. > >What do you mean by an "active state"? My understanding is that a state is >only active at the time that it is entered - i.e. when its action is >executed. After that, the object does nothing (is passive?) until it >recieves another event. Transitions can occur in the subtype without >causing transitions in the supertype (and visa-versa). Imprecision on my part. I should have said Current State. My point was that at any one time there is is only one Current State for the instance and that may be a state in either the subtype FSM or the supertype FSM. H. S. Lahman "There's nothing wrong with me that Teradyne/ATB wouldn't be cured by a capful of Draino." 321 Harrison Av L51 Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Re: Spliced State Models David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: -------------------------------------------------------------------- > LAHMAN@DARWIN.dnet.teradyne.com writes to shlaer-mellor-users: > Imprecision on my part. I should have said Current State. My point was > that at any one time there is is only one Current State for the instance and > that may be a state in either the subtype FSM or the supertype FSM. This is the point of disgreement. By the rules of OOA, as I understand them, every active object has a current_state attribute (OOA96 hides it most of the time). This means that both the supertype and subtype have a current state attribute. (In fact, the subtypes have different current_state attributes which have different attribute-domains). If you attempt to eliminate the current state attribute in the supertype (or subtype) then you must change the attribute-domain whenever you use subtype migration - this could get very messy, especially if assigners are busy checking the current_state of the supertpye whilst the current_state attribute holds a state name from a subtype (of which the assigner has no knowledge). You'd quickly end up in a bad mess. My contention is that the current_state attribute in the supertype does not change when the subtype transitions, because it is a different object. It always has a value, so the supertype object can be said to be in that state. Similarly, the subtype is always in exactly one state (and the set of possible states changes when it migrates). State machines don't just vanish when another object transitions, even when related using a super-sub relationship! I must emphesize that I am talking about the analysis viewpoint. An implementation can happily eliminate attributes if it wants to, provided it can derive an appropriate value on request. > >Thus the term "splicing" is used to describe the specific case when parallel > >state machines machines can be combined additively. To go back to the original > >question of this thread, there is no way for the analyst to specify this > >within an OOA, thus the achitecture should assume the general case unless > >colorations are provided. > > But doesn't the OOA analyst provide this be defining the events that > transition between the sub/super types? Also, the architecture knows that > it is dealing with FSMs in sub/super type objects. Therefore it should know > that the splicing case is in effect. The architecture knows it is dealing with a super-sub situation. It does not know what the valid supertype states are for a subtype transition, nor the valid subtype states for supertype transitions. Thus, unless it is very clever, or has help, it must assume that an event may be delivered to the subtype for any supertype state; and that the supertype can consume events in any subtype state. Polymorphism is specified on a per-object basis, not per-state. Splicing is not always achived by self-directed events, so we cannot use these to determine when splicing occurs. Dave -- David P. Whipp. Not speaking for: ------------------------------------------------------- G.E.C. Plessey Due to transcription and transmission errors, the views Semiconductors expressed here may not reflect even my own opinions! Subject: Re: (SMU) Re: What is a valid S-M Analysis? Jonathan.Monroe1@add.ssw.abbott.com writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Theobald... > What exactly makes Shlaer-Mellor a methodology? That is, > to provide a complete and executable description of the > problem, these models must be produced: information model, > state models, and process models. I've always understood a methodology to be a _collection_ of methods used in the creation and maintenance of software, covering the whole lifecycle. It is a prescibed process which says who does what, when. While the "Modeling the World in Data" and "Object Lifecycles" books describe concepts and notation (as previously mentioned by Tockey) for analysis and design, I would not call them a methodology description, as they omit discussion of large portions of the software lifecycle - requirements elicitation, integration, etc. And as Leon Starr points out in his book, there is a lot more to analysis than just modeling. The closest thing I've seen to a process definition for S-M is the paper, "The Shlaer-Mellor Method", available through PT. It at least prescribes what activities should be performed, what workproducts should be produced, and in what order, for the creation of models and code. Sorry to argue over semantics, but S-M is a method, not a methodology (and Shlaer and Mellor should be referred to as "methodists", not "methodologists" ;) ) Jonathan Monroe Abbott Laboratories North Chicago, IL monroej@ema.abbott.com Subject: Re: (SMU) Paper on Recursive Design Jay Case writes to shlaer-mellor-users: -------------------------------------------------------------------- Fellow SMUGaroos, I just finished my first reading of "Recursive Design of an Application-Independent Architecture", and have only one comment; Outstanding! -------------------------------------------------------------------- Jay Case Tellabs Operations, Inc. Subject: (SMU) Paper on Recursive Design Steve Mellor writes to shlaer-mellor-users: -------------------------------------------------------------------- Dear Jay, You're the first to comment on the paper. Quick work! Thank you very much for the kind words (or should I say 'word'?) This was quite a difficult paper, what with reviewers that don't have our context, lengthy cycles for review and writing, other work (that book, you know) and all the other stuff that happens just to keep things going. Anyway, Sally and I are going to award ourselves one 'smug-on' (that's the basic unit of smugness) for finally getting it out the door and in print. :) Keep in touch, and thanks again. We'll be interested to see what the other 'SMUGaroos' come up with.... -- steve mellor At 12:57 PM 1/24/97 -0600, you wrote: >Jay Case writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >Fellow SMUGaroos, > >I just finished my first reading of "Recursive Design of an >Application-Independent Architecture", and have only one comment; > >Outstanding! > >-------------------------------------------------------------------- >Jay Case >Tellabs Operations, Inc. > > Subject: Re: (SMU) Paper on Recursive Design Brad_Appleton-GBDA001@email.mot.com writes to shlaer-mellor-users: -------------------------------------------------------------------- steve@projtech.com writes: > Steve Mellor writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Dear Jay, > > You're the first to comment on the paper. Quick work! Very quick. I got mine last week and I havent gotten through it all yet. Let me just say however that the majority of the entire January '97 issue of IEEE Software is full of *great* stuff! Steve may not have mentioned it, but besides writing that article with Sally, he and Ralph Johnson basically collected, organized, and reviewed the articles for the entire issue that were focused on Objects, Patterns, and Architectures. That in itself is al also hard work for which Steve and Ralph deserve much praise. So dont just read Steve and Sally's RD article, read all of them. Steve and Ralph did a great job of sheperding them together! -- Brad Appleton | http://www.enteract.com/~bradapp "And miles to go before I sleep." | 1400+ WWW links on CS & Sw-Eng Subject: Re: (SMU) Spliced State Models "Lynch, Chris D. SD" writes to shlaer-mellor-users: -------------------------------------------------------------------- Various posters have recently addressed the difficulty of modeling with multiple state models within one object and looked at philosophical issues with the way such things are formalized. FWIW, I have been getting good results with the following practices: 1) conceptually treat the object and all current subtypes as one instance. I believe this is the PT approach. 2) Implement the whole object tree as a pushdown machine, so that the subtype's event handler supersedes that of the supertype when the object is in one of the subtype's states (i.e., it gets first crack at the incoming events.) If the subtype's event handler receives an event which is *not defined* for the subtype, it passes it up to the supertype and "returns" to that state machine. (If you recognized a recursive descent parser here, give yourself a cigar.) This may seem a little different from PT's published discussions of subtype migration, but I don't see anything which contradicts the PT state modeling formalism. 3) Use a Mealy model. Again, not a fundamental change, just a conflict with popular toolsets! The benefits of this approach are 1) We don't have to deal with the issues related to synchronizing 2 "independent" state machines. As one esmug correspondent wrote, for a real world object, it really seems to *be* one instance. As a practical matter, my experience with the "multiple instance" approach has been that such models can be very clumsy, bristling with all kinds of extra synching machinery unrelated to the analysis. Non-OOA-ers (management and my EE counterparts) seem to prefer the single instance idea, too. 2) The hierarchy of state models can be easily collapsed into one standard Shlaer/Mellor state model if one desires to show equivalence to the standard SMOOA state machine model. ("Exercise left to the reader.") If one objects to the event "pass-up" being in the architecture, one has the option of relaying the event explicitly in the state model. 3) The Mealy machine takes away 99% of those irritating self-directed events that say "done" or "next state". Also, since the transition action routine knows the state where it came *from*, the transitions into a superstate can discriminate between entry from a sibling state and entry via a return from a subtype's state-model. I haven't used this often but it has been very handy at times. 4) No need for polymorphic events. Events don't have to trickle down the object hierarchy to get to the subtype. In past architectures I have used, the overhead of polymorphic events has made us reluctant to subtype based on state (especially when there were lots of internal events--see (3), above). Now the performance impact is much lower. BTW, perhaps someone can tell me of a Shlaer/Mellor toolset which supports this scheme. We are currently hand-coding while evaluating tools on the side. Feedback appreciated. -Chris ------------------------------------------------------------------- Chris Lynch Abbott Ambulatory Infusion Systems (619) 485-7474 San Diego,CA 92128 LYNCHCD@HPD.ABBOTT.COM ------------------------------------------------------------------- Subject: (SMU) Re: the new Architecture article ... Don White writes to shlaer-mellor-users: -------------------------------------------------------------------- Steve and Sally, Good work! Finally more solid footing for those of us that didn't make it to the architecture class. Very good, nicely written, and should probably be required reading at the end of the overview phase of all Project Technology classes. I like the clarity of the overall process of architecture development. The subject is most clearly stated with this level of detail. I like the choice of architecture to be used as an example. The downloadable version of the article should include the "Origin of the Timepoint Architecture' box. I DO wish that the 'Define theory of operation' section gave at least a paragraph to actually define the theory for this example. The current view on page 2, as you are reading it, might be misunderstood to be the current SM view until you get to the Alternative View. Might be better to call it 'the industry view' vs. 'the Shlaer-Mellor view'? I would like to see a better overview of the current main categories of architectures and even the most approximate of statements of their respective advantages/disadvantages. Is this a pipe dream? Are architectures so diverse that they cannot be divided into a few main categories? At worst, the answer to this question would be a welcome addition. Shouldn't definition of conceptual entities include a survey of current solutions to find a 'best fit' if possible? Lastly, and more of a suggestion than a kudo or problem, have you considered sort of a trainer architecture which would operate on a specific and limited example OOA domain like a light switch and light? I know I'm a broken record here, but a simple architecture which could be used to play with ones understanding of OIM and SM's would be WONDERFUL. This would make a grand presentation tool since it would allow for a clear way to show the flexibility of the SMOO by, for instance, adding a switch for a real-world change to the requirements showing that the problem changed, then the models changed, but the architecture didn't. ... Overall, an excellent paper. Thanks! -- donw Subject: Re: (SMU) Re: Spliced State Models peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 10:50 AM 1/24/97 -0500, shlaer-mellor-users@projtech.com wrote: >LAHMAN@DARWIN.dnet.teradyne.com writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >Responding to fontana... After reading your replies to myself and Dave W., I think I understand your position better. >As a general comment on both rules, I tend to agree with Whipp that it is >easier to develop the flow of control if one thinks about the FSMs as being >in separate objects. By its nature splicing implies intimate communications >between the two FSMs, which tends to make one think of them as a single, >merged state machine. I don't agree that splicing is necessarily a giant network across the super/sub hierarchy. Pathfinder's view is that splicing is more like making an #include in the middle of the subtype's state machine. Our implementation of this in our translator creates an individual STT for each subtype - just as if the analyst didn't splice at all. Splicing is a specification convenience that lets us do 2 things: - abstract a sub-network of states in the parent that can be "included" by any child, instead of cloning these common states among children. - define the state action ADFDs once for these common states, instead of cloning the ADFDs as well. H.S. - I'm going to send along our "OOA Modeling Guide" which describes our state model splicing conventions (among other things). We can chat more Tuesday. If anyone else wants an emailed copy, please drop me a line. Thanks. __________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com| | effective solutions for OOA/RD challenges | | Peter J. Fontana voice: 888-OOA-PATH | peterf@pathfindersol.com fax: 508-384-1392 | __________________________________________________| Subject: Re: (SMU) Re: Spliced State Models Neil Lang writes to shlaer-mellor-users: -------------------------------------------------------------------- >David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: >-------------------------------------------------------------------- > In a recent posting Dave says in part: > >If you attempt to eliminate the current state attribute in the supertype >(or subtype) then you must change the attribute-domain whenever you use >subtype migration - this could get very messy, especially if assigners are >busy checking the current_state of the supertpye whilst the current_state >attribute holds a state name from a subtype (of which the assigner has >no knowledge). You'd quickly end up in a bad mess. > Permit a bit of clarification from the Guardian of the OOA rules :-) In OOA96 assigners do _not_ access the (hidden) current state at all; rather each of the objects participating in the competitive relationship has a spcific analyst supplied attribute for use in the assigner protocol These are the attributes used by the assigner to select participating instances (see chapter 7 in the OOA96 report) Hope this helps this discussion from going too far off track. Sorry for the interruption. Neil ......remainder of posting deleted....... ------------------------- Shlaer-Mellor Method ------------------------- Neil Lang Tel: (510) 845-1484 ext.23 Project Technology, Inc. Fax: (510) 845-1075 2560 Ninth Street - Suite 214 email: nlang@projtech.com Berkeley, CA 94710 URL: http://www.projtech.com ----- Improving the Productivity of Real-Time Software Development ----- Subject: (SMU) Real-Time Analysis modeling dippen patel writes to shlaer-mellor-users: -------------------------------------------------------------------- As part of my graduate project I am researching on existing O-O methodologies for modeling real-time requirements. Can I have some information on some of the methodologies and how good they are in modeling real-time requirements. I read some articles on Slaer-Mellor and it doesn't seem to be applicable for real-time systems. I would really appreciate it if anybody could provide me with some information. Thank you. **************************************** SOME GRIN AND BEAR IT OTHERS SMILE AND CHANGE IT ! Dippen Patel email: hbcsc355@huey.csun.edu **************************************** Subject: Re: (SMU) Re: Spliced State Models randyp@primenet.com (Randy D. Picolet) writes to shlaer-mellor-users: -------------------------------------------------------------------- >David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >This is the point of disgreement. By the rules of OOA, as I understand them, >every active object has a current_state attribute (OOA96 hides it most of >the time). This means that both the supertype and subtype have a current state >attribute. (In fact, the subtypes have different current_state attributes which >have different attribute-domains). > Having followed the discussion in this thread for a while, I agree this is the heart of the matter. As you might expect if you read my previous contribution, I'm afraid I couldn't disagree more . Of course, this has the feel of religious debate, so I don't expect I will change any minds. >My contention is that the current_state attribute in the supertype does >not change when the subtype transitions, because it is a different object. >It always has a value, so the supertype object can be said to be in that >state. Similarly, the subtype is always in exactly one state (and the >set of possible states changes when it migrates). State machines don't >just vanish when another object transitions, even when related using >a super-sub relationship! > This seems an awful lot like hierarchical state a la Harel, and introduces all of the complexity of that approach regarding rules for transitions across levels in the heirarchical state. SM are clearly on record as opposed to such an approach because of the desire for minimal analysis constructs and heirarchies based on objects instead of states (see ROAD Volume 1, No. 1 May-June 1994). And there is still the issue of current state. Do we actually introduce an additional attribute in the process of trying to extract out commonality in a supertype? That seems counter-productive, and I would venture to say it also violates the rules of attribution by introducing internal structure and dependencies into the current state attribute itself. >I must emphesize that I am talking about the analysis viewpoint. An >implementation can happily eliminate attributes if it wants to, provided >it can derive an appropriate value on request. > Agreed, the real question is what perspective to take during analysis. OOA91 says "In a subtype-supertype construct, one real-world instance is represented by the combination of an instance of the supertype and an instance of exactly one subtype. In contrast to some object-oriented programming languages, OOA does not permit creating an instance of the supertype without creating an instance of the one subtype, and vice versa." I think this statement is the source of much confusion, and its interpretation the source of the disagreement. Specifically, the exact mechanism by which instances of a supertype are "combined" with instances of a subtype to "represent" a "real-world" instance is never explicitly described. As this statement appears in the chapter on Information Modeling concepts, and prior to a discussion of Lifecycles, I intepret this as meaning the data "representations" are combined, and that each real-world instance requires the simple union of all the attributes of its constituent super/sub-types. The second half of the above quote can just as well be interpreted as imposing rules on the introduction of new types in the heirarchy, enforcing a strict generalization/specialization relationship, and infering what is meant by "type" in the first place. Ultimately, my perspective is guided by my understanding that the _purpose_ of introducing the concept of type heirarchy is simply to "abstract out" common pieces of shared behavior specifications, nothing more, nothing less. More fundamental than this "supertype" abstraction process is the initial concrete abstraction into a simple object/type "of a set of real-world things such that all of the real-world things in the set - the instances - have the same characteristics, and all instances are subject to and comform to the same rules," which is the SM definition of an object. To me, this means that the process of specifying/modelling the rules of behavior (i.e. object or type) of real-world instances is more fundamental than - and logically precendent to - the supertype abstraction process, even though we always iterate through both during analysis. So the questions then become: 1) What is a (minimal and) complete behavior specification from which supertypes can be abstracted? Clearly, the use of rules of attribution and Moore machines provide a sound mathemical basis for the primal "behavior specification" of real-world instances belonging to the object (although I have some questions about how the formal Moore construct is mapped into the object paradigm - but that is the subject for another thread). If two real-world instances cannot be described with the same set of attributes and the same lifecycle (including all actions/outputs), then they are not the same (type of) object. 2) What rules should be applied to the supertype abstraction (and therefore re-combination) process? Here I think the method is both a little fuzzy and overly constrained. In all of the non-splicing cases, the lifecycle spec simply resides in toto at a single node in the heirarchy. This corresponds to an abstraction process of simply siting a complete Moore machine at the most convenient spot to allow the most re-use. For splicing cases, the method imposes the following rules: "Events that cause transitions into or within the common portion of the lifecycle are directed at the supertype object", and "Events that cause transitions into or within the subtype portions of the lifecycle are directed at the subtypes." I assume these rules mean event "specifications" (as opposed to event "instances") and that "directing an event (spec) at a an object (type)" means its identifier label contains that of the object, so that on an OCM, the communication of events appears orderly (all events flowing into a given state model carry that state model's label). The best I can figure, this corresponds to an abstraction process that specifies that a portion of a lifecycle can be abstracted out _only_ if the columns (events) of the STT can be arranged into two groups whose cells each reference mutually exclusive subsets of the states of that model. I have to admit, I really don't understand the rationale for this constraint. It _seems_ like the intent might be to end up with two pieces that each act like stand-alone lifecycle specs (although this is not explicitly stated). But by these rules, the resulting partial lifecycles don't even have to be internally connected. And even if that is an additional (unstated) constraint, the resulting entities still do not (in my mind) qualify as proper independent state models - they may be lacking start/creation states, and they are tightly coupled to each other in that they must correlate splice states/transitions. A partial state model is exactly that, and of little use in any context _other_ than capturing commonality of lifecyle definition elements across subtypes. Just as problematic, these contraints prevent reuse in many very simple scenarios that differ only by small details, but cannot be fit into the above pattern. For example, consider several long born-and-die lifecycles driven by a simple repetitive input event that differ only in the number of states, or that have slightly different orders. Unless I am missing some overriding concern, this arbitrarily reduces the utility of the technique to a very small number of situations (by comparison). Remembering that the goal (my goal anyway) of splicing is capturing significant re-use of shared behavioral specification components thereby eliminating maintenance of dual specs, I refer you again to my previous description in this thread of how I view the splicing paradigm, claiming more flexibility, no additional analysis constructs, straightforward architecture implementation, and conceptual simplicity. Returning to the original question of this thread, given the approach I've outlined, I believe there is no additional representation needed to support splicing. The architecture simply always splices/overlays the various lifecycle component definitions. It is the responsibility of the analyst to ensure the result is a valid state model. I should note, I have not had my thoughts or approaches "limited" or "contaminated" by the use of any commercial tools. Rather, I have had to develope both architectures and translation tools from scratch, based only on my interpretations of the published method. As a result, there are probably many issues I have not encountered. Of course, I look forward to having my understanding of the world corrected or expanded by anyone reading this thread. Cheers... ;-) Subject: (SMU) Re: Soliced State Models LAHMAN@DARWIN.dnet.teradyne.com writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Whipp... Regarding number of Current States for an object. >This is the point of disgreement. By the rules of OOA, as I understand them, >every active object has a current_state attribute (OOA96 hides it most of >the time). This means that both the supertype and subtype have a current >state attribute. (In fact, the subtypes have different current_state >attributes which have different attribute-domains). > >If you attempt to eliminate the current state attribute in the supertype >(or subtype) then you must change the attribute-domain whenever you use >subtype migration - this could get very messy, especially if assigners are >busy checking the current_state of the supertpye whilst the current_state >attribute holds a state name from a subtype (of which the assigner has >no knowledge). You'd quickly end up in a bad mess. > >My contention is that the current_state attribute in the supertype does >not change when the subtype transitions, because it is a different object. >It always has a value, so the supertype object can be said to be in that >state. Similarly, the subtype is always in exactly one state (and the >set of possible states changes when it migrates). State machines don't >just vanish when another object transitions, even when related using >a super-sub relationship! Yes, it would appear that we are in disagreement here. I think this will have to be resolved by the Gurus. The basis for my view is twofold. First, the description of polymorphism on p. 215 of OL:MWS says, "At design time a polymorphic invocation is an invocation or one of a set of instance-based published operations, where *all* of the published operations in the set have the same module name but differing class names." (Emphasis mine.) As I read this it seems pretty clear that there is one instance and all of its operations are in a single state machine, though the individual operations may be named after differnt classes. Ergo, one Current State. The second basis is that the discussion of splicing on 59 & 60 of OL:MWS seems to be talking about a notational convenience for describing behavior that is shared by subtype state machines. They start with the premise that only the subtypes have state machines and they merely extract the common behavior in the notation to eliminate redundancy. I see this as very analogous to the way depth-first loops in ADFDs are described in OOA96. In this interpretation the redundant behavior has to be placed somewhere and the supertype just happens to be convenient. This would in no way infer that the supertpye is an independent state machine with and independent (i.e., simultaneous state with the subtytpes) Current State. I do not see Current State in the supertype as being indicative of an active object. As a general rule, I see super/subtyping in S-M as being strictly data inheritance with no implications about functional inheritance. Thus the appearance of Current State in the supertype merely reflects the fact that all subtypes have an attribute of that name. Finally, the idea of two or more Current States existing at the same time implies separate instances to me. I think instantiating multiple instances for the same concrete entity would be confusing at best and illegal at worst. I must emphesize that I am talking about the analysis viewpoint. An implementation can happily eliminate attributes if it wants to, provided it can derive an appropriate value on request. Regarding whether the architecture should supply an additive structure: >The architecture knows it is dealing with a super-sub situation. It does not >know what the valid supertype states are for a subtype transition, nor the >valid subtype states for supertype transitions. Thus, unless it is very >clever, or has help, it must assume that an event may be delivered to the >subtype for any supertype state; and that the supertype can consume events >in any subtype state. Polymorphism is specified on a per-object basis, not >per-state. Splicing is not always achived by self-directed events, so we >cannot use these to determine when splicing occurs. Good point. The tools usually fix this problem by asking for more information. It would be easy to fix in the OOA, though, with an extension to the polymorphic event translation table. If one added the valid state of origin for the polymorphic event and forced all FSM-crossing events through the table, there would be sufficient information. I think this would be very desirable because would allow error checking of can't-happen tranistions. H. S. Lahman "There's nothing wrong with me that Teradyne/ATB wouldn't be cured by a capful of Draino." 321 Harrison Av L51 Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) Re: Spliced State Models LAHMAN@DARWIN.dnet.teradyne.com writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Lang... >Hope this helps this discussion from going too far off track. But you didn't answer the biggy! If I have an instance where both the supertype and the subtype have a state machine, how many Current States are there? Select one: A. 1 Current State which can be in either FSM at a given moment in time. B. 2 Current States, one in each FSM. I.e., you were implicitly agreeing with Whipp. C. Some other answer that I don't want to know about because it will terminally confuse me. H. S. Lahman "There's nothing wrong with me that Teradyne/ATB wouldn't be cured by a capful of Draino." 321 Harrison Av L51 Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) Re: Real-Time Analysis Modelling LAHMAN@DARWIN.dnet.teradyne.com writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to patel... >As part of my graduate project I am researching on existing O-O >methodologies for modeling real-time requirements. Can I have some >information on some of the methodologies and how good they are in modeling >real-time requirements. I read some articles on Slaer-Mellor and it doesn't >seem to be applicable for real-time systems. I would really appreciate it >if anybody could provide me with some information. Thank you. I think you have been reading the wrong articles. They must have been proganda from the UML camp. When S-M was developed it was specifically targetted on real-time/embedded systems. Today the vast majority of users are R-T/E systems people. Probably the single thing that demonstrates this is that in S-M it is not possible to describe *any* flow of control without using a finite state machine. It would be more appropriate to question whether S-M can be used for applications *other* than R-T/E, given its heavy dependence on FSMs. (I would argue that it *is* because FSMs are a very general approach to defining flow of control.) I think you want to start your research with the bibles by Sally Shlaer and Steve Mellor: "Object Oriented Systems Analysis" and "Object Lifecycles", both from Prentice-Hall. Some points to note when reading these books: S-M distinguishes software Analysis from software Design in a somewhat unusual way. In an S-M Analysis one develops a complete, abstract solution to the problem that is independent of the implementation environment. (This also reflects the R-T/E origins because in that environement the hardware and the platform often changes and you do not want the basic logic to be affected in the inevitable ports.) Since the Analysis is an abstract solution to the problem, the actual software must be created in a separate development phase called Translation. This is a cross between softare Design and Implementation with most of the emphasis on the implementation side. It is quite literally a translation of the abstract Analysis solution into code. There is a formalism called Recursive Design within the methodology to do this. S-M achieves low level (class) decoupling and data encapsulation using the pure message paradigm with Moore model FSMs. S-M achieves high level decoupling, encapsulation, and reuse through the concept of Domains with the different, message-based communication abstraction. Thus S-M does little to support class reuse but it provides a specific approach for large scale resue. The S-M notation is a mathematically consistent and unambiguous notation that is suitable for automatic code generation. There are several tools on the market that will do 100% code code generation for Analysis Domains. (Because the Recursive Design formalism is still under development, the tools tend not to do 100% code generation for the bridges between Domains.) S-M starts with a data model, which looks very much like other methodologies' class diagrams. It then adds flow of control through the development of FSMs for each data object with nontrivial functionality. An object's FSM represents the encapsulation of the object's data processes and its interface to the outside world. This is analogous to the encapsulation of methods with objects in the class interfaces of other methodologies. The details of the processing are then captured in an Action Data Flow Diagram for each state in the Moore FSM. H. S. Lahman "There's nothing wrong with me that Teradyne/ATB wouldn't be cured by a capful of Draino." 321 Harrison Av L51 Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Re: Soliced State Models SVick25704@aol.com writes to shlaer-mellor-users: -------------------------------------------------------------------- remove Subject: Re: (SMU) Re: Soliced State Models David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: -------------------------------------------------------------------- > LAHMAN@DARWIN.dnet.teradyne.com writes to shlaer-mellor-users: > Yes, it would appear that we are in disagreement here. I think this will > have to be resolved by the Gurus. The basis for my view is twofold. First, > the description of polymorphism on p. 215 of OL:MWS says, "At design time a > polymorphic invocation is an invocation or one of a set of instance-based > published operations, where *all* of the published operations in the set > have the same module name but differing class names." (Emphasis mine.) As > I read this it seems pretty clear that there is one instance and all of its > operations are in a single state machine, though the individual operations > may be named after differnt classes. Ergo, one Current State. But that section is dealing with design, not analysis; and is dealing with classes, not objects. The is no requirement that polymorphic events be implemented using class-polymorphism. And class polymorphism is useful for things other than polymorphic events (mainly inter-domain mappings). We don't use class-polymorphism for polymorphic events because it gets difficult (becuase of our independent-objects viewpoint). I am probably biased by interpretations by both Kennedy Carter and SES, but I do not view an OOA subtype relationship as corresponding to inherritance (and yes, I have read section 9.6 of OL:MWS) > > The second basis is that the discussion of splicing on 59 & 60 of OL:MWS > seems to be talking about a notational convenience for describing behavior > that is shared by subtype state machines. Speaking of page 60, let me elaborate how my view implements figure 3.10.4. Hopefully this is already understood, but I'd just like to make sure. I will show that my interpretation is consistant with the rules at the end of section 3.10. Consider the transition leading into state "II". by rule1, these events must be in the supertpye (not the subtype). I therefore say that both cause a transition from state "I" to state "II" (and could both be the same event). The rules imply that this event must be a can't happen when the subtype is in states A1, B1 & B2 so there is no danger of this transition occuring at the wrong time. Therefore the supertype lifecycle is complete, remaining in state "I" while the subtype is busy. Similarly, the transitions leading into states A1 & B1 must be in the subtype (rule2). They are not creation events because the subtype may already exist. So I make the transitions come from states A2 and B3 respectively (again, the events must be "can't happen" when the supertype is busy). So all the lifecycles are complete. I have always found that the states "I, A2 and B3 will naturally exist while the tread of control weaves its way through the object participating object(s). It is not artificial to leave them as the current state while processing is elsewhere. Formalising spliced lifecycles in this way means that no additional concepts are needed to realise splicing. This may be why some tool vendors have used this approach. Given The rules at the end of section 3.10, this model is equivelent to one where real spicing is used. Randy D. Picolet wrote: > This seems an awful lot like hierarchical state a la Harel, and introduces > all of the complexity of that approach regarding rules for transitions > across levels in the heirarchical state. SM are clearly on record as > opposed to such an approach because of the desire for minimal analysis > constructs and heirarchies based on objects instead of states (see > ROAD Volume 1, No. 1 May-June 1994). It isn't as much like Harrel as I would sometimes like. Harrel-style superstates can only be realised by subtype migration. The difference is that transitions in the supertype do not require transitions in the subtype. Yes, SM should be a minimal notation. Thats why I don't want to add additional constructs to support incomplete lifecycles and splicing. The OOA96 rules of FSMs and polymorphism are adequate to model specialisations of behaviour in subtypes. Now extra complexity is required. > Agreed, the real question is what perspective to take during analysis. > OOA91 says "In a subtype-supertype construct, one real-world instance is > represented by the combination of an instance of the supertype and an > instance of exactly one subtype." I would use this quote to support my view also:-). One real-world instance is *COMBINATION* of one supertype instance ***AND*** one subtype instance. I read this as two SM instances representing one real-world instance (more if the supertype tree is deeper). Dave. p.s. yes, this could get a bit religious. This obviously needs clarification from PT. -- David P. Whipp. Not speaking for: ------------------------------------------------------- G.E.C. Plessey Due to transcription and transmission errors, the views Semiconductors expressed here may not reflect even my own opinions! Subject: Re: (SMU) Re: Spliced State Models J.W.Terrell@nortel.co.uk writes to shlaer-mellor-users: -------------------------------------------------------------------- > peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: > -------------------------------------------------------------------- > I don't agree that splicing is necessarily a giant network across the > super/sub hierarchy. Pathfinder's view is that splicing is more like making > an #include in the middle of the subtype's state machine. I agree entirely. I cannot accept the alternate view. In view of the polarised nature of this debate, would PT please offer some guidance? Regards, Jeff. -- Jeff Terrell Nortel, London Rd, Harlow, Essex, UK. +44 (0)1279 405870 J.W.Terrell@nortel.co.uk Subject: Re: (SMU) Re: Soliced State Models Tony Humphrey-Lewis writes to shlaer-mellor-users: -------------------------------------------------------------------- On Mon, 27 Jan 1997, Dave Whipp wrote: > David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > > LAHMAN@DARWIN.dnet.teradyne.com writes to shlaer-mellor-users: > > > Yes, it would appear that we are in disagreement here. I think this will > > have to be resolved by the Gurus. The basis for my view is twofold. First, > > the description of polymorphism on p. 215 of OL:MWS says, "At design time a > > polymorphic invocation is an invocation or one of a set of instance-based > > published operations, where *all* of the published operations in the set > > have the same module name but differing class names." (Emphasis mine.) As > > I read this it seems pretty clear that there is one instance and all of its > > operations are in a single state machine, though the individual operations > > may be named after differnt classes. Ergo, one Current State. > > But that section is dealing with design, not analysis; and is dealing with > classes, not objects. The is no requirement that polymorphic events be > implemented using class-polymorphism. And class polymorphism is useful > for things other than polymorphic events (mainly inter-domain mappings). > > We don't use class-polymorphism for polymorphic events because it gets > difficult (becuase of our independent-objects viewpoint). I am probably > biased by interpretations by both Kennedy Carter and SES, but I do > not view an OOA subtype relationship as corresponding to inherritance > (and yes, I have read section 9.6 of OL:MWS) > Well said Dave. FWIW when I consider super/sub types I think of them as two distict instances not one and if splicing their state models there are two current state attributes. We seem to do splicing on this basis quite well. Like Dave I also don't view an OOA subtype relationship as corresponding to inheritance. > > Agreed, the real question is what perspective to take during analysis. > > OOA91 says "In a subtype-supertype construct, one real-world instance is > > represented by the combination of an instance of the supertype and an > > instance of exactly one subtype." > > I would use this quote to support my view also:-). One real-world instance > is *COMBINATION* of one supertype instance ***AND*** one subtype instance. > I read this as two SM instances representing one real-world instance > (more if the supertype tree is deeper). > I'd take Dave's translation 8-) here. +----------------------------------------------------+ | Anthony Humphrey-Lewis Software Development | | GPT Ltd. | | email: hlewisa@ncp.gpt.co.uk Business Systems | | Technology Drive | | Beeston | | Notts. NG9 1LA | | United Kingdom | | Telephone: +44 115 943 4290 Fax: +44 115 943 3805 | +----------------------------------------------------+ Subject: (SMU) Modeling Hiearchical Allen Theobald writes to shlaer-mellor-users: -------------------------------------------------------------------- Greetings SMUGers! Is it possible to model entities that are hierarchical in nature rather than relational in nature? For example, a family tree. This is parent/child (hierarchical) and not relational. How would this be modeled? To make it interesting, lets allow a person to have more than one spouse, and sire more than one offspring. What does the OIM look like? I have a hierarchical model that I wish to make S-M. Rather than try to provide all the relevant data, I figured everyone was familiar with family trees. Input provided on this example will help me immensely with my problem. Much thanks, Allen Subject: (SMU) Re: Spliced State Models LAHMAN@DARWIN.dnet.teradyne.com writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Whipp... Regarding OL:MWS, p. 215: >But that section is dealing with design, not analysis; and is dealing with >classes, not objects. The is no requirement that polymorphic events be >implemented using class-polymorphism. And class polymorphism is useful >for things other than polymorphic events (mainly inter-domain mappings). True, but what I am inferring is that this explanation is a direct, natural outgrowth of the OOA concept rather than a collapse of a more general OOA concept through an unspecified translation step. To get to that design from your interpreation of the OOA is nontrivial and I am assuming that was not left as an exercise for the reader. > The second basis is that the discussion of splicing on 59 & 60 of OL:MWS > seems to be talking about a notational convenience for describing behavior > that is shared by subtype state machines. Regarding the interpretation of section 3.10: >Consider the transition leading into state "II". by rule1, these events must >be in the supertpye (not the subtype). I therefore say that both cause a >transition from state "I" to state "II" (and could both be the same event). >The rules imply that this event must be a can't happen when the subtype is >in states A1, B1 & B2 so there is no danger of this transition occuring at >the wrong time. Therefore the supertype lifecycle is complete, remaining in >state "I" while the subtype is busy. Hmmm. While I understand how that interpretation works, it just strikes me that inferring an equivalent I -> II event in an independent state machine is, at best, counter-intuitive because the overall FSM (i.e., when it was a pure subtype state machine before extracting the common behavior) would make such an event a can't-happen *always*. To introduce such an event when extracting the common behavior just seems to me to be an unnecesary architectural complication (two FSMs to be managed for a single instance) compared to the idea of a single FSM with one Current State that is notationally split into two patrs. Clearly we are not going to get any further on this until there is some clarification form PT. I believe both interpretations could be made to work consistently; we just don't know which one PT had in mind. At least we have identified are area that needs some clarification in the next edition. H. S. Lahman "There's nothing wrong with me that Teradyne/ATB wouldn't be cured by a capful of Draino." 321 Harrison Av L51 Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) Intent of Spliced State Models Sally Shlaer writes to shlaer-mellor-users: -------------------------------------------------------------------- I think I should have chimed in earlier, but . . . The intent of spliced state models was only to provide a convenient way to deal with the situation where there are one or more actions common to the subtypes. That is, continuing with the philosophy of 'one fact in one place', we did not want the analyst to have to replicate the common actions. Hence, as HS points out, the supertype was just a convenient place to hang the common actions. There was no intention to imply that the supertype had a true FSM/current state attribute. We did not have in mind a case where there were true FSMs at both the subtype and supertype level (the jury is still out on that one; see OOA96). However, as I have been reading the discussion (and had a look back at Object Lifecycles), I can see that the description was subject to multiple interpretations. Very sorry about that -- we do try to be clear, but it is obvious we didn't make it on this one! I quote HS below in case you find his explanation clearer than mine. Also, Peter's statement about using #include may work better for some readers. With apologies for muddy writing, Sally At 12:05 PM 1/26/97 -0500, >LAHMAN@DARWIN.dnet.teradyne.com writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >The second basis is that the discussion of splicing on 59 & 60 of OL:MWS >seems to be talking about a notational convenience for describing behavior >that is shared by subtype state machines. They start with the premise that >only the subtypes have state machines and they merely extract the common >behavior in the notation to eliminate redundancy. I see this as very >analogous to the way depth-first loops in ADFDs are described in OOA96. In >this interpretation the redundant behavior has to be placed somewhere and >the supertype just happens to be convenient. This would in no way infer >that the supertpye is an independent state machine with and independent >(i.e., simultaneous state with the subtytpes) Current State. > >I do not see Current State in the supertype as being indicative of an active >object. As a general rule, I see super/subtyping in S-M as being strictly >data inheritance with no implications about functional inheritance. Thus >the appearance of Current State in the supertype merely reflects the fact >that all subtypes have an attribute of that name. > >Finally, the idea of two or more Current States existing at the same time >implies separate instances to me. I think instantiating multiple instances >for the same concrete entity would be confusing at best and illegal at worst. > Subject: Re: (SMU) Spliced State Models randyp@primenet.com (Randy D. Picolet) writes to shlaer-mellor-users: -------------------------------------------------------------------- >Tony Humphrey-Lewis writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >> David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: >> -------------------------------------------------------------------- >> >> We don't use class-polymorphism for polymorphic events because it gets >> difficult (becuase of our independent-objects viewpoint). I am probably >> biased by interpretations by both Kennedy Carter and SES, but I do >> not view an OOA subtype relationship as corresponding to inherritance >> (and yes, I have read section 9.6 of OL:MWS) >> > >Well said Dave. FWIW when I consider super/sub types I think of them as >two distict instances not one and if splicing their state models there are >two current state attributes. We seem to do splicing on this basis quite >well. > >Like Dave I also don't view an OOA subtype relationship as corresponding >to inheritance. > > > >> > Agreed, the real question is what perspective to take during analysis. >> > OOA91 says "In a subtype-supertype construct, one real-world instance is >> > represented by the combination of an instance of the supertype and an >> > instance of exactly one subtype." >> >> I would use this quote to support my view also:-). One real-world instance >> is *COMBINATION* of one supertype instance ***AND*** one subtype instance. >> I read this as two SM instances representing one real-world instance >> (more if the supertype tree is deeper). >> > >I'd take Dave's translation 8-) here. > I respect your interpretation, and can easily see how it can be arrived at from all of the arguments presented. One question whose answer might help me to better understand your perspective is this: if you more easily think about these super- and sub-type instances as having separate state attributes and independent lifecycle topologies, where the subtype is constrained to live its entire existence within a single state of the supertype, then what is the additional motivating factor for modeling this as a super-sub relationship rather than a simple 1:1c on the IM (with appropriate event communication on the OCM), thus avoiding the whole problem of splicing? (I.e. the delegation versus inheritance argument...) I agree with others' comments that resolution on this by PT is needed, as I have seen at least three distinct but reasonable interpretations of the method, all of which have required either additions or changes to the method to be self-consistent. I believe this to be the symptom of a more fundamental issue than simple notation constructs: what is the formal definition of type, sub-type, super-type, and the type relationship? We need the same level of in-depth treatment as has been given instance relationships... Is a "supertype lifecycle" a formal concept? If so, is it still a Moore machine or some other construct, what are the rules of its formation (internal connectedness?), and how does it relate to a (presumably flattened) subtype Moore lifecycle? Is a "splice state" a formal concept? And so on. Cheers! Subject: (SMU) Re: Modeling Hierarchical LAHMAN@DARWIN.dnet.teradyne.com writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Theobald... >Is it possible to model entities that are hierarchical in >nature rather than relational in nature? For example, a >family tree. This is parent/child (hierarchical) and not >relational. How would this be modeled? To make it interesting, >lets allow a person to have more than one spouse, and sire more >than one offspring. What does the OIM look like? You may get a couple of slightly different examples of this because there is no "best" way to do it. In general hierarchical aspects are captured in the relationships of the Information Model themselves. Let's assume a more traditional form of polygamy: SPOUSE | | is-a +----------------+---------------------+ | | | R1 obeys | WIFE <<----------------------------> HUSBAND is ^ is married to ^ is loved | | supported by | R2 | by V | V bore R3 | CHILD <<------------------------------+ sired We subtype off SPOUSE to eliminate swinging singles, etc. so that HUSBAND and WIFE represent an active wedlock relationship. [If only parenting is of interest we would need somewhat different objects, like DEADBEAT DAD.] Both HUSBAND and WIFE have relationships to a CHILD that describe the hierarchy; in this case a WIFE bore the child and a HUSBAND sired it. The details of the particular instances of the hierarchy (i.e., exactly which WIFE and HUSBAND are the parents of a particular CHILD) are resolved through the relationship identifiers. For example, a WIFE object would have an attribute that identified her particular HUSBAND. Similarly, a CHILD would have a referential attribute for both the WIFE and the HUSBAND. Thus, for example, to find all the CHILDren of a particular HUSBAND sired through a particular WIFE, one could navigate R3 to find all the CHILD instances with that HUSBAND and then filter these for the ones that also had that WIFE as a mother. This is essentially walking a hierarchy tree. The next question is: how does one handle a hierarchy with multiple levels? This is elegantly handled with a new relationship, R4, between CHILD and SPOUSE. This relationship might represent something like, "a CHILD becomes a SPOUSE". (With a conditional relationship at the SPOUSE end in all practicality for this case.) If we don't care if these people are actually alive, then this model could be used to generate an arbitrarily deep geneology. The trick is that the SPOUSE linked to CHILD through R4 would be a different instance than either of the two SPOUSEs that begat that CHILD. Thus you navigate the tree as: CHILD -> R4 -> SPOUSE -> R1 -> other SPOUSE -> R3/R2 -> grand CHILD, etc. H. S. Lahman "There's nothing wrong with me that Teradyne/ATB wouldn't be cured by a capful of Draino." 321 Harrison Av L51 Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Spliced State Models David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: -------------------------------------------------------------------- randyp@primenet.com (Randy D. Picolet) writes to shlaer-mellor-users: > I respect your interpretation, and can easily see how it can be arrived at > from all of the arguments presented. One question whose answer might help me > to better understand your perspective is this: if you more easily think about > these super- and sub-type instances as having separate state attributes and > independent lifecycle topologies, where the subtype is constrained to > live its entire existence within a single state of the supertype, then what > is the additional motivating factor for modeling this as a super-sub > relationship rather than a simple 1:1c on the IM (with appropriate event > communication on the OCM), thus avoiding the whole problem of splicing? > (I.e. the delegation versus inheritance argument...) I have read Sally's clarification, and will attempt to answer this question in light of that clarification. I think we are all agreed that the purpose of splicing is to allow lifecycle portions that are common to many lifecycles to be factored out into a single place. All the interpretations allow this. The advantage that subtyping has over 1:c relationships is that event polymorphism is allowed. Thus other objcts can direct all events at the supertype, and needn't know which subtype is currently instantiated. > where the subtype is constrained to > live its entire existence within a single state of the supertype This is not quite what I am saying. I am saying that the model is constructed so that the subtype only transitions when the supertype is specific states. This requires no additional concepts, because the events that would cause it to transition on other occasions simply can't happen ("Can't happen" is not a constraint, its an assertion). As I have said, given the constraints of OL:MWS-3.10, my interpretation and PT's can be shown to be equivalent. This is important because tools such as SES/Objectbench (and, I believe, KC's IOOA - I stand to be corrected) do not support the "#include" view of splicing. They support multiple state machines with polymorphic events delivered to where they are used. Another point is the fact that I keep having to say "constrained". By constraining the multiple-lifecycle interpretation, it degrades to the PT intention. You can do interesting things if you relax those constraints. Dave. -- David P. Whipp. Not speaking for: ------------------------------------------------------- G.E.C. Plessey Due to transcription and transmission errors, the views Semiconductors expressed here may not reflect even my own opinions! Subject: (SMU) ADFD Vs Action Language smadan@panasonic.atlanta.com (Madan, Steve) writes to shlaer-mellor-users: -------------------------------------------------------------------- I am fairly new to the SM methodology, and have been trying to read all the literature and books that I can get my hands on. In the "Object Lifecycles" book, ADFD was introduced as a way to formulate the action process that occurs within a state. Even OOA96 has a chapter augmenting and updating the book's method, however, all of the Top end CASE Tools vendors are leaning towards the Action Language and shying away from ADFD's. I have yet to see any sort of formalism describing the Action Language or any reason for its popular choice. *********************************************************************** Steve Madan MCC Panasonic smadan@panasonic.atlanta.com 1225 Northbrook Parkway Phone: (770) 338-6120 Suite 2-364 FAX: (770) 338-6238 Suwanee, GA 30174 *********************************************************************** Subject: (SMU) Gratitude Allen Theobald writes to shlaer-mellor-users: -------------------------------------------------------------------- Greetings! I would just like to take a moment to express my appreciation at all the help I receive from the participants of this group. The answers I receive are very well thought out and are extremely helpful to me. Keep up the good work! Maybe soon I will lurk no longer, but be able to contribute as you have done to me. Thanks, Allen Subject: Re: (SMU) ADFD Vs Action Language "John D. Yeager" writes to shlaer-mellor-users: -------------------------------------------------------------------- Often the rationale for end users favoring action languages is two-fold. In the first place, they are more comfortable writing code (which most of the action languages really are -- they tend to include design decisions such as process ordering, loop ordering and shortcuts, etc.). A second reason is the fact that under most GUI systems, it is much faster to type in a sequence of four statements than to draw four process bubbles, label them, describe them, connect them, and label the flows. John Yeager Cross-Product Architecture Lucent Technologies, Inc. johnyeager@lucent.com Business Communications Systems voice: (908) 957-3085 200 Laurel Ave, 4C-514 fax: (908) 957-4142 Middletown, NJ 07748 Subject: (SMU) Interpreting Referential Attributes Allen Theobald writes to shlaer-mellor-users: -------------------------------------------------------------------- Hello SMUGies! Please interpret the referential attributes for this model. It comes from Leon Starr's book, "How to Build Shlaer-Mellor Object Models", page 28. It models token ring networks with token ring interfaces. Interfaces are numbered uniquely within a Ring Net.ID rather than uniquely across all Ring Nets. is Ring Net contained in c Interface * ID <-------R1--------->> * ID c c contains * Ring Net ID(R1,R2) <-- precedes - Next Interface ID(R2) | | | | | ---------R2------------ I understand the referential attribute (R2) for Next Interface.ID, but what does it mean to have a referential attribute (R1,R2) on Ring Net.ID? Obviously Ring Net.ID comes from the Ring Net object. What does R2 have to do with it? What does (R1,R2) mean? How is R2 formalized? Thanks a bunch! Allen Subject: Re: (SMU) ADFD Vs Action Language "John D. Yeager" writes to shlaer-mellor-users: -------------------------------------------------------------------- As a followup to my comments on why many end-users seem to prefer action languages, I would like to see the development of an action language which is isomorphic to the ADFD. That is, 1. each statement of the language is a process "bubble" 2. statement execution is unordered and potentially parallel where not constrained by data/process flows (note the ADFD execution model does not make clear the serialization of multiple processes within a single ADFD which access the same data store; I have favored a definition of the language such that any access of a single object's data is considered atomic, but searches are not -- the search would be guaranteed to find the instance if existed before and after the search with the same value of searched attributes for which being searched for). 3. execution of loops for single data processes across multiple item dataflows is implicit and order/parallelism will be architecture (and coloring) defined Thus figure 6.2.4 of OL:MtWiS would look like TR.1 Create temperature ramp(Batch Id, End Time, End Temperature, Timer Id, Current Time; Ramp Id) TIM.3 Create timer(;Timer Id) TR.3 Generate TR11(Ramp Id) TR.4 Set start temperature(Ramp Id, Start Temperature<=Actual Temperature) CT.1 Find tmperature of tank(Tank Id; Actual Temperature) B.1 Find tank for batch(Batch Id;Tank Id) For a more complicated example Figure 6.2.7 // A pre-OOA96 process; set state model state TR.9 Set status(Ramp ID, status<="controlling") /* * If complete, signal completion */ TR.7 Determine if ramp complete(Ramp Id, Current Time;;; ?complete=>TR.7 complete, ?not complete=>TR.7 not complete) TR.11 Generate TR12(Ramp ID;;?TR.7 complete) // Input conditional CF /* * If not complete schedule next wakeup */ // The following two processes are pre-OOA 96 TR.12 Make timer parameters(Ramp Id; Timer Id, time remaining<=10sec, event label<=TR13, instance id<=Ramp Id) TIM.1 Generate TIM1(Timer Id, time remaining, event label, instance id) /* * If not complete, manage temperature */ TR.5 Find batch for this temperature ramp(Ramp Id; Batch Id; ?TR.7 not complete) TR.8 Compute desired temperature(Ramp Id; Desired Temperature; ?TR.7 not complete) B.1 Find tank for batch(Batch Id; Tank Id) CT.1 Find temperature of tank(Tank Id; Actual Temperature) CT.2 Find heater of tank(Tank Id; Heater Id) TR.10 Determine if hot enough(Desired Temperature, Actual Temperature; ;; ?not hot enough, ?hot enough) H.1 Generate H20(Heater Id;;?not hot enough) H.2 Generate H21(Heater Id;;?hot enough) Anyway this should get te idea across. Obviously, one needs to make clear enough which flows are conditional (the ?), the mapping from expected "parameters" to a process and the data flows themselves, etc. There would need to be clear rules for flows of sequences, rules for when multiple processes can write the same output flows (the OOA96 joining rules) and the understanding that processes may be identical even if the number and type of conditional *input* flows are not the same. Anyway, I look forward to hearing why this won't work. John Yeager Cross-Product Architecture Lucent Technologies, Inc. johnyeager@lucent.com Business Communications Systems voice: (908) 957-3085 200 Laurel Ave, 4C-514 fax: (908) 957-4142 Middletown, NJ 07748 Subject: (SMU) RD Article Observations Michael Hendry writes to shlaer-mellor-users: -------------------------------------------------------------------- After reading the "Recursive Design of an Application-Independent Architecture" article (several times) I offer the follow observations for discussion or clarification. 1) In the PT RD class part of the RD process was to define rules for translating formal OOA elements (ie: Objects, Attributes, etc) into Architecture elements. The mechanisms of the Architecture needed to enforce the OOA execution paradigm. This seemed to be a central theme of the RD process that ensured continuity from the Analysis and simulation phase to the design and implementation phase. In the article this concept is not brought to the forefront. One could infer this from the "Populate the architecture" paragraph, but considering the emphasis given in previous RD literature I wonder if it is being de-emphasized. 2) Again from the PT RD class, archetypes were used as patterns that enforced the rules for translating formal OOA elements into Design elements. The archetypes were applied to the Application OOA model to produce the specific design elements to meet the analysis' needs. Instantiation of the instances of the design was done at initialization time. The article seems to define archetypes for patterns defined in the Architecture OOA model. These are then applied to the Architecture instance data. Instead of having place holders for the OOA formalism schema they have place holders for the values of Architecture instance data. This seems to be a shift in the use of Archetypes. 3) Since archetypes are applied to Architecture instance data there seems to be a new non-trivial step of translating Application instance data into Architecture instance data. 4) In the example KernelTask archetype in figure 2 there is the following construct: ('Case ' TimePointID ':' ChoreList 'Endcase')* The * indicates everything within the parenthesis is iterated for each related ChoreList. I have two questions here. 4a) Since 'Endcase' is inside the parenthesis why does it not appear more than once in the generated code? 4b) A name in an archetype is either another archetype or an attribute of the object for which the archetype is defined. (from "Building archetypes" paragraph) Does this mean that TimePointID is another archetype, since it is not an attribute of KernelTask? ************************************** Michael J. Hendry Sundstrand Aerospace MJHendry@snds.com ************************************** --------------------------------------------------- Michael J. Hendry Sundstrand Aerospace Rockford, IL Dept. 749-6 ph. (815)394-3387 fax (815)394-2497 Internet address: MJHendry@snds.com --------------------------------------------------- Subject: Re: (SMU) Interpreting Referential Attributes hogan@mmc1001.lmtas.lmco.com (Bary D. Hogan) writes to shlaer-mellor-users: -------------------------------------------------------------------- > Allen Theobald writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Hello SMUGies! > > Please interpret the referential attributes for this model. It comes > from Leon Starr's book, "How to Build Shlaer-Mellor Object Models", > page 28. It models token ring networks with token ring interfaces. > Interfaces are numbered uniquely within a Ring Net.ID rather than > uniquely across all Ring Nets. > > > is > Ring Net contained in c Interface > * ID <-------R1--------->> * ID c > c contains * Ring Net ID(R1,R2) <-- precedes > - Next Interface ID(R2) | > | | > | | > ---------R2------------ > > I understand the referential attribute (R2) for Next Interface.ID, but > what does it mean to have a referential attribute (R1,R2) on Ring > Net.ID? Obviously Ring Net.ID comes from the Ring Net object. What > does R2 have to do with it? What does (R1,R2) mean? How is R2 > formalized? Having (R1,R2) on the attribute just shows that the attribute formalizes more than one relationship. Formalizing R2 with Next_Interface_ID *and* Ring_Net_ID signifies the fact that the next Interface will always be in the same Ring Net. Notice that an instance of Interface cannot be identified by a single attribute. It takes a combination of ID and Ring Net ID to uniquely identify an instance. Similarily, to formalize the relationship from an instance of Interface to another instance of Interface, it takes two attributes (Ring_Net_ID and Next_Interface_ID). If just Next_Interface_ID were used, then it could NOT uniquely identify the correct instance of Interface. A good way to visualize this is to create a table of instance data, as shown in Figure 2.2. However, I think there is an error in the table possibly causing confusion. It appears that the attribute values in the first two columns are transposed. According to the picture, Interface.ID should have values of I1, I2, I3 ..., and Interface.Ring_Net_ID should have values of R1 and R2. If the nature of the relationship were different, such that it could point to another instance of Interface in a different Ring Net, then an additional attribute would be required (e.g. Next_Ring_Net_ID). This would show that the relationship is not constrained to be within the same Ring Net. Hope this helps, Bary Hogan Subject: (SMU) ADFD Vs Action Language -Reply Les Munday writes to shlaer-mellor-users: -------------------------------------------------------------------- Steve, I've been in touch with SES about their ObjectBench, and it doesn't appear any more advanced that BridgePoint. No, they don't have ADFDs either.They use an action language. I still think that action languages are a cop-out from trying to convert ADFDs into code. It's a pretty simple process to convert an ADFD into an action language, and even if the tool can't do it they should give you the drawing and checking capapbility, so that you can then convert manually to an action language, if you desire. (If not, don't use the ADFDs.) Unfortunately, I have to agree with you, that vendors want to go with an action language and miss out on the ADFD. My feeling is that this is simply ommiting a step in the development process. It's not a replacement, the two action languages and ADFDs should co-exist quite happily in the same tool. I say unfortunately, because working for the government, I would not get away with specifying my documentation in terms of action language statements. That means that all the functions would be specified in English, which is a big step backwards. Another company I found is called Kennedy Carter. They have their own adaptations to the S/M method. Their tool is Intelligent OOA and it too doesn't use ADFDs. They claim to have created the Action Specification Language as a replacement for ADFDs. They also have a lot of detail about the S/M method on their web page. http://www.kc.com Cheers Les. >>> Madan, Steve Tuesday, 28 January 1997, 914am >>> I am fairly new to the SM methodology, and have been trying to read all the literature and books that I can get my hands on. In the "Object Lifecycles" book, ADFD was introduced as a way to formulate the action process that occurs within a state. Even OOA96 has a chapter augmenting and updating the book's method, however, all of the Top end CASE Tools vendors are leaning towards the Action Language and shying away from ADFD's. I have yet to see any sort of formalism describing the Action Language or any reason for its popular choice. *********************************************************************** Steve Madan MCC Panasonic smadan@panasonic.atlanta.com 1225 Northbrook Parkway Phone: (770) 338-6120 Suite 2-364 FAX: (770) 338-6238 Suwanee, GA 30174 *********************************************************************** Subject: Re: (SMU) ADFD Vs Action Language lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Madan... > I am fairly new to the SM methodology, and have been trying to read all > the literature and books that I can get my hands on. In the "Object > Lifecycles" book, ADFD was introduced as a way to formulate the action > process that occurs within a state. Even OOA96 has a chapter augmenting > and updating the book's method, however, all of the Top end CASE Tools > vendors are leaning towards the Action Language and shying away from > ADFD's. I have yet to see any sort of formalism describing the Action > Language or any reason for its popular choice. Actually, one tool does use ADFDs directly -- Pathfinder's code generator works directly from System Architect's ADFDs, I believe. I think action languages were developed primarily because it was much easier to do with the available technology when the tools started to be developed. Ideally it should be possible to define an action language that is essentially just a text-based ADFD. In practice the vendors have had varying success in remaining faithful to the ADFD discipline. Rumor has it that PT is going to define and ADFD-compliant action language shortly. H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) ADFD Vs Action Language -Reply lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Munday... >Another company I found is called Kennedy Carter. They have their own >adoptations to the S/M method. Their tool is Intelligent OOA and it too >doesn't use ADFDs. They claim to have created the Action Specification >Language as a replacement for ADFDs. I don't want to get into Tool Wars here, but as a user of IOOA I think a couple of clarifications are in order because this could be interpreted to mean that KC is not following S-M. *All* tool vendors currently have variants on the methodology because they had to solve architectural and code generation problems before the methodology refinements were issued that addressed the problems. IMHO IOOA's variants are no worse than other vendors. Most tools do a pretty consistent job on the notation because it is, after all, supposed to be unambiguous. The variants tend to lie mostly in code generation add-ons (e.g., support of polymorphic events) and inconsistency in the action language, when used, with ADFD constraints. The IOOA action language *is* quite faithful to ADFDs. It can even be annoyingly faithful. For example, if you have an attribute, y, of an object X, you cannot write X.y = X.y + 1 in the IOOA ASL. This is because their ASL equates an ADFD process to a statement. The example has three distinct ADFD processes so it would have to be written as temp_y = X.y Read accessor: put value in a local variable temp_y = temp_y + 1 Transform: process the local data X.y = temp_y Write accessor: save new attribtue value -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) Domain Analysis for Compilers Allen Theobald writes to shlaer-mellor-users: -------------------------------------------------------------------- Greetings Once Again! Boy am I full of questions! And believe it or not they are all related to the same project! It seems years ago that Ralph Johnson (johnson@cs.uiuc.edu) wrote the following statements regarding domain analysis for compilers in the Shlaer-Mellor Methodology. "We can also analyze the domain of each part of a compiler. We learn about grammars, methods for specifying static semantics, and register transfer languages (my favorite way of specifying architectures). Some of these areas (like parsing) are much better understood than others (like code optimization)... ...The domain anlysis was done years ago, you are merely learning the results. This is good, of course, since domain analysis is expensive, and it is good to reuse what others have done... ...It is great when we can reuse the results of domain analysis that are done by other people..." These comments fit my sentiments exactly. Now the $64000 question. Has anyone put existing compiler domain analysis into the Shlaer-Mellor methodology? Anyone want to give it a shot? The steps, as Steve Mellor said, look like: 1. We take the problem-as-whole and divide it into "domains", understanding the dependencies between the domains. 2. Next, we identify purchasable domains, and annonate same. Then we divide large domains into subsystems. 3. Take the identified dependencies between the domains and try to pin them down more precisely. (...) I would welcome any input on the above steps for compiler domain analysis. Thanks in advance, Allen Subject: Re: (SMU) Domain Analysis for Compilers David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: -------------------------------------------------------------------- Allen Theobald writes to shlaer-mellor-users: > It seems years ago that Ralph Johnson (johnson@cs.uiuc.edu) wrote the > following statements regarding domain analysis for compilers in the > Shlaer-Mellor Methodology. > "We can also analyze the domain of each part of a compiler. We > learn about grammars, methods for specifying static semantics, and > register transfer languages (my favorite way of specifying > architectures). Some of these areas (like parsing) are much better > understood than others (like code optimization)... These comments fit my sentiments exactly. Now the $64000 question. > Has anyone put existing compiler domain analysis into the > Shlaer-Mellor methodology? Anyone want to give it a shot? I have tried, in the past, to put a compiler-type thing into SM. Its a lot harder than a real-time or embedded system. The big problem is to work our what the problem is (and what it isn't). It ia, IMO, a mistake to attempt to put lexical analysis or parsing into an SM analysis. Tools such as Lex and Yacc are focused on these problems. SM is a general purpose method. Therefore LEx and Yacc are better at parsing input files than an SM domain (though it could be done). An approach I have used in the past is to have a YACC script inject events into an SM domain. You have to construct a bridge between the parser and semantic stuff. This is not too difficult. But then you have to work out what to do with the input. It is easy to produce an OIM than describes the structure of a language, but its much harder to work out what the state models should be. A language definition is static. Similarly, you have to produce some output. The easiest way to do this is to get a stable object population and then trigger an output domain to query the compiler domain and dump out its contents. This implies that the compiler domain will need an OIM that describes the target environment. Unfortunately this is yet another static OIM. It is possible to analyse the bit in the middle to produce a machine that converts an input population into an output population. I have found that such an analysis has a rather artificial feel. You are forcing a fairly well understood process into a novel notation. This can produce new insights, but is difficult. Having said that, using automatic gode generation does allow you to ignore the implementation details of data structures. This lets you concentrate your attention on the real algorithms. With flexibility of thought, it is possible to get a nice description of the compiler. It is very difficult to avoid describing solutions, rather than problems. Have a go by all means. Don't expect your initial OIM to be the one you end up with. Dave. -- David P. Whipp. Not speaking for: ------------------------------------------------------- G.E.C. Plessey Due to transcription and transmission errors, the views Semiconductors expressed here may not reflect even my own opinions! Subject: Re: (SMU) Domain Analysis for Compilers peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 02:58 PM 1/31/97 GMT, shlaer-mellor-users@projtech.com wrote: >David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: >Allen Theobald writes to shlaer-mellor-users: > >> Has anyone put existing compiler domain analysis into the >> Shlaer-Mellor methodology? Anyone want to give it a shot? > >I have tried, in the past, to put a compiler-type thing into SM. Its >a lot harder than a real-time or embedded system. The big problem is to >work our what the problem is (and what it isn't). > >It ia, IMO, a mistake to attempt to put lexical analysis or parsing into >an SM analysis. Tools such as Lex and Yacc are focused on these problems. >SM is a general purpose method. Therefore LEx and Yacc are better at >parsing input files than an SM domain (though it could be done). After watching this thread half-heartedly for a bit, please help me out if I miss the point (but here goes): At Pathfinder Solutions, we look at static model analysis and automated model translation as a form of "compilation". The approach we took for this problem is to break it up just as David suggested. We have found that the resulting domain for the OOA semantics - our "Shlaer-Mellor Repository" domain (SMR) - initially looked static. In fact, the way we create most of the SMR instantes during CASE database extraction (realized) is through synchronous service of SMR. BUT when you start to actually use SMR (not just fill it in), things get interesting from a behavior perspective. This includes extraction (for translation) and semantic analysis (static checking). On the archetype side, we've got 2 other domains. One for the mechanical parsing of archetype file - this is realized. The other - "ARC" - holds the semantic interpretation of the archetype elements. In a similar manner to the CASE db extraction process, the parser synchronously creates many instances in ARC. Again, ARC's behavior analysis gets interesting when you consider target document production - basically the code (or document or report or whatever) generation phase. Our domain chart for this product family was posted to this forum (in ASCII) a few months ago. Static checking of OOA models, and their automatic archetype-based translation is a very suitable problem to be solved by SM-OOA/RD itself. David's comment about recognizing when to model a domain with OOA, and when to take advantage of a "tailored" realized capability - like YACC and LEX - is right on the mark. Write that one down. ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | | effective solutions for OOA/RD challenges | | Peter Fontana voice: 888-OOA-PATH | peterf@pathfindersol.com fax: 508-384-1392 | ____________________________________________________| Subject: Re: (SMU) Domain Analysis for Compilers lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Theobald.... I generally agree with Whipp's comments. I just have a couple of amplifications. I agree that unless you have a rather bizarre language or the medium isn't ASCII it would be best to rely on available OTS tools for the front end. I would go further an regard the parser as a realized OTS domain that provides events to the interesting part of the compilation (Whipp's semantic domain). However, if one did have to make a parser, one way to model it (assuming a BNF-style situation) might be to have active objects like Production that are active and whose events are derived from tokens (i.e., when the current token is processed the appropriate event is placed in the queue). Each Production state would place the appropriate data or action handle on the statement stack (which, when the Production completes niormally, is converted to events to the semantic domain). Such a state machine would exist purely to detect errors in a Production object, but higher level objects' state machines could traverse the syntax table by selecting Syntax Rows and invoking Productions based upon different paths dictated by current state and token event. Thus the OIM is based more on the abstract language elements (BNF) and the specific language only comes into play in the state machines themselves. I am not sure that the semantic domain will be static. It would certainbly tend to be if all it does is write object code to a file since that is just a reformatting of event data from the parser. However, if the compiler needs to do optimization or other complex processing (e.g., flattening loops, etc.) there might be some active objects lying around. Compiler optimization is not an area I am familiar with, so I won't speculate on what they might be. FWIW, my instinct agrees with Whipp that any active abstractions would probably not be simple descriptions of the target environment. That is, I suspect they would be abtractions of things in the intermediate steps to get there, just as the BNF entities might be the abstractions in the Parser above. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com 'archive.9702' -- Subject: (SMU) Associations considered a bad thing lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- I just caught up on some of my readings and encountered an interesting article in the February, 1997 Journal of Object Oriented Programming entitlted "Associations considered a bad thing" by Graham, Bischof, and Henderson-Sellers. The article underscores some problems with data model referential integrity as practiced in some common methodologies. Their proposed solution for the problems seems to be essentially that already practiced in S-M with unidirectional attributes used to map the specific instances in relationships. The thing that puzzles me is a quote: "Most of the popular methods for object oriented analysis [footnote references S-M among others]...offer a construct that places a link between object types depicting static connections other than specialization, aggregation, and usage." Though S-M is not mentioned again in the article, the implication is that it is lumped in with other methodologies that have problems with referential integrity. First, it seems to me that S-M relationships are only static connections for specifialization, aggregation, and usage. Second, it seems that the S-M approach to referential attributes already implements their solution. Has anyone else read the article and, if so, am I missing something here? -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) test email John Gibb writes to shlaer-mellor-users: -------------------------------------------------------------------- test; please ignore Subject: (SMU) Shlaer-Mellor vs. UML and SDL... Tomas Paal writes to shlaer-mellor-users: -------------------------------------------------------------------- Greetings! I am new to this mailing list and have a question to the recipients of the list. We are planning to developing a new product. It will include digital electronics (which will be designed with VHDL) and software in DSP:S and a couple of administrative CPU:s. I will probably be in charge of software design and need to know more about design methodologies. = I have heard many good things about the Shlaer-Mellor method and the Bridgepoint tool, especially it beeing a formalized method, thus making it possible to fully simulate your model. Full code generation is also an advantage. But what are the good and bad things with S-M compared to SDL (Specification and Description Language) and UML 1.0 respectively. Why (as I suppose you will recommend S-M) should I not use the other modeling methods? Thank you in advance. = -- = ----------------------------------------- Tomas Pa=E1l Ericsson Saab Avionics AB Display and Reconnaiscanse Systems Div. D/KB Software Design S-164 86 STOCKHOLM SWEDEN phone: +46 8 757 07 89 fax: +46 8 750 74 42 e-mail: Tomas.Paal@emw.ericsson.se ----------------------------------------- Subject: (SMU) Re: Your JOOP Article Ian Graham <101710.3061@CompuServe.COM> (by way of Steve Mellor ) writes to shlaer-mellor-users: -------------------------------------------------------------------- Everyone: I forwarded HS's question about the article in the February issue of Journal of Object Oriented Programming entitled "Associations considered a bad thing" by Graham, Bischof, and Henderson-Sellers to Henderson Sellers (I happened to have his e-mail address handy), who in turn sent it to Graham. First the question, preceded by '>'. Then Graham's response copied with his permission. -- steve mellor >From: lahman >Reply-To: lahman@ATB.Teradyne.COM >Organization: Teradyne/ATB >To: "shlaer-mellor-users@projtech.com" >Subject: (SMU) Associations considered a bad thing >Sender: owner-shlaer-mellor-users@projtech.com >Reply-To: shlaer-mellor-users@projtech.com >Errors-To: owner-shlaer-mellor-users@projtech.com > >lahman writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >I just caught up on some of my readings and encountered an interesting >article in the February, 1997 Journal of Object Oriented Programming >entitlted "Associations considered a bad thing" by Graham, Bischof, and >Henderson-Sellers. > >The article underscores some problems with data model referential >integrity as practiced in some common methodologies. Their proposed >solution for the problems seems to be essentially that already practiced >in S-M with unidirectional attributes used to map the >specific instances in relationships. > >The thing that puzzles me is a quote: "Most of the popular methods for >object oriented analysis [footnote references S-M among others]...offer >a construct that places a link between object types depicting static >connections other than specialization, aggregation, and usage." Though >S-M is not mentioned again in the article, the implication is that it is >lumped in with other methodologies that have problems with referential >integrity. > >First, it seems to me that S-M relationships are only static connections >for specifialization, aggregation, and usage. Second, it seems that the >S-M approach to referential attributes already implements their >solution. > >Has anyone else read the article and, if so, am I missing something >here? >-- >H. S. Lahman There is nothing wrong with me that Steve, Brian forwarded your query. Sorry if I misrepresented you. I haven't read your book for over five years now and remembered you as treating relationships as if they existed outside the entities. However, the whole point of the paper is that using unidirectional pointers implies that you need rulesets/invariants to represent the integrity rules. Therefore, and you certainly never mentioned rulesets, I assumed that you couldn't make do with the one-way thing. The treatment on page 55 onwards doesn't make this clear and, anyway, you normalize away all the n-m relationships, which is where all the interesting stuff happens from the viewpoint of an OO bigot like I sometimes become (i.e. when not working on commercial projects). OK, I shouldn't make assumptions and I'll have to blow the dust off your book and reread properly. All the barbs were really aimed at OMT, and it's a pity when innocent bystanders get hit by a riccochet! But I still need to convince myself fully that S-M really doen't violate encapsulation in regard to integrity at least. Thanks for the admonition anyhow. Ian Subject: (SMU) Associate Objects croche@tellabs.com writes to shlaer-mellor-users: -------------------------------------------------------------------- Dear S-M Users: I am very new to the SM methodology and had a question about associate objects. I was wondering if associate objects can be used twice, meaning if they can be associate objects for two different relationships? Also, if this is true, how is the associate object formalized for each unique relationship? Is the assoc. object formalized in relation to both relationships or just the unique one? Examples would be a plus and greatly appreciated. Thanks!!! -Christina Subject: (SMU) Associate Objects Andrew Nortje writes to shlaer-mellor-users: -------------------------------------------------------------------- Christine wrote > I am very new to the SM methodology and had a question about associate >objects. I was wondering if associate objects can be used twice, meaning if they >can be associate objects for two different relationships? Also, if this is true, >how is the associate object formalized for each unique relationship? Is the >assoc. object formalized in relation to both relationships or just the unique >one? Examples would be a plus and greatly appreciated. Thanks!!! > I discussed your question with one of my collegues and we came to the conclusion that it is not possible to use one associate object for two different objects. The reasons are as follows: 1. The Shlaer Mellor rules for attribution state that all attributes of an instance of an object must be valid - see p 19 of the Oject Lifecycles, Modeling the World in States book by Shlaer Mellor. Quote First Rule: One instance of an object has exactly one value for each attribute at any given time. ... It forbids a table with a "repeating group" structure as well as a table with holes Unquote (The holes bit is what concerns this problem) 2. An instance of an associative object only exists if the relationship defined by the association is valid. Because of 1 and 2 above if one tried to use one associative object to define two different relationships the association might not be valid for one of the relationships, hence one of the attributes would be invalid, which would imply that Rule 1 of attribution rule would be violated. Hope this helps. Andrew Subject: Re: (SMU) Associate Objects David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: -------------------------------------------------------------------- Andrew Nortje wrote > > I am very new to the SM methodology and had a question about associate > >objects. I was wondering if associate objects can be used twice, meaning if they > >can be associate objects for two different relationships? > I discussed your question with one of my collegues and we came to the > conclusion that it is not possible to use one associate object for two different > objects. The reasons are as follows: > > [attribution rules 1 & 2] > > Because of 1 and 2 above if one tried to use one associative object to define two > different relationships the association might not be valid for one of the > relationships, hence one of the attributes would be invalid, which would imply that > Rule 1 of attribution rule would be violated. I will disagree with the conclusion. What you have said is that it you can't use one assoc object for 2 relationships because this might lead to inconsistancies, I would view this as a constraint on the model's behaviour rather than on the structure of the model. Consider a model where there are two assoc objects connected by a 1:1 (unconditional) relationship. The constraint that is implied by this relationship is the same as when one assoc object is used for both objects. In fact, this example can be extended to have a 1:M (or M:M) unconditional relationship between two assoc objects. the important thing is that the connecting relationship must be unconditional for the equivalence to hold. Now, though I disagree with the conclusion, I agree with the sentiment. I will assert that if you want to specify the constraint between two realationships then this should be done using a relationship between associative objects. This makes the intent of the model much clearer. Dave. -- David P. Whipp. Not speaking for: ------------------------------------------------------- G.E.C. Plessey Due to transcription and transmission errors, the views Semiconductors expressed here may not reflect even my own opinions! Subject: Re: (SMU) Associate Objects "Duncan.Bryan" (Duncan Bryan) writes to shlaer-mellor-users: -------------------------------------------------------------------- > croche@tellabs.com writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Dear S-M Users: > > I am very new to the SM methodology and had a question about associate > objects. I was wondering if associate objects can be used twice, meaning if they > can be associate objects for two different relationships? Also, if this is true, > how is the associate object formalized for each unique relationship? Is the > assoc. object formalized in relation to both relationships or just the unique > one? Examples would be a plus and greatly appreciated. Thanks!!! > > > -Christina > An associative object is generally used to represent many-many relationships between objects pairs. To achieve this its identifiers are formalised as the sum of the identifiers of the objects that it associates. So, no you can't really use ONE twice but there is no reason why there cannot be more than one associative relationship describing different relationships between the same two objects, nor why the two objects associated by the associative object cannot actually be the same object ( reflexive associative relationship)! Hopefully the example will clarify this. General form - straight from MTWIS page 26 - a many to many formalisation using an associative object. 1. Home 2. Home Owner *number owns R1 *Name *zip code <<------------------>> . some attribute .some attribute ^ is owned by | | 3. Ownership *number (R1) *zip code (R1) *Name (R1) .some attribute Object 3, the associative object, represent the concept of ownership between objects 1 and 2. A home can be owned by many owners and a home owner may own many homes. The following is also reasonable and isn't straight from MTWIS but from my flu riddled imagination. 4. Part Ownership *number (R2) *zip code (R2) *Name (R2) .some attribute | | part owns v is part owned by 1. Home <<------------------>> 2. Person *number R2 *Name *zip code . some attribute .some attribute wholly owns R1 <<------------------>> ^ is wholly owned by | | 3. Ownership *number (R1) *zip code (R1) *Name (R1) .some attribute Objects 3 and 4 are similar, and are formalised in a similar way, but represent completely different relationships. Is that what you were trying to represent when you mention 'if they > can be associate objects for two different relationships' Just for completeness... connects to 1. Pin <<-------- 2. Connection *pin number |<---- * pin_number (R1) . some attribute<-------- * pin_number (R1) is connected to 1. Pin is the object of interest and 2. Connection represents an association between instances of 1. Pin. For example there may be 5 instances of pin ( 1 through to 5 ) and associative objects such as 2. Connection * 1 * 2 2. Connection * 3 * 4 2. Connection * 1 * 5 may exist that specify connections between pins 1 and 2, 3 and 4 and 1 and 5. Hopefully this email answers your question about 'using associative objects twice'? Any errors are purely viral :-) All the flu riddled best, Duncan Bryan. Subject: Re: (SMU) Associate Objects - per Duncan croche@tellabs.com writes to shlaer-mellor-users: -------------------------------------------------------------------- SM Users: See Below > > "Duncan.Bryan" (Duncan Bryan) writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > An associative object is generally used to represent many-many relationships between > objects pairs. To achieve this its identifiers are formalised as the sum of the > identifiers of the objects that it associates. > > So, no you can't really use ONE twice but there is no reason why there cannot be > more than one associative relationship describing different relationships between > the same two objects, nor why the two objects associated by the associative object > cannot actually be the same object ( reflexive associative relationship)! > > Hopefully the example will clarify this. > > General form - straight from MTWIS page 26 - a many to many formalisation using > an associative object. > > > 1. Home 2. Home Owner > *number owns R1 *Name > *zip code <<------------------>> . some attribute > .some attribute ^ is owned by > | > | > 3. Ownership > *number (R1) > *zip code (R1) > *Name (R1) > .some attribute > > Object 3, the associative object, represent the concept of ownership > between objects 1 and 2. A home can be owned by many owners > and a home owner may own many homes. > > > > The following is also reasonable and isn't straight from MTWIS but from > my flu riddled imagination. > > > 4. Part Ownership > *number (R2) > *zip code (R2) > *Name (R2) > .some attribute > | > | > part owns v is part owned by > 1. Home <<------------------>> 2. Person > *number R2 *Name > *zip code . some attribute > .some attribute wholly owns R1 > <<------------------>> > ^ is wholly owned by > | > | > 3. Ownership > *number (R1) > *zip code (R1) > *Name (R1) > .some attribute > > > > Objects 3 and 4 are similar, and are formalised in a similar way, but represent > completely different relationships. > > Is that what you were trying to represent when you mention 'if they > > can be associate objects for two different relationships' > > Duncan, I think an example will help explain what I am asking on this one: ------------- ------------ 1. HOME | is owned by |2. PERSON *number | <<------------------->> | *Name * zip code | owns | . some attribute .some attrib| -------------- ^ ------------ | ^ | ^ owned by | | --------------- | |3. Ownership | | | *number | | | *zip code |-----------> | | *name | | | .some attrib | | ---------------- V owns V ----------------- | 4. Car | *VIN number | .some attrib |---------------- In this example, can 3 be used in this manner(as an associate object for two different relationships)? Also how is 3 formalized? Are all the unique id's placed in 3? (Will *VIN number be added to 3's list)? -Christina > > Just for completeness... > > > > connects to > 1. Pin <<-------- 2. Connection > *pin number |<---- * pin_number (R1) > . some attribute<-------- * pin_number (R1) > is connected to > > 1. Pin is the object of interest and 2. Connection represents an association > between instances of 1. Pin. > > For example there may be 5 instances of pin ( 1 through to 5 ) > and associative objects such as > > 2. Connection > * 1 > * 2 > 2. Connection > * 3 > * 4 > 2. Connection > * 1 > * 5 > > > may exist that specify connections between pins 1 and 2, 3 and 4 and 1 and 5. > > > > > Hopefully this email answers your question about 'using associative objects twice'? > > > Any errors are purely viral :-) > > All the flu riddled best, > > Duncan Bryan. > Subject: Re: (SMU) Associate Objects lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Roche... > I am very new to the SM methodology and had a question about associate > objects. I was wondering if associate objects can be used twice, meaning if they > can be associate objects for two different relationships? Also, if this is true, > how is the associate object formalized for each unique relationship? Is the > assoc. object formalized in relation to both relationships or just the unique > one? Examples would be a plus and greatly appreciated. Thanks!!! I agree with Whipp that you can do that, but you probably don't want to do so. Though it is conventional to make the associative object's identifiers the identifiers of the related objects, I don't think this is necessary. There is nothing to prevent the associative object from having other, non-identifying referential attributes that are associated with a second relationship. Let's assume associative object X wants to be associative for R1 between objects A and B and also for R2 between objects C and D. Then object X might look something like: *X_id -A_id (R1) -B_id (R1) -C_id (R2) -D_id (R2) -other_attributes You would probably want the associative object to have its own, indendent identifier so that it is not bound to a particular order in which relationships are instantiated. While I think this is legal, there are a couple of reasons why I don't like it. First, as Whipp points out, it is probably clearer to have two objects with a relationship between them. A single associative object for two relationships is a pretty arcane usage. Also, there is very likely another data relationship that is being obscured. That is, there is probably a *reason* why the two relationships are closely linked together. Second, preserving data integrity in an asynchronous architecture could be very difficult when it is time to instantiate an X. You would have to lock A, B, C, and D during the instantiation. Worse, you would probably be creating at least two of these at the same time, so there might be other locks required as well. Data integrity requires that all the relevant instances be created simultaneously (from the outside view and if the relationships are unconditional) and this might not be very convenient in practice. You might be forced to make at least one of the relationships conditional just because of the temporal considerations realted to when the objects can be created and this would be obscure if not not outright bad modeling. Many of these difficulties are alleviated if you use two associative objects with a separate relationship between them. Finally, the primary purpose of an associative object is to document referential integrity for an relationship. I tend to regard them as an artifact of the *particular* relationship. While it is sometimes convenient or even elegant to ascribe other, real-world semantics and data to them, this is usually serendipitous. Therfore I am just a bit queasy about making them do double duty for multiple relationships; aesthetically I prefer a separate associative object for each relationship. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) Associative Objects Brian.Ochranek@add.ssw.abbott.com writes to shlaer-mellor-users: -------------------------------------------------------------------- >>> I am very new to the SM methodology and had a question about associate >>> objects. I was wondering if associate objects can be used twice, meaning if they >>> can be associate objects for two different relationships? >> I discussed your question with one of my collegues and we came to the >> conclusion that it is not possible to use one associate object for two different >> objects. The reasons are as follows: >> >> [attribution rules 1 & 2] >> >> Because of 1 and 2 above if one tried to use one associative object to define two >> different relationships the association might not be valid for one of the >> relationships, hence one of the attributes would be invalid, which would imply that >> Rule 1 of attribution rule would be violated. > > I will disagree with the conclusion. What you have said is that it > you can't use one assoc object for 2 relationships because this might > lead to inconsistancies, I would view this as a constraint on the > model's behaviour rather than on the structure of the model. > > Consider a model where there are two assoc objects connected by a 1:1 > (unconditional) relationship. The constraint that is implied by this > relationship is the same as when one assoc object is used for both > objects. In fact, this example can be extended to have a 1:M (or M:M) > unconditional relationship between two assoc objects. the important > thing is that the connecting relationship must be unconditional > for the equivalence to hold. > > Now, though I disagree with the conclusion, I agree with the sentiment. > I will assert that if you want to specify the constraint between two > realationships then this should be done using a relationship between > associative objects. This makes the intent of the model much clearer. It is difficult to give a hard and fast response when I am unsure what you are trying to model with the two relationships in question. I also think working from an interpretation of a shlaer-mellor excerpt always falls short of common sense and experience which comes with time. Food for thought. Your analysis condition must meet the following criteria before considering a single associative object for formalization of two relationships simultaneously: 1. I don't know the nature of these relationships, whether they are static or dynamic, but it must make sense for your model that when one is formalized the other is formalized and when one relationship is no longer valid the other relationship is no longer valid. It's an all or nothing thing. 2. The identifying attributes of the objects participating in the first relationship must be of the same attribute domain and value (but not necessarily of the same name) as the identifying attributes of the objects participating in the second relationship. In other words, it would be incorrect to have one set of identifiers for the associative object that formalize one relationship and another set of identifiers for the associative object that formalize the other relationship. If this were to be done it would be obvious that not all identifiers of the associative object are needed to uniquely identify an instance of the associate object and the corresponding relationship(s). If your analysis condition meets criterion 1 but not criterion 2, I agree with using an unconditional relationship between two associative objects. If your analysis condition meets none of the criteria, you either have a conditional relationship between two associative objects or no relationship at all. Brian Ochranek Abbott Laboratories Subject: Re: (SMU) Associate Objects - per Duncan Thomas Brennan-Marquez writes to shlaer-mellor-users: -------------------------------------------------------------------- Christina, In the example you give you cannot use a single associative object to apply to two different M:M relationships because: 1) not every person owning a home will necessarily own a car (and vice versa), and 2) clearly the car ownership relationship has nothing to do with ZipCode (for example). I think what you really mean is two different kinds of ownership. One kind is HomeOwnership between a Home and a Person. The other kind is CarOwnership between a Person and a Car. I would modify your IM as follows: ------------------ | 1. HOME | | *number | <<----------- | * zip code | owns | R1 | | | -------------------- ------------------ | <---- | 3. HomeOwnership | | | * number (R1) | | | * zip code (R1) | ---------------- is owned by | | * Name (R1) | | 2. PERSON |<<------------- -------------------- | * Name |<<------------- ---------------- is owned by | ---------------------- | <---- | 3. CarOwnership | | | * VIN number (R2) | ------------------ | | * Name (R2) | | 4. Car | owns | R2 ---------------------- | *VIN number |<<------------ | .some attrib | ------------------ Isn't this what you mean? Hope this helps. Thomas croche@tellabs.com wrote: > Duncan, > > I think an example will help explain what I am asking on this one: > > > > ------------- ------------ > 1. HOME | is owned by |2. PERSON > *number | <<------------------->> | *Name > * zip code | owns | . some attribute > .some attrib| > -------------- ^ ------------ > | ^ > | ^ owned by > | | > --------------- | > |3. Ownership | | > | *number | | > | *zip code |-----------> | > | *name | | > | .some attrib | | > ---------------- V > owns V > ----------------- > | 4. Car > | *VIN number > | .some attrib > |---------------- > In this example, can 3 be used in this manner(as an associate object for two > different relationships)? Also how is 3 formalized? Are all the unique id's > placed in 3? (Will *VIN number be added to 3's list)? > > -Christina Subject: Re: (SMU) Associate Objects - per Duncan lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Roche... > I think an example will help explain what I am asking on this one: > > > > ------------- ------------ > 1. HOME | is owned by |2. PERSON > *number | <<------------------->> | *Name > * zip code | owns | . some attribute > .some attrib| > -------------- ^ ------------ > | ^ > | ^ owned by > | | > --------------- | > |3. Ownership | | > | *number | | > | *zip code |-----------> | > | *name | | > | .some attrib | | > ---------------- V > owns V > ----------------- > | 4. Car > | *VIN number > | .some attrib > |---------------- > In this example, can 3 be used in this manner(as an associate object for two > different relationships)? Also how is 3 formalized? Are all the unique id's > placed in 3? (Will *VIN number be added to 3's list)? First, a quibble: Object 3 must have a referential identifier for VIN number. Also, name would be formalized with a reference to both relationships. If the 1/2 relationship is R1 and the 2/4 relationship is R2 then object 3 might look like: 3. Ownership *number (R1) *zip code (R1) *name (R1,R2) *VIN number (R2) As I indicated in my earlier message (we are probably suffering some time shifting) if R1 and R2 are both unconditional (i.e., all homeowners are also car owners), then making all the referntial identifiers part of the Ownership indentifier might make sense. It is more likely, though, that at least one set of referential identifiers should not be part of the Ownership identifier (i.e., should be simple attributes). Now to my non-quibble. I realize you are probably stretching to get an example of formaliztion, but this is not the way to model this situation. The nature of ownership is different for a home and a car. That is, the relationships are completely independent and the nature and responsibilities of being a home owner are quite different than being a car owner. Moreover, they are likely to be modeled in very different ways if there is, indeed, other attribute data ("some attribute") -- a likely situation would be Deed for R1 and Registration for R2. If you think of Deed and Registration as representative of separate associative objects, then it seems very likely that these two objects would not have a relationship between them. This suggests, in paraphrase of Whipp's original thought, that merging them is not justified. Since your original message I have tried to think of a realistic case where one might want to do this. There are a lot that are close (e.g., substitute Computer for Car, Software Package for Home, and Site License for Ownership), but none seems to be compelling. They always seem to come up inaccurate on closer scrutiny. Thus I am becoming suspicious that there is some Important Underlying Characteristic that makes this a poor idea universally rather than just generally. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: RE: (SMU) Associate Objects - per Duncan David Yoakley writes to shlaer-mellor-users: -------------------------------------------------------------------- ------ =_NextPart_000_01BC23E3.97498F20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ---------- From: croche@tellabs.com Sent: Tuesday, February 25, 1997 2:31 PM To: shlaer-mellor-users@projtech.com Subject: Re: (SMU) Associate Objects - per Duncan croche@tellabs.com writes to shlaer-mellor-users: -------------------------------------------------------------------- Duncan, I think an example will help explain what I am asking on this one: =09 ------------- ------------ 1. HOME | is owned by |2. PERSON *number | <<------------------->> | *Name * zip code | owns | . some attribute .some attrib| -------------- ^ ------------ | ^ | ^ owned by | | --------------- | |3. Ownership | | | *number | | | *zip code |-----------> | =20 | *name | | | .some attrib | | ---------------- V owns V ----------------- =20 | 4. Car | *VIN number | .some attrib |---------------- Christina, =20 As usual, it all comes back to the mission statement or subject matter = of the domain. Once you get all the objects working together towards a common goal and you get each object to represent one idea/notion within this subject matter, then many problems such as this one tend to = vaporize. Your example would either see a specialization of ownership=20 or a generalization of the things owned. Since previous posts already mentioned the possibility that the=20 ownership might be specialize two separate objects. Let me give an=20 alternate example, enforcing the notion the solution is absolutely = driven=20 by the mission of the domain. For example, if I am modeling a Catalog program that provides info on products, purchasers, date of sale, amount etc. then I probably do have multiple types of things that can be owned (purchased). =20 The key is that from the point of view of the Catalog, they are all just = instance of "Ownable Thing" and not separate objects. =20 Ownership in this case relates two instances of "Ownable Thing". =20 Important to note that attribution would also change to be consistent = with the=20 domain mission. For instance, "Ownable Thing" would probably have ids=20 that make sense to the Catalog domain (probably some auto generated catalog number). Attributes like the VIN number of a car would be kept in data attributes such as "user data 1", "user data 2" etc. hope this helps, David Yoakley ------ =_NextPart_000_01BC23E3.97498F20 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IgYMAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWN y b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAXAEAAAEAAAAMAAAAAwAAMAIAAAA L AA8OAAAAAAIB/w8BAAAAXwAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAHNobGFlci1tZWxsb3I t dXNlcnNAcHJvanRlY2guY29tAFNNVFAAc2hsYWVyLW1lbGxvci11c2Vyc0Bwcm9qdGVjaC5jb20 A AB4AAjABAAAABQAAAFNNVFAAAAAAHgADMAEAAAAhAAAAc2hsYWVyLW1lbGxvci11c2Vyc0Bwcm9 q dGVjaC5jb20AAAAAAwAVDAEAAAADAP4PBgAAAB4AATABAAAAIwAAACdzaGxhZXItbWVsbG9yLXV z ZXJzQHByb2p0ZWNoLmNvbScAAAIBCzABAAAAJgAAAFNNVFA6U0hMQUVSLU1FTExPUi1VU0VSU0B Q Uk9KVEVDSC5DT00AAAADAAA5AAAAAAsAQDoBAAAAAgH2DwEAAAAEAAAAAAAAAs1LAQSAAQApAAA A UkU6IChTTVUpIEFzc29jaWF0ZSBPYmplY3RzIC0gcGVyIER1bmNhbgAKDQEFgAMADgAAAM0HAgA a AAwAMQA4AAMAaAEBIIADAA4AAADNBwIAGgAMADEAGQADAEkBAQmAAQAhAAAAMzk0N0I4RUIyMzh G RDAxMTk0NzEwMDIwQUZGMjcyN0EACAcBA5AGAIQIAAAUAAAACwAjAAAAAAADACYAAAAAAAsAKQA A AAAAAwAuAAAAAAADADYAAAAAAEAAOQAgKJOR4yO8AR4AcAABAAAAKQAAAFJFOiAoU01VKSBBc3N v Y2lhdGUgT2JqZWN0cyAtIHBlciBEdW5jYW4AAAAAAgFxAAEAAAAWAAAAAbwj45GQ67hHOo8jEdC U cQAgr/JyegAAHgAeDAEAAAAFAAAAU01UUAAAAAAeAB8MAQAAABYAAAB5b2FrbGV5QGl4Lm5ldGN v bS5jb20AAAADAAYQFSwvhAMABxDlBgAAHgAIEAEAAABlAAAALS0tLS0tLS0tLUZST006Q1JPQ0h F QFRFTExBQlNDT01TRU5UOlRVRVNEQVksRkVCUlVBUlkyNSwxOTk3MjozMVBNVE86U0hMQUVSLU1 F TExPUi1VU0VSU0BQUk9KVEVDSENPTQAAAAACAQkQAQAAAOMGAADfBgAAmA8AAExaRnVETNxk/wA K AQ8CFQKkA+QF6wKDAFATA1QCAGNoCsBzZXRuMgYABsMCgzIDxQIAcIRycRIic3RlbQKDLjMDxgc T AoM0FK9mNREPemhlbAMgRGxn7QKDNg9/EIR9CoAIzwnZ4jsa7zI1NQKACoENscELYG5nMTAzFJA L AyBsaTE4MALRaS34MTQ0DfAM0B9TC1UYklYxGJATkG8UEGMFQC1fIXcKhyArDDAg9kYDYTpXIn4 g 9gyCIAUAbxGwZU5AFBAX4AGgcy4FoG2/Ih8jLQZgAjAkXyVrVApQIHNkYXksJABlYmRydQrAeSA d ICvgMQg5OTcsgDozMSDMUE0nXyMtVG8pnyVr7HNoC2AEkC0HgBfgBbCsLXUR8BHgQCDxaiEhjmg n Hy5vKTF1YmohMRMvvyVrUmU2AChTTXxVKRUQBBAmUAcwFBAgxk81swQgLSBwBJAYAHh1bmMAcAq F CosesDM+Nh/3FJIMASD2Jj9tIM53BRAUEAQgdG8xjzKR/joKhSF4QX9Cj0OfIawKha06BCw6bSX y ST7waAuAhGsgA5FleGFtC1DvOQAD8BfhF8FwSEELUz6AnxHABUBHoEhwSBBzawuA/GcgAiBHsgQ g AiA38EbqP0bqRBsl404dRG9HNTEuYCBIT01FJeNRg3yLThhLUndLkGQgYixwBVGyMlDgUEVSU0/ G TkbqUYAqbnUG0DnRMVGyIDw8RB9PcD4+K1WhVPBOSHBlVC0gev8FID1QBHFXQlKyBCBZ71dRP1D g OKAHgEgQAkAFEGJ16xQQVCsuW1l8TI9Pd1n6fl5Z/E9fVHdiv1qWTh1e/2HvZl9kD2USUrdlX2p f Z3//JgFdy21/YQxfSGxvba9RwfozUOBPUtER4EfQSVBR2v9dxnRvWnpVCXM/dE91XljX/1HBVnp a 43jFd89431TiV6H/a093r4D/VaFdCn9PgF9t//tNbyXyVoPfiI1OHVmihz//iVyMr4V/XwZRRoe Y Th9r7PQgNFDgQwrAj9+Tn5H24VThVklOIFUUkt+XD/+U+F0Klk+aj3AFRC8KnzxXdmMAQJKQaAU Q FAALgGG3RmY6xjiAIDJwLEBsK+DfPrBIEBfhM2EHkWIA0EgA1z8BR8A5AG0EAWlLARQA/zjhB4A C MErwBcChEDWzovCzW6E50W9mnVWiwmQDcV8LgFDgORA6IDkAeQhgIK5nEgChk6LCbzk1dwWw/0q z PwCnMRfApbFSwAsRBCCeYZ1VM2EEYAOgZ28HQNdIEVMApvZlANBop+U+8n8a8BOQB5Cj40uQUoA N sGH8L24hEKNBnVUD8EfCSyT/pFwr4KLBA6ADgSxwIPECYP8UIK+SrCFKkEsnPvAJ8FMAET8BdmF w BbBpemVdpnFZCGFISAhgbFMAZf+vATnREfBbgT8gOcA4wR6w/no44KNCpUBSs3LUnVUFsb+2AKc w crG2e6LCR8JnUqW6LjpsUwuApsGtEXajQFsycDmwbxQAqeFsGvBh/mQscKPSo0FS8aLCvKEAkP5 i AxA+sCxwR8BKEaLCt+bzcqejAGdoBUBVQLYYstG/qHC1sZ2BOOKn9aZxTKdB8VtxZ2l2W4EDoJ1 V B0B/pQF+oDjxSFUr4AnwAhBy/zjAqMKi0a4korM4oApAtsPfS1Em4ceiF9AscGQFEMQAv8RHUyG i yrmVphU6bEYFsf/FdwaQSjQEYh6wStG2AJKg/wGQGoBK4CDxCcBKYb8jIPH/vEANsAQgC4ACELf m A6Ag8e5ksfA5cCvgcAhwEbEygu8r4CuwwqK3IHMHQMXRSHD3CGCj8RIAY1DgsLNHoLFSXwGgyNC d VaYQSRBhxAFt/7UQn5BIkr7wOcBLYbmiuiMvvyM6McESUsQo0fZkKcumcZ1VVKLRa2UscEtR/78 j A1K+FQuApAG3ILxAB9F/uZXOlbCTLHAKwFuBF+FqfzJwBUCdVQuAo4GmsrcRIt9ykdUBOQDaMEr B IqszriH/wj/ZmHKYrzY6MBHwrOELYH8+w8IR3zbXA9/92ZidVUn/SIAakQBwrKOuIbniShFbpv+ j QrT0B0A4oD1QEcAd8LLR/z8QwSEFoACBFAGj8a7yv2r/phSi9qZxzJLfNivg3/609P/UxtXUrdA E IKVnShEAwNpw/7WxAIDrQ9zZ7WbY4PDWW1TvXAA/ELikFBBkqhbOpVUU/9mCFRBbtgQgHrDywaL C laj/twK2ADowrtG1A8Eh2nAFMN/ex9KitgBbp7HIIjJy/ATsMSLvQf2oMuDQ1AI6bPxobznASyR J ItHARZbV8P+t0LQR8rBIoGlGOt8f9xXCFzy5nVUaEQAGcAADABAQAAAAAAMAERAAAAAAQAAHMMC W Cn/jI7wBQAAIMMCWCn/jI7wBHgA9AAEAAAAFAAAAUkU6IAAAAAADAA00/TcAAM0j ------ =_NextPart_000_01BC23E3.97498F20-- Subject: Re: (SMU) Associate Objects - per duncan Don White writes to shlaer-mellor-users: -------------------------------------------------------------------- Hi, >domain mission. For instance, "Ownable Thing" would probably have ids >that make sense to the Catalog domain (probably some auto generated >catalog number). Attributes like the VIN number of a car would be kept >in data attributes such as "user data 1", "user data 2" etc. This sounds sensible but I think your approach is off. If your problem domain goal is to catalog, then ONE relationship should do it because you should only have ONE owned-thing kind of object with a data attribute specifying what is owned. Alternatively, if your problem domain goal is to articulate the behaviours of the different relationships, then the relationships (to be accurate) MUST be different. To rephrase, if you try to use one associative object for two relationships you are clearly stating that you really only have one kind of relationship. This means that having two kinds of owned things are inappropriate because they must both behave the same. Another observation ... It sounds to me like you might be trying to jump directly into implementation rather than truly modeling the given information. Example - specifics of ownership not important - (ie. just a database so ) should be only one ownership object (we don't care what an ) (owner does/needs ) is owned by owns person <<--------------------->> property ^ id = VIN,address | type = car,house ownership property id Example - specifics of ownership ARE important - (ie. we care about what ) should be multiple ownership objects ( an owner does/needs ) is owned by owns person <<--------------------->> car ^ ^ id = VIN ^ | | car ownership | registration = ... | | +---------------------------->> house ^ id = address | house ownership deed = ... -- donw Subject: Re: (SMU) Associate Objects - per Duncan lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Yoakley... > For example, if I am modeling a Catalog program that provides info > on products, purchasers, date of sale, amount etc. then I probably > do have multiple types of things that can be owned (purchased). > The key is that from the point of view of the Catalog, they are all just > instance of "Ownable Thing" and not separate objects. > Ownership in this case relates two instances of "Ownable Thing". I am not sure I understand how this relates to instantiating associative objects to multiple relationships. This seems to be a pure subtyping example: R1 R2 Person <---------->> Ownable Thing ---|--- C is-a If one include indigents among Persons, then the relationship to Ownable Thing would be conditional on both sides and an associative object (Proof of Purchase, say) might be in order to explain the relationship, but it would only be concerned with a single relationship. Could you clarify "relates two instances of 'Ownable Thing'"? I guess I don't see the purpose of having an Ownership object in this case; it seems to me it is implicit in the R1 relationship. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) OOA and 4 GL Gert Janse van Vuuren writes to shlaer-mellor-users: -------------------------------------------------------------------- Good day, We have been using the Shlaer-Mellor method for some time now at our company to develop software modules in C. We have a software architecture in place to translate our S-M models to C code, all the software engineering processes are in place and we are able to produce these modules very efficiently and in a predictable manner. These modules perform higly specialised processing and are invoked from a 4GL application as black box modules, it would be not possible to develop these modules in the 4GL and these black box modules could be re-used and are seen as company assets. We are currently investigating the possibility of also using OOA to model the 4GL side of the application, we realise that the OOA model is technology independent, but we come unstuck when it comes to defining a software architecture for translating the models to 4GL concepts. Has this been done at other companies and is it a good route to go? To my knowledge most of the 4GL tools are based on an information engineering approach to software development. Are there software development teams that develop in 4GL tools such as Powerbuilder, Delphi, Uniface, etc and that are using OOA for the analysis part? Thank you G v Vuuren. Subject: Re: (SMU) OOA and 4 GL Thomas Brennan-Marquez writes to shlaer-mellor-users: -------------------------------------------------------------------- Let me add my two cents to Gert's comments and questions. I am attempting to bring S-M methodology into the software group at my company (I've used it elsewhere and I believe in it). We are building an application based on Access/Visual Basic. So far, I have been able to convince folks here that analysis of the problem with a detailed IM is worthwhile. The next step, a harder sell I think, is to convince them that we should also build the state models to support the IM. I am almost convinced that, even though I don't see how we can get to automatic code generation in the time allowed, the IM and SM representations would be very useful. Further, I think I can build an architecture to map those models to Access/VB code. The process would have to be carried out manually but with discipline I think we could make it work. I would prefer to use a tool like BridgePoint to automate more (all?) of the process but I have to get the group walking before we can considering running. Anyone have any experience with this sort of environment? I realize I haven't actually answered Gert's question but, if I understand it correctly, I think my situation is somewhat similar. Thomas Gert Janse van Vuuren wrote: > > Gert Janse van Vuuren writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Good day, > > We have been using the Shlaer-Mellor method for some time now at our > company to develop software modules in C. We have a software > architecture in place to translate our S-M models to C code, all the > software engineering processes are in place and we are able to > produce these modules very efficiently and in a predictable manner. > > These modules perform higly specialised processing and are invoked > from a 4GL application as black box modules, it would be not > possible to develop these modules in the 4GL and these black box > modules could be re-used and are seen as company assets. > > We are currently investigating the possibility of also using OOA to model > the 4GL side of the application, we realise that the OOA model is > technology independent, but we come unstuck when it comes to defining > a software architecture for translating the models to 4GL concepts. > Has this been done at other companies and is it a good route to go? To > my knowledge most of the 4GL tools are based on an information > engineering approach to software development. > > Are there software development teams that develop in 4GL tools such > as Powerbuilder, Delphi, Uniface, etc and that are using OOA for the > analysis part? > > Thank you > G v Vuuren. Subject: (SMU) Transform Etiquette Jay Case writes to shlaer-mellor-users: -------------------------------------------------------------------- A minor philosophical question about Transformations. Is it socially/morally acceptable for one object to invoke a transform which has been "assigned" to the state model of another object? Say I've got objects DOG and FLEA, and FLEA has a transform BiteMe( who:unique_id ). For some strange reason, an instance of DOG wants to be bitten via Assign this_dog = self.DoggyID Transform FLEA::BiteMe( who:this_dog ) Sorry for the (poor) flea ridden syntax... I tend to think of transforms as 'private' to the object which declares them, but haven't seen any (ADFD) policy statements either way. Have I missed something (regardless of what any tool may support)? Thanks, Jay Case Tellabs Operations, Inc. Subject: Re: (SMU) Transform Etiquette peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 03:25 PM 2/27/97 -0600, shlaer-mellor-users@projtech.com wrote: >Jay Case writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >A minor philosophical question about Transformations. > >Is it socially/morally acceptable for one object to >invoke a transform which has been "assigned" to >the state model of another object? In short - yes. I believe the notion of data hiding enforced at the class level (a *good* thing) does/should not be transferred to the object level in OOA. I believe data hiding notion applies quite strongly to domains, but basically within a domain, there are no hard barriers. We could talk about other approaches for managing the complexity this wide-open visibility (like clusters) - but that's another topic. >I tend to think of transforms as 'private' to the >object which declares them, but haven't seen any >(ADFD) policy statements either way. Have I missed >something (regardless of what any tool may support)? No - I think you're transferring good implementation skills into the OOA realm and unduly restricting your alternatives. ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice/fax: 508-384-1392 | peterf@pathfindersol.com ext. 2 | ____________________________________________________| Subject: Re: (SMU) OOA and 4 GL lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to van Vuuren... > > Are there software development teams that develop in 4GL tools such > as Powerbuilder, Delphi, Uniface, etc and that are using OOA for the > analysis part? We don't use such tools, so regard my comments below with the appropriate level of skepticism. > We are currently investigating the possibility of also using OOA to model > the 4GL side of the application, we realise that the OOA model is > technology independent, but we come unstuck when it comes to defining > a software architecture for translating the models to 4GL concepts. > Has this been done at other companies and is it a good route to go? To > my knowledge most of the 4GL tools are based on an information > engineering approach to software development. I assume your goal in doing this is to use an OOA to define what you wish to implement in a 4GL. Superficially it would appear to be a reasonable thing since the 4GL mechanisms are just a different spin on the mechanisms one would use in an architecture to develop in C. In fact the 4GLs generally do far fewer things than you would do in, say, and R-T/E environment. However, I suspect there might be a problem due to the fact that the 4GLs also include higher level design features; in effect they are a mush of both design and implementation support. In fact, they strive to hide the low level mechanisms that an OOA would need access to for translation. Given this hypothesis, then the trick may be to separate the high level, design oriented features of the 4GL from the low level implementation mechanisms. Then the translation of the OOA would deal primarily with the low level 4GL mechanisms. What I am getting at is that translating an IM into the 4GL's database tables is probably pretty straight forward if you ignore all the fancy GUI stuff and use, say, the 4GL's programming API or language (SQL?) interface to create and access the tables. The trickier part would be making it do something useful by implementing the state models. The problem here is that you really don't have any way to build an architecture in the 4GL to support FSMs. (You probably wouldn't want to for performance reasons, even if you could.) If you can assume a synchronous architecture then this problem may go away. However, I still think there would be difficulties because the basic programming paradigms are very different and the 4GLs tend to provide a very limited suite of facilities in the interface. That is, the 4GLs tend to hide the detailed mechanisms for flow of control behind their design-oriented GUIs. For example, they might give you a pretty dialog box for specifying a relationship and a selection boolean with no access to the underlying navigational mechanisms. Therefore, I speculate that you could be successful in translating an OOA to a 4GL if the environment is synchronous and the 4GL provides a sufficiently low level programming API. I would not be sanguine about translating complete applications otherwise. However, just providing a detailed IM would be a big step up on the way to developing a 4GL application. Objects and relationships are a very natural fit to the 4GL paradigms -- the problem lies in the functionality. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Transform Etiquette lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Case... > Is it socially/morally acceptable for one object to > invoke a transform which has been "assigned" to > the state model of another object? > > I tend to think of transforms as 'private' to the > object which declares them, but haven't seen any > (ADFD) policy statements either way. Have I missed > something (regardless of what any tool may support)? The definitive answer is: yes and no. For OOA91, if a test or transform is assigned to an object it may not be accessed from another object. (See OL:MWS, pg 127, last paragraph under "Test" section. Albeit somewhat ambiguous, but this was defined as a rule in our class.) [This may have loosened up with OOA96 because neither one is allowed now to directly access the object's data store, so data coupling is reduced and the theoretical problem with public access may have gone away. Needs a Senior Guru clarification.] However, in practice transforms are called from multiple objects. The trick is not to assign them to the object. Instead, you make them an OOA96 wormhole and treat the transform as if it were realized code in a counterpart object in another domain. In general the intent of transforms is to provide a means for encapsulating arbitrarily complex operations that do not affect flow-of-control. Such encapsulation is consistent with the view of domains and bridges in that the processing represents operations at a different level of abstraction than the subject matter of the calling domain. That is, no matter how many IFs there are in the transform, if they don't affect flow-of-control in the calling domain, they are not relevant at the caller's level of abstraction. As a pratical matter every tool vendor I know of has implemeted something akin to Domain Synchronous Services as part their bridge implementations. These are services within the domain that have access to everything in the domain, but they are not associated with a particular object. These are, in effect, synchronous wormholes to that "other" domain. And everyone uses these as transforms across multiple objects, even when they don't really go to a bridge. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com 'archive.9703' -- Subject: Re: (SMU) Transform Etiquette Ted Barbour writes to shlaer-mellor-users: -------------------------------------------------------------------- lahman wrote: > Responding to Case... > > > Is it socially/morally acceptable for one object to > > invoke a transform which has been "assigned" to > > the state model of another object? > > > > I tend to think of transforms as 'private' to the > > object which declares them, but haven't seen any > > (ADFD) policy statements either way. Have I missed > > something (regardless of what any tool may support)? > > The definitive answer is: yes and no. For OOA91, if a test or transform > is assigned to an object it may not be accessed from another object. > (See OL:MWS, pg 127, last paragraph under "Test" section. The referenced paragraph reads "Transformations and tests are typically most closely related to internal (private) methods in OOD." While transformations and tests COULD be translated this way they dont necessarily have to be. Both OOA (ADFD-based) environments I have worked with translate transformations and tests to be public static member functions. Processes such as "Increment Count" and "Compare Strings" are generic enough to be conveniently defined once when they first crop up and reused in other object's ADFDs. > However, in practice transforms are called from multiple objects. The > trick is not to assign them to the object. Instead, you make them an > OOA96 wormhole and treat the transform as if it were realized code in a > counterpart object in another domain. While this practice is common to action language based OOA, as described above, it may be unnecessary when using ADFDs. -- ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | | effective solutions for OOA/RD challenges | | Ted Barbour voice: 888-OOA-PATH | tedb@pathfindersol.com | ____________________________________________________| Subject: (SMU) Sender: owner-shlaer-mellor-users@projtech.com Gert Janse van Vuuren writes to shlaer-mellor-users: -------------------------------------------------------------------- shlaer-mellor-users Subject: Re: (SMU) Transform Etiquette lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Ted, > The referenced paragraph reads "Transformations and tests are typically most closely related to internal > (private) methods in OOD." > While transformations and tests COULD be translated this way they dont necessarily have to be. Both OOA > (ADFD-based) environments I have worked with translate transformations and tests to be public static member > functions. Processes such as "Increment Count" and "Compare Strings" are generic enough to be conveniently > defined once when they first crop up and reused in other object's ADFDs. As I indicated, in the class (ca '91) we took this was couched as a rule. As I also indicated, since OOA96 no longer allows transforms to access the object data store, there is nothing to prevent transforms from *always* being static member functions. Note, though, that this does not help the OOA where there is no notion of static members and your ADFD would still have to provide an instance identifier on the data flow, which would probably have to be obtained by another process (e.g., Find Any). However, there is still the issue of associating a generic process with a particular object. For example, what if you decide the object is no longer needed? Now the generic transform must be associated with another object and all the callers have to be modified. Even if current thinking has reduced the rule to a guideline, I would still regard it as a *very strong* guideline for this reason. That is, I assume that the exception to the "typically" pertains to some obscure exception involving bifurcated timer assigners or some such. Regarding treating transforms as wormholes: > While this practice is common to action language based OOA, as described above, it may be unnecessary when > using ADFDs. In an ADFD it is, at most, a special notation (e.g., double circle) for the process to indicate that it is a wormhole. For me the issue is really using a notation that indicates that the transform is a generic process that is not associated with a particular object. The wormhole happens to be a convenient way to indicate this, whether it is in an ASL or in an ADFD. That is, I would regard documenting the generic process to be sufficient reason to justify using the wormhole notation. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: RE: (SMU) Associate Objects - per Duncan David Yoakley writes to shlaer-mellor-users: -------------------------------------------------------------------- ------ =_NextPart_000_01BC27BE.C3EBC7D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To Lahman and Don White: Thanks for the clarifications guys. Lahman wrote: Could you clarify "relates two instances of 'Ownable Thing'"? I guess I don't see the purpose of having an Ownership object in this case; it seems to me it is implicit in the R1 relationship. You are right, I did not state this correctly. What I *meant* is for ownership to be an associative object that relates a person and what is owned. My central point is that you can look at an IM such as Christina's and tell something is wrong but you do not know how to fix it without really understanding the domain (e.g. do we need two ownership objects or do we just have too many objects representing the thing that can be owned (just as Don White mentioned, the type of thing owned could be an attribute). To Don White This sounds sensible but I think your approach is off. If your problem domain goal is to catalog, then ONE relationship should do it because you should only have ONE owned-thing kind of object with a data attribute specifying what is owned. Alternatively, if your problem domain goal is to articulate the behaviours of the different relationships, then the relationships (to be accurate) MUST be different. Precisely. I am not sure how I lead you to think my example needed two relationships but at any rate we see the process the same. Thanks dy ------ =_NextPart_000_01BC27BE.C3EBC7D0 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IiIKAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWN y b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAXAEAAAEAAAAMAAAAAwAAMAIAAAA L AA8OAAAAAAIB/w8BAAAAXwAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAHNobGFlci1tZWxsb3I t dXNlcnNAcHJvanRlY2guY29tAFNNVFAAc2hsYWVyLW1lbGxvci11c2Vyc0Bwcm9qdGVjaC5jb20 A AB4AAjABAAAABQAAAFNNVFAAAAAAHgADMAEAAAAhAAAAc2hsYWVyLW1lbGxvci11c2Vyc0Bwcm9 q dGVjaC5jb20AAAAAAwAVDAEAAAADAP4PBgAAAB4AATABAAAAIwAAACdzaGxhZXItbWVsbG9yLXV z ZXJzQHByb2p0ZWNoLmNvbScAAAIBCzABAAAAJgAAAFNNVFA6U0hMQUVSLU1FTExPUi1VU0VSU0B Q Uk9KVEVDSC5DT00AAAADAAA5AAAAAAsAQDoBAAAAAgH2DwEAAAAEAAAAAAAAAs1LAQSAAQApAAA A UkU6IChTTVUpIEFzc29jaWF0ZSBPYmplY3RzIC0gcGVyIER1bmNhbgAKDQEFgAMADgAAAM0HAwA D AAoAJAAZAAEAIgEBIIADAA4AAADNBwMAAwAKAA4AJgABABkBAQmAAQAhAAAAMjA0NTgzQTZBQTk z RDAxMTk0NzUwMDIwQUZGMjcyN0EA7AYBA5AGACwGAAAUAAAACwAjAAAAAAADACYAAAAAAAsAKQA A AAAAAwAuAAAAAAADADYAAAAAAEAAOQAQNui+vie8AR4AcAABAAAAKQAAAFJFOiAoU01VKSBBc3N v Y2lhdGUgT2JqZWN0cyAtIHBlciBEdW5jYW4AAAAAAgFxAAEAAAAWAAAAAbwnvr7cpoNFIZOqEdC U dQAgr/JyegAAHgAeDAEAAAAFAAAAU01UUAAAAAAeAB8MAQAAABYAAAB5b2FrbGV5QGl4Lm5ldGN v bS5jb20AAAADAAYQWgaX2AMABxA5BAAAHgAIEAEAAABlAAAAVE9MQUhNQU5BTkRET05XSElURTp U SEFOS1NGT1JUSEVDTEFSSUZJQ0FUSU9OU0dVWVNMQUhNQU5XUk9URTpDT1VMRFlPVUNMQVJJRlk i UkVMQVRFU1RXT0lOU1RBTkNFU09GTwAAAAACAQkQAQAAAIkEAACFBAAA8gcAAExaRnUs/7Ut/wA K AQ8CFQKkA+QF6wKDAFATA1QCAGNoCsBzZXTuMgYABsMCgzIDxgcTAoMSMxMPZjQPemhlbNEDIER s ZwKAfQqACM/FCdk7F58yNTUCgAqBgw2xC2BuZzEwMxQg1wsKEvIMAWMAQCAKhRzkwFRvIExhaAO C AHAGZBZgAiAgV2hpdJxlOgqFHIwRwG5rBCDLAhAFwHQWICBjC2AGgWBpY2F0aQIgBCBncHV5cy4 c dhyLHYV3DwNgHqEiTQr0bGkzNq8N8AtVFCIMAXAkEmMFQHUIUWweEHkIYAqFIQR5PCAiF6ALYB6 g BCB0d0sdYAuAcwGQbmMHkW9AZiAnT3duAaBshyDgIBALgGcnIj8c4F5JIeEHkAQgK8BkAiAnWwV A EfBlCoUgwnAIcHBubxHwKlIRwHYrQR3hICsqoQSQcx6AcCpQYmpfJzILgCCxBAAg8GER8Dv7KbA s o20pYR1gB4AKhTDhfzBRB3ALUCFgMjIwEiDgUu8cYCkDIaIvUS4kfyWOG9keWQhgHeAXoDOwaWd o 1HQsLDJpHhBuJCAssD8BkB6gMCUFsBegJ0BseW8iMB5hIYArsSoHgABwdG4qMlIggQqFby8HMXF i tyDgHcIEEG8y4CGBdi4B7y+kIMA6cSkGYS2QLyEeQb0d8nc6YTHGKkEvAWQ6Id0iXE0o0CogAjB y B0AtkP5vC4AyQz5zJ9EwcQOgFzCcb2sd4AVAA5FJTSywznURsD0xCoVDaAUQKeD5C4BhJz8hHgE e oBZBPWA/B4AwMS6RMFEkAS6RYnW3Q8QsYDiTazigB+BoPBD3LPYdYCFQeDDSA/AgwAhg5z6iB0A 6 ACB1HgAvISnxPzhgLpEgwixgAMAwAShl7C5nIjBJIXcg4C8QCYA/KXI7ry+UKkEFwE4EanX/KeA u QjkhRHAxkABwKNBP9v8XoCbwB5BCkS6CLPlHtD5z/0QiPOFA802QUQMwkB4oMZHfUyECIAmAOCB T 83k/YBx2/yphR7RVVAWgJ5I85QJABRD5SKFlKTSNHVEeNwqPG6v/JudclyYqH8UwUT1gTBFg0f8 J 8ACQKuJIoivAR7JEkCfR+QXAYXAm8QDQRXBAwg3QfSIwSSpwYrIchybxKuFt/U0mZ2NAAyBDYh1 g IXEHQMxvZ1dzLtFORTO7LLD/S1EnoUkhHpAchzzgIXBREP8g4EPiaKUCIEvhUVNnkkDz+i1HtGs L gGsBKnAvlUsi/T8xZGbBHIdaRyywP2Ay4M8owC6CQBJAuUFsHqAEoP89ozoAOCAGkGKkZRUch2W f uzeBIZBjJ5A5BGHRZS5S7whhKkNM8waQZgSQQpEzu/xzLByHZ0Mgwnd7TZA8tR5jdQBCwFqxBdB V U1S/PNJ21zSGNX8bvwrBUDnB7wQAcdE6ISvAYWVwOKMIcO8g4EnhK7Eq8GEnszFiYlTybSjQZXi A IAtQLOZOYv9OhHltSKJEsyjQewJOIizB3y1UA2AqIUNyLOZzgCBNsOda/SAjXJVkeX2tXo0WwQI A jBAAAAADABAQAAAAAAMAERAAAAAAQAAHMEBP1bO7J7wBQAAIMEBP1bO7J7wBHgA9AAEAAAAFAAA A UkU6IAAAAAADAA00/TcAAMXp ------ =_NextPart_000_01BC27BE.C3EBC7D0-- Subject: Re: (SMU) Transform Etiquette ian@kc.com (Ian Wilkie) writes to shlaer-mellor-users: -------------------------------------------------------------------- > Jay Case writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > A minor philosophical question about Transformations. > > Is it socially/morally acceptable for one object to > invoke a transform which has been "assigned" to > the state model of another object? > [snip] > > lahman writes to shlaer-mellor-users: > -------------------------------------------------------------------- > [snip] > > The definitive answer is: yes and no. For OOA91, if a test or transform > is assigned to an object it may not be accessed from another object. > (See OL:MWS, pg 127, last paragraph under "Test" section. Albeit > somewhat ambiguous, but this was defined as a rule in our class.) [This > may have loosened up with OOA96 because neither one is allowed now to > directly access the object's data store, so data coupling is reduced and > the theoretical problem with public access may have gone away. Needs a > Senior Guru clarification.] Since OOA91 specifically excludes reuse of a transform ("A transformation is assigned to the object corresponding to the state model in which it is embedded...") and OOA96 makes no mention of the issue, we must presume that the rule stands. > However, in practice transforms are called from multiple objects. The > trick is not to assign them to the object. Instead, you make them an > OOA96 wormhole and treat the transform as if it were realized code in a > counterpart object in another domain. In general the intent of > transforms is to provide a means for encapsulating arbitrarily complex > operations that do not affect flow-of-control. Such encapsulation is > consistent with the view of domains and bridges in that the processing > represents operations at a different level of abstraction than the > subject matter of the calling domain. That is, no matter how many IFs > there are in the transform, if they don't affect flow-of-control in the > calling domain, they are not relevant at the caller's level of > abstraction. In OOA96 this may well be true. Since transforms must be pure (data accesses are no longer allowed), we are left with operations on types. If anything that makes the transform specific to the invoking domain is taken outside the transform (as is done with constants in OOA96), then what is left is almost always generic calculation which could then be specified in another domain. > As a pratical matter every tool vendor I know of has implemeted > something akin to Domain Synchronous Services as part their bridge > implementations. These are services within the domain that have access > to everything in the domain, but they are not associated with a > particular object. These are, in effect, synchronous wormholes to that > "other" domain. And everyone uses these as transforms across multiple > objects, even when they don't really go to a bridge. I suspect that a bigger issue is being addressed here than simply the reuse of pure transformations. Consider the "Moving to Source" and "Moving to Destination" states of the Robot in the ODMS domain. Both of these have lines of state pseudo code that looks like: look up x, y and theta coordinates for disk_transfer. compute x, y and theta increments and load stepper motors record new x, y and theta position for robot where is "source_id" or "destination_id" depending on the state. With the four process types of OOA96, and the rules surrounding them we are forced to state the above sequence twice. Since this is a set pattern for driving the robot in this domain, it would seem useful to be able to specify it once, so that in the ODMS we could say: move robot to disk_transfer.source_id and move robot to disk_transfer.destination_id and define the meaning of "move robot to" in one place. Our ASL therefore allows the grouping of blocks of ASL into services that are associated with an object, an instance or with a domain. Such services can be invoked from any object in the domain, or from outside it. Services that are pure transformations can be similarily accessed. Of course, such reuse does bring a risk in that a service that encapsulates significant activity can be inappropriately reused. However this can be offset against the risk of modifying only one of the non-reused sections of processing in the event of a maintenance change to the domain. Ian Wilkie ===================================================== Kennedy Carter, 14 The Pines, Broad Street, Guildford Surrey, GU3 3BH, U.K. Tel: (+44) 1483 483 200 Fax: (+44) 1483 483 201 Further Information: http://www.kc.com or info@kc.com ===================================================== Subject: Re: (SMU) Transform Etiquette Ted Barbour writes to shlaer-mellor-users: -------------------------------------------------------------------- lahman wrote: > > The referenced paragraph reads "Transformations and tests are typically most closely related to internal > > (private) methods in OOD." > > While transformations and tests COULD be translated this way they dont necessarily have to be. > > As I also indicated, since OOA96 no longer allows transforms to > access the object data store, there is nothing to prevent transforms > from *always* being static member functions. Note, though, that this > does not help the OOA where there is no notion of static members and > your ADFD would still have to provide an instance identifier on the data > flow, which would probably have to be obtained by another process (e.g., > Find Any). An instance identifier isnt needed as an input for Test and Transformation processes so I'm not sure what you mean. > However, there is still the issue of associating a generic process with > a particular object. For example, what if you decide the object is no > longer needed? By the time I'm doing ADFDs, I'm unlikely to be adding/deleting objects. However, your point is well taken and I will consider, in the futture, whether this type of process reuse is worth the risk you've pointed out. -- ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | | effective solutions for OOA/RD challenges | | Ted Barbour voice: 888-OOA-PATH | tedb@pathfindersol.com | ____________________________________________________| Subject: Re: (SMU) Transform Etiquette lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Ted Barbour wrote: > Ted, > An instance identifier isnt needed as an input for Test and Transformation processes so I'm not sure what you > mean. An instance identifier is required on the data flow into *any* process that is associated with an object. The identifier is required to identify the specific instance of that object to which the data flow is directed. However, since OOA96 has eliminated access to data stores for tests and transforms, I would think such functions could be static and, therefore, would not need an instance identifier. Alas, OOA96 did not clarify this so I think we need a Major Guru Ruling to be sure there is still not some other Arcane Theoretical Reason for still including the indentifier. > > However, there is still the issue of associating a generic process with > > a particular object. For example, what if you decide the object is no > > longer needed? > > By the time I'm doing ADFDs, I'm unlikely to be adding/deleting objects. However, your point is well taken and > I will consider, in the futture, whether this type of process reuse is worth the risk you've pointed out. True, during initial development one is idealy not adding or deleting objects when doing ADFDs. As it happens, I was thinking more of system maintenance subsequent to the initial development. However, I think there are two situations where such changes might come about in practice on real projects. If your schedule is aggressive you may have to put multiple people working in parallel on a domain. In such cases one subsystem team may be significantly ahead of another, so it is possible that one team is working on ADFDs while the other is still reviewing their portion of the IM. Not a good idea, perhaps, but unfortunately sometimes a necessary compromise to schedules. The second, more common, situation arise when the contents of a domain are built iteratively. It is not unusual to develop only some of the subsystems in a domain at a time. When subsystems are developed on those later iterations it may cause changes to the IM that will affect ADFDs developed on earlier iterations. In reality it is also not uncommon for such iterations to be laid out with some overlap in the schedule so that the work on the first iteration's ADFDs may be still going on when the work on the second iteration's portion of the IM commences. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Transform Etiquette Neil Lang writes to shlaer-mellor-users: -------------------------------------------------------------------- >lahman writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >Ted Barbour wrote: >> >Ted, > >> An instance identifier isnt needed as an input for Test and Transformation processes so I'm not sure what you >> mean. > >An instance identifier is required on the data flow into *any* process >that is associated with an object. The identifier is required to >identify the specific instance of that object to which the data flow is >directed. Not true in all cases. Consider accessors such as: Find all the dogs that weigh more than xxx lbs (where xxx flows into the process on a flow labeled weight) This process has no instance identifier as input. Yet this is a process that is clearly assigned to the DOG object. >However, since OOA96 has eliminated access to data stores for tests and >transforms, I would think such functions could be static and, therefore, >would not need an instance identifier. Alas, OOA96 did not clarify this >so I think we need a Major Guru Ruling to be sure there is still not >some other Arcane Theoretical Reason for still including the >indentifier. > You're right on track here. Transformations and tests do not require instance identifiers as input (In fact I can't think of a situation in which you could want to flow an identifer into a test/transformation) Anyway consider this a Major Guru Ruling :-) ......remainder of included posting deletd Hope this is of some help. Neil ---------------------------------------------------------------------- Neil Lang nlang@projtech.com Project Technology, Inc. 510-845-1484 x23 2560 Ninth Street, Suite 214 Berkeley, CA 94710 http://www.projtech.com ---------------------------------------------------------------------- Subject: Re: (SMU) Transform Etiquette peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 09:10 AM 3/7/97 -0500, shlaer-mellor-users@projtech.com wrote: > Alas, OOA96 did not clarify this >so I think we need a Major Guru Ruling to be sure there is still not >some other Arcane Theoretical Reason for still including the >indentifier. > I seen HS make this request before - and I would like to ask a related question. Who is doing "real-world" ADFD-based process modeling out there? I know there are a lot of state-action-language shops, and sometimes there are good pearls brought up about process modeling with ADFDs. To put it another way - who can provide a Major Guru Ruling on ADFD stuff? I know OOA96 provided some good stuff on ADFD modeling - we adopted quite a bit of it straight. But even that document - very recent, and apparently with significant effort in this area (ADFDs) - had significant holes and other issues that showed up quickly once we started to apply it to "real" projects, and generate code automatically from the ADFDs. We've ended up having to refine our rules for ADFD modeling a little bit beyond OOA96. Does anyone else have a similar experience? So who are the ADFD Guru's? Sally and Steve: have you and/or your R&D elves applied the ADFD aspects of OOA96 to a complete project and executed the results? Can you tell us what "conventions" you applied? To the expert practitioners who contribute on this forum - does anyone want to step up to the ADFD Guru podium and offer guidance? (To answer HS's question from our perspective - we've adopted the convention that there are 3 basic types of processes: Wormhole, Object, and Event. Of the Object processes, Create, Find, Find, Test, and Transformation do not require object id's to flow in. Delete, Write, Read, ReadTest, FindNext, and FindPrevious do require an instance to be identified. All Object processes are allocated with one object. And yes - domain synchronous services are useful for the very reasons you outlined. We call that a Wormhole - not a Transformation.) Thanks. ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice/fax: 508-384-1392 | peterf@pathfindersol.com ext. 2 | ____________________________________________________| Subject: Re: (SMU) Transform Etiquette peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 11:37 AM 3/7/97 -0800, shlaer-mellor-users@projtech.com wrote: >You're right on track here. Transformations and tests do not require >instance identifiers as input (In fact I can't think of a situation >in which you could want to flow an identifer into a test/transformation) >Anyway consider this a Major Guru Ruling :-) Thanks Neil. And sorry for calling you an elf. ( ;-) ) (is that Guru', or Gu'ru?) ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice/fax: 508-384-1392 | peterf@pathfindersol.com ext. 2 | ____________________________________________________| Subject: Re: (SMU) Transform Etiquette lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Lang... > >An instance identifier is required on the data flow into *any* process > >that is associated with an object. The identifier is required to > >identify the specific instance of that object to which the data flow is > >directed. > > Not true in all cases. Consider accessors such as: > Find all the dogs that weigh more than xxx lbs > (where xxx flows into the process on a flow labeled weight) > This process has no instance identifier as input. > Yet this is a process that is clearly assigned to the DOG object. I knew that! Actually it was careless typing on my part. My original should have read "...associated with an instance." > You're right on track here. Transformations and tests do not require > instance identifiers as input (In fact I can't think of a situation > in which you could want to flow an identifer into a test/transformation) > Anyway consider this a Major Guru Ruling :-) A related question is whether they still need to be associated with an object in the ADFD (i.e., . identifiers). This no longer seems relevant and seems to work against generic reuse in different ADFDs. In the post-OOA96 world can these now have generic (i.e., domain-level) process identifiers instead of being wormholes? If so, what if the form of the identifier? -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) Synchronous deletion of active instances "Monroe,Jonathan" writes to shlaer-mellor-users: -------------------------------------------------------------------- Is synchronous deletion of an active instance legal per the method? Or can an active instance only be deleted by causing a transition into a terminal state? Thanks, Jonathan Monroe Abbott Laboratories - Diagnostics Division North Chicago, IL monroej@ema.abbott.com Subject: Re: (SMU) Synchronous deletion of active instances Jay Case writes to shlaer-mellor-users: -------------------------------------------------------------------- > "Monroe,Jonathan" writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Is synchronous deletion of an active instance legal per the method? It's certainly legal. The OOA96 Report (Section 9.3.1) even mentions two required forms of such accessors (man, wouldn't that there "where" form be handy :). You might want to also look at Section 8.5, which has some Q & A on instance deletion. In practice, however, one needs to be cautious about it's use. Basically, you're clobbering the poor instance pretty hard. Maybe that's OK, maybe not, depends on what you're trying to model. If the "shooter" state is dissolving relationships the "target" might have, and the "target" can cease to exist safely in any state, go for it. But these are pretty heavy assumptions, and can evolve into maintenance problems. > Or can > an active instance only be deleted by causing a transition into a terminal > state? FWIW, our internal guidelines do not preclude synchronous deletion, but (strongly) recommends the use of asynchronous events to entice the target instance to transition into a final state. This not only allows the doomed instance to get it's funeral in order (unrelates, send events to close family members, etc), but also give the intended victim a chance to refuse deletion. This can be a pain at times, since you can end up with a lot of "extra" transitions. Like everything, it's a trade off, but in most cases, a very safe one. Just my (arche-dweebic) opinion, however... > > Thanks, > > Jonathan Monroe > Abbott Laboratories - Diagnostics Division > North Chicago, IL > monroej@ema.abbott.com Subject: Re: (SMU) Synchronous deletion of active instances lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Monroe... > Is synchronous deletion of an active instance legal per the method? Or can > an active instance only be deleted by causing a transition into a terminal > state? I agree with Case's comments and would just add one amplification. If you are using a case tool with an action language, then that action language typically includes constructs to instantiate specific instance-level relationships. When an instance is deleted, these need to be removed. For active objects this is typically done in the terminal state. If you delete synchronously, then you have to take care of this at the point where the delete accessor is invoked. From an aesthetic view this can be a maintenance problem if you add a relationship to the deleted object since each action with a synchronous delete will have to be modified. Even if the relationship maintenance is left to the architecture, it will generally be simpler to have one translation rule that deals with this which is invoked when the terminal state is entered. Alas, this topic opens up a more arcane issue. It is rather common to have brain dead active objects. These are objects that would normally be passive but they are created and deleted within the application execution time frame. Since they have a life cycle in the execution time frame the methodology requires that they be active. FWIW, we generally chose to treat these as passive anyway and use synchronous create/delete on them. It is usually less trouble to maintain the relationship linking than to deal with the tool overhead of creating trivial state models. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) Transfer Vectors J.W.Terrell@nortel.co.uk writes to shlaer-mellor-users: -------------------------------------------------------------------- In the "Bridges & Wormholes" paper (Section 2, "Receiving a transfer vector"), it states that the transfer vector associated with an asynchronous return must be saved in an object in the Away domain. Is this typically an object specifically designed for the purpose (e.g. Monitor Request) or is the transfer vector more often than not assigned to an existing object (obviously one associated in some way with the asynchronous return). Any information / examples on this would be much appreciated. Regards, Jeff. -- Jeff Terrell Nortel, London Rd, Harlow, Essex, UK. +44 (0)1279 405870 J.W.Terrell@nortel.co.uk Subject: Re: (SMU) Transfer Vectors lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Terrell... > In the "Bridges & Wormholes" paper (Section 2, "Receiving a > transfer vector"), it states that the transfer vector associated > with an asynchronous return must be saved in an object in the > Away domain. > > Is this typically an object specifically designed for the purpose > (e.g. Monitor Request) or is the transfer vector more often > than not assigned to an existing object (obviously one associated > in some way with the asynchronous return). I don't know if "typically" is appropriate since this is new and previously untrammeled territory for the S-M specification. FWIW, my interpretation was that the object where the transfer vector would be stored would be a separate object from others in the domain. That is, the object that stores the transfer vector is really part of the bridge rather than the domain. Since the implementation details of the transfer vector could be different from one application to another, I would think these need to be kept separate from the basic domain subject matter. I kind of like the idea of separate bridge objects because it allows a consistent handling of "smart" bridges that have to do a lot of processing to convert bridge requests into terms that the domain can understand. Currently we do this by creating a separate interface domain that exposes these (bridge) translation details to the OOA. As I read the note, we could now include that processing and the related objects within the application domains. By their nature they would be inherently decoupled from the real subject matter processing because they would merely initiate it (rather than participate in it). So they could be easily replaced if the domain is moved to another application. If, however, you included bridge-specific data like the transfer vector in domain subject matter objects, this decoupling would not be preserved and it would start to get messy when you tried to move a domain to another application which used a different request interface. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) Component size and reliability lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- There was an interesting article in the Mar/Apr issue of IEEE Software entitled "Rexamining the Fault Density - Component size connection" by Les Hatton. He proposes a different model for relating fault density to component size. His model is based on current thinking about the way the human memory works. Basically our memory seems to work best if the short term memory cache is exactly full. That is, if you have to go back and forth to long term memory, there are problems due to different mechanisms and you make mistakes. Similarly, if the short term cache is only partially full, it works "inefficiently" and you make mistakes. Therefore one would expect that the most reliable software would be made when the size of the symbolic complexity of the component exactly matched the size of the author's short term memory cache. Hattan provided a lot of interesting data to support this model. For example, it turns out that the reliability of both assembly and Ada code peaks at about 300-400 lines per component, despite the fact that there would usually be at least five assembler lines per Ada line in functionally equivalent components. The model also accounts for some widely observed anomolies in reliability data that indicate that very small program units tend to have a disproportionate share of bugs. For example, the NAG FORTRAN library has quasi-independent routines of widely varying size and the very small and very large routines have had a consistently lower reliability than the mid-sized rotuines. Though I am personnally very skeptical that anyone really understands how the human mind works, I recommend the paper as an interesting perspective. So what has this got to do with S-M? Alas, Hattan had no data on OO projects. However, it seems to me that S-M focuses on the domain as a component. The issue then would be how big should a domain be to just naturally get maximum reliability? In a modest sized domain I submit that there are typically a few hundred objects, states, and events. If such a count is a reasonable measure of symbolic complexity, then that size should naturally maximize reliability. (Hattan indicated that the unit of complexity did not matter too much; LOC worked pretty much the same way as, say, trace path counts or function points.) Is the moral of Hattan's work that S-M domains should be lean and mean (i.e., define subject matters to yield more, smaller domains)? Or is it that the methodology should do more to define the boundaries of subsystems within domains? -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) How to Model Threads Allen Theobald writes to shlaer-mellor-users: -------------------------------------------------------------------- Please! I need help in modeling an aspect of our language: threads. The behavior is that a thread can "spawn" many threads, who can, in turn, "spawn" many threads. The behavior I am having trouble with, is that only the "parent" can "wait" on the termination of a spawned thread. That is, sibling threads cannot wait on other siblings, parents cannot directly wait for the termination of, for lack of better terminology, "grandchild" threads. How is this modeled via objects and relations? Thanks in advance, Allen Subject: Re: (SMU) Transform Etiquette Sally Shlaer writes to shlaer-mellor-users: -------------------------------------------------------------------- At 04:11 PM 3/7/97 -0500, Peter wrote: >peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >I seen HS make this request before - and I would like to ask a related >question. Who is doing "real-world" ADFD-based process modeling out there? >I know there are a lot of state-action-language shops, and sometimes there >are good pearls brought up about process modeling with ADFDs. To put it >another way - who can provide a Major Guru Ruling on ADFD stuff? I'm not prepared to make a MGR on ADFDs, but perhaps I can tell you how Steve and I and our collaborators are thinking about this subject. In OOA91, we were very focussed on understanding 'what it means to be a process'. (We were not satisfied with the loose ideas from Structured Analysis times.) Hence we tried to take everything down to the most primitive atomic level. I think we did a pretty good job answering the question, although several ideas came back to haunt us. Among those still of concern: In driving down to the atoms, we prescribed that an accessor could only access a single object data store. This had a number of happy consequences, but made lengthy relationship navigation a real chore -- lots of bubbles of limited value. We now recognize that assigning tests and transformations to objects was really a specific coloring and not necessarily what one wanted in general. We repaired some problems in OOA96, but, as Peter points out, we didn't solve everything. Also, by late 1995, it was apparent that a number of users preferred the action language approach. Hence we embarked on a project to delve fairly deeply into Process Models from an action language perspective. Our most important conclusions were: We need a more powerful way to express actions: more powerful in the sense that the analyst shouldn't need to do so much work in order to make precise statements about actions. Here we are thinking about migrate accessors, simpler ways to trace a chain of relationships, etc. We need to satisfy clients (and toolmakers) who prefer an action language approach. We also need to satisfy those who prefer a graphical approach to specifying processing. In other words, we would like to put action language and ADFDs on an equal footing (as HS has pointed out, in OOA91&6, ADFDs are the defining statement for process models, and action languages are derivative). The textual and graphical forms should be absolutely equivalent in semantics, and it should be possible to translate one form to the other absolutely accurately and in a straightforward manner. All of this has led to the following: In the RD book (yes, we **are** pedaling as fast as we can!), you will see ADFDs. These ADFDs will not assign tests and transformations to objects. We will not bear down heavily on the ADFDs (since we don't need to for the purposes of the book). In the OOA9x book (we are committed to doing a full-scale update on the analysis material immediately after the RD book), we will raise the level of the graphical rendition of process models. In due course (and I'm not saying where or when), we will produce equivalent textual and graphical forms. This will be done in such a way that it will be easy to migrate existing graphical and textual forms to a new common footing. >I know OOA96 provided some good stuff on ADFD modeling - we adopted quite a >bit of it straight. But even that document - very recent, and apparently >with significant effort in this area (ADFDs) - had significant holes and >other issues that showed up quickly once we started to apply it to "real" >projects, and generate code automatically from the ADFDs. We've ended up >having to refine our rules for ADFD modeling a little bit beyond OOA96. [snip] Peter, we would love to have your input on how you refined the ADFD rules -- either directly or through this forum. We'd also like comments and concerns from everyone else. When we are ready to make a "Major Guru Ruling", we want to make sure we have understood and assimilated all the experience and findings so that the MGR represents the summation of the community knowledge in this area. My best regards to you all, Sally Subject: Re: (SMU) Transfer Vectors J.W.Terrell@nortel.co.uk writes to shlaer-mellor-users: -------------------------------------------------------------------- > lahman writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Responding to Terrell... > > > In the "Bridges & Wormholes" paper (Section 2, "Receiving a > > transfer vector"), it states that the transfer vector associated > > with an asynchronous return must be saved in an object in the > > Away domain. > > > > Is this typically an object specifically designed for the purpose > > (e.g. Monitor Request) or is the transfer vector more often > > than not assigned to an existing object (obviously one associated > > in some way with the asynchronous return). > FWIW, my interpretation was that the object where the transfer vector > would be stored would be a separate object from others in the domain. > That is, the object that stores the transfer vector is really part of > the bridge rather than the domain. Since the implementation details of > the transfer vector could be different from one application to another, > I would think these need to be kept separate from the basic domain > subject matter. I agree that the implementation details of a transfer vector may vary from one application to another, but isn't this transparent to the application? An application simply regards a transfer vector as a data element of type "transfer vector". > I kind of like the idea of separate bridge objects because it allows a > consistent handling of "smart" bridges that have to do a lot of > processing to convert bridge requests into terms that the domain can > understand. But (and I quote) "a bridge is conceptually similar to clear pane of glass. It forms a barrier but contains nothing in the barrier". > By their nature they would be inherently decoupled from the real subject > matter processing because they would merely initiate it (rather than > participate in it). So they could be easily replaced if the domain is > moved to another application. If, however, you included bridge-specific > data like the transfer vector in domain subject matter objects, this > decoupling would not be preserved and it would start to get messy when > you tried to move a domain to another application which used a different > request interface. In the Bridges & Wormholes paper, it says that the analyst can think of the transfer vector as a partial event, i.e. an event label and instance identifier, which will be filled out with supplemental data at some future point in time. I guess it's not only possible for the transfer vector to be implemented differently from application to application, but it's also possible for the essential *content* of the transfer vector to change when, say, one service domain is replaced by another. I don't see why this should affect the client domain at all. The client simply retains a data element of type "transfer vector", whatever its form and content. For example, suppose Server A expects an event A1 to be asynchronously returned by its client. The transfer vector passed to the client therefore includes the event label A1. If Server A is replaced by Server B, it's possible for B to require a different asynchronous return, B1 say. Thus the transfer vector passed to the client now includes the event label B1. Does the client really care whether it's storing A1 or B1? Is the client's behaviour different in the 2 cases? I don't think that it is. I stand to be corrected on all this. Many thanks for your comments anyway. Regards, Jeff. -- Jeff Terrell Nortel, London Rd, Harlow, Essex, UK. +44 (0)1279 405870 J.W.Terrell@nortel.co.uk Subject: Re: (SMU) Transfer Vectors J.W.Terrell@nortel.co.uk writes to shlaer-mellor-users: -------------------------------------------------------------------- > I agree with your basic point. My issue is more around the existence of > the transfer vector. Related to my point about protocols above, suppose > the original client domain, A, made three separate requests requiring > event returns A1, A2, and A3. Now suppose the new context, client > domain B, recovers the identical semantics with two requests requiring > event returns B1 and B2. The data packets for A1, A2, and A3 contain, > together, exactly the same information as the data packets for B1 and > B2. However, the number of transfer vectors has changed since the > bridge's protocols have changed. I contend that the domain internals > should not know about this. There's a comment in Bridges & Wormholes about this very thing (p14, "What if there is no match for a wormhole?"). It recognises the fact that server domains may be produced before client domains and that mismatches can be fixed in either the client domain or the server domain. In your example, it would seem sensible to fix the mismatch in client B, since client A already matches the server. Regards, Jeff. -- Jeff Terrell Nortel, London Rd, Harlow, Essex, UK. +44 (0)1279 405870 J.W.Terrell@nortel.co.uk Subject: Re: (SMU) Transfer Vectors peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 10:27 AM 3/13/97 GMT, shlaer-mellor-users@projtech.com wrote: >J.W.Terrell@nortel.co.uk writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >In the "Bridges & Wormholes" paper (Section 2, "Receiving a >transfer vector"), it states that the transfer vector associated >with an asynchronous return must be saved in an object in the >Away domain. > >Is this typically an object specifically designed for the purpose >(e.g. Monitor Request) or is the transfer vector more often >than not assigned to an existing object (obviously one associated >in some way with the asynchronous return). > In an architecture I collaborated on in the 94-95 timeframe, we needed the ability to do something like a "transfer vector", but we implemented it as "Indirect Events". Basically, an event generate generally has 2 steps bundled together: bundle up the data into an event, and then send the event. An "Indirect Event" is one where these steps are split up. You can create the event (with an Architecture service), and then treat it as an atomic clump of data - for instance: store it as an attribute, pass it as a data item of another event, or even pass it to another domain through a wormhole (since an "Event" is a system-level concept). Later, whoever ends up with this IndirectEvent atom can then call another Architecture service to send it (the second half of the generate process). The IndirectEvent has been a part of every architecture I've done since, and I consider it to be a must-have feature. If you want more details on this concept, let me know. It's not exactly the same as the "transfer vector", but with some flexibility that you have with when you fill in destination and/or data items, it is quite powerful. We find IndirectEvents reduce the complexity of our models significantly in some cases. ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice/fax: 508-384-1392 | peterf@pathfindersol.com ext. 2 | ____________________________________________________| Subject: Re: (SMU) Transform Etiquette peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 08:19 PM 3/13/97 PST, shlaer-mellor-users@projtech.com wrote: >Sally Shlaer writes to shlaer-mellor-users: >-------------------------------------------------------------------- >> We've ended up >> having to refine our rules for ADFD modeling a little bit beyond OOA96. > >[snip] > >Peter, we would love to have your input on how you refined the ADFD >rules -- either directly or through this forum. Thank you for the invitation. In consideration of bandwidth and attention spans, I'll summarize what Pathfinder Solutions developed as Process Modeling conventions, and if you want more detail, you can download our "OOA Modeling Guide" from our web site. (If you *are* interested, please don't try to divine details from the poor summaries below - see section 10 of the Modeling Guide - thanks.) a) "No transients" To maintain conciseness in ADFDs and avoid absure attributes, we support that event data items and transients can have ranges of value independent from object attributes, and are analysis concepts in their own right. b) Flow Elements To help define the constitution of data flows and specify their proper use, we define a Process Modeling vocabulary which includes the concepts of data flow element type. Flow elements correspond to attributes, event data items, transients, or literals. c) Specific Process Types/Flow Combinations In OOA96 table 9.1 was saw two dimensions of process distinction blended into the "Type and form name" column - process type, and flow composition. We have defined the following base process types: Wormhole, Create, Read, Write, Delete, Find, Test, Transformation, Generate, Cancel, and ReadTime. (As a convenience to reduce ADFD bulk, we added FindNext, FindPrevious, and ReadTest.) We significantly restrict the semantics of the Find process type - the "stated criteria" can only be a match (==) of a subset of attributes. For each process type, we rigorously define the combinations of flow elements permitted/required, and specify the supported content of conditional control outputs where permitted. We also firm up the application of multiple flows, and provide specific rules for their use. This includes a specific interpretation for the refined meaning of each process type for each legal combination of multiple inputs/outputs. All of this has left us in a position where we can generate the behavior for all process types - no process bodies or definitions required - except Wormhole and Transformation (they are manually specified). Any architecture has a sufficiently rigorous definition of each process based on process type and the flow topology to provide all process functioning. Thanks for the opportunity to share this. The OOA Modeling Guide is a very wandering collection tips, conventions, rules, extensions, and anything else that might be useful and isn't specific to our tool set (except appendix A). We apologize where appropriate for the lack of clarity, conciseness, or examples. This document will soon split into higher-level versus lower-level foci. ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice/fax: 508-384-1392 | peterf@pathfindersol.com ext. 2 | ____________________________________________________| Subject: Re: (SMU) Transfer Vectors lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Terrell... > There's a comment in Bridges & Wormholes about this very thing > (p14, "What if there is no match for a wormhole?"). It recognises the > fact that server domains may be produced before client domains and > that mismatches can be fixed in either the client domain or the server > domain. > > In your example, it would seem sensible to fix the mismatch in client B, > since client A already matches the server. This all depends upon what "fixed in...domain" means. I contend that if this means fixed in an object that is part of the domain subject matter, then the domain is not truly reusable. That is, you would not be able to port the domain without reverifying the correctness of the domain logic itself in the new context (i.e., rerun the entire domain simulation suite at a minimum). If, however, the domains have separate bridge objects that contain the transfer vector, these could be fixed for each application without affecting the subject matter objects in the domain. In this case you would only have to verify that the bridges worked correctly. As an example of the importance of this, consider two applications using the same architecture. A domain could consist of two DLLs that are linbked into the application together, one for the domain logic and one for the domain's bridges. In my scheme the domain logic DLL would not have to be rebuilt -- it could be linked in as is; the only new software would be the bridge DLL. If, instead, the transfer vector were held in domain subject matter objects, then that DLL would have to be rebuilt (referring to my protocol change example) and, therefore, reverified. As I indicated before, IMHO Bridges & Wormholes has too narrow a focus in concentrating on strictly data semantic issues. If the bridge does not handle protocol differences, then it probably does not make much difference where the transfer vector is stored because it will be invariant with domain implementation. However, if one does not allow the bridge to handle protocol differences, then one no longer has an advantage over mechanisms like dynamic polymorphism for decoupling -- if you change the external interface to the domain subject matter (e.g., the place where the transfer vector is stored), then you potentially affect every application that includes that domain. Point of clarification: conceptually I see a domain as two entities. The first is the subject matter which is described in the OOA. This has its own interface to the domain boundary or shell that should be invariant with the application context. The second is the domain interface or shell (suite of bridges) that provides an interface to the outside world. This is application specific and provides the semantic and protocol translations that are necessary to accommodate specific applications. This is effectively an application-specific wrapper around the invariant domain subject matter implementation. I just want to keep the application specific information in objects that are associated with the domain interface rather than keeping it within the bounds of the domain's subject matter interface. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) How to Model Threads peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 01:31 PM 3/13/97 +0000, shlaer-mellor-users@projtech.com wrote: >Allen Theobald writes to shlaer-mellor-users: >The behavior is that a thread can "spawn" many threads, who >can, in turn, "spawn" many threads. The behavior I am having >trouble with, is that only the "parent" can "wait" on the >termination of a spawned thread. That is, sibling threads >cannot wait on other siblings, parents cannot directly wait >for the termination of, for lack of better terminology, "grandchild" >threads. > >How is this modeled via objects and relations? > How about: Thread + | isa ----------|------------- | | ParentThread ChildThread | (1) |(mc) -----------R1------------ is spawned from/can wait for I must be missing the thrust of the question - ? ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice/fax: 508-384-1392 | peterf@pathfindersol.com ext. 2 | ____________________________________________________| Subject: (SMU) Re: reflexive relationships Peter Nau writes to shlaer-mellor-users: -------------------------------------------------------------------- I sent the following email to Dave Whipp recently, and his response follows. I decided to post our dialog, because I found Dave's response helpful and in case anyone else wants to comment. ---------------------------------------------------- Dear Dave: A while back, you posted the following on the S-M mailing list: > > Dave Whipp writes to shlaer-mellor-users: > ---------------------------------------------------------------------- > > Yves van de Vijver wrote: > > > I have a question on symmetric reflexive relation- > > ships in OOA as presented in OOA'96. > [...] > > Now what if I send an event to Work Partner. I should > > state the identifying attributes, but should I > > state them necessarily in the right order? > > And if I would like to send an event to all Work Partners > > of an Employee X, should my process model access > > the WorkPartners store through two distinct processes, > > one to match Employee1 = Employee X, and one to > > match Employee2 = Employee X? > > I have given this some thought. The best solution I can think > of is to put the burden on the architecture and its definition > of an event generator to such an associative object. That is, > you can draw your ADFD (or write ASL) making the assumption > that, because the architecture knows that the relationship is > special, it can imply that the identifier of the associative > object is special (it is the formalising attribute(s) of the > relationship) and can therefore correctly deliver the event. > > There is a similar issue whenever the identifier of the > associative object is used. The attributes from each employee > are interchangeable, and any search/access operation must be > aware of this. > > Incidentally, this problem would be compounded if you wanted a > symmetric reflexive relationship between more than two > employees. > > Personally I would use a Work-Group object that is > related to one or more employees (possibly with an > associative object). Then, one employee is a partner of > another if they are both members of the same workgroup. > I have actually come to view any reflexive relationship > with distrust. They seem to cause more trouble than is > justified by the abstractions they represent. They can > always be eliminated through the introduction of a > "node" object, which generally produces a more stable > model and frequently does not increase the number of > objects. We recently purged the last remaining reflexive > relationship from our models because of the potential > maintenance problems. > > Dave. Could you please explain your method of eliminating reflexive relationships using a "node" object? Following is my problem: I am conducting a pilot project (in my company) for code generation using Project Technology's MC-2010 Model Compiler. The generated code will run on a PC and will act as a memory monitor for an embedded processor to which it is attached by slow serial link. The embedded processor has about 64K of RAM, in contrast with the host PC's 8-16 mbyte RAM. My OOA model has an object called RAMbyte, each instance of which corresponds to a byte in the embedded processor's memory. RAMbyte has a reflexive relationship to itself: proceeds/follows. A RAMbyte has the following attributes: * RAMbyteAddress - RAMbyteAddress(R3) - RAMimageID(R2) - value - isUninitialized - isWriteable - hasBeenEdited, etc... R2 is a many-to-one relationship to a RAMimage, which I guess you'd call the collection of RAMbytes. I'll need to do random access on the RAMbyte instances so that they can be edited arbitrarily. I expect there will be a performance problem, since the architecture as it presently stands will have to search a list to find the correct RAMbyteAddress. One good solution is to color objects involved in reflexive relationships so that they are implemented as arrays of structures, providing fast indexed access. This will, however, involve some possibly time-consuming architecture work I'd prefer to avoid. In summary, I'm trying to find a good (and simple) way to gain fast random access to RAMbytes, and, as you have suggested, purging my model of reflexive relationships may be the solution. [...] Peter Nau Ventritex, Inc. Sunnyvale, California email: pnau@ventritex.com voice: 408 522-6882 fax: 408 738-0955 ------------------------------------------------------------------------- ---- Dave's response: >From whipp@Roborough.gpsemi.com Mon Mar 10 03:54:14 1997 Received: from mail5.netcom.com by uu4.psi.com (5.65b/4.0.940727-PSI/PSINet) via SMTP; id AA11640 for PNAU; Mon, 10 Mar 97 03:54:14 -0500 Received: from gpgate.sv.gpsemi.com (gpgate.gpsemi.com [144.168.150.1]) by mail5.netcom.com (8.6.13/Netcom) id AAA10353; Mon, 10 Mar 1997 00:54:09 -0800 Received: from roborough.gpsemi.com (roborough.gpsemi.com [144.168.48.112]) by gpgate.sv.gpsemi.com (8.6.12/8.6.12) with SMTP id AAA28538 for ; Mon, 10 Mar 1997 00:54:00 -0800 Received: from psupw46.roborough.gpsemi.com (psupw46.roborough.gpsemi.com [144.168.72.46]) by roborough.gpsemi.com (8.6.12/8.6.12r) with ESMTP id IAA25624 for ; Mon, 10 Mar 1997 08:54:58 GMT From: David.Whipp@gpsemi.com (Dave Whipp) Received: (whipp@localhost) by psupw46.roborough.gpsemi.com (8.6.9/8.6.9) id IAA06562 for PNAU@ventritex.com; Mon, 10 Mar 1997 08:53:52 GMT Date: Mon, 10 Mar 1997 08:53:52 GMT Message-Id: <199703100853.IAA06562@psupw46.roborough.gpsemi.com> To: PNAU@ventritex.com Subject: Re: Reflexive relationships > My OOA model has an object called RAMbyte, each instance of which > corresponds to a byte in the embedded processor's memory. RAMbyte has > a reflexive relationship to itself: proceeds/follows. I'm afraid I'm not going to answer the question that you asked. I'm going to suggest that you probably don't need a relationship here at all. What is the purpose of having a relationship to tell you the order of bytes? There may be several reasons, such as Seq-mode accesses or endian-ness. However, I think that in this case you just want to be able to look up bytes, given an address. If that is the case then you should just use an accessor to do the look up. It is the architecture's responsibility to ensure that such a look-up meets performance constraints. In general, an attempt to model a linked-list in SM is the result of implementation biased thinking and is unnecessary. You already have a sortable primary identifier: there is no need to reinforce it. > R2 is a many-to-one relationship to a RAMimage, which I guess you'd call > the collection of RAMbytes. This is an example of what I meant by eliminating reflexive relationships using 'node' objects. The RAMimage is a node that refers to many RAMbytes. The reflexive version would have been to have a relationship "is part of same RAMimage" with an assoc object that names the RAM image. Very messy. > I'll need to do random access on the RAMbyte instances so that they > can be edited arbitrarily. I expect there will be a performance > problem, since the architecture as it presently stands will have to > search a list to find the correct RAMbyteAddress. > > One good solution is to color objects involved in reflexive > relationships so that they are implemented as arrays of structures, > providing fast indexed access. This will, however, involve some > time-consuming architecture work I'd prefer to avoid. You either have to put the work in the model or in the architecture. However, if you put it in the architecture then you can get a version 1.0 system working before you do the [other] work. You might want to consider whether sorted access is really necessary -- would the system work just as well with unordered RAMbytes. > In summary, I'm trying to find a good (and simple) way to gain fast > random access to RAMbytes, and, as you have suggested, purging my > model of reflexive relationships may be the solution. Eliminating reflexive relationships won't necessarily improve performance. It may, however, simplify the model. Dave. -- David P. Whipp. Not speaking for: ------------------------------------------------------- G.E.C. Plessey Due to transcription and transmission errors, the views Semiconductors expressed here may not reflect even my own opinions! Subject: RE: (SMU) How to Model Threads "Nguyen, Dan" writes to shlaer-mellor-users: -------------------------------------------------------------------- > >>At 01:31 PM 3/13/97 +0000, shlaer-mellor-users@projtech.com wrote: >>>Allen Theobald writes to shlaer-mellor-users: > >>>The behavior is that a thread can "spawn" many threads, who >>>can, in turn, "spawn" many threads. The behavior I am having >>>trouble with, is that only the "parent" can "wait" on the >>>termination of a spawned thread. That is, sibling threads >>>cannot wait on other siblings, parents cannot directly wait >>>for the termination of, for lack of better terminology, "grandchild" >>>threads. >>> >>>How is this modeled via objects and relations? >>> >> >> >>How about: > >> Thread >> + >> | isa >> ----------|------------- >> | | >> ParentThread ChildThread >> | (1) |(mc) >> -----------R1------------ >> is spawned from/can wait for>> >> >> >>I must be missing the thrust of the question - ? How about a ChildThread can also be a ParentThread. Dan Nguyen Aerial Communications Subject: Re: (SMU) How to Model Threads Greg Eakman writes to shlaer-mellor-users: -------------------------------------------------------------------- Nguyen, Dan wrote: > > "Nguyen, Dan" writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > > > >>At 01:31 PM 3/13/97 +0000, shlaer-mellor-users@projtech.com wrote: > >>>Allen Theobald writes to shlaer-mellor-users: > > > >>>The behavior is that a thread can "spawn" many threads, who > >>>can, in turn, "spawn" many threads. The behavior I am having > >>>trouble with, is that only the "parent" can "wait" on the > >>>termination of a spawned thread. That is, sibling threads > >>>cannot wait on other siblings, parents cannot directly wait > >>>for the termination of, for lack of better terminology, "grandchild" > >>>threads. > >>> > >>>How is this modeled via objects and relations? > >>> > >> > >> > >>How about: > > > >> Thread > >> + > >> | isa > >> ----------|------------- > >> | | > >> ParentThread ChildThread > >> | (1) |(mc) > >> -----------R1------------ > >> is spawned from/can wait for>> > >> > >> > >>I must be missing the thrust of the question - ? > > How about a ChildThread can also be a ParentThread. > > Dan Nguyen > Aerial Communications This is similar to an example I've seen published somewhere, modeling a Bulls eye target, where one ring is always outside the another, except for the center. I can't find the reference right now, but it may have been OOA '96. Thread <------------------ is spawned by + | | isa | R1 ----------|------------- | | | | RootThread ChildThread<<--- C spawns This is a very slick pattern that I've found useful in a few places in modeling. Here, there is a thread that is the root thread and can spawn child threads, which, being threads, can again spawn children, etc. Only the root thread has no parent. Ciao Greg -- Greg Eakman email: eakman@atb.teradyne.com Teradyne, ATB Phone: (617)422-3471 179 Lincoln St. FAX: (617)422-3100 MS L50 "The two most common things in the Boston, Ma. 02111 universe are hydrogen and stupidity." Subject: Re: (SMU) Sender: owner-shlaer-mellor-users@projtech.com LurchBaker@aol.com writes to shlaer-mellor-users: -------------------------------------------------------------------- Could you re-send your message? Subject: Re: (SMU) How to Model Threads lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Peter, > Thread > + > | isa > ----------|------------- > | | > ParentThread ChildThread > | (1) |(mc) > -----------R1------------ > is spawned from/can wait for I believe the problem is that the spawning relationship and the waiting relationship are different. Though both are conditional, a parent can spawn without waiting so the conditionality is different. Therefore you need two separate relationships to describe the problem. The trick is that both relationships have to resolve to the same child instance. The second problem is that if threads are nested, the same thread could be both a parent and a child. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) How to Model Threads lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Greg, > This is similar to an example I've seen published somewhere, modeling > a Bulls eye target, where one ring is always outside the another, > except for the center. I can't find the reference right now, but it > may have been OOA '96. > > Thread <------------------ is spawned by > + | > | isa | R1 > ----------|------------- | > | | | > RootThread ChildThread<<--- C spawns > > This is a very slick pattern that I've found useful in a few places > in modeling. Here, there is a thread that is the root thread and can > spawn child threads, which, being threads, can again spawn children, > etc. > Only the root thread has no parent. Alas, I don't think this works in this case. The problem is that if threads are nested a thread can be both a parent and a child. I posted an answer for this one but it seems to have gotten lost. I think you have to go with a self-directed relationship and an associative object: +-------+ | | R1 +----------+ | Thread|<---------+ | | | | |<------| Progeny | | |<<--------+ |Definition| +-------+ +----------+ ^ ^ | R2 | +----------------------------+ where R1 is 1:Mc::is spawned by:spawns and R2 is 1:1c::blocks:waits for child from Of course it would be helpful if the relational identifiers in Progeny Definition were some useful like Parent Thread and Child Thread. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) How to Model Threads lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Greg Eakman and I have debated this offline and have come to the conclusion that our solutions were both missing elements and need to be combined. R3 = R1 + R2 +---------------------------------------+ | | v R2 | Thread <-------------------+ v | | v +-------------+ R1 |<------ Progeny Definition | | | Root Thread Child Thread <<-----+ where R2 is 1:Mc::is spawned by:begets and R3 is 1:Mc::defines child for:waits for child from and R1 is subtyping One needs the Root Thread to describe the recursive nature of nested threads. This effectively allows a Thread to be both a parent and a child at the same time (but the root honorable ancestor cannot be a child). However R2 cannot serve both begetting and waiting since the set yielded be R2 for spawning could be a different set than that yielded by R2 for waiting. So we still need the associative object. The R3 relationship must be composed because otherwise one cannot preserve referential integrity since the identifiers in Progeny Definition will look like: *Parent Thread ID (R2) *Child Thread ID(R2) -Waiting Parent ID (R3) In the case where A spawns B which spawns C, from the IM there is nothing to prevent instantiating an R3 relationship between A and C (i.e., my suggestion of using informative names was a descriptive kludge while this enforces it). To avoid this possibility explicitly, one needs the composed relationship. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) How to Model Threads Thomas Brennan-Marquez writes to shlaer-mellor-users: -------------------------------------------------------------------- lahman wrote: > > lahman writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Greg, > > > This is similar to an example I've seen published somewhere, modeling > > a Bulls eye target, where one ring is always outside the another, > > except for the center. I can't find the reference right now, but it > > may have been OOA '96. > > > > Thread <------------------ is spawned by > > + | > > | isa | R1 > > ----------|------------- | > > | | | > > RootThread ChildThread<<--- C spawns > > > > This is a very slick pattern that I've found useful in a few places > > in modeling. Here, there is a thread that is the root thread and can > > spawn child threads, which, being threads, can again spawn children, > > etc. > > Only the root thread has no parent. > > Alas, I don't think this works in this case. The problem is that if > threads are nested a thread can be both a parent and a child. > > I posted an answer for this one but it seems to have gotten lost. I > think you have to go with a self-directed relationship and an > associative object: > > +-------+ > | | R1 +----------+ > | Thread|<---------+ | | > | | |<------| Progeny | > | |<<--------+ |Definition| > +-------+ +----------+ > ^ ^ > | R2 | > +----------------------------+ > FWIW, I think the supertype/subtype solution works fine. That construct allows for a thread that is both parent and child. I have also used this pattern and found it quite useful. Seems to me it's a bit clearer than the associative object solution. Thomas Subject: (SMU) Re: How to Model Threads Allen Theobald writes to shlaer-mellor-users: -------------------------------------------------------------------- Thanks to both of you for your solution. I seemed to be close to the mark on this, but not close enough. I believe I am there now thanks to you. Your time on this is much appreciated. Best Regards, Allen lahman wrote: > > lahman writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Greg Eakman and I have debated this offline and have come to the > conclusion that our solutions were both missing elements and need to be > combined. > > R3 = R1 + R2 > +---------------------------------------+ > | | > v R2 | > Thread <-------------------+ v > | | v > +-------------+ R1 |<------ Progeny Definition > | | | > Root Thread Child Thread <<-----+ > > where R2 is 1:Mc::is spawned by:begets > and R3 is 1:Mc::defines child for:waits for child from > and R1 is subtyping > > One needs the Root Thread to describe the recursive nature of nested > threads. This effectively allows a Thread to be both a parent and a > child at the same time (but the root honorable ancestor cannot be a > child). However R2 cannot serve both begetting and waiting since the > set yielded be R2 for spawning could be a different set than that > yielded by R2 for waiting. So we still need the associative object. > > The R3 relationship must be composed because otherwise one cannot > preserve referential integrity since the identifiers in Progeny > Definition will look like: > > *Parent Thread ID (R2) > *Child Thread ID(R2) > -Waiting Parent ID (R3) > > In the case where A spawns B which spawns C, from the IM there is > nothing to prevent instantiating an R3 relationship between A and C > (i.e., my suggestion of using informative names was a descriptive kludge > while this enforces it). To avoid this possibility explicitly, one > needs the composed relationship. Subject: Re: (SMU) Transfer Vectors J.W.Terrell@nortel.co.uk writes to shlaer-mellor-users: -------------------------------------------------------------------- > lahman writes to shlaer-mellor-users: > -------------------------------------------------------------------- > Point of clarification: conceptually I see a domain as two entities. > The first is the subject matter which is described in the OOA. This has > its own interface to the domain boundary or shell that should be > invariant with the application context. The second is the domain > interface or shell (suite of bridges) that provides an interface to the > outside world. This is application specific and provides the semantic > and protocol translations that are necessary to accommodate specific > applications. How is this modeled? And how do you capture the relationships between the objects in the interface part and the objects in the subject matter part of a domain? Is it clear where one part ends and the other part begins? The fundamental issue here is whether bridges should contain anything. I worked on a project last year where the bridges contained all manner of functionality. This came about because the (non-OOA) server domains were developed before the application domain. I didn't know where to put the protocol translations that were required, so I stuck them in the bridge. The trouble is, all manner of non-OOA techniques were used to specify them. With the next project, I would like to move to a position which I think is closer to what S-M are advocating, i.e. put nothing in bridges, put behaviour to handle mismatches between domains in domains. I'd be most grateful if someone from PT would comment on the recent discussions on this issue. Many thanks. Regards, Jeff. -- Jeff Terrell Nortel, London Rd, Harlow, Essex, UK. +44 (0)1279 405870 J.W.Terrell@nortel.co.uk Subject: Re: (SMU) Transfer Vectors David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: -------------------------------------------------------------------- > J.W.Terrell@nortel.co.uk writes to shlaer-mellor-users: > How is this modeled? And how do you capture the relationships between > the objects in the interface part and the objects in the subject matter > part of a domain? Is it clear where one part ends and the other part > begins? > > The fundamental issue here is whether bridges should contain anything. > I worked on a project last year where the bridges contained all > manner of functionality. This came about because the (non-OOA) server > domains were developed before the application domain. I didn't know > where to put the protocol translations that were required, so I stuck > them in the bridge. The trouble is, all manner of non-OOA techniques > were used to specify them. I will touch on this issue in my talk at this year's SMUG. It is generally true that bridges tend to be fairly structured. For example, when a service domain has an object that is mapped to many differnet counterpart objects in the application domain then this can be described by a 1:M relationship. The mappings naturally form an associative object on this relationship. Furthermore, the highly structured nature of the bridge leads to simple code generation of the bridges. Complex bridges have many different mapping, thus many tables. They are all describing the same subject matter (the bridge) so it is natural to consider the bridge as a domain and build its information model. Note that it is a meta-model - attribute-domains may be function names (to an implementation domain) or synch-serivce names (to an SM domain). But where is this domain in the domain chart? My personal preference is to use the concept of an "associated domain" that is attached to a bridge arc on the domain chart. This is analagous to attaching an "associative object" to a relationship arc on an OIM. Lahman's suggestion of an shell-domain is a slightly different concept. Essentially, the shell is an independent domain, connected to the main domain via a bridge. Its a highly useful concept that simplifies the other domains and the bridges. Once you accept that it is useful to build an OIM of the bridge, and that it forms a domain that describes the bridge, then you can start thinking about putting state information into the domain. In light of the PT statement that bridges are like "a pane of glass", I have been reluctant to place state models in the bridge. However, some services do require synchronisation. I currently put this sychronisation in either the server or client domains, but it doesn't always seem to belong there. The other reason for being reluctant to put state information in the bridge is that this would require more advanced code generation. I currently do not use our main code generator to construct bridges. This is because the bridges are independent of the architecture (and need to be used with the simulator). Generating a "switch" statement from a table requires only a simple perl script. Dave. -- David P. Whipp. Not speaking for: ------------------------------------------------------- G.E.C. Plessey Due to transcription and transmission errors, the views Semiconductors expressed here may not reflect even my own opinions! Subject: Re: (SMU) Transfer Vectors lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Terrell... > How is this modeled? And how do you capture the relationships between > the objects in the interface part and the objects in the subject matter > part of a domain? Is it clear where one part ends and the other part > begins? Now that is a good question. Since the wormholes paper did not indicate whether the object containing the transfer vector is a bridge object or a mainline domain object, there is no precedent. FWIW, with my view that the object should be a bridge object, I would argue that the bridge objects are modeled separately from the mainline domain objects. At a minimum the domain objects would still communicate with ternminals on the OCM, rather than with bridge objects directly. This would ensure that the domain was an entity that was application independent. The precedent for separate representation is that bridges are already regarded as part of the architecture, so this would be nothing new. I would also expect that the objects are effectively passive because the bridge should have no non-deterministic flow of control. That is, it should be a deterministic translation of semantic and protocol detail, such as converting millivolts to volts and providing local persistence so that, say, two incoming events can be combined into a single outgoing event. This makes the bridge kind of special because there may be significant processing for the interface translation, but it is not associated with active objects. I see this as another reason for a separate bridge notation to capture bridge opbjects that probably has more restrictive rules than an OOA. > The fundamental issue here is whether bridges should contain anything. > I worked on a project last year where the bridges contained all > manner of functionality. This came about because the (non-OOA) server > domains were developed before the application domain. I didn't know > where to put the protocol translations that were required, so I stuck > them in the bridge. The trouble is, all manner of non-OOA techniques > were used to specify them. We have long been advocates of keeping bridges simple. Past experience has indicated that smart bridges, precisely because of the lack of discipline, tend to be the least reliable parts of the system. However, I believe much of the problem arises because smart bridges tend to start off simple and as processing is added there is a strong risk of sneaking in dynamic flow-of-control that more properly goes in an OOA domain. For example, we had a case where a hardware interface bridge became inordinately bright when it was discovered that there was a signal-to-noise problem with the hardware. This introduced a bunch of code for averaging, signal splitting, and the like that wound up in the bridge because the client just wanted a measured value back and could care less about the hardware's s-t-n ratio problems. Before you knew it the bridge was doing scaling, error checking, and all sorts of other hardware control stuff all on its own. The 20/20 hindsight was that we should have introduced a new interface domain to expose all of that in an OOA. > With the next project, I would like to move to a position which I think > is closer to what S-M are advocating, i.e. put nothing in bridges, put > behaviour to handle mismatches between domains in domains. If you are referring to creating new domains to deal with serious interface mismatch problems (e.g., domain A wants to talk to domain B but because of interface mismatches, so you want to introduce domain C such that A -> C -> B), then I agree that is a viable solution. It would be particularly appropriate when the translation required complex processing and local persistence between requests. However, I would not like the idea of using mainline domain objects for any such adjustments. This essentially would defeat the reuse of the domain because its subject matter objects would be co-opted into providing application-specific support. In between these is the idea of a bridge that is capable of handling simple mismatches. A classic case is the VXI Plug&Play standard for integrating VXI instruments into a framework. The standard provides a rather broad framework for defining interfaces, but it is by no means Plug&Play because if you swap one intrument for another with identical functionality you have to make code changes in the framework. This is because the API functions will have different names, there may be multiple functions where a single one was used previously, and the parameters may be somewhat different. VXI P&P ensures that all instruments supply *essentially* the same interface (e.g., a suite of Setup functions that are separate from, say, the Measure functions) but the details are quite different. [Though VXI P&P defines a synchronous C API, it partitions the functions so along asynchronous lines so that setup, measurement, and result recovery may be invoked spearately.] If the instrument drivers and the framework are OOA domains, it should be possible to build them so that they are all invariant with the application. The framework should be able, for example, to make a generic Measure request of a DMM that would not require code changes in the framework when a different vendor's DMM is substituted in the system. The bridge should be able to handle the details of translating a framework's basic request to the specific instrument driver's API calls even though it requires some small protocol changes such as replacing two Setup function calls for meter A with a single function call for meter B. [Of course these function calls are an implementation issue and would be modeled as events.] In my view the VXI P&P standard is an excellent example of the sort of elementary translation capability a bridge should be able to provide. At the same time I think the notation should be severely restricted so that you can't start throwing in flow-of-control stuff. The wormholes paper has restricted the notation to the point where small protocol changes cannot be accommodated. If it were used literally one would have to insert mini-domains between the framework and each of the VXI P&P instrument drivers. > I'd be most grateful if someone from PT would comment on the recent > discussions on this issue. Funny you should mention that! -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) priority queue kearnan@Summa4.COM (Gregg Kearnan) writes to shlaer-mellor-users: -------------------------------------------------------------------- I am having a problem drawing the line between "application rules" and "implementation" for the following problem: We have a "Status" domain which will accept status postings from all other domains. To a client domain, a bridge call might appear as Status.Post(DISK_ERROR). In the bridge, a table might map the posted status to a priority: DOMAIN STATUS | PRIORITY ----------------------------- COMM_LINK_ERROR | HIGH DISK_ERROR | MEDIUM . . . We might receive COMM_LINK_ERRORs from more than one client domain. All of these errors are priority HIGH. We intend to queue up all status postings, and display (on LEDs) only the highest priority posting. At this point, we are allowing more than one posting of a given priority (more than one HIGH priority, more than one MEDIUM...). The status domain should not have to maintain information as to which client actually made the posting. Some time after posting a status, the client domain might want to clear the status (remove the post). This seems to imply that the service domain would have to return a handle by which the client can refer to the post. I have a few questions: The concept of a "queue" seems to be an implementation issue. It is an ordered set of objects. For this question, refer to the following IM: displays highest priority LED_display Status_post *ID <--------------------> *ID -number_LEDs R1 c -priority -displayed_post(R1) where there is a pool of Status_post objects, and only one is being displayed (one LED_display object). Whenever an event came across the bridge, it might be mapped to the LED_display object, which would create a Status_post object (maybe return its ID to the client domain????) determine if its priority was higher than the priority of the currently displayed post, and if so delete the current R1 and create a new R1 to the new Status_post. If a request to remove a post arrived, the LED_display would find the requested Status_post. If this is the displayed post, then R1 would be deleted along with the Status_post object, and the Status_post with the next highest priority would be displayed (new R1). In action language, the goal is to *not* use loop counters because this prevents a multiprocessing implementation. Can I simply state: "find one Status post with the highest priority" (If so, what is a typical action language statement for this?) OR - do I have to "find many" and then iterate through all of them to find the highest priority. If I have to iterate, do I start with a "test priority" of HIGH, look through all the objects, and then lower the test priority and look again until I find the highest priority post? This is an ugly solution. I know that my implementation could easily keep an ordered link list, and I would always use the top of the list. Is there an IM that would better represent this problem? Should the concept of an ordered list be modelled? How do I deal with the problem of a unique handle by which the client can refer to its posting? This seems to be a counterpart to asyncronous returns in OOA96, with the service providing the handle instead of the client. Any help would be appreciated. Gregg Subject: Re: (SMU) priority queue David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: -------------------------------------------------------------------- kearnan@Summa4.COM (Gregg Kearnan) wrote: > In action language, the goal is to *not* use loop counters because this > prevents a multiprocessing implementation. Can I simply state: > > "find one Status post with the highest priority" (If so, what is a > typical action language statement for this?) This is the correct way to think about it. The implementation of the (accessor) process should not effect the model. Unfortunately, there is no standard action language. The action language of our CASE tool does not support this concept. I tend to find myself using various ugly solutions that provide an inline implementation (for simulation purposes) along with [meta]-comments that give the specification. I tell myself that I could have our code generator recognise the comment and do an optimisation (though we have yet to implement this capability). I think you will have to ask your CASE vendor (or potential vendor, if you are evaluating tools) how they handle this. I would not advise you to start messing up the macro-structure of the model to work around this particular tool limitation. (This is only one of many weaknesses to be found in the various action language implementations - my action specifications tend to have quite a few cases of implementation biased code with meta-comments). Dave. -- David P. Whipp. Not speaking for: ------------------------------------------------------- G.E.C. Plessey Due to transcription and transmission errors, the views Semiconductors expressed here may not reflect even my own opinions! Subject: Re: (SMU) priority queue lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Kearnan... > Can I simply state: > > "find one Status post with the highest priority" (If so, what is a typical action language > statement for this?) First, let's start with the ADFD representation since it is generic. The process you describe is just a fancy filter accessor and could be represented with a single process bubble in the ADFD. Note that this makes it independent of whether the data store is a queue or not since that implementation is buried in the process bubble. [As OOA96 points out, such accessor extensions *might* place some extra constraints on the architecture, though in this case I doubt that.] Alas, the action language is tool specific. Many support accessors with a simple . notation, which doesn't help you do complex filters. But they typically also have some sort of find...where... construct for getting instances. Most tools also seem to have support for synchronous services that can be associated either with domains or with objects. Generally these are used for transforms, but typically the syntax doesn't make any distinction, so you could use them as accessors. In effect they are just a surrogate for a single ADFD process bubble. Thus you would probably have a one line statement invoking the service or the find function in the state action or bridge routine. > OR - do I have to "find many" and then iterate through all of them to find the highest > priority. If I have to iterate, do I start with a "test priority" of HIGH, look through all > the objects, and then lower the test priority and look again until I find the highest > priority post? This is an ugly solution. I know that my implementation could easily keep > an ordered link list, and I would always use the top of the list. You still have to write some code somewhere to implement the ADFD process or the action language synchronous service (if you can't use a find...where... construct). This may or may not be ugly depending upon personal style. The difference is that it is "realized" code which may be implementation specific and there is nothing in your pristine state action to indicate any ugliness. The real issue is whether your domain's level of abstraction requires that you model a queue explicitly. In the limited description you provided it doesn't seem like it cares. My general rule of thumb is that the structure of a data store within a domain is usually an implementation issue unless the client expects behavior that is consistent with a particular structure. This is rarely the case because one also tries to define client requests in an abstract manner (i.e., such an assumption would probably have to trace back through the client to an end user requirement). If you do not need to model it explicilty, there are mechanisms such as those I described above to handle the structure as an abstraction. > Is there an IM that would better represent this problem? Should the concept of an ordered > list be modelled? The only quibble I have with your description is that I would think the bridge creates an instance of the status_post and returns its handle as a synchronous activity. It might also place an event on the queue directed at the LED_display to instantiate R1 if there is no current instantiation or the instantiation is to a status_post at a lower prority. This would be the asynchronous part of the bridge activity if LED_display is active. [As the recent wormholes paper indicates, the bridge can be viewed as having both a synchronous and an asychronous component.] Note that the bridge could probably instantiate the R1 relationship synchronously when the status_post instance is created because all it has to do is check the priority of the current R1 link (if any). This is just a static check of the domain state which the architecture must guarantee to be consistent throughout the processing of the bridge wormhole process (although the problems for the architecture increase rapidly as the bridges get smarter). If R1 does not exist or links to a lower priority status_post, the bridge can simply replace the relationship with the new one on the fly. The Clear bridge could do similar things. It would find the particular status_post instance using the handle provided by the create and check if this was the one referenced by R1. If so, the bridge would have to kill that relationship, find the next highest priority status_post and instantiate it as R1. > How do I deal with the problem of a unique handle by which the client can refer to its > posting? This seems to be a counterpart to asyncronous returns in OOA96, with the service > providing the handle instead of the client. I don't think it is necessarily asynchronous. OOA96 and the wormhole paper allow a synchronous data return. This is usually status or acknowledgement, but there is nothing to prevent it from being an instance handle. The client domain needs to know nothing about its implementation (e.g., whether it is a memory pointer or an index). As I indicate above, the bridge could create the status_post instance and return some appropriate handle synchronously. However, you could just as well return the handle asynchronously, as you suggest. BTW, in my view choosing between a synchronous vs. asynchronous data return from a wormhole where the service domain can perform the service synchronously is an area where architecture can affect the OOA. The problem is that the *mechanism* of distributed communication may be inherently synchronous or asynchronous (e.g., RPCs vs. mailboxes) even though the service domain can process the request synchronously (i.e., without placing events on the queue). I do not see how the decision to design for a synchronous data return can be made without knowledge of the architecture. I would further argue that allowing a synchronous data return potentially places requirements (i.e., that it perform its service synchronously) that are inappropriate because they define how it should do things rather than what it should do. But I digress... -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) priority queue Greg Eakman writes to shlaer-mellor-users: -------------------------------------------------------------------- Gregg Kearnan wrote: > > kearnan@Summa4.COM (Gregg Kearnan) writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > I am having a problem drawing the line between "application rules" and "implementation" > for the following problem: > > We have a "Status" domain which will accept status postings from all other domains. To a > client domain, a bridge call might appear as Status.Post(DISK_ERROR). In the bridge, a > table might map the posted status to a priority: > > DOMAIN STATUS | PRIORITY > ----------------------------- > COMM_LINK_ERROR | HIGH > DISK_ERROR | MEDIUM > . > . > . > > We might receive COMM_LINK_ERRORs from more than one client domain. All of these errors are > priority HIGH. We intend to queue up all status postings, and display (on LEDs) only the > highest priority posting. At this point, we are allowing more than one posting of a given > priority (more than one HIGH priority, more than one MEDIUM...). The status domain should > not have to maintain information as to which client actually made the posting. > > Some time after posting a status, the client domain might want to clear the status (remove > the post). This seems to imply that the service domain would have to return a handle by > which the client can refer to the post. > > I have a few questions: > > The concept of a "queue" seems to be an implementation issue. It is an ordered set of > objects. You are correct here. The concept of a queue here is an implementation of the problem. You state the correct view of the problem when you said > "find one Status post with the highest priority" > If so, what is a typical action language > statement for this? There is no "typical" ASL statement, unfortunately, since there is no agreed upon ASL standard. However, this is what the ASL would look like in IOOA ASL. They have a set ordering construct (which right now only works to order by integers) that would fit this situation. {status_set} = find-all Status order-by Priority #the loop iterator is now gauranteed to process them in order # so to get the first off the list : for status_item in {status_set} do top_priority_handle = status_item break #only want to go through once endfor As far as the implementation goes, from your description, a sorted list might be a better implementation. If you color the Status object to have its instances kept in a sorted list, a flexible code generator/ architecture can create the code to maintain the list on create and delete, and the order-by construct would become a noop for this object, rather than a sort. Depending upon your run-time execution profile, you can trade off the maintenance of the ordered list against sorting every time you want to find the top priority. > In action language, the goal is to *not* use loop counters because this prevents a > multiprocessing implementation. I'm not sure why this is an issue. "OOA models are independent from the implementation". That's the ideal we are striving for. If there is an architectural limitation that prevents the way you can express the problem, I'm not sure how to work around it without more information. But any way you specify it in the models, if you look under the hood at the generated code (blasphemy!), I'm sure you will find some sort of loop. The problem may be in the way you can package and map the ASL to processors. With regard to your having to return some kind of handle to the client, I might suggest this approach. The Status object might look like this: Status ====== *ID (one for each type of status DISK_ERROR, COMM, ...) -priority -count You can create one instance for each of the status types at initialization, all with count = 0, and the Post and Unpost services increment and decrement the count. Finding the top priority might then look like: {status_set} = find-all Status where count > 0 order-by Priority Of course, then any domain could upost a status posted by another domain, but with a little bit of work, you can fix that without having to pass the instance handle back to the client. > > Any help would be appreciated. > > Gregg Hope that helps. Ciao Greg -- Greg Eakman email: eakman@atb.teradyne.com Teradyne, ATB Phone: (617)422-3471 179 Lincoln St. FAX: (617)422-3100 MS L50 "The two most common things in the Boston, Ma. 02111 universe are hydrogen and stupidity." Subject: Re: (SMU) priority queue lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- If anyone is looking for a ride I will have room for 6 comfortably. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) priority queue J.W.Terrell@nortel.co.uk writes to shlaer-mellor-users: -------------------------------------------------------------------- > Greg Eakman writes to shlaer-mellor-users: > -------------------------------------------------------------------- > There is no "typical" ASL statement, unfortunately, since there is no > agreed upon ASL standard. However, this is what the ASL would look like > in IOOA ASL. They have a set ordering construct (which right now only > works to order by integers) that would fit this situation. > > {status_set} = find-all Status order-by Priority > > #the loop iterator is now gauranteed to process them in order > # so to get the first off the list : > for status_item in {status_set} do > top_priority_handle = status_item > break #only want to go through once > endfor Kenndey-Carter's IOOA ASL supports a number of variants of "find", namely find, find-all, find-one, find-only. find-one returns a single arbitrary instance, e.g. status = find-one Status where Priority = high if (status = UNDEFINED) then ... endif Regards, Jeff. -- Jeff Terrell Nortel, London Rd, Harlow, Essex, UK. +44 (0)1279 405870 J.W.Terrell@nortel.co.uk Subject: Re: (SMU) priority queue ian@kc.com (Ian Wilkie) writes to shlaer-mellor-users: -------------------------------------------------------------------- > Greg Eakman writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > [.....] > > There is no "typical" ASL statement, unfortunately, since there is no > agreed upon ASL standard. However, this is what the ASL would look like > in IOOA ASL. They have a set ordering construct (which right now only > works to order by integers) that would fit this situation. > > {status_set} = find-all Status order-by Priority Just to provide a minor clarification to Greg's comments, our ASL defines that the ordering can be on any type "for which order is defined". These are Real, Integer, Date, Time. Our implementation does not restrict this. The ASL also allows you to say things like: {status_set} = find-all Status ordered-by Priority & Date but our implementation does not support this at the moment. Jeff Terrell said: >Kenndey-Carter's IOOA ASL supports a number of variants of "find", namely >find, find-all, find-one, find-only. find-one returns a single arbitrary >instance, e.g. > >status = find-one Status where Priority = high >if (status = UNDEFINED) then > ... >endif We have also considered the possibility of introducing constructs such as: next_status = find-first Status ordered-by Priority which would achieve the same effect as the loop that Greg suggested, but is probably more easily optimisable in an architecture. Ian Wilkie ===================================================== Kennedy Carter, 14 The Pines, Broad Street, Guildford Surrey, GU3 3BH, U.K. Tel: (+44) 1483 483 200 Fax: (+44) 1483 483 201 Further Information: http://www.kc.com or info@kc.com ===================================================== Subject: (SMU) ASL vs ADFD's once again Alex Bushell writes to shlaer-mellor-users: -------------------------------------------------------------------- Good whatever the time of day it may be in your part of the world. I hate to start the ASL vs ADFD thing again but I'm comparing the use of graphical and textual languages as my final year dissertation. I am particular fascinated with the use of Action Specification Language and Action Data Flow Diagrams within Shlaer & Mellor. Having digested the thread from a few months back it would seem that an ASL is ok if it embodies the process modelling properties found in ADFD's and is abstract enough to avoid implementationalism (is that a word?). But the majority seem to prefer ADFD's. I have some comments and questions I would like to put to the group. Translation: I imagine process modelling needs to be quite precise in order to aid translation. What difficulties arise with parsing ADFD's? Translating? Simulation? I would think the precision inherent in the textual ASL reduces these difficulties. Am I right? Comprehension: Graphical notations are good for presenting a high level view to an 'onlooker', presenting s/he with a 'gestalt' image of the whole. This is open to interpretation difficulties, however. How can you guarantee the onlooker will receive the meaning you intended? Empirical studies have demonstrated that text is easier to read than graphics when precision is involved, for experts and novices, and conveys the meaning more efficiently. Usability: Which method do you find easiest to use? I would imagine that not having to be reliant on navigating through complex Tools or adjusting your diagrams for readability (you could probably spend a lot of time on this) is a relief. Does anybody get tired of navigating through large ADFD's? Do many of you spend time laying out your diagrams for readability? Does anybody have experience of ASL and ADFD's they can relate to the above? Maintenance Has anybody had difficulties maintaining another's work? A large percentage of projects are maintenance. Writers argue between 50% and 80% (references on demand). ADFD's present the problem of interpretation of the authors meaning. Producing a good diagram is dependant upon the authors use of 'Secondary Notation' - layout styles and typographic clues. If these are badly done then the diagram will be poorly interpreted. Secondary notation is limited in a textual language but can still be badly done, however empirical (oh no 'Empirical' again!) studies have demonstrated that the meaning in text is conveyed quicker than with graphics, even with experts! Expression: Do ASL or ADFD's express all you wish? What things can't be expressed that should be? What impact does this have? I am an independent body and have no financial interest in recommending either ASL or ADFD's. I am, however, pliable and am very interested in what others have to say, particularly experience wise. I am not completely ASL bias, it would depend upon your business requirements. If time to market is important to you then ASL is of great benefit. Like the previous thread I think that a notation that was reversible (ala BON) between text and graphics is best. With the ability to add precision to the text as required. I hope I haven't offended many people and I would like to stress that I don't just want to put a point of view across, this is something I am very interested in and I would appreciate any comments. Thanks. Alex Bushell (abushell@bournemouth.ac.uk - yes I'm from the uk, that explains it eh?) Subject: Re: (SMU) ASL vs ADFD's once again lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- General: apologies for spurious message yesterday that was meant for Greg Eakman internally. Responding to Bushell... > > Alex Bushell writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Good whatever the time of day it may be in your part of the world. The last good time of day in my part of the world was in 1968. > Having digested the thread from a few months back it would seem that an > ASL is ok if it embodies the process modelling properties found in > ADFD's and is abstract enough to avoid implementationalism (is that a > word?). But the majority seem to prefer ADFD's. I have some comments > and questions I would like to put to the group. I think it might be an overstatement that the majority *prefer* ADFDs. I would tend to be indifferent between an ASL that faithfully provided the ADFD rigor and an ADFD. I believe the main issue in choosing between them would lie in the tools themselves. If it is a major pain to modify ADFD diagrams in the GUI, then I would probably opt for ASL. OTOH, if the ASL tends to be wordy because of the need to include relationship navigation constructs and the like, I might prefer the ADFDs. > Translation: > I imagine process modelling needs to be quite precise in order to aid > translation. What difficulties arise with parsing ADFD's? Translating? > Simulation? I would think the precision inherent in the textual ASL > reduces these difficulties. Am I right? Peter Fontana is the only one I know who does this for automatic code generation, so he is the one to ask about that aspect (peterf@pathfindersol.com). I think this is a problem of the underlying database that stores the ADFD representations. Parsing a true graphical representation (i.e., a bitmap of the diagram) would tend to be painful, but the data is more likely to have rather conventional objects for processes, data stores, and data flows. At that level there is really not very much stuff to deal with and I would not think this is any more difficult to parse than an ASL. As far as precision is concerned, the problem today is quite the opposite. The ADFDs are rigorous and unambiguous but the existing ASLs generally aren't (though some are much closer than others). For example, ObjectBench essentially uses C++ for the ASL which has no ADFD-like restrictions while IOOA uses an ASL that is very faithful to ADFDs. > Comprehension: > Graphical notations are good for presenting a high level view to an > 'onlooker', presenting s/he with a 'gestalt' image of the whole. This > is open to interpretation difficulties, however. How can you guarantee > the onlooker will receive the meaning you intended? Empirical studies > have demonstrated that text is easier to read than graphics when > precision is involved, for experts and novices, and conveys the meaning > more efficiently. I find this a rather moot assertion. Is the "text" a formal language or the more common, for specifications, spoken language? If the latter I find this conclusion difficult to believe since spoken languages are notorious for ambiguity because each person brings their own semantic set to the interpretation. An ADFD is already more precise and unambiguous than the formal languages (ASLs) currently available for the same task. So how would there be more confusion over interpreation for an ADFD than an ASL? I am also not sure what "easier to read than graphics when precision is involved" means. Does this simply mean it takes longer to absorb the detail or does it mean that it is more likely to be incorrectly interpreted? In general I would need to know a lot more about those "empirical studies" before I lept on this bandwagon because it is quite contrary to my experience. > Usability: > Which method do you find easiest to use? > I would imagine that not having to be reliant on navigating through > complex Tools or adjusting your diagrams for readability (you could > probably spend a lot of time on this) is a relief. > Does anybody get tired of navigating through large ADFD's? > Do many of you spend time laying out your diagrams for readability? > Does anybody have experience of ASL and ADFD's they can relate to the > above? Laying out an ADFD for readability is usually not that tough. However, there is no question that modifying a large ADFD is a major pain when the changes are significant and you are trying to avoid long data flow lines and lots of data flow crossovers for better readability. However, this is mainly a tool engineering problem; since an ADFD is a directed, acyclic graph the tool should be able to do the layout properly for you. Since an ADFD in S-M is bounded by a single state action, they really should not be very large. If a state action is doing so much processing that a large ADFD is required, then you have probably incorrectly abstracted the processing. Usually ADFDs are quite easily comprehended with less than a dozen bubbles draped gracefully across the page. By contrast, most ASLs tend to be rather wordy. This is because they often require explicit navigation constructs that are implicit in ADFDs as naming conventions. This navigational boilerplate tends to obscure the basic processing. In most situations I would probably find an ADFD easier to read. > Maintenance > Has anybody had difficulties maintaining another's work? > A large percentage of projects are maintenance. Writers argue between > 50% and 80% (references on demand). ADFD's present the problem of > interpretation of the authors meaning. Producing a good diagram is > dependant upon the authors use of 'Secondary Notation' - layout styles > and typographic clues. If these are badly done then the diagram will be > poorly interpreted. Secondary notation is limited in a textual language > but can still be badly done, however empirical (oh no 'Empirical' > again!) studies have demonstrated that the meaning in text is conveyed > quicker than with graphics, even with experts! In our experience OO does not buy anything in the original development, especially if you have to also develop your initial architecture. However, we find very large benefits for doing maintenance. In our shop everyone does everything and no one "owns" anything, so we are often meddling in each other's work. This has not been a problem precisely because the models *are* complete and unambigous. When we did the same thing in the procedural days working from text implementation specifications this was not so true. You are implying that there is somehow something open to interpreation about what an ADFD actually means. This is not the case. An S-M ADFD, within the context of the surrounding OOA is unambiguous and not open to interpreation. If someone does a bad job of laying out the ADFD it might take longer to understand it, but there should be no problem with that understanding. > Expression: > Do ASL or ADFD's express all you wish? > What things can't be expressed that should be? > What impact does this have? For most of today's ASLs, the real question is: do they express too much? Unfortunately some tool vendors have put in enhancements over the ADFD way of doing things that allow implementation to creep into the OOA. The only thing I wanted added to ADFDs was a means of expressing depth-first iterative processing. OOA96 obliged; I just don't like the way they did it. > I am not completely ASL bias, it would depend upon your business > requirements. If time to market is important to you then ASL is of great > benefit. Like the previous thread I think that a notation that was > reversible (ala BON) between text and graphics is best. With the ability > to add precision to the text as required. I don't think time to market has anything to do with the choice between ASL and an ADFD; I doubt that any difference in productivity would be large enough to be measured. In my view an ASL and a ADFD should be duals, each derivable unambiguously from the other. Today this is not possible because the available ASLs are less restricted than an ADFD. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Transfer Vectors peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 09:17 AM 3/18/97 -0500, shlaer-mellor-users@projtech.com wrote: >lahman writes to shlaer-mellor-users: >Responding to Terrell... >FWIW, with my view that the object should be a bridge object, I would >argue that the bridge objects are modeled separately from the mainline >domain objects. At a minimum the domain objects would still communicate >with ternminals on the OCM, rather than with bridge objects directly. >This would ensure that the domain was an entity that was application >independent. I agree that the complexity of some bridging between domains can be high, and needs to be managed with analysis constructs, but I disagree with these specific conclusions. I believe that the notion of the bridge itself must be kept very simple - the "pane of glass". If domain interface situation seems to call out for a complex bridge - requiring modeling - then you simply have another domain. No new notation and semantics. The subject matter of this new domain may very much focus on abstracting the original server domain services at a some higher and more useful manner, but you should treat it like any other domain: domain requirements, IM, scenario-based OCM, SM, PM (ADFDs of course), and Dynamic Verification. ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice/fax: 508-384-1392 | peterf@pathfindersol.com ext. 2 | ____________________________________________________| Subject: Re: (SMU) ASL vs ADFD's once again peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- H.S. Lahman replied to this message a couple of days back, and I basically agree with his assessments. Rather than reiterate his points, I'll simply add a few comments here. At 04:49 PM 3/20/97 +0000, shlaer-mellor-users@projtech.com wrote: >Alex Bushell writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >Good whatever the time of day it may be in your part of the world. > >I hate to start the ASL vs ADFD thing again but I'm comparing the use >of graphical and textual languages as my final year dissertation. Do you have any practical experience with either? First hand experience can really firm up nebulous assumptions into cold, hard reality. - even at the level of a sample application. Please contact me if you want a sample model with translatable ADFDs. >Translation: >I imagine process modelling needs to be quite precise in order to aid >translation. The rigor of the method itself as specified in OOA96 has nearly all the precision that is required. To be a valid form of Process Modeling, any legitimate ASL must be equally precise. > What difficulties arise with parsing ADFD's? Translating? There is one algorithm to sequence the groupings of process invocations properly, and another related one for multiple flows. Not simple, but doable. Like many techincal problems, once we implemented it successfully, the whole picture came much more crisply into focus. My personal theory on the popularity of ASLs is the fear of this technical challenge by the CASE marketeers lead them to move toward ASL dialects as the easy out - basically to support model execution. The off-the-shelf availability of fully automatic, archetype-based translation of ADFD-based models is no longer an issue - it is history. Translation is no longer a differentiator between ADFDs and ASLs. >Simulation? I would think the precision inherent in the textual ASL >reduces these difficulties. Am I right? We don't see that. Our "real-world" observations show the opposite. The occasional implementation-pollution of process models we see in some popular ASL dialects make the "simulation" version of the action code different in some cases from the "target" actions. I've never seen that in ADFDs. It could be an architecture-specific thing, but we've seen it in different architectures on different projects. >Comprehension: >Graphical notations are good for presenting a high level view to an >'onlooker', presenting s/he with a 'gestalt' image of the whole. This >is open to interpretation difficulties, however. How can you guarantee >the onlooker will receive the meaning you intended? The method has clearly defined the meaning of ADFDs. Action languages have not yet received such rigorous attention. As a reviewer, I find ADFDs more clear than various dialects of ASL - the architecture tends to cloud the ASL more than ADFDs. > Empirical studies >have demonstrated that text is easier to read than graphics when >precision is involved, for experts and novices, and conveys the meaning >more efficiently. My apologies - but this sounds like a self serving hand-waving. Did these studies involve laboratory animals? Provide details please, or refrain from the theatrics. > >Usability: >Which method do you find easiest to use? >I would imagine that not having to be reliant on navigating through >complex Tools or adjusting your diagrams for readability (you could >probably spend a lot of time on this) is a relief. You still must navigate from the state models to individual textual blobs of ASL. However you are basically correct - the currently available ADFD editors are basically early 80's vintage leftovers from SA products. They could use some product development budget. >Does anybody get tired of navigating through large ADFD's? I'll strongly echo H.S. comment - you should not have big ADFDs so this basically is a non-issue. You could *hypothetically* assume you have a big ADFD, but then I'd have to *hypothetically* tell you to reduce it's complexity. >Do many of you spend time laying out your diagrams for readability? Just like in IM and STD layout, it is a proportionally small effort, but definitely non-zero. Graphical issues, like layout, hardcopy scaling, etc are real issues. Of course, the other edge of the graphic sword is a generally greater ability to convey complex concepts than textual means. > > ADFD's present the problem of >interpretation of the authors meaning. Much less so than various ASL dialects. > Producing a good diagram is >dependant upon the authors use of 'Secondary Notation' - layout styles >and typographic clues. You sound like an OMT practitioner. I do not find this to be a significant factor in a method that is as simple, orthogonal, and well defined as Shlaer-Mellor OOA. I expect the IM would see more of this than the lower diagrams, it is was an issue at all. > ... however empirical (oh no 'Empirical' >again!) studies have demonstrated that the meaning in text is conveyed >quicker than with graphics, even with experts! I'll guess this was not in the context of SM-OOA. Again - please present more specific information. ... "experts" - ? >Expression: >Do ASL or ADFD's express all you wish? >What things can't be expressed that should be? Take it the other way - what can I express in ASL that I shouldn't. It all comes back to the basic question of how true is an ASL dialect to Process Modeling? If you agree that you are comparing the best action language that closely maintains the Process Modeling level of abstraction to OOA96 ADFDs, then semantically they should be close. Then does your question become "what are the expressive limits of Process Modeing in OOA96?"? I would say your typical, experienced programmer can find quite a few useful implementation concepts missing from true Process Modeling. But then you must decide which of these cool features really belong in the Architecture domain? >I am an independent body and have no financial interest in recommending >either ASL or ADFD's. I am, however, pliable and am very interested in >what others have to say, particularly experience wise. > >I am not completely ASL bias, it would depend upon your business >requirements. OK - on one hand you're saying you have no firm opinion, but then you jump to the following conclusions: > If time to market is important to you then ASL is of great >benefit. Like the previous thread I think that a notation that was >reversible (ala BON) between text and graphics is best. With the ability >to add precision to the text as required. Basically, your saying ASL is always of "great benefit". Time to market is ALWAYS important. Every project I have ever consulted to, or even has casual contact with, would like to complete their efforts sooner than later. Time is always the first resourse to be constrained - before people and money. To counter your assertion, the metrics I've seen show processes that use ASL spend more time in state and process modeling than ADFD-based projects. It's close in some cases, but the most productive (in terms of hours/object) projects we've seen were/are ADFD based. >I hope I haven't offended many people and I would like to stress that I >don't just want to put a point of view across, this is something I am >very interested in and I would appreciate any comments. I hope you take my reply in the same light. But you should resturcture some of your assertions as questions until you can validate your hunches with objective data - which I admit is very hard to find, and even harder to make public. Overall, I greatly support your work. Objective research is needed to overcome assumptions - and even casual observations. I look forward to seeing your results. Thank you for the opportunity to provide input. ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice/fax: 508-384-1392 | peterf@pathfindersol.com ext. 2 | ____________________________________________________| Subject: Re: (SMU) ASL vs ADFD's once again lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Bushell... (again) > Usability: > Which method do you find easiest to use? > I would imagine that not having to be reliant on navigating through > complex Tools or adjusting your diagrams for readability (you could > probably spend a lot of time on this) is a relief. > Does anybody get tired of navigating through large ADFD's? > Do many of you spend time laying out your diagrams for readability? > Does anybody have experience of ASL and ADFD's they can relate to the > above? In my last reply I forgot one point. Speaking from a fair amount of experience I can say that it is *MUCH* easier to debug software using state models and ADFDs than it is to work directly from code. The models provide a higher level for abstraction for the flow of control that is not obscured by low level code boilerplate. To be fair, much of this productivity gain comes at the state model level rather than the ADFD, but I would argue that the ADFD still allows one to follow the money much more easily than walking the code (ASL) directly. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) ASL vs ADFD's once again Thomas Brennan-Marquez writes to shlaer-mellor-users: -------------------------------------------------------------------- This topic has been thrashed about enough I guess but let me just add my two-cents on this small corner of the overall discussion arena: > >Do many of you spend time laying out your diagrams for readability? > Just like in IM and STD layout, it is a proportionally small effort, but > definitely non-zero. Graphical issues, like layout, hardcopy scaling, etc > are real issues. Of course, the other edge of the graphic sword is a > generally greater ability to convey complex concepts than textual means. > > > I am convinced that not nearly enough time is invested in source code layout issues in conventional development shops. When writing C, C++, Pascal, or anything else, there are *two* major concerns as the lines of code are being developed: 1. The code has to work properly (i.e., it must be "correct"). 2. The code must be clear to the s'ware engineer that will come along later and have to figure out what the earlier developer was doing/thinking/meaning. I am appalled how little attention s'ware folks are willing to give to things like indentation, whitespace usage, comments, etc. Seems to me the problem of producing a clear graphical layout of an ADFD is no worse than the problem of layout of source code text, if you take both equally seriously. Thomas _______________________________ / \ Thomas Brennan-Marquez Argonaut Technologies 887 Industrial Road, Suite G San Carlos, CA 94070 415.598.1363 x280 thomas@argotech.com \_______________________________/ Subject: Re: (SMU) Transform Etiquette Ted Barbour writes to shlaer-mellor-users: -------------------------------------------------------------------- Peter J. Fontana wrote: [snip] > Thank you for the invitation. In consideration of bandwidth and attention > spans, I'll summarize what Pathfinder Solutions developed as Process > Modeling conventions, and if you want more detail, you can download our "OOA > Modeling Guide" from our web site.[snip] For anyone interested but unable to view the Word formatted document, an uncompressed rich text format (RTF) version of the "OOA Modeling Guide" is now available for downloading. -- ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | effective solutions for OOA/RD challenges | | Ted Barbour voice: 508-875-6456 | tedb@pathfindersol.com | ____________________________________________________| Subject: (SMU) Where are the rules defined? Thomas Brennan-Marquez writes to shlaer-mellor-users: -------------------------------------------------------------------- Folks, In reading the threads of these conversations I see multiple references like: Since OOA91 specifically excludes reuse of a transform... Clearly there must be some definitive catalog of the OOA91 rules somewhere. From what document are people quoting when this kind of statement is made? Thomas Subject: (SMU) The world converges peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- Ha! All the yap from Booch/Martin about the weakness of translation has just been whipped around by their (Rational's) marketing trolls - a recent press announcement says Rational is going to further mutate UML by trying to get translation by absorbing ObjecTime's ROOM approach - ! The world converges on translation. Now the method choice question becomes "Do you want a mature, self-consistent and rigorous translation through Shlaer-Mellor OOA/Recursive Design, or will you settle for a mish-mash of slapped-together compromises that isn't even thoroughtly defined yet (UML)?" ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice/fax: 508-384-1392 | peterf@pathfindersol.com | ____________________________________________________| Subject: Re: (SMU) Where are the rules defined? peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- >Thomas Brennan-Marquez writes to shlaer-mellor-users: >Clearly there must be some definitive catalog of the OOA91 rules >somewhere. From what document are people quoting when this kind of >statement is made? The version of the method defined by the text "Object Lifecycles" is referred to as "OOA91" by some. ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice/fax: 508-384-1392 | peterf@pathfindersol.com | ____________________________________________________| Subject: Re: (SMU) The world converges rmartin@oma.com (Robert C. Martin) writes to shlaer-mellor-users: -------------------------------------------------------------------- Date: Fri, 28 Mar 1997 12:02:50 -0500 (EST) From: peterf@pathfindersol.com (Peter J. Fontana) peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- Ha! All the yap from Booch/Martin about the weakness of translation has just been whipped around by their (Rational's) marketing trolls - a recent press announcement says Rational is going to further mutate UML by trying to get translation by absorbing ObjecTime's ROOM approach - ! The world converges on translation. This is a bit of a stretch. As an engineer I refuse to be responsible for the actions of non-technical (or even past-technical) marketing people. I can fully believe that some of the money oriented folks at Rational would like to find a way to increase their market share by expanding UML into territory currently held by others. So the announcement (which I have not seen) does not overly suprise me. Also, please remember that certain kinds of translation have always been part of the ROSE/UML scheme. The generation of boiler-plate and structural code are natrual outgrowths of using a UML-like notation. However, none of this is an indication that the world is converging upon translation as defined by Project Technologies. That particular kind of translation is quite a bit different from anything that the bulk UML users would be interested in. It is also not an indication that UML will incorporate anything like a ROOM methodology. Such a move would simply divorce UML from the bulk of its users. Now the method choice question becomes "Do you want a mature, self-consistent and rigorous translation through Shlaer-Mellor OOA/Recursive Design, or will you settle for a mish-mash of slapped-together compromises that isn't even thoroughtly defined yet (UML)?" Tsk, tsk, typical marketing drivel. The choice is now, and always has been to choose the method that works best for each environment. There are likely some applications that are better done with SM, and yet others that are better done with UML. -- Robert Martin | Design Consulting | Training courses offered: Object Mentor Inc. | rmartin@oma.com | OOA/D, C++, Advanced OO 14619 N. Somerset Cr| Tel: (847) 918-1004 | Mgt. Overview of OOT Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com "One of the great commandments of science is: 'Mistrust arguments from authority.'" -- Carl Sagan Subject: Re: (SMU) The world converges peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 10:31 AM 3/29/97 -0600, shlaer-mellor-users@projtech.com wrote: > As an engineer I refuse to be responsible >for the actions of non-technical (or even past-technical) marketing people. Boy do I know that feeling. But who holds the rudder(s)? Do you maintain that the immediate future for UML does not hold any form of translation? Or are you saying that the UML translation approach of the future is hoped to be *better* than the Shlaer-Mellor variant? >> ...Now the method choice question becomes... >Tsk, tsk, typical marketing drivel. Quite true - I stand chastised. ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice/fax: 508-384-1392 | peterf@pathfindersol.com | ____________________________________________________| Subject: Re: (SMU) The world converges rmartin@oma.com (Robert C. Martin) writes to shlaer-mellor-users: -------------------------------------------------------------------- Date: Sat, 29 Mar 1997 13:37:35 -0500 (EST) From: peterf@pathfindersol.com (Peter J. Fontana) peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 10:31 AM 3/29/97 -0600, shlaer-mellor-users@projtech.com wrote: > As an engineer I refuse to be responsible >for the actions of non-technical (or even past-technical) marketing people. Boy do I know that feeling. But who holds the rudder(s)? All the hype and glitz aside, it is the engineers who hold the rudder. All the high level sales in the world add up to nothing when the engineers refuse to use what their managers have purchased. Do you maintain that the immediate future for UML does not hold any form of translation? Not at all, translation is not anathema to UML nor vice versa. I *do* hold, however, that most users of UML will not be practicing Shlaer-Mellor style translation. This is because SM translation is an extremely specific kind of translation. Or are you saying that the UML translation approach of the future is hoped to be *better* than the Shlaer-Mellor variant? Not that either. I think that SM is an excellent approach for certain kinds of problems. But I think that other kinds of problems require different approaches. UML will be a powerful tool for some of those kinds of applications. -- Robert Martin | Design Consulting | Training courses offered: Object Mentor Inc. | rmartin@oma.com | OOA/D, C++, Advanced OO 14619 N. Somerset Cr| Tel: (847) 918-1004 | Mgt. Overview of OOT Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com "One of the great commandments of science is: 'Mistrust arguments from authority.'" -- Carl Sagan Subject: Re: (SMU) The world converges "Ken Cook" writes to shlaer-mellor-users: -------------------------------------------------------------------- Peter, could you post the appropriate excerpt from Rose marketing so Robert and the rest of us can see it? This could clear up the point as to whether Rose plans to absorb ROOM or not. Robert Martin writes: > I think that SM is an excellent approach for certain > kinds of problems. But I think that other kinds of problems require > different approaches. UML will be a powerful tool for some of those > kinds of applications. Robert, since your company consults on all kinds of projects, your statement seems to indicate that its likely you have needed to use SM-style translation on some projects. Can you tell us about your company's experiences using SM-style translation? Did you run into any issues that this user's group might be able to help with? Please don't tell us that you let groups that really needed SM-style translation apply UML-style instead. How can you tell when to recommend SM-style translation for a project? After hearing last fall's OOPSLA debate, I've often said that each side should be required to build a project using the other side's method - as penance for their debate statements. You know, walk a mile in the other's shoes. Maybe that would be a worthy topic for next year's OOPSLA. I know I've learned much from the practice of both proto-UML (Booch/Martin) and Shlaer/Mellor. Regards, -Ken Subject: Re: (SMU) The world converges peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 11:51 PM 3/30/97 -0800, shlaer-mellor-users@projtech.com wrote: >"Ken Cook" writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >Peter, could you post the appropriate excerpt from Rose marketing >so Robert and the rest of us can see it? This could clear up the point >as to whether Rose plans to absorb ROOM or not. OK Ken: >> SANTA CLARA, Calif.--(BUSINESS WIRE) via Individual Inc. -- IBM, >>ObjecTime Limited, and Rational Software Corporation have agreed to combine >>efforts to create an extensible industry-standard visual modeling language. > ..... >> The revised Unified Modeling Language (UML) proposal will merge a >>previous complementary IBM and ObjecTime Limited proposal with the UML >>developed by Rational and its partners in response to a recent Object >>Management Group Object Analysis and Design Request for Proposal. ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice/fax: 508-384-1392 | peterf@pathfindersol.com | ____________________________________________________| Subject: Re: (SMU) The world converges Ladislav Bashtarz writes to shlaer-mellor-users: -------------------------------------------------------------------- Ken Cook wrote: > After hearing last fall's OOPSLA debate, I've often said that each side > should be required to build a project using the other side's method - as > penance for their debate statements. booch & martin perhaps - steve mellor and mike lee have not said anything that was untrue. > You know, walk a mile in the other's shoes. are you serious? the entire software development industry _has_ been walking in booch's shoes far too long!!! (even before he happened to come along.) > Maybe that would be a worthy topic for next year's OOPSLA. there is simply no point to this. booch/martin did not come to debate, but to promote themselves and gain a bit of pr. booch was probably concerned about the timing (rational going public a few days/weeks later). martin has a long record of technical issue obfuscation and double-speak. i am not saying that people cannot change, but i have not heard anything new in the latest volley. i would rather not see this mailing list depart once again from discussing real shlaer-mellor technical issues. 'voting' on the fundamental truths of logic and self-consistency does not make sense. even if rational had 99.9999% of the market, it does not change the truth or the maturity level of a method. doing so negates rational thought, along with any foundation of logic. ladislav bashtarz Subject: Re: (SMU) The world converges "Stephen R. Tockey" writes to shlaer-mellor-users: -------------------------------------------------------------------- > peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > At 11:51 PM 3/30/97 -0800, shlaer-mellor-users@projtech.com wrote: > >"Ken Cook" writes to shlaer-mellor-users: > >-------------------------------------------------------------------- > > > >Peter, could you post the appropriate excerpt from Rose marketing > >so Robert and the rest of us can see it? This could clear up the point > >as to whether Rose plans to absorb ROOM or not. > > > OK Ken: > > >> SANTA CLARA, Calif.--(BUSINESS WIRE) via Individual Inc. -- IBM, > >>ObjecTime Limited, and Rational Software Corporation have agreed to combine > >>efforts to create an extensible industry-standard visual modeling language. > > ..... > >> The revised Unified Modeling Language (UML) proposal will merge a > >>previous complementary IBM and ObjecTime Limited proposal with the UML > >>developed by Rational and its partners in response to a recent Object > >>Management Group Object Analysis and Design Request for Proposal. Be careful not to read too much into the press release. Rational et. al. have submitted UML to the OMG's Request For Proposal (RFP) on object oriented analysis and design "methods" (term used with reservations) and tool interchange facility. A joint submission from IBM and ObjecTime Ltd was also received (a copy of which could be found via the ObjecTime home page). After having read the IBM/ObjecTime submission and having scanned the ROOM book, it appears that the IBM/ObjecTime submission could be used to support ROOM (and many others, such as UML). However the IBM/ObjecTime submission ***IS NOT THE SAME THING AS ROOM***. In fact, they are quite different. Where ROOM is a specific modeling language, the IBM/ObjecTime submission is a "meta-language" (i.e., a model of modeling languages). One advantage of the IBM/ObjecTime submission is their insistence on more precisely defined semantics than were found in many of the other submissions. The true meaning of the press release is simply that IBM and ObjecTime will now work with Rational et. al. to combine their (currently separate) proposals into a single, joint proposal. Since ROOM was not explicitly a part of the original IBM/ObjecTime proposal, I would not expect it to be a part of the joint (revised) submission. I would, however, expect to see the joint (revised) submission being able to support ROOM (better than UML 1.0 currently does). I hope this helps clear things up, -- steve Subject: Re: (SMU) The world converges lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Martin... > Not at all, translation is not anathema to UML nor vice versa. I *do* > hold, however, that most users of UML will not be practicing > Shlaer-Mellor style translation. This is because SM translation is > an extremely specific kind of translation. > > Not that either. I think that SM is an excellent approach for certain > kinds of problems. But I think that other kinds of problems require > different approaches. UML will be a powerful tool for some of those > kinds of applications. If you define "certain types of problems" as software development! The fact that UML users cannot effectively use translation is a matter of their choice of notations, not a matter of the generality of the technique. S-M translation takes the abstract description represented by an S-M OOA and converts it into usable software. Any significant software system can be represented as an S-M OOA. Therefore translation is generally applicable to software development. You seem to be replacing one myth with another. Now that the myth that translation is not viable has been laid to rest, it appears there is another myth: that S-M translation is not general because S-M itself is not general. Do you have an example of a type of problem where UML would be appropriate but S-M would not? It seems to me that for those few situations where an S-M OOA might not be the *best* representation, UML et al would be equally inappropriate because those situations involve pure algorithmic processing of a large number of data instances from a very few data types. No OO representation is going to be effective in describing a pure algorithm because OO representations are all data driven. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Where are the rules defined? Neil Lang writes to shlaer-mellor-users: -------------------------------------------------------------------- At 12:48 PM 3/3/97 -0800, >Thomas Brennan-Marquez writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >Folks, > >In reading the threads of these conversations I see multiple references >like: > > Since OOA91 specifically excludes reuse of a transform... > >Clearly there must be some definitive catalog of the OOA91 rules >somewhere. From what document are people quoting when this kind of >statement is made? > >Thomas > There is in fact such a document: We published the OOA91 rules in Software Engineering Notes. The reference is: Neil Lang ,"Shlaer-Mellor Object Oriented Analysis rules" Software Engineering Notes Vol 18, #1, January 1993. Check our web site for a copy of this report. If you can't find it there then contact me and I'll make sure you get a copy. Neil Lang ---------------------------------------------------------------------- Neil Lang nlang@projtech.com Project Technology, Inc. 510-845-1484 x23 2560 Ninth Street, Suite 214 Berkeley, CA 94710 http://www.projtech.com ---------------------------------------------------------------------- Subject: Re: (SMU) The world converges rmartin@oma.com (Robert C. Martin) writes to shlaer-mellor-users: -------------------------------------------------------------------- Date: Mon, 31 Mar 1997 09:11:17 -0500 From: Ladislav Bashtarz Ladislav Bashtarz writes to shlaer-mellor-users: -------------------------------------------------------------------- Ken Cook wrote: > After hearing last fall's OOPSLA debate, I've often said that each side > should be required to build a project using the other side's method - as > penance for their debate statements. booch & martin perhaps - steve mellor and mike lee have not said anything that was untrue. And Booch/Martin did? What untruth did we speak? > You know, walk a mile in the other's shoes. are you serious? the entire software development industry _has_ been walking in booch's shoes far too long!!! (even before he happened to come along.) Would that that were so. But, in fact, most of the software industry is still trying to figure out what Yourdon was talking about 20 years ago. > Maybe that would be a worthy topic for next year's OOPSLA. there is simply no point to this. booch/martin did not come to debate, but to promote themselves and gain a bit of pr. booch was probably concerned about the timing (rational going public a few days/weeks later). martin has a long record of technical issue obfuscation and double-speak. i am not saying that people cannot change, but i have not heard anything new in the latest volley. I'd like to set that record straight. It was Steve who invited me to that debate. As I recall (although I could be wrong about this) the debate was Steve's idea in the first place. In any case, I think it is fair to say that all the attendees of the debate were there to promote themselves in one way or another; even (gasp) Steve. i would rather not see this mailing list depart once again from discussing real shlaer-mellor technical issues. Is that what you are discussing in this letter? -- Robert Martin | Design Consulting | Training courses offered: Object Mentor Inc. | rmartin@oma.com | OOA/D, C++, Advanced OO 14619 N. Somerset Cr| Tel: (847) 918-1004 | Mgt. Overview of OOT Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com "One of the great commandments of science is: 'Mistrust arguments from authority.'" -- Carl Sagan Subject: Re: (SMU) The world converges rmartin@oma.com (Robert C. Martin) writes to shlaer-mellor-users: -------------------------------------------------------------------- Date: Mon, 31 Mar 1997 10:22:01 -0500 From: lahman Hello, HSL... Do you really wan't to have this debate again? I'm game, but I presume the readers of SMU would rather not be subjected. So, this time, I'm going to let your comments pass; except to say that (and everybody should be aware of this) *nothing* was "put to rest" by the debate. To really put that topic to rest would take more than just an hour long debate... lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Martin... <<>> -- Robert Martin | Design Consulting | Training courses offered: Object Mentor Inc. | rmartin@oma.com | OOA/D, C++, Advanced OO 14619 N. Somerset Cr| Tel: (847) 918-1004 | Mgt. Overview of OOT Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com "One of the great commandments of science is: 'Mistrust arguments from authority.'" -- Carl Sagan 'archive.9704' -- Subject: Re: (SMU) Where are the rules defined? (Son Vu) writes to shlaer-mellor-users: -------------------------------------------------------------------- Neil, I've been to the web site and looked all over but couldn't find the article referenced. Could you send me a copy of the article? Thanks. --------------------------------------------------------------------------- - -------------- Son Vu Phoenix Technologies Ltd. Phone: (714)790-2131 135 Technology Drive Fax: (714)790-2005 Irvine, CA 92618 son_vu@phoenix.com http://www.phoenix.com ------------- Original Text >From Neil Lang , on 3/31/97 4:10 PM: Neil Lang writes to shlaer-mellor-users: -------------------------------------------------------------------- At 12:48 PM 3/3/97 -0800, >Thomas Brennan-Marquez writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >Folks, > >In reading the threads of these conversations I see multiple references >like: > > Since OOA91 specifically excludes reuse of a transform... > >Clearly there must be some definitive catalog of the OOA91 rules >somewhere. From what document are people quoting when this kind of >statement is made? > >Thomas > There is in fact such a document: We published the OOA91 rules in Software Engineering Notes. The reference is: Neil Lang ,"Shlaer-Mellor Object Oriented Analysis rules" Software Engineering Notes Vol 18, #1, January 1993. Check our web site for a copy of this report. If you can't find it there then contact me and I'll make sure you get a copy. Neil Lang ---------------------------------------------------------------------- Neil Lang nlang@projtech.com Project Technology, Inc. 510-845-1484 x23 2560 Ninth Street, Suite 214 Berkeley, CA 94710 http://www.projtech.com ---------------------------------------------------------------------- Subject: (SMU) Setting the record straight. Steve Mellor writes to shlaer-mellor-users: -------------------------------------------------------------------- At 07:22 PM 3/31/97 -0600, you wrote: >rmartin@oma.com (Robert C. Martin) writes to shlaer-mellor-users: >-------------------------------------------------------------------- > Ladislav Bashtarz writes to shlaer-mellor-users: > -------------------------------------------------------------------- >I'd like to set that record straight. It was Steve who invited me >to that debate. As I recall (although I could be wrong about this) >the debate was Steve's idea in the first place. In any case, I think >it is fair to say that all the attendees of the debate were there to >promote themselves in one way or another; even (gasp) Steve. > This is what happened: * Someone at PT copied me on a message they found in which Booch said "translation is a myth" * I sent a message to comp.object asking Grady why he said such a thing * A lengthy, but stop-and-go, debate ensued * Grady suggested we take the debate to reality * I readily agreed * We discovered we were not able to attend the same conferences, except for the-far-in-the-future OOPSLA * Agreement! As for how Robert was invited: * I wanted the debate to be with Grady and Jim Rumbaugh * I wanted Robert on the Panel because of his expertise and his participation in the electronic debate * In a couple of day period, Grady asked Robert to be his second, and I asked Robert to be on the Panel. * Since it's only fair that Grady gets to choose his own debating partner, that's how it ended up. And, yes, I agree with Robert, everyone was there for reasons other than the purely technical. And that's not a bad thing: A lot of people went away with the idea that there may be more than just the lemming-like rush to the process implicit in UML. -- steve mellor Subject: Re: (SMU) The world converges lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Martin... > Hello, HSL... Do you really wan't to have this debate again? > I'm game, but I presume the readers of SMU would rather not be subjected. > So, this time, I'm going to let your comments pass; except to say that > (and everybody should be aware of this) *nothing* was "put to rest" by > the debate. To really put that topic to rest would take more than > just an hour long debate... I don't see it as the same debate. In the past I *thought* we were agreed that both methodologies are capable of leading to a good system in a given situation, though we might disagree about the likelihood, ease of getting there, artistic skill level required, and whatnot. This does not seem to be the case, based upon your recent posting. I was responding to your assertion that there are problems where S-M is inappropriate but UML et al are not. I would still like an example of what type of problem that might be. As to whether this would be an appropriate debate for this forum, there are lurkers on the forum who are new to S-M or who are evaluating it and to allow such an assertion go by unmolested would tacitly lend it credence. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) The world converges Brad_Appleton-GBDA001@email.mot.com writes to shlaer-mellor-users: -------------------------------------------------------------------- lahman@ATB.Teradyne.COM writes: > As to whether this would be an appropriate debate for this forum, there > are lurkers on the forum who are new to S-M or who are evaluating it and > to allow such an assertion go by unmolested would tacitly lend it > credence. Speaking personally, I thought that the conclusion "world converges toward translation" was itself erroneous. The original poster appeared to be intepreting some marketing glitz from Rational to mean that Rational and the three Amigos were now somehow embracing translation in the sense that Schlaer-Mellor uses the word. I saw absolutely no evidence to support this conclusion. IMHO it was just some overly ebullient press-release that gave someone an incorrect impression (which of course is what press-releases are for after all :-) ;-) -- Brad Appleton | http://www.enteract.com/~bradapp/ "And miles to go before I sleep." | 2500+ WWW links on CS & Sw-Eng Subject: (SMU) OOA Rules and more "Ralph L. Hibbs" writes to shlaer-mellor-users: -------------------------------------------------------------------- Hello E-Smug, Several of you have requested copies of the OOA Rules paper by Neil Lang. This paper is now on our web site. In fact, four papers were recently added to the website for easy downloading in both Adobe Acrobat and Adobe PostScript formats: Shlaer-Mellor Object-Oriented Analysis Rules Object-Oriented Design in Ada: A Transformational Approach Based on Object-Oriented Analysis The Project Matrix: A Model for Software Engineering Project Management Shlaer-Mellor Object-Oriented Development: A Manager's Practical Guide We respond to your feedback. In addition to adding the Postscript format and new papers for downloading, we've modified the way we use the "What's New" page to reflect changes over the last two months. You can now visit the site every other month and easily what's new on the web site. http://www.projtech.com/news/whatsnew.html Please continue to provide me feedback on how to help you be successful with the Shlaer-Mellor Method. Sincerely, Ralph Hibbs P.S. You'll also see that PT is moving to new larger office space later this month. --------------------------- Shlaer-Mellor Method --------------------------- Ralph Hibbs Tel: (510) 845-1484 ext.29 Director of Marketing Fax: (510) 845-1075 Project Technology, Inc. email: ralph@projtech.com 2560 Ninth Street - Suite 214 URL: http://www.projtech.com Berkeley, CA 94710 --------- Improving the Productivity of Real-Time Software Development------ Subject: Re: (SMU) Where are the rules defined? Neil Lang writes to shlaer-mellor-users: -------------------------------------------------------------------- A few days ago >Neil Lang innocently but mistakenly wrote to shlaer-mellor-users: >-------------------------------------------------------------------- ......deletia >There is in fact such a document: We published the OOA91 rules in >Software Engineering Notes. The reference is: > Neil Lang ,"Shlaer-Mellor Object Oriented Analysis rules" Software > Engineering Notes Vol 18, #1, January 1993. > >Check our web site for a copy of this report. If you can't find it there >then contact me and I'll make sure you get a copy. Unfortunately the web site didn't contain the report when I posted the last message. But our web wizards tell me that it is now available on the web site. Sorry for the misdirection. Neil Lang ---------------------------------------------------------------------- Neil Lang nlang@projtech.com Project Technology, Inc. 510-845-1484 x23 2560 Ninth Street, Suite 214 Berkeley, CA 94710 http://www.projtech.com ---------------------------------------------------------------------- Subject: Re: (SMU) The world converges rmartin@oma.com (Robert C. Martin) writes to shlaer-mellor-users: -------------------------------------------------------------------- Date: Wed, 02 Apr 1997 12:33:40 -0500 From: lahman Reply-To: lahman@ATB.Teradyne.COM Organization: Teradyne/ATB X-Mailer: Mozilla 3.0 (WinNT; U) Mime-Version: 1.0 References: <199704010134.TAA24409@oma.com> Content-Transfer-Encoding: 7bit Sender: owner-shlaer-mellor-users@projtech.com Precedence: bulk Reply-To: shlaer-mellor-users@projtech.com Errors-To: owner-shlaer-mellor-users@projtech.com Content-Type: text/plain; charset=us-ascii Content-Length: 1497 lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Martin... > Hello, HSL... Do you really wan't to have this debate again? > I'm game, but I presume the readers of SMU would rather not be subjected. > So, this time, I'm going to let your comments pass; except to say that > (and everybody should be aware of this) *nothing* was "put to rest" by > the debate. To really put that topic to rest would take more than > just an hour long debate... I don't see it as the same debate. In the past I *thought* we were agreed that both methodologies are capable of leading to a good system in a given situation, though we might disagree about the likelihood, ease of getting there, artistic skill level required, and whatnot. This does not seem to be the case, based upon your recent posting. I was responding to your assertion that there are problems where S-M is inappropriate but UML et al are not. I would still like an example of what type of problem that might be. I do not want to start another long argument here. On the other hand, I think that a discussion of the issues you are asking me about would be valuable. So, this is what I have done. I have emailed to Steve my thoughts on when SM would and would not be approrpriate. He has received them. One he reads through them, he may decide to post them with his own comments. -- Robert Martin | Design Consulting | Training courses offered: Object Mentor Inc. | rmartin@oma.com | OOA/D, C++, Advanced OO 14619 N. Somerset Cr| Tel: (847) 918-1004 | Mgt. Overview of OOT Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com "One of the great commandments of science is: 'Mistrust arguments from authority.'" -- Carl Sagan Subject: (SMU) Sending data to another domain kearnan@Summa4.COM (Gregg Kearnan) writes to shlaer-mellor-users: -------------------------------------------------------------------- Still trying to break the chains of implementation...;) Lets saay that I need to download a record (a junk of data) to another=20 processor. I=20 might have an information model in one domain (a domain for persistant = storage,=20 for example): Domain : Record Record Record_Element *T <--------->> * RID -name - value -num_elements - sequence_number When I send this record to the other processor, I use the services of = another domain which packs the Record (and its elements) into a message and then = = =20 uses the architecture (accessing a TCP/IP connection, for example) to = send the=20 message. In this domain, an IM might look like Domain : Message I/O Message Byte * MID <-------->> *ID -number_bytes -value -priority=04=04 -sequence_number =20 =20 Lets say that messages have different priorities. If I the record being = = =20 downloaded is very large, I want to break it into small pieces (many = messages)=20 and allow higher priority messages to be intermixed with the download = messages. The message domain may be smart enough to know to break apart large = chunks of=20 data to allow this. =20 Question 1: In the Record domain, I have a large number of Record_Elements floating = = =20 around. When I send this record, I want all these Record_Elements to = appear as=20 Byte(s) in the Message I/O domain. Do I: =09 1) Make a series of bridge calls, - bridge.Send_Record_Start(Record.RID, Record.num_elements) - bridge.Send_Record_Data(RID, Record_Element.value ) . . - bridge.Send_Record_Data(RID, Record_Element.value ) =09 until the last Record_Element has been sent. I would expect the=20 bridge to convert each value (depending on its size in bytes) to=20 multiple byte objects in the Message I/O domain. 2) Make one bridge call, =09 - bridge.Send_Record ( Record.RID ) =09 and allow the bridge to know that this means create byte objects for each Record_Element related to the Record? =20 3) Do something that should be obvious to me, but isn't - i.e. HELP =09 Some of my questioning arises because I know that in *implementation* I = would=20 have a record that is an array and I would probably pass a pointer to = this=20 array to the other module (domain). I know, I know, this is = implementation. So how should this be modeled. This problem is arising in many places in = our=20 project. In addition, persistant storage seems like an architectural problem. If = I know=20 that I have a file on disk or (FLASH ram) that must be downloaded to = another=20 processor, do I rely on the architecture to be able to instantiate my = objects=20 from disk (FLASH ram)? Any help would be much appreciated. =20 Gregg Kearnan Summa Four Inc. (603) 625-4050 x2557 kearnan@summa4.com Subject: Re: (SMU) Sending data to another domain lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Kearnan... > > Domain : Record > > Record Record_Element > *T <--------->> * RID > -name - value > -num_elements - sequence_number > > Domain : Message I/O > > Message Byte > * MID <-------->> *ID > -number_bytes -value > -priority -sequence_number > > 1) Make a series of bridge calls, > > - bridge.Send_Record_Start(Record.RID, Record.num_elements) Quibble here: RID is an attribute of Record_Element not Record, but I think I know what you are doing. > - bridge.Send_Record_Data(RID, Record_Element.value ) > . > . > - bridge.Send_Record_Data(RID, Record_Element.value ) > > until the last Record_Element has been sent. I would expect the > bridge to convert each value (depending on its size in bytes) to > multiple byte objects in the Message I/O domain. This one bothers me because it introduces asychronous complications. These bridge events are linked together through the count and this bodes ill for error processing and the like. It also requires logic in Message I/O or the bridge to check whether it is OK to send the message yet (i.e., it is complete). It is also splitting what is inherently a single transaction (i.e., post a related suite of Record_Element.values to the other domain) into multiple transations. However, it is certainly feasible. > 2) Make one bridge call, > > - bridge.Send_Record ( Record.RID ) > > and allow the bridge to know that this means create byte objects > for each Record_Element related to the Record? This is the idea I prefer, but there is an intermediate step. The recent wormholes paper defined a bridge as two synchronous services, one in each domain. The one on the Record end would accept Record.ID and create a data packet for the interdomain event. That data packet would be Record.T together with the Record_Element.value and Record_Element.sequence_number values in some efficient but arbitrary format. That event would be sent to Message I/O where it would be fielded by a synchronous service that extracted the values and created the Byte instances. When it finished the extraction it would presumeably place a Send event on the queue to actually send the message. The key issue is that the knowledge that these synchronous services would share would be that efficient but arbitrary event data packet format (as you suggested, probably an array of some sort in the implementation). In particular, bridge.Send_Record would be on the Record side and would not have any knowledge of Bytes. The corresponding bridge.Get_Message(data_packet) function would be on the Message I/O side and would have no knowledge of Record_Elements. The event data packet format becomes a pure bridge implementation issue and appears nowhere in the the OOA. > Some of my questioning arises because I know that in *implementation* I would > have a record that is an array and I would probably pass a pointer to this > array to the other module (domain). I know, I know, this is implementation. So > how should this be modeled. This problem is arising in many places in our > project. As a general rule you probably want to think about complex data aggregates passed across bridges in terms of a single data abstraction. The indivudal elements of the aggregate are not relevant to flow of control in the domain, so you only care about the aggregate as an entity. Flow of control may be affected by the attributes it is derived from in the source domain or the attributes that will be created from it in the target domain, but not by elements of the bridge data packet itself. One way to model this is with a transform ADFD process that accepts the suite of data (probably the set of Record_Elements) on a data flow and produces a single data abstraction (call it bridge_message_handle or whatever) that represents the aggregate. The transform handles formatting the aggregate. This handle is passed into the ADFD process to generate an event to the wormhole representing the other domain. The actual implementation of the representation of the data aggregate is then buried in the ADFD transform and the bridge mechanics so it does not appear explicitly in the OOA. > In addition, persistant storage seems like an architectural problem. If I know > that I have a file on disk or (FLASH ram) that must be downloaded to another > processor, do I rely on the architecture to be able to instantiate my objects > from disk (FLASH ram)? There are three situations where you might want to do this. In the Beginning of Time when the domain is initialized; as a result of a bridge request; or as a step in a state action. In all cases the actual processing would probably be done in a synchronous service because it is not relevant to the domain flow of control (i.e., at most a success/failure return value would be relevant). In effect such a service is simply the equivalent of a transform process on an ADFD (and would be if it is invoked from a state action). In this sense it is an architectural problem in all cases. You still have to write the code for the service or transform, but it is not part of the OOA (i.e., it is an atomic action that can only affect the fundamental problem flow of control through the state of the system after it completes). I may be reading more into your last two paragraphs than is warranted, but I sense some questions about the level of abstraction for an OOA. The goal of an OOA is not to define the system down to the level of lines of code. When I first started doing S-M I looked at ADFDs and assumed that they were striving for one bubble = one code line. It took awhile to figure out that this is not at all the case. In fact, S-M tends to leave a *lot* of procedural coding as an exercise for the implementor. The intent of an OOA (in my view) is to provide a rather high level of abstraction for the description. Because of its roots, that level of abstraction is designed to provide the bare minimum necessary to unambiguously define the asynchronous flow of control in real time systems. This happens to be a rather fundamental view of the flow of control of the overall system and it leaves out a lot of local flow of control information needed to perform various tasks. As a simple example, consider finding the largest value from a set of values. This would always appear as a single ADFD process. However, that process would always involve an iteration and an IF. This is flow of control at the code level but it is irrelevant at the ADFD level where finding the largest value is an atomic task. In general, S-M inentionally buries a lot of procedural processing in ADFD transforms and synchronous services. So where am I going with this? The level of abstraction of flow of control is crucial figuring out what to do with the data aggregate going to the bridge. The elements of that aggregate cannot affect flow of control in the domain, so it is fair to lump them into a single entity. This is done in a transform whose innards is not exposed in the OOA. However, this view of the level of abstraction extends well beyond bridges. The subject matter of a domain implicitly defines a level of abstraction for that domain. For example, when I look at your Record and Message I/O domain examples the similarity in the structures for Record and Message are striking and they make me a bit suspicious that at least one of them, probably Record, is at the wrong level of abstraction. Obviously this is a judgement that cannot be made without more knowledge of the context. To resolve this, though, I first would question whether Record_Element or Byte are really needed. Often a data aggregate can be abstracted into a single attribute in the OOA. One can do this *if* no flow of control decisions are made based upon the individual element values. That is, so long as you don't generate an event or not depending on some test like "if Record_Element.value < 0 then generate XXX:crash_and_burn". I suspect Record_Element.sequence_number exists solely because the set of Record_Elements is ordered if it is treated as a separate 1:M entity. If the Record_Element aggregate became an abstracted attribute of Record, this order could be implicit in the implementation (e.g., array order). If the Record domain merely manipulates Records without really caring about the individual Record_Element.value values or their order, then this might be a fair abstraction. [Of course if everyone familiar with the problem space immediately thinks of a flock of Record Elements when you mention the word "Record", it might be misleading to hide this.] If one chooses to go this route, conceptually the new abstract attribute in Record would be realized in another domain that knew about the specific structure. In a simple case like this that "domain" would be in the architecture as an Array class or somesuch. Thus the "transform" processes that might deal with it in the Record domain could be viewed as synchronous wormholes. This would allow you to do moderately interesting things with it that might be of interest in the domain (e.g., get-largest-value) without sacrificing the level of abstraction. Note that the bridge.Send_Record would not have to extract the values from Record_Element; it would simply pass the attribute, which would already be a handle to that efficient but arbitrary data structure. I have no idea whether such abstraction is actually applicable to Record or Message. I have gone through this drill simply to underscore the idea that the level of abstraction is crucial to the modeling of a domain. Using abstractions that are too detailed is the leading cause of model hacking where the models start to get so very complicated that you lose sight of the problem that you were trying to solve. Using the flow-of-control criteria can be a useful trick for identifying ways for raising the level of abstraction in a domain. Raising the level of abstraction simplifies the models so they focus on fundamental issues while moving a lot of local algorithms into the implementation. The result is a suite of state models with very little in the actions. However, it is not unusual to have those actions invoke a transform process that contains tens or even hundreds of lines of code when it is implemented. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) Supertype/Subtype creation Yves van de Vijver writes to shlaer-mellor-users: -------------------------------------------------------------------- Dear Shlaer-Mellor-users, If I have a subtype and a supertype, do I have to create instances of both myself, or is a supertype instance created automatically when a subtype instance is created? Yves van de Vijver Dutch National Aerospace Laboratory NLR email: vyver@nlr.nl Subject: Re: (SMU) Supertype/Subtype creation bruce.levkoff@cytyc.com (Bruce Levkoff) writes to shlaer-mellor-users: -------------------------------------------------------------------- <If I have a subtype and a supertype, do I have to >create instances of both myself, or is a supertype >instance created automatically when a subtype >instance is created? >Yves van de Vijver>> It's probably architecture-dependent. In ours (written in C++), the actions and state transition tables of a supertype are available to a subtype through inheritence. The supertype has no executable state model and is not instantiated. The analysis models represent states shared by the subtypes in the state model of the supertype. Splice points are clearly anotated. Bruce Subject: Re: (SMU) Supertype/Subtype creation David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: -------------------------------------------------------------------- Yves van de Vijver wrote> > Dear Shlaer-Mellor-users, > > If I have a subtype and a supertype, do I have to > create instances of both myself, or is a supertype > instance created automatically when a subtype > instance is created? You must create all the supertypes yourself. This can be done in two ways: either create the whole tree syncronously, or send a creation event to the subtype, which will then instantiate the tree (sychronously). Personally, I would allow the supertype to be created by a creation event generated from the subtype, but the recent discussions on state model splicing would tend to rule this out (because it requires two independent state models). Dave. -- David P. Whipp. Not speaking for: ------------------------------------------------------- G.E.C. Plessey Due to transcription and transmission errors, the views Semiconductors expressed here may not reflect even my own opinions! Subject: Re: (SMU) Supertype/Subtype creation peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 12:42 PM 4/8/97 +0200, shlaer-mellor-users@projtech.com wrote: >Yves van de Vijver writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >If I have a subtype and a supertype, do I have to >create instances of both myself, or is a supertype >instance created automatically when a subtype >instance is created? It depends on the implementatin of your software architecture domain. Through our consulting, we've seen a couple of architectures from "main" vendors that have very bulky sub/super and binary relationship management. Some of this clumsiness includes the requirement to separately create supertype instances and then explicitly formalize the sub/super relationship. We feel a better architectural approach is one that handles all of this automatically through the invocation of a single process - the Create accessor for the leaf (lowest) subtype instance. There are architectures generally available to do this quite nicely. Another common architectural problem in this area is a inability to access supertype attributes through processes assigned to the subtype. This can cause real problems when writing a set of attribute values - if some are the set are subtype attributes and others are supertype attributes, these clumsy architectures require different processes. As an example - say the object Food has a subtype Fruit through relationship R1, and Fruit has a subtype Apple through R2. To create an instance of Apple with properly initialized relationships, you should only have to call a single create accessor for Apple and flow in all the initial attribute values - for Apple, Fruit, and Food. One bubble - very clean and concise. You may instead be forced to call a create accessor for Food, then another for Fruit, then a third for Apple. Then three write accessors must be called to initialize each object's attributes separately. Adding insult to injury, you must then separately formalize R1 and R2. The tally is 8 process invocations. Choose your architectures wisely. ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice/fax: 508-384-1392 | peterf@pathfindersol.com | ____________________________________________________| Subject: Re: (SMU) Supertype/Subtype creation lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to van de Vijver... > If I have a subtype and a supertype, do I have to > create instances of both myself, or is a supertype > instance created automatically when a subtype > instance is created? At the theoretical level the answer is: None of the Above. Only the subtype needs to be created since each instantiation of an object must be unique and subtypes share identifiers with supertypes. Because a subtype has an is-a relation with the supertype they are really the same object so there can only be one unique instance. (If both supertype and subtype have state machines, then these are spliced into a single subtype state machine in the architecture at implementation time. The dual state machines are only supported in the methodology as a notational convenience to factor out redundant behavior from individual subtype state machines in the STDs.) At the practical level, some tools instantiate (or require you to instantiate) both subtype and supertype. In this case it is purely an artifact of the particular tool used for simulation/code generation. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) Looking for Real time Embedded, Object Oriented developers Steve Lackey writes to shlaer-mellor-users: -------------------------------------------------------------------- If you are interested, please send your resume to: SL@gte.net There are over 80 job openings for Real time Embedded, Object Oriented developers in the Dallas, Texas area. Thanks, Steve Lackey SL@gte.net Subject: (SMU) Are you interested in relocating to Dallas? Steve Lackey writes to shlaer-mellor-users: -------------------------------------------------------------------- I am looking for a Real time embedded OO person (actually 80 people). Please send me your resume if you are interested. Steve Lackey SL@gte.net Subject: Re: (SMU) Looking for Real time Embedded, Object Oriented Jay Case writes to shlaer-mellor-users: -------------------------------------------------------------------- Steve Lackey wrote: > > Steve Lackey writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > If you are interested, please send your resume to: SL@gte.net > > There are over 80 job openings for Real time Embedded, Object Oriented > developers in the Dallas, Texas area. > > Thanks, > Steve Lackey > SL@gte.net IMHO, this is bad form, man... Although tempting, I'm sure, it contributes nothing to the group. It's even more boring that those malignant remaining rants regarding the Great Debate. Please note that PT (kindly) provides postings for clients under the Job Opportunities of thier web site. And there's always the shark etiquette of ones favorite head hunting shop. But do we need want adds on the SMUG??? FWIW, just another rant :) Jay Case Tellabs Operations, Inc. Subject: Re: (SMU) Looking for Real time Embedded, Object Oriented devel Peter Nau writes to shlaer-mellor-users: -------------------------------------------------------------------- Jay Case wrote (in response to Steve Lackey's job posting): > IMHO, this is bad form, man... Probably, but it also makes me feel good, and it helps motivate me, when I see real demand out there for what we do (in contrast with generic C++/Java/InteraNet, object-oriented whatever). But I was unaware of this point, and I think it clinches the argument: > Please note that PT (kindly) provides postings for > clients under the Job Opportunities of their web site. Peter Nau pnau@ventritex.com Subject: Re: (SMU) Supertype/Subtype creation J.W.Terrell@nortel.co.uk writes to shlaer-mellor-users: -------------------------------------------------------------------- > peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: > -------------------------------------------------------------------- > As an example - say the object Food has a subtype Fruit through relationship > R1, and Fruit has a subtype Apple through R2. To create an instance of > Apple with properly initialized relationships, you should only have to call > a single create accessor for Apple and flow in all the initial attribute > values - for Apple, Fruit, and Food. One bubble - very clean and concise. One thing that concerns me about this approach is that Apple's Create accessor does more than just create an instance of itself. It also orchestrates the creation of other objects and the relationships between them. Could you clarify what you mean by "a single create accessor"? Do you mean one of the fundamental create accessors (i.e. one of those that appear in OOA96, p50) or do you mean a process (attached to Apple) that invokes the fundamental create accessors of Apple, Fruit and Food? Regards, Jeff. -- Jeff Terrell Nortel, London Rd, Harlow, Essex, UK. +44 (0)1279 405870 J.W.Terrell@nortel.co.uk Subject: Re: (SMU) Supertype/Subtype creation bruce.levkoff@cytyc.com (Bruce Levkoff) writes to shlaer-mellor-users: -------------------------------------------------------------------- >J.W.Terrell@nortel.co.uk writes to shlaer-mellor-users: >-------------------------------------------------------------------- >> peterf@pathfindersol.com (Peter J. Fontana) writes to >shlaer-mellor-users: >> -------------------------------------------------------------------- > >> As an example - say the object Food has a subtype Fruit through >relationship >> R1, and Fruit has a subtype Apple through R2. To create an instance >of >> Apple with properly initialized relationships, you should only have >to call >> a single create accessor for Apple and flow in all the initial >attribute >> values - for Apple, Fruit, and Food. One bubble - very clean and >concise. >One thing that concerns me about this approach is that Apple's Create >accessor does more than just create an instance of itself. It also >orchestrates the creation of other objects and the relationships >between them. I don't think so. Only apple is created. The apple object inherits the relationships (and state behavior) of its ancestors. N'est pas Pierre? Bruce Subject: Re: (SMU) Supertype/Subtype creation lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Terrell... > One thing that concerns me about this approach is that Apple's Create > accessor does more than just create an instance of itself. It also > orchestrates the creation of other objects and the relationships > between them. > > Could you clarify what you mean by "a single create accessor"? Do you > mean one of the fundamental create accessors (i.e. one of those that appear > in OOA96, p50) or do you mean a process (attached to Apple) that invokes the > fundamental create accessors of Apple, Fruit and Food? I believe Fontana intended a fundamental create accessor for the subtype. It is important to distinguish between what the OOA models say, what the architecture actually does, and what the code generation/simulation tools implement. Suppose the IM has something like +----- SubA1 R1 | Other <---------> SuperA--|---+ R2 | +----- SubA2 For Other to talk to SubA1 via an event or a data accessor, it merely needs the identifiers for SubA1 in the Other ADFD. These are the same as those for SuperA, so the Other ADFD only requires one process bubble to navigate to SubA1. Similarly, Other only needs one fundamental create accessor to create a SubA1. Since the super-/sub-typing reflects only data inheritance (i.e., the state machines, if any, are only in the subtypes), the ADFDs never have to have a process bubble for SuperA. [Other's state machine may generate a polymorphic event to SuperA, a la OOA96, but the Architecture must translate this to the appropriate event for the SubAn in hand.] It is the responsibility of the Architecture to Do The Right Thing for the create accessor for SubA1. This will depend upon the implementation language. In straight C the SuperA data is probably an embedded struct ing the SubA1 struct. If SuperA has a pointer to allocated storage then the SubA1 constructor and destructor would have to create and delete properly, just as they would do for a SubA1 pointer. The R1/R2 relationship would effectively be replaced by a single relationship (typically a pointer) directly between Other and SubA1. [Note that a fundamental premise of S-M is that code is generated automatically, so lots of messy casts that might be risky in hand-generated code aren't a problem.] In straight C it is clearer that only the subtype constructor/destructor is needed. If the implementation is in C++, then a header file for SuperA will probably be generated and its implementation file will contain constructors and destructors to handle any embedded pointers to allocated storage. However, the need for the separate constructors/destructors is an artifact of the language; that's just the way C++ works. Now most tools use an ASL instead of ADFDs. Typically they use IM relationships for navigation rather than identifiers. This creates a problem when they try to navigate from Other to SubA1 because they have to include SuperA (e.g., this -> R1 -> R2.SubA1) as if it were really instantiated. This isn't too bad if their matching code generator is smart enough to replace R1 -> R2 with a single pointer, effectively making SuperA a no-op. The size and performance overhead goes up if they take the easy path and actually implement an instance of SuperA. (To do this they have to effectively expand the identifiers to include the object name behind the scenes.) As I read your question, it seems that you are looking at the constructor from the OOPL point of view where the base class constructors and destructors are associated via inheritance with the supertypes. The code generator is free to do exactly this if the implementation language is an OOPL. However, the subtype instance being created still has the responsibility for allocating and deallocating *all* of the relevant storage -- the OOPL just makes this transparent in most cases by providing specific mechanisms to handle it more or less behind the scenes. As far as the relationships are concerned, the key idea is that S-M really only does data inheritance when subtyping. Thus a supertype really says little more than, "These attributes are contained in every subtype." Relationships that go to the supertype go to every subtype, so when a subtype instance is created those relationships can be instantiated directly to the subtype by the Architecture. [This is why polymorphic events had to be added to OOA96; in the example above an action in Other's state machine might have no clue which SubAn was on the other end of the pointer when constructing the event identifier.] -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Supertype/Subtype creation J.W.Terrell@nortel.co.uk writes to shlaer-mellor-users: -------------------------------------------------------------------- > bruce.levkoff@cytyc.com (Bruce Levkoff) writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > >J.W.Terrell@nortel.co.uk writes to shlaer-mellor-users: > >-------------------------------------------------------------------- > > >> peterf@pathfindersol.com (Peter J. Fontana) writes to > >shlaer-mellor-users: > >> -------------------------------------------------------------------- > > > > > >> As an example - say the object Food has a subtype Fruit through > >relationship > >> R1, and Fruit has a subtype Apple through R2. To create an instance > >of > >> Apple with properly initialized relationships, you should only have > >to call > >> a single create accessor for Apple and flow in all the initial > >attribute > >> values - for Apple, Fruit, and Food. One bubble - very clean and > >concise. > > >One thing that concerns me about this approach is that Apple's Create > >accessor does more than just create an instance of itself. It also > >orchestrates the creation of other objects and the relationships > >between them. > > I don't think so. Only apple is created. The apple object inherits > the relationships (and state behavior) of its ancestors. N'est pas > Pierre? What do you mean by "inherits", and how does this inheritance mechanism work in the context of OOA? My understanding is that the creation and deletion of every object and relationship in OOA must be accounted for in the analysis. I'd be grateful if Peter would clarify his example. Many thanks. Regards. Jeff. -- Jeff Terrell Nortel, London Rd, Harlow, Essex, UK. +44 (0)1279 405870 J.W.Terrell@nortel.co.uk Subject: (SMU) Where to model Sycnronous Services? Paul Coene writes to shlaer-mellor-users: -------------------------------------------------------------------- Hello all. I apologize if this is well covered territory. After reading the extracts "Syncronous Services" and "Bridges and Wormholes" By Steve and Sally, I am left with two questions: 1) Where do the SDFD's associated with these syncronous services show up in the work products? Are they "orphans"? Are the attached to the Information Model formally? 2) Do any tools support the concept (beyond modelling orphan DFDs)? -- Drool WWW: http://www.servtech.com/public/drool ARPA: drool@servtech.com Cindy Crawford _is_ God drool@questra.com Subject: (SMU) Job postings on ESMUG "Ralph L. Hibbs" writes to shlaer-mellor-users: -------------------------------------------------------------------- Hello Folks, As an FYI. I diligently follow this list and respond privately to all people who put ads on this mailing list. I have responded to Mr. Lackey. Since he appears to be a professional recruiter, I'm sure he will not post again. Diligent follow-up has reduced the problem we have on this list to a managable level---especially given the current growing size. It took me a day, as I was out of the office without my computer. (It was nice to be disconnected momentarily.) Sincerely, Ralph Hibbs --------------------------- Shlaer-Mellor Method --------------------------- Ralph Hibbs Tel: (510) 845-1484 ext.29 Director of Marketing Fax: (510) 845-1075 Project Technology, Inc. email: ralph@projtech.com 2560 Ninth Street - Suite 214 URL: http://www.projtech.com Berkeley, CA 94710 --------- Improving the Productivity of Real-Time Software Development------ Subject: Re: (SMU) Supertype/Subtype creation J.W.Terrell@nortel.co.uk writes to shlaer-mellor-users: -------------------------------------------------------------------- > lahman writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Responding to Terrell... > > > One thing that concerns me about this approach is that Apple's Create > > accessor does more than just create an instance of itself. It also > > orchestrates the creation of other objects and the relationships > > between them. > > > > Could you clarify what you mean by "a single create accessor"? Do you > > mean one of the fundamental create accessors (i.e. one of those that appear > > in OOA96, p50) or do you mean a process (attached to Apple) that invokes the > > fundamental create accessors of Apple, Fruit and Food? > > I believe Fontana intended a fundamental create accessor for the > subtype. It is important to distinguish between what the OOA models > say, what the architecture actually does, and what the code > generation/simulation tools implement. I'm principally concerned with what the OOA models say. That's what prompted the question. > Suppose the IM has something > like > > +----- SubA1 > R1 | > Other <---------> SuperA--|---+ R2 > | > +----- SubA2 > > For Other to talk to SubA1 via an event or a data accessor, it merely > needs the identifiers for SubA1 in the Other ADFD. These are the same as > those for SuperA, so the Other ADFD only requires one process bubble to > navigate to SubA1. Similarly, Other only needs one fundamental create > accessor to create a SubA1. Since the super-/sub-typing reflects only > data inheritance (i.e., the state machines, if any, are only in the > subtypes), the ADFDs never have to have a process bubble for SuperA. Is this true? Leaving implementation aside, hasn't *everything* got to be accounted for in the analysis, even the creation of SuperA? Regards, Jeff. -- Jeff Terrell Nortel, London Rd, Harlow, Essex, UK. +44 (0)1279 405870 J.W.Terrell@nortel.co.uk Subject: Re: (SMU) Supertype/Subtype creation -Reply Dana Simonson writes to shlaer-mellor-users: -------------------------------------------------------------------- >>> 04/09/97 03:53pm >>> J.W.Terrell@nortel.co.uk writes to shlaer-mellor-users: -------------------------------------------------------------------- >What do you mean by "inherits", and how does this inheritance >mechanism work in the context of OOA? My understanding is that the >creation and deletion of every object and relationship in OOA must be >accounted for in the analysis. Remember, an instance of a sub-type "IS A" instance of a supertype. To the analyst (not the architect) they are ONE and only ONE object. You cannot create a supertype because the supertype does not fully specify the object. You can only create subtypes and doing so creates the supertype 'part' of the object. Subject: Re: (SMU) Supertype/Subtype creation bruce.levkoff@cytyc.com (Bruce Levkoff) writes to shlaer-mellor-users: -------------------------------------------------------------------- >J.W.Terrell@nortel.co.uk writes to shlaer-mellor-users: >What do you mean by "inherits", and how does this inheritance mechanism >work in the context of OOA? My understanding is that the creation and >deletion of every object and relationship in OOA must be accounted for >in the analysis. The information model should be pretty clear. On page 57 of Object Lifestyles, this is represented with mixing tank and children which are assigned and unassigned mixing tanks. The model shows the supertype relationship (R2) as attributes of the children (the object ID). Through R2, unassigned and assigned tanks derive attributes and state models from the parent mixing tank. I have chosen to implement supertype relationships in C++ through inheritance, as in class UnassignedMixingTank: public MixingTank{}; This is the implementation for relationship R2. Actions and transition tables shared between the child classes would belong to the MixingTank class (protected members). Again, only the leaf classes, (e.g., assigned and unassigned mixing tank) are instantiated. There is no reason to create or delete MixingTank. Bruce Through Subject: Re: (SMU) Supertype/Subtype creation -Reply gvd@tellabs.com writes to shlaer-mellor-users: -------------------------------------------------------------------- > > Dana Simonson writes to shlaer-mellor-users: > -------------------------------------------------------------------- > Remember, an instance of a sub-type "IS A" instance of a supertype. To > the analyst (not the architect) they are ONE and only ONE object. You > cannot create a supertype because the supertype does not fully specify > the object. You can only create subtypes and doing so creates the > supertype 'part' of the object. Actually, as quoted from p.29 of "Object Lifecycles, Modeling the World in States": In a subtype-supertype construct, one real-world instance is represented by the combination of an instance of the supertype and an instance of exactly one subtype. This statement implies to me that there are 2 OOA instances involved. The rules state explicitly that one cannot exist without the other, but there are two distinct instances from an OOA perspective. The statement on page 57 seems to contradict the statement on page 29 depending on your interpretation: In a subtype-supertype construction, a single instance is represented in both the supertype and in the subtype object on the information model. It seems to me that the architecture plays a very important role in determining the rules for how instances of the supertypes and subtypes are created. I haven't found a statement from the methodology about creation of instances for the supertype-subtype relationships for the create accessor support in the process modeling section. Greg Degnan -- Greg Degnan email: gvd@tellabs.com Tellabs Operations,Inc Phone: (630) 512-7307 4951 Indiana Ave Lisle, IL 60532 Subject: Re: (SMU) Supertype/Subtype creation randyp@primenet.com (Randy D. Picolet) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 05:43 PM 4/9/97 BST, shlaer-mellor-users@projtech.com wrote: >J.W.Terrell@nortel.co.uk writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >> lahman writes to shlaer-mellor-users: >> -------------------------------------------------------------------- >> >> Suppose the IM has something >> like >> >> +----- SubA1 >> R1 | >> Other <---------> SuperA--|---+ R2 >> | >> +----- SubA2 >> >> For Other to talk to SubA1 via an event or a data accessor, it merely >> needs the identifiers for SubA1 in the Other ADFD. These are the same as >> those for SuperA, so the Other ADFD only requires one process bubble to >> navigate to SubA1. Similarly, Other only needs one fundamental create >> accessor to create a SubA1. Since the super-/sub-typing reflects only >> data inheritance (i.e., the state machines, if any, are only in the >> subtypes), the ADFDs never have to have a process bubble for SuperA. > >Is this true? Leaving implementation aside, hasn't *everything* got to >be accounted for in the analysis, even the creation of SuperA? > I haven't had formal training, so I may be mistaken, but my interpretation of the published materials says the method is quite ambiguous on this point (whether intentional or not I don't know). Perhaps the issue can be focussed a little more by asking how the attributes of a supertype are defined at creation time _within_ the analysis. In other words, does the list of attribute values in the signature of a sub-type create accessor include the attributes of its supertypes? If so, then you only have to invoke the sub-type create accessor in Other's ADFD. Otherwise, you have to have to invoke the whole heirarchy. I would prefer the former, but I can't find any combination of published rules that supports one interpretation over the other. Randy Picolet "Speaking for myself, and then some..." Subject: Re: (SMU) Supertype/Subtype creation -Reply -Reply Dana Simonson writes to shlaer-mellor-users: -------------------------------------------------------------------- >>> 04/09/97 01:24pm >>> gvd@tellabs.com writes to shlaer-mellor-users: -------------------------------------------------------------------- > Actually, as quoted from p.29 of "Object Lifecycles, Modeling the > World in States": > In a subtype-supertype construct, one real-world instance is > represented by the combination of an instance of the supertype > and an instance of exactly one subtype. > This statement implies to me that there are 2 OOA instances involved. > The rules state explicitly that one cannot exist without the other, > but there are two distinct instances from an OOA perspective. > The statement on page 57 seems to contradict the statement on page > 29 depending on your interpretation: > In a subtype-supertype construction, a single instance is > represented in both the supertype and in the subtype object > on the information model. Yes, also note OL p15: "An identifier is a set of one or more attributes whose values uniquely distinguish each instance of an object." Since both the subtype and supertype instance have the same analysis identifier you can view them as being two parts of the same analysis object. I realize that OOA91 was a bit vague on this. My view was derived primarily from the PT OOA course. [Neil, am I misrepresenting you here] > It seems to me that the architecture plays a very important role > in determining the rules for how instances of the supertypes > and subtypes are created. I haven't found a statement from the > methodology about creation of instances for the supertype-subtype > relationships for the create accessor support in the process modeling > section. I would view putting super-type creates into the analysis as implementation corruption. The analysis should be implementation independent. The architecture should be allowed to implement the create action anyway it choses. The analysis should not have a role in setting order (do you create the supertype or subtype first?) or be allowed to potentially delete one without deleting the other. Subject: Re: (SMU) Supertype/Subtype creation -Reply -Reply gvd@tellabs.com writes to shlaer-mellor-users: -------------------------------------------------------------------- > > Dana Simonson writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > > OL p15: "An identifier is a set of one or more attributes whose values > uniquely distinguish each instance of an object." > > Since both the subtype and supertype instance have the same > analysis identifier you can view them as being two parts of the same > analysis object. Be very careful here. The supertype and subtype do not necessarily have the same identifier. There is a relationship between the supertype and subtype that needs to be formalized. The key identifier can be different, but the formalism of the RELATIONSHIP is the link between supertype and subtype. The PT course notes actually give several examples. The PT course notes also state, "If you have an instance of a subtype, you must have a corresponding instance of the supertype." Again, we're back to 2 instances, 1 for the supertype, one for the subtype. > I would view putting super-type creates into the analysis as > implementation corruption. The analysis should be implementation > independent. The architecture should be allowed to implement the create > action anyway it choses. The analysis should not have a role in setting > order (do you create the supertype or subtype first?) or be allowed to > potentially delete one without deleting the other. I'll leave this discussion up to the architects. Although I might agree from an OOA purist perspective, I'm always very aware of the architectural and CASE tool issues. This issue isn't necessarily trivial for the architects especially with the CASE tool ASL support. Greg -- Greg Degnan email: gvd@tellabs.com Tellabs Operations,Inc Phone: (630) 512-7307 4951 Indiana Ave Lisle, IL 60532 Subject: Re: (SMU) Supertype/Subtype creation Greg Eakman writes to shlaer-mellor-users: -------------------------------------------------------------------- Yves van de Vijver wrote: > > Yves van de Vijver writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Dear Shlaer-Mellor-users, > > If I have a subtype and a supertype, do I have to > create instances of both myself, or is a supertype > instance created automatically when a subtype > instance is created? >From what I can gather from the existing publications on the analysis semantics, instances of the supertype and subtype must be created separately. As Greg Degnan quoted from Object Lifecycles, p29. In a subtype-supertype construct, one real-world instance is represented by the combination of an instance of the supertype and an instance of exactly one subtype. This implies that there are separate instances of the supertype and the subtype, which must be related. Neither one can exist by itself. >From OOA 96, p39, Section 8.2, Axiom: Any instance is created by invoking a create accessor. This is the only way an instance can be created in the time scope of the analysis. This says that an accessor can create one and only one instance. Also, since the accessor is only for an object, the create accessor cannot create instances of other objects. Thus, in the analysis, it is the analysts responsibility to create both the supertype and subtype instances and formalize the relationship. That is my view of SM OOA proper on this issue. There are different interpretations and "better" ways to express these things that are supported by the various tool vendors. Pete Fontana's comments seemed to imply that a subtype create accessor would also create all the supertype instances. (Peter, is this right?) If so, this is another flavor of the method, contributing to the continued divergence of the method flavors supported by tool vendors. Ciao Greg -- Greg Eakman email: eakman@atb.teradyne.com Teradyne, ATB Phone: (617)422-3471 179 Lincoln St. FAX: (617)422-3100 MS L50 "The two most common things in the Boston, Ma. 02111 universe are hydrogen and stupidity." Subject: Re: (SMU) Supertype/Subtype creation Jay Case writes to shlaer-mellor-users: -------------------------------------------------------------------- Greg Eakman nails it right on the head! And since quotes from the Great Books are being tossed around, let us sing together from OL pg. 46 (for minor amplification on Greg's note). What a State Action MUST do: Leave subtypes and supertypes consistent. The action must leave the subtypes and supertypes consistently populated. Therefore, if an action creates an instance of the supertype object, it must also create an instance of exactly one of the subtype objects. Similarly, if an action deletes an instance of a subtype, it must also delete the corresponding instance of the supertype. And from pg 45: Ensure consistency of relationships. [...] Us arche-dweebs like these kind of things. :) The architecture is free to conspire and do all manner of evil and interesting things (like using the C++ I-word for subtype/supertype) for performance optimizations. But these have nothing to do with the rules governing application level analysis. To do otherwise would be having the architecture wag the tail of it's well respected clients. Jay Case Tellabs Operations, Inc. Subject: Re: (SMU) Supertype/Subtype creation randyp@primenet.com (Randy D. Picolet) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 05:17 PM 4/9/97 -0500, shlaer-mellor-users@projtech.com wrote: >Jay Case writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >Greg Eakman nails it right on the head! And since quotes from >the Great Books are being tossed around, let us sing together >from OL pg. 46 (for minor amplification on Greg's note). > >What a State Action MUST do: > > Leave subtypes and supertypes consistent. The action must > leave the subtypes and supertypes consistently populated. > Therefore, if an action creates an instance of the supertype > object, it must also create an instance of exactly one of > the subtype objects. Similarly, if an action deletes an > instance of a subtype, it must also delete the corresponding > instance of the supertype. > >And from pg 45: > Ensure consistency of relationships. [...] > >Us arche-dweebs like these kind of things. :) > To me, this seems like one of those places where the imprecision of the language used leads to multiple possible interpretations, as it doesn't explicitly say that the action must _syntactically_ invoke the individual create processes of each sub/super-type, only that the action must have the effect of leaving the populations consistent. Adding confusion to a syntactic interpretation is the use of sub-type migration in the method, which clearly would create (and delete) only a sub-type instance in an action... Also, the SM philosophy of modeling one thing in one place, along with the previous requirement for consistent populations, would seem to vote against modeling the creation of sub/super type heirarchies in every ADFD that needs to create an instance of the sub-type. Probably a good way to balance these conflicts is to send a creation event to a subtype and invoke the supertype create accessor (so the supertype instance is "non-self-created") in the action of the creation state of the subtype. This seems to be legal and solve most of the problems with the normal (non-migrating) situation... >The architecture is free to conspire and do all manner of >evil and interesting things (like using the C++ I-word for >subtype/supertype) for performance optimizations. But these >have nothing to do with the rules governing application >level analysis. To do otherwise would be having the >architecture wag the tail of it's well respected clients. > The question of how to most accurately and efficiently model creation of analysis instances is a method issue, not an architecture issue. Randy Picolet "Speaking for myself, and then some..." Subject: Re: (SMU) Supertype/Subtype creation peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 09:55 AM 4/9/97 BST, shlaer-mellor-users@projtech.com wrote: >J.W.Terrell@nortel.co.uk writes to shlaer-mellor-users: > ... To create an instance of >> Apple with properly initialized relationships, you should only have to call >> a single create accessor for Apple and flow in all the initial attribute >> values - for Apple, Fruit, and Food. One bubble - very clean and concise. > >One thing that concerns me about this approach is that Apple's Create >accessor does more than just create an instance of itself. It also >orchestrates the creation of other objects and the relationships >between them. Depending on your architecture, this may not actually be much OOP work. > >Could you clarify what you mean by "a single create accessor"? Do you >mean one of the fundamental create accessors (i.e. one of those that appear >in OOA96, p50) Yes. or do you mean a process (attached to Apple) that invokes the >fundamental create accessors of Apple, Fruit and Food? No. As of when I'm writing this, there has been quite a bit of back-and-forth on this, ending with Randy P.'s question: " In other words, does the list of attribute values in the signature of a sub-type create accessor include the attributes of its supertypes? If so, then you only have to invoke the sub-type create accessor in Other's ADFD. Otherwise, you have to have to invoke the whole heirarchy. " If you recall my original response to the first post on this thread highlighted BOTH approaches. It seems we have identified a gray area of architectural interpretation. Some architectures (including ours) support a single, primitive create access that can initialize all attributes (sub- and super-), and other architectures require the analyst to do all this. The technical interpretations we have developed and support are: - outlaw any notion of a supertype instance: only leaf subtype instances can exist, which inherit attributes and (optionally) behavioral threads from supertypes - only support leaf subtype create accessors - automatically create appropriate supertypes at subtype creation time - allow subtype accessors to get at supertype attributes - allow any type of non-create accessors to be allocated to supertypes - allow tests, transformations, generates, etc to be allocated to supertypes ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice/fax: 508-384-1392 | peterf@pathfindersol.com | ____________________________________________________| Subject: Re: (SMU) Where to model Sycnronous Services? peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 12:45 PM 4/9/97 -0400, shlaer-mellor-users@projtech.com wrote: >Paul Coene writes to shlaer-mellor-users: >After reading the extracts "Syncronous Services" and "Bridges and >Wormholes" By Steve and Sally, I am left with two questions: > >1) Where do the SDFD's associated with these syncronous services show up >in the work products? Are they "orphans"? Are the attached to the >Information Model formally? Check out our "Modeling Guide" on our web site. We say you define a set of services on a domain-by-domain basis. >2) Do any tools support the concept (beyond modelling orphan DFDs)? Since this is a pretty new concept, any tool support would be an "adaptation". We use an STD and label it to be a "Bridge STD". Each state represents a service, that then lets you navigate to a SDFD. Short questions - short answers. More details available upon request. ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice/fax: 508-384-1392 | peterf@pathfindersol.com | ____________________________________________________| Subject: Re: (SMU) Supertype/Subtype creation peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 04:56 PM 4/9/97 -0400, shlaer-mellor-users@projtech.com wrote: >Greg Eakman writes to shlaer-mellor-users: > ... >That is my view of SM OOA proper on this issue. There are different >interpretations and "better" ways to express these things that >are supported by the various tool vendors. Pete Fontana's >comments seemed to imply that a subtype create accessor would >also create all the supertype instances. (Peter, is this right?) Yes. >If so, this is another flavor of the method, contributing to >the continued divergence of the method flavors supported >by tool vendors. This is very true - Greg's point is correct and significant. Take my input with a grain of salt. Our use of the method on our own projects and with our clients has lead us to *bend* some of the rules of OOA to make it easier to use and more effective: - we have slightly refined ADFD's to make them more precise and achieve executability - OOA96 almost got us there - we defined/supported Indirect Events before anything was published on Return Vectors - we've defined/supoprted a state model splicing approach - nothing this forum has reached consensus on. There are other sins I could confess to... Sally and Steve have done a magnificent job in defining the method. Since they're human, we shouldn't expect it to be 100% perfect. I'm very grateful so much of it is *right* - and so generally applicable. Of course, what I consider to be the imperfect 1% will be different from the next guy...and so will our attempts to work around it. ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice/fax: 508-384-1392 | peterf@pathfindersol.com | ____________________________________________________| Subject: Re: (SMU) Job postings on ESMUG Steve Lackey writes to shlaer-mellor-users: -------------------------------------------------------------------- Ralph, I apologize for the intrusion. I was just surfing the net, looking for the keywords 'real-time' and 'embedded', and your group turned up. So I thought I would join in and voice my interests. I am not a headhunter or recruiter, but a programmer myself. A friend of mine at Texas Instruments is needing 80+ people with your skills, and I thought I might try to help him out. Please remove my name from the user list. Regards, Steve Lackey SL@gte.net Subject: Re: (SMU) Supertype/Subtype creation lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- esponding to Terrell... > > +----- SubA1 > > R1 | > > Other <---------> SuperA--|---+ R2 > > | > > +----- SubA2 > > > > For Other to talk to SubA1 via an event or a data accessor, it merely > > needs the identifiers for SubA1 in the Other ADFD. These are the same as > > those for SuperA, so the Other ADFD only requires one process bubble to > > navigate to SubA1. Similarly, Other only needs one fundamental create > > accessor to create a SubA1. Since the super-/sub-typing reflects only > > data inheritance (i.e., the state machines, if any, are only in the > > subtypes), the ADFDs never have to have a process bubble for SuperA. > > Is this true? Leaving implementation aside, hasn't *everything* got to > be accounted for in the analysis, even the creation of SuperA? Alas, no it is not. If one accesses attributes from the supertype in an ADFD, one needs a data store for the supertype and the accessor process that accesses that data store must be owned by the supertype. Since that data store has to be instantiated, the OOA *does* require create/delete accessors for the supertype. When I made the original statement I overlooked this notational requirement. To answer your original question, the analyst *does* have to provide the create accessors in the ADFD for the supertypes in an ADFD. However, I see this as simply a notational artifact that is not theoretically required. One could specify the ADFD so that one identified the supertype data store by the subtype object. S-M has chosen to maintain the data store distinction in the ADFD for the sake of clarity in its relationship with the IM but at the cost of having to use explicit supertype create/delete accessors in lock-step with the subtype create/delete accessors. In contrast, Pathfinder has chosen to consolidate the create/delete in their ADFD notation without any apparent loss in rigor. I don't happen to like the S-M tradeoff because it allows the analyst to make mistakes, particularly when one uses events instead of accessors. The creates and deletes must be done in pairs, but the analyst can screw up and forget one (usually the delete). However, I don't like our political system, but no one seems the care about that opinion either. (It was wishful thinking over thsi tradeoff that partially contributed to my error above. In addition I have been using an ASL too much lately and have forgotten the ADFD nuances. The last contributing factor was simple senility.) -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Supertype/Subtype creation -Reply lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Degnan... > Actually, as quoted from p.29 of "Object Lifecycles, Modeling the > World in States": > > In a subtype-supertype construct, one real-world instance is > represented by the combination of an instance of the supertype > and an instance of exactly one subtype. > > > > The statement on page 57 seems to contradict the statement on page 29 > depending on your interpretation: > > In a subtype-supertype construction, a single instance is > represented in both the supertype and in the subtype object > on the information model. I believe the contradiction disappears if one adds the "real-world" and "combination" qualifiers from the first statement to the second statement: In a subtype-supertype construction, a single instance is represented both the supertype and the subtype objects on the information model. The criticism of the statements that I have is that the word "instance" is overloaded in that there is no one-to-one correspondance between a real-world instance and an OOA instance where sub-/super-types are concerned. In the IM the single real-world instance is abstracted to two (or more, depending upon depth of subtyping) objects and in the ADFD it is abstracted to two or more data stores. S-M has chosen to make ADFDs consistent with the IM by creating and deleting *representational* instances using different create/delete accessors in the ADFD for supertypes and subtypes. (See my recantation to Terrell.) That is, the ADFD maintains the idea of combining multiple representational instances for a single real-world instance and the actual combining of the abstractions into a realized instance is left as an exercise for the Architecture. There are other mechanisms that might might have been used in the ADFD that would maintain the rigor while providing 1:1 mapping of instances, albeit at the possible price of clarity vis-a-vis the IM. However, this thread is testimony to the fact that clarity is illusive. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Supertype/Subtype creation lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Picolet... > I haven't had formal training, so I may be mistaken, but my interpretation > of the published materials says the method is quite ambiguous on this point > (whether intentional or not I don't know). Perhaps the issue can be > focussed a little more by asking how the attributes of a supertype are > defined at creation time _within_ the analysis. In other words, does the > list of attribute values in the signature of a sub-type create accessor > include the attributes of its supertypes? If so, then you only have to > invoke the sub-type create accessor in Other's ADFD. Otherwise, you have > to have to invoke the whole heirarchy. See my back-pedalling to Terrell on what is required in an ADFD. The answer is that the subtype's create accessor does not include the supertype's attributes; one has to use a separate supertype create accessor to instantiate that data store in an S-M ADFD. There are other valid alternatives, such as Pathfinder's, but that is the way OL defines the ADFD notation. > > I would prefer the former, but I can't find any combination of published > rules that supports one interpretation over the other. I can certainly see the logic in the OL approach. If one starts with an IM using a relational data model, then there is no choice about the two (or more) abstractions representing a single instantiation. The question becomes: when do you combine these representations into the single real-world instance? The OL approach essentially keeps the multiple abtraction representation throughout the OOA and leaves it to translation to combine them. This is very consistent with the overall philosophy; abstractions are abstractions and implementation is implementation. The alternative is to treat the ADFD as a different level of abstraction and combine the IM abstractions there (i.e., access a single subtype data store that implicitly includes all the supertype attributes). This would require only a single create accessor whose data signature was inclusive of the supertypes. While this is not lock-step consistent with the IM view, it has the advantage that the analyst can't screw up by forgetting one of the create/delete accessors. It also explicitly makes the necessary conversion of the IM's M:1 mapping to a 1:1 mapping for representation:realization in the OOA before going the translation. Bottom line: I am biased towards the alternative but I think debating the superiority among the approaches is close to moot; one could spend a lot of time making subjective judgements without a lot of closure. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Job postings on ESMUG "Katherine Zhao" writes to shlaer-mellor-users: -------------------------------------------------------------------- On Apr 10, 12:29am, Steve Lackey wrote: > Subject: Re: (SMU) Job postings on ESMUG > Steve Lackey writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Ralph, > > I apologize for the intrusion. I was just surfing the net, looking for > the keywords 'real-time' and 'embedded', and your group turned up. So I > thought I would join in and voice my interests. > > I am not a headhunter or recruiter, but a programmer myself. A friend > of mine at Texas Instruments is needing 80+ people with your skills, and > I thought I might try to help him out. > > Please remove my name from the user list. > > Regards, > Steve Lackey > SL@gte.net >-- End of excerpt from Steve Lackey Subject: Re: (SMU) Supertype/Subtype creation Dana Simonson writes to shlaer-mellor-users: -------------------------------------------------------------------- OK, the SM methodology may allow for supertype creates (in lock step with subtypes, yuck!) but I find it interesting that the ODMS example has create processes for online and offline disks, but no create process for the disk supertype. Now, the example did not include every peice of analysis for the system, but since it did have the disk in the state process table, if PT was using analysis creates for supertypes they should have been listed. Maybe someone at PT would care to chime in on whether they use analysis creates for supertypes in their ADFDs. (The methodology uses ADFDs not ASLs. In my opinion most ASLs are much to close to the architecture.) Subject: Re: (SMU) Supertype/Subtype creation Neil Lang writes to shlaer-mellor-users: -------------------------------------------------------------------- At 07:51 AM 4/11/97 -0500, you wrote: >Dana Simonson writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >OK, the SM methodology may allow for supertype creates (in lock step >with subtypes, yuck!) but I find it interesting that the ODMS example has >create processes for online and offline disks, but no create process for >the disk supertype. Now, the example did not include every peice of >analysis for the system, but since it did have the disk in the state >process table, if PT was using analysis creates for supertypes they >should have been listed. The ODMS model we use in our training classes reflects a world in which there a pre-existing set of disks. For simplicity, we chose not to allow new disks to added to the ODMS system or existing disks to be removed. However these disks can migrate between online and offline subtypes Hence we need to be able to create/delete the subtypes but we do not need to create or delete instances of the supertype. That's why (and the only reason why) you don't find any supertype creation operators in the model. > Maybe someone at PT would care to chime in on whether they use >analysis creates for supertypes in their ADFDs. (The methodology uses >ADFDs not ASLs. In my opinion most ASLs are much to close to the >architecture.) > > Suppose we extended the ODMS model to permit the addition of new disks to the ODMS cabinet system during run-time ( a most reasonable extension BTW) We would add a creation state in the disk state model in which the analyst would explicitly state the following: Create instance of disk object Create instance of appropriate subtype (since a new disk will most likely be added to the external library first, we'll create an instance of the off-line disk subtype) Link these two instances together across the subtype relationship Notice that the analyst specifies all three operations. The formalism does NOT fill in any of those details for you. Hope this example clears the air on this subject. Neil ---------------------------------------------------------------------- Neil Lang nlang@projtech.com Project Technology, Inc. 510-845-1484 x23 2560 Ninth Street, Suite 214 Berkeley, CA 94710 http://www.projtech.com ---------------------------------------------------------------------- Subject: (SMU) Synchronous deletion of active objects "Monroe,Jonathan" writes to shlaer-mellor-users: -------------------------------------------------------------------- A month ago I posted a question regarding whether or not synchronous deletion of an active instance was a legal thing to do. The concensus seemed to be that it is legal to do so, but it is considered bad form. Instead, and event should be sent which causes a transition to a terminal state. I would like to pick that thread up again with some follow-up questions: 1. Is the conditionality and multiplicity specification of a relationship an invariant for the processing? If so, 2. When is the invariant evaluated? At the end of a state action? At the end of a thread of control? 3. Does the conditionality invariant mean that there are cases where synchronous deletion of an active instance is required? To start this discussion, I will assume that a relationship specified as being non-conditional is an invariant which is evaluated at the end of each action. This means that an instance which has a (1:1) relationship can change who it is related to within an action, but at the end of the action it must be related to exactly one instance. Now consider the following elided IM: DOG <<------> DOG OWNER where DOG and DOG OWNER are both active objects related non-conditionally. Both have born-and-die lifecycles. When the last DOG instance related to a particular DOG OWNER enters its terminal state, both the DOG and the related DOG OWNER must be deleted. If the DOG sends a deletion event to the DOG OWNER, then there may be some amount of time after the DOG has been deleted but before the event to the DOG OWNER has been processed. The invariant has been violated because the DOG OWNER instance exists without a corresponding DOG. To remedy this situation, DOG OWNER must be synchronously deleted in the same action that the last related DOG is deleted (in this case, the terminal state of DOG). Is this a correct interpretation of the S-M rules? This scenario (two active, born-and-die objects related non-conditionally) is a very common occurrence in my domain. If I can not (or should not) use deletion accessors on non-self objects, then I either have to add a bunch of "C"'s to my relationships which do not really model the real world, or combine both state models into a single state model, which synchronously deletes the now passive object. Both of these approaches seem UGLY. Is this a case where synchronous deletion is appropriate? Your feedback is much appreciated. Jonathan Monroe Abbott Laboratories - Diagnostics Division North Chicago, IL monroej@ema.abbott.com Subject: (SMU) Referential Attributes gvd@tellabs.com writes to shlaer-mellor-users: -------------------------------------------------------------------- I have a question about write accessors and referential attributes. The OL book indicates that write accessors update the value of an attribute of an instance of an object. From an OOA perspective, can write accessors update referential attributes? I realize that CASE tools and the architecture folks won't look kindly on this question. The architectures don't necessarily need to translate referential attributes into variables. I haven't found a formalism that discusses relating instances of objects, although it's informally mentioned throughout the OL book. I mistakenly faulted the methodology for not formalizing the creation of subtype and supertypes last week (thanks to Greg Eakman and Jay Case for properly defending the methodology), so I thought I'd ask if someone can point me to the formalism. Our CASE tool and our architecture probably won't permit write accessors for referential attributes, so my question is more informational than practical. Thanks, Greg Degnan -- Greg Degnan email: gvd@tellabs.com Tellabs Operations,Inc Phone: (630) 512-7307 4951 Indiana Ave Lisle, IL 60532 Subject: Re: (SMU) Synchronous deletion of active objects Tony Humphrey-Lewis writes to shlaer-mellor-users: -------------------------------------------------------------------- Monroe,Jonathan wrote: > > "Monroe,Jonathan" writes to shlaer-mellor-users: > -------------------------------------------------------------------- > I would like to pick that thread up again with some follow-up questions: > > 1. Is the conditionality and multiplicity specification of a relationship an > invariant for the processing? > If by that you mean that a relationship that is unconditional will never become conditional, or become many when it was one then yes it is invariant. However, you do have to deal with the fact that things happen sequentially. E.G. creating two object instances which have a 1:1 relationship will momentarily violate it. i.e. create first object, create second and then formalise relationship. > If so, > 2. When is the invariant evaluated? At the end of a state action? At the > end of a thread of control? On completion of a state action the system must be 'consistent'. However I refer you to OL p.106 which discusses consistency of data and the issue of propagation time. This says that an action makes the system consistent by "writing data ... or by generating events to cause other state machines to come into conformance. > 3. Does the conditionality invariant mean that there are cases where > synchronous deletion of an active instance is required? I wouldn't say it is required, but it may well make your system simpler. > Now consider the following elided IM: > > DOG <<------> DOG OWNER > > where DOG and DOG OWNER are both active objects related non-conditionally. > Both have born-and-die lifecycles. When the last DOG instance related to a > particular DOG OWNER enters its terminal state, both the DOG and the related > DOG OWNER must be deleted. If the DOG sends a deletion event to the DOG > OWNER, then there may be some amount of time after the DOG has been deleted > but before the event to the DOG OWNER has been processed. The invariant has > been violated because the DOG OWNER instance exists without a corresponding > DOG. To remedy this situation, DOG OWNER must be synchronously deleted in > the same action that the last related DOG is deleted (in this case, the > terminal state of DOG). The violation is strictly speaking ok, because once the event sent to delete the DOG OWNER then the system is consistent again and this event was generated by the state action which had to ensure consistency was re-established, albeit after some finite time. What is perhaps more of an issue is whether or not the rest of your system handles this propagation time for the event. Referring back to OL p.106 you will see that it says that "It is the responsibility of the analyst to ensure that the data required by an action is consistent, or that the action operates in such a way to allow for inconsistencies due to propagation time" IMHO that means you can choose to synchronously delete the DOG OWNER or ensure that your other state actions handle the delay. This might be by suitable synchronisation of state actions, or use of additional attribute data that can be tested. Examples of this sort of thing can be seen in the tests carried out by state models for things like the Service Assigner. It looks for a customer with state "Waiting for Idle Clerk" AND "not appearing in an instance of Service". See OL p. 74/75 for a description. > Is this a correct interpretation of the S-M rules? This scenario (two > active, born-and-die objects related non-conditionally) is a very common > occurrence in my domain. If I can not (or should not) use deletion accessors > on non-self objects, then I either have to add a bunch of "C"'s to my > relationships which do not really model the real world, or combine both state > models into a single state model, which synchronously deletes the now passive > object. Both of these approaches seem UGLY. > Yes it is. I would agree that adding C's just to handle this is wrong, although it may make you think about your application policies again. > Is this a case where synchronous deletion is appropriate? Your feedback is > much appreciated. It may well be appropriate. However you should consider what the rest of your model does. If you found, for example, that nowhere in your model needed to worry about this then you could choose to use the event to make it consistent eventually. It really does depend on what the rest of your model does. Hope this helps ___________________________________________________________________ Anthony Humphrey-Lewis email: hlewisa@ncp.gpt.co.uk Siemens GEC Communication Systems Ltd. Technology Drive, Beeston Tel: +44 (0)115 943 4290 Nottingham United Kingdom Fax: +44 (0)115 943 3805 Subject: Re: (SMU) Synchronous deletion of active objects lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Monroe... > To start this discussion, I will assume that a relationship specified as > being non-conditional is an invariant which is evaluated at the end of each > action. This means that an instance which has a (1:1) relationship can > change who it is related to within an action, but at the end of the action it > must be related to exactly one instance. > > Now consider the following elided IM: > > DOG <<------> DOG OWNER > > where DOG and DOG OWNER are both active objects related non-conditionally. > Both have born-and-die lifecycles. When the last DOG instance related to a > particular DOG OWNER enters its terminal state, both the DOG and the related > DOG OWNER must be deleted. If the DOG sends a deletion event to the DOG > OWNER, then there may be some amount of time after the DOG has been deleted > but before the event to the DOG OWNER has been processed. The invariant has > been violated because the DOG OWNER instance exists without a corresponding > DOG. To remedy this situation, DOG OWNER must be synchronously deleted in > the same action that the last related DOG is deleted (in this case, the > terminal state of DOG). Humphrey-Lewis pretty much covered the territory. I just have two things that I would add. The first is that there are mechanisms one can employ in the architecture to guarantee consistency. (Note that instantiating and de-instantiating relationships is fundamentally an architecture issue.) For example, when an instance deletes itself the architecture could enforce consistency by placing an access lock on all instances to which it has relationships. This is kind of a last resort because it can get complicated (e.g., how does the architecture know DOG OWNER is also going to get deleted so locks can be placed on *its* related instances) or be a performance hit (e.g., lock everybody when a delete event is issued) or there may be race conditions in obtaining locks, etc. The second point is a more practical one. Most non-threaded domains are internally synchronous. By that I mean that asynchronous events are *usually* only introduced through bridges to the outside world while the normal flow of control for internal operations is pretty deterministic and repeatable. Therefore you often might be pretty confident that when the PET EUTHANASIA CENTER places the event to delete DOG on the queue that the queue will be empty and the next event processed will be the one DOG places on the queue to delete DOG OWNER. (You could be even more confident if PET EUTHANSIA CENTER sent both delete events at the same time) My point here is that S-M's admonition that it is the analyst's responsibility to ensure consistency is usually not a major problem for most situations and those where it is an issue are also often easily recognized (e.g., there is potentially a bridge event to DOG OWNER). -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Referential Attributes lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Degnan... > I have a question about write accessors and referential attributes. > The OL book indicates that write accessors update the value of an > attribute of an instance of an object. From an OOA perspective, > can write accessors update referential attributes? I agree that OL isn't very explicit about this. Basically this question comes down to: How does one instantiate relationships outside of a create accessor? (Clearly conditional or M:M relationships may be instantiated after both instances already exist, so we can't leave it as an architectural issue for the create accessor.) The first thing to note is that there is no Instantiate Relationship accessor. (I think -- my track record on ADFDs has not been too good lately.) There would appear to be no other way than to use a write accessor. Also, a referential attribute is still an attribute and OOA96's table of accessors doesn't restrict the write accessor to non-referential attributes. Therefore, it would seem that one instantiates relationships using a write accessor. However, there is an alternative. One could view the instantiation of a relationship as a purely architectural issue and invoke an architecture transform to do it. This is effectively the route that the tool vendors have gone by offering a special language construct to instantiate relationships. In these circumstances it would be bad form to touch the referential atttributes outside that transform because you might omit something clever that the architecture required for navigation. Alas, OOA96 seems to disallow this. OOA96 stipulates that transforms may not access data stores and can only process sets on input. (I have big time problems with both these restrictions, but that's another story.) This leaves invoking a wormhole to the Architecture domain, which seems inordinately klutsy. Bootom line: there does not seem to be any other feasible mechanism than the write accessor for instantiating a relationship outside a create accessor. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Synchronous deletion of active objects "Monroe,Jonathan" writes to shlaer-mellor-users: -------------------------------------------------------------------- > Tony Humphrey-Lewis writes: > Jonathan Monroe wrote: > >> I would like to pick that thread up again with some follow-up questions: > >> 1. Is the conditionality and multiplicity specification of a relationship >> an invariant for the processing? > If by that you mean that a relationship that is unconditional will never > become conditional, or become many when it was one then yes it is > invariant. However, you do have to deal with the fact that things > happen sequentially. E.G. creating two object instances which have > a 1:1 relationship will momentarily violate it. i.e. create first object, > create second and then formalise relationship. I was assuming that a non-conditional relationship specified a post condition for a state action, i.e. that an instance in a (1:1) relationship MUST have a related instance at the end of the action (any temporary inconsistency while the action is being processed would be OK). This appears to be an incorrect assumption. >> If so, >> 2. When is the invariant evaluated? At the end of a state action? >> At the end of a thread of control? > On completion of a state action the system must be 'consistent'. > However I refer you to OL p.106 which discusses consistency of > data and the issue of propagation time. > This says that an action makes the system consistent by "writing data > ... or by generating events to cause other state machines to come into > conformance. So, its not really an invariant that the architecture can enforce. It would be difficult to conclusively determine (without some sophisticated look-ahead ability) that a generated event, when processed, will cause a transition to a state that will delete a related instance. Which leads me another question. For the case where an instance in a terminal state needs to delete a related (1:1) instance by sending it an event: 1. does the generated event have to cause a transition into a state that actually deletes the instance, OR 2. can that state generate an event that eventually causes the instance to be deleted? In other words, can all non-conditionality be enforced by the architecture at the end of a thread of control? > Hope this helps Yes, it does. Thank you very much. Jonathan Monroe Abbott Laboratories - Diagnostics Division North Chicago, IL monroej@ema.abbott.com Subject: (SMU) Reference Descriptions "Robert G. Lane" writes to shlaer-mellor-users: -------------------------------------------------------------------- The Bridgepoint CASE tool provides the capability to enter a description for relationships, referential attributes, and attribute references. Can anyone tell me the difference between the information that might belong in the referential attribute description versus the attribute reference description? After writing a relationship description (containing the info described in OL pg. 24 ) and referential attribute description (using OL pg. 19 as a guide), I am at a loss for anything else that might need to be said about the relationship an its referential attributes. Any advice or opinions would be greatly appreciated. -- bobl@network.com, Bob Lane, Network Systems Group 7600 Boone Ave N. Brooklyn Park, MN 55428 612-391-1158 Subject: Re: (SMU) Reference Descriptions Ken Cook writes to shlaer-mellor-users: -------------------------------------------------------------------- Robert G. Lane wrote: > > "Robert G. Lane" writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > The Bridgepoint CASE tool provides the capability to enter a description > for relationships, referential attributes, and attribute references. Can > anyone tell me the difference between the information that might belong > in the referential attribute description versus the attribute reference > description? After writing a relationship description (containing the > info described in OL pg. 24 ) and referential attribute description > (using OL pg. 19 as a guide), I am at a loss for anything else that > might need to be said about the relationship an its referential > attributes. > > Any advice or opinions would be greatly appreciated. > Seems like you are writing more descriptions than the average bear; readers/users of your models will appreciate that. I find that writing good text which describes how a relationship is used is one of the fastest ways to find weak spots in my models. If you haven't written those kind of explanations, I'd encourage you to give it a try. Having so many things which can be described can be a real help when subtle coloring needs to be done, but I don't think it's necessary to fill in all three descriptions you mention. -Ken Subject: Re: (SMU) Referential Attributes gvd@tellabs.com writes to shlaer-mellor-users: -------------------------------------------------------------------- > > lahman writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Responding to Degnan... > > > I have a question about write accessors and referential attributes. > > The OL book indicates that write accessors update the value of an > > attribute of an instance of an object. From an OOA perspective, > > can write accessors update referential attributes? > > > Bootom line: there does not seem to be any other feasible mechanism than > the write accessor for instantiating a relationship outside a create > accessor. If that's the case, then let's consider this example: ************ R1 ************ * Object A * <----------> * Object B * * *ID * c c * *ID(R1) * ************ ************ It's perfectly legal to have the key identifier of Object B be a referential attribute. However, the conditionality creates a problem. An instance of Object B can exist without an instance of Object A. If I create an instance of Object B (without a corresponding instance of A), can I use a write accessor to set the identifier(which happens to be a referential attribute)? -- Greg Degnan email: gvd@tellabs.com Tellabs Operations,Inc Phone: (630) 512-7307 4951 Indiana Ave Lisle, IL 60532 Subject: Re: (SMU) Synchronous deletion of active objects Greg Eakman writes to shlaer-mellor-users: -------------------------------------------------------------------- Monroe,Jonathan wrote: > > "Monroe,Jonathan" writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > > Tony Humphrey-Lewis writes: > > > Jonathan Monroe wrote: > > > >> I would like to pick that thread up again with some follow-up questions: > > > >> 1. Is the conditionality and multiplicity specification of a relationship > >> an invariant for the processing? > > > If by that you mean that a relationship that is unconditional will never > > become conditional, or become many when it was one then yes it is > > invariant. However, you do have to deal with the fact that things > > happen sequentially. E.G. creating two object instances which have > > a 1:1 relationship will momentarily violate it. i.e. create first object, > > create second and then formalise relationship. > > I was assuming that a non-conditional relationship specified a post > condition for a state action, i.e. that an instance in a (1:1) relationship > MUST have a related instance at the end of the action (any temporary > inconsistency while the action is being processed would be OK). This > appears to be an incorrect assumption. If you consider an architecture in which the actions are not atomic but the individual processes (accessors, tests, ...) are atomic, and each process is on its own processor (a massively parallel architecture), there is still a time between the create of the first object, the create of the second, and the relationship formalization, in which other actions running in parallel may attempt to access that first object and traverse the relationship. This is a bad thing that the architecture must prevent through the use of locks, as HS Lahman alluded to. SMOOA claims to support atomicity at the process level, but this is a good example that shows that it cannot. This interpretation of a SMOOA model cannot work unless the model includes explicit locks within it. This is clearly a lot of extra work that is not related to modeling the subject matter of the domain. I believe that the semantics of SMOOA should only support atomicity at the action level. Thus only one action may be executing at a time. Note that this does not prevent the massively parallel implementation from above, since an architecture could add locks to prevent incorrect interleaving like the above example, while still allowing unrelated processing to continue in parallel. This effectively moves the need for locks from the application and/or service domains into the architecture domain. But enough on atomics. > >> If so, > >> 2. When is the invariant evaluated? At the end of a state action? > >> At the end of a thread of control? > > > On completion of a state action the system must be 'consistent'. > > However I refer you to OL p.106 which discusses consistency of > > data and the issue of propagation time. > > > This says that an action makes the system consistent by "writing data > > ... or by generating events to cause other state machines to come into > > conformance. > > So, its not really an invariant that the architecture can enforce. It would > be difficult to conclusively determine (without some sophisticated > look-ahead ability) that a generated event, when processed, will cause > a transition to a state that will delete a related instance. > > Which leads me another question. For the case where an instance in > a terminal state needs to delete a related (1:1) instance by sending it > an event: > 1. does the generated event have to cause a transition into a state that > actually deletes the instance, OR > 2. can that state generate an event that eventually causes the instance > to be deleted? > > In other words, can all non-conditionality be enforced by the architecture > at the end of a thread of control? -- cut and paste of actual OL quote from Tony Humphrey-Lewis Referring back to OL p.106 you will see that it says that "It is the responsibility of the analyst to ensure that the data required by an action is consistent, or that the action operates in such a way to allow for inconsistencies due to propagation time" -- end paste Since there is no way that I can think of for an architecture to enforce this for each state action, my interpretation of this is that the domain must be consistent when it is in a stable state. "Consistent" means that all invariants defined on the IM are satisfied, as well as any domain and object invariants that exist in the domain's subject matter. "Stable state" means that all processing in the domain is completed - there are actions being executed, the event queue is empty, there are no outstanding wormhole responses or solicited events pending. This really means the end of all threads within the domain. If there were multiple threads active, and one ends, it is likely that the domain invariants still may not hold until the other threads have stopped as well. Ciao Greg -- Greg Eakman email: eakman@atb.teradyne.com Teradyne, ATB Phone: (617)422-3471 179 Lincoln St. FAX: (617)422-3100 MS L50 "The two most common things in the Boston, Ma. 02111 universe are hydrogen and stupidity." Subject: Re: (SMU) Referential Attributes Greg Eakman writes to shlaer-mellor-users: -------------------------------------------------------------------- gvd@tellabs.com wrote: > > gvd@tellabs.com writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > I have a question about write accessors and referential attributes. > The OL book indicates that write accessors update the value of an > attribute of an instance of an object. From an OOA perspective, > can write accessors update referential attributes? > > I realize that CASE tools and the architecture folks won't look > kindly on this question. The architectures don't necessarily > need to translate referential attributes into variables. > > I haven't found a formalism that discusses relating instances of > objects, although it's informally mentioned throughout the OL > book. I mistakenly faulted the methodology for not formalizing > the creation of subtype and supertypes last week (thanks to > Greg Eakman and Jay Case for properly defending the methodology), > so I thought I'd ask if someone can point me to the formalism. > Our CASE tool and our architecture probably won't permit write > accessors for referential attributes, so my question is more > informational than practical. SMOOA proper uses only data to formalize relationships. Thus a relationship does not exist until the formalizing attributes are set, and a write accessor must be used to do that. On our first SMOOA project here, we used this techique to formalize relationships. To traverse relationships, we had to get the formalizing attributes and use a find accessor to get the object on the other side. This was actually somewhat confusing when we got to code generation, using a pointer based architecture. Sometimes the attributes were used only to navigate relationships, sometimes only as data, sometime for both. We had to infer from the use of the attributes what the purpose of the access was. So, based on this experience, I find myself advocating a variant of the method which supports the distinction of relations creation, traversal, and deletion from attribute access. KC's ASL is the variant I'm most familiar with, so I'll describe it quickly. ASL supports a link, unlink, and -> (traverse) construct. The link construct formalizes the relationship, and, in doing so, sets the formalizing attributes to the appropriate value. In this case, the use of a write accessor to override the formalizing attribute would be in bad form if not prevented by the tool. The exception to this is that a create accessor which has a formalizing attribute as its primary identifier must have that formalizing attribute's value explicitly set. To summarize, the answer to your question is (and increasingly becoming) - it depends upon which variant of the method you are using. Ciao Greg -- Greg Eakman email: eakman@atb.teradyne.com Teradyne, ATB Phone: (617)422-3471 179 Lincoln St. FAX: (617)422-3100 MS L50 "The two most common things in the Boston, Ma. 02111 universe are hydrogen and stupidity." Subject: Re: (SMU) Synchronous deletion of active objects Tony Humphrey-Lewis writes to shlaer-mellor-users: -------------------------------------------------------------------- Monroe,Jonathan wrote: > > "Monroe,Jonathan" writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > > Tony Humphrey-Lewis writes: > > > Jonathan Monroe wrote: > I was assuming that a non-conditional relationship specified a post > condition for a state action, i.e. that an instance in a (1:1) relationship > MUST have a related instance at the end of the action (any temporary > inconsistency while the action is being processed would be OK). This > appears to be an incorrect assumption. Temporary inconsistency is certainly OK and cannot really be avoided. It's how you handle the duration of this inconsistency in your model or architecture that's important. For example if you take the view that State Actions are atomic (as per Greg Eakman's reply) then dealing with it synchronously in the state action means you no longer have a problem. If you continue to send events though, there is still the time taken to receive/process that event. Alternatively taking the non-atomic action with infinite parallelism of Greg Eakman's reply even synchronous activities at the ADFD process bubble can give rise to problems. Which you would need to handle either architecturally or in the model. > So, its not really an invariant that the architecture can enforce. It would > be difficult to conclusively determine (without some sophisticated > look-ahead ability) that a generated event, when processed, will cause > a transition to a state that will delete a related instance. That's right. An architecture can try to enforce it by making state actions atomic for example, but once you introduce events which are responsible for ensuring the necessary consistency is achieved it becomes an issue for the analyst. > Which leads me another question. For the case where an instance in > a terminal state needs to delete a related (1:1) instance by sending it > an event: > 1. does the generated event have to cause a transition into a state that > actually deletes the instance, OR > 2. can that state generate an event that eventually causes the instance > to be deleted? Either is valid, although I would suggest that 1 makes life simpler. > In other words, can all non-conditionality be enforced by the architecture > at the end of a thread of control? The simple answer is Maybe but I'll refer you to Greg's reply where he talks about empty event queues and active threads. ___________________________________________________________________ Anthony Humphrey-Lewis email: hlewisa@ncp.gpt.co.uk Siemens GEC Communication Systems Ltd. Technology Drive, Beeston Tel: +44 (0)115 943 4290 Nottingham United Kingdom Fax: +44 (0)115 943 3805 Subject: Re: (SMU) Reference Descriptions lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Lane... > The Bridgepoint CASE tool provides the capability to enter a description > for relationships, referential attributes, and attribute references. Can > anyone tell me the difference between the information that might belong > in the referential attribute description versus the attribute reference > description? After writing a relationship description (containing the > info described in OL pg. 24 ) and referential attribute description > (using OL pg. 19 as a guide), I am at a loss for anything else that > might need to be said about the relationship an its referential > attributes. First, let me qualify that I don't use Bridgepoint, so I am not exactly sure about the context of these descriptions. I would speculate that in most cases they will be the same and you might want to just refernce a central definition. [We tend to use a lot of compound identifiers to resolve loops so we find ourselves defining the same identifying attribute in several objects, so we have adopted the convention of only providing a detailed description at the first (parent) occurence.] One exception I can think of might occur for a conditional relationship when the relationship exists for only a subset of the referential attribute's data domain. For example, the relationship between a State object and a Confiscatory Tax object might only exist when the State object's identifier, State Name, had a value of "Massachusetts". This might be usefully described in the attribute reference for the relationship. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Synchronous deletion of active objects lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Monroe... > Which leads me another question. For the case where an instance in > a terminal state needs to delete a related (1:1) instance by sending it > an event: > 1. does the generated event have to cause a transition into a state that > actually deletes the instance, OR > 2. can that state generate an event that eventually causes the instance > to be deleted? While Eakman, Humphrey-Lewis, and I have waxed enthusiastically about the implications of relationship consistency with event-based deletes, let me take a step back to your original premise. As I recall you originally opened with a statement to the effect that using a delete event seemed preferrable to using a synchronous delete accessor, based upon the consensus of a prior SMUG thread. Many of the problems that have been described in this thread could be overcome by using synchronous delete accessors if we assume atomic functionality at the state level rather than the process level. Thus if PET EUTHANASIA center synchronously invokes DOG's and DOG OWNER's delete accessors, the system is could be consistent at the end of the action. Thus we have a tradeoff to be evaluated in selecting the means of handling the deletes rather than a hard-and-fast rule. So if you happen to be in one of those nasty situations (e.g., multithreading, aynchronous external events, etc.) where relationship consistency is going to be a *practical* problem, then synchronous deletes may be the proper way to go. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Referential Attributes lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Degnan... Regarding the need to use a write accessor: > If that's the case, then let's consider this example: > > ************ R1 ************ > * Object A * <----------> * Object B * > * *ID * c c * *ID(R1) * > ************ ************ > > It's perfectly legal to have the key identifier of Object B be > a referential attribute. However, the conditionality creates a > problem. An instance of Object B can exist without an instance > of Object A. If I create an instance of Object B (without a > corresponding instance of A), can I use a write accessor to set > the identifier(which happens to be a referential attribute)? For the sake of unaccustmed brevity I will not dwell on the fact that B needs another identifier in addition to ID, sicne it doesn't affect the discussion. Since B.ID is an identifier of B it must be assigned when B is created, so there would be no need to assign it later with a write accessor. (I believe it would be incorrect to change it later with a simple write accessor; a delete/create would be required.) Note that if A and B already exist and one then decides to instantiate the relationship, the IM dictates that they both have to have the same identifier ID and no setting would be required. Having established that there is no *need* to set the ID with a write accessor, I assume the point of the question is: how does one indicate the instantiation of the relationship in the OOA? I believe the answer is that one still uses the write accessor and leaves it up to the architecture to Do the Right Thing. That is, the architecture should recognize that an identifier is being updated and check if the values match. If so, don't update; otherwise raise an error. [In effect the code generation tools do this in their transforms that handle relationship instantiation.] -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Referential Attributes hogan writes to shlaer-mellor-users: -------------------------------------------------------------------- On Tue, 15 Apr 1997 gvd@tellabs.com wrote: > > If that's the case, then let's consider this example: > > ************ R1 ************ > * Object A * <----------> * Object B * > * *ID * c c * *ID(R1) * > ************ ************ > > It's perfectly legal to have the key identifier of Object B be > a referential attribute. However, the conditionality creates a > problem. An instance of Object B can exist without an instance > of Object A. If I create an instance of Object B (without a > corresponding instance of A), can I use a write accessor to set > the identifier(which happens to be a referential attribute)? > I wouldn't consider this a valid model. Making B.ID the referential attribute implies that R1 is not conditional on the A side. If an instance of B is created, then B.ID must be set. Since B.ID is also the referential attribute, then this indicates that an instance of the R1 relationship exists, and therefore the instance of A with the same ID value also exists. If the relationship is truly bi-conditional, then a separate referential attribute should be created in object B. One attribute can't identify an object instance and simultaneously indicate that it is not related to another object. I will concede that a scheme could be devised to deal with this in the architecture, but I think that the additional attribute is a much cleaner way to do it. Setting of identifiers is normally only done during creation. Just my opinion, Bary Hogan Lockheed Martin Tactical Aircraft Systems Subject: Re: (SMU) Referential Attributes lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to hogan... > > ************ R1 ************ > > * Object A * <----------> * Object B * > > * *ID * c c * *ID(R1) * > > ************ ************ > > I wouldn't consider this a valid model. Making B.ID the referential > attribute implies that R1 is not conditional on the A side. If an > instance of B is created, then B.ID must be set. Since B.ID is also the > referential attribute, then this indicates that an instance of the R1 > relationship exists, and therefore the instance of A with the same ID > value also exists. > > If the relationship is truly bi-conditional, then a separate referential > attribute should be created in object B. One attribute can't identify > an object instance and simultaneously indicate that it is not related to > another object. > > I will concede that a scheme could be devised to deal with this in the > architecture, but I think that the additional attribute is a much cleaner > way to do it. Setting of identifiers is normally only done during creation. The model, as written, is not valid, but I believe for a different reason than the one you suggest. S-M essentially just requires that identifiers be provided in one object that uniquely identify the other object(s). The "(R1)" notation merely indicates that the attribute *may* be used to identify a particular instance of the related object, A, and that it must have valid values *if* the relationship is instantiated. The basic model is that one would search the set of all instances of A for one with the matching identifiers. There is no requirement that the referential attribute itself indicate whether the relationship is active; you would have to look for the instance of A and not find it to know that the relationship was not instantiated. [Of course one rarely implements using the Find model for performance reasons and the implemented identifier may well provide a direct clue like a NULL pointer to indicate the relationship is not instantiated. One practical view of conditionality is that it simply tells the Architecture when it must deal gracefully with the special case of no instance.] As far as the cleanliness of using separate, non-identifier relational attributes is concerned, I am not sure I can but into that. When you use coumpound identifiers for resolving relationship loops it is almost impossible to avoid having object identifiers serve double duty as relational attributes. Using separate relational attributes would clutter the attribute list and I believe it would also be misleading because it would imply that the related instance might NOT belong to the same family of compound identifiers when, in fact, it does. For example, in the given example, the model is quite explicit that the identifier "ID" for both A and B *must* be the same if they are to be related. In fact, the model is not valid if B's identifer is simply "ID" and there are non-identifier attributes in both A and B. This is because the relationship does require ID to be identical in both objects so one can no longer guarantee separate "functional dependence" for any non-identifier data in A and B per OOA96. Therefore B should have another attribute in its identifier. This would not be the case if one used a separate relational attribute because B.ID would no longer be constrained to be identical to some A.ID when the relationship is active so the functional dependencies could be separated with the simple identifier. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Referential Attributes hogan writes to shlaer-mellor-users: -------------------------------------------------------------------- On Thu, 17 Apr 1997, lahman wrote: > lahman writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Responding to hogan... > > > > ************ R1 ************ > > > * Object A * <----------> * Object B * > > > * *ID * c c * *ID(R1) * > > > ************ ************ > > > > I wouldn't consider this a valid model. Making B.ID the referential > > attribute implies that R1 is not conditional on the A side. If an > > instance of B is created, then B.ID must be set. Since B.ID is also the > > referential attribute, then this indicates that an instance of the R1 > > relationship exists, and therefore the instance of A with the same ID > > value also exists. > > > > If the relationship is truly bi-conditional, then a separate referential > > attribute should be created in object B. One attribute can't identify > > an object instance and simultaneously indicate that it is not related to > > another object. > > > > I will concede that a scheme could be devised to deal with this in the > > architecture, but I think that the additional attribute is a much cleaner > > way to do it. Setting of identifiers is normally only done during creation. > > The model, as written, is not valid, but I believe for a different > reason than the one you suggest. S-M essentially just requires that > identifiers be provided in one object that uniquely identify the other > object(s). The "(R1)" notation merely indicates that the attribute *may* > be used to identify a particular instance of the related object, A, and > that it must have valid values *if* the relationship is instantiated. > The basic model is that one would search the > set of all instances of A for one with the matching identifiers. > > There is no requirement that the referential attribute itself indicate > whether the relationship is active; you would have to look for the > instance of A and not find it to know that the relationship was not > instantiated. [Of course one rarely implements using the Find model for > performance reasons and the implemented identifier may well provide a > direct clue like a NULL pointer to indicate the relationship is not > instantiated. One practical view of conditionality is that it simply > tells the Architecture when it must deal gracefully with the special > case of no instance.] If this is the case, then there is no reason to invoke a write accessor for B.ID to instantiate the R1 relationship as you indicated in your original reply. Simply creating an instance of A with A.ID = B.ID should do the trick. Forget the architecture for a moment. There is nothing in the analysis itself other than the object instances along with their attributes to indicate whether a relationship currently exists. I have to admit that I have always considered it necessary to set a referential atttribute to some "null" value when a conditional relationship is not formalized. If this is not the case, then I stand corrected. Anyone else have an opinion on this? > As far as the cleanliness of using separate, non-identifier relational > attributes is concerned, I am not sure I can but into that. When you > use coumpound identifiers for resolving relationship loops it is almost > impossible to avoid having object identifiers serve double duty as > relational attributes. Using separate relational attributes would > clutter the attribute list and I believe it would also be misleading > because it would imply that the related instance might NOT belong to the > same family of compound identifiers when, in fact, it does. I agree that it is better to use the identifier to formalize the relationship if possible, but I had (incorrectly?) assumed it was not possible due to the conditionality in the example. We also use identifiers as referential attributes all the time. When the relationship is unconditional or conditional on only one side, this works out rather nicely. > For example, in the given example, the model is quite explicit that the > identifier "ID" for both A and B *must* be the same if they are to be > related. In fact, the model is not valid if B's identifer is simply > "ID" and there are non-identifier attributes in both A and B. This is > because the relationship does require ID to be identical in both objects > so one can no longer guarantee separate "functional dependence" for any > non-identifier data in A and B per OOA96. Therefore B should have > another attribute in its identifier. You've lost me here. I went back and re-read Chapter 2 of OOA96, and I don't see a problem. Since A and B are separate objects, the principles set forth are not necessarily violated if A and/or B have non-identifying attributes. That is to say, both A and B can be "properly attributed" and also be related as in the example. Am I missing your point? Regards, Bary Hogan LMTAS Subject: Re: (SMU) Referential Attributes lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to hogan... > If this is the case, then there is no reason to invoke a write accessor > for B.ID to instantiate the R1 relationship as you indicated in your > original reply. Simply creating an instance of A with A.ID = B.ID should > do the trick. Forget the architecture for a moment. There is nothing in > the analysis itself other than the object instances along with their > attributes to indicate whether a relationship currently exists. You need the write accessor because the relationship was conditional. The presence of the write accessor indicates *when* the architecture/code generator should instantiate the conditional relationship. Since the architecture may be using some arbitrary mechanism to implement relationship navigation, it may need to perform some action when the relationship is actually instantiated. Just because the OOA has the identifier pull double duty doesn't mean the architecture can't use separate mechanisms for identifiers and relational links and, in fact, most do. If, for performance reasons, the architecture uses a separate pointer for the relationship navigation, then it might also use a NULL value to signal no relationship currently exists. It would then need to know when the relationship was actually instantiated so that it could update the pointer. However, you trigger an interesting question for which I do not have an answer: how does one express termination of the relationship in the OOA if the relational attribute is also an identifier? Clearly one can't define a data domain for the relational attribute that includes NOT_ACTIVE and use a write accessor to set the identifier with it. The tools all get around this by substituting specific relationship create/delete functions instead of depending upon attribue write accessors. However, it seems to me this is a hole in the OOA representation. Any Major Guru comments on this? Regarding functional dependence: > You've lost me here. I went back and re-read Chapter 2 of OOA96, and I > don't see a problem. Since A and B are separate objects, the > principles set forth are not necessarily violated if A and/or B have > non-identifying attributes. That is to say, both A and B can be > "properly attributed" and also be related as in the example. Am I missing > your point? In A the non-referential attributes are functionally dependent upon the identifying attributes. Similarly, in B the non-referential attributes would be functionally dependent upon its identifiers. However, if the identifying attributes in A and B are identical, then the non-referential attributes need to be consolidated into the same object since attributes with the same functional dependence need to be in the same entity. [There is, no doubt, some more precise way of stating this by quoting Normal Forms, but I forgot which were which about 35 years ago. So I am in the position of a Supreme Court Justice delivering an opinion on a pornography case: I know what's right, but I haven't had enough recent practice to describe it.] -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Referential Attributes baryh@why.net (Bary Hogan) writes to shlaer-mellor-users: -------------------------------------------------------------------- >lahman writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >Responding to hogan... > >> If this is the case, then there is no reason to invoke a write = accessor >> for B.ID to instantiate the R1 relationship as you indicated in your >> original reply. Simply creating an instance of A with A.ID =3D B.ID = should >> do the trick. Forget the architecture for a moment. There is nothing= in >> the analysis itself other than the object instances along with their >> attributes to indicate whether a relationship currently exists. > >You need the write accessor because the relationship was conditional.=20 >The presence of the write accessor indicates *when* the >architecture/code generator should instantiate the conditional >relationship. Since the architecture may be using some arbitrary >mechanism to implement relationship navigation, it may need to perform >some action when the relationship is actually instantiated. I would argue that *when* is as soon as the instance of A is created. If= the particular tool being used requires something to indicate that the = relationship is formalized, then that's fine. However, I don't believe that makes it = a general rule. An architecture/code generator could do the inefficient = Find accessor (i.e. Find instance of A with A.ID =3D B.ID) to determine when = the relationship exists. Is it possible for an instance of A to exist with A.ID =3D B.ID, without = the R1 relationship formalized? In my opinion, it is not possible. Requiring a= write accessor to formalize R1 in this case implies that it is possible since I= could choose not to do it. =20 >However, you trigger an interesting question for which I do not have an >answer: how does one express termination of the relationship in the OOA >if the relational attribute is also an identifier? Clearly one can't >define a data domain for the relational attribute that includes >NOT_ACTIVE and use a write accessor to set the identifier with it. The >tools all get around this by substituting specific relationship >create/delete functions instead of depending upon attribue write >accessors. However, it seems to me this is a hole in the OOA >representation. Any Major Guru comments on this? My view of the method solves this problem. The only way to terminate the relationship in the example is to delete the instance of A or the = instance of B that is related. If the tool additionally requires a relationship = delete, then fine, but that's a tool issue. Of course, any Major Guru ruling would be= much appreciated. > >Regarding functional dependence: > >In A the non-referential attributes are functionally dependent upon the >identifying attributes. Similarly, in B the non-referential attributes >would be functionally dependent upon its identifiers. However, if the >identifying attributes in A and B are identical, then the >non-referential attributes need to be consolidated into the same object >since attributes with the same functional dependence need to be in the >same entity. You are probably correct. I was only applying the guidelines to one = object at a time. However, I thought it was acceptable to model a complex real world= entity as multiple objects. Generally, these objects would have the exact same identifier and would be related 1:1 unconditionally. Is this really a = bad thing to do? Regards, Bary Hogan Subject: (SMU) Immediate Event Processing Michael Hendry writes to shlaer-mellor-users: -------------------------------------------------------------------- Hi everyone. Here's an architectural question, but first: THE ANALYSIS SETUP: There are two objects, objectA and objectB. In the state action of objectA, stateA1, generates an event to objectB, eventB1. Assume eventB1 causes a transition in objectB to stateB1. THE ARCHITECTURE: The architecture translates the generation of eventB1 and stateB1 actions into procedures that work as follows. When eventB1 is called it determines that the instance (instance information is passed as a parameter of the procedure.) can accept the event and the event causes a transition to stateB1. At this point the procedure eventB1 immediately calls the procedure stateB1 that in turn executes the actions found in that state. This means that the actions of stateB1 complete before returning to stateA1 to complete its actions. Now I know this could be carried on to other immediately processed events in other object instances executing other states, etc. But to keep it simple assume that the thread described terminates at stateB1 and returns to stateA1 after completion. THE QUESTION: Does this translation violate the OOA execution paradigm? If not, are there any precautions that should be taken? Any opinions are valued. Michael J. Hendry Sundstrand Aerospace Rockford, IL MJHendry@snds.com Subject: Re: (SMU) Referential Attributes lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Hogan... Regarding the instantiation of a relationship: > I would argue that *when* is as soon as the instance of A is created. If the > particular tool being used requires something to indicate that the relationship > is formalized, then that's fine. However, I don't believe that makes it a > general rule. An architecture/code generator could do the inefficient Find > accessor (i.e. Find instance of A with A.ID = B.ID) to determine when the > relationship exists. > > Is it possible for an instance of A to exist with A.ID = B.ID, without the R1 > relationship formalized? In my opinion, it is not possible. Requiring a write > accessor to formalize R1 in this case implies that it is possible since I could > choose not to do it. If the relationship is only instantiated when an instance is created, there would be no need to do it with a write accessor; that would be a proper job for a create accessor. The write accessor is needed to instantiate relationships at some indeterminate time *after* both instances have been created. This is commonly the case in situations where there is a 1:M or M:M between two objects where there is also the idea of a "current" relationship to a particular one of the M instances. The main 1:M or M:M relationship is instantiated by the create accessor for one of the objects. However, the relationship that captures currency is a second 1:1 that may be instantiated many times during the instances' life cycles. A timely example for us is that a Test may generate several Messages (1:M), but only one Message is returned immediately (1:1) while the others have to be retrieved asynchronously. Processing determines which Message is the immediate reply message after all instances have been created. > > > >However, you trigger an interesting question for which I do not have an > >answer: how does one express termination of the relationship in the OOA > >if the relational attribute is also an identifier? Clearly one can't > >define a data domain for the relational attribute that includes > >NOT_ACTIVE and use a write accessor to set the identifier with it. The > >tools all get around this by substituting specific relationship > >create/delete functions instead of depending upon attribue write > >accessors. However, it seems to me this is a hole in the OOA > >representation. Any Major Guru comments on this? > > My view of the method solves this problem. The only way to terminate the > relationship in the example is to delete the instance of A or the instance of B > that is related. If the tool additionally requires a relationship delete, then > fine, but that's a tool issue. Of course, any Major Guru ruling would be much > appreciated. Alas, I don't think that works. There are too many situations where the relationship exists only for a portion of the time that the connected instances exist. Relationships like ownership, current relevance, licensing, and others can all be changed (i.e., instantiated with different instances) during the life of their connected instances. I believe this view can only work if one restricts the nature of the object abstractions. It would be fine for the recent DOG OWNER/DOG relationship. However, suppose the owner had more substance and needed to be a PERSON so that owning a DOG became a conditional relationship. This view would have a problem because both PERSON and DOG could clearly exist outside the relationship of ownership (e.g., the PERSON might buy and sell the DOG during the application lifetime). > >Regarding functional dependence: > > You are probably correct. I was only applying the guidelines to one object at a > time. However, I thought it was acceptable to model a complex real world entity > as multiple objects. Generally, these objects would have the exact same > identifier and would be related 1:1 unconditionally. Is this really a bad thing > to do? "Must be" might have been too strong. I remember reducing tables like this many, many moons ago and I believe it was mandatory for the ERD but it might have been just an optimization (e.g., tables with identical row keys waste the space for the duplicated keys). I believe it was mandatory because the collection of relational row keys mean more than just identifiers -- it implies identity itself. Individual identifiers in different objects could coincidently have the same values. However, it would be wrong for rows in two tables to have the same identity. As it happens, we noticed as a result of this thread that in one of our current domains we were violating this. We have a Digital Instrument with an INST_ID identifier. It has has-a relationships to things like System Clock. Since there was only one of each of these per instrument, for convenience INST_ID was reused as an identifier for System Clock (i.e, it had the same name and was assigned with the value of Digital Instrument.INST_ID on creation). A very natural thing to do. When the has-a relationship was instantiated, it was used for that as well since it was known to match Digital Instrument's INST_ID. However, System Clock is a very different critter than a Digital Instrument, which is why we made it a separate object rather than just packing Digital Instrument with its attributes. If it is a different critter, it should have a distinct identity. For clarity that identity should be reflected in an original identifier abstraction, like Sys_Clock_ID. At this point there are two ways to go: One way is to assign Digital Instrument.INST ID to Sys_Clock_ID when creating the System Clock. The idea is that the value of the identifier is different than the identity and it is OK to be coincidently the same. This approach, though, would not allow Sys_Clock_ID to also be the referential attribute of the has-a relationship; we would have to add the separate INST_ID(Rn) referential attribute to System Clock for that because Sys_Clock_ID, being the only identifier, cannot represent the identities of both Digital Instrument and System Clock. The second alternative is to define a compound identifier for System Clock consisting of INST_ID and Sys_Clock_ID. This is nice because it reflects the derivative nature of System Clock to Digital Instrument. It also allows the relationship to be instantiated through System Clock.INST_ID, even though it is an identifier because it is not the whole object identifier and, hence, does not uniquely represent System Clock's identity -- only Digital Instrument's. We chose to correct the problem this way because we already tend to routinely use compound identifiers for loop resolution so it was consistent. You will no doubt astutely note that these two solutions are notationally identical except for whether INST_ID is part of the System Clock identifer set. The thing that is interesting is the logic that got to each place. But either way one gets back to my original point the B in the original example needs another identifier (or a separate relational attribute). Note also, that the relationship between Digital Instrument and System Clock is not restricted in any way by either solution; changing that relationship to, say, 1:Mc is possible and would have no implications for the identities involved. I submit that this robustness is achieved by ensuring that the separate identities are explicitly maintained in the model, which *B.ID(R1) does not do. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Immediate Event Processing peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 01:49 PM 4/21/97 -0500, shlaer-mellor-users@projtech.com wrote: >Michael Hendry writes to shlaer-mellor-users: >-------------------------------------------------------------------- >THE QUESTION: > ... >Does this translation violate the OOA execution paradigm? While this approach (the "synchronous architecture") is somewhat common in simple efforts, in general it can lead to the violation of a very fundamental rule/assumption - "attribute integrity": - an object instance can assume that all attribute values of all instances (including itself) are *consistent* at the beginning of it's action - that instance is then free to do what it needs to the state of the system, including altering attribute values, of both itself and other instances. - that instance is responsible to restore the *consistency* of the system before the completion of the action it is executing (in multi-threaded systems with multiple concurrent execution of OOA actions, significant locking complexity is used to help ensure this consistency.) If you call action functions as soon as an event is 'generated", then you are leaving the middle of one action to go do another. The first action may not have things in order. > If not, >are there any precautions that should be taken? The most common adjustment to this simplest form of the "synchronous architecture" is to accumulate the generated events until the end of the action (when thing must be consistent again), and then synchronously "send" the events, causing transition evaluations and (maybe) actions. This can lead to significant growth in the program call stack in some cases - use your imagination. ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice/fax: +01 508-384-1392 | peterf@pathfindersol.com | ____________________________________________________| Subject: Re: (SMU) Referential Attributes Neil Lang writes to shlaer-mellor-users: -------------------------------------------------------------------- At 12:08 AM 4/17/97 -0500, you wrote: >hogan writes to shlaer-mellor-users: >-------------------------------------------------------------------- > > > >On Tue, 15 Apr 1997 gvd@tellabs.com wrote: > >> >> If that's the case, then let's consider this example: >> >> ************ R1 ************ >> * Object A * <----------> * Object B * >> * *ID * c c * *ID(R1) * >> ************ ************ >> >> It's perfectly legal to have the key identifier of Object B be >> a referential attribute. However, the conditionality creates a >> problem. An instance of Object B can exist without an instance >> of Object A. If I create an instance of Object B (without a >> corresponding instance of A), can I use a write accessor to set >> the identifier(which happens to be a referential attribute)? >> > >I wouldn't consider this a valid model. Making B.ID the referential >attribute implies that R1 is not conditional on the A side. If an >instance of B is created, then B.ID must be set. Since B.ID is also the >referential attribute, then this indicates that an instance of the R1 >relationship exists, and therefore the instance of A with the same ID >value also exists. > >If the relationship is truly bi-conditional, then a separate referential >attribute should be created in object B. One attribute can't identify >an object instance and simultaneously indicate that it is not related to >another object. > >I will concede that a scheme could be devised to deal with this in the >architecture, but I think that the additional attribute is a much cleaner >way to do it. Setting of identifiers is normally only done during creation. > > >Just my opinion, >Bary Hogan > >Lockheed Martin Tactical Aircraft Systems > Barry, you're absolutely right in your comments. The model fragment above is syntactically incorrect. The model fragment states that I can identify an instance of B by the identifer of the corresponding instance of A. Therefore there MUST ALWAYS BE (forgive the shouting) a corresponding instance of A. If there isn't (as stipulated in the conditionality of the above fragment) then I can't use the referential attribute as an identifer. Neil ---------------------------------------------------------------------- Neil Lang nlang@projtech.com Project Technology, Inc. 510-845-1484 x23 2560 Ninth Street, Suite 214 Berkeley, CA 94710 http://www.projtech.com ---------------------------------------------------------------------- Subject: Re: (SMU) Referential Attributes Neil Lang writes to shlaer-mellor-users: -------------------------------------------------------------------- At 08:54 AM 4/17/97 -0400, >lahman writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >Responding to hogan... > >> > ************ R1 ************ >> > * Object A * <----------> * Object B * >> > * *ID * c c * *ID(R1) * >> > ************ ************ >> >> I wouldn't consider this a valid model. Making B.ID the referential >> attribute implies that R1 is not conditional on the A side. If an >> instance of B is created, then B.ID must be set. Since B.ID is also the >> referential attribute, then this indicates that an instance of the R1 >> relationship exists, and therefore the instance of A with the same ID >> value also exists. >> >> If the relationship is truly bi-conditional, then a separate referential >> attribute should be created in object B. One attribute can't identify >> an object instance and simultaneously indicate that it is not related to >> another object. >> >> I will concede that a scheme could be devised to deal with this in the >> architecture, but I think that the additional attribute is a much cleaner >> way to do it. Setting of identifiers is normally only done during creation. > >The model, as written, is not valid, but I believe for a different >reason than the one you suggest. S-M essentially just requires that >identifiers be provided in one object that uniquely identify the other >object(s). The "(R1)" notation merely indicates that the attribute *may* >be used to identify a particular instance of the related object, A, and >that it must have valid values *if* the relationship is instantiated. >The basic model is that one would search the >set of all instances of A for one with the matching identifiers. > >There is no requirement that the referential attribute itself indicate >whether the relationship is active; you would have to look for the >instance of A and not find it to know that the relationship was not >instantiated. [Of course one rarely implements using the Find model for >performance reasons and the implemented identifier may well provide a >direct clue like a NULL pointer to indicate the relationship is not >instantiated. One practical view of conditionality is that it simply >tells the Architecture when it must deal gracefully with the special >case of no instance.] > Not the way OOA deals with this. The referential attribute does in fact directly indicate whether the relationship exists. When the referential attribute has a value other than null (or 'not participating" which is the value we use at PT in our training material to denote an unrelated instance) then the instance of the relationship exists. And there better be be that related instance or else the analysis has a problem. Neil ---------------------------------------------------------------------- Neil Lang nlang@projtech.com Project Technology, Inc. 510-845-1484 x23 2560 Ninth Street, Suite 214 Berkeley, CA 94710 http://www.projtech.com ---------------------------------------------------------------------- Subject: Re: (SMU) Immediate Event Processing Tony Humphrey-Lewis writes to shlaer-mellor-users: -------------------------------------------------------------------- Michael Hendry wrote: > > Michael Hendry writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > > THE ARCHITECTURE: > The architecture translates the generation of eventB1 and > stateB1 actions into procedures that work as follows. When > eventB1 is called it determines that the instance (instance > information is passed as a parameter of the procedure.) can > accept the event and the event causes a transition to stateB1. At > this point the procedure eventB1 immediately calls the > procedure stateB1 that in turn executes the actions found in that > state. This means that the actions of stateB1 complete before > returning to stateA1 to complete its actions. > > > THE QUESTION: > Does this translation violate the OOA execution paradigm? If not, > are there any precautions that should be taken? If you are following the Concurrent (simultaneous) interpretation OL p.104 then there is nothing wrong with this. If you are following the interleaved interpretation then it would be a violation since you have interrupted stateA to run an action of B. In your example the only real issues to look out for are to do with common data accesses in both states, which may affect your processing and ensuring that if stateB1 generated an event back to the same instance of A that you didn't attempt to run a state action, since stateA1 has not yet finished executing. ___________________________________________________________________ Anthony Humphrey-Lewis email: hlewisa@ncp.gpt.co.uk Siemens GEC Communication Systems Ltd. Technology Drive, Beeston Tel: +44 (0)115 943 4290 Nottingham United Kingdom Fax: +44 (0)115 943 3805 Subject: Re: (SMU) Immediate Event Processing David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: -------------------------------------------------------------------- Michael Hendry wrote: > > THE QUESTION: > Does this translation violate the OOA execution paradigm? If not, > are there any precautions that should be taken? There have been a few answers, based on data integrety, etc which require generators to be delayed to the end of the state action. However, there is also a potential event order violation: Imagine state A1 generates 2 events: B1 and C1 (which just happen to be processed in that order). Now imagine that the action of the delivery of B1 generates an Event (A2) that takes us to state A2, which generates event C2. The synchronous nature of the architecture may cause this event ordering: B1 (A -> B) A2 (B -> A) C2 (A -> C) C1 (A -> C) Note that C2 is processed before C1, but event order between two instances (A -> C) must be maintained. Therefore there is a violation. (A slightly less suble problem would be a infinite recursive loop). Subject: Re: (SMU) Immediate Event Processing David Pedlar writes to shlaer-mellor-users: -------------------------------------------------------------------- Peter J. Fontana wrote: > While this approach (the "synchronous architecture") is somewhat common in > simple efforts, in general it can lead to the violation of a very > fundamental rule/assumption - "attribute integrity" Sending events as messages in queues does take a long time. ( eg 1 ms ) If the architecture for a project uses such queues, programmers get to know about the performance issues, and as a result, they try to use less event-generation, and therefore use fewer and bigger objects. (Remember my gripes about big state machines?) The obvious way to speed things up would be to use an architecture where event generation is done by calling subroutines (synchronous) rather than sending messages (asynchronous) . It would therefore be a great pity if this invalidated the models. David Pedlar ( my views only) dwp@ftel.co.uk Subject: Re: (SMU) Immediate Event Processing Tony Humphrey-Lewis writes to shlaer-mellor-users: -------------------------------------------------------------------- Dave Whipp wrote: > > David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Michael Hendry wrote: > > > However, there is also a potential event order violation: > Provided you obey all the Rules about accepting events for processing I don't believe what you describe should happen. > Imagine state A1 generates 2 events: B1 and C1 (which just happen to be > processed in that order). Now imagine that the action of the delivery > of B1 generates an Event (A2) that takes us to state A2, which generates > event C2. > Rules About Actions OL p.105 says that "Only one action of a given state machine can be in execution at any point in time" and "Once initiated, an action of a state machine must complete before another event can be accepted by the same state machine" Therefore on generating the event A2 from the state B1 your architecture has to recognise that the instance of A is already running an action. The event should then have to be queued rather than immediately executing a state action. This is what I was alluding to when I said that you had to watch out for trying to run another state action of A because the previous state has not yet finished executing. The sequence should then be stateA1 generates B1 and executes stateB1 stateB1 queues A2 against A and returns to stateA1 stateA1 generates C1 and executes stateC1 stateC1 returns to stateA1 A2 is dequeued and causes execution of stateA2 stateA2 generates C2 and executes stateC2 stateC2 returns to state A1 which completes > The synchronous nature of the architecture may cause this event ordering: > > B1 (A -> B) > A2 (B -> A) > C2 (A -> C) > C1 (A -> C) > > Note that C2 is processed before C1, but event order between two instances > (A -> C) must be maintained. Therefore there is a violation. If you follow the above rules then this becomes impossible to achieve. > (A slightly less suble problem would be a infinite recursive loop). It also cures the possibility of infinite loops. Because once you have just queued an event for subsequent execution you simply unravel the thread of control back to teh original state. ___________________________________________________________________ Anthony Humphrey-Lewis email: hlewisa@ncp.gpt.co.uk Siemens GEC Communication Systems Ltd. Technology Drive, Beeston Tel: +44 (0)115 943 4290 Nottingham United Kingdom Fax: +44 (0)115 943 3805 Subject: Re: (SMU) Immediate Event Processing David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: -------------------------------------------------------------------- David Pedlar wrote: > Sending events as messages in queues does take a long time. ( eg 1 ms ) > If the architecture for a project uses such queues, > programmers get to know about the performance issues, and as a result, > they try to use less event-generation, and therefore use fewer and > bigger > objects. (Remember my gripes about big state machines?) > > The obvious way to speed things up would be to use an architecture where > event generation is done by calling subroutines (synchronous) > rather than sending messages (asynchronous) . As I have mentioned before, there is another approach - improve the queue mechanism. If you forget about procedural languages, and consider the machine code level, then a queue (FIFO) has the same efficiency as a stack (FILO). You would probably need such a queue to be circular (to stop it wandering around your memory space) but basically they are the same. You could use most of the current techniques (such as stack frames and link pointers) on such a queue - the problem is that there are no high level languages to do it for you. some of the concepts are a bit stange if you think in terms of functions; but if you are willing to accept that each "not-a-function" ends with a "goto next queue frame" instead of "return to prev stack frame" then you should be able to follow what's going on. Dave. Subject: Re: (SMU) Referential Attributes lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Lang... > Not the way OOA deals with this. The referential attribute does in fact > directly indicate whether the relationship exists. When the referential > attribute has > a value other than null (or 'not participating" which is the value > we use at PT in our training material to denote an unrelated instance) > then the instance of the relationship exists. And there better be > be that related instance or else the analysis has a problem. Fascinating! I was obviously not aware of this. On thinking about it, it certainly makes sense because one needs to know when a conditional relationship is instantiated if the relationship life is less than both of the connected instances and my Find model only works for unconditional relationships. Since I am arguing the latter point in another thread I find myself engaged in petard hoisting. I assume that this is simply a notational abstraction and has no nasty implications for the implementation (e.g., requiring an actual attribute for all conditional relationships that has a data domain to support a common value of 'not participating') that would constrain the translation's use of mechanisms for instantiating relationships. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Immediate Event Processing David Yoakley writes to shlaer-mellor-users: -------------------------------------------------------------------- Another "cheap" alternative is to only use synchronous events where they will not cause any harm (e.g. color certain events as synchronous). The burden is on the designer to ensure such colorations will not cause data inconsistencies, infinite loops, or event ordering violations. This is not the approach for everyone but for most designers that understand the OOA rules, its easy and provides significant performance improvements. Any YES this violates the rules but the important thing to remember about the OOA rules is that it is ok to violate them, its just not ok to get caught ;-) In other words, OOA models better execute as if the rules were not violated (consistent data, events received in the correct order etc). Question for Peter Fontana - Have you figured out a way to delay synchronous event generation to the end of the state without incurring roughly the same performance hit as going through an asynchronous queue? dy ________________________________________________________________________ David Yoakley Objective Innovations Inc. Phone: (281) 255-3569 24618 Haigshire Dr. Fax: same Tomball, TX 77375 Replies: yoakley@oiinc.com ________________________________________________________________________ Subject: Re: (SMU) Immediate Event Processing Neil Lang writes to shlaer-mellor-users: -------------------------------------------------------------------- At 10:28 AM 4/22/97 +0100, >Tony Humphrey-Lewis writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >Michael Hendry wrote: >> >> Michael Hendry writes to shlaer-mellor-users: >> -------------------------------------------------------------------- >> > >> >> THE ARCHITECTURE: >> The architecture translates the generation of eventB1 and >> stateB1 actions into procedures that work as follows. When >> eventB1 is called it determines that the instance (instance >> information is passed as a parameter of the procedure.) can >> accept the event and the event causes a transition to stateB1. At >> this point the procedure eventB1 immediately calls the >> procedure stateB1 that in turn executes the actions found in that >> state. This means that the actions of stateB1 complete before >> returning to stateA1 to complete its actions. >> > >> >> THE QUESTION: >> Does this translation violate the OOA execution paradigm? If not, >> are there any precautions that should be taken? > >If you are following the Concurrent (simultaneous) interpretation OL >p.104 then there is nothing wrong with this. > >If you are following the interleaved interpretation then it would be a >violation since you have interrupted stateA to run an action of B. I'd like to remind everyone out there that the atomicity/non-interruptability of an action refers to handling events posted to your own state machine prior to competing your own action. It is not a violation of the OOA time and event rules to allow some other action to execute either simultaneously (or even premptively) while in the midst of executing your own action as long as you don't deal with your events until you complete your action. .... some deletia Neil ---------------------------------------------------------------------- Neil Lang nlang@projtech.com Project Technology, Inc. 510-845-1484 x23 2560 Ninth Street, Suite 214 Berkeley, CA 94710 http://www.projtech.com ---------------------------------------------------------------------- Subject: Re: (SMU) Immediate Event Processing Neil Lang writes to shlaer-mellor-users: -------------------------------------------------------------------- At 11:22 AM 4/22/97 +0100, >David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >Michael Hendry wrote: >> >> THE QUESTION: >> Does this translation violate the OOA execution paradigm? If not, >> are there any precautions that should be taken? > >There have been a few answers, based on data integrety, etc which require >generators to be delayed to the end of the state action. > >However, there is also a potential event order violation: > >Imagine state A1 generates 2 events: B1 and C1 (which just happen to be >processed in that order). Now imagine that the action of the delivery >of B1 generates an Event (A2) that takes us to state A2, which generates >event C2. > >The synchronous nature of the architecture may cause this event ordering: > > B1 (A -> B) > A2 (B -> A) > C2 (A -> C) > C1 (A -> C) > >Note that C2 is processed before C1, but event order between two instances >(A -> C) must be maintained. Therefore there is a violation. > >(A slightly less suble problem would be a infinite recursive loop). Yes, there can be problems with a synchronous event architecture if one is not careful. For instance the above example shows events being accepted in an order that is inconsistent with the OOA time and event rules (in this case the rule about accepting events from the same sender in the order in which they were generated). In a discussion a few years ago (on comp.object I believe) we pointed out that it's the responsibility of any architecture (including synchronous ones) to ensure the delivery of events in an order that's consistent with the OOA rules. There is nothing inherently wrong with a synchronous event architecture but it is not as simple as automatically replacing a Generate Event with a direct invocation of a state action. As Tony Humphrey-Lewis points out in another posting, queuing of some of the events in this thread will make this architecture execute properly. Hope this helps Neil ---------------------------------------------------------------------- Neil Lang nlang@projtech.com Project Technology, Inc. 510-845-1484 x23 2560 Ninth Street, Suite 214 Berkeley, CA 94710 http://www.projtech.com ---------------------------------------------------------------------- Subject: (SMU) OOPSLA'96 Video Tape: Translation: Myth or Reality "Ralph L. Hibbs" writes to shlaer-mellor-users: -------------------------------------------------------------------- Hello E-Smug, University Video Productions has finished their OOPSLA'96 Video collection. One of the tapes from the show is the debate on Translation. Many of you were interested in obtaining a copy for your personal viewing. Below is the description of the tape from their web-site. TRANSLATION: MYTH OR REALITY? Speaker: Grady Booch , Rational Software Corporation Robert Martin , Object Mentor Stephen J. Mellor , Project Technology Michael Lee , Project Technology Sponsor: ACM/SIGPLAN Conference: OOPSLA 1996 US Price: $29.99 / Int'l Price: $39.99 Order #: oo96-Debate New Release Available in NTSC & PAL format Tape Description In the realm of object-oriented technologies there are two major schools of thought. Both schools claim to define mechanisms whereby software applications can be created that are reusable, maintainable and robust. Moreover, both schools claim to use abstraction as a key mechanism for achieving these benefits. At issue is whether is or not these two schools are fundamentally different, or just variations on a n object-oriented theme.

The panel takes the form of an official debate. claim to use abstraction as a key mechanism for achieving these benefits. At issue is whether is or not these two schools are fundamentally different, or just variations on a n object-oriented theme.

The panel takes the form of an official debate. After initial positions and rebuttals, the panel of journalists probe the debaters with the goal of illuminating the underlying issues.

Journalists: Martin Fowler, Consultant; Stehen Garone, International Data Corp.; Marie Lenzi, Consultant. Tape Length: 80 minutes Date Recorded: Oct 96 Usage Suggestions: Upper-division/Graduate-level/Industry & Professional Use Order Info: Web site: http://www.uvc.com/videos/oo96Debate.video.html >From this site you can read about the video, then link to their on-line order form. This form is complete for ordering your video and calculating the correct shipping fees. Phone: (800) 900 1510 or 408 379 0100/ Fax: 408 379 2300 You can call them directly and they can help you from the information in this email. Sincerely, Ralph Hibbs --------------------------- Shlaer-Mellor Method --------------------------- Ralph Hibbs Tel: (510) 845-1484 ext.29 Director of Marketing Fax: (510) 845-1075 Project Technology, Inc. email: ralph@projtech.com 2560 Ninth Street - Suite 214 URL: http://www.projtech.com Berkeley, CA 94710 --------- Improving the Productivity of Real-Time Software Development------ Subject: Re: (SMU) Immediate Event Processing David Yoakley writes to shlaer-mellor-users: -------------------------------------------------------------------- > Neil Lang writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > I'd like to remind everyone out there that the atomicity/non-interruptability > of an action refers to handling events posted to your own state machine > prior to competing your own action. It is not a violation of the OOA > time and event rules to allow some other action to execute either > simultaneously (or even premptively) while in the midst of > executing your own action as long as you don't deal with > your events until you complete your action. > I am confused here. I thought the atomicity rule applied to all actions in the domain. If it only applies to the actions of a given object, then how do you ensure data integrity given that any action can manipulate the data of any instance of *any* other object(s)? Isn't it possible that an action may be making multiple write accesses from one state/action such that if that state is interrupted by the state of some other object then the accessed data may be missleading to this other object? I assume that is why you confirmed in another previous post that some synchronous events may need to be queued at the end of state so I guess the issue is simply which rule or rules ensure the data integrity if not the atomicity rule. ________________________________________________________________________ David Yoakley Objective Innovations Inc. Phone: (281) 255-3569 24618 Haigshire Dr. Fax: same Tomball, TX 77375 Replies: yoakley@oiinc.com ________________________________________________________________________ Subject: Re: (SMU) Immediate Event Processing Tony Humphrey-Lewis writes to shlaer-mellor-users: -------------------------------------------------------------------- Neil Lang wrote: > > Neil Lang writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > > I'd like to remind everyone out there that the atomicity/non-interruptability > of an action refers to handling events posted to your own state machine > prior to competing your own action. It is not a violation of the OOA > time and event rules to allow some other action to execute either > simultaneously (or even premptively) while in the midst of > executing your own action as long as you don't deal with > your events until you complete your action. > You've confused me now. Are you really saying that it is permissible for a state action of another object to run in parallel (or premptively) with another object's state action for the *interleaved* interpretation of time? ___________________________________________________________________ Anthony Humphrey-Lewis email: hlewisa@ncp.gpt.co.uk Siemens GEC Communication Systems Ltd. Technology Drive, Beeston Tel: +44 (0)115 943 4290 Nottingham United Kingdom Fax: +44 (0)115 943 3805 Subject: Re: (SMU) Immediate Event Processing peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- >Question for Peter Fontana - > >Have you figured out a way to delay synchronous event generation >to the end of the state without incurring roughly the same >performance hit as going through an asynchronous queue? First - I do not currently work with any architecture that uses this approach, but I have done some detailed design as an architectural alternative. You've made a good observation, and the answer is "half". Basically you need to "remember" the event data item values of the generated events until the end of the action. The cost of doing this is roughly equivalent to constructing a cheap event shell. The other half of the cost - the part you save - is on the actual queueing. Depending on how you implement your event queue, considering events to self, events from off-task and off-process, cleanup tracing, etc, this queueing cost can be slight or it can be significant. BUT the best thing to keep in mind is Dave Whipp's comments - there is NOTHING that says you have to use a linked list or other similarly general purpose and slow data structures. You don't have to use standard function calls. You don't need "Event" classes. Free you mind - you're in the *software architecture* now - a completely different domain from any analysis world. This is not OMT - be creative. Explore the compelling sensations of pure speed. (zoom.) No - really - I'm OK now. The nice men in the white coats are calling to me ... "I'll be right there fellas..." ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice/fax: +01 508-384-1392 | peterf@pathfindersol.com | ____________________________________________________| Subject: Re: (SMU) Immediate Event Processing lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Lang... > In a discussion a few years ago (on comp.object I believe) we pointed > out that it's the responsibility of any architecture (including > synchronous ones) to ensure the delivery of events in an order > that's consistent with the OOA rules. There is nothing inherently wrong > with a synchronous event architecture but it is not as simple as automatically > replacing a Generate Event with a direct invocation of a state action. > As Tony Humphrey-Lewis points out in another posting, queuing of some > of the events in this thread will make this architecture execute properly. What is not clear to me is how one gets the architecture to enforce this in the general case. Queueing seems inconsistent for a synchronous architecture since there is no queue manager and the events have been replaced by synchronous calls. Do you have any techniques that work in a pure synchronous architecture? Even if one does use a hybrid synchronous/asynchronous architecture, how do you figure out which events to color asynchronous? The only general criteria I can think of might be to use the OCM and identify objects where different events pass between them in the same direction and make those asynchronous. In Whipp's example: B1 (A -> B) A2 (B -> A) C2 (A -> C) C1 (A -> C) this would be C1 and C2. But this only works if one places C1 on the queue before B1 is processed, which would require a rather sophisticated look-ahead by the architecture when generating the action code. It will not work if C1 is generated conditionally in the action because you could not simply place it on the queue before B1 is generated. In addition, the OCM rule does not flag the case of the same event with different parameters being issued in the wrong order. I suppose you could look at all actions that generate multiple events and make all but the first aysnchronous instead of using the OCM. But I think this has the same conditionality problem. It would also make a lot of events asynchronous that didn't need to be so. Is there any better (i.e., more cookbook) way to do this analysis? -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) ESMUG Closing While PT Moves "Ralph L. Hibbs" writes to shlaer-mellor-users: -------------------------------------------------------------------- Hello E-Smug, Project Technology is moving corporate headquarters this weekend, to a larger space in San Leandro, California. Unfortunately, this means we will be temporarily taking down our servers, and this means a short vacation for ESMUG. ESMUG's mailing list server will be taken down this evening, and I expect to have it back-up and running some time Tuesday. I will send out a message when it is back up. I apologize for the inconvience this causes the group---especially with the interesting Immediate Event Processing thread underway. Please rush your last-minutes posts today, and then hold-back until next week. PT's operations will not be impacted by the move--as the bulk of the work will occur over the weekend. Only network operations (which includes ESMUG) will experience more than a one-day work outage. Also, please update your address/phone records for PT's new location: Project Technology, Inc. 10940 Bigge Street San Leandro, CA 94577 tel: 510-845-1484 (this isn't changing) fax: 510-567-0250 (new!!!) Have a nice weekend, and we'll see you next week. Sincerely, Ralph Hibbs --------------------------- Shlaer-Mellor Method --------------------------- Ralph Hibbs Tel: (510) 845-1484 ext.29 Director of Marketing Fax: (510) 567-0250 Project Technology, Inc. email: ralph@projtech.com 10940 Bigge Street URL: http://www.projtech.com San Leandro, CA 94577 ------- Improving the Productivity of Real-Time Software Development ------- Subject: Re: (SMU) Immediate Event Processing Dana Simonson writes to shlaer-mellor-users: -------------------------------------------------------------------- >>> lahman 04/23/97 07:30am >>> >What is not clear to me is how one gets the architecture to enforce this >in the general case. Queueing seems inconsistent for a synchronous >architecture since there is no queue manager and the events have >been replaced by synchronous calls. Do you have any techniques that >work in a pure synchronous architecture? One of many possibilities (short on details), Write the state action function with semaphore protection (could be implemented with flags). If the called instance is unable to get the semaphore (already executing) then the event and its data would be stored (could use self-allocating static arrays to avoid the cost of individual allocation) and the function would return. At the end of the already executing state action, it woud release the semaphore, check for pending events and if any existed, call itself (or jump back to the beginning of the routine to avoid stack growth) to process the pending "event". All events are translated to a function call. The function itself handles event queuing so the only events that get queued are ones sent to an executing instance. Subject: Re: (SMU) Immediate Event Processing Neil Lang writes to shlaer-mellor-users: -------------------------------------------------------------------- At 11:41 PM 4/22/97 +0000, you wrote: >David Yoakley writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >> Neil Lang writes to shlaer-mellor-users: >> -------------------------------------------------------------------- >> >> I'd like to remind everyone out there that the atomicity/non-interruptability >> of an action refers to handling events posted to your own state machine >> prior to competing your own action. It is not a violation of the OOA >> time and event rules to allow some other action to execute either >> simultaneously (or even premptively) while in the midst of >> executing your own action as long as you don't deal with >> your events until you complete your action. >> > >I am confused here. I thought the atomicity rule applied to >all actions in the domain. If it only applies to the actions >of a given object, then how do you ensure data integrity given >that any action can manipulate the data of any instance of >*any* other object(s)? That's the responsibility of the analyst who must synchronize the state machines correctly to prevent concurrent data accesses that might have unpleasant results. See rule 2 on page 106 in OL >Isn't it possible that an action may be >making multiple write accesses from one state/action such that if >that state is interrupted by the state of some other object then >the accessed data may be missleading to this other object? Certainly is possible and the analyst needs to deal with it. All this is tied in with the fundamental assertion that state machines in SMOOA execute in parallel. I assume >that is why you confirmed in another previous post that some >synchronous events may need to be queued at the end of state so I >guess the issue is simply which rule or rules ensure the data >integrity if not the atomicity rule. > >________________________________________________________________________ > > David Yoakley > Objective Innovations Inc. Phone: (281) 255-3569 > 24618 Haigshire Dr. Fax: same > Tomball, TX 77375 Replies: yoakley@oiinc.com >________________________________________________________________________ > > Neil ---------------------------------------------------------------------- Neil Lang nlang@projtech.com Project Technology, Inc. 510-845-1484 x23 2560 Ninth Street, Suite 214 Berkeley, CA 94710 http://www.projtech.com ---------------------------------------------------------------------- Subject: Re: (SMU) Immediate Event Processing Neil Lang writes to shlaer-mellor-users: -------------------------------------------------------------------- At 10:12 AM 4/23/97 +0100, >Tony Humphrey-Lewis writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >Neil Lang wrote: >> >> Neil Lang writes to shlaer-mellor-users: >> -------------------------------------------------------------------- >> > >> >> I'd like to remind everyone out there that the atomicity/non-interruptability >> of an action refers to handling events posted to your own state machine >> prior to competing your own action. It is not a violation of the OOA >> time and event rules to allow some other action to execute either >> simultaneously (or even premptively) while in the midst of >> executing your own action as long as you don't deal with >> your events until you complete your action. >> > >You've confused me now. Are you really saying that it is permissible for >a state action of another object to run in parallel (or premptively) >with >another object's state action for the *interleaved* interpretation of >time? Yes that's exactly what I'm saying. There is nothing in the concept of interleaving actions that requires that it be actions that are interleaved. Interleaving "is the view of concurrency supported by multitasking operating systems" -- from OL page 104 -- . Think about each action getting a time-slice to execute in. The first action can lose its time slice before completion ; it then is suspended while other actions execute some. The important thing is that no state machine deal with its events until its action is complete. Hope this clears things up > >___________________________________________________________________ >Anthony Humphrey-Lewis email: hlewisa@ncp.gpt.co.uk >Siemens GEC Communication Systems Ltd. >Technology Drive, Beeston Tel: +44 (0)115 943 4290 >Nottingham United Kingdom Fax: +44 (0)115 943 3805 > > > > Neil Lang ---------------------------------------------------------------------- Neil Lang nlang@projtech.com Project Technology, Inc. 510-845-1484 x23 2560 Ninth Street, Suite 214 Berkeley, CA 94710 http://www.projtech.com ---------------------------------------------------------------------- Subject: Re: (SMU) Immediate Event Processing David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: -------------------------------------------------------------------- Chris Lynch wrote: >I wrote >>If you forget about procedural languages, and consider the machine code >>level, then a queue (FIFO) has the same efficiency as a stack (FILO). >>You would probably need such a queue to be circular (to stop it wandering >>around your memory space) but basically they are the same. > >If I take your point correctly in the above, I agree that the two >mechanisms are performing the same work with respect to data movement >from one object to another. But what about the additional work involved >to switch execution threads from writer to reader? A call/return pair >is about as short as you can get, while queueing usually introduces >either a pair of context-switches (when multitasking) or a trip through >the event loop (single tasking). > Or did I miss your point? I think you missed the point. I am looking looking at mechanisms well below the level of context switching. I am suggesting an alternative to the machine code stack. The code involved in a function is something like (using psuedo C syntax with sp=stack pointer and pc = program counter): function: sp += frame_size // do stuff *sp++ = args *sp++ = pc + 2 pc = another_function // branch: sychronous function results = *--sp // do more stuff sp -= frame_size pc = *--sp // branch : caller This is a sychronous process - the called function must complete before the callee continues. Now consider my alternative: A module would queue a task by doing (head, tail = pointer to start and end of queue respectively [head >= tail]): module: my_args = *tail++ // do stuff *head++ = another_module // no branch! *head++ = its_args // do more stuff pc = *tail++ // branch: not necessarily to "another_module" (I've ignored the fact that you probably want a circular queue. I've also assumed that the queue will never be empty - this is probably a reasonable assumption becuase the kernel can run a background task [a module on the same queue!] to test for an empty queue. This is more efficient than having every module do the check. The same module could be responsible for reseting the head pointer to anchor the queue) In this case, there is no concept of a sychronous service. Pushing "another_module" onto the queue does not interrupt the operation of "module". The system is asynchronous. Therefore it is implicitly multithreaded. Each module could push more than one queued_module onto the queue, thus creating many threads. Alternatively it could pass 0 next-modules onto the queue, thus terminating a thread. There is no need for any additional overhead for multithreading. It might, in fact, be more efficient than a stack because there is no need to create a new stack frame for local variables. one module always completes before the next one starts, so a single global area can be used for local variables. Oh yes, if you want to emulate a function call in this system, then you can always pass a return address on the queue (as an arg). This would be an asynchronous message-response pair (the "called" module would have to push the return message onto the queue when its ready) There is, of course, nothing to stop a system being implemented using both a queue and a stack to provide a mixture of both sychronous and asynchronous services. Dave. p.s. Chris - I tried to email you direct but your email address didn't work - so I've posted both your question and my response -- David P. Whipp. Not speaking for: ------------------------------------------------------- G.E.C. Plessey Due to transcription and transmission errors, the views Semiconductors expressed here may not reflect even my own opinions! Subject: Re: (SMU) Immediate Event Processing Tony Humphrey-Lewis writes to shlaer-mellor-users: -------------------------------------------------------------------- Neil Lang wrote: > > Neil Lang writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > At 10:12 AM 4/23/97 +0100, > >Tony Humphrey-Lewis writes to shlaer-mellor-users: > >-------------------------------------------------------------------- > > > >Neil Lang wrote: > >> > >> Neil Lang writes to shlaer-mellor-users: > >> -------------------------------------------------------------------- > >> > > > >> > >> I'd like to remind everyone out there that the atomicity/non-interruptability > >> of an action refers to handling events posted to your own state machine > >> prior to competing your own action. It is not a violation of the OOA > >> time and event rules to allow some other action to execute either > >> simultaneously (or even premptively) while in the midst of > >> executing your own action as long as you don't deal with > >> your events until you complete your action. > >> > > > >You've confused me now. Are you really saying that it is permissible for > >a state action of another object to run in parallel (or premptively) > >with > >another object's state action for the *interleaved* interpretation of > >time? > > Yes that's exactly what I'm saying. There is nothing in the concept > of interleaving actions that requires that it be actions that are > interleaved. Interleaving "is the view of concurrency supported > by multitasking operating systems" -- from OL page 104 -- . But how do you reconcile the above with Rule 3b in OL p.105 which says "Concurrency for interleaved interpretation: Only one action can be executing at any time. Once an action gets control, it executes to completion without interruption. Actions from different state machines are interleaved with one another arbitrarily. In other words, the action is the unit of interleaving." > The important thing is that no state machine deal with its events until its action > is complete. > Agreed. I hope I made the deadline. ___________________________________________________________________ Anthony Humphrey-Lewis email: hlewisa@ncp.gpt.co.uk Siemens GEC Communication Systems Ltd. Technology Drive, Beeston Tel: +44 (0)115 943 4290 Nottingham United Kingdom Fax: +44 (0)115 943 3805 Subject: Re: (SMU) OOPSLA'96 Video Tape: Translation: Myth or Reality Campbell McCausland writes to shlaer-mellor-users: -------------------------------------------------------------------- Ralph, Could you get us a PAL copy ? Many thanks, Campbell At 16:14 22/04/97 -0700, you wrote: >"Ralph L. Hibbs" writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >Hello E-Smug, > >University Video Productions has finished their OOPSLA'96 Video collection. >One of the tapes from the show is the debate on Translation. Many of you >were interested in obtaining a copy for your personal viewing. Below is the >description of the tape from their web-site. > >TRANSLATION: MYTH OR REALITY? > > Speaker: > Grady Booch , Rational Software Corporation > Robert Martin , Object Mentor > Stephen J. Mellor , Project Technology > Michael Lee , Project Technology > > Sponsor: ACM/SIGPLAN > Conference: OOPSLA 1996 > > US Price: $29.99 / Int'l Price: $39.99 > Order #: oo96-Debate > New Release > Available in NTSC & PAL format > > Tape Description > >In the realm of object-oriented technologies there are two major schools of >thought. Both schools claim to define mechanisms whereby software >applications can be created that are reusable, maintainable and robust. >Moreover, both schools claim to use abstraction as a key mechanism for >achieving these benefits. At issue is whether is or not these two schools >are fundamentally different, or just variations on a n object-oriented >theme.

The panel takes the form of an official debate. claim to use >abstraction as a key mechanism for achieving these benefits. At issue is >whether is or not these two schools are fundamentally different, or just >variations on a n object-oriented theme.

The panel takes the form of an >official debate. After initial positions and rebuttals, the panel of >journalists probe the debaters with the goal of illuminating the underlying >issues.

Journalists: Martin Fowler, Consultant; Stehen Garone, >International Data Corp.; Marie Lenzi, Consultant. > > > Tape Length: 80 minutes > Date Recorded: Oct 96 > Usage Suggestions: Upper-division/Graduate-level/Industry & >Professional Use > >Order Info: > >Web site: http://www.uvc.com/videos/oo96Debate.video.html > >From this site you can read about the video, then link to their on-line >order form. This form is complete for ordering your video and calculating >the correct shipping fees. > >Phone: (800) 900 1510 or 408 379 0100/ Fax: 408 379 2300 > >You can call them directly and they can help you from the information in >this email. > > >Sincerely, > >Ralph Hibbs > >--------------------------- Shlaer-Mellor Method --------------------------- > Ralph Hibbs Tel: (510) 845-1484 ext.29 > Director of Marketing Fax: (510) 845-1075 > Project Technology, Inc. email: ralph@projtech.com > 2560 Ninth Street - Suite 214 URL: http://www.projtech.com > Berkeley, CA 94710 >--------- Improving the Productivity of Real-Time Software Development------ > > Subject: (SMU) polymorphic events kearnan@Summa4.COM (Gregg Kearnan) writes to shlaer-mellor-users: -------------------------------------------------------------------- Just a little question on polymorphic events... A while back this group had a thread on polymorphic events. In reading OOA96, it is very clear how an event would be mapped to the subtype object when sent to the supertype. If I have an event that is sent to a subtype, but must actually be handled by the supertype (the action is common across all subtypes), do I use the same polymorphic event concept in the analysis? Any help would be appreciated, Gregg Subject: Re: (SMU) Immediate Event Processing Greg Eakman writes to shlaer-mellor-users: -------------------------------------------------------------------- Neil Lang wrote: > > Neil Lang writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > At 11:41 PM 4/22/97 +0000, you wrote: > >David Yoakley writes to shlaer-mellor-users: > >-------------------------------------------------------------------- > > > >> Neil Lang writes to shlaer-mellor-users: > >> -------------------------------------------------------------------- > >> > >> I'd like to remind everyone out there that the atomicity/ non-interruptability > >> of an action refers to handling events posted to your own state machine > >> prior to competing your own action. It is not a violation of the OOA > >> time and event rules to allow some other action to execute either > >> simultaneously (or even premptively) while in the midst of > >> executing your own action as long as you don't deal with > >> your events until you complete your action. > >> > > > >I am confused here. I thought the atomicity rule applied to > >all actions in the domain. If it only applies to the actions > >of a given object, then how do you ensure data integrity given > >that any action can manipulate the data of any instance of > >*any* other object(s)? > > That's the responsibility of the analyst who must synchronize > the state machines correctly to prevent concurrent data accesses that > might have unpleasant results. See rule 2 on page 106 in OL This approach would be extremely, extremely painful for the analyst. The state-interleaved version of time is a much cleaner, safer approach, which still does prevent a parallel implementation. The "total concurrency" model for Shlaer-Mellor, where atomicity is at the process level, fails to satisfy the data integrity rules of OOA. In the above statement from Neil, the analyst must insure that the model meets all the rules. The only ways the analyst can safely do this is to make sure that none of the states will execute concurrently, or add locks to the analysis model to synchronize the processing. For example, lets take the example from another discussion. The 1:1 unconditional relationship requires at least two atomic process modeling elements to formalize, two separate create accessors, where one of the create accessors includes the writing of the formalizing attribute(s). Any concurrently executing state action can lookup the new object and fail walking the unconditional relationship between the two creates (while the relationship is unformalized). There are two ways that I know of to deal with this in the "total concurrency" model. The first is to add the concept of locks around the objects and relationship. These locks would have to be added everywhere in the model, around the create accessors, the find accessors, read/write accessors, etc. These locks would be everwhere in the application domain, while they really should reside in a domain like the architecture. The second alternative is to construct the models such that only one action is executing at any point in time. But this is the interleaved model. > >Isn't it possible that an action may be > >making multiple write accesses from one state/action such that if > >that state is interrupted by the state of some other object then > >the accessed data may be missleading to this other object? > > Certainly is possible and the analyst needs to deal with it. All this > is tied in with the fundamental assertion that state machines in SMOOA > execute in parallel. OK, I've said that SMOOA models, at the analysis level, cannot execute in parallel. The state-interleaved interpretation MUST be used to insure safety and correctness, and not include any architectural dependencies in the application domain. This does not preclude an implementation which is massively parallel. Between the architecture and colorization, the necessary locks can be added at code generation time, without bogging down the application models. Ciao Greg -- Greg Eakman email: eakman@atb.teradyne.com Teradyne, ATB Phone: (617)422-3471 179 Lincoln St. FAX: (617)422-3100 MS L50 "The two most common things in the Boston, Ma. 02111 universe are hydrogen and stupidity." Subject: Re: (SMU) Immediate Event Processing kearnan@Summa4.COM (Gregg Kearnan) writes to shlaer-mellor-users: -------------------------------------------------------------------- > Greg Eakman writes to shlaer-mellor-users: > -------------------------------------------------------------------- > OK, I've said that SMOOA models, at the analysis level, cannot > execute in parallel. The state-interleaved interpretation MUST be > used to insure safety and correctness, and not include any architectural > dependencies in the application domain. > > This does not preclude an implementation which is massively > parallel. Between the architecture and colorization, I'm confused. Above you suggest a state-interleaved interpretation, but also suggest that a massively parallel implementation is not precluded. State-interleaved implies to me that only one atomic action can run at any given point in time. Massively parallel implies the more than one action. These actions would obviously have to be in separate state machines. Could you please clarify? Gregg Subject: (SMU) E-SMUG Back On-line "Ralph L. Hibbs" writes to shlaer-mellor-users: -------------------------------------------------------------------- Hello ESMUG, The mailing list is back online and PT has successfully relocated their corporate headquarters. A couple of points of interest: 1) The mailing list may be slow for two weeks. Our internet connection was tempoarily downgraded. The only impact is that messages will take longer to route through the list. 2) The phone number at PT has changed. This was an unexpected change during the move. So, you can update your records: Project Technology, Inc. 10940 Bigge Street San Leandro, CA 94577 tel: 510-567-0255 (new!!!) fax: 510-567-0250 (new!!!) Sincerely, Ralph Hibbs --------------------------- Shlaer-Mellor Method --------------------------- Ralph Hibbs Tel: (510) 567-0255 ext. 629 Director of Marketing Fax: (510) 567-0250 Project Technology, Inc. email: rlh@projtech.com 10940 Bigge Street URL: http://www.projtech.com San Leandro, CA 94577 ------- Improving the Productivity of Real-Time Software Development ------- 'archive.9705' -- Subject: Re: (SMU) Immediate Event Processing lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Simonson... > >Do you have any techniques that > >work in a pure synchronous architecture? > > Write the state action function with semaphore protection (could be > implemented with flags). If the called instance is unable to get the > semaphore (already executing) then the event and its data would be > stored (could use self-allocating static arrays to avoid the cost of > individual allocation) and the function would return. At the end of the > already executing state action, it woud release the semaphore, check for > pending events and if any existed, call itself (or jump back to the > beginning of the routine to avoid stack growth) to process the pending > "event". If you mean literally writing state actions (i.e., putting the semaphores in the ADFD), then this means that you have implementation detail in the OOA since you would not have to do this for an asynchronous architecture. My track record has not been too good lately, but I am pretty sure this is a no-no. If you are proposing that the code generator do this, then I have a couple of problems with it for the general case. If you introduce semaphores for all events you have effectively reintroduced an asynchronous architecture. If you want to do it selectively, then there is the problem for the architecture of figuring out when to do it. The only general translation rule I can think of would be to introduce semaphores for all objects that have at least one state that generates multiple events. In practice this would usually be most of the active objects. You could manually color the objects requiring semaphores, but in the general case this would require an exhaustive analysis of all possible threads. I also have a problem with the performance. For each transition you have to check the semaphore, set it, and reset it when you are done. This is about the same overhead as that for processing an event in a well designed asynchronous architecture. The problem comes in processing when the semaphore is not available; saving the context involves substantial processing. One can argue that there is similar overhead in managing the event queue, but the point is that if the approaches have similar overhead it defeats the purpose of going to a synchronous architecture in the first place. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) Question on application domain scope "Pierre Geneau" writes to shlaer-mellor-users: -------------------------------------------------------------------- Hello everyone, We are building a system whose responsabilitiy is basically to gather data from either a graphical user interface or a batch interface, provide persistence for this data, transform/compile this data in a form required by another system, transfer the data to this system when required. The system interfaces are therefore: - a graphical user interface (GUI) - a batch (file-based) interface, i.e. data is read from formatted files - a CORBA interface to another system. - a database management system (relational DBMS) interface Initially, this system is single-user: one user at a time can either use the graphical user interface or the batch interface to enter data in the system. In future releases, the system will support multiple concurrent users. We have difficulty deciding how much knowledge the application domain should have with respect to the different interfaces of the system. For example, when data is entered through the graphical user interface, many interactions are required with the user, windows need to be popup and deleted, buttons/menus states need to be controlled, etc. When data is entered in batch mode, a parser is invoked, all data required to create entity X in the application domain is available within one interaction. What should be the scope of the application domain? Should it contains the behavior required to drive the graphical user interface, or should this behavior be placed in an "Application-specific GUI domain"? Should the interface of the application domain be at the level of transactions containing all the data required to complete them, or should it model the detailed interactions required to gather this data through an interactive user interface? Also, we are wondering to which domain/bridge we should assign the code generated by the third-party GUI builder tool that we use to paint our windows. Any suggestions? Any information you can share on these questions would be greatly appreciated, Thank you. ================================================================= Pierre Geneau Tel: (514) 765-8288 Nortel Technologies Fax: (514) 761-8509 Multimedia Communication Systems email: geneau@nortel.ca ================================================================= Subject: Re: (SMU) Question on application domain scope lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Geneau... Alas, there are a lot of roads that one might take here, so you will probably get several answers. Let me start with my view of where the various components should go. > The system interfaces are therefore: > - a graphical user interface (GUI) This goes in a service domain for which the Application is a client. Depending upon the complexity of the GUI it might be in its own domain or a major subsystem in a more general UI domain. > - a batch (file-based) interface, i.e. data is read from formatted files I would probably make this another subsystem in the UI domain. I would imagine it is primarily realized code rather than active objects (i.e., the parser invokes actions that are effectively bridge functions to the relevant domains). > - a CORBA interface to another system. This is an architectural issue. In effect it is a particular type of bridge to the outside world. Depending upon the complexity of the external interface it may be encapsulated in a few bridge functions or it might be fairly ubiquitous in the implementation. No domain other than Architecture should have any inkling that CORBA exists. > - a database management system (relational DBMS) interface This is another architecture issue, similar to CORBA. Unfortunately the newer OODBMSes like Object Store tend to require that its language constructs are everywhere in the implementation code. (They even do nasty things like globally overloading the new operator.) Nonetheless, nobody but the Architecture domain should have any inking about the mechanisms. Persistence is not exlicit in an OOA, so your OOA is unaffected by this. > We have difficulty deciding how much knowledge the application domain > should have with respect to the different interfaces of the system. > For example, when data is entered through the graphical user interface, > many interactions are required with the user, windows need to be popup and > deleted, buttons/menus states need to be controlled, etc. When data is > entered in batch mode, a parser is invoked, all data required to create > entity X in the application domain is available within one interaction. Your UI domain will have objects in it that reflect stuff like Windows and Text Boxes. These should not care about the semantics of your data; they view at as Integer Value, etc. The only operations they perform on it are general ones like range checking input data. The UI domain should not do any processing that depends upon specific semantic information. Similarly, the other domains should know the semantics of the data but should know nothing about how it was obtained. Regardless of the interface to the end user, the UI domain employs the same bridge interface to the other domains. The bridge between the UI and the Application simply passes data back and forth. It may be *convenient* to provide some different bridge functions for the GUI than for the batch interface because of differences in sequencing or whatnot in the UI domain. However, the Application should not know this; it simply Does The Right Thing for any of the data supplied by any of the individual bridge functions. > What should be the scope of the application domain? > Should it contains the behavior required to drive the graphical user interface, > or should this behavior be placed in an "Application-specific GUI domain"? This depends upon what you mean by "drive the GUI". The Application understands the semantics so it provides data to the GUI consistent with those semantics. For example if the application is a Bridge Tutor, it displays the cards played in the order of play dictated by the rules of Bridge. In this sense the Application drives the GUI. However, this driving is done strictly by the selecting the data to be sent to the GUI. The GUI just knows some data has been sent to a screen object in a particular position. The GUI does not know why or who wins the trick. OTOH, the Application should know nothing about message loops, pixels, or any of the rest of the GUI mechanisms. It should not drive those mechanisms specifically. > Should the interface of the application domain be at the level of transactions > containing all the data required to complete them, or should it model the > detailed interactions required to gather this data through an interactive > user interface? This is a rather different question than the others. This is where you will start to get a lot of variation in the answers. The short answer is: it depends. In practice, the requirements on the bridge between the Application and the UI are negotiated. If the Application expects data in large aggregates that span multiple GUI data entry screens, then this might introduce unjustified complexity into the UI domain to support local persistence, convoluted undo, and the like. OTOH, if the GUI sends out data packets that are small subsets of the logically related attributes in the Application, it could introduce some consistency problems in the Application. In reality you balance these considerations and define the data transfer protocol to minimize overall hassle in both domains and the bridge itself. Once the requirements are properly defined, each domain is modeled so that those requirements are fulfilled. It is a subtle but important point that modeling within either domain is done against the bridge requirements (communication events), not against the content of the other domain. That is, the Application domain has to be able to accept some set of asynchronous events containing the data from the UI and process them correctly. At this point the Application can't tell whether those events came from a batch job or a GUI. You, as the analyst for both domains, know *why* the specific events are provided and you may know that some events come only from the GUI. However, this does not affect the way the domain handles the events. > Also, we are wondering to which domain/bridge we should assign > the code generated by the third-party GUI builder tool that we > use to paint our windows. Any suggestions? The GUI builder (and things like widget libraries) are typically placed either in the Archtecture or in their own low level implementation domain. This is mostly a matter of whether you feel it is important to note a specific tool for the application. My rule of thumb would be to use a specific domain if I used different tools in different applications in a family or if it has major implications for the architecture (e.g., RDBMS vs. OODBMS) but I would lump it in with the other Architecture stuff otherwise. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Question on application domain scope peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 11:09 AM 5/1/97 EDT, shlaer-mellor-users@projtech.com wrote: >"Pierre Geneau" writes to shlaer-mellor-users: > ... >We have difficulty deciding how much knowledge the application domain >should have with respect to the different interfaces of the system. > ... Hi Pierre. Interfacing to current generated GUI application frameworks is one of the more delicate domain modeling situations to work through. Domain purity is one of the most import "academic" aspects of the method to get right - the degree to which you achieve subject matter purity determines the conceptual power your abstractions will yield. You should not have any awareness of GUI details in you application domain. This domain may be in a position to make high-level service requests of GUI, but knowledge of dialog interlinking is definately inappropriate, > ... >Also, we are wondering to which domain/bridge we should assign >the code generated by the third-party GUI builder tool that we >use to paint our windows. Any suggestions? The approach we've taken on some recent projects is to allocate the UI-builder-generated code to a realized "GUI" domain. Then model an "Operator Interface" domain (analyzed) above "GUI" that has the job of managing the GUI mechanics, and providing gui services to the rest of the application at a level of abstraction convenient for the clients. If you have a sophisticated gui component in your system, the "OI" domain can be somewhat involved. In more simple situations, there may be no need for an "OI" at all - we've seen both sides. An interesting note: This approach seems to do a reasonable job of containing the gui-specific subject matter in OI and GUI - keeping the rest of the application mostly free of OI/GUI concerns. We have even been successful at keeping knowledge of the application out of the analyzed OI domain. However I have not yet found a satisfactory approach to keep application-specific information out of the realized GUI code. Coming from a couple of recent MFC efforts, I find a lot of application-specific information captured in dialog titles, prompts, input validation, dialog sequencing, information structuring, etc. We've done what we can using services of other domains when possible, but sometimes it seems like Microsoft (just as 1 example) wouldn't understand domain separation if it bit them in the butt. I'll repeat myself - domain purity is very important. Recognizing the realized GUI domain as an exception (and still doing your best there), you should strive for a high degree of subject matter purity throughout your system. The magnitude of the strategic benefits of OOA/RD are directly tied to this. ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice/fax: +01 508-384-1392 | peterf@pathfindersol.com | ____________________________________________________| Subject: Re: (SMU) Immediate Event Processing Greg Eakman writes to shlaer-mellor-users: -------------------------------------------------------------------- Gregg Kearnan wrote: > > kearnan@Summa4.COM (Gregg Kearnan) writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > > > Greg Eakman writes to shlaer-mellor-users: > > -------------------------------------------------------------------- > > > > > OK, I've said that SMOOA models, at the analysis level, cannot > > execute in parallel. The state-interleaved interpretation MUST be > > used to insure safety and correctness, and not include any architectural > > dependencies in the application domain. > > > > This does not preclude an implementation which is massively > > parallel. Between the architecture and colorization, > > I'm confused. Above you suggest a state-interleaved interpretation, but > also suggest that a massively parallel implementation is not precluded. > > State-interleaved implies to me that only one atomic action can run at any > given point in time. Massively parallel implies the more than one action. > These actions would obviously have to be in separate state machines. > > Could you please clarify? > > Gregg What I was trying to say is that the rules for the analysis, ie. the OOA semantics, should only support atomic states. In the implementation, the architecture may weaken this restriction, while still maintaining safety and correctness. Given an analysis that is correct using the atomic state view, the implementation may still be parallel. For example, in the implementation for each state, the architecture may lock all of the objects that that state references. Therefor, any states which use completely disjoint sets of objects may proceed in parallel, since they will never conflict. This is one approach. There are others that will increase the amount of parallelism, but those that I know of require a fair amount of colorization. Did that help? Ciao Greg -- Greg Eakman email: eakman@atb.teradyne.com Teradyne, ATB Phone: (617)422-3471 179 Lincoln St. FAX: (617)422-3100 MS L50 "The two most common things in the Boston, Ma. 02111 universe are hydrogen and stupidity." Subject: (SMU) Domain Knowledge Allen Theobald writes to shlaer-mellor-users: -------------------------------------------------------------------- Greetings! I have been wondering lately (because of recent discussions) "what" particular knowledge a domain has and how it is represented in the OOA? Specifically, I was wondering about the "arhitecture" domain, and the "service" domain. What types of knowledge do these domains possess? Kind Regards, Allen Theobald Subject: (SMU) Comments on Data integrity ("Immediate Events" thread) "Lynch, Chris D. SD" writes to shlaer-mellor-users: -------------------------------------------------------------------- David Yoakley wrote: >... then how do you ensure data integrity given >that any action can manipulate the data of any instance of >*any* other object(s)? > Isn't it possible that an action may be >making multiple write accesses from one state/action such that if >that state is interrupted by the state of some other object then >the accessed data may be missleading to this other object? > I assume that is why you confirmed in another previous post that some >synchronous events may need to be queued at the end of state so I >guess the issue is simply which rule or rules ensure the data >integrity if not the atomicity rule. Neil Lang's response: > That's the responsibility of the analyst who must synchronize > the state machines correctly to prevent concurrent data accesses that > might have unpleasant results. See rule 2 on page 106 in OL While I agree with Neil, I would add the following: * Some "synchronization" would be supplied by the analyst, through monitors and assigners * As mentioned in "States and Processes", when objects "look into" the data of another active object it is easy to create difficulties for both the analysis and the design. Bluntly put, this represents *a contention problem* which the analyst and the architect need to solve. It took me awhile to appreciate this, but once I did, I took great pains to break the habit of "any object reading and writing attributes of any other object". (Just like "Modular Programming, from the early '70's!) The way I deal with this when it does happen is to a) look carefully for race conditions, and b) "color" the OCM and OAM with events and accessors which require special protection. As part of the "colorizing" I would write "translator's notes" for the domain and identify exceptions on the object descriptions. * While analysts are supposed to not know or care about the architecture I think it's fair to point out that in the real world (where you will know your platform and the architecture principles for a domain) your task of looking for race conditions is easier if you know that the "interleaved interpretations of time" is in effect in your domain. Of course, some piece of documentation should state this. Finally, some good news is that ... * With data normalized per SMOOA rules, these special-case locks are somewhat rare. This is the ONLY help you get from the method, in my opinion. (Just think of the nightmare you would have with unnormalized data!) Regards, Chris ------------------------------------------------------------------- Chris Lynch Abbott Ambulatory Infusion Systems (619) 485-7474 San Diego,CA 92128 LYNCHCD@HPD.ABBOTT.COM ------------------------------------------------------------------- Subject: (SMU) SMOOA and CORBA "James McDonald" writes to shlaer-mellor-users: -------------------------------------------------------------------- Has anyone ever used SMOOA in conjunction with CORBA? In embedded systems? -- Regards, Jim McDonald Subject: (SMU) convenient relationships kearnan@Summa4.COM (Gregg Kearnan) writes to shlaer-mellor-users: -------------------------------------------------------------------- This question may arise as a result of an incomplete action language, but I could use some advice on how to handle the problem. Our action language does not allow you to use a 'where x == y' clause so that you can search a set for a specific instance (or subset). On occasion, we will search a set in one state of a state model, finding the particular instance we are interested in, and would like to transition to another state to operate on this instance. We are trying to make the state model simpler, and would prefer to separate actions where it makes sense. We cannot pass an instance handle as an event parameter. Some of our analysts have found it convenient to have an extra 'relationship' which makes note of the fact that "this is the instance I want to use". Traversing this relationship is easy in the state models. In some cases, this relationship is actually a meaningful real-world relationship which reflects static information that had not previously been shown on the IM. In others, the relationship seems to be a state-model relationship rather than an information model relationship. Because we cannot search with a 'where x == y' clause, we are stuck having to pass the identifier of the object as an event parameter and then search through the entire instance set comparing identifiers, just to find the particular instance *again*. Although I know it should be obvious that a 'convenient' relationship should not be constructed to solve an action language shortcoming, we also don't want to have to re-search a list we have already searched. This re-searching becomes part of the analysis, and should theoretically be implemented by the architecture. Any suggestions (or simply opinions)? Gregg Subject: Re: (SMU) Question on application domain scope Ashok A Narain writes to shlaer-mellor-users: -------------------------------------------------------------------- Hello Pierre Geneau: My name is Ashok Narain. I am a developer and work for a company named "Softwire Corporation". This company is based in California, USA. I read your mail to the Shlaer-Mellor users regarding your question on "scope of application domain". I also noted the interfaces that your application needs to support for translating the data and transporting it to another system. As I was going through your mail, I felt that if we (Softwire) could get an opportunity to describe to you what we do, you may find us quite useful in developing your application quickly and with high quality. I have taken the liberty to describe very briefly what we do: One way to describe us is that we build Shlaer-Mellor(S-M) model compiler. This compiler generates (tested) C++ code for a S-M model. This compiler is quite intelligent though. It understands a number of industry-standard interfaces. For example, it understands CORBA objects. Therefore, a model-builder can identify in the s-m model the objects that need to communicate over ORB. He/She can then have (C++) interface code automatically generated by running this model through our compiler. For these (i.e. CORBA) objects, our compiler also generates the IDL to be used by a CORBA client, IDL-> JAVA mapping for WEB based GUI and IDL->OLE to facilitate GUI development using tools available on MS-WINDOWS platform. Our model compiler also understands persistent objects. A model-builder can mark objects in the S-M Object Information Model (OIM) to be persistent. The compiler then automatically generates the schema and the code for creating, deleting, querying these objects. The model-builder simply manipulates these objects in the model like any other object in the model. We use Bridge Point modeling tool that is quite intutive to use and is very compliant with Shlaer-Mellor modeling methodology (Bridge Point comes to us from Project Technology- Sally Shlaer and Steve Mellor are among the owners of this company). In addition to providing the model-compiler, we provide a comprehensive set of tools to test both the model and the generated code. We provide run-time support for running the executables generated from the model. The delivery of the messages exchanged between objects is guaranteed via a reliable transaction service. Towards network management, we support SNMP interface. In future, we will add CMIP/CMIS and SS7 support in our toolkit. Thanks for your patience. I am very interested in talking with you to explore areas where we could be helpful to you. -- Ashok A. Narain Softwire Corporation 900 Larkspur Landing Circle, Suite 179, Larkspur, CA 94939 e-mail: ashok.narain@softwire.com Phone: 415/925-3472 Fax: 415/925-3499 Subject: Re: (SMU) Question on application domain scope Ashok A Narain writes to shlaer-mellor-users: -------------------------------------------------------------------- I intended to send my previous mail to Pierre Geneue only. I apologize for my mistake. It will not happen again. -- Ashok A. Narain Softwire Corporation 900 Larkspur Landing Circle, Suite 179, Larkspur, CA 94939 e-mail: ashok.narain@softwire.com Phone: 415/925-3472 Fax: 415/925-3499 Subject: Re: (SMU) SMOOA and CORBA DTZ writes to shlaer-mellor-users: -------------------------------------------------------------------- James McDonald wrote: > > "James McDonald" writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Has anyone ever used SMOOA in conjunction with CORBA? In embedded systems? > > -- > Regards, > Jim McDonald I have used SMOOA in embedded system for over two years (not with COBRA). I believe SMOOA may be a good tool for the applications which do not care about the performance (e.g. database application). SMOOA and action language treat everything like a database application. Subject: Re: (SMU) convenient relationships "Ken Cook" writes to shlaer-mellor-users: -------------------------------------------------------------------- > kearnan@Summa4.COM (Gregg Kearnan) writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Although I know it should be obvious that a 'convenient' relationship should not be > constructed to solve an action language shortcoming, we also don't want to have to > re-search a list we have already searched. This re-searching becomes part of the > analysis, and should theoretically be implemented by the architecture. > > > Any suggestions (or simply opinions)? > > Gregg we have done the same thing (convenient relationships) for the same reasons. We've also taken action language like the following select many dog_set from instances of dog for each dog in dog_set if ( dog.name == "fido" ) and optimized it during code generation to do a "select...where". It takes some doing, but it works. -Ken Subject: Re: (SMU) SMOOA and CORBA "Ken Cook" writes to shlaer-mellor-users: -------------------------------------------------------------------- > "James McDonald" writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Has anyone ever used SMOOA in conjunction with CORBA? In embedded systems? > We have begun some projects like this. IDL can be generated nicely from SMOOA. A bit of coloring is added to indicate whether attributes are readwrite or readonly. One can color whole objects to indicate whether they should be published as an IDL interface or not. To go a step further, one can use SMOOA to generate skeleton implementations of your interfaces. This makes for an interesting domain chart. I see the ORB and the SM Software Architecture as two domains in the "S/W Arch" portion of the chart. The bridge one develops between these two domains has all the characteristics of a bridge between an application domain and a service domain. We haven't done anything with embedded systems. While I can think of some, what special concerns would you have for embedded systems? -Ken Subject: Re: (SMU) SMOOA and CORBA "Ken Cook" writes to shlaer-mellor-users: -------------------------------------------------------------------- ---------- > > DTZ writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > I have used SMOOA in embedded system for over two years (not with COBRA). I > believe SMOOA may be a good tool for the applications which do not care about > the performance (e.g. database application). SMOOA and action language treat > everything like a database application. I think many SM users have found that it is architecture choices that determine performance, rather than the analysis method. One of my early architectures I designed to implement my SM analysis was embarassingly slow. -Ken Subject: Re: (SMU) SMOOA and CORBA lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to DTZ... > I have used SMOOA in embedded system for over two years (not with COBRA). I > believe SMOOA may be a good tool for the applications which do not care about > the performance (e.g. database application). SMOOA and action language treat > everything like a database application. I agree with Cook that this is an archtitectural issue, not a methodology issue. As an anecdotal data point, we recently we switched archtitectures and got three orders of magnitude improvement in performance and nearly two orders of magnitude improvement in code size without any changes to the OOA. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) SMOOA and CORBA bruce.levkoff@cytyc.com (Bruce Levkoff) writes to shlaer-mellor-users: -------------------------------------------------------------------- shlaer-mellor-users@projtech.com,Internet writes: >From Lahman... > As an anecdotal data point, we recently we switched >archtitectures and got three orders of magnitude improvement in >performance and nearly two orders of magnitude improvement in code size >without any changes to the OOA. Can you describe some of the differences or was it all black box. Who developed the architectures? Thanks, Bruce Subject: Re: (SMU) SMOOA and CORBA lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Levkoff... > > As an anecdotal data point, we recently we switched > >archtitectures and got three orders of magnitude improvement in > >performance and nearly two orders of magnitude improvement in code size > >without any changes to the OOA. > > Can you describe some of the differences or was it all black box. Who > developed the architectures? We switched from automatic code generation based upon a CASE tool architecture to manual code generation using our own architecture. We still use the code generation for simulation (the tool instruments the generated code to do simulation). We upgraded an architecture that we developed awhile back on a pilot project. The basic problem is that the tool vendors have been concentrating on getting the code generator to create correct code rather than concentrating on optimization and configurability. They all seem to have pretty well solved the correct code problem, but performance tends to be pretty abyssmal and they are just now beginning to address this problem. This is not unexpected; it took a decade produce C compilers for PCs that would generate fast code. [When we last evaluated tools we gave relatively little weight to code generation capabilities because we were highly skeptical of their ability to deliver performance; we were right.] Using our own architecture we were able to eliminate a large number of instance searches, implement some objects' instances as simple arrays of data structures, generally cut down on malloc/free operations, eliminated linked lists as the primary vehicle for managing relationships, etc. Since it relates to tools this is a bit off the SMUG charter, so if you want more detailed information I suggest you contact Greg Eakman (eakman@atb.teradyne.com) offline since he is the principle author of our architecture and he was involved in the tool evaluations as well. [Greg is also presenting an interesting paper at ESMUG later this month that proposes a rather novel approach to defining and possibly automatically generating bridges.] -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) SMOOA and CORBA DTZ writes to shlaer-mellor-users: -------------------------------------------------------------------- I agree with Ken and lahman that in SM world, performance is architecture team's job. But remember, SM action language almost use data base concept to do everything. There is no pointer concept. A lot of time, you need to search the same dlist again and again in different state for the same thing. Look at their event deliver, just to many overhead. Sure, some one may say just improve the architecture, but it is often just too complicated to make architecture perfect (well, far from perfect). The key is after OOA and action language determine how to do the job, architecture just cannot or not easily to tune. Architecture is just like a action language compiler. Think like this way, in embedded world, tell your engineer not to think about the performance and depends on compiler to do the job. Also if the "action language compiler" changes (or improves) so frequently, think about your software quality. Every time architecture changes or improves, it may bring new error. SM does not have a way to test a single domain. You probably need to test your system again and again. All these are not easy in Embedded world. Using C++/C, I can easily beat current PT translation 5-10 times (speed). Sure in PC world, just tell the user to buy fater machine (Pentium 66, 75,133, 166, 200 ..) and bigger hard disk. But not in embedded world. Thanks, Ken Cook wrote: > > I think many SM users have found that it is architecture choices that > determine performance, rather than the analysis method. One of my early > architectures I designed to implement my SM analysis was embarassingly > slow. > > -Ken lahman wrote: . > > I agree with Cook that this is an archtitectural issue, not a > methodology issue. As an anecdotal data point, we recently we switched > archtitectures and got three orders of magnitude improvement in > performance and nearly two orders of magnitude improvement in code size > without any changes to the OOA. > Subject: Re: (SMU) SMOOA and CORBA DTZ writes to shlaer-mellor-users: -------------------------------------------------------------------- lahman wrote: > > We switched from automatic code generation based upon a CASE tool > architecture to manual code generation using our own architecture. That is a smart decision. I hope my company do this way also. SM probably has nothing wrong. The problem is the SM with code generation. > We still use the code generation for simulation (the tool instruments the > generated code to do simulation). Well, I think this may cause consistent problem. Code may work under the simulation tool and not in the real project. This may cause doubling the test effort. > > The basic problem is that the tool vendors have been concentrating on > getting the code generator to create correct code rather than > concentrating on optimization and configurability. They all seem to > have pretty well solved the correct code problem, but performance tends > to be pretty abyssmal and they are just now beginning to address this > problem. Well, something they may not easily improve. There some root cause that is not easily to solve. > This is not unexpected; it took a decade produce C compilers > for PCs that would generate fast code. Well, it should be us (especially small company) to pay it and do the beta test. > Using our own architecture we were able to eliminate a large number of > instance searches, implement some objects' instances as simple arrays of > data structures, generally cut down on malloc/free operations, > eliminated linked lists as the primary vehicle for managing > relationships, etc. > How big is architecture team? Seems to me that it is a big team to improve and maintain the architecture. Subject: Re: (SMU) SMOOA and CORBA kearnan@Summa4.COM (Gregg Kearnan) writes to shlaer-mellor-users: -------------------------------------------------------------------- In an off-line conversation with HS Lahman, we discussed some of the inefficiencies of the action language our tool supports. [HS, please feel free to blast me if I say something incorrect!;)] Our action language forces us to do a few nasty (IMHO) things: 1) If you find an object instance in one state, you have to re-search the set again if you need that same instance in another state. 2) We are not allowed to select sets of object instances based on a criteria: [select ... where == ] or [select ... related by where ... we either select all instances in a set or relationship, select any (with no idea which one you will get), or select one (if the relationship is singular on the side you are trying to select 3) Iteration over a set of instances must procede over *all* instances - there is no concept of a break from the loop Because we are going to hand translate, we are defining our own action language (built off of the existing one, but expanded where needed - and within reason) HS tells me that they pass instance handles as event parameters. We are allowed to pass identifiers, but not handles. Neither of us are sure if handle passing is a valid OOA concept - but maybe it should be... Passing handles allows you to find an instance in one state and pass it to another. HS's suggestion was that the restriction of not passing handles may be intended to force you to pass the attributes of the object, rather than the object. He was not sure. I was concerned that if you pass a handle to an object, you should verify that the object still exists when the event is taken. Of course, your analysis should be robust enough to make sure that doesn't happen. Since there remains to be an authoritative document (i.e a new book) on Action Languages, I would like to know how other people get around these problems. There may be some inventive architecture solutions that people don't want to disclose, but it would be very helpful if hints could be given. Any 'Guru' comments would be more than welcome. Thanks for any help, Gregg Subject: Re: (SMU) SMOOA and CORBA "Ken Cook" writes to shlaer-mellor-users: -------------------------------------------------------------------- > From: Gregg Kearnan > To: shlaer-mellor-users@projtech.com > HS tells me that they pass instance handles as event parameters. We are allowed to > pass identifiers, but not handles. Neither of us are sure if handle passing is > a valid OOA concept - but maybe it should be... Passing handles allows you to find > an instance in one state and pass it to another. HS's suggestion was that the > restriction of not passing handles may be intended to force you to pass the > attributes of the object, rather than the object. He was not sure. > > I was concerned that if you pass a handle to an object, you should verify that > the object still exists when the event is taken. Of course, your analysis should > be robust enough to make sure that doesn't happen. > We also pass instance handles as event parameters. Our architecture does make fast checks to see that things exist before they are used. We have to an a new type "object_reference" to the modeling tool, and we have to color the passed parameter with an object name, so the translator can pass a specific type as an argument. I understand DTZ's concerns with the effort it takes to get an optimized automatic translation. At some point, the number of objects, the number of domains, or the number of model changes grows large enough to make manual translation more costly than writing an optimized translator. I would argue that the key elements of an optimized translator to get right are 1) how events are passed and queued 2) how relationships are stored and traversed 3) how objects are instantiated, stored, and how their extents are gathered. Note that these things are fundamental to the architecture, and should be the handwritten portion (e.g. classes like XXObject, XXObjectExtent, XXObjectSet, XXEQueue, etc) If the design for these things is fast, the action language translation uses these classes and can speedily go about it's business. So I disagree with the notion that the database nature of the action language makes optimization difficult. Subject: Re: (SMU) Immediate Event Processing Neil Lang writes to shlaer-mellor-users: -------------------------------------------------------------------- Our move and the suspension of the list followed by 2 weeks of teaching has kept me from responding to a couple of postings in this thread. Anyway at the risk of beating a dead horse here goes: At 09:56 AM 4/24/97 +0100, you wrote: >Tony Humphrey-Lewis writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >Neil Lang wrote: >> >> Neil Lang writes to shlaer-mellor-users: >> -------------------------------------------------------------------- >> >> At 10:12 AM 4/23/97 +0100, >> >Tony Humphrey-Lewis writes to shlaer-mellor-users: >> >-------------------------------------------------------------------- >> > >> >Neil Lang wrote: >> >> >> >> Neil Lang writes to shlaer-mellor-users: >> >> -------------------------------------------------------------------- >> >> >> > >> >> >> >> I'd like to remind everyone out there that the atomicity/non-interruptability >> >> of an action refers to handling events posted to your own state machine >> >> prior to competing your own action. It is not a violation of the OOA >> >> time and event rules to allow some other action to execute either >> >> simultaneously (or even premptively) while in the midst of >> >> executing your own action as long as you don't deal with >> >> your events until you complete your action. >> >> >> > >> >You've confused me now. Are you really saying that it is permissible for >> >a state action of another object to run in parallel (or premptively) >> >with >> >another object's state action for the *interleaved* interpretation of >> >time? >> >> Yes that's exactly what I'm saying. There is nothing in the concept >> of interleaving actions that requires that it be actions that are >> interleaved. Interleaving "is the view of concurrency supported >> by multitasking operating systems" -- from OL page 104 -- . > >But how do you reconcile the above with Rule 3b in OL p.105 which says > >"Concurrency for interleaved interpretation: Only one action can be >executing at >any time. Once an action gets control, it executes to completion without >interruption. >Actions from different state machines are interleaved with one another >arbitrarily. >In other words, the action is the unit of interleaving." > > Boy I've tried to think of some clever response but I haven't been able to come up with something better than "Oh you mean that type of interleaving :-) " Regardless of the definition of interleaving there still is the case that I posited in my previous posting in which the architecture/OS interrupts an action prior to its completion to allow another action some execution time. It's a different type of interleaving but I'd expect that it would be a common one to run across in simple multitasking architectures. And as we both agree the architecture needs to ensure that the events for that state machine are only processed after it completes its action. > >> The important thing is that no state machine deal with its events until its action >> is complete. >> > >Agreed. > >I hope I made the deadline. > >___________________________________________________________________ >Anthony Humphrey-Lewis email: hlewisa@ncp.gpt.co.uk >Siemens GEC Communication Systems Ltd. >Technology Drive, Beeston Tel: +44 (0)115 943 4290 >Nottingham United Kingdom Fax: +44 (0)115 943 3805 > > > > Neil ---------------------------------------------------------------------- Neil Lang nlang@projtech.com Project Technology, Inc. 510-567-0255 x623 10940 Bigge Street San Leandro, CA 94577 http://www.projtech.com ---------------------------------------------------------------------- Subject: Re: (SMU) SMOOA and CORBA lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to DTZ, > Well, I think this may cause consistent problem. Code may work under the > simulation tool and not in the real project. This may cause doubling the > test effort. True. However, the simulation environment offers some debugging advantages. The big win, though, is early in the cycle when only part of the system is available and where there might be problems that require significant changes. At this time using the simulator is similar to prototyping and there is no investment in the manual code generation. > > > > They all seem to > > have pretty well solved the correct code problem, but performance tends > > to be pretty abyssmal and they are just now beginning to address this > > problem. > > Well, something they may not easily improve. There some root cause that > is not easily to solve. If you mean that there are inherent problems in doing translation than I must disagree. If one can manually translate using predefined rules to an efficient system, then one can build a program to do the same thing. We see no theoretical difficulties in building a code generator for S-M that will generate fast code. There are a few engineering problems left to be solved before that happens, though. > How big is architecture team? Seems to me that it is a big team to > improve and maintain the architecture. Our architecture team consists of Greg Eakman at the moment and I would guess that the architecture has occupied less than half his time in the past year. [He has had significant help, on occassion, from one other person in the past.] -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) SMOOA and CORBA lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to DTZ, > I agree with Ken and lahman that in SM world, performance is architecture > team's job. But remember, SM action language almost use data base concept > to do everything. There is no pointer concept. A lot of time, you need > to search the same dlist again and again in different state for the same > thing. Look at their event deliver, just to many overhead. Sure, some one > may say just improve the architecture, but it is often just too complicated to > make architecture perfect (well, far from perfect). The key is after OOA > and action language determine how to do the job, architecture just cannot > or not easily to tune. We got our improvement by manually coding directly from an action language. There really aren't that many mechanisms that need to be fine tuned: relationship navigation; instance creation/deletion; instance searches; and set operations will probably provide 90% of the performance gain. Once you have the infrastructure for these in templates, it becomes relatively trivial to convert the action language. > Architecture is just like a action language compiler. Think like this way, > in embedded world, tell your engineer not to think about the performance > and depends on compiler to do the job. Also if the "action language compiler" > changes (or improves) so frequently, think about your software quality. > Every time architecture changes or improves, it may bring new error. SM does > not have a way to test a single domain. You probably need to test your > system again and again. All these are not easy in Embedded world. Actually, testing a single domain is pretty easy. Most simulators do this very well and have a harder time with multidomain simulations. In fact, with a few small changes to the event queue manager you can exhaustively unit test individual state actions if you want. If the code generator changes, there is a risk that incorrect code may be generated. This is probably the reason that the tool vendors have concentrated correctness rather than performance. They want to get code generation to the point of user confidence that other language compilers have achieved. That is, if it isn't a mission-critical application you generally don't retest just because you compiled with a new version of the C compiler; instead you rely on the compiler to generate correct code. Once the code generators reach this level (and they are pretty close) the situation is no different than for a conventional language. [Note that with manual generation, you only build the code once; any changes after that are done to that build.] -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) SMOOA and CORBA Greg Eakman writes to shlaer-mellor-users: -------------------------------------------------------------------- DTZ wrote: > > DTZ writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > lahman wrote: > > > > > We switched from automatic code generation based upon a CASE tool > > architecture to manual code generation using our own architecture. > > That is a smart decision. I hope my company do this way also. > SM probably has nothing wrong. The problem is the SM with code generation. Actually, the problem was not with the code generation. The architecture that we used to manually code can be formalized to instruct the computer how to do it. At the time, we did not have the time to spend to formalize the architecture for automatic code generation. We needed to ship a product. We are now looking at options to automate the translation. > > > We still use the code generation for simulation (the tool instruments the > > generated code to do simulation). > > Well, I think this may cause consistent problem. Code may work under the > simulation tool and not in the real project. This may cause doubling the > test effort. Ideally, if two architectures correctly enforce the OOA semantics, the models can be easily be "ported" from one architecture to the other. Just like C code is portable from one compiler to another. However, in the real world, not all architectures handle all the semantics properly, given some of the ambiguity that still exists in the method. (And yes, C code is not quite as portable as we would like either). So while there is some additional work to test two implementations, it is not double. > > Using our own architecture we were able to eliminate a large number of > > instance searches, implement some objects' instances as simple arrays of > > data structures, generally cut down on malloc/free operations, > > eliminated linked lists as the primary vehicle for managing > > relationships, etc. > > > > How big is architecture team? Seems to me that it is a big team to > improve and maintain the architecture. Depending upon the complexity of the architecture, it may not require a big team. Creating the archetypes and translation rules took some time, but the improvement and maintenance hasn't been much of a problem. Ciao Greg -- Greg Eakman email: eakman@atb.teradyne.com Teradyne, ATB Phone: (617)422-3471 179 Lincoln St. FAX: (617)422-3100 MS L50 "The two most common things in the Boston, Ma. 02111 universe are hydrogen and stupidity." Subject: Re: (SMU) SMOOA and CORBA lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Kearnan... > HS tells me that they pass instance handles as event parameters. We are allowed to > pass identifiers, but not handles. Neither of us are sure if handle passing is > a valid OOA concept - but maybe it should be... Passing handles allows you to find > an instance in one state and pass it to another. HS's suggestion was that the > restriction of not passing handles may be intended to force you to pass the > attributes of the object, rather than the object. He was not sure. As a clarification, my concern is that considerable burden is placed on the architecture when instance handles are passed. Not only must the instance handle still be valid, the data must still be consistent. Suppose you pass two handles for instances A and B in an event. If A's attributes are changed but not B's, then when the state processes the event an inconsistent result may be obtained. You can even get inconsistency for a single instance if the data for that instance was modified before the event was processed. In addition you can get into trouble if relationships with the instance change. Then there are the second order effects: State X found the instance of B with the biggest value of Attribute1 and sends the handle off to State Y while, in the meantime before the event is processed, somebody adds a new instance with a larger value of Attribute1. Mechanisms like object locking don't deal with this. All in all it is, at best, a highly risky thing to pass instance handles around. But it is real handy. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) SMOOA and CORBA lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Cook... > I understand DTZ's concerns with the effort it takes to get an optimized > automatic > translation. At some point, the number of objects, the number of domains, > or the > number of model changes grows large enough to make manual translation more > costly than writing an optimized translator. When we do manual translation, we generally live with that code. That is, we maintain the code by making double edits to the models and the code. This is one reason why we still use the instrumented code in the simulator. We want to get everything logically correct before committing to the manual code generation. [In the example I originally cited, we actually got the system working on the hardware with the automated code before doing the manual generation.] > I would argue that the key elements of an optimized translator to get right > are > 1) how events are passed and queued > 2) how relationships are stored and traversed > 3) how objects are instantiated, stored, and how their extents are > gathered. FWIW, I don't recall that we observed big gains, though we did go to a synchronous architecture in most cases. The other two are the biggies, though. I would also add infrastructure to support efficient instance searches to your list, though one could argue this is closely related to (3). -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) SMOOA and CORBA "Ken Cook" writes to shlaer-mellor-users: -------------------------------------------------------------------- ---------- > From: lahman > To: shlaer-mellor-users@projtech.com > Subject: Re: (SMU) SMOOA and CORBA > Date: Thursday, May 08, 1997 2:35 PM > > lahman writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Responding to Kearnan... > > > HS tells me that they pass instance handles as event parameters. We are allowed to > > pass identifiers, but not handles. Neither of us are sure if handle passing is > > a valid OOA concept - but maybe it should be... Passing handles allows you to find > > an instance in one state and pass it to another. HS's suggestion was that the > > restriction of not passing handles may be intended to force you to pass the > > attributes of the object, rather than the object. He was not sure. > > As a clarification, my concern is that considerable burden is placed on > the architecture when instance handles are passed. Not only must the > instance handle still be valid, the data must still be consistent. > Suppose you pass two handles for instances A and B in an event. If A's > attributes are changed but not B's, then when the state processes the > event an inconsistent result may be obtained. You can even get > inconsistency for a single instance if the data for that instance was > modified before the event was processed. In addition you can get into > trouble if relationships with the instance change. Then there are the > second order effects: State X found the instance of B with the biggest > value of Attribute1 and sends the handle off to State Y while, in the > meantime before the event is processed, somebody adds a new instance > with a larger value of Attribute1. Mechanisms like object locking don't > deal with this. good list. It doesn't seem like any of these problems go away if you pass keys (unique ids) rather than instance handles. Passing keys is allowed by the method. We both seem to be passing handles just to eliminate a second search for the instance. Whether time is taken for a second search or not wouldn't seem to change the method, would it? Your handles are not copies, right? Subject: Re: (SMU) Immediate Event Processing Neil Lang writes to shlaer-mellor-users: -------------------------------------------------------------------- Again I don't want to be beating a potentially dead horse but I would like to at least get one last thought in on this issue. At 06:09 PM 4/25/97 -0400, you wrote: >Greg Eakman writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >Neil Lang wrote: >> >> Neil Lang writes to shlaer-mellor-users: >> -------------------------------------------------------------------- >> >> At 11:41 PM 4/22/97 +0000, you wrote: >> >David Yoakley writes to shlaer-mellor-users: >> >-------------------------------------------------------------------- >> > >> >> Neil Lang writes to shlaer-mellor-users: >> >> -------------------------------------------------------------------- >> >> >> >> I'd like to remind everyone out there that the atomicity/ non-interruptability >> >> of an action refers to handling events posted to your own state machine >> >> prior to competing your own action. It is not a violation of the OOA >> >> time and event rules to allow some other action to execute either >> >> simultaneously (or even premptively) while in the midst of >> >> executing your own action as long as you don't deal with >> >> your events until you complete your action. >> >> >> > >> >I am confused here. I thought the atomicity rule applied to >> >all actions in the domain. If it only applies to the actions >> >of a given object, then how do you ensure data integrity given >> >that any action can manipulate the data of any instance of >> >*any* other object(s)? >> >> That's the responsibility of the analyst who must synchronize >> the state machines correctly to prevent concurrent data accesses that >> might have unpleasant results. See rule 2 on page 106 in OL > >This approach would be extremely, extremely painful for >the analyst. The state-interleaved version of time is a much >cleaner, safer approach, which still does prevent a parallel >implementation. > >The "total concurrency" model for Shlaer-Mellor, where atomicity >is at the process level, fails to satisfy the data integrity >rules of OOA. In the above statement from Neil, the analyst must >insure that the model meets all the rules. The only ways the >analyst can safely do this is to make sure that none of >the states will execute concurrently, or add locks to >the analysis model to synchronize the processing. Greg, I think that you've overstated the case here. This is certainly an issue that we at PT have varying ideas but we all agree that Shlaer-Mellor OOA models are intrinsically simultaneous. Let me share what how some of us here think about the data consistancy problem. Each state action accesses some set of data ( we call this the data access set). In some models the data access sets are quite separate; in this case a small amount of synchonization introduced by the analyst will be sufficient to guarantee consistancy without resorting to global locks etc. On the other hand there will classes of problems that involve a great deal of overlap among the data access sets, and it makes a great deal of sense to manage this uniformly and consistently in the architecture rather than doing it piecemeal in the anlysis. In this view there isn't necessarily just one way to deal with data consistancy. The nature of the problem will determine the the approach one should take just like the nature of the problem determines other details of the architecture ......deletia >OK, I've said that SMOOA models, at the analysis level, cannot >execute in parallel. The state-interleaved interpretation MUST be >used to insure safety and correctness, and not include any architectural >dependencies in the application domain. > It is certainly true that a state-interleaved architecture will handle the consistancy of data access sets. But I don't believe that it is the only general solution that does so. As an example consider an architecture that creates a local copy of the data access set upon action initiation; this architecture does not require that actions go to completion. It's not my intention to keep this discussion going (in fact I'm leaving for a couple of weeks of vacation) but I did want to throw in my $.02 worth before we declare a cease-fire and agree to disagree. Neil ---------------------------------------------------------------------- Neil Lang nlang@projtech.com Project Technology, Inc. 510-567-0255 x623 10940 Bigge Street San Leandro, CA 94577 http://www.projtech.com ---------------------------------------------------------------------- Subject: Re: (SMU) SMOOA and CORBA DTZ writes to shlaer-mellor-users: -------------------------------------------------------------------- lahman wrote: > > lahman writes to shlaer-mellor-users: > > If you mean that there are inherent problems in doing translation than I > must disagree. If one can manually translate using predefined rules to > an efficient system, then one can build a program to do the same thing. > We see no theoretical difficulties in building a code generator for S-M > that will generate fast code. There are a few engineering problems left > to be solved before that happens, though. > >From theory, you are right. Anything you can manually translate, you can always build a program to do it. The problem is that it will make translation too complicated. We try to use color concept to translate different object different way. But it will cost a lot effort architecture team to do it and to maintain it. We can easily manually translate ourself. For most of us, the goal is to solve the problem and hit the dead line at minimum cost. > > How big is architecture team? Seems to me that it is a big team to > > improve and maintain the architecture. > > Our architecture team consists of Greg Eakman at the moment and I would > guess that the architecture has occupied less than half his time in the > past year. [He has had significant help, on occassion, from one other > person in the past.] > I read serval your post. It seems to me that you do a lot of manully translation. It is really a good decision I think. This will save you a lot of burden for architecture. Here, everything except bridge and transform is going through automatically translation. Subject: Re: (SMU) SMOOA and CORBA DTZ writes to shlaer-mellor-users: -------------------------------------------------------------------- Greg Eakman wrote: > > Greg Eakman writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > SM probably has nothing wrong. The problem is the SM with code generation. > > Actually, the problem was not with the code generation. The > architecture > that we used to manually code can be formalized to instruct the > computer how to do it. At the time, we did not have the time > to spend to formalize the architecture for automatic code > generation. We needed to ship a product. We are now looking > at options to automate the translation. > O.K. I agree. Put this way, the problem is SM with 100% automatic code generation. Subject: Re: (SMU) SMOOA and CORBA ian@kc.com (Ian Wilkie) writes to shlaer-mellor-users: -------------------------------------------------------------------- Gregg Kearnan wrote: > Date: Thu, 8 May 1997 07:43:21 -0400 > > kearnan@Summa4.COM (Gregg Kearnan) writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > In an off-line conversation with HS Lahman, we discussed some of the inefficiencies > of the action language our tool supports. > > [HS, please feel free to blast me if I say something incorrect!;)] > > Our action language forces us to do a few nasty (IMHO) things: > [problems with Gregg's action language cut] > > Because we are going to hand translate, we are defining our own action language > (built off of the existing one, but expanded where needed - and within reason) > > HS tells me that they pass instance handles as event parameters. We are allowed to > pass identifiers, but not handles. Neither of us are sure if handle passing is > a valid OOA concept - but maybe it should be... Passing handles allows you to find > an instance in one state and pass it to another. HS's suggestion was that the > restriction of not passing handles may be intended to force you to pass the > attributes of the object, rather than the object. He was not sure. The intention behind the instance handle concept in the Action Language that HS is using was that it is simply a short form of the set of identifying attributes. This allows analysts to refer to, for example, "owning_customer" instead of "owning_bank_name, owning_customer_number" (assuming the bank_name and customer_name are the identifying attribute of "customer"). The leads to more succinct and readable Action Language and is less unstable against changes in the information model. If one accepts that handles are semantically equivalent to identifying attributes, then passing handles around in events is no more "invalid" or dangerous than passing identifying attributes around. (The danger of doing either is that it allows analysts to omit relevant relationship from the Information Model. This can be dealt with by modeling strategies and guidelines). Of course, having handles that are explicit in the action language does make it more straight forward for a translator (automatic or human) to turn the action language into code in an instance handle based architecture. However, it is possible to do this from identifying attributes (just as it is possible to take instances handles in the Action Language and turn them into identifying attributes in an RDBMS type architecture). > I was concerned that if you pass a handle to an object, you should verify that > the object still exists when the event is taken. Of course, your analysis should > be robust enough to make sure that doesn't happen. The equivalence of handles and identifying attributes implies that the architecture must "know" if the instance handle refers to a deleted (and thus non-existant) instance. This can be tricky in architectures where the handle becomes simply a memory pointer to some place on the heap, but the problem is soluble. Ian Wilkie ===================================================== Kennedy Carter, 14 The Pines, Broad Street, Guildford Surrey, GU3 3BH, U.K. Tel: (+44) 1483 483 200 Fax: (+44) 1483 483 201 Further Information: http://www.kc.com or info@kc.com ===================================================== Subject: Re: (SMU) SMOOA and CORBA shlaer-mellor-users@projtech.com writes to shlaer-mellor-users: -------------------------------------------------------------------- > > This is a MIME Encoded message. If you are reading this text, > then your mail reader does not support the MIME (Multipurpose > Internet Mail Extensions) standard. To take full advantage of > the features of this message, you need to upgrade your mailer to > a MIME V1.0 compliant package. Some parts of this message may > be in human readable form. > > MIME Decoding Utilities > ----------------------- > To make use of this encoded message, you can decode it using > a MIME Decoding utility. The following are some freely available > MIME decoding utilities: > > UNIX Users > ----------- > Metamail : ftp://ftp.bellcore.com/pub/nsb/mm2.7.tar.Z > This is the Metamail source code distribution. > Mpack : ftp://ftp.andrew.cmu.edu/pub/mpack/mpack-1.5-src.tar.Z > Source code for all platforms. > MACINTOSH Users > --------------- > Mpack : ftp://ftp.andrew.cmu.edu/pub/mpack/mpack-1.5-mac.hqx > Contains the Macintosh binaries > PC Users > --------- > Metamail : ftp://ftp.bellcore.com/pub/nsb/mm2.7.dos.zip > This is the MS-DOS binaries > > Mpack : ftp://ftp.andrew.cmu.edu/pub/mpack/mpack15d.zip > This contains the MS-DOS binaries > MIME-Aware Mail User Agents > --------------------------- > Note that the following Mail User Agents support MIME and hence if > one of these are used the message will be automatically decoded > be in a readable state: > Elm Version 2.4 (UNIX) > ftp://ftp.uu.net/networking/mail/elm > Eudora 1.4.4 (Macintosh, MS-Windows) > ftp://ftp.qualcomm.com/quest/eudora/windows/1.4/eudor144.exe > ftp://ftp.qualcomm.com/quest/eudora/mac/1.4/eudora144.hqx > Pegasus mail (MS-DOS, MS-Windows, Macintosh) > ftp://risc.ua.edu/pub/network/pegasus/* > Pine (UNIX) > ftp://ftp.cac.washington.edu/pine/pine.tar.Z > --gwcNEAvCGccTnGW4fpovmn3769SoHvNy Content-type: text/plain; charset="us-ascii" Greg Eakman writes to shlaer-mellor-users: -------------------------------------------------------------------- DTZ wrote: > > DTZ writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > lahman wrote: > > > > > We switched from automatic code generation based upon a CASE tool > > architecture to manual code generation using our own architecture. > > That is a smart decision. I hope my company do this way also. > SM probably has nothing wrong. The problem is the SM with code generation. Actually, the problem was not with the code generation. The architecture that we used to manually code can be formalized to instruct the computer how to do it. At the time, we did not have the time to spend to formalize the architecture for automatic code generation. We needed to ship a product. We are now looking at options to automate the translation. > > > We still use the code generation for simulation (the tool instruments the > > generated code to do simulation). > > Well, I think this may cause consistent problem. Code may work under the > simulation tool and not in the real project. This may cause doubling the > test effort. Ideally, if two architectures correctly enforce the OOA semantics, the models can be easily be "ported" from one architecture to the other. Just like C code is portable from one compiler to another. However, in the real world, not all architectures handle all the semantics properly, given some of the ambiguity that still exists in the method. (And yes, C code is not quite as portable as we would like either). So while there is some additional work to test two implementations, it is not double. > > Using our own architecture we were able to eliminate a large number of > > instance searches, implement some objects' instances as simple arrays of > > data structures, generally cut down on malloc/free operations, > > eliminated linked lists as the primary vehicle for managing > > relationships, etc. > > > > How big is architecture team? Seems to me that it is a big team to > improve and maintain the architecture. Depending upon the complexity of the architecture, it may not require a big team. Creating the archetypes and translation rules took some time, but the improvement and maintenance hasn't been much of a problem. Ciao Greg -- Greg Eakman email: eakman@atb.teradyne.com Teradyne, ATB Phone: (617)422-3471 179 Lincoln St. FAX: (617)422-3100 MS L50 "The two most common things in the Boston, Ma. 02111 universe are hydrogen and stupidity." --gwcNEAvCGccTnGW4fpovmn3769SoHvNy Content-type: text/plain; charset="us-ascii" Received: from bcarsbf5.localhost (actually bcarsbf5.ott.bnr.ca) by bcarsfbb.ott.bnr.ca; Thu, 8 May 1997 18:40:42 -0400 Received: from projtech.com (actually projtech.projtech.com) by bcarsbf5.localhost; Thu, 8 May 1997 18:40:21 -0400 Received: by projtech.com (4.1/PT-2.55S) id AA12758; Thu, 8 May 97 14:38:42 PDT Message-Id: <337247E8.63DABEB6@atb.teradyne.com> Date: Thu, 08 May 1997 17:38:48 -0400 From: Greg Eakman Organization: Teradyne X-Mailer: Mozilla 3.01 (X11; I; SunOS 4.1.3 sun4m) Mime-Version: 1.0 To: shlaer-mellor-users@projtech.com Subject: Re: (SMU) SMOOA and CORBA References: <3370B7F8.59FE@atb.teradyne.com> <3371372F.4286@bellsouth.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-shlaer-mellor-users@projtech.com Precedence: bulk Reply-To: shlaer-mellor-users@projtech.com Errors-To: owner-shlaer-mellor-users@projtech.com --gwcNEAvCGccTnGW4fpovmn3769SoHvNy-- Subject: Re: (SMU) SMOOA and CORBA lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to DTZ... Regarding difficulty of automatic generation for performance: > From theory, you are right. Anything you can manually translate, you can > always build a program to do it. The problem is that it will make > translation too complicated. We try to use color concept to translate > different object different way. But it will cost a lot effort architecture > team to do it and to maintain it. We can easily manually translate ourself. > For most of us, the goal is to solve the problem and hit the dead line > at minimum cost. All colorization does is define a selection from among alternative mechanisms for a specific OOA element (object, relationship, etc.). If the mechanisms are already defined, then all the tanslation program has to do is insert the selected mechanism for that element. The architecture mechanisms are reusable and should be stable, once developed. In practice I see the biggest problem as not yet having a good suite of alternative mechanisms in the comercial architectures. These are tricky to define because they need to be reusable. Moreover, they must be defined in a manner that is consistent with the way the translator incorporates selections. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) Real time Embedded, Object Oriented people needed Steve Lackey writes to shlaer-mellor-users: -------------------------------------------------------------------- Peter, Please check out this site: http://home1.gte.net/SL/realtime.htm Tell your associates! Thanks, Steve Lackey SL@gte.net Subject: (SMU) process modelling kearnan@Summa4.COM (Gregg Kearnan) writes to shlaer-mellor-users: -------------------------------------------------------------------- I have a question regarding transformation processes in an ADFD and action language equivalents. Looking through "Modeling the World in States," I have been unable to find an example of a transformation process which would be equivalent to assign interest = loan * interest_rate It appears that a simple computation has to be hidden in the implementation of the transformation process. Is this true? I have seen transformation processes which might have a description such as "compute interest" without giving the actual method of computation. Any help would be appreciated. Gregg Subject: Re: (SMU) process modelling lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Respinding to Kearnan... > Looking through "Modeling the World in States," I have been unable to find an > example of a transformation process which would be equivalent to > > assign interest = loan * interest_rate > > It appears that a simple computation has to be hidden in the implementation of > the transformation process. Is this true? > > I have seen transformation processes which might have a description such as > "compute interest" without giving the actual method of computation. The official view is that transforms contain basic algorithmic computations whose implementation may vary but which, at the level of abstraction of an OOA, are not important to the solution description. The transform essentially captures the idea of a black box algorithm that is represented as an abstract process with defined inputs and outputs. A transform called "compute interest" would have inputs of "loan" and "interest_rate" and it would produce the "interest" output. In this simple example it would be a stretch to come up with an example of a valid alternative example of how to compute this, but one that comes to mind is a maintenance situation. Suppose originally "interest" was the total annual interest and "interest_rate" was the annual interest rate. If one needed to change the system so that "interest" was the monthly amount but "interest_rate" had to remain annual, the computation in the process would change but the OOA abstraction would not. The important issue is that in the OOA the data is modeled abstractly. Though part of the model definition is to describe the semantics of the data and provide a data domain, this is done primarily for the translation. The data model does not care much about the semantics of individual attributes; it is concerned with broader issues like data integrity and referential integrity (e.g., that the data is available and you access the correct instance's data for the computation). This comes down to a fundamental difference between S-M and the "elaboration" methodologies. An S-M OOA is a high level abstraction of the solution description that is concerned with large scale issues of communication and flow of control. It is assumed that during translation of a domain the details of the functionality will be provided by other realized modules that are accessed via bridges and transforms. In an OOA a transform represents some abstract but well defined transformation of data. The "compute interest" process bubble is fundamentally no different than a "sort" bubble that uses some flashy quicksort alrgorithm to order a set or a "get optimal flows" bubble that invokes a full linear programming package to solve a subset problem. For the problem in hand in the OOA the actual algorithms are not relevant; one only needs the results of the transformation (and know that an suitable algorithm does exist) and the implementation of the algorithm is left to the translation. In practice an S-M application typically has a lot of basic procedural code that perform operations that are not described in the OOA because they are not important at that level of abstraction. All the OOA does is provide a de facto partitioning and modularization of this procedural code. [Note that OOA96 filled some potential holes by restricting a transform to operating on formal input data rather than employing data store accessors.] Put another way, an OOA is not intended to describe a *detailed* solution. Instead it provides a consistent level of abstraction through the analysis that is approriate for the overall understanding of the problem at hand. For example, for one problem, say to forecast the cost of delivered petroleum, one might invoke a linear programming package through a transform to optimize the tanker flows of crude oil to determine the marginal cost of transport. Since this application doesn't care how the flows are optimized, only what they are, a transform is appropriate. However, if you are the author of that linear programming package you might want to describe it with an OOA because now the package itself is the problem at hand. Having espoused the Party Line, I have to point out that I have been engaged in an ongoing, offline, on-again-off-again debate with Sally and Neil about what can actually be buried in a transform. I argue that one should not place any algorithm in a transform when flow-of-control decisions (i.e., which events will be generated) depend upon the data values resulting from the transformation. My view is that if flow-of-control is affected in the OOA, one must expose the way one got there. Otherwise one cannot execute the model (i.e., simulate). Their view seems to be that you can always stub the transform to do the right thing during model execution. I contend that they would need to define how to do this in the methodology and that it ignores that fact that the algorithm is at the same level of abstraction as the flow-of-control if its results affect that flow-of-control. And that is about where we left off last. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) Deleting conditional relationships in action language lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- It is time to vote on philosophical issues again! Recently we had an interesting philosophical debate over deleting instances having conditional relationships. This tends to be most clear when one uses an action language rather than an ADFD. The problem exists for all conditional relationships, but I will use a doubly conditional as an example because the implications are most clear in that case. Consider two objects linked by a doubly conditional relationship: ObjectA <---------> ObjectB C R1 C Let's further assume that these objects may have other relationships, conditional or not, to other instances. If I want to delete ObjectB using an action langauge I probably have to also deinstantiate all its relationships via some construct like unlink objectA R1 ObjectB If one has a simulation tool that does error checking and one tries to delete an instance before all of its relationships have been formally deinstantiated an error results. Such a tool would also generate an error if one tried to deinstantiate a relationship that was not instantiated. Therefore one must make sure that R1 has been deinstantiated before ObjectB is deleted, but only when it has been instantiated. The core of the debate is when to do this. One approach is to deinstantiate all relationships in ObjectB's delete state before the instance itself is deleted. However, the R1 relationship may not exist. This would require a check to see if it was instantiated before deleting it. This check might involve significant overhead in situations where the the relationship was rarely instantiated. (Admittedly this can be reduced greatly in the translation, but at a cost in space and/or complexity.) Worse, it may mask an analysis error. If the relationship was instantiated when it should not have been, the check will not detect this. The other approach is to require that the action doing the delete be responsible for deinstantiating conditional relationships before invoking the delete action. In theory it should be possible to know whether the relationship should be there or not whithout doing a check on the relationship itself (i.e., the nature of a doubly conditional relationship describes some aspect of the problem that should be apparent). Now one eliminates overhead because the relationship is only deinstantiated when it is known to exist. More importantly, if there is an analysis error causing a non-existent relationship to be deinstantiated or an existing relationship to not be deinstantiated, then an error will result during simluation. The downside of the second approach is that it effectively imposes an order of deinstantiation of relationships on the OOA processing. It also places a burden upon the analyst during mainteance to uncover how, when, and where the original system deinstantiated the relationship and to ensure that the system will still correctly deinstantiate after the changes. In the general case this could become a rather complex task. This work is artificial in that it is introduced solely because of the policy of deinstantiating the conditional relationships outside the delete state. It also tends to introduce "boilerplate" action language statements in places where they are not really relevant (i.e., the action doing the delete doesn't want to see this sort of unlinking stuff; it just wants to delete an isntance). By contrast, if all relationships are deinstantiated in the delete state, the analyst needs only to look at the IM to determine whether referential integrity will be preserved by deleting an instance in a given action. (The real issue is the nonconditional relationships that may require other instances to be deleted in the same action.) The analyst doing the maintenance need not be concerned with the order of deinstantiation of relationships eslewhere in the OOA. So the basic tradeoff is that the first option makes life easier for the analyst doing maintenance but at the cost of possibly masking an analysis error in simulation. The second option eliminates the error masking but at the cost making the maintenance analyst's job more complicated and introducing some action language clutter. So how do people handle this? -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Deleting conditional relationships in action language "Ken Cook" writes to shlaer-mellor-users: -------------------------------------------------------------------- > [snip] > delete state. It also tends to introduce "boilerplate" action language > statements in places where they are not really relevant (i.e., the > action doing the delete doesn't want to see this sort of unlinking > stuff; it just wants to delete an isntance). > > [snip] > So the basic tradeoff is that the first option makes life easier for the > analyst doing maintenance but at the cost of possibly masking an > analysis error in simulation. The second option eliminates the error > masking but at the cost making the maintenance analyst's job more > complicated and introducing some action language clutter. > > So how do people handle this? Seems this is an either/or proposition only if the analysts are using just state actions or just termination states for deletion. I think most models would be better if both styles of deletion were available. Therefore, cleaning up relationships before deleting objects would be done either in the delete state or in the state action calling delete. Code to clean up relationships is boilerplate only as much as all the C/C++ code we've written to free memory allocations. As in that case, life is made a lot easier if the architecture provides automatic clean-up of the relationships upon delete. Yet you're right to identify the simulator as a problem: if a model omits relationship clean-up because one architecture provides it, another architecture(e.g. simulator) may bomb because those statements are missing. So it is probably good to have a rigorous architecture/simulator around to keep our models honest. If I had to choose between the two, I would choose the 2nd option: bring on the relationship clean-up code. -Ken Subject: (SMU) Relationships conditional on attribute values(?) Rich Bowen writes to shlaer-mellor-users: -------------------------------------------------------------------- Novice question: How do I model a relationship that is conditional on an attribute value? For instance, suppose I have a Tree object: TREE * tree ID o produces fruit [yes, no] And suppose I have another object, Fruit Picker, that can have a relationship with a Tree object, but only if the Tree instance is of a type that produces fruit. I had thought that I might create subtypes of Tree: Fruit Tree and Non-Fruit Tree. Then the Fruit Picker would only have a relationship with a Fruit Tree. However, these subtypes would not have any attributes besides identifiers. I am inclined to just write restrictions into the relationship descriptions and not create subtypes. However, I would like for the Information Model to show these restrictions. Is there a correct/better way to represent this type of relationship? Rich -------------------------------------------------------------------- Richard K. Bowen NetEdge Systems, Inc. Email: Rich_Bowen@NetEdge.com http://www.netedge.com -------------------------------------------------------------------- Subject: Re: (SMU) SMOOA and CORBA "Claire Cote" writes to shlaer-mellor-users: -------------------------------------------------------------------- >"Ken Cook" writes to shlaer-mellor-users: >-------------------------------------------------------------------- > > > > DTZ writes to shlaer-mellor-users: > > -------------------------------------------------------------------- > > > > I have used SMOOA in embedded system for over two years (not with COBRA). > > I believe SMOOA may be a good tool for the applications which do not care about > > the performance (e.g. database application). SMOOA and action language treat > > everything like a database application. > I think many SM users have found that it is architecture choices that > determine performance, rather than the analysis method. One of my early > architectures I designed to implement my SM analysis was embarassingly > slow. > > -Ken > In message "(SMU) SMOOA and CORBA", lahman@ATB.Teradyne.COM writes: > lahman writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Responding to DTZ... > > > I have used SMOOA in embedded system for over two years (not with COBRA). I > > believe SMOOA may be a good tool for the applications which do not care about > > the performance (e.g. database application). SMOOA and action language treat > > everything like a database application. > > I agree with Cook that this is an archtitectural issue, not a > methodology issue. As an anecdotal data point, we recently we switched > archtitectures and got three orders of magnitude improvement in > performance and nearly two orders of magnitude improvement in code size > without any changes to the OOA. > > -- > H. S. Lahman There is nothing wrong with me that > 321 Harrison Av L51 couldn't be cured by a capful of Draino > Boston, MA 02118-2238 > v(617)422-3842 > f(617)422-3100 > lahman@atb.teradyne.com > I don't agree that performance is an architectural issue ONLY. The role of the architecture is to map algorithms in the analysis domains into implementation. Each of those algorithms belongs to some order of complexity. The architecture can not produce a log-n implementation given a n-cube algorithm. Of course, the architecture also has its own algorithms (just like any other domain). The importance of their optimization is crucial because they are intensively used. At the beginning of the project, we were faced with serious performance problems. Performance improvements were obtained by modifications brought to the architectural classes, the translation rules, and the analysis. The benefits obtained by modifications to non-architectural algorithms were not negligible; they were as high as the ones obtained by tuning the architecture. Claire Cote Nortel Technologies Tel.: (514) 765-7794 FAX : (514) 761-8509 clairec@nortel.ca Subject: Re: (SMU) Relationships conditional on attribute values(?) "Ken Cook" writes to shlaer-mellor-users: -------------------------------------------------------------------- Use your subtypes, Fruit Tree and Non-fruit tree. Even if your subtypes have only identifiers as attributes, they have something else that is equally as important as identifiers - a relationships. The "more than a list" object test taught in PT class and in S/M first book needs some qualification: IMO, if an object has important state model behavior, or participates in an important relationship, it is ok if it has no attributes other than an identifier. In this case, it truly is more than a list. As your trees grow, I'm sure you will find some interesting attributes (How about "average yearly yield in bushels" for the Fruit Tree?). -Ken ---------- > From: Rich Bowen > To: shlaer-mellor-users@projtech.com > Subject: (SMU) Relationships conditional on attribute values(?) > Date: Thursday, May 15, 1997 12:35 PM > > Rich Bowen writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Novice question: How do I model a relationship that is conditional > on an attribute value? > > For instance, suppose I have a Tree object: > > TREE > * tree ID > o produces fruit [yes, no] > > And suppose I have another object, Fruit Picker, that can have > a relationship with a Tree object, but only if the Tree instance > is of a type that produces fruit. > > I had thought that I might create subtypes of Tree: Fruit > Tree and Non-Fruit Tree. Then the Fruit Picker would only > have a relationship with a Fruit Tree. However, these > subtypes would not have any attributes besides identifiers. > > I am inclined to just write restrictions into the relationship > descriptions and not create subtypes. However, I would like > for the Information Model to show these restrictions. Is there > a correct/better way to represent this type of relationship? > > Rich > > -------------------------------------------------------------------- > Richard K. Bowen NetEdge Systems, Inc. > Email: Rich_Bowen@NetEdge.com http://www.netedge.com > -------------------------------------------------------------------- Subject: Re: (SMU) SMOOA and CORBA "Ken Cook" writes to shlaer-mellor-users: -------------------------------------------------------------------- > From: Claire Cote > > > DTZ writes to shlaer-mellor-users: > > > -------------------------------------------------------------------- > > > > > > I have used SMOOA in embedded system for over two years (not with COBRA). > > > I believe SMOOA may be a good tool for the applications which do not care about > > > the performance (e.g. database application). SMOOA and action language treat > > > everything like a database application. > > I don't agree that performance is an architectural issue ONLY. > [snip] > The benefits obtained by modifications to non-architectural algorithms > were not negligible; they were as high as the ones obtained by > tuning the architecture. You are right, performance improvements can be found by improving architecture, the translations that use the architecture, or the analysis. DTZ original assertion was that "SMOOA may be a good tool for applications which do not care about performance". Indeed, if I had to use some algorithm for some application problem, which I knew had been optimized by others, I would not subject it to a translator. I would put it in a hand-coded domain, or in a hand-coded transform. H.S and I were claiming that there is nothing inherent in the method which leads to poor performance. We pointed to architecture as a culprit. DTZ's performance problems seemed to finger architecture.You are right, though, there can be other villians. -Ken Subject: Re: (SMU) process modelling DTZ writes to shlaer-mellor-users: -------------------------------------------------------------------- I have been used SM and bridge point tool for more than two years. I have learned what transformation and some bridges mean in action language at least most of time. They are really those functions that PT cannot translate and simulate. They are the things that you must do yourself. lahman wrote: > > lahman writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Respinding to Kearnan... > > > Looking through "Modeling the World in States," I have been unable to find an > > example of a transformation process which would be equivalent to > > > > assign interest = loan * interest_rate > > > > It appears that a simple computation has to be hidden in the implementation of > > the transformation process. Is this true? > > > > I have seen transformation processes which might have a description such as > > "compute interest" without giving the actual method of computation. > > The official view is that transforms contain basic algorithmic > computations whose implementation may vary but which, at the level of > abstraction of an OOA, are not important to the solution description. > The transform essentially captures the idea of a black box algorithm > that is represented as an abstract process with defined inputs and > outputs. > > A transform called "compute interest" would have inputs of "loan" and > "interest_rate" and it would produce the "interest" output. In this > simple example it would be a stretch to come up with an example of a > valid alternative example of how to compute this, but one that comes to > mind is a maintenance situation. Suppose originally "interest" was the > total annual interest and "interest_rate" was the annual interest rate. > If one needed to change the system so that "interest" was the monthly > amount but "interest_rate" had to remain annual, the computation in the > process would change but the OOA abstraction would not. > > The important issue is that in the OOA the data is modeled abstractly. > Though part of the model definition is to describe the semantics of the > data and provide a data domain, this is done primarily for the > translation. The data model does not care much about the semantics of > individual attributes; it is concerned with broader issues like data > integrity and referential integrity (e.g., that the data is available > and you access the correct instance's data for the computation). > > This comes down to a fundamental difference between S-M and the > "elaboration" methodologies. An S-M OOA is a high level abstraction of > the solution description that is concerned with large scale issues of > communication and flow of control. It is assumed that during > translation of a domain the details of the functionality will be > provided by other realized modules that are accessed via bridges and > transforms. In an OOA a transform represents some abstract but well > defined transformation of data. The "compute interest" process bubble > is fundamentally no different than a "sort" bubble that uses some flashy > quicksort alrgorithm to order a set or a "get optimal flows" bubble that > invokes a full linear programming package to solve a subset problem. > For the problem in hand in the OOA the actual algorithms are not > relevant; one only needs the results of the transformation (and know > that an suitable algorithm does exist) and the implementation of the > algorithm is left to the translation. > > In practice an S-M application typically has a lot of basic procedural > code that perform operations that are not described in the OOA because > they are not important at that level of abstraction. All the OOA does > is provide a de facto partitioning and modularization of this procedural > code. [Note that OOA96 filled some potential holes by restricting a > transform to operating on formal input data rather than employing data > store accessors.] Put another way, an OOA is not intended to describe a > *detailed* solution. Instead it provides a consistent level of > abstraction through the analysis that is approriate for the overall > understanding of the problem at hand. For example, for one problem, say > to forecast the cost of delivered petroleum, one might invoke a linear > programming package through a transform to optimize the tanker flows of > crude oil to determine the marginal cost of transport. Since this > application doesn't care how the flows are optimized, only what they > are, a transform is appropriate. However, if you are the author of that > linear programming package you might want to describe it with an OOA > because now the package itself is the problem at hand. > > Having espoused the Party Line, I have to point out that I have been > engaged in an ongoing, offline, on-again-off-again debate with Sally and > Neil about what can actually be buried in a transform. I argue that > one should not place any algorithm in a transform when flow-of-control > decisions (i.e., which events will be generated) depend upon the data > values resulting from the transformation. My view is that if > flow-of-control is affected in the OOA, one must expose the way one got > there. Otherwise one cannot execute the model (i.e., simulate). Their > view seems to be that you can always stub the transform to do the right > thing during model execution. I contend that they would need to define > how to do this in the methodology and that it ignores that fact that the > algorithm is at the same level of abstraction as the flow-of-control if > its results affect that flow-of-control. And that is about where we > left off last. > > -- > H. S. Lahman There is nothing wrong with me that > 321 Harrison Av L51 couldn't be cured by a capful of Draino > Boston, MA 02118-2238 > v(617)422-3842 > f(617)422-3100 > lahman@atb.teradyne.com Subject: Re: (SMU) Deleting conditional relationships in action language DTZ writes to shlaer-mellor-users: -------------------------------------------------------------------- We are the software engineers. We should not care that much philosophical issues. My experience tells me no methodology can solve everything. Software engineers should be solve problem themself. The best thing methodology can do is that it can guide the team to do it consistently. Choose a simple way and everyone does it the same way. Keep it simple. lahman wrote: > > lahman writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > It is time to vote on philosophical issues again! > > Recently we had an interesting philosophical debate over deleting > instances having conditional relationships. This tends to be most clear > when one uses an action language rather than an ADFD. The problem > exists for all conditional relationships, but I will use a doubly > conditional as an example because the implications are most clear in > that case. > > Consider two objects linked by a doubly conditional relationship: > > ObjectA <---------> ObjectB > C R1 C > > Let's further assume that these objects may have other relationships, > conditional or not, to other instances. If I want to delete ObjectB > using an action langauge I probably have to also deinstantiate all its > relationships via some construct like > > unlink objectA R1 ObjectB > > If one has a simulation tool that does error checking and one tries to > delete an instance before all of its relationships have been formally > deinstantiated an error results. Such a tool would also generate an > error if one tried to deinstantiate a relationship that was not > instantiated. Therefore one must make sure that R1 has been > deinstantiated before ObjectB is deleted, but only when it has been > instantiated. The core of the debate is when to do this. > > One approach is to deinstantiate all relationships in ObjectB's delete > state before the instance itself is deleted. However, the R1 > relationship may not exist. This would require a check to see if it was > instantiated before deleting it. This check might involve significant > overhead in situations where the the relationship was rarely > instantiated. (Admittedly this can be reduced greatly in the > translation, but at a cost in space and/or complexity.) Worse, it may > mask an analysis error. If the relationship was instantiated when it > should not have been, the check will not detect this. > > The other approach is to require that the action doing the delete be > responsible for deinstantiating conditional relationships before > invoking the delete action. In theory it should be possible to know > whether the relationship should be there or not whithout doing a check > on the relationship itself (i.e., the nature of a doubly conditional > relationship describes some aspect of the problem that should be > apparent). Now one eliminates overhead because the relationship is only > deinstantiated when it is known to exist. More importantly, if there is > an analysis error causing a non-existent relationship to be > deinstantiated or an existing relationship to not be deinstantiated, > then an error will result during simluation. > > The downside of the second approach is that it effectively imposes an > order of deinstantiation of relationships on the OOA processing. It > also places a burden upon the analyst during mainteance to uncover how, > when, and where the original system deinstantiated the relationship and > to ensure that the system will still correctly deinstantiate after the > changes. In the general case this could become a rather complex task. > This work is artificial in that it is introduced solely because of the > policy of deinstantiating the conditional relationships outside the > delete state. It also tends to introduce "boilerplate" action language > statements in places where they are not really relevant (i.e., the > action doing the delete doesn't want to see this sort of unlinking > stuff; it just wants to delete an isntance). > > By contrast, if all relationships are deinstantiated in the delete > state, the analyst needs only to look at the IM to determine whether > referential integrity will be preserved by deleting an instance in a > given action. (The real issue is the nonconditional relationships that > may require other instances to be deleted in the same action.) The > analyst doing the maintenance need not be concerned with the order of > deinstantiation of relationships eslewhere in the OOA. > > So the basic tradeoff is that the first option makes life easier for the > analyst doing maintenance but at the cost of possibly masking an > analysis error in simulation. The second option eliminates the error > masking but at the cost making the maintenance analyst's job more > complicated and introducing some action language clutter. > > So how do people handle this? > > -- > H. S. Lahman There is nothing wrong with me that > 321 Harrison Av L51 couldn't be cured by a capful of Draino > Boston, MA 02118-2238 > v(617)422-3842 > f(617)422-3100 > lahman@atb.teradyne.com Subject: Re: (SMU) SMOOA and CORBA DTZ writes to shlaer-mellor-users: -------------------------------------------------------------------- Ken Cook wrote: > H.S and I were claiming that there is nothing inherent in the method which > leads to poor performance. We pointed to architecture as a culprit. DTZ's > performance problems seemed to finger architecture.You are right, though, > there can be other villians. > > -Ken No, there are a lot of thing inherent in the method and bridge point case tool that leads to poor performance. Let me name some: 1. You cannot pass pointer to self. Imagine this, you are in company A and you call a friend in company B. A: SELECT MANY people FROM B FOR EACH person IN people IF (person.name == "my friend") GENERATE "hello" TO person END IF; END FOR; After B receives this event, even he knows who is calling, he still need to search A to generate an ACK back to A. B: SELECT MANY people FROM A FOR EACH person IN people IF (person.name == "my friend") GENERATE "ack" TO person END IF; END FOR; This is what we call double search. 2. You can only have one way event. No function call concept. Bridge and transform only should be used in simple case. 3. There are no local or static variables. So if you need to do things in different states, you may select again and agian. Select many relate to is not cheap. e.g. In state A, you need to an instance from a class, you need to search. In state B, you need the same instance again, you need to search again. You can establish relationship. But if you look at code to establish relationship, they expensive also (except one to one relationship). 4. Everything need to go through state transition table. Think about this way, if you generate event to yourself, you also need to go through this. 5. All relationship exist on both side even if you only need from one side. If you manully translate most of the code yourself. Sure you can do what ever you like. According, the beauty for SM and bridge point tool is the translation. You force your whole team to do things consistently. But if architecture wants to solve everything, you can imagine the performance. Architecture looks like solution for solution. Subject: Re: (SMU) Deleting conditional relationships in action language peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 09:29 AM 5/15/97 -0400, shlaer-mellor-users@projtech.com wrote: >lahman writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >It is time to vote on philosophical issues again! >... >So how do people handle this? Let me give you the ADFD process modeling perspective. Basically, the invocation of a single Delete accessor is all that is required for proper relationship "unformalization" and instance disposal. Create, Write, and Delete accessors all have the potential of modifying an instance's relationship participation. (Just to remind folks - we don't require a separate "unlink" step). Of course, all of this is done via a single "bubble". We believe significant, pervasive benefits are realized whenever we can eliminate an opportunity for an analyst to specify something incorrectly. ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice/fax: +01 508-384-1392 | peterf@pathfindersol.com | ____________________________________________________| Subject: Re: (SMU) process modelling peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 06:16 PM 5/14/97 -0400, shlaer-mellor-users@projtech.com wrote: >kearnan@Summa4.COM (Gregg Kearnan) writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >I have a question regarding transformation processes in an ADFD and action language >equivalents. > >Looking through "Modeling the World in States," I have been unable to find an >example of a transformation process which would be equivalent to > >assign interest = loan * interest_rate > >It appears that a simple computation has to be hidden in the implementation of >the transformation process. Is this true? > >I have seen transformation processes which might have a description such as >"compute interest" without giving the actual method of computation. > While H.S. response covers many of the higher-level ramifications of this quite well, I'll risk repetition and summarize: Yes. ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice/fax: +01 508-384-1392 | peterf@pathfindersol.com | ____________________________________________________| Subject: Re: (SMU) SMOOA and CORBA "Ken Cook" writes to shlaer-mellor-users: -------------------------------------------------------------------- > From: DTZ > > No, there are a lot of thing inherent in the method and bridge point case tool > that leads to poor performance. Let me name some: > > [list deleted] > > If you manully translate most of the code yourself. Sure you can do what ever > you like. According, the beauty for SM and bridge point tool is the translation. > You force your whole team to do things consistently. But if architecture > wants to solve everything, you can imagine the performance. Architecture looks > like solution for solution. Your list is a good one, but they are all optimized in state-of-the-art model compilers. I can see it from your perspective. It seems you feel your team has a method/translator/architecture that has less performance than you need. >From your perspective, if only the method loosened things up a bit, you could write some really fast stuff, and wouldn't be forced to use all these slow oneway events, state transition tables, etc. So it looks like the method is a performance culprit. You know you could manually translate, but that has a cost. You know, given enough time, that you could build a high-performance translator, but that costs too. The off-the-shelf translators you need for real-time platforms may not be available yet, or it is too late to switch now, or they are too costly. In a sense you are right. The method doesn't care at all about performance. If your architecture takes 6 days, or 6 ms, it doesn't care. All it cares about is the integrity of the analysis. I think until you get a chance to work with a model compiler that provides the performance you want, you will tend to feel that the method is not good for performance. I get the sense that your team will do what is necessary to get the performance you need. I am guessing your system will have some hand-written domains, some hand-translated domains, plenty of transforms for those function calls, and fine-tuned models with all the fat taken out. -Ken Subject: Re: (SMU) Relationships conditional on attribute values(?) Rich Bowen writes to shlaer-mellor-users: -------------------------------------------------------------------- Ken, Thanks for the help. Now let me complicate the example a little. Suppose I add another differentiating attribute to the Tree object: TREE * tree ID o produces fruit [yes, no] --> o makes a good shade tree [yes, no] If I use subtypes to represent the different types of trees then the number of subtypes increases exponentially: Fruit & Shade Tree Fruit & Non-Shade Tree Non-Fruit & Shade Tree Non-Fruit & Non-Shade Tree It seems like this approach becomes intractable if there are very many attributes that dictate whether or not relationships can exist. It also causes me to go back to the Fruit Picker object and modify it so that it can now have relationships with two subtypes of Tree instead of just one. Wouldn't it be simpler just to put some conditional logic in the objects that are interested in Trees with particular attribute values and use a single Tree object? Rich Ken Cook wrote: > > "Ken Cook" writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Use your subtypes, Fruit Tree and Non-fruit tree. > Even if your subtypes have only identifiers as attributes, they > have something else that is equally as important as identifiers - > a relationships. > > The "more than a list" object test taught in PT class and in S/M > first book needs some qualification: IMO, if an object has important state > model behavior, or participates in an important relationship, it > is ok if it has no attributes other than an identifier. In this case, it > truly is more than a list. > > As your trees grow, I'm sure you will find some interesting attributes > (How about "average yearly yield in bushels" for the Fruit Tree?). > > -Ken > ---------- > > From: Rich Bowen > > To: shlaer-mellor-users@projtech.com > > Subject: (SMU) Relationships conditional on attribute values(?) > > Date: Thursday, May 15, 1997 12:35 PM > > > > Rich Bowen writes to shlaer-mellor-users: > > -------------------------------------------------------------------- > > > > Novice question: How do I model a relationship that is conditional > > on an attribute value? > > > > For instance, suppose I have a Tree object: > > > > TREE > > * tree ID > > o produces fruit [yes, no] > > > > And suppose I have another object, Fruit Picker, that can have > > a relationship with a Tree object, but only if the Tree instance > > is of a type that produces fruit. > > > > I had thought that I might create subtypes of Tree: Fruit > > Tree and Non-Fruit Tree. Then the Fruit Picker would only > > have a relationship with a Fruit Tree. However, these > > subtypes would not have any attributes besides identifiers. > > > > I am inclined to just write restrictions into the relationship > > descriptions and not create subtypes. However, I would like > > for the Information Model to show these restrictions. Is there > > a correct/better way to represent this type of relationship? > > > > Rich > > > > -------------------------------------------------------------------- > > Richard K. Bowen NetEdge Systems, Inc. > > Email: Rich_Bowen@NetEdge.com http://www.netedge.com > > -------------------------------------------------------------------- Subject: Re: (SMU) process modelling Patrick Ray writes to shlaer-mellor-users: -------------------------------------------------------------------- Some competitive information. Pat At 09:41 PM 5/15/97 -0400, you wrote: >DTZ writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >I have been used SM and bridge point tool for more than two years. >I have learned what transformation and some bridges mean in action language >at least most of time. They are really those functions that PT >cannot translate and simulate. They are the things that you must do yourself. > > > > > > >lahman wrote: >> >> lahman writes to shlaer-mellor-users: >> -------------------------------------------------------------------- >> >> Respinding to Kearnan... >> >> > Looking through "Modeling the World in States," I have been unable to find an >> > example of a transformation process which would be equivalent to >> > >> > assign interest = loan * interest_rate >> > >> > It appears that a simple computation has to be hidden in the implementation of >> > the transformation process. Is this true? >> > >> > I have seen transformation processes which might have a description such as >> > "compute interest" without giving the actual method of computation. >> >> The official view is that transforms contain basic algorithmic >> computations whose implementation may vary but which, at the level of >> abstraction of an OOA, are not important to the solution description. >> The transform essentially captures the idea of a black box algorithm >> that is represented as an abstract process with defined inputs and >> outputs. >> >> A transform called "compute interest" would have inputs of "loan" and >> "interest_rate" and it would produce the "interest" output. In this >> simple example it would be a stretch to come up with an example of a >> valid alternative example of how to compute this, but one that comes to >> mind is a maintenance situation. Suppose originally "interest" was the >> total annual interest and "interest_rate" was the annual interest rate. >> If one needed to change the system so that "interest" was the monthly >> amount but "interest_rate" had to remain annual, the computation in the >> process would change but the OOA abstraction would not. >> >> The important issue is that in the OOA the data is modeled abstractly. >> Though part of the model definition is to describe the semantics of the >> data and provide a data domain, this is done primarily for the >> translation. The data model does not care much about the semantics of >> individual attributes; it is concerned with broader issues like data >> integrity and referential integrity (e.g., that the data is available >> and you access the correct instance's data for the computation). >> >> This comes down to a fundamental difference between S-M and the >> "elaboration" methodologies. An S-M OOA is a high level abstraction of >> the solution description that is concerned with large scale issues of >> communication and flow of control. It is assumed that during >> translation of a domain the details of the functionality will be >> provided by other realized modules that are accessed via bridges and >> transforms. In an OOA a transform represents some abstract but well >> defined transformation of data. The "compute interest" process bubble >> is fundamentally no different than a "sort" bubble that uses some flashy >> quicksort alrgorithm to order a set or a "get optimal flows" bubble that >> invokes a full linear programming package to solve a subset problem. >> For the problem in hand in the OOA the actual algorithms are not >> relevant; one only needs the results of the transformation (and know >> that an suitable algorithm does exist) and the implementation of the >> algorithm is left to the translation. >> >> In practice an S-M application typically has a lot of basic procedural >> code that perform operations that are not described in the OOA because >> they are not important at that level of abstraction. All the OOA does >> is provide a de facto partitioning and modularization of this procedural >> code. [Note that OOA96 filled some potential holes by restricting a >> transform to operating on formal input data rather than employing data >> store accessors.] Put another way, an OOA is not intended to describe a >> *detailed* solution. Instead it provides a consistent level of >> abstraction through the analysis that is approriate for the overall >> understanding of the problem at hand. For example, for one problem, say >> to forecast the cost of delivered petroleum, one might invoke a linear >> programming package through a transform to optimize the tanker flows of >> crude oil to determine the marginal cost of transport. Since this >> application doesn't care how the flows are optimized, only what they >> are, a transform is appropriate. However, if you are the author of that >> linear programming package you might want to describe it with an OOA >> because now the package itself is the problem at hand. >> >> Having espoused the Party Line, I have to point out that I have been >> engaged in an ongoing, offline, on-again-off-again debate with Sally and >> Neil about what can actually be buried in a transform. I argue that >> one should not place any algorithm in a transform when flow-of-control >> decisions (i.e., which events will be generated) depend upon the data >> values resulting from the transformation. My view is that if >> flow-of-control is affected in the OOA, one must expose the way one got >> there. Otherwise one cannot execute the model (i.e., simulate). Their >> view seems to be that you can always stub the transform to do the right >> thing during model execution. I contend that they would need to define >> how to do this in the methodology and that it ignores that fact that the >> algorithm is at the same level of abstraction as the flow-of-control if >> its results affect that flow-of-control. And that is about where we >> left off last. >> >> -- >> H. S. Lahman There is nothing wrong with me that >> 321 Harrison Av L51 couldn't be cured by a capful of Draino >> Boston, MA 02118-2238 >> v(617)422-3842 >> f(617)422-3100 >> lahman@atb.teradyne.com > >Pat Ray pray@ses.com SES, Inc. (512) 329-9761 Subject: Re: (SMU) SMOOA and CORBA kearnan@Summa4.COM (Gregg Kearnan) writes to shlaer-mellor-users: -------------------------------------------------------------------- > DTZ writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Ken Cook wrote: > > > H.S and I were claiming that there is nothing inherent in the method which > > leads to poor performance. We pointed to architecture as a culprit. DTZ's > > performance problems seemed to finger architecture.You are right, though, > > there can be other villians. > > > > -Ken > > No, there are a lot of thing inherent in the method and bridge point case tool > that leads to poor performance. Let me name some: > 1. You cannot pass pointer to self. Imagine this, you are in company A and > you call a friend in company B. > A: SELECT MANY people FROM B > FOR EACH person IN people > IF (person.name == "my friend") > GENERATE "hello" TO person > END IF; > END FOR; > After B receives this event, even he knows who is calling, he still need > to search A to generate an ACK back to A. > B: SELECT MANY people FROM A > FOR EACH person IN people > IF (person.name == "my friend") > GENERATE "ack" TO person > END IF; > END FOR; > > This is what we call double search. We are using BridgePoint as well, and are faced with the same problems. Not everyone is using BridgePoint, so it should be pointed out that this is not a deficiency of the method. OOA96, on pg 50, Table 9.1 lists the 'required' forms for accessors. The first paragraph in section 9.3.1 states "Note that this is the minimum set of accessor forms that must be supported by any architectural domain." If you need to generate an ACK back to the sending object instance, you should pass the identfiers of the sending object in the event. Although I am not sure it is part of the method, BridgePoint allows you to pass event handles as event parameters. You can generate the event in the receiving state machine using a statement such as: generate rcvd_evt.event_handle. Of course, you can't add any event data (as far as I know), but this method can be used for simple syncronization of state models. Someone else using BridgePoint please give me a sanity check on this!! According to the method, my (just recently acquired) understanding is that you should pass the identifiers of the sending object and then generate the return event: generate V:ack({identifiers of receiving object}; {any supplemental data}); There doesn't appear to be a concept of an 'instance handle' explicitly defined in the method. I approve of this because 'handles' make software engineers think of 'pointers,' which, to my understanding, stinks of implementation. Section 9.3.2 on pg 51 of OOA shows what sending an event would look like in an ADFD, and the section on events gives the syntax. As I stated before, my understanding is only recently acquired. I felt that the tool we were using was not reflecting the method. We are going to be hand translating our models, but we want to define the translation so that it could be automated later on when we have time. We have been following a strategy of writing the desired action language in comments just before the implementation of the desired action language using the supplied action language. The reason for using the supported action language was two-fold: can be parsed and simulated using the verifier, and can be translated using MC2010, which we purchased, but cannot use without modifying it (when we come up for air...). Another suggestion which came from PT the other day was to define a transform such as: (I'm using BridgePoint syntax here) assign = OBJECT_KEYLETTER::SelectWhere__eq({ attribute search value }); where { attribute search value } could be more than a single attribute. We could then use the supported action language in the transform description (the verifier will actually execute the description if special syntax is used to tell it that the description contains action language. The problem with this (as far as I can see) is that the tool won't allow you to pass instance handles about, so you can't return the instance handle. Is there anyone out there who knows the ins and outs of BridgePoint and could help with this problem, I would be very grateful. > > 2. You can only have one way event. No function call concept. Bridge and > transform only should be used in simple case. > > 3. There are no local or static variables. So if you need to do things in > different states, you may select again and agian. Select many relate > to is not cheap. > e.g. In state A, you need to an instance from a class, you need to search. > In state B, you need the same instance again, you need to search again. > You can establish relationship. But if you look at code to establish > relationship, they expensive also (except one to one relationship). > > 4. Everything need to go through state transition table. Think about this > way, if you generate event to yourself, you also need to go through this. > > 5. All relationship exist on both side even if you only need from one side. > > > If you manully translate most of the code yourself. Sure you can do what ever > you like. According, the beauty for SM and bridge point tool is the translation. > You force your whole team to do things consistently. But if architecture > wants to solve everything, you can imagine the performance. Architecture looks > like solution for solution. As I stated above, these limitations are from the tool. We have recently started investigating other tools to see the 'state of the art.' Other vendors do support some/all of the needed read/write accessors in their action language. I haven't seen the tools, so I'm not sure of their utility. Hope this help you, and I hope someone helps me ;-) Gregg Subject: Re: (SMU) Deleting conditional relationships in action language lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Cook... > Seems this is an either/or proposition only if the analysts are using > just state actions or just termination states for deletion. I think > most models would be better if both styles of deletion were available. > Therefore, cleaning up relationships before deleting objects would be > done either in the delete state or in the state action calling delete. But whether to deinstantiate in the calling action or in the delete state is the issue here. Doing it in the delete state makes it easier for the analyst doing maintenance but may mask an analysis error during simulation. Doing it in the calling action will not mask the error but it introduces problems for the analyst. > Code to clean up relationships is boilerplate only as much as all the > C/C++ code we've written to free memory allocations. As in that > case, life is made a lot easier if the architecture provides automatic > clean-up of the relationships upon delete. Unfortunately automatic clean-up presents some problems for error checking during simulation. As in my example, the architecture can't know when the conditional relationship should *not* be there at the time of the delete; it will simply delete it if it is there and mask the analysis error. The second problem lies in relationships that are conditional on only one side. If the instance on the conditional side is deleted w/o deleting the instance on the other side at the same time there is a referential integrity error. The first problem is unavoidable if the cleanup is automatic; it is a variation on the situation that gave rise to my original question. The second problem remains whether the cleanup is automatic or not, but if it is not automatic the analyst has a reminder to consider the issue when providing for the deinstantiation. Since the action languages have to provide the mechanisms for relationship create/delete anyway to handle doubly conditional relationships, it seems consistent to make none of it automatic. Unfortunately the largest state actions are typically the ones doing instance deletions precisely because of the amount of relationship desinstantiation required. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) SMOOA and CORBA peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- >> From: DTZ >> >> No, there are a lot of thing inherent in the method and bridge point case >tool >> that leads to poor performance. Let me name some:... >> ... According, the beauty for SM and bridge point tool is the >translation. >"Ken Cook" writes to shlaer-mellor-users: >-------------------------------------------------------------------- >I can see it from your perspective. It seems you feel your team has a >method/translator/architecture that has less performance than you need. > ... This is a good general discussion, and I think it is important to sort out the issues. As the original poster states, translation is a significant feature of all modern CASE offerings supporting Shlaer-Mellor OOA/RD. While Ken's response shows there are alternatives, I'd like to steal a minute and separate the environmental elements Ken lumped together for expediency. Let us briefly review the difference between process modeling, translation, "simulation", and the target architecture. PROCESS MODELING: the detailed specification of behavior AT THE LEVEL OF ANALYSIS for each state and service. Your process modeling should not change from "simulation" to target architecture, and details of how architectures are implemented (such as relationship formalization) should not be visible. Your tool choice dictates the subset of primitives you have to deal with. We recommend ADFDs for process modeling, based on OOA96 and our "OOA Modeling Guide". If your analysis capture environment supports action language, then each action language atom should map as directly to flows and bubble as possible. Recognize when your action language is conceptually to porous to the implementation, or if it only supports a limited subset of processes. TRANSLATON: the extraction of semantic OOA information (plus design annotation/coloring/tagging) from the CASE database, and presentation in another form, such as text, formatted documentation, or whatever. The details of how you translate (manually or with a translation engine) should not affect your process modeling. Projects typically determine they need to abandon automated translation and do manual translation if their translation environment is not complete or flexible enough. If your translation support does not meet your needs, then your tooling is flawed - NOT THE METHOD. There are translation alternatives from a variety of vendors. "SIMULATION": Dynamic Verification is the exercising of your models via an architecture that runs in your development environment, and provides sufficient visibility into the analysis-level behavior of your models to verify their validity. Your are not "simulating" - you are *really* executing them, but this term is quite often misused in this manner. It is very important to exercise the models you are going to generate the target system from, and not some other models. This means that your dynamic verification architecture needs to support the everything the target architecture does - including process modeling primitives. If you have state actions with #if SIM/#else/#endif selection, then you've got 2 sets of models (with different behavior). If you have an off-the-shelf translation and "simulation" environment that does not support all of the elements of the method you need, then you should seriously consider alternatives, which are available for most common case environments. TARGET ARCHITECTURE: This is the set of architectural code templates or specifications to guide translation, a set of base model execution mechanisms, and a manual to help the analyst use it all. It is targeted to run in the final system execution environment - on target hardware, in the customer environment, etc. An architecture itself does not include the translation engine - only the archetypes or other form of code template specification. An architecture may come bundled with a translation engine if the native translation capability of target CASE environment is deficient. SUMMARY: As practitioner, YOU are responsible for all aspects of your OOA/RD software engineering support environment. If you buy an editor because of a nice capture inferface, and later find you cannot capture the process modeling primitives required to properly express your system, or find the translation support to be inadequate for your architectural needs, or discover that your "simulation" support is too limited, the you sould seek alternatives to repair the deficiencies WHERE THEY EXIST. Your alternatives include using different process modeling conventions (such as adopting a better action language dialect), and buying better translation or dynamic verification support. Make as FEW changes as possible in your analysis to work around these kinds of defects. ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice/fax: +01 508-384-1392 | peterf@pathfindersol.com | ____________________________________________________| Subject: Re: (SMU) Relationships conditional on attribute values(?) lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Bowen... > For instance, suppose I have a Tree object: > > TREE > * tree ID > o produces fruit [yes, no] > > And suppose I have another object, Fruit Picker, that can have > a relationship with a Tree object, but only if the Tree instance > is of a type that produces fruit. > > I had thought that I might create subtypes of Tree: Fruit > Tree and Non-Fruit Tree. Then the Fruit Picker would only > have a relationship with a Fruit Tree. However, these > subtypes would not have any attributes besides identifiers. > > I am inclined to just write restrictions into the relationship > descriptions and not create subtypes. However, I would like > for the Information Model to show these restrictions. Is there > a correct/better way to represent this type of relationship? I would say that either way is acceptable. The choice depends upon what you regard as important in the model context. In particular, how important is the relationship itself? If it is crucial to the abstraction then you probably want to go with the subtype solution. This might be the case in a resource allocation application where the assignment of Fruit Pickers to particular trees was quite important to making sure all the trees got picked. OTOH, if the relationship is not central to the domain subject matter, then it might be better to simply qualify the relationship description rather than clutter the IM with subtypes. This might be the case in an accounting application where one was only interested in the count of Trees picked by each Fruit Picker. Another way to look at this is to ask if an impartial subject matter expert would reasonably understand the abstraction if you didn't use the subtypes. If that domain expert is a straw boss for a migrant fruit picking crew, it will probably be pretty intuitive that Pine Trees are not included in the relationships with a Fruit Picker. In fact, if the relationship label is "picks fruit from" this might be pretty intuitive for even a lawyer. If the restrictions on the relationship are more obscure and can't be made self-explanatory through labelling or naming conventions, then you want to clarify by using the subtypes because they are up-front explicit. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: re:fw:Re: (SMU) SMOOA and CORBA "Claire Cote" writes to shlaer-mellor-users: -------------------------------------------------------------------- > kearnan@Summa4.COM (Gregg Kearnan) writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > In an off-line conversation with HS Lahman, we discussed some of the > inefficiencies of the action language our tool supports. > [HS, please feel free to blast me if I say something incorrect!;)] > > Our action language forces us to do a few nasty (IMHO) things: > > 1) If you find an object instance in one state, you have to re-search the > set again if you need that same instance in another state. If the two states requiring a handle to the same instance belong to the same instance state model, then one way to avoid searching the same instance over and over again is to define a relationship between the "searched" instance and the "searching" instance. If an instance deals with the same other instance in different states, then there may be a relationship between the two. If the two states belong to two different state models, then I see two alternatives: 1) Use subtype migration: If an instance is needed, during a certain time interval, by different object instances, then there may be something special enough about that instance that it could be considered as a temporarily different object. 2) Use an artificial relationship to "remember" that instance. This solution is not elegant but it does the job. Depending on the domain analysis those solutions may or may not make sense. If someone has other alternatives, I would be greatly interested in knowing what they are. > > 2) We are not allowed to select sets of object instances based on a criteria: > [select ... where == ] > or [select ... related by where ... > we either select all instances in a set or relationship, select any (with > no idea which one you will get), or select one (if the relationship is > singular on the side you are trying to select > > 3) Iteration over a set of instances must procede over *all* instances - there > is no concept of a break from the loop The work-around that we use for the lack of "break" statement is to define a bridge "break()" to Software Architecture that translates directly into a break statement in our C++ generated code. The search is still linear but, at least, it reduces the average search time by a factor of 2. Claire Cote Nortel Technologies Tel.: (514) 765-7794 FAX : (514) 761-8509 clairec@nortel.ca Subject: Re: (SMU) Relationships conditional on attribute values(?) "Ken Cook" writes to shlaer-mellor-users: -------------------------------------------------------------------- Rich, The relationship to Fruit Picker was a good reason to have a Fruit Tree subtype, and still is. In your expanded example, you don't say whether there are any special relationships, behaviors, or attributes specific to Good Shade Trees or to Bad Shade Trees. Assuming there is nothing special about Good or Bad Shade Trees that you would need an object for, then I would write Fruit Tree IS A Tree Non-Fruit Tree IS A Tree Fruit Tree IS HARVESTED BY Fruit Picker Tree (Tree_ID, good_shade_tree) identifier: Tree_ID where good_shade_tree simply captures a characteristic of the tree. If, however, Good or Bad Shade trees have all kinds of interesting special characteristics/relationships/behavior, then you have this option Tree IS A Good Shade Tree or a Bad Shade Tree Tree IS A Fruit Tree or a Non-Fruit Tree Two different IS A structures! Looks like this: -------|- O -|----------- | | | | 0 0 0 0 This structure is the clearest illustration of how OOA subtyping is not identical to C++ inheritance. In this structure, we are partitioning the trees by two orthogonal set criteria: Fruited and Shading. A tree instance is related to a Fruit or Non-Fruit instance *and* it is related to a Good or Bad Shade instance. In C++, you can't do this with inheritance. Because of this and other characteristics of SMOOA IS A, many SM-compliant architectures implement subtypes objects as a separate class from the supertype object's class. -Ken ---------- > From: Rich Bowen > To: shlaer-mellor-users@projtech.com > Subject: Re: (SMU) Relationships conditional on attribute values(?) > Date: Friday, May 16, 1997 5:45 AM > > Rich Bowen writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Ken, > > Thanks for the help. > > Now let me complicate the example a little. Suppose I add > another differentiating attribute to the Tree object: > > TREE > * tree ID > o produces fruit [yes, no] > --> o makes a good shade tree [yes, no] > > If I use subtypes to represent the different types of trees > then the number of subtypes increases exponentially: > > Fruit & Shade Tree > Fruit & Non-Shade Tree > Non-Fruit & Shade Tree > Non-Fruit & Non-Shade Tree > > It seems like this approach becomes intractable if there > are very many attributes that dictate whether or not > relationships can exist. It also causes me to go back to > the Fruit Picker object and modify it so that it can now > have relationships with two subtypes of Tree instead of > just one. Wouldn't it be simpler just to put some > conditional logic in the objects that are interested in > Trees with particular attribute values and use a single > Tree object? > > Rich > > Ken Cook wrote: > > > > "Ken Cook" writes to shlaer-mellor-users: > > -------------------------------------------------------------------- > > > > Use your subtypes, Fruit Tree and Non-fruit tree. > > Even if your subtypes have only identifiers as attributes, they > > have something else that is equally as important as identifiers - > > a relationships. > > > > The "more than a list" object test taught in PT class and in S/M > > first book needs some qualification: IMO, if an object has important state > > model behavior, or participates in an important relationship, it > > is ok if it has no attributes other than an identifier. In this case, it > > truly is more than a list. > > > > As your trees grow, I'm sure you will find some interesting attributes > > (How about "average yearly yield in bushels" for the Fruit Tree?). > > > > -Ken > > ---------- > > > From: Rich Bowen > > > To: shlaer-mellor-users@projtech.com > > > Subject: (SMU) Relationships conditional on attribute values(?) > > > Date: Thursday, May 15, 1997 12:35 PM > > > > > > Rich Bowen writes to shlaer-mellor-users: > > > -------------------------------------------------------------------- > > > > > > Novice question: How do I model a relationship that is conditional > > > on an attribute value? > > > > > > For instance, suppose I have a Tree object: > > > > > > TREE > > > * tree ID > > > o produces fruit [yes, no] > > > > > > And suppose I have another object, Fruit Picker, that can have > > > a relationship with a Tree object, but only if the Tree instance > > > is of a type that produces fruit. > > > > > > I had thought that I might create subtypes of Tree: Fruit > > > Tree and Non-Fruit Tree. Then the Fruit Picker would only > > > have a relationship with a Fruit Tree. However, these > > > subtypes would not have any attributes besides identifiers. > > > > > > I am inclined to just write restrictions into the relationship > > > descriptions and not create subtypes. However, I would like > > > for the Information Model to show these restrictions. Is there > > > a correct/better way to represent this type of relationship? > > > > > > Rich > > > > > > -------------------------------------------------------------------- > > > Richard K. Bowen NetEdge Systems, Inc. > > > Email: Rich_Bowen@NetEdge.com http://www.netedge.com > > > -------------------------------------------------------------------- Subject: Re: (SMU) Relationships conditional on attribute values(?) "Ken Cook" writes to shlaer-mellor-users: -------------------------------------------------------------------- > From: lahman > To: shlaer-mellor-users@projtech.com > Another way to look at this is to ask if an impartial subject matter > expert would reasonably understand the abstraction if you didn't use the > subtypes. If that domain expert is a straw boss for a migrant fruit > picking crew, it will probably be pretty intuitive that Pine Trees are > not included in the relationships with a Fruit Picker. In fact, if the > relationship label is "picks fruit from" this might be pretty intuitive > for even a lawyer. Unless your are harvesting pine nuts. :-) Anyway, you make a good point. In most models, there is usually a point where you say: "this structure is complex enough. We'll just move this logic into state actions (or pre-existing instance populator). So only Trees bearing fruit would get relationships with Fruit Pickers. Subject: Re: (SMU) Deleting conditional relationships in action language shlaer-mellor-users@projtech.com writes to shlaer-mellor-users: -------------------------------------------------------------------- > > This is a MIME Encoded message. If you are reading this text, > then your mail reader does not support the MIME (Multipurpose > Internet Mail Extensions) standard. To take full advantage of > the features of this message, you need to upgrade your mailer to > a MIME V1.0 compliant package. Some parts of this message may > be in human readable form. > > MIME Decoding Utilities > ----------------------- > To make use of this encoded message, you can decode it using > a MIME Decoding utility. The following are some freely available > MIME decoding utilities: > > UNIX Users > ----------- > Metamail : ftp://ftp.bellcore.com/pub/nsb/mm2.7.tar.Z > This is the Metamail source code distribution. > Mpack : ftp://ftp.andrew.cmu.edu/pub/mpack/mpack-1.5-src.tar.Z > Source code for all platforms. > MACINTOSH Users > --------------- > Mpack : ftp://ftp.andrew.cmu.edu/pub/mpack/mpack-1.5-mac.hqx > Contains the Macintosh binaries > PC Users > --------- > Metamail : ftp://ftp.bellcore.com/pub/nsb/mm2.7.dos.zip > This is the MS-DOS binaries > > Mpack : ftp://ftp.andrew.cmu.edu/pub/mpack/mpack15d.zip > This contains the MS-DOS binaries > MIME-Aware Mail User Agents > --------------------------- > Note that the following Mail User Agents support MIME and hence if > one of these are used the message will be automatically decoded > be in a readable state: > Elm Version 2.4 (UNIX) > ftp://ftp.uu.net/networking/mail/elm > Eudora 1.4.4 (Macintosh, MS-Windows) > ftp://ftp.qualcomm.com/quest/eudora/windows/1.4/eudor144.exe > ftp://ftp.qualcomm.com/quest/eudora/mac/1.4/eudora144.hqx > Pegasus mail (MS-DOS, MS-Windows, Macintosh) > ftp://risc.ua.edu/pub/network/pegasus/* > Pine (UNIX) > ftp://ftp.cac.washington.edu/pine/pine.tar.Z > --ctXJ6sJv2LPmrbcD4WDkDTZHb3KIZWvL Content-type: text/plain; charset="us-ascii" peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 09:29 AM 5/15/97 -0400, shlaer-mellor-users@projtech.com wrote: >lahman writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >It is time to vote on philosophical issues again! >... >So how do people handle this? Let me give you the ADFD process modeling perspective. Basically, the invocation of a single Delete accessor is all that is required for proper relationship "unformalization" and instance disposal. Create, Write, and Delete accessors all have the potential of modifying an instance's relationship participation. (Just to remind folks - we don't require a separate "unlink" step). Of course, all of this is done via a single "bubble". We believe significant, pervasive benefits are realized whenever we can eliminate an opportunity for an analyst to specify something incorrectly. ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice/fax: +01 508-384-1392 | peterf@pathfindersol.com | ____________________________________________________| --ctXJ6sJv2LPmrbcD4WDkDTZHb3KIZWvL Content-type: text/plain; charset="us-ascii" Received: from bcarsbf5.localhost (actually bcarsbf5.ott.bnr.ca) by bcarsfbb.ott.bnr.ca; Thu, 15 May 1997 22:39:00 -0400 Received: from projtech.com (actually projtech.projtech.com) by bcarsbf5.localhost; Thu, 15 May 1997 22:38:34 -0400 Received: by projtech.com (4.1/PT-2.55S) id AA01548; Thu, 15 May 97 19:20:23 PDT Date: Thu, 15 May 1997 22:23:35 -0400 (EDT) Message-Id: <199705160223.WAA13054@uhura> X-Sender: peterf@mail.ici.net X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: lahman@ATB.Teradyne.COM, "shlaer-mellor-users@projtech.com" From: peterf@pathfindersol.com (Peter J. Fontana) Subject: Re: (SMU) Deleting conditional relationships in action language Sender: owner-shlaer-mellor-users@projtech.com Precedence: bulk Reply-To: shlaer-mellor-users@projtech.com Errors-To: owner-shlaer-mellor-users@projtech.com --ctXJ6sJv2LPmrbcD4WDkDTZHb3KIZWvL-- Subject: Re: (SMU) SMOOA and CORBA peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 10:08 AM 5/8/97 -0700, shlaer-mellor-users@projtech.com wrote: >"Ken Cook" writes to shlaer-mellor-users: >-------------------------------------------------------------------- > ...At some point, the number of objects, the number of domains, >or the >number of model changes grows large enough to make manual translation more >costly than writing an optimized translator. > >I would argue that the key elements of an optimized translator to get right >are >1) how events are passed and queued >2) how relationships are stored and traversed >3) how objects are instantiated, stored, and how their extents are >gathered. In my last posting to this thread, I tossed out a definition for a translator, but I'm not sure I understand what an "optimized" translator is. Have you not separated archetypes from the translation engine? I believe we all recognize and applaud PT's efforts to keep this forum commercial free, and would like things to continue in this manner. In this context of this thread, I believe some specific context is needed from Ken to help us understand what he is discretely hinting at. In that light Ken, plase give us a brief, "commercial-free" overview of how your products address the original problem brought up in this thread. Thanks. ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice/fax: +01 508-384-1392 | peterf@pathfindersol.com | ____________________________________________________| Subject: Re: (SMU) SMOOA and CORBA lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Cote... > I don't agree that performance is an architectural issue ONLY. > The role of the architecture is to map algorithms in the > analysis domains into implementation. Each of those algorithms > belongs to some order of complexity. The architecture can not > produce a log-n implementation given a n-cube algorithm. > > Of course, the architecture also has its own algorithms > (just like any other domain). The importance of their optimization > is crucial because they are intensively used. > > At the beginning of the project, we were faced with serious performance problems. > Performance improvements were obtained by modifications brought to > the architectural classes, the translation rules, and the analysis. > The benefits obtained by modifications to non-architectural algorithms > were not negligible; they were as high as the ones obtained by > tuning the architecture. I agree with you that one can do a bad model that is analogous to choosing a bubble sort over a quicksort; it might have superfluous objects and state machines together with inefficient partitioning of functionality and overly detailed abstractions. However, I don't see an S-M OOA as a vehicle for describing algorithms. In this context I would argue it is more of a vehicle for modularizing algorithms. Flow of control in an OOA is pretty high level and is oriented around specific communications issues. The level of abstraction for algorithms where performance becomes an issue is usually buried in transforms. I have yet to see a convincing case where performance could have been improved by changing an otherwise reasonable OOA. I have seen cases where an OOA needed to be changed to enhance performance, but this was because the OOA itself was improperly modeled or did not have the correct level of abstraction. Perhaps a couple of examples might clarify why I feel this way... On our first pilot project we were modeling a domain for new hardware where the performance of the hardware had not been determined. We had two nested iterations that extended across state machines. We did not know which of two operations would be faster in the hardware, so we did not know which iteration should be the outer one. This seemed to be a clear case where performance considerations in the hardware would affect the OOA and we believed this for quite awhile. We built the OOA by simply guessing at the nesting. Eventually someone noted that the iterations could be defined generically in the OOA by simply having an IF...ELSE statement in the action at the start and end of the loops that checked a specification object for which way was better. The IF...ELSE then generated the appropriate event. Thus it was possible to switch the nesting of the loops dynamically based upon the value in the specification object and the OOA did not change. We should have thought of this up front when we *knew* it could go either way -- the OOA could and should have reflected the uncertainty. That is, the OOA was modeled incorrectly by including an unnecesary guess about an implementation issue. My next example relates to levels of abstraction. Recently we had a domain that was very large and complex with fifty-odd objects and a couple of dozen state machines. Flurries of events were running around doing little else than shifting from one wait state to another. The people working on the domain were frustrated because they didn't have a handle on what was happening and it was beginning to look like it would be a performance pig because of the state machine thrashing. In this case the problem was model hacking because the domain was being analyzed at a level of abstraction that was too low. Conceptually the domain was little more than a translator bridge that moved a pile of data in one format from one doamin into a pile of data in another format for another domain. It only existed because the order of processing of the data had to effectively be reversed so we needed temporary persistence over a sequence of service requests and this could not be done in a simple bridge. We raised the level of abstraction by aggregating a lot of data (objects) into attributes that were simply handles and processed them in transforms that were realized code that understood the data format for the handles. This reduced the domain to about twenty objects and only one of these was active. All of the algorithmic code for translating formats was still there, but it was buried in transform processes and bridges because it did not affect flow of control at the higher level of abstraction. Basically the domain became just a smart bridge, which was the reason it was defined originally. A byproduct was that the implementation of the transforms was independent of the OOA and the performance issues were relegated to the realized transforms. My last example is a more traditional, translation-can-do-anything, example. We had an active object with thousands of instances and several other objects had 1:M or M:M relationships with it. This looked like a classic performance disaster for the event manager to find the right instances and for navigating the relationships since we needed to find specific instances rather than process sets. We could have revised the IM, but it seemed an elegant representation of the data. So we decided to see what we could do in translation to tune performance. When we got through the implementation did not look a whole lot like the original OOA, but there weren't any performance problems because all the objects were arrays of structs, new index objects were introduced, state actions were static functions with the instance data index passed as a parameter, and all the searches were replaced with table lookups or eliminated altogether. The moral being that just because the OOA is littered with sets and abstract 1:M and M:M relationships it doesn't mean the implementation has to be done with myriads of instances, each with a linked list to related instances. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) SMOOA and CORBA "Ken Cook" writes to shlaer-mellor-users: -------------------------------------------------------------------- > peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: > -------------------------------------------------------------------- > >"Ken Cook" writes to shlaer-mellor-users: > >-------------------------------------------------------------------- > > ...At some point, the number of objects, the number of domains, > >or the > >number of model changes grows large enough to make manual translation more > >costly than writing an optimized translator. > > > >I would argue that the key elements of an optimized translator to get right > >are > >1) how events are passed and queued > >2) how relationships are stored and traversed > >3) how objects are instantiated, stored, and how their extents are > >gathered. > > > In my last posting to this thread, I tossed out a definition for a > translator, but I'm not sure I understand what an "optimized" translator is. > Have you not separated archetypes from the translation engine? > > I believe we all recognize and applaud PT's efforts to keep this forum > commercial free, and would like things to continue in this manner. In this > context of this thread, I believe some specific context is needed from Ken > to help us understand what he is discretely hinting at. In that light Ken, > plase give us a brief, "commercial-free" overview of how your products > address the original problem brought up in this thread. Thanks. I especially want to keep the forum commercial free. Your posting with the definitions was very good. I use those terms too loosely because many people I talk to don't yet know the difference between an architecture, an archtype, and a translator. Your posting, I think, raised awareness. You are right: it is the architecture and the archtypes that have all the optimization. Our translation engine is out-of-the-box BridgePoint. Summary of our strategy for a high performance architecture: Shared memory and user tuneable hash tables are used to store objects, relationships, events, and event data. We manage the shared memory space; malloc is never used. Native threads provide multiplatform scalability (NT and Solaris). Exceptions and highly optimized assertions are used instead of slow error checking. Wherever possible, decisions are pushed out of runtime and into codegen time. Events to self are optimized. Like optimized 3GL compilers, the model compiler does multiple passes to gather information for optimization. Performance regression tests are required for any changes to the architecture. The team that designed this really knows s/w architectures - and they didn't have any prior knowledge of SMOOA! For the infamous case of the double search for an instance handle, as I said in another posting, we do allow the modeler to pass an instance handle as an event parameter. -Ken Subject: (SMU) Linking/Unlinking Relationships - Why? David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: -------------------------------------------------------------------- I have noticed many threads which assume concepts of linking and unlinking relationships. Where did these concepts arise? An information model uses referential attributes to formalise relationships. When the value of a (possibly compound) referential attribute matches the value of the identifier of an instance of the defining object then the relationship is formed. The difference between conditional and unconditional relationships is whether the referential attributes are allowed to have (on a non-transitory basis) a value that does not match than of a defining instance. I understand why linking and unlinking might be useful for naive translation engines, but can anyone give a justification for the link/unlink concepts that does not make reference to architectural issues? Dave. p.s. Our CASE tool does not support link/unlink. It is quite capable of simulating an OOA model. (and it uses action-language, not ADFDs). -- David P. Whipp. Not speaking for: ------------------------------------------------------- G.E.C. Plessey Due to transcription and transmission errors, the views Semiconductors expressed here may not reflect even my own opinions! Subject: Re: (SMU) Linking/Unlinking Relationships - Why? lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Whipp... > I have noticed many threads which assume concepts of linking and > unlinking relationships. Where did these concepts arise? This whole thing came up because of an issue I had about *when* conditional relationships are deinstantiated. Since action languages usually have a special construct for this it was easier and clearer for me to couch the issue in those terms. However, the issue is the same even if one simply assigns to the referential attribute or uses a link construct. > I understand why linking and unlinking might be useful for naive > translation engines, but can anyone give a justification for > the link/unlink concepts that does not make reference to > architectural issues? I think advantage is that it allows a simpler IM by using the link/unlink as an alternative to assigning INACTIVE to identifiers. Consider the following: R3 +-------------------------------+ | | v R1 C R2 C v A <------------> B <----------> C *ID1(R3) *IDb *ID1 *IDa +ID1(R1,R2) +IDa(R1) How do I remove the R2 relationship? I could add a separate relational atttribute to B for the R2 relatiosnhip using a different name, but this would be, at best, misleading in the model and, at worst, incorrect without further clarification. To clarify that the identifiers were really the same I would have to add R2=R1+R3, which is also misleading because it *suggests* that R2 is there whenever R1 and R3 are. While I can do various things in the IM to remove the ambiguity, they all tend to clutter and be unnatural. If the action language contains a special construct to do the link/unlink, then you can do the IM as above which seems more natural to me. OTOH, some purist twit might argue that because R2 is conditional and because one has to be able to deinstantiate it by assigning INACTIVE, the IM is *required* to have separate identifiers for the two relationships anyway. (He said, daring the Defenders of the Relational Model to venture forth and be identified.) I would counter that the price of this is the ugliness of the INACTIVE assignment and that the link/unlink approach is actually more implementation independent. (He said, deftly moving the debate from a technical realm to an aesthetic one.) -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Linking/Unlinking Relationships - Why? David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: -------------------------------------------------------------------- > lahman wrote: > Consider the following: > > R3 > +-------------------------------+ > | | > v R1 C R2 C v > A <------------> B <----------> C > *ID1(R3) *IDb *ID1 > *IDa +ID1(R1,R2) > +IDa(R1) I have considered it - there is no point in going into your resulting arguments because this IM is inconsistant. R2 cannot be biconditional, given that R1 and R3 are unconditional and given your formalisations. My reading of this IM is: R3 is 1:M (each instance of C can have many related A because A has a compound identifier) => Every instance of C MUST have a 1 or more instances of A. Given that R1 is 1:1 (unconditional) you MUST also have an instance of B. We don't know the value of IDb, but we do know the value of ID1 and IDa. R1 is unconditional, so these formalising attributes MUST be a secondary identifier. Now, we know that the value of ID1 of this instance of B MUST be the same as the value of ID1 in A and therefore of ID1 in C (R1 and R3 are unconditional) Therefore R2 MUST BE unconditional (in both directions), given these formalisations. (In fact, it must be 1:M) There are two ways to allow a conditional R2: either add additional attributes to either B or C (which then formalise R2) or add an associative object. Which is correct would be idientified by looking at your subject matter. If R2 is really conditional and R1/R3 are really unconditional then you've missed some attributes/objects. Dave. > > -- > H. S. Lahman There is nothing wrong with me that > 321 Harrison Av L51 couldn't be cured by a capful of Draino > Boston, MA 02118-2238 > v(617)422-3842 > f(617)422-3100 > lahman@atb.teradyne.com > Subject: Re: (SMU) Linking/Unlinking Relationships - Why? hogan@mmc1700.lmtas.lmco.com (Bary D. Hogan) writes to shlaer-mellor-users: -------------------------------------------------------------------- > > David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > I have noticed many threads which assume concepts of linking and > unlinking relationships. Where did these concepts arise? > > An information model uses referential attributes to formalise > relationships. When the value of a (possibly compound) referential > attribute matches the value of the identifier of an instance of > the defining object then the relationship is formed. The difference > between conditional and unconditional relationships is whether the > referential attributes are allowed to have (on a non-transitory > basis) a value that does not match than of a defining instance. > > I understand why linking and unlinking might be useful for naive > translation engines, but can anyone give a justification for > the link/unlink concepts that does not make reference to > architectural issues? > > > Dave. > > > p.s. Our CASE tool does not support link/unlink. It is quite capable > of simulating an OOA model. (and it uses action-language, not ADFDs). > I agree. In the analysis proper, the relationships are only formalized by the referential attributes. I don't have a problem with tools that have an additional concept of linking and unlinking an instance of a relationship, but that should be done at the same time that the referential attributes are set, and the two should be considered inseparable (as if they were done in a single process bubble). Any potential problems that exist in an analysis using tools that have the link/unlink concept should be the same ones that potentially exist without the link/unlink. Bary Hogan LMTAS Subject: Re: (SMU) SMOOA and CORBA Allen Theobald writes to shlaer-mellor-users: -------------------------------------------------------------------- Ken Cook wrote: [snip] > Your posting with the definitions was very good. I use those terms > too loosely because many people I talk to don't yet know the difference > between an architecture, an archtype, and a translator. Your posting, > I think, raised awareness. [snip] I bite. I don't know what the difference is between an architecture, an archtype, and a translator. I read the related postings and still don't. Please don't flame me, just enlighten me. Kind Regards, Allen Subject: Re: (SMU) SMOOA and CORBA "Ralph L. Hibbs" writes to shlaer-mellor-users: -------------------------------------------------------------------- At 01:34 PM 5/19/97 +0000, you wrote: >Allen Theobald writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >Ken Cook wrote: >[snip] >> Your posting with the definitions was very good. I use those terms >> too loosely because many people I talk to don't yet know the difference >> between an architecture, an archtype, and a translator. Your posting, >> I think, raised awareness. >[snip] > >I bite. I don't know what the difference is between an architecture, >an archtype, and a translator. I read the related postings and still >don't. > Software Architecture: A system wide statement of design. This is a collection of "rules" or "design patterns" that describe a particular design implementation. You can think of this as the specification for the design, as it is usually captured as a written specification. In addition to having the "rules" or "design patterns" captured in text, the software architecture should have descriptions of things like how errors are handled, implementation technologies assumed, and performance characteristics. Archetype: This is a specific codified description of a design pattern, which is part of a software architecture. Translator: This is a general purpose "engine" or automation tool, that applies the design patterns (or archetypes) to the OOA models. This "engine" handles all the parsing of the OOA models, so the software architect can focus on the system design. Model Compiler: This is a collection of archetypes or design patterns that works with a translator to form a fully automated software architecture. Ralph --------------------------- Shlaer-Mellor Method --------------------------- Ralph Hibbs Tel: (510) 567-0255 ext. 629 Director of Marketing Fax: (510) 567-0250 Project Technology, Inc. email: rlh@projtech.com 10940 Bigge Street URL: http://www.projtech.com San Leandro, CA 94577 ------- Improving the Productivity of Real-Time Software Development ------- Subject: Re: (SMU) Linking/Unlinking Relationships - Why? David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: -------------------------------------------------------------------- > lahman wrote: > Responding to Whipp... > > > I have noticed many threads which assume concepts of linking and > > unlinking relationships. Where did these concepts arise? > > This whole thing came up because of an issue I had about *when* > conditional relationships are deinstantiated. Since action languages > usually have a special construct for this it was easier and clearer for > me to couch the issue in those terms. However, the issue is the same > even if one simply assigns to the referential attribute or uses a link > construct. Fine, so you seem here to be saying that the unlink operation is synonymous with assigning a value to referential attributes that does not identify a related instance. Unfortunately, there may be many possible "inactive" values that can be assigned to a referential attribute that do not refer to a related instance. If the range of the attribute-domain is R, and the number of instances of related object is N, then there are (R-N) possible values that could be assigned to the referential attribute to unlink it - Which one should "unlink" use? The answer is important because in instance might later be created whose identifier does match the value you used. > > I understand why linking and unlinking might be useful for naive > > translation engines, but can anyone give a justification for > > the link/unlink concepts that does not make reference to > > architectural issues? > > I think advantage is that it allows a simpler IM by using the > link/unlink as an alternative to assigning INACTIVE to identifiers. This is not so good. Here, you seem to be saying that unlink and assignment of inactive value are not synonymous. The only conclusion I can draw from your suggestion that it simplifies the IM is that you are not using referential attributes to formalise the relationship. Instead, you are using hidden variables within the architecture. Now, I do not have a problem with hidden variables - OOA96 defined "current-state" to be a hidden variable. However, you must consider the implications of this radical change in the method. If refential attributes no longer formalise relationships, then it follows that they are not a necessary part of a model. They would have to be considered as optional. In fact, they are no longer referential - they are just mathematically dependent attributes that have a unity transform from their defining attributes. This begins to seem rather redundant. We soon reach the conclusion that referential attributes serve no useful purpose and clutter up the IM. The obvious conclusion is that they should be removed from the method. Is this the conclusion you intended? Dave. -- David P. Whipp. Not speaking for: ------------------------------------------------------- G.E.C. Plessey Due to transcription and transmission errors, the views Semiconductors expressed here may not reflect even my own opinions! Subject: (SMU) Modelling wormholes/syncronous services in BridgePoint Paul Coene writes to shlaer-mellor-users: -------------------------------------------------------------------- Hi Debbie (and all), This is Paul Coene from Questra Consulting. Don't let the e-mail name throw you, its just a lame nickname from a set of fantasy books I read in college. I've been modelling this sample project of ours, and have determined many places for wormhole/syncronous service combinations (I think). We have an application domain, and a User Interface domain. The User Interface domain is the abstract level of widgets, buttons, etc. This will be realized at some point by Motif, or some other implemented layer. We are utilizing the bridge to contain the interface to the application domain. For the purpose of this question, lets say the application domain has an object called foo. At any given time there can be n instance of this object. This object has an attribute called type. Now, at some point, the bridge between the UI and the application needs to display a screen that lists all the different types of foo. This list can be obtained from a syncronous service in the application domain, that does a find across foo and finds all the unique types. Ok, now the question. Where is the action for this syncronous service modelled in BridgePoint? The bridge editor seems to let me key in a name for the service, parameters, and a return value. I'd like more. I'd like to be able to use the process language, or some other method to lay out the information and do some sort of verification. Is there somewhere? I've considered creating a new object in the application (say UI_Counterpart) that has a state for each syncronous service. Then, when the bridge wants this service, it would send an event to this object to get it to change state, execute my action and the return back. This seems like it would work, but it makes the IM ugly, and seems like a hack. The state model paradigm doesn't seem to fit. It seems like it would be better to have floating DFDs somewhere to model the syncronous services? I think Kent is out, but if you don't have the answers to this, is he checking e-mail? I copied the mailing list in case folks out there have their own techniques. This could be considered a repost of a previous question, but I think it is better stated, and I am more equipped to handle the answers now ;) -- Drool WWW: http://www.caiwireless.net/~drool ARPA: drool@caiwireless.net Cindy Crawford _is_ God drool@questra.com Subject: Re: (SMU) SMOOA and CORBA lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Theobald... > I bite. I don't know what the difference is between an architecture, > an archtype, and a translator. I read the related postings and still > don't. Just a couple of qualifications for Hibbs' answers An Architecture is often also thought of as including reusable infrastructure code. A typical example would be the event queue manager. You code this once and reuse it in all asynchronous applications. An Archetype is not necessarily required. This is one convenient approach to building an architecture, but unlike the Translation Rules it is not essential. There are Translator tools available that simulate and generate code without using archetypes. As far as I know, all of the current Model Compilers are actually Translators that add instrumentation to the generated code for purposes of simulation. Since all but Peter Fontana's use action languages the boundary between the OOA and the implementation tends to get blurred. That is, since the simulator "sees" inside transforms, etc. it becomes less clear whether you are simulating the models or the implementation. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: [Fwd: Re: (SMU) Linking/Unlinking Relationships - Why?] lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- This is a multi-part message in MIME format. --------------617E7F297BD6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com --------------617E7F297BD6 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <3382F761.4A09@atb.teradyne.com> Date: Wed, 21 May 1997 09:23:45 -0400 From: lahman Reply-To: lahman@atb.teradyne.com Organization: Teradyne/ATB X-Mailer: Mozilla 3.0 (WinNT; U) MIME-Version: 1.0 To: Dave Whipp Subject: Re: (SMU) Linking/Unlinking Relationships - Why? References: <199705191509.QAA13844@psupw46.roborough.gpsemi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dave Whipp wrote: > > > lahman wrote: > > Consider the following: > > > > R3 > > +-------------------------------+ > > | | > > v R1 C R2 C v > > A <------------> B <----------> C > > *ID1(R3) *IDb *ID1 > > *IDa +ID1(R1,R2) > > +IDa(R1) > > I have considered it - there is no point in going into your resulting > arguments because this IM is inconsistant. > > R2 cannot be biconditional, given that R1 and R3 are unconditional > and given your formalisations. I'm afraid I do not follow this. The R2 relationship is independent of R1 and R3. As an example, replace C with Test, A with Diagnosis, and B with Message. In this case R2 could represent a relationship for the end user optionally fetching the diagnostic message that the user associates with the Test. > My reading of this IM is: > > R3 is 1:M (each instance of C can have many related A because A has > a compound identifier) We typically use compound identifiers to make loop validation easier. In this case it is routine to have 1:1 relationships like Instrument <-------------> Clock *INST_ID *INST_ID *CLK_ID If a given Instrument might be hooked up to, say, either a User Clock or a System Clock, then one needs CLK_ID, which will be a different identifier than INST_ID. If there are two Instruments in the system, each with their own clock, then it is conventient to distinguish one clock from another by inheriting the INST_ID as part of a compound identifier. Thus the compound identifier implies nothing about the cardinality of the relationship. However, I agree it would be more relevant for R1 to be 1:M::A:B and R3 to be 1:M::C:A. The example would have been clearer if I had done this. In particular, the diagnostic message example above would be more realistic. > => Every instance of C MUST have a 1 or more instances of A. Given that > R1 is 1:1 (unconditional) you MUST also have an instance of B. We > don't know the value of IDb, but we do know the value of ID1 and IDa. > R1 is unconditional, so these formalising attributes MUST be a > secondary identifier. I also do not follow the conclusion. Ignoring the Message example above and dealing with the more general case, suppose B and C exist throughout the application scope while A is created and deleted many times, each with a different IDa. So long as R1 and R3 are properly instantiated to preserve referential integrity, then IDa in B is changing while IDb is not. Therefore, in general, IDa *cannot* be a secondary identifier since I believe the identifier for an instance must be constant throughout its life (i.e., if you want to change an identifier you have to delete and re-create it). > Now, we know that the value of ID1 of this instance of B MUST be the same > as the value of ID1 in A and therefore of ID1 in C (R1 and R3 are > unconditional) Therefore R2 MUST BE unconditional (in both directions), > given these formalisations. (In fact, it must be 1:M) Even if I granted all of the above, I still would not follow either of these conclusions. There is no reason why R2 has to relate a given instance of B to the same instance of C that A is related to in general. The conditionality and cardinality of the relationships have nothing to do with this. As it happens, the model *says* they must be the same because the same relational identifier in B is used to define both relationships, but this has nothing to do with the cardinality or conditionality -- it was an explicit statement in my model. This was one of the points I made in the original message. As soon as one uses a separate relational identifier for ID1 in B, then one loses the fact that one *wants* them to be the same. This requires the clarification of a composed relationship. R3 +---------------------------------------+ | | v | v R1 C R2 C v A <-------------->> B <---------------> C *ID1(R3) *IDb * ID1 *IDa +ID1A(R1) +ID1C(R2) +IDa(R1) This is a legal model but it allows a different instance of C to be related to B via the R2 path than by the R1/R3 path. Therefore one needs R2=R1+R3 to capture that the paths are supposed to the lead to the same instance of C. I also see no reason why the R2 relationship can't be doubly conditional. As it happens this example was taken from a real world case where the R2 relationship represents a special selection that is crucial to the analysis but the selection only exists under certain circumstances (i.e., during processing for a single input bridge request). -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com --------------617E7F297BD6-- Subject: [Fwd: Re: (SMU) Linking/Unlinking Relationships - Why?] lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- This is a multi-part message in MIME format. --------------33D241574A8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com --------------33D241574A8 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <3382FB75.67BE@atb.teradyne.com> Date: Wed, 21 May 1997 09:41:09 -0400 From: lahman Reply-To: lahman@atb.teradyne.com Organization: Teradyne/ATB X-Mailer: Mozilla 3.0 (WinNT; U) MIME-Version: 1.0 To: Dave Whipp Subject: Re: (SMU) Linking/Unlinking Relationships - Why? References: <199705201014.LAA14022@psupw46.roborough.gpsemi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Responding to Whipp... > Fine, so you seem here to be saying that the unlink operation is synonymous > with assigning a value to referential attributes that does not identify > a related instance. Yes, unlink is equivalent to writing NOT PARTICPATING to the relational identifier. The tools do some other things, though, that *are* architectural in nature. > Unfortunately, there may be many possible "inactive" values that can be > assigned to a referential attribute that do not refer to a related instance. > If the range of the attribute-domain is R, and the number of instances of > related object is N, then there are (R-N) possible values that could be > assigned to the referential attribute to unlink it - Which one should > "unlink" use? The answer is important because in instance might later > be created whose identifier does match the value you used. It was news to me that there was even one when Neil pointed it out awhile back. So my track record here isn't too good, but I believe there is only one value that may be used: NOT PARTICIPATING, meaning that there is no relationship. What the value of NOT APRTICIPATING is was left as an exercise for the architecture, but I would think it implies that the atribute domain is R+1. > > I think advantage is that it allows a simpler IM by using the > > link/unlink as an alternative to assigning INACTIVE to identifiers. > > This is not so good. Here, you seem to be saying that unlink and > assignment of inactive value are not synonymous. The only conclusion > I can draw from your suggestion that it simplifies the IM is that > you are not using referential attributes to formalise the relationship. > Instead, you are using hidden variables within the architecture. > > Now, I do not have a problem with hidden variables - OOA96 defined > "current-state" to be a hidden variable. However, you must consider > the implications of this radical change in the method. > > If refential attributes no longer formalise relationships, then it > follows that they are not a necessary part of a model. They would > have to be considered as optional. In fact, they are no longer > referential - they are just mathematically dependent attributes > that have a unity transform from their defining attributes. This > begins to seem rather redundant. We soon reach the conclusion that > referential attributes serve no useful purpose and clutter up the > IM. The obvious conclusion is that they should be removed from the > method. > > Is this the conclusion you intended? No, I merely considered the link/unlink as an operation *on* referential attributes, not a replacement for them. The link/unlink allows one to avoid using separate identifiers for each relationship and introducing composed relationships into the IM. That was the point of my example that we are debating separately. The link/unlink would be used in exactly the same places as a write accessor; it would simply remove some implementation issues for deinstantiation when the IM shows a relational attribute participating in multiple relationships. All of the underlying fundamentals of relational atributes are still preserved. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com --------------33D241574A8-- Subject: Re: (SMU) Linking/Unlinking Relationships - Why? David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: -------------------------------------------------------------------- Lahman wrote: > Responding to Whipp... > > > Fine, so you seem here to be saying that the unlink operation is synonymous > > with assigning a value to referential attributes that does not identify > > a related instance. > > Yes, unlink is equivalent to writing NOT PARTICPATING to the relational > identifier. The tools do some other things, though, that *are* > architectural in nature. > > > Unfortunately, there may be many possible "inactive" values that can be > > assigned to a referential attribute that do not refer to a related instance. > > If the range of the attribute-domain is R, and the number of instances of > > related object is N, then there are (R-N) possible values that could be > > assigned to the referential attribute to unlink it - Which one should > > "unlink" use? The answer is important because in instance might later > > be created whose identifier does match the value you used. > > It was news to me that there was even one when Neil pointed it out > awhile back. So my track record here isn't too good, but I believe > there is only one value that may be used: NOT PARTICIPATING, meaning > that there is no relationship. What the value of NOT PARTICIPATING is > was left as an exercise for the architecture, but I would think it > implies that the atribute domain is R+1. I think this is poorly defined area of the method. A quick example will demonstrate my viewpoint (there are flaws, due to the contrived nature of the example). Consider the relationship: CHILD has exactly one MOTHER Is this true? Does the child still have a mother after the mother has died? If, for the purpose of the model, we decide that the answer is no, then the relationship becomes conditional: CHILD has zero or one MOTHER. However, consider that (for the pupose of the example) the relaionship is formalised by an attribute in the child: 'mother's name'. Let's call her "Joan Doe'. When she dies, we delete instance 'Joan Doe' of MOTHER. We have not changed the attribute in the child (to "INACTIVE") because there is no need. The model is consistant. The child's mother is Joan Doe, who no longer exists. There is no need for a special value. (and if Joan Doe was ressurected, the relationship would automatically be reinstantiated). I beleive that the attribute-domain of referential attributes should be defined by the analyst to be appropriate for the model. Values like "inactive" may be inappropriate. Any value that isn't matched to a defining object can be used. Dave. -- David P. Whipp. Not speaking for: ------------------------------------------------------- G.E.C. Plessey Due to transcription and transmission errors, the views Semiconductors expressed here may not reflect even my own opinions! Subject: Re: (SMU) Linking/Unlinking Relationships - Why? peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- > When she dies, we delete instance 'Joan Doe' of MOTHER. >We have not changed the attribute in the child (to "INACTIVE") because >there is no need. The model is consistant. Yikes! This sounds like a modeling convenience resulting from a fancy architectural feature, but I'd prefer to see the analyst have the child recognize the death (and fix the formalizing attribute(s)), and maybe invoke an action to go get counseling or do some kind of culture-specific ritual or something. You're right - the method is subject to interpretation here. I hope the architecture guide that documents all these relationship features clearly lays out what happens in these cases. ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice/fax: +01 508-384-1392 | peterf@pathfindersol.com | ____________________________________________________| Subject: Re: (SMU) Linking/Unlinking Relationships - Why? lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Whipp... Regarding the multiple alternatives to NOT APRTICIPATING: > I think this is poorly defined area of the method. A quick example will > demonstrate my viewpoint (there are flaws, due to the contrived > nature of the example). > > Consider the relationship: CHILD has exactly one MOTHER > > Is this true? Does the child still have a mother after the mother has > died? If, for the purpose of the model, we decide that the answer is > no, then the relationship becomes conditional: CHILD has zero or one > MOTHER. > > However, consider that (for the pupose of the example) the relaionship > is formalised by an attribute in the child: 'mother's name'. Let's call > her "Joan Doe'. When she dies, we delete instance 'Joan Doe' of MOTHER. > We have not changed the attribute in the child (to "INACTIVE") because > there is no need. The model is consistant. The child's mother is > Joan Doe, who no longer exists. There is no need for a special value. > (and if Joan Doe was ressurected, the relationship would automatically > be reinstantiated). > > I beleive that the attribute-domain of referential attributes should > be defined by the analyst to be appropriate for the model. Values like > "inactive" may be inappropriate. Any value that isn't matched to a > defining object can be used. But what if the relationship is CHILD MOTHER and the CHILD does something nasty like setting fire to SIBLING so that the relationship ceases to exist but the MOTHER instance still lives on? Now the "mother's name" referential attribute in CHILD still contains the MOTHER name so, since the MOTHER instance is still around, this implies the relationship still exists. Put another way, why is the previous value of the referential attribute of interest once the relationship is deinstantiated? It seems to me that from the viewpoint of referential integrity the only thing that matters at that point is that the relationship is not instantiated, which is easily captured with a single abstract value, NOT PARTICIPATING. I also have a problem with using such explicit data domains to infer relationship mechanisms. The fact that one has a referential attribute whose data type is Text and which has a domain of some set of names should not place requirements on the implementation. The referential attribute merely means that whatever implementation mechanism is used to support the relationship, the instance that mechanism connects to had better have that name as an identifying attribute. I don't think it implies that one actually has to use the name as an integral part of the mechanism. In fact I think it would be extermely rare for any performance sensitive architecture to do so. Suppose the translator chose to use an address pointer instead of the name. So long as the address pointer pointed to a MOTHER data structure associated with "Joan Doe", all would be well. However, at run time how would you check to see if there was a "Joan Doe" instance before using the pointer? You certainly wouldn't search all the MOTHER instances for "Joan Doe". I suppose you could implement an auxiliary boolean data attribute for whether the pointer was really there that was set/reset as the relationship was created/deleted. Or you could change the address to point to some MOTHER instance whose identifier was "Just Kidding". But these seem to be just another way of doing NOT PARTICIPATING. I think one has to view referential attributes as abstractions of undefined mechanisms that simply ensure one gets to the right place (i.e., to an instance where the identifier has unique meaning) when navigating. In the OOA the relational identifier abstractions provide a convenient mechanism for verifying referential integrity but they only specify the run time post conditions for the translation, not how to get there. In this case a referential attribute domain of N+1 valid names (i.e., the valid set of viable MOTHER names plus NOT PARTICIPATING) seems reasonable. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) requirements flow kearnan@Summa4.COM (Gregg Kearnan) writes to shlaer-mellor-users: -------------------------------------------------------------------- We are trying to resolve a domain chart problem concerning two domains which seemingly place requirements on each other... We have a "message interface" domain which receives buffers of data across ethernet from a controller. This domain will use the services of a "logging" domain for logging diagnostic text strings. Many other domains will use the services of the 'logging' domain. This is an obvious flow of requirements from the "message interface" to the "logging" domain. It is forseen that logging information could be redirected to the controller instead of being sent to the typical media. This would mean that the "message interface" domain would be required to transport information from the logging domain. This appears to be the reverse flow of requirements. Does this problem indicate that the domain chart has some larger problems, are we misinterpreting our "flow of requirements", or are we allowed to flow requirements in both directions? Any help would be appreciated. Gregg Subject: RE: (SMU) Linking/Unlinking Relationships - Why? "John Harby" writes to shlaer-mellor-users: -------------------------------------------------------------------- I agree wholeheartedly with your last paragraph. Many of these interpretations of relationships and cardinality are subjective. If one deletes the mother and father then could one be able to conclude that this person is now equivalent to an orphan? Would this make orphanhood now a bi-directionally transient property rather than uni-directional? Possibly, if one is modeling a situation where orphanhood is not an issue, then this type of situation would not cause problems whereas others it may. ---------- From: owner-shlaer-mellor-users@projtech.com on behalf of Dave Whipp Sent: Wednesday, May 21, 1997 8:04 AM To: shlaer-mellor-users@projtech.com Subject: Re: (SMU) Linking/Unlinking Relationships - Why? David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: -------------------------------------------------------------------- Lahman wrote: > Responding to Whipp... > > > Fine, so you seem here to be saying that the unlink operation is synonymous > > with assigning a value to referential attributes that does not identify > > a related instance. > > Yes, unlink is equivalent to writing NOT PARTICPATING to the relational > identifier. The tools do some other things, though, that *are* > architectural in nature. > > > Unfortunately, there may be many possible "inactive" values that can be > > assigned to a referential attribute that do not refer to a related instance. > > If the range of the attribute-domain is R, and the number of instances of > > related object is N, then there are (R-N) possible values that could be > > assigned to the referential attribute to unlink it - Which one should > > "unlink" use? The answer is important because in instance might later > > be created whose identifier does match the value you used. > > It was news to me that there was even one when Neil pointed it out > awhile back. So my track record here isn't too good, but I believe > there is only one value that may be used: NOT PARTICIPATING, meaning > that there is no relationship. What the value of NOT PARTICIPATING is > was left as an exercise for the architecture, but I would think it > implies that the atribute domain is R+1. I think this is poorly defined area of the method. A quick example will demonstrate my viewpoint (there are flaws, due to the contrived nature of the example). Consider the relationship: CHILD has exactly one MOTHER Is this true? Does the child still have a mother after the mother has died? If, for the purpose of the model, we decide that the answer is no, then the relationship becomes conditional: CHILD has zero or one MOTHER. However, consider that (for the pupose of the example) the relaionship is formalised by an attribute in the child: 'mother's name'. Let's call her "Joan Doe'. When she dies, we delete instance 'Joan Doe' of MOTHER. We have not changed the attribute in the child (to "INACTIVE") because there is no need. The model is consistant. The child's mother is Joan Doe, who no longer exists. There is no need for a special value. (and if Joan Doe was ressurected, the relationship would automatically be reinstantiated). I beleive that the attribute-domain of referential attributes should be defined by the analyst to be appropriate for the model. Values like "inactive" may be inappropriate. Any value that isn't matched to a defining object can be used. Dave. -- David P. Whipp. Not speaking for: ------------------------------------------------------- G.E.C. Plessey Due to transcription and transmission errors, the views Semiconductors expressed here may not reflect even my own opinions! Subject: Re: (SMU) requirements flow Ken Cook writes to shlaer-mellor-users: -------------------------------------------------------------------- No, I don't think there is any problem with two service domains using each other. I would just draw arrows from each bubble pointing to the other bubble and move on. When you go to build the system, you will face the same issues any co-dependent clients have. Try to implement this bridge (in fact, all bridges) so that each domain depends only on the *interface* of the other domain, and not on the other domain's implementation. -Ken Gregg Kearnan wrote: > > kearnan@Summa4.COM (Gregg Kearnan) writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > We are trying to resolve a domain chart problem concerning two domains > which seemingly place requirements on each other... > > [snipped the actual example] > > Does this problem indicate that the domain chart has some larger > problems, are we misinterpreting our "flow of requirements", or > are we allowed to flow requirements in both directions? > > Any help would be appreciated. > > Gregg Subject: Re: (SMU) Linking/Unlinking Relationships - Why? lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Whipp... We have wandered a long way from my original point. A lot of this may be my fault because the details of the model were not important to me and I didn't worry about them. I was simply using it as a vehicle to illustrate a point about deinstantiating conditional relationships when the relational identifier is shared among relationships. As far as I was concerned the only things about the example that were important were ID1(R1,R2) and R2 being conditional. Unfortunately we are off on a tangent about the details of the example relationships. The arguments you are citing seemed to imply some dependencies based upon cardinality and conditionality that I didn't think applied. Or I misunderstood the argument that you were making. In any event it seems to me that something has gotten lost in translation, to coin a phrase. Your last message makes me think we are actually not that far apart because we both now seem to be saying that NOT PARTICIPATING is the root of all evil, or at least this example's. > > > I'm afraid I do not follow this. The R2 relationship is independent of > > R1 and R3. As an example, replace C with Test, A with Diagnosis, and B > > with Message. In this case R2 could represent a relationship for the end > > user optionally fetching the diagnostic message that the user associates > > with the Test. > > They are not independent, because R1 and R2 share a referential attribute. > That attribute can't have an "innactive" value because R1 is unconditional. > Therefore R2 cannot be conditional. In your original objection you cited a general argument based upon the cardinality of the R1 and R3 relationships than required that ID1 must represent the same instance. *That* general assertion is what I was arguing against. In the original message and this message I pointed out that because the R1 served two relationships, that fact required that the C instance must be the same on both paths. They are not independent in the sense that they must trace back to the same instance of C due to the shared identifier. However, the conditionality of R1 should have nothing to do with the conditionality of R2. All the shared relational attribute says is that both paths get back to the same C instance _if R2 is instantiated_. If R2 is not instantiated, then the issue is moot. This underscores my original point that using NOT PARTICIPATING creates a problem when one wants to deinstantiate R2. [Note the R1 could have been conditional as well, but that should not imply that they both have to go away at the same time.] As I indicated in the original message, R1 as 1:M and R2 as 1c:1c with ID1(R1,R2) is only a problem because use of NOT PARTICIPATING has painted the notation into a corner. If one uses an unlink construct instead of NOT PARTICIPATING, there is no problem and that set of relationships would be quite legal. > > > R3 is 1:M (each instance of C can have many related A because A has > > > a compound identifier) > > > > Instrument <-------------> Clock > X *INST_ID R1 *INST_ID(R1) > > *CLK_ID > What you are saying is that a clock is uniquely identified by the > instrument its connected to. For any value of INST_ID, there can > only be one value of CLK_ID. If this is what you are saying, then > clk_id is not part of the identifier - its just descriptive. No, there could be any of several Clocks with different CLK_IDs, but only one may be connected to an instrument at a time. You are correct that *most* of the time there would be and unconditional 1:M along with a 1c:1 (selection) relationship. However, this is not always the case. If a domain creates the Instrument and the Clock at the same time (based upon a particular bridge request that specifies the Clock to use), then there is no need to model the other Clocks and the single relationship is unconditional. This would not change the fact that CLK_ID is still a meaningful identifier in the domain, especially if there were multiple Instruments using different Clocks. > I get an uneasy feeling when I see this sort of model. If you > detach the clock from one instrument, and attach it to another, > then does it change identity?. The identity of the clock shouldn't > depend on its context - unless the clock is part of the instrument. > (in which case the model would still be wrong) True, identity is a problem. In those cases where one wants to switch the Clock to another Instrument, one literally has to delete the instance and re-create it. Generally when we use this scheme it is only in contexts where the need to switch identities is nil. PT recommended this approach in our original class years ago and we have adopted it as a standard. We very rarely have to worry about identity swaps and it provides a brainless way to ensure the integrity of relationship loops. And we have gotten burned when we don't do it by missing a relationship ambiguity. On balance it seems to be a Good Thing. > > Even if I granted all of the above, I still would not follow either of > > these conclusions. There is no reason why R2 has to relate a given > > instance of B to the same instance of C that A is related to in > > general. The conditionality and cardinality of the relationships have > > nothing to do with this. As it happens, the model *says* they must be > > the same because the same relational identifier in B is used to define > > both relationships, but this has nothing to do with the cardinality or > > conditionality -- it was an explicit statement in my model. > > Precisely - The model *says* so. The formalisation of relationships can > define constraints. In the case of your model, the constraints defined by > the formalisations resulted in an inconsitant model - It would be > impossible achieve a consistant population what utilised R2's ability to > be conditional. Since I pointed this out in the original message, I assumed you were making an argument based upon entirely different criteria related to conditionality and cardinality. > In the model you give below, R2 can be conditional - until/unless you > reimpose the constraints by asserted that R2=R1+R3. As soon as you do > this, R2 again cannot be conditional. > > > R3 > > +---------------------------------------+ > > | | > > v | > > v R1 C R2 C v > > A <-------------->> B <---------------> C > > *ID1(R3) *IDb * ID1 > > *IDa +ID1A(R1) > > +ID1C(R2) > > +IDa(R1) > > > > This is a legal model but it allows a different instance of C to be > > related to B via the R2 path than by the R1/R3 path. Therefore one > > needs R2=R1+R3 to capture that the paths are supposed to the lead to the > > same instance of C. > > The constraint is stonger than you are implying. The loop constraint > doesn't say "any instance of R2 must be equivalent to R1+R3". It says > "The set of instances of R2 must be equivalent to the set of chained > instances of R1+R3". Thus you cannot not have an R2 that corresponds > to an R1+R3. You have a good point. However, I think this again supports my original point. The problem is: given that the example above (w/o composed R2) reflects the real world, how do I also ensure that ID1A and ID1C stem from the same C instance? I think we are back to using ID1(R1,R2). But, given the notation's insistence that one write NOT PARTICIPATING into B.ID1 when the R2 relationship is deinstantiated, this is not possible. Which brings me back to my original assertion that the unlink contruct solves this problem because it leaves it to the implementation to figure out how to deinstantiate. Unlike NOT PARTICIPATING for an identifier sharing relationships, the syntax of the unlink is unambiguous about which relationship is deinstantiated so that it is possible to make the underlying mechanism for handling relationships consistent when it is encountered and relationships are shared in a referential attribute. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) requirements flow lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Kearnan... > Does this problem indicate that the domain chart has some larger > problems, are we misinterpreting our "flow of requirements", or > are we allowed to flow requirements in both directions? Not necessarily. There is an important distinction between the flow of requirements and the flow of communications. In a GUI environment the UI domain is usually a fairly low level service domain. However, it typically initiates all the "commands" to the application. Despite the fact that the UI domain initiates almost all communications that cause the application do something useful, it is still a basic service (providing an interface to the user) whose requirements are defined by the nature of the application. What you describe *seems* like a case of simply passing information back up the food chain and I would regard that as just a form of communication. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Linking/Unlinking Relationships - Why? David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: -------------------------------------------------------------------- Lahman wrote: > You have a good point. However, I think this again supports my original > point. The problem is: given that the example above (w/o composed R2) > reflects the real world, how do I also ensure that ID1A and ID1C stem > from the same C instance? I think we are back to using ID1(R1,R2). > But, given the notation's insistence that one write NOT PARTICIPATING > into B.ID1 when the R2 relationship is deinstantiated, this is not > possible. Which brings me back to my original assertion that the unlink > contruct solves this problem because it leaves it to the implementation > to figure out how to deinstantiate. > > Unlike NOT PARTICIPATING for an identifier sharing relationships, the > syntax of the unlink is unambiguous about which relationship is > deinstantiated so that it is possible to make the underlying mechanism > for handling relationships consistent when it is encountered and > relationships are shared in a referential attribute. I think we have a slight mismatch in our communications. You seem to be saying that you have a shared referential attribute where only one relationship is conditional. You realise that this attribute cannot hold a "not-participating" value; and you don't want to add other attributes to remove the sharing. Your solution is to use the UNLINK construct and let the implementation work out how to deinstantiate the relationship. If this is the case, then you are back to hidden variables; and thus we return the conclusion that referential attributes are redundant and just clutter up the model; and so should be discarded (see my previous posting). Dave. -- David P. Whipp. Not speaking for: ------------------------------------------------------- G.E.C. Plessey Due to transcription and transmission errors, the views Semiconductors expressed here may not reflect even my own opinions! Subject: Re: (SMU) Linking/Unlinking Relationships - Why? kearnan@Summa4.COM (Gregg Kearnan) writes to shlaer-mellor-users: -------------------------------------------------------------------- Subject: Re: (SMU) Linking/Unlinking Relationships - Why? lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Whipp... > I think we have a slight mismatch in our communications. You seem to be > saying that you have a shared referential attribute where only one > relationship is conditional. You realise that this attribute cannot > hold a "not-participating" value; and you don't want to add other > attributes to remove the sharing. Your solution is to use the UNLINK > construct and let the implementation work out how to deinstantiate > the relationship. > > If this is the case, then you are back to hidden variables; and thus > we return the conclusion that referential attributes are redundant > and just clutter up the model; and so should be discarded (see my > previous posting). Wow, I sure didn't see this conclusion coming! It is not that I don't *want* to to use separate attributes. The problem is that if I do, then I lose the idea that those attributes must be the same. When two relationships *necessarily* navigate to the same instance eventually, then it is important to capture this in the model and I see no alternative to using the ID(R1,R2) shared notation. This seems to be the only way to capture that fact that the referential identifiers for both relationships must get to the same place (i.e., the identifier for both relationships is always the same). My issue is that if the real world also demands that one relationship is conditional and one relationship is unconditional, then there is a problem with the notation (i.e., NOT PARTICIPATING) if the relationship can be deinstantiated before either instance is deleted. The problem is that NOT PARTICIPATING is ambiguous because when it is written to the referential attribute it does not indicate which relationship is being deinstantiated. [Actually it is only ambiguous when both relationships are instantiated AND both are conditional AND only one is removed, but who's quibbling about details?] I submit that an unlink construct does not have this ambiguity. I don't see what this has to do with hidden variables. And I especially don't see that it implies that referential attributes are redundant and should be discarded. I am merely suggesting the substitution of an unambigous notational artifact (link/unlink) for a ambiguous one (writing NOT PARTICIPATING to the attribute) when creating/deleting relationships. The underlying constraints on referential integrity are still preserved through the referential attributes. Link/unlink is just an artifact for describing *when* a relationship is active; the referential attributes must still determine *what* is related when the relationship is active. [I would argue that this dichotomy between what and when is esentially the problem with NOT PARTICIPATING; the notation is making assignment to a referential attribute serve double duty.] -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: RE: (SMU) requirements flow "David Wanner" writes to shlaer-mellor-users: -------------------------------------------------------------------- If the reason for using the "message interface" domain for redirecting logging domain output to the controller is because the "message interface" domain provides for the encoding of messages for transport over the ethernet then dual requirements may make sense. It depends on what the mission statement of your logging domain is. If the mission statement is simply to provide media storage for logged information then it doesn't make sense, however, if the logging domain also provides re-directing ability then it does make sense. In this second case the "message interface" domain is assuming a domain exists for logging diagnostic text strings (the logging domain) and the logging domain assumes that there is a domain that understands how to package re-directed logging information to the controller. So, in this case there could be a bridge with double sided arrowheads. However, ask yourself what re-direction really mean in your system. Is it a function of the operating system? Should it really be a function of a service domain? If it should be a part of a service domain then perhaps its a domain within itself (the Re-direction domain). This domain would understand things like what it means to re-direct information to another place. Specifically, it would understand that in order to re-direct information to the controller, ethernet header and trailor information needed to be wrapped around it, and therefore it would forward the information to the "message interface" domain. It would also understand that re-directed information to the media storage did not need such wrapping, and thus it would simply write the logged information. While the addition of another domain to handle re-direction is probably correct in theory, it probably is overkill within your system. I would lean to placing such re-directing ability either in the logging domain or in the architecture as a layer surrounding the standard io driver for your media. hope it helps! ---------- From: owner-shlaer-mellor-users@projtech.com on behalf of Gregg Kearnan Sent: Wednesday, May 21, 1997 5:38 PM To: shlaer-mellor-users@projtech.com Subject: (SMU) requirements flow kearnan@Summa4.COM (Gregg Kearnan) writes to shlaer-mellor-users: -------------------------------------------------------------------- We are trying to resolve a domain chart problem concerning two domains which seemingly place requirements on each other... We have a "message interface" domain which receives buffers of data across ethernet from a controller. This domain will use the services of a "logging" domain for logging diagnostic text strings. Many other domains will use the services of the 'logging' domain. This is an obvious flow of requirements from the "message interface" to the "logging" domain. It is forseen that logging information could be redirected to the controller instead of being sent to the typical media. This would mean that the "message interface" domain would be required to transport information from the logging domain. This appears to be the reverse flow of requirements. Does this problem indicate that the domain chart has some larger problems, are we misinterpreting our "flow of requirements", or are we allowed to flow requirements in both directions? Any help would be appreciated. Gregg Subject: (SMU) Formal analysis based on Shlaer-Mellor Sally Shlaer writes to shlaer-mellor-users: -------------------------------------------------------------------- Dear Leo, I am copying your message to our electronic users group and we'll see what they are aware of. I know there is academic work going on in this area, but as far as published, accessible information, I'm drawing a blank. Best regards, Sally Shlaer P. S. Esmugers, can we help Leo? BTW, his e-mail address, as it came through in the message header, is marcus@rush.aero.org. ===== At 03:39 PM 5/21/97 -0700, Leo Marcus wrote: > >Hello, > >I am interested to find out any references to published >work on formal analysis (e.g. translation to formal specification >languages, machine-aided proofs, etc.) based on Shlaer-Mellor >methodology. > >Many thanks, > >Leo Marcus > >Computer Systems Division, M1-055 >The Aerospace Corporation >Box 92957 >Los Angeles, CA 90009 > >marcus@aero.org >Phone:(310)336-4541 >Fax:(310)336-2231 > > Subject: (SMU) When you're finished with a timer Sam Walker writes to shlaer-mellor-users: -------------------------------------------------------------------- Situation: An instance is preparing for deletion, but still has a timer running which is set to fire an event to itself upon expiration. Scenario1: Cancel the timer and enter deletion. Suppose that the timer has already fired, but the event is still waiting to be processed by the instance. Also, suppose that another timer had been created just after the deletion of the first timer and has been given coincidentally the same timer id as the other one. So by attempting to cancel the timer which had already expired may lead to cancelling a wrong timer. Scenario2: Don't cancel the timer, and go into deletion. But suppose that after the instance had been deleted, another instance was created which has been given the same handle as for the old instance. The timer then fires and the new instance unexpectedly receives the event. Scenario3: Don't cancel the timer and don't go into deletion until the event has been recieved. The instance will continue to exist until it receives the timer event. Scenario4: Cancel the timer, and make the architecture enforce the fact that timer id's are unique throughout an entire session, and not just at one point in time. (Possibly by appending a time-stamp to the timer id). Scenario5: The architecture will automatically cancel the timer when the instance is deleted, so that it needn't be cancelled by the analyst. I guess the real question is, should this be an architecture problem or an analysis one? I would greatly appreciate any opinions, suggestions! Sam Walker Subject: Re: (SMU) When you're finished with a timer peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 03:03 AM 5/24/97 +1200, shlaer-mellor-users@projtech.com wrote: >Sam Walker writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >Situation: >An instance is preparing for deletion, but still has a timer running which is >set to fire an event to itself upon expiration. > Our architectures solve this problem by at object instance deletion time by finding all events and timers still outstanding against the deleted instance and eliminating them. If the timer didn't fire yet, the you kill it there. If it fired, then the event is caught in the event queue. >Scenario1: >Cancel the timer and enter deletion. Suppose that the timer has already >fired, but the event is still waiting to be processed by the instance. Also, >suppose that another timer had been created just after the deletion of the >first timer and has been given coincidentally the same timer id as the >other one. So by attempting to cancel the timer which had already >expired may lead to cancelling a wrong timer. Architecturally you should strive to avoid id reuse so quickly. >Scenario2: >Don't cancel the timer, and go into deletion. But suppose that after the >instance had been deleted, another instance was created which has >been given the same handle as for the old instance. The timer then fires >and the new instance unexpectedly receives the event. This is covered by the architectural cleanup activities during object instance deletion. >Scenario3: >Don't cancel the timer and don't go into deletion until the event has been >recieved. The instance will continue to exist until it receives the timer >event. If this isn't what the analyst wanted to do, then you've got architecture restrictions affecting your analysis. >Scenario4: >Cancel the timer, and make the architecture enforce the fact that timer >id's are unique throughout an entire session, and not just at one point in >time. (Possibly by appending a time-stamp to the timer id). This is a generic problem - EVERYTHING that references an object/timer/event/etc with a reusable identifier must be cleaned up when that object/timer/event/etc is deleted. >Scenario5: >The architecture will automatically cancel the timer when the instance is >deleted, so that it needn't be cancelled by the analyst. Bingo. Good luck. ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice/fax: +01 508-384-1392 | peterf@pathfindersol.com | ____________________________________________________| Subject: Re: (SMU) Linking/Unlinking Relationships - Why? lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Kearnan... > I certainly wouldn't want to lose the ability to collapse a reference and > and the ability express the intent to reference the same object. If one of the > relationships is conditional, then > ID (R1, R2) isn't correct right from the start. Should you read this as "ID > references an object across both R1 and R2 simultaneously," or as "when both R1 and > R2 are valid relationships, we can use the same attribute for formalization." These > seem to be very different statements. I agree you don't want to lose the intent of referencing the same object. I also don't think ID(R1,R2) should be incorrect if one or both is conditional. It is only incorrect because writing NOT PARTICIPATING is ambiguous in this case. In my view this is an inconsistency in the notation. The basic problem is that assignment to the referential attribute is serving double duty in that it both identifies instance (static) and tracks instantiation (dynamic). I feel these are orthogonal functions in this case, so a single "value" can't service both. This is analogous to the double use of a function's return value to be a useful value if all went well or an error code if things went not so well. Bitter experience has demonstrated that this is a very bad programming practice because you always get screwed doing maintenance when the data domains for errors and/or useful values change and start to overlap. In this case one gets screwed when one has to simultaneously identify an instance and deinstantiate an instance. Of course, if there is another way of capturing the idea that the identifier for two relationships traces to the same instance without using ID(R1,R2), this becomes academic. I just can't think of a way to do that (other that composed relationships that, as Whipp pointed out, place additional constraints on cardinality and, therefore, can't work in all cases). Neil inserted NOT PARTICIPATING into my life. So where is he when I have to live with it? -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Formal analysis based on Shlaer-Mellor "Stephen R. Tockey" writes to shlaer-mellor-users: -------------------------------------------------------------------- > Sally Shlaer writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Dear Leo, > > I am copying your message to our electronic users group > and we'll see what they are aware of. I know there is academic > work going on in this area, but as far as published, > accessible information, I'm drawing a blank. > > Best regards, > Sally Shlaer > > P. S. Esmugers, can we help Leo? BTW, his e-mail address, as it > came through in the message header, is marcus@rush.aero.org. > > ===== > > At 03:39 PM 5/21/97 -0700, Leo Marcus wrote: > > > >Hello, > > > >I am interested to find out any references to published > >work on formal analysis (e.g. translation to formal specification > >languages, machine-aided proofs, etc.) based on Shlaer-Mellor > >methodology. > > > >Many thanks, > > > >Leo Marcus > > > >Computer Systems Division, M1-055 > >The Aerospace Corporation > >Box 92957 > >Los Angeles, CA 90009 > > > >marcus@aero.org > >Phone:(310)336-4541 > >Fax:(310)336-2231 Leo and all, To answer your question directly, we are not aware of any published work on formal analysis of Shlaer-Mellor models. But, several of us here at the Collins Avionics and Communications division of Rockwell are involved in a project to correlate OO specifications into the PVS prover system (from SRI). To date, we are not very far along, and we are not doing it for Shlaer-Mellor exactly. But I believe that our results will at least be correlate-able (if that's even a word) to S-M. I may not be able to give you the complete story, but I can at least give you some idea of where we've been. And we do intend to publish when we've got results that are complete enough to go public with. -- steve Sally: I'd be interested in hearing who in the academic community is working on this. Subject: Re: (SMU) Linking/Unlinking Relationships - Why? ian@kc.com (Ian Wilkie) writes to shlaer-mellor-users: -------------------------------------------------------------------- > peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > David Whipp wrote: > > >When she dies, we delete instance 'Joan Doe' of MOTHER. > >We have not changed the attribute in the child (to "INACTIVE") because > >there is no need. The model is consistant. > > Yikes! This sounds like a modeling convenience resulting from a fancy > architectural feature, but I'd prefer to see the analyst have the child > recognize the death (and fix the formalizing attribute(s)), and maybe invoke > an action to go get counseling or do some kind of culture-specific ritual or > something. I would agree with Peter here. I think that in David's example, the relationship "CHILD has exactly one MOTHER" is a vague one. What exactly does "has" mean ? If the relationship is conditional and is not present when the mother has died then I think that a better phrase would be "CHILD has exactly one *living* MOTHER". However, David's interpretation of the referential attribute (i.e. the value is always there) indicats a different relationships "CHILD was born to exactly one MOTHER". Which relationship is correct depends on the exact nature of the domain being modelled. If *both* are in some sense required then I would model the "born to" relationship with death being modelled as a state of the MOTHER. In either case, the referential attribute would reflect the presence or not of the relationship. > You're right - the method is subject to interpretation here. I hope the > architecture guide that documents all these relationship features clearly > lays out what happens in these cases. I don't believe the method is open to interpretation here. To back this up I rushed off to consult "Modeling the World in Data" (which just manages to avoid making it clear) then the lifecycles book (which doesn't go into sufficient detail about information modelling) and finally to my extensive collection of PT's training material: For example: The old "OOA: Information Models" course Version 3.0 (circa 1992) page 5.3.11 has an example of a 1c:1c relationship and clealy states that the domain of the referential attribute is the same as the referred attrbute plus "Not Participating". The original postings of this thread dealt with the use of link and unlink relationship constructs in ASL; When we designed our ASL, the intent behind this was to: a. Produce a more compact way of indicating relationship manipulation without referring to all of the referential attributes (of which there may be many) b. Reduce the instability of the ASL against changes in object identifiers c. Remove the ambiguity implied by setting only one many referntial attributes required for a relationship. d. Improve the readability of the ASL. Our ASL states that: - A domain may use either the link/unlink style or use referential attributes for manipulating the relationships. - If the link/unlink style is used then it is the responsbility of the architecture to set/unset the referential attributes as the link/unlinks are executed. Of the many architectures I have seen that support our ASL, all support the link/unlink style. >From a language perspective, I believe that an instance handle is semantically equivalent to the set of identifying attributes. Thus performing: link a R1 b is semantically equivalent to : b.ra1 = a.id1 b.ra2 = a.id2 b.ra3 = a.id3 where the ra's are the referential attributes of b and the id's are the identifying attributes of a. Ian Wilkie ===================================================== Kennedy Carter, 14 The Pines, Broad Street, Guildford Surrey, GU3 3BH, U.K. Tel: (+44) 1483 483 200 Fax: (+44) 1483 483 201 Further Information: http://www.kc.com or info@kc.com ===================================================== Subject: Re: (SMU) Linking/Unlinking Relationships - Why? kearnan@Summa4.COM (Gregg Kearnan) writes to shlaer-mellor-users: -------------------------------------------------------------------- Subject: (SMU) Recursive Design Gildo Medeiros Junior writes to shlaer-mellor-users: -------------------------------------------------------------------- Hi People ! I'm new in Shlaer-Mellor and I'd like to get additional information about Recursive Design and Implementation through Transformation. So, does anybody know where I can get such information ? Thanks a lot -- /*********************************/ /* Gildo Medeiros Junior */ /* Software Developer */ /* Equitel S.A. / Siemens */ /* */ /* e-mail: gildo@theoffice.net */ /* phone: +55 41 3415113 */ /* fax : +55 41 3415620 */ /* Address: Pedro Gusso 2635-CIC */ /* ZIP 80310900 */ /* Curitiba - Parana */ /* Brazil */ /*********************************/ Subject: Re: (SMU) Linking/Unlinking Relationships - Why? -Reply ERZ@ESEC.CH.MHS.CompuServe.COM writes to shlaer-mellor-users: -------------------------------------------------------------------- Ich befinde mich momentan in PARIS !!! Da ich mich dort nicht gerne storen lasse, sind meine Stellvertreter fur Pick&Place- Angelegenheiten CST oder PAP. Haben Sie Sorgen mit dem Waferhandler wenden sie sich bitte an RE. Fur Masterbereiche ist der Ansprechpartner JAB oder ST. Ich werde wieder ab dem 2. Juni ('97 !!) in der ESEC SA sein. Gruss Ernst Subject: [Fwd: Re: (SMU) Linking/Unlinking Relationships - Why?] lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- This is a multi-part message in MIME format. --------------7EF56F812C77 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com --------------7EF56F812C77 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <3385F1D6.45C1@atb.teradyne.com> Date: Fri, 23 May 1997 15:36:54 -0400 From: lahman Reply-To: lahman@atb.teradyne.com Organization: Teradyne/ATB X-Mailer: Mozilla 3.0 (WinNT; U) MIME-Version: 1.0 To: Gregg Kearnan Subject: Re: (SMU) Linking/Unlinking Relationships - Why? References: <199705231338.JAA03509@sneezy.summa4.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Responding to Kearnan... > The way I understand it, ID(R1,R2) really implies: > > IDa(R1) > IDb(R2) > > with a mathematical dependency of IDa = IDb. Now, if we view a mathematical > dependency as IDa = F( IDb ), we can make use of the fact that > the inverse relationship: > > -1 > IDb = F ( IDa ) > > may not always have a proper definition (i.e. it doesn't exist). > > Using mathematical dependency instead of ID(R1,R2) may be a way out of this > problem. > > (Here's where someone should stop me if this doesn't make sense) > > Lets say the model would look like: > > IDa(R1) M > IDb(R2) M // according to OOA96 I am not sure I understand the significance of the "M". Are you referring to the "c" qualifier on pg 14 of OOA96? If so, I think this solution is not quite it; it is meant to deal with dependency between identifiers, not necessarily equality. > where R1 is conditional and R2 is conditional. > and in the description of the attributes we place the formulas: > > IDa = IDb | IDb != NOT PARTICIPATING > > and > > IDb = IDa | IDa != NOT PARTICIPATING > > This notation could be read "attribute IDa equals IDb given that R2 exists." > (I'm stealing the "given" notation from probability notation) > and vice versa. My whole intent with this notation is to expose the relationship > dependency using well defined notation. This would allow one to use an ADFD to > assign a value of NOT PARTICIPATING, and allow the architecture to use the formula > to decide whether or not to generate an error condition. Sure, this works. The problem is that for automatic generation you would have to do something else at translation time to capture that description in a translation rule. The advantage of unlink (in conjunction with the IM) is that there is sufficient information for the translator in the combined IM and ADFD process (assuming unlink would be a special ADFD process akin to "create"). Once the unlink process was defined, no additional work would be necessary to generate code or simulate. > If the relationships are both unconditional, use the ID(R1,R2) notation. > > questions about this notation do arise, however. IF I need to change both > IDa and IDb to another value (but still identical), I might write this as > > IDa = new value // after this process, IDa != IDb !!! > IDb = new value > > Should an error be generated here? Given a mathematical dependence between > IDa and IDb, should I simply write this as: Not necessarily. If the atomic unit of integrity is the state action, then it would not be an error unless the two assignments were is separate actions. One just has to be sure things are OK by the end of the action. > This is just an idea I'm tossing out. Solving this problem should be done by > expanding notation that will allow the use of the current ADFD process types. > I prefer to think of the processes in terms of ADFD because they remove any > concept of code and data structures. Action languages (at least my concept of > them) still feel as though you are writing pseudo-code. I think a new process type would have to be added, or at least a special naming convention (assuming one goes with the unlink form). The goal is to allow the translator to recognize the unlink process and the relationship so that it can do the right thing unaided. I suspect you would need an ADFD process called "unlink" that had an out-of-the-air input data flow with the relationship name. (Things get trickier for M:M because of the associative object.) BTW, everyone's E-Mail buffer gets a rest for a week -- I'm going on vacation. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com --------------7EF56F812C77-- Subject: Re: (SMU) Linking/Unlinking Relationships - Why? -Reply Dana Simonson writes to shlaer-mellor-users: -------------------------------------------------------------------- Ich sprecha Deutsch nicht, sprecht du Americanner? (Sorry if spelling is mutilated, I haven't looked at German since college.) >>> 05/23/97 12:46pm >>> ERZ@ESEC.CH.MHS.CompuServe.COM writes to shlaer-mellor-users: -------------------------------------------------------------------- Ich befinde mich momentan in PARIS !!! Da ich mich dort nicht gerne storen lasse, sind meine Stellvertreter fur Pick&Place- Angelegenheiten CST oder PAP. Haben Sie Sorgen mit dem Waferhandler wenden sie sich bitte an RE. Fur Masterbereiche ist der Ansprechpartner JAB oder ST. Ich werde wieder ab dem 2. Juni ('97 !!) in der ESEC SA sein. Gruss Ernst Subject: Re: (SMU) Linking/Unlinking Relationships - Why? -Reply ERZ@ESEC.CH.MHS.CompuServe.COM writes to shlaer-mellor-users: -------------------------------------------------------------------- Ich befinde mich momentan in PARIS !!! Da ich mich dort nicht gerne storen lasse, sind meine Stellvertreter fur Pick&Place- Angelegenheiten CST oder PAP. Haben Sie Sorgen mit dem Waferhandler wenden sie sich bitte an RE. Fur Masterbereiche ist der Ansprechpartner JAB oder ST. Ich werde wieder ab dem 2. Juni ('97 !!) in der ESEC SA sein. Gruss Ernst Subject: Re: (SMU) Linking/Unlinking Relationships - Why? -Reply -Reply ERZ@ESEC.CH.MHS.CompuServe.COM writes to shlaer-mellor-users: -------------------------------------------------------------------- Ich befinde mich momentan in PARIS !!! Da ich mich dort nicht gerne storen lasse, sind meine Stellvertreter fur Pick&Place- Angelegenheiten CST oder PAP. Haben Sie Sorgen mit dem Waferhandler wenden sie sich bitte an RE. Fur Masterbereiche ist der Ansprechpartner JAB oder ST. Ich werde wieder ab dem 2. Juni ('97 !!) in der ESEC SA sein. Gruss Ernst Subject: [Fwd: Re: (SMU) Linking/Unlinking Relationships - Why?] -Reply ERZ@ESEC.CH.MHS.CompuServe.COM writes to shlaer-mellor-users: -------------------------------------------------------------------- Ich befinde mich momentan in PARIS !!! Da ich mich dort nicht gerne storen lasse, sind meine Stellvertreter fur Pick&Place- Angelegenheiten CST oder PAP. Haben Sie Sorgen mit dem Waferhandler wenden sie sich bitte an RE. Fur Masterbereiche ist der Ansprechpartner JAB oder ST. Ich werde wieder ab dem 2. Juni ('97 !!) in der ESEC SA sein. Gruss Ernst Subject: (SMU) RE: (M)/ids (was: Linking/Unlinking Relationships) peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 09:38 AM 5/23/97 -0400, shlaer-mellor-users@projtech.com wrote: >kearnan@Summa4.COM (Gregg Kearnan) writes to shlaer-mellor-users: >-------------------------------------------------------------------- > ... >If the relationships are both unconditional, use the ID(R1,R2) notation. > >questions about this notation do arise, however. IF I need to change both >IDa and IDb to another value (but still identical), I might write this as > >IDa = new value // after this process, IDa != IDb !!! >IDb = new value > >Should an error be generated here? Given a mathematical dependence between >IDa and IDb, should I simply write this as: > >IDa = new value > >and assume that the architecture will replace the value of IDb? >Any thoughts on this? Along 2 lines: At the lowest level - regarding mathematical dependance and ignoring the identifier aspects - what you've specifed and asserted is correct: if IDb is (M), then you cannot have a write accessor for it. The way we see (M) attributes from OOA96, you must have a property of the attribute which specifies the "formula/equation" of the dependence. Architecturally, we apply the equation in the read accessor for IDb. OK - on a higher level - I am very uncomfortable with the use of (M) on identifiers - I believe collapsed formalization is more appropriate. The architecture knows more about ID(R1,R2) than it knows about IDa(R1), IDb(M)(R2). Even if you extend your architectural understanding of (M) to cover identifiers, the collapsed formalization notation is simpler, and in all likelyhood more portable across architectures. ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice/fax: +01 508-384-1392 | peterf@pathfindersol.com | ____________________________________________________| Subject: Re: (SMU) Linking/Unlinking Relationships - Why? David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: -------------------------------------------------------------------- > ian@kc.com (Ian Wilkie) writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > I don't believe the method is open to interpretation here. To back this > up I rushed off to consult "Modeling the World in Data" (which just manages > to avoid making it clear) then the lifecycles book (which doesn't go > into sufficient detail about information modelling) and finally to > my extensive collection of PT's training material: > > For example: The old "OOA: Information Models" course Version 3.0 (circa > 1992) page 5.3.11 has an example of a 1c:1c relationship and clealy states > that the domain of the referential attribute is the same as the > referred attrbute plus "Not Participating". You are right. Your knowledge of the PT material is more extensive than mine. This fact (not supported by the CASE tool that we use) simplifies one of my other points: R1 c R2 c A<----->B<-------->C where B has attribute ref_attr(R1,R2) is an invalid model because it requires two different domains. R1 is unconditional, so the domain of ref_attr is same as id_A but R2 is conditional so the domain is id_c + 'not participating'. My proof of inconsitancy is now trivial if I am able to assert that 'not participating' is a magic value, and therefore cannot be part of an identifier (in the domain of id_A) But now back to the most important point: As Ian identified, the main purpose of this thread is the meaning of the link/unlink constructs. I've selectively quoted as few of his points about the reasons for link/unlink. ibutes required for a relationship. > [...] > > - If the link/unlink style is used then it is the responsbility > of the architecture to set/unset the referential attributes as > the link/unlinks are executed. > > From a language perspective, I believe that an instance handle is > semantically equivalent to the set of identifying attributes. Thus > performing: > > link a R1 b > > is semantically equivalent to : > > b.ra1 = a.id1 > b.ra2 = a.id2 > b.ra3 = a.id3 > > where the ra's are the referential attributes of b and the id's are > the identifying attributes of a. This equivalence has the implication that "link a R1 b" is equivalent to "link b R2 c" in the example above. This must be true because setting the referential attributes will link both relationships. There can be no possiblity of linkning the relationships independently. > b. Reduce the instability of the ASL against changes in object identifiers > > c. Remove the ambiguity implied by setting only one many referntial > attr Ian made these points in favour of link/unlink. However, duality is unavoidable. The corresponding points against link/unlink could be: b. link/unlink should have side effects that vary as relationship formalisation changes. For example, if an assoc object is introduced on R2 then linking R1 would no longer effect R2. c. link/unlink have side effects when multiple relationships are formalised in a single referential attribute. My ASL documentation (which is rather dated) implies that the analyst must explicity link/ unlink all relationships involved. For example, associative objects must be unassociated before unlinking the relationship. These issues arise because there are two ways of thinking about relationships. My understanding is that a relationship exists as a consequence of the inclusion of foreign keys (referential attributes) into a data table (object). The value of these attributes is used to search the related data table for the maching key (identifier). From this point of view, relationships only have a virtual existance (**from the point of view of the analysis** - the architecture can create shortcut links) The other view of relationships is that they are tangible things that can be manipulated to form links between object-instances. They exist semi-independently of the objects that they connect. This mind-set would imply that all relationships have an associative object, but the notation allows its ommision for simple relationships. In this view, the instantiation of relationships is done via hidden variables (a bit like "current state") and referential attributes are used to reflect the existance, or otherwise, of relationship instances. From this point of view, the referential attributes only have virtual existance (**from the point of view of the analysis** - the architecture can store local copies of the values) These two viewpoints are quite fundamentaly different, with some external similarities. Lahman's posts suggest that he favours the latter interpretation, and thus is able to say, for example: | All the shared relational attribute says is that both paths get | back to the same C instance _if R2 is instantiated_. If R2 is not | instantiated, then the issue is moot. The "foreign-key' interpretation has no concept of relationship instantiation, so this statement is meaningless. A referential attribute always has exactly one value, and this value is used to search the related data table(s) for the related instance(s). Dave. -- David P. Whipp. Not speaking for: ------------------------------------------------------- G.E.C. Plessey Due to transcription and transmission errors, the views Semiconductors expressed here may not reflect even my own opinions! Subject: Re: (SMU) Linking/Unlinking Relationships - Why? ian@kc.com (Ian Wilkie) writes to shlaer-mellor-users: -------------------------------------------------------------------- I posted this last week, but it seems to have got lost..... > peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > David Whipp wrote: > > >When she dies, we delete instance 'Joan Doe' of MOTHER. > >We have not changed the attribute in the child (to "INACTIVE") because > >there is no need. The model is consistant. > > Yikes! This sounds like a modeling convenience resulting from a fancy > architectural feature, but I'd prefer to see the analyst have the child > recognize the death (and fix the formalizing attribute(s)), and maybe invoke > an action to go get counseling or do some kind of culture-specific ritual or > something. I would agree with Peter here. I think that in David's example, the relationship "CHILD has exactly one MOTHER" is a vague one. What exactly does "has" mean ? If the relationship is conditional and is not present when the mother has died then I think that a better phrase would be "CHILD has exactly one *living* MOTHER". However, David's interpretation of the referential attribute (i.e. the value is always there) indicats a different relationships "CHILD was born to exactly one MOTHER". Which relationship is correct depends on the exact nature of the domain being modelled. If *both* are in some sense required then I would model the "born to" relationship with death being modelled as a state of the MOTHER. In either case, the referential attribute would reflect the presence or not of the relationship. > You're right - the method is subject to interpretation here. I hope the > architecture guide that documents all these relationship features clearly > lays out what happens in these cases. I don't believe the method is open to interpretation here. To back this up I rushed off to consult "Modeling the World in Data" (which just manages to avoid making it clear) then the lifecycles book (which doesn't go into sufficient detail about information modelling) and finally to my extensive collection of PT's training material: For example: The old "OOA: Information Models" course Version 3.0 (circa 1992) page 5.3.11 has an example of a 1c:1c relationship and clealy states that the domain of the referential attribute is the same as the referred attrbute plus "Not Participating". The original postings of this thread dealt with the use of link and unlink relationship constructs in ASL; When we designed our ASL, the intent behind this was to: a. Produce a more compact way of indicating relationship manipulation without referring to all of the referential attributes (of which there may be many) b. Reduce the instability of the ASL against changes in object identifiers c. Remove the ambiguity implied by setting only one many referntial attributes required for a relationship. d. Improve the readability of the ASL. Our ASL states that: - A domain may use either the link/unlink style or use referential attributes for manipulating the relationships. - If the link/unlink style is used then it is the responsbility of the architecture to set/unset the referential attributes as the link/unlinks are executed. Of the many architectures I have seen that support our ASL, all support the link/unlink style. >From a language perspective, I believe that an instance handle is semantically equivalent to the set of identifying attributes. Thus performing: link a R1 b is semantically equivalent to : b.ra1 = a.id1 b.ra2 = a.id2 b.ra3 = a.id3 where the ra's are the referential attributes of b and the id's are the identifying attributes of a. Ian Wilkie ===================================================== Kennedy Carter, 14 The Pines, Broad Street, Guildford Surrey, GU3 3BH, U.K. Tel: (+44) 1483 483 200 Fax: (+44) 1483 483 201 Further Information: http://www.kc.com or info@kc.com ===================================================== ----- End Included Message ----- 'archive.9706' -- Subject: Re: (SMU) Linking/Unlinking Relationships - Why? lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Whipp... > You are right. Your knowledge of the PT material is more extensive than mine. > This fact (not supported by the CASE tool that we use) simplifies one of > my other points: > > R1 c R2 c > A<----->B<-------->C > > where B has attribute ref_attr(R1,R2) > > is an invalid model because it requires two different domains. R1 is > unconditional, so the domain of ref_attr is same as id_A but R2 is > conditional so the domain is id_c + 'not participating'. My proof > of inconsitancy is now trivial if I am able to assert that > 'not participating' is a magic value, and therefore cannot be part of > an identifier (in the domain of id_A) At the risk of beating a dead example, I agree with you that this is illegal. My issue is that it is *only* illegal because NOT PARTICIPATING has screwed things up. I believe it is highly desirable in a model to indicate that two relationships _must_ have the same identifier. This is not possible so long as the attribute must also capture the temporal nature of conditional relationships through NOT PARTICIPATING. [As you pointed out, one cannot use a composed relationship to solve the problem if one uses separate attributes.] > These issues arise because there are two ways of thinking about > relationships. My understanding is that a relationship exists as > a consequence of the inclusion of foreign keys (referential > attributes) into a data table (object). The value of these > attributes is used to search the related data table for the > maching key (identifier). From this point of view, relationships > only have a virtual existance (**from the point of view of the > analysis** - the architecture can create shortcut links) > > The other view of relationships is that they are tangible things > that can be manipulated to form links between object-instances. > They exist semi-independently of the objects that they connect. > This mind-set would imply that all relationships have an > associative object, but the notation allows its ommision for > simple relationships. In this view, the instantiation of > relationships is done via hidden variables (a bit like "current > state") and referential attributes are used to reflect the > existance, or otherwise, of relationship instances. From this > point of view, the referential attributes only have virtual > existance (**from the point of view of the analysis** - the > architecture can store local copies of the values) > > These two viewpoints are quite fundamentaly different, with > some external similarities. Lahman's posts suggest that he > favours the latter interpretation, and thus is able to say, > for example: > > | All the shared relational attribute says is that both paths get > | back to the same C instance _if R2 is instantiated_. If R2 is not > | instantiated, then the issue is moot. > > The "foreign-key' interpretation has no concept of relationship > instantiation, so this statement is meaningless. A referential > attribute always has exactly one value, and this value is used > to search the related data table(s) for the related instance(s). As you point out the problem with the first view is that it does not capture the dynamics of conditional relationships. OTOH, it provides a very good, simple mechanism for referential integrity in a static model. Thus I would prefer to think of referential attributes themselves as static relational table identifiers at analysis time. In this sense I see the first sentence of my quote as supporting the relational view. However, when doing ADFDs of state actions, I would prefer the link/unlink to capture the ephemeral nature of conditional relationships. (Note that I would not be unhappy if link/unlink were limited only to conditional relationships and one just did attribute assignments for unconditional relationships.) In this sense I see the second sentence of my quote as supporting the tangible relationship view. However, I don't like the word "tangible" because it seems too strong. An implementation with an implicit associative object is not at all what I would envision. I see link/unlink as merely an abstract mechanism to indicate existence of the relationship itself. It just seems cleaner an less implementation dependent than including an R2_exists flag atribute in the IM (as opposed to NOT PARTICIPATING). I really think that instantiation/deinstantiation of conditional relationships dynamically is an orthogonal issue to the static instance identification issues. So I come firmly down in favor of both views. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) Instance Data Michael Hendry writes to shlaer-mellor-users: -------------------------------------------------------------------- Hello everyone. I have a curiosity question. I was wondering how many of you are currently using instance data during translation. I'm not talking about translating a model and adding initialization code to create appropriate instances. I'm talking about using instance data during the process to guide the translation. If you are, how is the translation done, by hand or automated, and how is the instance data pulled into the translation process. Thanks, Michael J. Hendry Sundstrand Aerospace Rockford, IL MJHendry@snds.com Subject: Re: (SMU) Recursive Design "Sergio Mainetti Jr." writes to shlaer-mellor-users: -------------------------------------------------------------------- Gildo Medeiros Junior wrote: > > Gildo Medeiros Junior writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Hi People ! > > I'm new in Shlaer-Mellor and I'd like to get additional information > about Recursive Design and Implementation through Transformation. So, > does anybody know where I can get such information ? > > Thanks a lot I haven't seen any answers to this message in the list. I'm wondering if nobody sent answers to this or if it's a problem with my Email address that is not receiving all the messages in this list. Could someone tell me if there were answers to this ? If nobody answered, let me decrease the scope of the subjects. What I'm really interested is Recursive Design. I remember reading articles from Steve Mellor in 1994-95 in Object Magazine (or Journal of Object Oriented Programming, or ROAD, I don't remember exactly which one) and it was mentioned that he was writting a book about Recursive Design to be published soon. Does anyone know anything about such a book ? Is there any book about this available ? Is there anyplace on the Web where we can go to obtain more information about this ? Actually I've been hearing about Recursive Design for quite some time (since those articles in 94-95) but I haven't seen any formal description, or anyone really using. Are there articles available about this on the net ? Are there companies using Recursive Design ? Are there real case studies about this ? Thanks in advance for the information. ---------------------------------------------------- Sergio Mainetti Jr. - Visionnaire mainetti@visionnaire.com.br mainetti@embratel.net.br http://www.visionnaire.com.br Tel: +55 (041) 243-2724 ---------------------------------------------------- Subject: Re: (SMU) Linking/Unlinking Relationships - Why? David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: -------------------------------------------------------------------- lahman wrote: > However, when doing ADFDs of state actions, I would prefer the > link/unlink to capture the ephemeral nature of conditional > relationships. (Note that I would not be unhappy if link/unlink were > limited only to conditional relationships and one just did attribute > assignments for unconditional relationships.) In this sense I see the > second sentence of my quote as supporting the tangible relationship > view. However, I don't like the word "tangible" because it seems too > strong. An implementation with an implicit associative object is not at > all what I would envision. I see link/unlink as merely an abstract > mechanism to indicate existence of the relationship itself. It just > seems cleaner an less implementation dependent than including an > R2_exists flag atribute in the IM (as opposed to NOT PARTICIPATING). (sorry for the bit about the associative object. Its the foreign-key way of expressing what you are doing. If you hold the tangible-instances view of relationships then, by definition, you won't see the need for the associative object). > I really think that instantiation/deinstantiation of conditional > relationships dynamically is an orthogonal issue to the static instance > identification issues. So I come firmly down in favor of both views. > I has to think a bit about this last paragraph. My immediate thought was that conditionality is a static property, whilst the actual instance identification is dynamic. My view of conditionality implies meerly that it is legal to have no related instance for a relationship. Then I realised that what you are proposing is that there is an orthogonal distinction between _what_ instances are involved and _whether_ the relationship is connected. I do not see any such distinction. Both are implied by the values of referential attributes. I will strongly suggest, however, that if you do want to separate the two concepts then you have TWO pieces of information. Thus you MUST have two attributes somewhere in the model -- even if one is hidden in the architecture But I think you already understood that. Your problem is that you want to constrain a conditional relationship such that when a related instance exists, that related instance must be related (unconditonally) to a third instance. You manged the method to allow you to express that concept. Looking at the method we see three ways of constraining referential attributes: composed relastionships [e.g. R1=R2+R3], collapsed referentials [e.g. ref_a(R1,R2)] and the rather less well defined constrained referential [e.g. ref_a(R1c)] OOA96 (p14) says of this final form: "Note that this tagging is simply a reminder to the analyse who will still have to incorporate the constraint formally ..." Thus it does not currently have any well defined meaning. If you want to mould the method to incorporate more complex constraints than are currently defined in the method then perhaps this should be your starting point. Dave. -- David P. Whipp. Not speaking for: ------------------------------------------------------- G.E.C. Plessey Due to transcription and transmission errors, the views Semiconductors expressed here may not reflect even my own opinions! Subject: Re: (SMU) Instance Data lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Hendry... > I have a curiosity question. I was wondering how many of you > are currently using instance data during translation. I'm not > talking about translating a model and adding initialization code > to create appropriate instances. I'm talking about using instance > data during the process to guide the translation. If you are, how > is the translation done, by hand or automated, and how is the > instance data pulled into the translation process. I am not sure how instance data could guide translation. The implication is that somehow an attribute value, the existence of a conditional relationship, or the existence of an instance whould somehow cause different code to be generated. The problem is that at translation time all one has is abstractions rather than values, specific relationships or specific instances. That is, the model "data" being translated is always the same. I am not sure we do what you have in mind. One example that *may* be relevant is the automatic generation of bridge calls from write accessors. We have two domains where attributes in one domain have a direct correspondance to objects in another domain. When a write accessor writes to the attribute the translator automatically generates a bridge call to the second domain. One could argue, though, that this is simply a translation rule. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Linking/Unlinking Relationships - Why? lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Whipp... > > I really think that instantiation/deinstantiation of conditional > > relationships dynamically is an orthogonal issue to the static instance > > identification issues. So I come firmly down in favor of both views. > > > > I has to think a bit about this last paragraph. My immediate thought > was that conditionality is a static property, whilst the actual > instance identification is dynamic. My view of conditionality implies > meerly that it is legal to have no related instance for a relationship. > > Then I realised that what you are proposing is that there is an > orthogonal distinction between _what_ instances are involved and > _whether_ the relationship is connected. I do not see any such > distinction. Both are implied by the values of referential > attributes. I will strongly suggest, however, that if you do > want to separate the two concepts then you have TWO pieces of > information. Thus you MUST have two attributes somewhere in the > model -- even if one is hidden in the architecture More precisely, I see a distinction between _what_ instances are involved and _when_ they are involved. I may be counting angels on a pinhead but _whether_ is more of a binary concept in my mind; _when_ implies a span in time. While I agree that there are two pieces of information, I do not see the need for two attributes explicitly in the model. I see link/unlink as an abtract mechanism for defining the temporal bounds of the existence of the relationship. This is one piece of information while the referntial attribute is the other piece of information. This allows the architecture the flexibility to use NOT PARTICIPATING as an added data domain value for the existing referential attribute (e.g., a NULL pointer) if that is appropriate. Similarly the translator could implement ref_a(R1,R2) as two separate pointers where R2 can be NULL or an indirect reference to the R1 pointer. That is, I see ref_a(R1,R2) combined with link/unlink as a sufficient, unambiguous description of what is going on so there is no need to add another attribute to the IM. > But I think you already understood that. Your problem is that you > want to constrain a conditional relationship such that when a > related instance exists, that related instance must be related > (unconditonally) to a third instance. You manged the method to > allow you to express that concept. > > Looking at the method we see three ways of constraining > referential attributes: composed relastionships [e.g. R1=R2+R3], > collapsed referentials [e.g. ref_a(R1,R2)] and the rather less > well defined constrained referential [e.g. ref_a(R1c)] My problem is that there are cases where none of these work. The composed does not work for different cardinalities, the collapsed does not work for different conditionality, and the defined relationship is too loosely defined. > OOA96 (p14) says of this final form: "Note that this tagging is > simply a reminder to the analyse who will still have to incorporate > the constraint formally ..." Thus it does not currently have any > well defined meaning. If you want to mould the method to > incorporate more complex constraints than are currently defined in > the method then perhaps this should be your starting point. I look at this with a different slant. In my view the problem is that the existing construct, NOT PARTICPATING, is imperfect because it precludes the desirable ref_a(R1,R2) construct when there is differing conditionality. It fails because it forces a single construct, the static referential attribute, to serve double duty. I see link/unlink as an elegant replacement for NOT PARTICIPATING. I don't see the defined referential as a solution basis because it also forces double duty on a single construct and it is merely a static qualifier. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Instance Data David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: -------------------------------------------------------------------- Michael Hendry wrote: > I have a curiosity question. I was wondering how many of you > are currently using instance data during translation. I'm not > talking about translating a model and adding initialization code > to create appropriate instances. I'm talking about using instance > data during the process to guide the translation. If you are, how > is the translation done, by hand or automated, and how is the > instance data pulled into the translation process. Presumably you are talking about using initial population data, not dynamic instances. If so, the answer is yes but not as part of our main translator (and, I suspect, even this is not quite what you were talking about) Our application is modelling microcontrollers. One aspect of microcontrollers is that they contain peripherals that are controlled by memory mapped peripherals. We have a domain that contains an object called "register" which has attributes that describe its access modes - read/write; 8, 16 or 32 bits wide. Well, having got a nice C++ model of our microcontroller, derived from the SM model, I had a look at the possibilities of generating all or part of the hardware from the model. A complete hardware architecture is still beyond us, but I was able to write a generator for a bus slave that took a table of data describing its registers and wrote out an RTL VHDL description (which could then be synthesised to produce a silicon implementation). I was able to generate the table of data for this generator from the initial population of our model, so I could claim that I generated an implementation from instance data. Of course, this is a very limited application. There was no architecture in the conventional sense. I just took one object and generated a specific architype for that object. We are looking at more advanced techniques, but these are still fairly primative. If you look at what I was doing, you could generalise the technique to claim that all code generators use instance data to guide translation. The model that is populated is the OOA-of-OOA; and the instance data is the application domain models. I can see that there could be translators that used instance data in a more general way. If an instance was tagged as "constant" then standard constant propogation techniques of compilers could be extended to SM translators (In fact, we only require partial constness - if an object always exists then we can embed it more tightly into code). In the short term I can't see these techniques being used in automated generators. I can, however, foresee them being used as a standard part of manual/mechanised code generation. Dave. -- David P. Whipp. Not speaking for: ------------------------------------------------------- G.E.C. Plessey Due to transcription and transmission errors, the views Semiconductors expressed here may not reflect even my own opinions! Subject: Re: (SMU) Linking/Unlinking Relationships - Why? David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: -------------------------------------------------------------------- lahman wrote: > While I agree that there are two pieces of information, I do not see the > need for two attributes explicitly in the model. Yes, it could be a hidden variable - i.e. not explicitly in the model. But it must exist. My preference is to make it explicit. > I look at this with a different slant. In my view the problem is that > the existing construct, NOT PARTICPATING, is imperfect because it > precludes the desirable ref_a(R1,R2) construct when there is differing > conditionality. It fails because it forces a single construct, the > static referential attribute, to serve double duty. I see link/unlink > as an elegant replacement for NOT PARTICIPATING. I think we will have to agree to disagree. Whilst I understand the distinction you are making between the _what_ and the _when_ for relationship instances, I do not believe that this distiction is required for a Shlaer-Mellor model (you might just as well argue that you require Mealy machines in the state model). Ian (ian@kc.com) wrote that link/unlink is synonymous with writing referential attributes. This does not allow it to add any of the semantics that you are implying. Referential attributes specify the _what_ for any given _when_. Thus there is only one piece of information at a given time, not 2. Analysis is the process of breaking a problem into its constituent pieces. If there are 2 facts, then an analysis should expose them as such. You don't want to hide information. Dave. -- David P. Whipp. Not speaking for: ------------------------------------------------------- G.E.C. Plessey Due to transcription and transmission errors, the views Semiconductors expressed here may not reflect even my own opinions! Subject: Re: (SMU) Linking/Unlinking Relationships - Why? lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Whipp... > I think we will have to agree to disagree. Whilst I understand the > distinction you are making between the _what_ and the _when_ for > relationship instances, I do not believe that this distiction > is required for a Shlaer-Mellor model (you might just as well > argue that you require Mealy machines in the state model). The desire to use ref_a(R1,R2) with different conditionalities strikes me as a requirement that NOT PARTICIPATING can't handle. There may be other notational fixes, but the _what_ vs. _when_ dichotomy seems aesthetically pleasing. > Ian (ian@kc.com) wrote that link/unlink is synonymous with writing > referential attributes. This does not allow it to add any of the > semantics that you are implying. Referential attributes specify the > _what_ for any given _when_. Thus there is only one piece of > information at a given time, not 2. But Ian was talking about a particular action language implementation which was attempting to be faithful with NOT PARTICIPATING. I want to treat the link/unlink as a *replacement* for NOT PARTICIPATING with a different, purely temporal interpretation in the methodology. Then I think it *is* a different piece of information because it no longer has anything to do with the value of the referential attribute and the translator can deal with it quite independently. [The fact that the translator may choose to effectively use NOT PARTICIPATING via a NULL pointer or somesuch would be strictly an implementation issue.] -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Recursive Design peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- Sergio - Let me apologize for this on-line community - your question has been somewhat neglected. But answering an inquiry of such a daunting scope (*just* RD is still huge) is not something that you can just crank off quickly. At 01:16 PM 6/2/97 -0300, shlaer-mellor-users@projtech.com wrote: >"Sergio Mainetti Jr." writes to shlaer-mellor-users: > ... > If nobody answered, let me decrease the scope of the >subjects. What I'm really interested is Recursive Design. >I remember reading articles from Steve Mellor in 1994-95 in >Object Magazine (or Journal of Object Oriented Programming, >or ROAD, I don't remember exactly which one) and it was mentioned >that he was writting a book about Recursive Design to be >published soon. Does anyone know anything about such a book ? You can contact Steve directly through steve@projtech.com, but the book is not yet available. Actually, its availability is the subject of much speculation outside of Project Technology (Sally and Steve's company - and the host for this email forum) - Steve (or anyone else) - do you have an official answer for Sergio? > Is there anyplace >on the Web where we can go to obtain more information about this ? Browse www.projtech.com and download recent papers on bridges and synchronous services. They are taken from the work going into the book. Kennedy-Carter also has papers on these topics at www.kc.com. >Actually I've been hearing about Recursive Design for quite >some time (since those articles in 94-95) but I haven't seen >any formal description, or anyone really using. > ... > Are there companies >using Recursive Design ? Are there real case studies about this ? The book will be the closest thing to a "formal description", but there are quite a few projects really using it. I speculate that at least 75% of the projects who *seriously* apply this method today (excluding dabblers, experimenters, etc.) use some form of Recursive Design. I wouldn't be surprised if this fraction is actually over 95%. Consequently, there is some variation in how it is practiced. However, the core of the approach is relatively consistent, with the core concepts being very much shared, and different approaches varying in some of the details and levels of tool support. Brief summary: one of the most significant characteristics of Shlaer-Mellor OOA (not considering RD) - one that substantially distinguishes it from all other flavors of "OOA" - is the concept of Domain separation. The separation of a system into separate subject matters is the fundamental source of power behind virtually all of the strategic benefits of SM-OOA. These benefits include simple and orthogonal (and therefor elegant and powerful) constructs within domains, the separation of implementation from analysis and its family of benefits, and the ability to translate the analysis for a domain into its implementation via RD. Let me say that again: "SEPARATION OF SUBJECT MATTERS IS WHAT MAKES RD POSSIBLE". Conversly, the degree to which you are successful with SM-OOA/RD is significantly affected by the degree to which you are able to maintain domain "purity" - how well did you enforce the separation of subject matters. OK - what does all this have to do with RD? RD involves 3 basic steps: 1) the architectural design of the system: how all the pieces will fit together, and what mechanisms they use to run 2) the specification of what the implementatin form looks like for elements of the system modeled in OOA - this specification is sometimes captured in a set of templates or "archetypes" 3) the conversion of the semantic information for a domain - expressed in SM-OOA notation - into a set implementation components. Obviously if the templates from step 2) can be fed into a translation engine that reads your CASE database, this step can be fully automated. So why is it called "Recursive" design? You can express the implementation of a domain in terms of its servers (the domains it relies on). This is RD - but what do you call what "everyone else" does? The "traditional" approach is sometimes called "elaboration". At it's most rigorous, elaboration is the specification of analysis in some form, followed by a design phase where the analysis actually is manually changed (therefore eroded) into design, and design is again manually converted/eroded into implementation. Most commonly, elaboration is just hacking code. In RD, the analysis stands pure, and is the actual "source" for the system - the design is separate and disjoint (subject matter separation), and the implementation is a product of two. Example (this is an old P.T. metaphor): cookie dough is the Analysis, cookie cutters are the Design, and cookies are the Implementation. You don't get to use cookie cutters in Elaboration - each cookie is tediously shaped, one after the other, each cookie a little different from the last. With RD, the cookie cutter is employed to greatly increase quality, productivity (in the long term), and uniformity. I hopes this answers enough of your questions. RD is not new, nor is it an experiment. OOA/RD has been used for many years to produce solutions for some of the most demanding software challenges around: technical and embedded applications, including medical, avionics and telecom. It is the closest thing to rigorous *Software Engineering* that I am aware of. More questions are certainly welcome - but please try to make the scope a little more narrow - thanks. ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice/fax: +01 508-384-1392 | peterf@pathfindersol.com | ____________________________________________________| Subject: Re: (SMU) Recursive Design lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Fontana... > OK - what does all this have to do with RD? RD involves 3 basic steps: > > 1) the architectural design of the system: how all the pieces will fit > together, and what mechanisms they use to run > > 2) the specification of what the implementatin form looks like for elements > of the system modeled in OOA - this specification is sometimes captured in a > set of templates or "archetypes" > > 3) the conversion of the semantic information for a domain - expressed in > SM-OOA notation - into a set implementation components. Obviously if the > templates from step 2) can be fed into a translation engine that reads your > CASE database, this step can be fully automated. > > So why is it called "Recursive" design? You can express the implementation > of a domain in terms of its servers (the domains it relies on). Hmmm... This is a somewhat different spin on "recursive" than one gets from the PT course. There RD seemed to be described as the overall process with two phases operating on the domain chart. The first phase is the OOA where one works from the higher level domains to the lower, placing requirements on the lower level domains as each domain is analyzed. The second phase works through the domain chart from lower level to higher level doing the things you describe above to implement the analyzed domains. Thus I had the impression that "recursive" referred to the fact that one went over the domain chart twice. The difference in our views is clearly just cosmetic, though, since it just relates to what "recursive" means and where RD starts. The basic methodology activities are still the same. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Draino Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Recursive Design "Ken Cook" writes to shlaer-mellor-users: -------------------------------------------------------------------- Though both Peter's and HS's views of what "Recursive" means My perception of "Recursive Design" from the PT course was: applyOOA( domain ) { // please take this summary of SMOOA with // a grain of salt. produce domain technical description review produce Object Model review for each dynamic_obj in Object Model produce State Model for each state in State Model produce action specification end for end for review // HERES THE RECURSION PART for each domain_serving in domain applyOOA( domain_serving ) end for } Another sense of "recursion" is when you applyOOA to the architectural domains, you are often applying OOA to OOA. The above could be accomplished with a simple for loop over all the domains in the domain chart. It seems "Iterative Design" would have been just as accurate, though, IMO, neither "Iterative" nor "Recursive" really capture the full power of the method or the technology. We say "The model is the code". -Ken ---------- > From: lahman > To: shlaer-mellor-users@projtech.com > Subject: Re: (SMU) Recursive Design > Date: Thursday, June 05, 1997 6:21 AM > > lahman writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Responding to Fontana... > > > OK - what does all this have to do with RD? RD involves 3 basic steps: > > > > 1) the architectural design of the system: how all the pieces will fit > > together, and what mechanisms they use to run > > > > 2) the specification of what the implementatin form looks like for elements > > of the system modeled in OOA - this specification is sometimes captured in a > > set of templates or "archetypes" > > > > 3) the conversion of the semantic information for a domain - expressed in > > SM-OOA notation - into a set implementation components. Obviously if the > > templates from step 2) can be fed into a translation engine that reads your > > CASE database, this step can be fully automated. > > > > So why is it called "Recursive" design? You can express the implementation > > of a domain in terms of its servers (the domains it relies on). > > Hmmm... This is a somewhat different spin on "recursive" than one gets > from the PT course. There RD seemed to be described as the overall > process with two phases operating on the domain chart. The first phase > is the OOA where one works from the higher level domains to the lower, > placing requirements on the lower level domains as each domain is > analyzed. The second phase works through the domain chart from lower > level to higher level doing the things you describe above to implement > the analyzed domains. Thus I had the impression that "recursive" > referred to the fact that one went over the domain chart twice. > > The difference in our views is clearly just cosmetic, though, since it > just relates to what "recursive" means and where RD starts. The basic > methodology activities are still the same. > > -- > H. S. Lahman There is nothing wrong with me that > 321 Harrison Av L51 couldn't be cured by a capful of Draino > Boston, MA 02118-2238 > v(617)422-3842 > f(617)422-3100 > lahman@atb.teradyne.com Subject: RE: (SMU) Recursive Design "David Wanner" writes to shlaer-mellor-users: -------------------------------------------------------------------- In response to Peter and HS: I agree with HS in that you both are describing the same thing. However, Peter is also describing what is in the SW Architecture domain (or Architecture domain or Model Compiler domain, what ever it called these days)...things like mechanisms, archetypes and translations rules. The way I think of RD is as follows: Since client domains place requirements on service domains, it makes sense to proceed with analysis work from the Application down through the service domains..etc.. I call this working from the top to the bottom of the domain chart. As with any good recursive function there will be a point where a domain is reached that supplies the required service of the client(s) domain (no analysis is required). This usually occurs at the Architeture domain or at the Implementation domains. So.....what happens next...?? Well, we can now start to implement high level client domains though the lower level service domains (this is what Peter was describing -- this is the translation step). The logical way to do this is from the bottom up on the domain,since the service must exist before the client domain can use it. When one sits down and contemplates this one can draw an analogy with recursive functions. Recursive functions keep calling lower level functions (usually the same function) with new parameter data, until the function can solve a part of the problem, at which time the previously called functions are backed out returning sub solutions to build the complete solution. If we can think of analysis as the first part of recursion, then applying the design is the second part of recursion, thus the term Recursive Design :) . Hope this helps rather than hinders.... ---------- From: owner-shlaer-mellor-users@projtech.com on behalf of Peter J. Fontana Sent: Wednesday, June 04, 1997 9:36 AM To: mainetti@visionnaire.com.br; shlaer-mellor-users@projtech.com Subject: Re: (SMU) Recursive Design peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- Sergio - Let me apologize for this on-line community - your question has been somewhat neglected. But answering an inquiry of such a daunting scope (*just* RD is still huge) is not something that you can just crank off quickly. At 01:16 PM 6/2/97 -0300, shlaer-mellor-users@projtech.com wrote: >"Sergio Mainetti Jr." writes to shlaer-mellor-users: > ... > If nobody answered, let me decrease the scope of the >subjects. What I'm really interested is Recursive Design. >I remember reading articles from Steve Mellor in 1994-95 in >Object Magazine (or Journal of Object Oriented Programming, >or ROAD, I don't remember exactly which one) and it was mentioned >that he was writting a book about Recursive Design to be >published soon. Does anyone know anything about such a book ? You can contact Steve directly through steve@projtech.com, but the book is not yet available. Actually, its availability is the subject of much speculation outside of Project Technology (Sally and Steve's company - and the host for this email forum) - Steve (or anyone else) - do you have an official answer for Sergio? > Is there anyplace >on the Web where we can go to obtain more information about this ? Browse www.projtech.com and download recent papers on bridges and synchronous services. They are taken from the work going into the book. Kennedy-Carter also has papers on these topics at www.kc.com. >Actually I've been hearing about Recursive Design for quite >some time (since those articles in 94-95) but I haven't seen >any formal description, or anyone really using. > ... > Are there companies >using Recursive Design ? Are there real case studies about this ? The book will be the closest thing to a "formal description", but there are quite a few projects really using it. I speculate that at least 75% of the projects who *seriously* apply this method today (excluding dabblers, experimenters, etc.) use some form of Recursive Design. I wouldn't be surprised if this fraction is actually over 95%. Consequently, there is some variation in how it is practiced. However, the core of the approach is relatively consistent, with the core concepts being very much shared, and different approaches varying in some of the details and levels of tool support. Brief summary: one of the most significant characteristics of Shlaer-Mellor OOA (not considering RD) - one that substantially distinguishes it from all other flavors of "OOA" - is the concept of Domain separation. The separation of a system into separate subject matters is the fundamental source of power behind virtually all of the strategic benefits of SM-OOA. These benefits include simple and orthogonal (and therefor elegant and powerful) constructs within domains, the separation of implementation from analysis and its family of benefits, and the ability to translate the analysis for a domain into its implementation via RD. Let me say that again: "SEPARATION OF SUBJECT MATTERS IS WHAT MAKES RD POSSIBLE". Conversly, the degree to which you are successful with SM-OOA/RD is significantly affected by the degree to which you are able to maintain domain "purity" - how well did you enforce the separation of subject matters. OK - what does all this have to do with RD? RD involves 3 basic steps: 1) the architectural design of the system: how all the pieces will fit together, and what mechanisms they use to run 2) the specification of what the implementatin form looks like for elements of the system modeled in OOA - this specification is sometimes captured in a set of templates or "archetypes" 3) the conversion of the semantic information for a domain - expressed in SM-OOA notation - into a set implementation components. Obviously if the templates from step 2) can be fed into a translation engine that reads your CASE database, this step can be fully automated. So why is it called "Recursive" design? You can express the implementation of a domain in terms of its servers (the domains it relies on). This is RD - but what do you call what "everyone else" does? The "traditional" approach is sometimes called "elaboration". At it's most rigorous, elaboration is the specification of analysis in some form, followed by a design phase where the analysis actually is manually changed (therefore eroded) into design, and design is again manually converted/eroded into implementation. Most commonly, elaboration is just hacking code. In RD, the analysis stands pure, and is the actual "source" for the system - the design is separate and disjoint (subject matter separation), and the implementation is a product of two. Example (this is an old P.T. metaphor): cookie dough is the Analysis, cookie cutters are the Design, and cookies are the Implementation. You don't get to use cookie cutters in Elaboration - each cookie is tediously shaped, one after the other, each cookie a little different from the last. With RD, the cookie cutter is employed to greatly increase quality, productivity (in the long term), and uniformity. I hopes this answers enough of your questions. RD is not new, nor is it an experiment. OOA/RD has been used for many years to produce solutions for some of the most demanding software challenges around: technical and embedded applications, including medical, avionics and telecom. It is the closest thing to rigorous *Software Engineering* that I am aware of. More questions are certainly welcome - but please try to make the scope a little more narrow - thanks. ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice/fax: +01 508-384-1392 | peterf@pathfindersol.com | ____________________________________________________| Subject: Re: (SMU) Recursive Design peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 11:54 AM 6/5/97 -0700, shlaer-mellor-users@projtech.com wrote: >"Ken Cook" writes to shlaer-mellor-users: >-------------------------------------------------------------------- >My perception of "Recursive Design" from the PT course was: > > applyOOA( domain ) > { > ...produce Object Model, ...state ... action specification Yes - you have the accurately summarized the notion of iterating over the domains recursively, but it is the "Design" element of the term that always bothered me. See - your recursive function does much more than design. This is why I "preach" RD the way I posted - recursively applying design across already analyzed domains to produce their implementation. You don't have to have completed any implementation to complete your analysis (in some circumstances). > It seems "Iterative Design" would >have been just as accurate, though, IMO, neither "Iterative" nor >"Recursive" >really capture the full power of the method or the technology. Agreed. >We say "The model is the code". Yes - this is *the point* - the source code for your system is your set of OOA models - not the resulting implementation. ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice/fax: +01 508-384-1392 | peterf@pathfindersol.com | ____________________________________________________| Subject: (SMU) Minimum iteration rates Michael Hendry writes to shlaer-mellor-users: -------------------------------------------------------------------- Hi everyone, I hope I can ask this question clearly. But first a little background. We produce embedded control systems. In the past, functions were time sliced by executing them at specified iteration rates through a cyclic scheduler. Currently, during analysis we find that we have objects that we feel are required to execute processes at some minimum number of times per second to meet timing requirements. We meet this requirement in the analysis by having the object set a timer to generate an event at the next time period. (The architecture is required to initially start the timer.) My concern about this approach is that it adds attributes to the objects. (for the time period and the timer id) It also adds state actions to set the timer and creates the need for many timer instances. However, minimum iteration rates seems to be something that needs to be captured somewhere. My question: Is this a requirement of the application domain or architecture domain? If architecture domain, where in the method should this be documented? A bridge description perhaps? Thanks for your opinions. Michael J. Hendry Sundstrand Aerospace Rockford, IL MJHendry@snds.com Subject: Re: (SMU) Minimum iteration rates David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: -------------------------------------------------------------------- Michael Hendry wrote > My question: Is this a requirement of the application domain or > architecture domain? If architecture domain, where in the > method should this be documented? A bridge description > perhaps? It doesn't seem like a requirement of the application domain. Since you are doing an embedded system with fairly hard hard real time requirements, you need to construct it in such a way that these timing requirements are met. This is a generic statement about hard real time systems, not your application. The domain in which you analyse the construction of a system to meet timing requirements is the architecture (or possibly onle of many architectural domains). You need a domain that handles these timing issues. The application domain must be analysed to allow the timing domain to do its stuff. The simplest way to do this is via events generated from external inputs (experience tells us that an event called "Clock Edge" is a bad idea in an application domains, so make sure its a meaningful event). So now you just need to specifiy the timings of the incoming events. By having the timer generation in a separate domain you are able to have an object that specifies the required timers. If you use a meta-bridge then you can specify the event to generate as an attribute of this object - otherwise you'll need to indirect via wormholes. The population of the object can be provided in many ways. The simplest would be a table of event-to-generate and frequency (as a simple ascii file) but you could use coloration of the application domain to tag the events with their frequencies. As an asside, I don't know anything about your application; however, if those time-critical processes are just polling device status or similar then that probably doesn't belong in the application. The application events should be generated when a specific condition is detected and the application will then respond to that event. This greatly simplifies the application state models and allows you to think in terms of lifecycles instead of behaviour. Dave -- David P. Whipp. Not speaking for: ------------------------------------------------------- G.E.C. Plessey Due to transcription and transmission errors, the views Semiconductors expressed here may not reflect even my own opinions! Subject: RE: (SMU) Minimum iteration rates "David Wanner" writes to shlaer-mellor-users: -------------------------------------------------------------------- In response to the questions asked by Michael Hendry: "Currently, during analysis we find that we have objects that we feel are required to execute processes at some minimum number of times per second to meet timing requirements." This statement interests me a bit. I think a little more information is needed in order to answer your question. Ask yourself the following questions: Does my system really need to identify processes within objects that require minimum execution or are there a series of objects with states and actions that require minimum execution (e.g. a thread of control idea)? Is the minimum nature of the processes, being throttled by any tight control loop within the system? In other word, is there a critical loop in your system that has some known bound time to execute (like from n to n+m nanoseconds), and other non critical work needs to be done during times when the critical loop isn't doing work? If your answers to these questions are yes, then it may be that a non object-oriented architecture is needed for your system. Sometimes in real-time systems with tight critical loops that demand large execution times another type of architecture is needed, like possibly a thread of control architecture. If you were to build a thread of control architecture then the concept would be documented in the architecture specification documents, the mechanisms, the templates and translation rules (e.g. how information from the bridge hits the architect). Realize, that are different "types" of architectures, perhaps a different type might meet your needs better. "We meet this requirement in the analysis by having the object set a timer to generate an event at the next time period. (The architecture is required to initially start the timer.)" I have seen this type of use before in lower level communication systems (level 2 and 3 of ISO/OSI). In one respect you are bringing performance information into the analysis model (e.g. -- the need to execute processes at a minimum number of times), however, this may be justified by the type of problem space you are working in. In the case of lower level communication systems, polling and error avoidance is part of the problem space and manifests itself as the requirement to process certain code segments several times per specified time period to ensure the quality of interconnections. In the case of some topologies, this polling and error avoidance has to occur even if the link or connection is in use by a higher level entity. These kinds of systems usually define an object or a group of objects that specifies critical time intervals that sequences of state models use to synchronize themselves to. So the analysis just contains the nature of the problem space. OOPS, getting a little to wordy, will sign-off now.... ---------- From: owner-shlaer-mellor-users@projtech.com on behalf of Michael Hendry Sent: Friday, June 06, 1997 9:01 AM To: shlaer-mellor-users@projtech.com Subject: (SMU) Minimum iteration rates Michael Hendry writes to shlaer-mellor-users: -------------------------------------------------------------------- Hi everyone, I hope I can ask this question clearly. But first a little background. We produce embedded control systems. In the past, functions were time sliced by executing them at specified iteration rates through a cyclic scheduler. Currently, during analysis we find that we have objects that we feel are required to execute processes at some minimum number of times per second to meet timing requirements. We meet this requirement in the analysis by having the object set a timer to generate an event at the next time period. (The architecture is required to initially start the timer.) My concern about this approach is that it adds attributes to the objects. (for the time period and the timer id) It also adds state actions to set the timer and creates the need for many timer instances. However, minimum iteration rates seems to be something that needs to be captured somewhere. My question: Is this a requirement of the application domain or architecture domain? If architecture domain, where in the method should this be documented? A bridge description perhaps? Thanks for your opinions. Michael J. Hendry Sundstrand Aerospace Rockford, IL MJHendry@snds.com Subject: Re: (SMU) Minimum iteration rates lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Hendry... Basically I agree with everything Dave Whipp mentioned. This is just a minor amplification. > Currently, during analysis we find that we have objects that we > feel are required to execute processes at some minimum > number of times per second to meet timing requirements. We > meet this requirement in the analysis by having the object set a > timer to generate an event at the next time period. (The > architecture is required to initially start the timer.) > > My concern about this approach is that it adds attributes to the > objects. (for the time period and the timer id) It also adds state > actions to set the timer and creates the need for many timer > instances. However, minimum iteration rates seems to be > something that needs to be captured somewhere. I see nothing inherently wrong with adding the iteration rates as attributes, especially if they are different for various objects. However, I would see this more as a specification that is communicated to some other domain. I agree with Whipp that the "other domain" is probably the Architecture since this problem seems to be more generic than a specific application. A viable alternative, though, might be to use a separate, low level implementation domain to handle the timers and associated processing. Your application might request that timer instances be set up but after that it would only see the events generated from that domain. At the very minimum this would remove the clutter you object to from the application and it could be implemented seamlessly as if it were part of the architecture. Depending upon your application, such a domain might provide more elegant services. If there is some special activity associated with the time cycles (e.g., polling, data refresh, etc.) then this might also be abstracted to such a domain. FOr example, instead of generating an event that causes a register to be read by the application, the domain might read the register and issue an event with the data. I am pushing the idea of a separate implementation domain for two situations. The first is to separate this particular functionality from the architecture. In addition to the aesthetic appeal of modularization, this might be useful if the timing issues are common to only a subset of your application where you might otherwise use the same Architecture. The second might arise if you want to use the same software for different hardware and you can demote some interface functionality from the application to the domain in addition to the timing stuff. [General aside: Steve pointed out to me the I misspelled "Drano" in my signoff. Alas, as many of you have no doubt noted, spelling is not a major forte of mine.] -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) Looking for A Good Tool Allen Theobald writes to shlaer-mellor-users: -------------------------------------------------------------------- Greetings, I'm looking for a tool that supports formal specification and verification in software engineering. Specifically, i'm looking for some tool that will allow me to specify the *functional* and *timing* behavior required of a software system. Ideally, the tool would allow the user to construct and run an executable version of a software specification, and provide some verification of the specification. >From what i've seen, current tools generally support only the coding phase and do not support the specification of functional and timing requirements. I've been a S-M accolyte for some years now. I've always done my S-M by hand, but never with a tool. Does anyone know of a tool that fits the above criteria? Kind Regards, Allen Theobald Subject: (SMU) Equivalence Class Definition Jay Case writes to shlaer-mellor-users: -------------------------------------------------------------------- Anybody out there have a nice crisp formal definition of an "equivalence class"? One working thought is "That funky Voodoo the architecture do as part of its evil implementation of relationships (typically involving smoke and mirrors on both sides)". However, this is probably lacking in sufficient rigor... Before any Anti-Architecture zealot chimes in, please note the term is used in the Multiple Assigners (section 7.4) discussion of OOA96. :) Thanks, Jay Case Tellabs Operations, Inc. Subject: RE: (SMU) Equivalence Class Definition "John Harby" writes to shlaer-mellor-users: -------------------------------------------------------------------- An equivalence relation is a binary relation between a set with an operator and itself that is reflexive, symmetric and transitive. For example, the integers under addition as a set with congruence mod a prime as the relation. (So we say a = b iff a mod p = b mod p). The equivalence class of a given element is all other elements in the set that are equivalent to that element (under the defined relation). Thus, if p = 7 is the prime, then {3,10,17,24, ...} would be the equivalence class of 3. This is a pure mathematical definition and may not be the one you are seeking, but I have found it to be useful in modeling systems that use overloaded operators. ---------- From: owner-shlaer-mellor-users@projtech.com on behalf of Jay Case Sent: Monday, June 16, 1997 12:10 PM To: shlaer-mellor-users@projtech.com Subject: (SMU) Equivalence Class Definition Jay Case writes to shlaer-mellor-users: -------------------------------------------------------------------- Anybody out there have a nice crisp formal definition of an "equivalence class"? One working thought is "That funky Voodoo the architecture do as part of its evil implementation of relationships (typically involving smoke and mirrors on both sides)". However, this is probably lacking in sufficient rigor... Before any Anti-Architecture zealot chimes in, please note the term is used in the Multiple Assigners (section 7.4) discussion of OOA96. :) Thanks, Jay Case Tellabs Operations, Inc. Subject: (SMU) Re: Equivalence Class Definition TGett@aol.com writes to shlaer-mellor-users: -------------------------------------------------------------------- In a message dated 97-06-17 10:02:37 EDT, you write: > Jay Case writes to shlaer-mellor-users: > - -------------------------------------------------------------------- > > Anybody out there have a nice crisp formal definition > of an "equivalence class"? > > One working thought is "That funky Voodoo the architecture > do as part of its evil implementation of relationships > (typically involving smoke and mirrors on both sides)". > However, this is probably lacking in sufficient rigor... > > Before any Anti-Architecture zealot chimes in, please > note the term is used in the Multiple Assigners (section 7.4) > discussion of OOA96. :) > > Thanks, > Jay Case > Tellabs Operations, Inc. > > ------------------------------ > The term "Equivalence Class" I feel certain comes from the concept of an equivalence class(!) -- something that does indeed have a nice crisp formal definition in the discipline of abstract algebra. The concept is one that Sally, mathematician that she is, very neatly applied in a proper manner in the S-M method. I don't have my old textbook handy, so I unfortunately am not able to be immediately forthcoming with that good wording. Check your math reference material. You math guys out there feel free to jump in here anytime now and help on this.... Pax, Terry Gett Subject: Re: (SMU) Equivalence Class Definition lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Case... > Anybody out there have a nice crisp formal definition > of an "equivalence class"? > > Before any Anti-Architecture zealot chimes in, please > note the term is used in the Multiple Assigners (section 7.4) > discussion of OOA96. :) I agree that Harby's description of the underlying mechanism is the underlying principle. Just to clarify, in the OOA96 example the Assigner could be regarded as the operation while the Customer and Clerk are the equivalence classes. The basis of their equivalence is made specific in the IM through the Department class to which they are both unambiguously related. There is another area where equivalence classes are expressed explicitly in an OOA: derived attributes. The formula for deriving the attribute value is the operation and the relevant objects are the equivalence classes. Note that there is a specific context to equivalence classes and it is not impossible for a given object to be an equivalence class in multiple contexts (i.e., for multiple operations involving different objects -- such as having two assigners for relationships with two different objects). One can also argue that equivalence classes appear implicitly in the OOA as counterpart objects between domains. In this situation there is usually some sort of equivalence operation that is implemented in the bridge that allows actions in one domain to have effects in the other domain. That is, the underlying rigor of the equivalence relationship governs what the bridge can and cannot do. Greg Eakman's paper at the recent E-SMUG on mapping OOA constructs across domains to automatically generate bridges was also an example of the use of equivalence classes. For example, if an attribute in one domain maps to an event in the other domain, then one can have the write accessor in the first domain generate the event in the second domain through judicious application of bridge glue code. The attribute and event are equivalence classes with the bridge representing the operation. The formalism of equivalence classes goes a long way towards allowing automation generation of the bridge's glue code based upon the OOA of OOA in combination with the specific application OOAs. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: re:(SMU) Equivalence Class Definition? "Paul Higham" writes to shlaer-mellor-users: -------------------------------------------------------------------- An equivalence class is well-defined mathematical concept, to provide the definition properly requires another definition first, i.e., that of an equivalence relation: Let R be a binary relation on a set S, i.e., R is a subset of S X S, the cartesian product of S with itself, i.e., R is a set of ordered pairs (x,y) where x and y belong to S. We write xRy if (x,y) belongs to R, i.e., if x is related to y by the the relation R. R is said to be an equivalence relation if it satisfies the following three properties: REFLEXIVE: xRx, i.e., every element is equivalent to itself SYMMETRIC: if xRy then yRx TRANSITIVE: if xRy and yRz, then xRz Now the equivalence class of x, denoted [x] or [x] , is the R set of all elements in S that are equivalent to x, or more formally [x] = {y in S, such that xRy} It can be shown fairly easily that the set of equivalence classes of R form a partition of the set S, i.e., the union of all the equivalence classes is S and every pair of equivalence classes are either equal or disjoint. Is this crisp and formal enough? Paul Higham NORTEL Subject: RE: (SMU) Equivalence Class Definition Sally Shlaer writes to shlaer-mellor-users: -------------------------------------------------------------------- At 12:59 AM 6/17/97 >"John Harby" writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >An equivalence relation is a binary relation between a set with an operator >and itself that is reflexive, symmetric and transitive. For example, the >integers >under addition as a set with congruence mod a prime as the relation. (So we >say >a = b iff a mod p = b mod p). The equivalence class of a given element is all >other >elements in the set that are equivalent to that element (under the defined >relation). >Thus, if p = 7 is the prime, then {3,10,17,24, ...} would be the equivalence >class of >3. Yes, the mathematical definition of equivalence class as given here and also by Paul Higham is just what we intended. What has not been made so clear is what is the _relation_. In the OOA report (and elsewhere, I am sure), the relation is "can be replaced by", which is transitive, reflexive, and symmetric. So, connecting to Paul's posting, R is "can be replaced by" (or "is interchangeable with") and S is the set of instances of some OOA object. FWIW, a 1-M relationship always partitions the instances on the many side into equivalence classes. Think of our standard Dog-Dog Owner example: The "owns" relationship partitions the dogs into disjoint subsets according to owner. (We sometimes call these subsets "dog packs".) I'm not sure how useful it is to know this, but it does have a nice air of elegance, don't you think? Best regards, Sally Subject: RE: (SMU) Equivalence Class Definition "John Harby" writes to shlaer-mellor-users: -------------------------------------------------------------------- I see this as extremely interesting from the theoretical standpoint. I am personally into researching the use of object models to generate topologies of one sort or another and then attempting to derive relations with domains (e.g. Topology of Cones in Economics, etc.). Additional views of any mathematical findings are always of immense assistance. Thanks for the information. ---------- From: owner-shlaer-mellor-users@projtech.com on behalf of Sally Shlaer Sent: Wednesday, June 18, 1997 5:35 PM To: shlaer-mellor-users@projtech.com Subject: RE: (SMU) Equivalence Class Definition Sally Shlaer writes to shlaer-mellor-users: -------------------------------------------------------------------- Yes, the mathematical definition of equivalence class as given here and also by Paul Higham is just what we intended. What has not been made so clear is what is the _relation_. In the OOA report (and elsewhere, I am sure), the relation is "can be replaced by", which is transitive, reflexive, and symmetric. So, connecting to Paul's posting, R is "can be replaced by" (or "is interchangeable with") and S is the set of instances of some OOA object. FWIW, a 1-M relationship always partitions the instances on the many side into equivalence classes. Think of our standard Dog-Dog Owner example: The "owns" relationship partitions the dogs into disjoint subsets according to owner. (We sometimes call these subsets "dog packs".) I'm not sure how useful it is to know this, but it does have a nice air of elegance, don't you think? Best regards, Sally 'archive.9707' -- Subject: Re: (SMU) Equivalence Class Definition Neil Lang writes to shlaer-mellor-users: -------------------------------------------------------------------- At 02:10 PM 6/16/97 -0500, you wrote: >Jay Case writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >Anybody out there have a nice crisp formal definition >of an "equivalence class"? > >One working thought is "That funky Voodoo the architecture >do as part of its evil implementation of relationships >(typically involving smoke and mirrors on both sides)". >However, this is probably lacking in sufficient rigor... > >Before any Anti-Architecture zealot chimes in, please >note the term is used in the Multiple Assigners (section 7.4) >discussion of OOA96. :) As the author of the above-mentioned section in the OOA96 report, let me add my $.02 worth to this discussion. The term equivalence class as used in the section on Assigners and in other parts of PT's training material refers to the partitioning of something (usually instances of an object) into mutually exclusive subsets. (This informal usage is consistent with the formal definitions given by others (especially Paul Higham) in subsequent postings.) For instance the instances of an object DOG can be partitioned in equivalence classes based the attribute breed. Also as Sally points out the DOGs can be partitioned by the instances of DOG OWNER where the DOG OWNER/DOG relationship is 1:m We didn't intend to convey more than that simple concept. Hope that helps Neil ---------------------------------------------------------------------- Neil Lang nlang@projtech.com Project Technology, Inc. 510-567-0255 x623 10940 Bigge Street San Leandro, CA 94577 http://www.projtech.com ---------------------------------------------------------------------- Subject: Re: (SMU) Equivalence Class Definition lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Lang... > As the author of the above-mentioned section in the OOA96 report, > let me add my $.02 worth to this discussion. The term equivalence class > as used in the section on Assigners and in other parts of PT's training > material refers to the partitioning of something (usually instances of > an object) into mutually exclusive subsets. > (This informal usage is consistent with > the formal definitions given by others (especially Paul Higham) > in subsequent postings.) For instance the instances of an object DOG > can be partitioned in equivalence classes based the attribute breed. Also > as Sally points out the DOGs can be partitioned by the instances of > DOG OWNER where the DOG OWNER/DOG relationship is 1:m > > We didn't intend to convey more than that simple concept. How sad! I had hoped that they were a bit more ubiquitous than that in the methodology. For example, I assumed they applied to derived attributes in that the set of instances involved in the calculation were equivalence classes relative a particular calculation. If so, this would place some restrictions on derived attributes. Using the tried and true Density = f(Mass, Volume) example, the binary nature of equivalence classes would preclude Mass be an attribute of one object, Volume being an attribute of a second and Density an attribute of a third. However, as I read your comment equivalence classes would not apply here and one could have Mass and Volume in different objects when deriving Density in a third. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) Syncronous event communications Paul Coene writes to shlaer-mellor-users: -------------------------------------------------------------------- Folks, Let us say that we have an object called 'X'. Object 'X' has a pretty simple lifecycle, involving little more than creation, a stable state, and deletion states. Now, lets say that multiple other objects in our domain may generate and event or events which should cause a 'Delete' event to be sent to object X. Let us also say that in each case, the object sending the 'Delete' event must wait on a 'Deleted' event back before moving on to another state. How does the state action for model X's "Deleting" state know where to send the 'Deleted' event? We're not allowed (at least in bridgepoint) to send an instance id as supplemental data with the "Delete" event. We can send an identifying attribute to tell us which instance the caller is, but then how would object X know which object to search for that attribute? I don't think object X should broadcast the event to all that might be concerned, because there could be multiple outstanding requests from different sources. This seems like a simple issue, but I'll be darned if I can solve it (short of eliminating the state models and using a method/syncronous service/Transformer instead). -- Drool WWW: http://www.servtech.com/public/drool ARPA: drool@servtech.com Cindy Crawford _is_ God drool@questra.com Subject: Re: (SMU) Syncronous event communications Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- Paul Coene wrote: > Let us say that we have an object called 'X'. Object 'X' has a pretty > simple lifecycle, involving little more than creation, a stable state, > and deletion states. > > Now, lets say that multiple other objects in our domain may generate and > event or events which should cause a 'Delete' event to be sent to object > X. Let us also say that in each case, the object sending the 'Delete' > event must wait on a 'Deleted' event back before moving on to another > state > > How does the state action for model X's "Deleting" state know where to > send the 'Deleted' event? We're not allowed (at least in bridgepoint) > to send an instance id as supplemental data with the "Delete" event. We > can send an identifying attribute to tell us which instance the caller > is, but then how would object X know which object to search for that > attribute? The situation you describe sounds like you are modelling in terms of behaviour, not lifecycles. You may have some domain pollution. A critical examination of a model usually allows you to eliminate these situations. But lets say that you can't eliminate it. Then how do we solve the problem? Well, one simple solution is the define the concept of "things that might try to delete X". This is a concept; and concepts can be objects. So we have an object: "Deleter of X" - you should be able to find a more application oriented name. If you truely don't have any domain pollution (or behavioural bias) then you should find that this is a natural object within your subject matter. The "Deleter of X" object can be a passive supertype of all objects that may want to delete X. Its identifier can form a secondary identifer of its subtypes. This identifier would be passed as supplemental data on the "delete-X" event and the "X-deleted" reply event can be delivered polymorphically to any object that might want to delete X. There is another problem that you will come across - if two objects send X a "delete" event, and both wait for a reply then one of the "delete" events will arive first, deleting X. The second event will not be delivered, so no reply will be sent back, and the system could lock up. You have a synchronous protocol so you may decide to use sychronous services (though that isn't the only solution). Dave, Not speaking for GPS. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Tamerton Road, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com For embedded Systems Support mailto:armapps@gpsemi.com Subject: Re: (SMU) Syncronous event communications lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Coene, Regarding asynchronous deletes: First, I would question whether you really want to do asynchronous deletes internally in the domain. Anything that you do in the delete action can be done in a synchronous service that is associated with the object. [If you have multiple delete states doing different things, as your message implied, then you could have multiple synchronous services.] The synchronous services should be able to accept the instance handle of the deletee; since it is synchronous the identity of the deleter is not relevant. Using synchronous creates and deletes removes potential temporal problems with accesses to the instance, such as your case where there are potentially multiple objects that might place multiple delete events on the queue, and reduces the analyst's concerns. Thus the deleter can check for existence and do the delete within the temporal context of a single action. Since most domains are internally synchronous because it is convenient to make distributed or otherwise asynchronous boundaries coincide with domain boundaries, the asynchronous representation entails unnecessary complications. This, of course, is not possible for a more complex situation where the orignal "delete" event actually triggers some asynchoronous activity (i.e., the deletee requires another transition before getting to the actual delete state). In that case I would suggest instantiating a temporary doubly-conditional relationship between deletee and deleter when the delete event is issued. Then the deletee's delete state can check each such relationship to see if it is active. If so, the approriate response event is issued, the relationship is deinstantiated, and the deletee deletes itself. Note that this can also solve the problem of queued multiple deletes from different objects to the same instance with a little extra work to count the incoming delete events until they match the active relationship count before issuing the responses and doing the actual delete. [Usually processing an event to a nonexistent instance does bad things so you don't want to delete when the first event shows up.] The relationship makes the state actions simpler but it has the disadvantage of cluttering the IM. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Syncronous event communications Paul Coene writes to shlaer-mellor-users: -------------------------------------------------------------------- Dave Whipp wrote: > The situation you describe sounds like you are modelling in terms of > behaviour, not lifecycles. Can you tell me the difference? The object really has little more than a live/die lifecycle. There is a little bit of interesting stuff upoin delete, as the object needs to check a few things before allowing deletion. > You may have some domain pollution. A > critical examination of a model usually allows you to eliminate these > situations. I'd like to know if I have this, but I don't think I do. It is one of my domains key activities to collect object 'X' and track its relationships. I think deletion of object 'X' is central and core. > But lets say that you can't eliminate it. Then how do we solve the > problem? Well, one simple solution is the define the concept of > "things that might try to delete X". This is a concept; and concepts > can be objects. So we have an object: "Deleter of X" - you should > be able to find a more application oriented name. If you truely don't > have any domain pollution (or behavioural bias) then you should find > that this is a natural object within your subject matter. > > The "Deleter of X" object can be a passive supertype of all objects > that may want to delete X. Its identifier can form a secondary identifer > of its subtypes. This identifier would be passed as supplemental data > on the "delete-X" event and the "X-deleted" reply event can be delivered > polymorphically to any object that might want to delete X. I've had a couple folks suggest this. I can certainly use this technique, but adding this object seems to me akin to modelling the solution domain, not the problem space. Would not the new object be nothing more than a functional based object? I think object 'X' should know full well how to delete itself without a 'X deleter' functional object. I would love to know full well how to do it ;) > There is another problem that you will come across - if two objects > send X a "delete" event, and both wait for a reply then one of the > "delete" events will arive first, deleting X. The second event will > not be delivered, so no reply will be sent back, and the system could > lock up. You have a synchronous protocol so you may decide to use > sychronous services (though that isn't the only solution). UGH. I think I've intentioanlly blocked this issue out, because state models suck at the concept of multiple accesses in general. Two gui's accessing the same object in the same service domain simultaeneously exibits the same problem, for nearly every state model. I have been assuming that the architecture will somehow deal with race-condition issues, locking, etc. Bad assumption? -- Drool WWW: http://www.servtech.com/public/drool ARPA: drool@servtech.com Cindy Crawford _is_ God drool@questra.com Subject: Re: (SMU) Syncronous event communications peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 09:35 AM 7/24/97 -0400, shlaer-mellor-users@projtech.com wrote: >lahman writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >Responding to Coene, > >Regarding asynchronous deletes: > >First, I would question whether you really want to do asynchronous >deletes internally in the domain. Anything that you do in the delete >action can be done in a synchronous service that is associated with the >object. This is the most straightforward approach. Of course the original poster was looking for a solution in the context of BridgePoint simulation - and I don't believe synchronous services are supported. > ... >This, of course, is not possible for a more complex situation where the >orignal "delete" event actually triggers some asynchoronous activity >(i.e., the deletee requires another transition before getting to the >actual delete state). In that case I would suggest instantiating a >temporary doubly-conditional relationship between deletee and deleter >when the delete event is issued. Actually to be workable, this approach would require all objects that would initiate the delete to be subtypes of a common supertype. David Whipp also covered this. Another good idea... I'd like to add one more alternative - Indirect Events. This topic has already been covered somewhat in this forum during the 3/97 - 4/97 timeframe. With some straightforward architecture extensions, you can separate the creation of an event from its sending (when it is queued). This requires architecture services to create an event given a label and event data item values, and to send an event thusly created. You must also be able to pass around the event (or a handle to it) in event data, and save it in an attribute value. Given that support, then the resolution to the original problem is straightforward. Objects sending delete events to object X would also send along a "delete complete" event instance. Once X does the delete, then it sends the delete complete" event instance. It goes back to whoever created it. IMPORTANT NOTES: - H.S.'s original suggestion to make the delete a synchronous service is the best answer. If your off-the-shelf architecture and/or sim support doesn't give you synchronous services, then fix it or get a different one. - Indirect events are a very powerful capability - but can obscure the true nature of your event flow through your system if overused. They should be used sparingly. Do not use indirect events instead of modeling correctly. ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice/fax: +01 508-384-1392 | peterf@pathfindersol.com | ____________________________________________________| Subject: Re: (SMU) Syncronous event communications Paul Coene writes to shlaer-mellor-users: -------------------------------------------------------------------- Yesterday I posted a question regarding how an object, X, could respond to an event that may have been generated by one of many other objects. As I said then, the identity of the caller cannot be cleanly passed with the event: - instance handles are not allowed - a unique ID does not tell us which source object to search - a hard-coded string could be passes to indicate the source class, but that seems lame In a discussion of this issue with a non-shaler/mellor colleague, he suggested that the object that originates the event could poll for the result of the event. At first, I didn't like this, but it is growing on me. Would it be a bad application of a timer object to: - send a delete event to object X. - set a timer - when the timer expires, look to see if object X was deleted - if so, go on. - if not, set the timer again. This removes all knowledge from object X regarding who called, but allows the client object to perform activities based on the completion of the event sent. My issue is really a very common case, and I'm suprised that many of the replies I've received haven't considered it so. Lets say that an object (A) is in a one to many relatrionship with object B. (one A relates to many Bs unconditionally). When object A gets a delete event, it cannot delete itself until all the instances of object B are deleted. If it does, the model is unstable(bridgepoint would barf in the simulator). If object B uses a delete event to intiate deletion, and object A sends those events, object A must either perform a wait/check loop, or wait for an event back from object A that indicates deletion. This is precisely my situation, extended by multiple other objects like object A that may request a deletion of object B. I cannot have object B send an event back when done, because I don't know which related object sent the delete event. If the client uses a send/wait/check loop, the problem is resolved. I like the idea. Opinions? -- Drool WWW: http://www.servtech.com/public/drool ARPA: drool@servtech.com Cindy Crawford _is_ God drool@questra.com Subject: Re: (SMU) Syncronous event communications lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Fontana... > >Regarding asynchronous deletes: > This is the most straightforward approach. Of course the original poster > was looking for a solution in the context of BridgePoint simulation - and I > don't believe synchronous services are supported. Maybe not explicitly associated with an object, but I thought it did have the notion of synchronous services. In particular, I thought it used them for bridge implementations. If not, it should. Regarding instantiating relationships. > Actually to be workable, this approach would require all objects that would > initiate the delete to be subtypes of a common supertype. David Whipp also > covered this. Another good idea... I don't think so. R1 R2 A <------> B <-------> C (ignoring other relations provide sense) c c c c is legal without A and C being subtypes of some common supertype. R1 and R2 are independent relationships that *coincidently* are both concerned with deleting B. The crucial activities are in B's delete state that checks which relationships are active and whether all the events have been received yet (if > 1 relationship is active). For example, this should work fine if we substitute B => Kitten A => Odious Sibling (to Owner of Kitten => R3 Kitten, not shown) C => Itinerant Psycho and the relationships are: R1 = R2 = places in garbage disposal / is whacked by even if there were no direct relationship between Itinerant Psycho and Odious Sibling in the OOA (i.e., they are not related by blood, are not members of the same coven, etc.). -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Syncronous event communications "Mark Murray" writes to shlaer-mellor-users: -------------------------------------------------------------------- > Responding to Coene, > > Regarding asynchronous deletes: > > First, I would question whether you really want to do asynchronous > deletes internally in the domain. Anything that you do in the delete > action can be done in a synchronous service that is associated with the > object. [If you have multiple delete states doing different things, as > your message implied, then you could have multiple synchronous > services.] The synchronous services should be able to accept the > instance handle of the deletee; since it is synchronous the identity of > the deleter is not relevant. I am under the impression that synchronous deletes are not always a good thing. On a multi-processor system, it could be possible for a state of an object to be running whilst somebody else synchronously deletes it underneath. Could this be guarded against ? Mark Murray Subject: Re: (SMU) Syncronous event communications peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 12:40 PM 7/24/97 -0400, shlaer-mellor-users@projtech.com wrote: >Paul Coene writes to shlaer-mellor-users: >-------------------------------------------------------------------- >> There is another problem that you will come across - if two objects >> send X a "delete" event, and both wait for a reply then one of the >> "delete" events will arive first, deleting X. The second event will >> not be delivered, so no reply will be sent back, and the system could >> lock up. You have a synchronous protocol so you may decide to use >> sychronous services (though that isn't the only solution). > >UGH. I think I've intentioanlly blocked this issue out, because state >models suck at the concept of multiple accesses in general. Two gui's >accessing the same object in the same service domain simultaeneously >exibits the same problem, for nearly every state model. I have been >assuming that the architecture will somehow deal with race-condition >issues, locking, etc. > >Bad assumption? - yeah. You face anaylsis issues: you seem to have captured incomplete information in your problem space - the architecture can't compensate for that, or guess what you want. If you had synchronous services for the delete, and used an assigner to resolve and contention for this simultaneous access of the same object (as you illustrate in the case of two GUI (tasks-?)), then you would not have a race condition. TIHS IS AN ANALYSIS ISSUE. > I think I've intentioanlly blocked this issue out, because state >models suck at the concept of multiple accesses in general. I disagree - you just need to train yourself to resolve these issues at a higher level than simply at a single state model. They reflect incomplete abstractions in the domain. Given you aren't sure about your domain separation, and you indicate this race condition may be pervasive, is it time you considered the help of an experienced consultant? Do you have one now? >Cindy Crawford _is_ God That explains it - I doubt she really believes in the fundamental benefits of maintaining subject matter purity. Cindy - speak up lass! - are you lurking out there...? ;-) ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice/fax: +01 508-384-1392 | peterf@pathfindersol.com | ____________________________________________________| Subject: Re: (SMU) Syncronous event communications peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 03:29 PM 7/24/97 -0400, shlaer-mellor-users@projtech.com wrote: >Paul Coene writes to shlaer-mellor-users: >-------------------------------------------------------------------- > ... >In a discussion of this issue with a non-shaler/mellor colleague, he >suggested that the object that originates the event could poll for the >result of the event. At first, I didn't like this, but it is growing on >me. > > ... >I like the idea. Opinions? In my experience, many polling loops are hacks to work around an incomplete understanding of system behavior. Basically, you're conceding that you cannot complete adequate system analysis. Simply, polling sucks, and should be avoided where possible. Once your problem space is sufficiently understood and properly abstracted, a relatively simple and effective solution should be apparent. Of course, none of us who have offered suggestions can really assert we KNOW a better answer util we have invested some time to understand YOUR application. But our own experiences in other somewhat similar situations makes us confident that our suggestions may help you find a more simple and elegant solution than you currently propose. ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice/fax: +01 508-384-1392 | peterf@pathfindersol.com | ____________________________________________________| Subject: Re: (SMU) Syncronous event communications peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 03:37 PM 7/24/97 -0400, shlaer-mellor-users@projtech.com wrote: >lahman writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >Responding to Fontana... >> Actually to be workable, this approach would require all objects that would >> initiate the delete to be subtypes of a common supertype. David Whipp also >> covered this. Another good idea... > >I don't think so. > > R1 R2 >A <------> B <-------> C (ignoring other relations provide sense) > c c c c > >is legal without A and C being subtypes of some common supertype. Valid point - I should have said "Actually to be workable IN THE CASE WHERE THERE ARE MANY DIFFERENT OBJECTS DELETING X's, this approach would require all objects that would initiate the delete to be subtypes of a common supertype" Simply an assumption in the interests of keeping to problem managable. ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice/fax: +01 508-384-1392 | peterf@pathfindersol.com | ____________________________________________________| Subject: Re: (SMU) Syncronous event communications Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- Paul Coene wrote: > > Dave Whipp wrote: > > > The situation you describe sounds like you are modelling in terms of > > behaviour, not lifecycles. > > Can you tell me the difference? The object really has little more than > a live/die lifecycle. There is a little bit of interesting stuff upoin > delete, as the object needs to check a few things before allowing > deletion. If an event is generated with the intention of causing a specific behaviour, or eliciting a specific response, then you are creating a behavioural model. Events should indicate that a something has happenned; They should not be used to give orders or make requests. Thus "CT1: Thermo-nuclear device detonated(location)" may be an event, but "CT1: Delete City(location)" is not. I won't say that any event that makes a request is incorrect; but they shoud be critically considered and justified. One consequence of thinking of events in terms of just giving inforation, and not making requests, is that the need for synchronous protocols is reduced. It is often necessary to set an attribute (in the sender) in addition to sending the event becasue it is quite common for an object to ignore events. >>[supertype: deleter of X] > I've had a couple folks suggest this. I can certainly use this > technique, but adding this object seems to me akin to modelling the > solution domain, not the problem space. Would not the new object be > nothing more than a functional based object? I think object 'X' should > know full well how to delete itself without a 'X deleter' functional > object. I think , perhaps, I wasn't entirely clear. The "X deleter" supertype object does not delete X. X is deleted when it moves into its termination state. The "X deleter" object is used only to allow delivery of an "X deleted" event to a number of different objects. Its purpose might be better stated as being "an object that wants to know when X has been deleted" - in principle the informed object might not be the same object that initiated the deletion. This is not uncommon. If such an object doesn't naturally fit into the model then it probably doesn't belong. If this is the case then you may have a more fundamental problem with the model. Dave. Not Speaking for GPS. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Tamerton Road, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com For embedded Systems Support mailto:armapps@gpsemi.com Subject: Re: (SMU) Syncronous event communications lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Fontana... > > R1 R2 > >A <------> B <-------> C (ignoring other relations that provide sense) > > c c c c > > > >is legal without A and C being subtypes of some common supertype. > > Valid point - I should have said "Actually to be workable IN THE CASE WHERE > THERE ARE MANY DIFFERENT OBJECTS DELETING X's, this approach would require > all objects that would initiate the delete to be subtypes of a common supertype" But in this case A and C are different objects (a small value of "many") and they both initiate the delete of B, yet I see no need for them to be subtypes of a common supertype. What am I missing in your argument? -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Syncronous event communications lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Murray... > I am under the impression that synchronous deletes are not always a good > thing. On a multi-processor system, it could be possible for a state of an > object to be running whilst somebody else synchronously deletes it > underneath. > > Could this be guarded against ? There are situations where the care you have to exercise in using a synchronous delete is not worth the effort. My original example was one where major surgery on the model would be required to make them work. In general a synchronous delete can be made to work _provided_ you handle things correctly in the analysis and your architecture enforces the rules properly. For example, in your original example it would appear that there could be multiple delete events sent to the same instance. If this is the case the state model for the deletee is going to have to somehow ensure that these are exhausted from the queue before the instance is actually deleted. This is the analyst's problem because the delete events are generated from different actions and, therefore, that flow of control must be correctly handled in the OOA. Similarly, if you are going to use synchronous deletes, then each action that wants to do a delete is going to have to ensure there is something there to delete when more than one instance might delete. OTOH, I doubt that your multiprocessor example is an OOA issue, per se. Your architecture needs to support a multiprocessor environement. The architecture will have to provide the appropriate protections to ensure that the threads on each processor do not do nasty things to one another. Your architecture and translation rules will determine the threads and allocate them to processors. That is, the analyst should not be concerned with this issue; the OOA should Just Work in whatever environment it is translated to -- so long as you have resolved the OOA flow of control issues between actions (as above) correctly. To put all this another way, there are two levels of guarding. At the OOA you, as the analyst, have to explicitly account for everything that occurs beyond the boundary of the state action. That is, you must account for any *possible* changes in the environment that might occur between the execution of any two arbitrary actions. At the level of a state action the architecture must ensure that the environment of execution remains consistent throughout execution of the action. For example, if an action traverses a relationship, then if that relationship existed at the start of the action the architecture must guarantee it remains in existence throughout the action (unless the action itself removes it). Specifically, if an instance that action A1 wants to synchronously access exists at the start of execution of A1, then the architecture must prevent deletion of that instance prior to the completion of A1. In this sense the synchronous delete accessor is no different than an attribute read accessor. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Syncronous event communications lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Coene... As Peter pointed out, we can all offer vague recommendations, but without more concrete examples it is difficult to get specific -- especially when there are fundamental modeling issues. > In a discussion of this issue with a non-shaler/mellor colleague, he > suggested that the object that originates the event could poll for the > result of the event. At first, I didn't like this, but it is growing on > me. Sure, you could use polling and it might even be appropriate. However, I agree with Peter on this also -- look for a better way. > My issue is really a very common case, and I'm suprised that many of the > replies I've received haven't considered it so. > > Lets say that an object (A) is in a one to many relatrionship with > object B. (one A relates to many Bs unconditionally). When object A > gets a delete event, it cannot delete itself until all the instances of > object B are deleted. If it does, the model is unstable(bridgepoint > would barf in the simulator). If object B uses a delete event to > intiate deletion, and object A sends those events, object A must either > perform a wait/check loop, or wait for an event back from object A that > indicates deletion. > > This is precisely my situation, extended by multiple other objects like > object A that may request a deletion of object B. I cannot have object > B send an event back when done, because I don't know which related > object sent the delete event. If the client uses a send/wait/check > loop, the problem is resolved. The 1:M case *is* quite common. However, I would deal with this in a single action in A, using synchronous deletes of the Bs. In this case everyone is going away and the key issue is maintaining consistency with the A/B relationship. Maintaining that consistency using events is complicated and adds irrelevant clutter to A's state model. When a single action removes the relationships at the same time the Bs are deleted, consistency is enforced by the action scope. The second situation, where multiple objects may request deletes, is much less common. My first observation is that this is not exactly an extension of the 1:M case. The difference lies in the fact that for the 1:M case *both* A and B were going away. Assuming we have R1 R2 A <------>> B <<------> C there are three cases (with variants). First, only the Bs are going away; A and C live on. This is fairly common. In this case there is really no need for acknowledgements. Both A and C could have a single delete state that synchronously removed all relevant Bs, R1s and R2s. Whoever gets there first does the deed. In the second case A but not C dies (or C and not A) along with the B's. This is also fairly common and is essentially your 1:M case. The only difference is that for the deleted Bs both R1 and R2 are removed. Again a single delete action in A can handle this with synchronous deletes. In the third case A, C, and all the Bs are going away, akin to your 1:M example. I would argue that this is just an extension of the 1:M. Whoever is initiating all these deletes could do so with a single action that killed all the relationships and instances. However, this case is not very common -- the only places I can recall our doing it is for things like error recovery and system resets. All this assumes that the main problem is consistency of the R1/R2 relationships while instances go away. If this is the only issue, then I think life is much simpler using synchronous deletes from a single action. What I believe Whipp and Fontana are going after is a deeper implication regarding what is being modeled -- that there is some other reason why you want to use events to delete the Bs. For instance, because the B delete state is the container of some common functionality, other than simply removing relationships and committing suicide. As I recall, your original posting suggested that there were multiple delete states in B. The only justification for this would be that those states each did something different. A corollary implication is that your model forces you into the case 3 mode above. As a practical generality, I would argue that this is not a good idea. Many consistency problems lurk in instance creation and deletion. Making this more complicated by adding other functionality to the create/delete process is asking for trouble. Stuffing extra functionality into a delete action because it is algorithmically in temporal proximity to the delete is very suggestive of functional partitioning (put all the stuff that happens at one time in one routine). I believe that case 3 is not common is because usually it would be handled differently. For example, whoever is initiating the deletes would probably send a My Work Here Is Done event to both A and C. Their states would be expected to Do the Right Thing to the relevant Bs (case 2) and it should not matter who acted first. This only gets complicated if you *must* delete a B via an event because it is doing other processing in the delete. The event that triggers case 3 is really saying: do the processing in B's delete state and *then* do some housekeeping. Moral: Don't Do That -- separate your processing from your housekeeping. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Syncronous event communications Paul Coene writes to shlaer-mellor-users: -------------------------------------------------------------------- lahman wrote: > lahman writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Responding to Coene... > > As Peter pointed out, we can all offer vague recommendations, but > without more concrete examples it is difficult to get specific -- > especially when there are fundamental modeling issues. Your message (the long one with the illustration) conveys the example very well. You suggest that all deletes should be handled using syncronous services, which will guarantee syncronous behavior. I think this will work. I am troubled though: I fear I might be bypassing a modelling issue of some sort, rather than solving it. I don't think this is the case, but I want to make sure. Dave Whipp pointed out that a 'Delete X' didn't sound like an event notification, it sounded more like a functional request. I am forced to agree. However, in one of the cases in my scenario, it is a communication over a bridge from the UI, stating that the user has requested that an 'X' previously deisplayed be 'X' be deleted. What would an event be? 'User Requested Delete of X'? This still sounds functional. To me more detailed about my scenarion, there are (3) possible deleters of X. 1) One is the UI through a bridge. This occurs when a user requests deletion of a user visible instance of 'X'. In this case, only X knows if deletion of itself is legal at this time, so X needs to either delete itself, or notify the caller of why 'X' cannot be deleted. This 'reason X cannot be deleted' is made up of showing the user instances of another object that depends on X. Thus, my current state model for 'X' sends events back to the user (or whould like to, if it knew who called it) carrying this information. This sounds pretty functional, but I don't know what else to do. 2) The second 'deleter of X' is an object that owns 'n' instances of X. When this object dies, it unconditionally takes all instances of X related to it with it. 3) The third 'deleter of X' is just like (2). Again, the syncronous services solution works. I don't like the idea proposed by someone to have a supertype over the three deleters of X. The UI, and the other 2 objects have nothing in common besides their relationship to X. Polling works in all cases, and keeps the solution in state models, rather than in syncronous services. Most voices I've heard feel that "polling sucks" however. > As a practical generality, I would argue that this is not a good idea. > Many consistency problems lurk in instance creation and deletion. > Making this more complicated by adding other functionality to the > create/delete process is asking for trouble. Stuffing extra > functionality into a delete action because it is algorithmically in > temporal proximity to the delete is very suggestive of functional > partitioning (put all the stuff that happens at one time in one > routine). Where else would one put checks needed to assure that deletion of X is allowed, if not in a 'Pending Delete' state in X? Seems like solid encapsulation to me. -- Drool WWW: http://www.servtech.com/public/drool ARPA: drool@servtech.com Cindy Crawford _is_ God drool@questra.com Subject: Re: (SMU) Syncronous event communications TGett@aol.com writes to shlaer-mellor-users: -------------------------------------------------------------------- In a message dated 97-07-26 00:38:43 EDT, you write: > peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: > -------------------------------------------------------------------- ... > In my experience, many polling loops are hacks to work around an incomplete > understanding of system behavior. Basically, you're conceding that you > cannot complete adequate system analysis. > Bravo! Hear, hear. Sic 'em, Pete. I concur with an earlier statement of yours that this is an ANALYSIS issue. Unfortunately, the masses seem to not readily comprehend the import or power of proper analysis. T. Gett Subject: Re: (SMU) Syncronous event communications lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding Coene... > Your message (the long one with the illustration) conveys the example You must be new to SMUG. That message was of rather modest size. > I fear I might be bypassing a modelling issue of some sort, rather than > solving it. I don't think this is the case, but I want to make sure. > Dave Whipp pointed out that a 'Delete X' didn't sound like an event > notification, it sounded more like a functional request. I am forced to > agree. However, in one of the cases in my scenario, it is a > communication over a bridge from the UI, stating that the user has > requested that an 'X' previously deisplayed be 'X' be deleted. What > would an event be? 'User Requested Delete of X'? This still sounds > functional. I think Whipp's insight that events are announcements rather than instructions is excellent. However, as he pointed out, there are some exceptions. For example, it is hard to imagine a context where a create event is not a request to create. Similarly, in a lot of situations a delete event would really be a request for hari kari. My spin on Whipp's view is that OO in general and FSMs in particular are oriented around localized, incremental and independent processing. The spirit of encapsulation applies to function as well as data. As a result you don't want to tell an object How to do something. Unfortunately if you are telling it What to do, then it is sometimes hard to avoid slipping in a bit of How. OTOH, if you, as an external entity, restrict yourself to simply announcing that your part of the processing is completed, you avoid the How trap. It is also more consistent with the notion of localized, incremental, and independent processing being better. This is especially true in FSMs where an action is not supposed to know about history and context (i.e., what other state actions do). > To me more detailed about my scenarion, there are (3) possible deleters > of X. > > 1) One is the UI through a bridge. This occurs when a user requests > deletion of a user visible instance of 'X'. In this case, only X knows > if deletion of itself is legal at this time, so X needs to either delete > itself, or notify the caller of why 'X' cannot be deleted. This 'reason > X cannot be deleted' is made up of showing the user instances of another > object that depends on X. Thus, my current state model for 'X' sends > events back to the user (or whould like to, if it knew who called it) > carrying this information. This sounds pretty functional, but I don't > know what else to do. Bridges are one of the exceptions. By its nature the bridge is a request because the client domain is demanding a service. In your case, though, it would seem the bridge could handle everything synchronously (assuming there is nothing tricky about collecting the reason it can't be deleted). It is pretty common to have bridges use synchronous processing to handle asynchronous events. > 2) The second 'deleter of X' is an object that owns 'n' instances of X. > When this object dies, it unconditionally takes all instances of X > related to it with it. > > 3) The third 'deleter of X' is just like (2). In my view this sounds like a simple consistency issue. That is, the rules of OOA require that you leave the model in a consistent state at the end of the original deletion. As the analyst you have several choices. One is to use events and this would require waiting until you knew all the Xes were gone. Another is to do everybody synchronously in one state action. I would tend to opt for the second because it is simple and clean. However, even if one views this as a kind of request on X, I can rationalize it as being a more mechanical enforcement of consistency. > Polling works in all cases, and keeps the solution in state models, > rather than in syncronous services. Most voices I've heard feel that > "polling sucks" however. I am in the Suck camp. FWIW, I think it would be shooting gherbils with Exocets in this case. Polling tends to introduce complications you don't need (e.g., what if it never acknowledges?) and it is inherently relatively complicated both in the OOA and in the architecture. Architecturally it can be annoying if you have to port to another environment. From a practical point of view, it sucks up system resources, even if you use some "free" operating system goody for timing. In general I would leave polling to those pure hardware communication situations where it is unavoidable. > > As a practical generality, I would argue that this is not a good idea. > > Many consistency problems lurk in instance creation and deletion. > > Making this more complicated by adding other functionality to the > > create/delete process is asking for trouble. Stuffing extra > > functionality into a delete action because it is algorithmically in > > temporal proximity to the delete is very suggestive of functional > > partitioning (put all the stuff that happens at one time in one > > routine). > > Where else would one put checks needed to assure that deletion of X is > allowed, if not in a 'Pending Delete' state in X? Seems like solid > encapsulation to me. I happen to be a big believer that create states should do nothing except initialize attributes and instantiate relationships and that delete states should do nothing but deactivate relationships and deallocate the instance. However, I may only be a consensus of one in this. Moreover, there are always a few exceptions, such as sending off an event to some other instance to announce the deletion. First, you are already separating the checking from the deletion state by using the Pending Delete. [Clearly the check can't be done in the same state as the delete itself in case it couldn't be deleted; a delete state is forever.] This was my main concern -- the partitioning of functionality among states. So I assume you are concerned about doing the check synchronously in, say, the bridge instead of in the instance which should have the knowledge. This is a valid point. One way to do it is to ask the instance synchronously if it is deletable. The tool I use supports object synchronous services but you could also do the same thing with a flag attribute if that isn't available. However, I would point out that a common reason why an instance might not be deletable is because it has active relationships with other instances. IMHO, anything that is on the IM should be regarded as common knowledge within a domain. Thus the active relationships for an instacnce should not be regarded as encapsulated in that instance -- anybody can look at them. So if that is the reason, then it is fair for the check to be outside the instance. P.S. It is not necessary to address mail to me and then cc it to SMUG; since SMUG always echoes it to all members, this just means I get two copies. It also has an unfortunate side affect; you alone are the default return address in my mailer and I may forget to change that back to SMUG so that others won't miss my deathless prose. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Syncronous event communications Scott Finnie writes to shlaer-mellor-users: -------------------------------------------------------------------- [Disclaimer : reply from a non-SM user, trying to learn...] Are you sure that 'delete' truly represents the semantics of what you're trying to do? Without knowing more about your problem domain it's hard to tell; however it seems to me there are two possible scenarios here (may be more): 1. 'Delete' means 'remove reference to': i.e. the sender has finished doing whatever it wants to do, and therefore is terminating any relationship with the receiver. The sender doesn't actually care what happens to the receiver; what's important is that they are now no longer related. 2. 'Delete' actually means 'delete': the sender must know that the receiver will be deleted. The receiver, on the other hand, cannot be deleted until all objects it is related to issue a delete. If it's the former, then I don't think you're actually deleting the object, you're deleting the relationship. I don't know SM well enough to say how this should be done (sure someone else can help). If it's the latter, my initial reaction would be to model it as a delete request (not in the true SM delete object sense, but as a separate request carrying sender id, etc.) You seem to suggest that the object instance may not be deleted until all related objects have sent delete requests; one possible sequencing for this (which I've used outside SM) is : 1. Object received 'delete' request from 1st sender 2. Object broadcasts 'request to delete me' message to all currently related instances; 3. Object waits for all remaining instances to acknowledge (by sending 'delete') 4. Object broadcasts 'deleting' acknowledgement once all requests received 5. Object deletes itself. There are obviously numerous variations on this theme, but hopefully you get the picture. Anyway, I hope this helps. Apologies if it's way off base - as I say I'm not an SM user - just interested in learning. Scoot. -- Scott Finnie Tel. (+44) 131 331 7756 Telecoms Systems Division Hewlett Packard Ltd. mailto:sfinnie@sqf.hp.com Subject: Re: (SMU) Syncronous event communications lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Finnie... > 1. 'Delete' means 'remove reference to': i.e. the sender has > finished doing whatever it wants to do, and therefore is > terminating any relationship with the receiver. The sender > doesn't actually care what happens to the receiver; what's > important is that they are now no longer related. > 2. 'Delete' actually means 'delete': the sender must know that > the receiver will be deleted. The receiver, on the other > hand, cannot be deleted until all objects it is related to > issue a delete. There is a bit of chicken-and-egg here. The problem lies in maintaining model consistency while doing so, and this revolves around the relationship. The two consistency issues are: you cannot delete an instance so long as it has active relationships and an unconditional relationship must be deactivated at and only at the same time (i.e., within the same state action) one of the instances is deleted. If one chooses to delete via events (i.e., asynchronously), then one scheme for doing so is exactly as you suggested -- which is pretty much what Coene originally proposed. The original question essentially was: is there a better way? At least three proposals were made, each with advantages and disadvantages. A second issue was raised about the modeling itself. This was speculation based upon other implied characteristics of the problem, such as there were multiple instances that might want to delete a particular instance and that the deleted instance might by doing other processing besides the mechanics of relationship deactivation and deallocation. Thus I believe it is a given that the relationship was unconditional so there had to be a corresponding delete. Most of the thread has been related to the second issue, at least indirectly, because the decision among several approaches depends upon the subject matter context. You correctly sensed that the main issue was around what needed to be modeled (an insight not often seen in rookies); but I think the issue was How to delete rather than Whether to delete. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com 'archive.9708' -- Subject: (SMU) PT_Builder Patrick Greenlee writes to shlaer-mellor-users: -------------------------------------------------------------------- I would like to know if there is enough information contained in the eps files that are written my Builder to support translation into vector type mif files for allowing manipulation (moving/sizing) of the graphical objects e.g. arrows, states, etc. and or editing of the textual content of boxes (states, objects, subsystems, or whatever). If yes, we would appreciate knowing about any sw application that can perform that translation. Patrick Subject: (SMU) subsystem re-use Kenneth Cook writes to shlaer-mellor-users: -------------------------------------------------------------------- I have a question for discussion: Are subsystems re-useable? -Ken Subject: (SMU) re: subsystem re-use Gordon Colburn writes to shlaer-mellor-users: -------------------------------------------------------------------- Kenneth Cook asked: Are subsystems re-usable? Not really. Given that relationships span subsystem boundaries and events are sent between subsystems, subsystems have a lot of interdependencies and are not easily separable. Also, given that object numbers and names must be unique over an entire domain, attempting to re-use subsystems from several different projects all in one domain could result in name clashes. Usually the domain is the smallest re-usable element of an analysis. Obviously there are some exceptions where pieces of a subsystem or perhaps the entire subsystem can be reused with minor modifications, but this is not common in my experience. -Gordon Colburn Subject: Re: (SMU) subsystem re-use peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 12:51 PM 8/18/97 -0700, shlaer-mellor-users@projtech.com wrote: >Kenneth Cook writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >I have a question for discussion: > >Are subsystems re-useable? > No. They are convenient containers for arbitrary fragments of domains. In the same manner that a single class is not typically reusable - because of the possible (and common) entanglements. Domains are the only real unit of reuse I've seen, because the only explicit points of contact are at the bridges. ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice: +01 508-384-1392 | peterf@pathfindersol.com fax: +01 508-384-7906 | ____________________________________________________| Subject: Re: (SMU) re: subsystem re-use kearnan@Summa4.COM (Gregg Kearnan) writes to shlaer-mellor-users: -------------------------------------------------------------------- Subject: Re: (SMU) subsystem re-use lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Cook... > I have a question for discussion: > > Are subsystems re-useable? Normally not. We use them almost exclusively as a means of partitioning where people work in a domain. Typically we place our domain boundaries around those portions of the system that we feel might be reusable. This tends to lead to a number of small domains (10-30 objects), though. [A bigger problem is that it tends to promote partitioning based upon functionality rather than "subject matter", but that's another story.] In my view the big problem is the outgoing events and any accessors for objects outside the subsystem. I can imagine tool support that allows some sort of name-casting for outgoing events and simple data accessors that would allow plunking a subsystem into a new context in a disciplined manner. Unfortunately the tricky part is addressing those events and accessors to particular instances of foreign objects. You would have to pass in the return address as a typeless instance handle on an incoming event to be reusable. This is kind of disciplined in a klunky sort of way, but a domain boundary does a much better job. One possible, albeit rare, reuse possibility occurs to me. If the subsystem only has incoming events and only talks to a bridge, then it could be reusable. An example might be a domain that does some sort of translation. It would have two subsystems with a one-way event flow: input bridge -> subsys1 -> events -> subsys2 -> output bridge -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) Bridges Patrick Greenlee writes to shlaer-mellor-users: -------------------------------------------------------------------- Maybe I have been "lookin' for bridges in all the wrong places" but I don't seem to have an unambiguous, clear, concise, communicable understanding of them. I have a sort of arm waving, high level, philosophical appreciation for the concept but come up seriously short in the real-world-now-build-some arena. Anyone care to shed some light on my darkness? If this is something not likely of general interest (or covered ad infinitum prior to my enlistment), please respond direct and not annoy the subscribers. Also, is there a FAQ or archive so a newby can catch up without wasting bandwidth or boring the masses? Any assistance would be appreciated. TIA, Patrick Subject: Re: (SMU) Bridges "Anil K. Arya 6192" writes to shlaer-mellor-users: -------------------------------------------------------------------- Patrick, Your observations coincide with my own. We are currently looking into defining our own internal Bridge Policy because of the lack of detailed specifications available for them. In particular, areas such as the following seem to need defining:- 1. Bridge counterpart mappings. - purpose of (to avoid domain pollution, where one domain is knowledgeable of another) - which are allowed, with rationale - which are disallowed, with rationale 2. Bridge operations - What processing is allowed/disallowed on the bridge, if any (again, with rationale). 3. Bridge mechanisms - What mechanisms should be supplied by the architecture 4. Bridge creation and deletion policies - Are there special considerations for counterpart mappings that create an object instance in the other domain (e.g. the instance must exist before the counterpart can be used). - Similarly for deletion of counterpart/original instances. Note that we're using KC's flavour of Shlaer-Mellor, so some of the "holes" may be peculiar to them, but this doesn't seem to be the case (e.g. the book OBJECT LIFECYCLES Modeling the World in States pp138-140 barely discusses the above issues, if at all). Our policy is aimed at protecting the purity of our domains by utilising counterpart mappings in all cases. Thus, the mapping between domains is held in the bridge. Each domain has no knowledge of any other and is, therefore, not "polluted". The overriding purpose of this is to permit our domains to be truly reusable. Comments/definitions/guidance on the above or other associated points would be most welcome. Patrick Greenlee writes: > Patrick Greenlee writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Maybe I have been "lookin' for bridges in all the wrong places" but I don't > seem to have an unambiguous, clear, concise, communicable understanding of > them. I have a sort of arm waving, high level, philosophical appreciation > for the concept but come up seriously short in the > real-world-now-build-some arena. Anyone care to shed some light on my > darkness? If this is something not likely of general interest (or covered > ad infinitum prior to my enlistment), please respond direct and not annoy > the subscribers. > > Also, is there a FAQ or archive so a newby can catch up without wasting > bandwidth or boring the masses? > > Any assistance would be appreciated. > > TIA, > > Patrick > > > -- Anil K Arya Simoco Europe Ltd. anil.arya@cambridge.simoco.com P.O. Box 24, St Andrews Road http://www.simoco.com CAMBRIDGE CB4 1DP, ENGLAND Tel/Fax: +44 1223 586192/314812 (This is not an official communication) Subject: Re: (SMU) re: subsystem re-use Kenneth Cook writes to shlaer-mellor-users: -------------------------------------------------------------------- At 09:10 PM 8/18/97 -0400, you wrote: >kearnan@Summa4.COM (Gregg Kearnan) writes to shlaer-mellor-users: >-------------------------------------------------------------------- >> Kenneth Cook asked: >> Are subsystems re-usable? > >It would seem to me that if the subject matter of a subsystem is >re-usable, it probably could be a domain all by itself. > This is a good jumping off place. I say "yes" subsystems are reusable, and should be reused. They are reusable both in analysis and in their implementations. Certainly domains are a vital partition of reuse. Domains and bridges make available services that are semantically separated: when you find yourself having to draw a relationship from every object to one particular object ( train uses i/o port, switch uses i/o port, track segment uses i/o port, etc ) you can be pretty sure you've found a domain. And bridges are powerful. They've been formulated to describe architecture independent communications between domains, where binding can be delayed as long as desired (I can imagine a system where binding can be changed during runtime). But why should only semantically separated objects be reused? Both kearnan and lahman have implied that a domain may not be semantically separate if we need to reuse these objects. But this is in conflict with the method's definition of a domain. >From a purely analysis point of view, we reuse subsystems all the time. The Subsystem Access and Communications diagrams are pictures of our subsystem reuse. If we add new objects to a domain, we draw yet more relationships, accesses, and events from the new objects to our reused subsystems. We simply let our domain grow to contain all objects in this semantic realm. I've seen this in practice, where the first subsystems developed by a group get re-used for more and more products. In one case, they were objects describing semiconducting wafers, that have been reused for 5 different products (and counting). If we had ever drawn one big OIM, the semantics would have required us to put objects from every product in the same domain as our wafer subsystem. Over the years, if we developed more and more applications and features, our domain would grow. While the method says that these objects must remain together in analysis, it also allows us to partition and distribute the implementation of these objects into any number of nodes and processes. And we are now entering the age of Distributed Object Computing. Enterprises expect to be able to distribute their objects and instances, balancing loads. Reuse in a Distributed Components world means that partitions of our analysis (components, if you will) are implemented and live out there on some node, waiting to be used by other "components" on some other node. Some of these components will be entire domains, having an interface specified by a Bridge. Other components will need to be smaller partitions. Subsystem is a good partition because it can arbitrarily contain one or many objects. In our analysis, we can, over time, replace the behavior of objects in a subsystem. Unless we are willing to re-generate, re-test and re-deploy all the components using our modified subsystem, our tools, architectures and code generators should support this kind of model change. If the interface remains the same, we should be able to change the behavior inside a subsystem, and redeploy the subsystem without ever stopping the client components. Just as we expect to add new features in our analysis over time, Distributed Components anticipate that they will be used by new clients. This is where we really start re-using subsystems: Consider a subsystem, implemented as a component, and running on the Enterprise network. Then, without ever bringing that component down, new objecs are modeled, generated, initiated, and start reusing that old component. If that old component provides access to a Billing database, for example, you can see the value of this. This is also where we stretch the method, and some of the postings mentioned this. For the above re-use to work, subsystems would have to have no knowledge of their client subsystems. But the method never makes this restriction. The method assumes that subsystems have full visibility of objects in other subsystems. Such client-server separation is reserved for domains. But again, why should only semantically separated objects have this kind of client-server separation? Fortunately, we can model subsystems to be ignorant of their users. To stay true to the method requires some additional modeling conventions. Or our tools and our architectures can help us in ways like incorporating "transfer vector" type callbacks, and implementing relationships as uni-directional. So I believe that subsystems are already reused in the analysis, and we must look to how we will implement that reuse in a world of Distributed Components. -Ken Subject: (SMU) Domain/Subdomain chart for a game/engine Allen Theobald writes to shlaer-mellor-users: -------------------------------------------------------------------- Greetings SMUG! I have been asked to come up with a preliminary domain/subdomain chart for the development of a computer-based game. The first cut looks like: Game / \ / Process I/O / / / / Renderer | \ | \ | Software Arch | / \ | / \ O/S Prog Lang Where, O/S - Event-Driven, Message-Based Programming (tasks, messages, events, etc.) - Win 95/NT Programming Language - C++ Process I/O - Game Controllers (joystick, mouse, etc) Renderer - Video - Graphics - Sound - Music What I can't place are these characteristics: Story - all the storyboard, concept, theme, etc. World - all the physical characteristics (gravity, etc) Granted this diagram was done in haste. So, I would also like comment on the diagram and what to add/delete/change. Any idea on possible subdomains are welcome as well. Kind Regards, Allen Theobald Nova Engineering, Inc. Subject: Re: (SMU) re: subsystem re-use peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 11:27 AM 8/19/97 -0700, shlaer-mellor-users@projtech.com wrote: >Kenneth Cook writes to shlaer-mellor-users: >-------------------------------------------------------------------- > ... >I say "yes" subsystems are reusable, and should be reused. They are >reusable both in analysis and in their implementations. > ... >So I believe that subsystems are already reused in the analysis, and we >must look to how we will implement that reuse in a world of Distributed >Components. > Interesting twist. I see your logic, but your point illuminates some of the subtle variations possible in the meaning of "reuse". So anyway - I'll bite - what's your *real* point? (It sounds like they accidentally locked you into the ObjectWorld show overnight or something.) > ... >"transfer vector" type callbacks, ... You can use our notion of Indirect Events to support this basic capability. ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice: +01 508-384-1392 | peterf@pathfindersol.com fax: +01 508-384-7906 | ____________________________________________________| Subject: Re: (SMU) re: subsystem re-use lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Cook... > But why should only semantically separated objects be reused? Both kearnan > and lahman have implied that a domain may not be semantically separate if > we need to reuse these objects. But this is in conflict with the method's > definition of a domain. As Peter pointed out, this depends upon one's definition of "reuse" and it also depends upon one's definition of "subject matter". Alas, the exposition in the methodology is a tad vague about the latter. For lack of a better suite of criteria I tend to use the following to define the bounds of a "subject matter": - All the elements must be logically and closely related. - All the elements should be at the same level of abstraction. - The elements are independent in their representation from other subject matters. The last point indirectly defines reuse as a requirement for defining a domain. So I don't see any conflict with the definition of a domain. With the current software technologies, things are reusable through their interfaces. To be reusable the interfaces must be invariant with context. In particular, a reusable component should not have knowledge of its context. This is not the case within a domain. All objects are intimately related and they have very explicit knowledge of the domain structure (e.g., relationships used for navigation) in their implementations (i.e., state actions that navigate the relationships). The event naming conventions and addressing schemes in the notation are specific to a domain, which means that the interfaces (events, accessors) are not invariant with context. In my view the methodology simply does not support subsystem reuse; its basic unit of reuse is the domain. You seem to be suggesting that the notation should change to insert the same level of abstraction (or indirection) represented by inter-domain bridges for communication between subsystems. Basically I don't see the need for this because I think that if a subsystem's subject matter is independent enough of context to be reusable, then it qualifies as a domain. At a megathinker philosophical level, I think there are some good reasons why large scale reuse is better than small scale reuse. In general class-level reuse has been the biggest bust since expert systems. It is so bad that all the gurus advocating it half a dozen years ago have abandoned it and jumped on the Component Reuse bandwagon in hopes that scaling up a bit will somehow solve the problems. As I see it the problems are: - It is hard to keep track of reusable elements. You need a big infrastructure just to be able to find an element. The more elements there are, the more complex this gets, so large scale reuse has an advantage because there are fewer elements. - For smaller elements it is hard to describe a reusable element well enough to know whether it can be reused without describing its implementation. This is because what the class does *is* the description. The larger the scale of reuse the more the description becomes one of interface alone. At the domain level you define bridges and services rather than implementation. The potential user very rarely needs anything more than the abstract bridges descriptions to know whether a domain can be reused. - It is hard to make the interface independent of the implementation for small scale reuse. Large scale reuse also has large scale interfaces that leave the implementor much more freedom for mixing and matching components internally. - It is hard to design an interface that all clients will be happy with. The smaller the scale, the less inclined the client is to want to change anything internally, so the client demands fine detail on the reusable interface. If you can't tinker with the interfaces, then the likelihood of being able to reuse a component is reduced. The last point is crucial, in my view. Component Reuse is not going to work, regardless of the scale, so long as the interfaces are defined as invariants. The most general and efficient way I know of to fix an interface mismatch problem is the S-M approach where the bride is custom coded in context without affecting the component implementations. (The somewhat equivalent UMLer approach is to use polymorhic wrapper classes customized to the context.) The downside is the cost of custom coding and testing the intertface in each reuse context. This is only worthwhile if your scale of reuse is large. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) re: subsystem re-use kearnan@Summa4.COM (Gregg Kearnan) writes to shlaer-mellor-users: -------------------------------------------------------------------- Subject: Re: (SMU) Domain/Subdomain chart for a game/engine lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Theobald... > I have been asked to come up with a preliminary domain/subdomain chart > for the development of a computer-based game. The first cut looks > like: > > Game > / \ > / Process I/O > / / > / / > Renderer > | \ > | \ > | Software Arch > | / \ > | / \ > O/S Prog Lang > > > What I can't place are these characteristics: > > Story - all the storyboard, concept, theme, etc. > > World - all the physical characteristics (gravity, etc) > Different folks tend to have different views about what goes into the highest level application domain (your Game). I think this application is a bit unusual in that the thing you want to be reusable would be the game engine itself. All of the domains shown would Just Work for any game you built for Win 95/NT using C++. What I am trying to articulate is that the Game domain probably wants to be reusable as the generic game engine -- you would create a new game application by replacing the Story and World domains in the overall application. Thus I would see Story and World as service domains that the Game coordinates. If you intend to use the same basic engine for different contexts (e.g., for 97 new flavors of Doom), then the smarts would be mostly in Game and the Story and World domains would be relatively uninteresting. In this case they would be mostly passive objects whose data is accessed by Game in response to Process I/O requests. Game would probably talk to Story/World and then to Renederer. However, if you plan on significantly different game mechanics in different versions, then you might want Story and World to be smarter and also package specialized algorithms in these domains. In this case the Game's service requests would probably be more general (Here's the player action; figure out what to do with it). Story/World might talk directly to Renderer in this case. In any event, I would think that Story and World are domains. There might be some other domains as well. You might want to separate Video/Graphics from Sound/Music since they are fundamentally different; Game can handle coordination, if any. Also, it is sometimes useful to have two domains for the GUI: a low level one to handle the Window manager stuff, which knows nothing of the semantics of the data displayed, and one that has a richer knowledge of data semantics where particular images are meaningful. If you are going to use MFC or a commercial window builder, you should include that among your architectural domains. Process I/O is probably a lower level domain, bordering on architecture. If all it is dealing with are peripheral device drivers, it is little more than a smart bridge to hardware that announces stuff to Game or Renderer. If you have two GUI domains, these might be subsystems of the low level Window Manager domain. You might have a low level database domain for saving games or for holding initialization information. Finally, I am not sure that Story and World are separate domains. If Game has all the smarts, then these might well be combined -- they would essentially just be repositories for specification objects. World sounds like it might be only passive specification objects, in which case it could be included in Story. Even if each version has different game mechanics, I would think these go with Story rather than World. That is, what happens next would be a function of the state of Story, but the hit points for your Laser Guided Defrabrulator would be just be data. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Bridges lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Greenlee... > Maybe I have been "lookin' for bridges in all the wrong places" but I don't > seem to have an unambiguous, clear, concise, communicable understanding of > them. I have a sort of arm waving, high level, philosophical appreciation > for the concept but come up seriously short in the > real-world-now-build-some arena. Anyone care to shed some light on my > darkness? If this is something not likely of general interest (or covered > ad infinitum prior to my enlistment), please respond direct and not annoy > the subscribers. The basic S-M philosophy is that bridge form a context-dependent comunication between domains with independent implementations. Bridge code must be created for each specific application where a domain is used (or reused). The bridge provides the *mechanism* for communicating. Thus bridges are usually regarded as being part of the Architecture. >From an architectural view each domain has an interface. When an outgoing bridge is invoked from within a domain to make to send a message to another domain an interface routine is actually invoked. The interface to this routine is fixed from the view inside the domain. Since the domain's view of the outside world is limited to this invariant interface, once the domain is working in one context, it is guaranteed to work in all other contexts. In the responding domain there is a similar routine that is invoked by otehr domains. This routine knows about the domain internals and will Do The Right Thing when invoked. It presents an invariant interface to all other domains. Again, since its interface to the outside world in invariant, the service domain will always behave the same way, regardless of context. The bridge is essentially a connection between these two interfaces. The assumption is that if the domains were developed independently, there will be mismatches in the interfaces. That is, the client's domain interface will have a slightly different format that the service domain's interface. These mismatches should be syntactic rather than semantic (i.e., the service domain must somehow be capable of satisfying client requests or it is the wrong domain to use). The bridge handles these mismatches by providing code that translates between the two interfaces. In practice this bridge code is usually placed in the outgoing interface routine of the domain initiating the communication. Thus a domain's outgoing bridge routine is initially just a shell with nothing in it; it just defines the outgoing interface. In a particular context the meat is put into the routine that invokes the specific interface routines of the target domain in the application. [On the receiving side, the interface faces the outside world, so the routine internals can be filled in when the domain is built or modified. In this sense the incoming interface routine's internals are really part of the domain internals.] Generally people refer to the combination of interface routine's code from both domains as The Bridge. However, usually only the outgoing routines have customized bridge code in them. There is a lot more to this, mainly concerned with synchrnonous vs. asynchronous communication, than I have mentioned. This is pretty well described in PT's wormhole paper on their web site. [PT and Kennedy-Carter worked together to produce most of the material.] It would probably be better if you read that and then came back with any specific questions. One parallel with the Booch/UML/OMT world is worth noting. The outgoing interface routine is analogous to a polymorphic interface shell in a specific context. There are a couple of subtle differences, though. First, the glue code that invokes a specific implementation is associated with the implementation in the UML case while it is associated with the invoker in the bridge case. More importantly, the UML interface is cast in stone regardless of the level of abstraction, genericity, etc.; all clients must invoke exactly that interface and all target implementations must somehow present that interface. Therefore, in the UML world if all clients and services agree on the interface, services are interchangeable without any code changes. In the S-M approach all clients and services can work together, even without interface agreement, but the price is a small amount of code must be written specific to each context, even when there is interface aggreement. [In the long term I believe this code will be generated automatically. Greg Eakman outlined an approach for doing this at the E-SMUG meeting earlier this year.] I hope this was the level of abstraction that you were looking for. > Also, is there a FAQ or archive so a newby can catch up without wasting > bandwidth or boring the masses? This is easier. Check the Project Technologies web page (projtech.com). There are a couple of papers there related to bridges. Also I think Kennedy-Carter has has some interesting stuff on bridges on their web (kc.com) -- but K-C has added extensions to S-M to support their tool, such as counterpart objects, so it is of interest philosophically for the discussions of blocking, etc.. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) re: subsystem re-use Kenneth Cook writes to shlaer-mellor-users: -------------------------------------------------------------------- At 11:00 PM 8/19/97 -0400, you wrote: >peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >So anyway - I'll bite - what's your *real* point? (It sounds like they >accidentally locked you into the ObjectWorld show overnight or something.) They told me it was "saturation training" :-) Sorry, no big hidden agenda. My real point was to find out what the users group community thought about subsystem reuse. The issues I described regarding distributed components are real issues - I have to make our model compiler work for this paradigm. I knew I could generate components from domains, but, given partitioning and other issues I've not yet mentioned ;-), do I need to/want to make subsystems into reuseable components? Specifically, the issues I wonder about are: o Must semantically separate subject matters be the only partition of reuse? ( more on this when I respond to Lahman's post ). o Is it acceptable to want to reuse an implemented cluster of objects, the same way I've reused libraries for years. In other words, can the method sustain the practice of shipping implemented subsystems and then using them by importing "stub objects" into a new model. Shipping a stub object model would be analogous to shipping an IDL interface to a service. o Can subsystem reuse go further to alleviate the problem of "one small change for man, one giant re-build for mankind"? -Ken Subject: Re: (SMU) Domain/Subdomain chart for a game/engine lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Theobald... > Video/Graphics, Sound/Music domains are still in the service domains? > Are they servers to anything? Maybe the renderer? Or vice versa -- > i'm not sure. I don't know a whole lot about handling heavy duty sound and video, so mine view was simply speculation. It just seemed to me that the video might require more sophisticated and different activities than spooling a sequence of WAV files to the sound card driver. Also the abstractions might be more complicated for video. You attributed these to the Renderer domain, as I recall. I was just suggesting that they might qualify as separate subject matter and, therefore, the Renderer domain might be split into two domains. They would still be service domains. Regarding two domains for the GUI: > Where do these domains go? Who are their clients? Who are their > servers? Is the Window Manager(GUI) different from Video/Graphics? Before we get too far into this, a caveat. You might be better off if someone with a bit more GUI experience lept in. I have never had to deal with the problem personnally, so the details are all hearsay filtered by inexperience. As they say, I have just enough knowledge to be dangerous. The Window Manager (this in not the OS window manager; a better name might be Screen Handler or GUI PIO) would be a very low level service domain, bordering on the architecture. The basic idea is that it is given a pile of data and a window identifier and it throws it out the the operating system or video drivers. It knows nothing about what the data means; the data is just a bunch of numbers, strings, bitmaps, etc. It is the buffer between meaningful abstractions in your domain (e.g., Scantily Clad Heroine) and screen images (i.e., Toolbars, Sprites, pixels, etc.). A higher level service domain would handle the management of meaningful graphic abstractions that have real (game context) relationships with one another. This domain knows that the door on the right leads to Treasure while the door on the left leads to The Pit. This domain knows about the state of the application (e.g., what direction Dauntless Hero is facing) and manages funneling the correct set of images to the Window Manager. In your original description I had assumed the Renderer would be the higher level domain but that it might be useful to farm out the nitty gritty dirver details to a lower level service domain. There is going to be a lot of realized code for rendering graphics. You aren't going to implement complex 3D rendering algorithms as OOA state machines. I would think most of this would be invoked in the lower level service domain where it is closer to the device drivers to get better performance. The Renderer would be a client of the Screen Handler. It would deal with higher level abstractions. The actual data from which the screen image was rendered would probably be represented in this domain as an attribute that was an abstract data handle; only the low level domain (or realized code in the architecture) would know how to process it. > > Finally, I am not sure that Story and World are separate domains. > > If Game has all the smarts, then these might well be combined -- > > they would essentially just be repositories for specification > > objects. World sounds like it might be only passive specification > > objects, in which case it could be included in Story. Even if each > > version has different game mechanics, I would think these go with > > Story rather than World. That is, what happens next would be a > > function of the state of Story, but the hit points for your Laser > > Guided Defrabrulator would be just be data. > > Story and World will have all the smarts -- as it stands now. My point was that World did not sound very interesting. If it is all specifications for the particular game context, then it may not warrant being separate from Story. > >From what you said I gather (without drawing it): > > Application Domain(s) > --------------------- > > 1. Game. > > Server domains: Story, World, Video/Graphics, Sound/Music, > Process I/O, and Database. My first cut would be to try it with Game talking only to Renderer, Story, and PIO. > Service Domain(s) > ----------------- > > 1. Story > 2. World > > Server domains for 1,2: Renderer > > 3. Video/Graphics > 4. Sound/Music > 5. Process I/O > > Server domains for 3,4,5: Software Arch > > 6. Database > 7. Renderer > > Server domains for 6,7: Software Arch, and O/S I would probably try Renderer as a higher level service domain that serves Story, World, and Game. It, in turn, requires the services of Video/Graphics, Sound/Music, and PIO. In this case Video/Graphics is my low-level GUI domain while Renderer is the high level GUI domain. I would also think that 3, 4, and 5 also interface with the OS (memory management, file services, etc.). Story, World, and (perhaps) Game might be direct clients of database. > Archtectural Domain(s) > ---------------------- > > 1. Software Arch > > Server domains: MFC or some commerical window builder, O/S, > Network, Programming Language. > > 2. MFC or some commerical window builder > > Server domains: O/S I was careless. MFC or the window builder are more logically implementation domains. > Implementation Domain(s) > ------------------------ > > 1. O/S > 2. Network > 3. Programming Languages > > Server domains for 1,2,3: None A dubious digression: Having said all this, I would not put too fine a line on the client/service relationships. These could change a good deal, depending upon the final abstractions that you choose to deal with. For example, when the game starts up the player may request loading of a saved game. Presumeably Game gets this request somehow. At this point Game could request Story to load its state and Story would, in turn, make a request to Database. Alternatively Game could make a request directly of Database to load the state of the game. Which choice you make will depend upon your overall concept for what the "state" of the game is. It could be a suite of instances in Story, in which case Story probably wants to manage their creation directly. Or it could be a set of attribute values strewn around Game, Story, and World so that it might make sense for Game to manage the dispersement of the data from Database. Peter Fontana will tell you that the main purpose of the hierarchy on the Domain Chart is to define requirements on service domains. Your initial domain chart is largely an educated guess. Once you analyze Game, you then refine your requirements for services such as Story that Game actually wants to access directly. Then you move down to the next layer of services, analyze them, and define the actual requirements on the layer below that. This is a rational and consistent approach that defines the Domain Chart relationships on an as-you-go basis. [I have some problems with this because the realities of scheduling require more parallel development of domains, but that is another story.] Peter's point is that it is difficult to account for *every* detail of client/service relationships without doing domain analysis of the clients. What I am getting at here is that your initial Domain Chart should have a pretty good idea about what domains will be used and what they are, but the details of exactly who is client to whom will evolve over time. The important issue is that client domains determine what service domains are needed and what they do. The second important issue for the Domain Chart is that the arrows specify client/service (or flow or requirements) but not communications. For example, in a Windows systems the winproc procedure is usually feeding some pretty low level service domain. However, that low level service domain is almost always initiating requests *to* the application domain. The application is quite content to sit on its thumbs (in a nonthreaded app) until that low level service domain tells it to do something. The service the application is requesting is, "Tell me what to do next" and the low level service simply obliges. The client domain defines the details of the communication and who initiates it based upon its needs; the service domain just does whatever is needed. > Be assured, I appreciate your time in answering these questions. I > know how valuable your time is. Opinions are cheap and I have an oversupply. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) Re: subsystem re-use Kenneth Cook writes to shlaer-mellor-users: -------------------------------------------------------------------- At 09:09 AM 8/20/97 -0400, you wrote: >lahman writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >Responding to Cook... > >As Peter pointed out, this depends upon one's definition of "reuse" and >it also depends upon one's definition of "subject matter". Alas, the >exposition in the methodology is a tad vague about the latter. For lack >of a better suite of criteria I tend to use the following to define the >bounds of a "subject matter": > >- All the elements must be logically and closely related. > >- All the elements should be at the same level of abstraction. > >- The elements are independent in their representation from other >subject matters. After reading your comments and talking with others, I'm seeing subject matter as an important criteria for a "good" domain, but not the only criteria. Partitioning for reuse is also one of the criteria. So, if I have a subsystem of 6 objects that describe the shape and layout of a semiconductor wafer, and I find I'm developing features like Wafer Probe, Wafer Pad Inspection, Wafer Alignment, and Wafer Slicing, I could pull the subsystem out and make it a domain. >With the current software technologies, things are reusable through >their interfaces. To be reusable the interfaces must be invariant with >context. In particular, a reusable component should not have knowledge >of its context. This is not the case within a domain. All objects are >intimately related and they have very explicit knowledge of the domain >structure (e.g., relationships used for navigation) in their >implementations (i.e., state actions that navigate the relationships). >The event naming conventions and addressing schemes in the >notation are specific to a domain, which means that the interfaces >(events, accessors) are not invariant with context. But think about developing models for an Enterprise over time. The subsystem you develop in 1997 will have no knowledge of objects, relatinships, accessors you will model in 1999. So from the point of view of the 1999 subsystem, the older subsystem (SS) is invariant, if it is reused without modification. Relationship drawn between the 1999 SS and the 1997 SS present a problem, but only if you require the model to use the link in both directions. The method says that the link is available in both directions, but does not require its use and does not require bi-directional links to be implemented (I've worked on translators that implemented just the direction of the formal reference). > >In my view the methodology simply does not support subsystem reuse; its >basic unit of reuse is the domain. You seem to be suggesting that the >notation should change to insert the same level of abstraction (or >indirection) represented by inter-domain bridges for communication >between subsystems. I think the method supports it if you are willing to have some restrictions in your use of the models. Basically, when you encounter a SS model, you have to know whether it is a "stub" model or a "skel" model, to borrow the CORBA terms. In my example, when the 1997 SS model is imported into the same domain as the 1999 SS, the 1997 SS is a stub model, and all other objects are a skel model. Am I changing the notation? Maybe not. If I know at build-time which SS is a stub, and which is a skel, I can generate the right thing. If I want to enforce the right use of stub models within a tool, I would need to know this during modeling time. But this information does not have to live in the notation. Maybe I'd use different colored post-its :-) > Basically I don't see the need for this because I >think that if a subsystem's subject matter is independent enough of >context to be reusable, then it qualifies as a domain. Yes, I agree with this. But bridges present a problem for me: While bridges are intented to be implementation independent, the one implementation they have a hard time mapping to is OO. In some cases, intiator domains will want to hold onto, and operate on, specific instances of objects in the receptor domains. To do this, I wind up defining bridge operations like unique_id foo_handle createFoo(); void doSomethingToFoo(unique_id fhandle) void doSomethingElse(unique_id fhandle) void destroyFoo(unique_id fhandle) void setFooMemberA(unique_id fhandle, string anA) void setFooMemberB(unique_id fhandle, string anB) string theA getFooMemberA(unique_id fhandle) But returnAllBarsRelatedToFoo(unique_id fhandle) !! No way to do this!! and similarly for events. Why am I going through all this, when I've already got the interface defined on the receptor side? The answer is actually the same reason that other methods encourage (but don't require) interfaces to be defined in abstract base classes - you need to have the interface defined independently from the implementation, to allow implementations to change underneath invariant interfaces. Bridges do this, so do abstract base classes, and so do stubs and skels. But the bridges have some restrictions that make a full OO implementation difficult. 1) As in the rest of the method, it is not settled whether object references should be considered a native type. 2) Only native types can be passed as bridge parameters. There is no way to pass structured data, or sets. 3) There is no way to return structured data, or sets. 4) There is no way to form a relationship to a set of objects in the receptor domain. If I instantiate a gaggle of Foo's, I have to store foo unique id's as a attribute in an "Foo Storage" object on the initiator side, and instantiate a set of these Foo storage objects (note the semantic pollution we were trying to avoid with bridges!) I won't even get into inheritance - that is a whole other discussion, You can see that mapping bridges to an OO implementation forces as many compromises to that paradigm as I forced upon the method with my Subsystem reuse proposal. My SS reuse proposal is weak because it would be difficult to change the implementation without changing the interface. I like bridges because they force you to separate the interface from the implementation. What I would really like is to have two choices of bridging available. The first is bridges the way they are now. The second requires mapping of objects to objects and methods to methods. I've recently implemented one of these bridges to a specific domain - it worked quite well. I did not need any External Entities or Bridge Operations. I just specified, in a small language, the object, method, and event mappings. I even mapped accessors, creator events and destructor events. My goal is to provide the best facilities to help users create components, without breaking the method, or making too many special things to learn. -Ken Subject: Re: (SMU) Bridges iansm@kc.com (Ian sm) writes to shlaer-mellor-users: -------------------------------------------------------------------- > "Anil K. Arya 6192" writes to shlaer-mellor-users: > -------------------------------------------------------------------- > [...] > Your observations coincide with my own. We are currently looking into > defining our own internal Bridge Policy because of the lack of > detailed specifications available for them. [...] > Note that we're using KC's flavour of Shlaer-Mellor, so some of the > "holes" may be peculiar to them, but this doesn't seem to be the case > (e.g. the book OBJECT LIFECYCLES Modeling the World in States > pp138-140 barely discusses the above issues, if at all). We have tried to cover all the issues concerning Bridges in a technical note (available on our Web Site; Note number CTN 47 "Bridges in OOA/RD"). This note gathers together our experiences over the last 7 or so years in applying OOA/RD to a wide variety of systems. This has been revised and updated by our "OOA 97" paper (CTN 53) which will be on our Web site shortly. > In particular areas such as the following seem to need defining:- > > 1. Bridge counterpart mappings. > - purpose of (to avoid domain pollution, where one domain is > knowledgeable of another) > - which are allowed, with rationale > - which are disallowed, with rationale Section 5 of the note covers the ideas of layers of abstraction and terminators both in application level ("real world") and in more abstract domains. Section 6 goes on to discuss counterparting and in particular the extent to which one domain is "aware" of others. The aim of the approaches outlined is to avoid domain pollution where one domain knows about another specific domain. The note describes all the mappings that we currently advocate and are supported by ASL and those that are not allowed. For example, the concept of specific/generic counterparting provides for implcit mapping between things that happen to the specific object and operations to be executed on the generic object. Analysts cannot, however, place *explicit* mappings in this direction as this would involve the kind of domain pollution that we are trying to avoid with specific/generic mappings. > 2. Bridge operations > - What processing is allowed/disallowed on the bridge, if any > (again, with rationale). All the allowed operations are described in this note and in the ASL reference manual. The method supports explicit mappings via terminator operations (services and events) in one domain and services/events accepted by another domain. Counterpart relationships can be declared and utilised by the brdiges to support this. Specific/Generic counterparts provide for implicit mappings (where the mappings are not visible on some of the domain models) to allow clean domain separation. > 3. Bridge mechanisms > - What mechanisms should be supplied by the architecture The note describes the way in which the bridges execute at run time. Implicit spefic to generic mappings are defined by showing a section of ASL that *implements* the mapping described. This allows the possibility that an architecture either: - Implements the mapping directly (in the manner described by the ASL) or: - Generates the ASL shown first and then treats the ASL as any other analyst written ASL > 4. Bridge creation and deletion policies > - Are there special considerations for counterpart mappings > that create an object instance in the other domain > (e.g. the instance must exist before the counterpart can be > used). > - Similarly for deletion of counterpart/original instances. Again, Section 6 describes our rules for this. > Our policy is aimed at protecting the purity of our domains by > utilising counterpart mappings in all cases. Thus, the mapping between > domains is held in the bridge. Each domain has no knowledge of any > other and is, therefore, not "polluted". The overriding purpose of > this is to permit our domains to be truly reusable. We have very similar aims, and I think we have largely achieved them. I would be very interested in hearing opinions to the contrary. Responding to H.S.Lahman - thank you for crediting us with contributing to the "Wormholes" paper: > PT and Kennedy Carter worked together to produce most of the material but I have to admit that it was entrirely Steve and Sally's own work. Ian Wilkie P.S. This message would have gone out sooner but I fell foul of the recent anti-spam changes to the mailer since I subscribe to this group with a different e-mail address to my "official" one :-( ===================================================== Kennedy Carter, 14 The Pines, Broad Street, Guildford Surrey, GU3 3BH, U.K. Tel: (+44) 1483 483 200 Fax: (+44) 1483 483 201 Further Information: http://www.kc.com or info@kc.com ===================================================== Subject: Re: (SMU) re: subsystem re-use lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Alas, Cook and I both have spastic mailers that get confused about replying to SMUG. I recently re-sent his message rather than forwarding this one after discovering the rely only went to him. Sorry about that. Responding to Cook... Regarding hard-wired context in the OOA notation: > But think about developing models for an Enterprise over time. The subsystem > you develop in 1997 will have no knowledge of objects, relatinships, accessors > you will model in 1999. So from the point of view of the 1999 subsystem, > the older subsystem (SS) is invariant, if it is reused without modification. > > Relationship drawn between the 1999 SS and the 1997 SS present a problem, > but only if you require the model to use the link in both directions. > The method says that the link is available in both directions, but does > not require its use and does not require bi-directional links to be > implemented (I've worked on translators that implemented just the direction > of the formal reference). I'm afraid you completely lost me here. I think we are talking about reuse at two different levels. Are you referring to reusing a subsystem implementation? Given a miscommunication, let me see if I can clarify my concern. My issue is at the OOA level. If I want to reuse a subsystem in another application I have to move the OOA for that subsystem to some domain in that other application. Because it is a subsystem it has to interact at the OOA level with the objects in the domain where it will be reused. To verify the full domain's correctness (e.g., simulate) I have to see its objects interact with the reused subsystem at the OOA level before generating code. When I reuse a domain the OOA for the reused domain is unchanged. I can look at that domain's OOA in either application and it is identical. Moreover, if my tool supports multi-domain simulation, I can simulate with it in either application without any changes to the OOA, just the bridges. But this is not true for a subsystem. If my subsystem has an action with something like: generate ABC1:doit(data_packet) to abc_inst_handle or x = abc_inst_handle.attribute_1 where abc_inst_handle refers to an object instance in the original domain that is outside the subsystem, there will be no matchup to the names in the new domain. Worse, if my subsystem action has to do any relationship navigation to get to abc_inst_handle, that will be specific to the original domain. To simulate that subsystem in the new context I will have to change the action, and that is why I feel there is no support for susbsystem reuse in the notation. > I think the method supports it if you are willing to have some restrictions > in your use of the models. Basically, when you encounter a SS model, > you have to know whether it is a "stub" model or a "skel" model, to > borrow the CORBA terms. In my example, when the 1997 SS model is imported > into the same domain as the 1999 SS, the 1997 SS is a stub model, and > all other objects are a skel model. > > Am I changing the notation? Maybe not. If I know at build-time which > SS is a stub, and which is a skel, I can generate the right thing. > If I want to enforce the right use of stub models within a tool, I would > need to know this during modeling time. But this information does not > have to live in the notation. Maybe I'd use different colored post-its :-) Alas, I don't know enough about CORBA to follow this with confidence. However, this is the section that made me think you are reusing the subsystem implementation rather than the OOA. This is probably do-able for event and accessor names. I think there would still be a problem with relationship navigation to identify non-subsystem target instances. What is not clear is what the OOA in the new application looks like. Since you *must* verify the domain in which you are embedding the reused subsystem, how is the subsystem expressed in the OOA notation to allow this? At this point I am worried that we are talking past each other, so I'll defer responding to the rest of the message until I figure out what is going on here. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com 'archive.9709' -- Subject: (SMU) Inter-Domain Event Sequencing "Anil K. Arya 6192" writes to shlaer-mellor-users: -------------------------------------------------------------------- Are two events, say A and B, sent by an object instance in one domain to the same destination object instance in another domain via a terminator *guaranteed* to be received in the order of transmission (that is, sent as AB and received as AB)? If this *is* specified by the method, I would appreciate a reference to the relevant piece of documentation. Thank you. -- Anil K Arya Simoco Europe Ltd. anil.arya@cambridge.simoco.com P.O. Box 24, St Andrews Road http://www.simoco.com CAMBRIDGE CB4 1DP, ENGLAND Tel/Fax: +44 1223 586192/314812 (This is not an official communication) Subject: Re: (SMU) Inter-Domain Event Sequencing peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 07:46 PM 9/1/97 +0100, shlaer-mellor-users@projtech.com wrote: >"Anil K. Arya 6192" writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >Are two events, say A and B, sent by an object instance in one domain >to the same destination object instance in another domain via a >terminator *guaranteed* to be received in the order of transmission >(that is, sent as AB and received as AB)? No. If you step up to the bridging philosophy hinted at in OOA96 - then you don't even send events explicitly between domains. You may invoke a service of the server domain, and if the current implementation of that domain (which is invisible to the outside world) calls for an event, then the service - not the "invoking" instance in the client domain - sends the event. Even if you wanted to consider the notion of mapping events between domains as is common in OOA91 shops, then I'd still say no order is guaranteed. Of course, your architecture lead has the last laugh. If an analyst insists that they need to rely on this ordering, and your architecture doesn't support it, then all the rules in the world won't make the system run right. ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice: +01 508-384-1392 | peterf@pathfindersol.com fax: +01 508-384-7906 | ____________________________________________________| Subject: (SMU) attributes dependent on current state? Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- (My appologies if this arrives twice - I think I'm having problems with the anti-spam filter) I have a simple philosophical question A model that I'm working on is simplified if the answer is yes. In OOA96 the "current_state" attribute was removed from the information model and became inaccessable. The main reason for this was the additional coupling it provided between objects. OOA96 also introduced the concept of methematically dependent attributes. These allow many transforms to be eliminated from state actions and allow improved clarity of the information model. What I would like to know is: can I create a boolean attribute that is mathematically dependent on the current state of the object for which it is defined. If you want an example of this, consider the ODMS example from the PT training course. Imagine that the robot object has a "is_moving" attribute. I could specify its value in each state but this would result in redundant data storage because its value _is_ dependent on the current state of the robot object (its true except in states 1, 4 and 8). (In case anyone's wondering, the reason why its important to get this right is that I'm looking into harware architectures. A variable-attribute translates into a register (1 or more latches or flip-flops) plus the combinatorial logic to work out its value. A mathematically dependent attribute requires only the combinatorial logic.) Of course, I could create a code generator that detects attributes that are unamibguously assigned a known value in every state; and which are not assigned from any other object-instance. Having detected this fact (possibly with coloration) I could treat the write accessors as a canonical specification of the dependency. That does seem to be an unduely complex solution. So, should I be allowed to specify that an attribute's value is mathematically dependent on the state of its owning object? Dave. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Tamerton Road, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com For embedded Systems Support mailto:armapps@gpsemi.com Subject: Re: (SMU) Inter-Domain Event Sequencing "Anil K. Arya 6192" writes to shlaer-mellor-users: -------------------------------------------------------------------- Thus, if a domain speaks to another which turns a physical light on and off, then it would invoke services to do so. Two consecutive calls to LightOn and LightOff, therefore (given that ordering of the events is indeterminate, should that be the way the services are implemented), would mean that the client domain cannot be sure whether the light is actually on or off. The OFF event could overtake the ON event, leaving the light in a totally unexpected and undesired state. How would one overcome this scenario (given that it uses event-implemented services)? Peter J. Fontana writes: > peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > At 07:46 PM 9/1/97 +0100, shlaer-mellor-users@projtech.com wrote: > >"Anil K. Arya 6192" writes to > shlaer-mellor-users: > >-------------------------------------------------------------------- > > > >Are two events, say A and B, sent by an object instance in one domain > >to the same destination object instance in another domain via a > >terminator *guaranteed* to be received in the order of transmission > >(that is, sent as AB and received as AB)? > > No. If you step up to the bridging philosophy hinted at in OOA96 - then you > don't even send events explicitly between domains. You may invoke a service > of the server domain, and if the current implementation of that domain > (which is invisible to the outside world) calls for an event, then the > service - not the "invoking" instance in the client domain - sends the event. > > Even if you wanted to consider the notion of mapping events between domains > as is common in OOA91 shops, then I'd still say no order is guaranteed. Of > course, your architecture lead has the last laugh. If an analyst insists > that they need to rely on this ordering, and your architecture doesn't > support it, then all the rules in the world won't make the system run right. > -- Anil K Arya Simoco Europe Ltd. anil.arya@cambridge.simoco.com P.O. Box 24, St Andrews Road http://www.simoco.com CAMBRIDGE CB4 1DP, ENGLAND Tel/Fax: +44 1223 586192/314812 (This is not an official communication) Subject: Re: (SMU) Inter-Domain Event Sequencing kearnan@Summa4.COM (Gregg Kearnan) writes to shlaer-mellor-users: -------------------------------------------------------------------- Subject: Re: (SMU) Inter-Domain Event Sequencing peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 10:04 AM 9/2/97 +0100, shlaer-mellor-users@projtech.com wrote: >"Anil K. Arya 6192" writes to shlaer-mellor-users: >-------------------------------------------------------------------- > ...The OFF event could overtake the ON event ... >... How would one overcome this scenario (given that it uses >event-implemented services)? OK - let's remind ourselves what we're discussing: rules of event ordering. The assertion that I made was the rule of OOA about event ordering does not apply between domains - since each domain is it's own universe. The point is YOU DO NOT EXPLICITLY SEND EVENTS BETWEEN DOMAINS. If you do not agree with this conclusion, then go right ahead and extend the event ordering rules to apply between domains - for your project. Again - we're discussing rules. The way a client domain imposes its will on a server domain is through the flow of requirements. In this situation, where the Lamp_Management domain has a TurnOn service and a TurnOff service, then one of the requirements on Lamp_Management is that an invocation of TurnOn followed by an invocation of TurnOff SHALL leave the designated lamp hardware in an off state after some period of time. This is reliable - this requirement is a project-specific RULE of your system. Continuing: if the Lamp_Management domain chooses to implement these services through asynchronous means - let's say events to a Lamp object - then it may need to impose requirements on one of its servers: the Software_Architecture. That requirement would be that events are received in the same time order they are sent - or at least allow coloring/tagging to support this in some cases. If you were to assert that this Software_Architecture requirement is global to all domains in your system that send events from a synchronous service, I'd easily agree. If you wanted to say this is a "Rule of OOA", I ask where you read it, expect you would have no answer, and wish you were right anyway. Rules aside - I expect that most software architecture developers/vendors recognize this implicit rule and support the "right" behavior. ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice: +01 508-384-1392 | peterf@pathfindersol.com fax: +01 508-384-7906 | ____________________________________________________| Subject: Re: (SMU) bridges Michael.French@cambridge.simoco.com (Michael S. French x5138) writes to shlaer-mellor-users: -------------------------------------------------------------------- This is a note detailing our policy on bridges. It is directed at the user group as the ideas deviate from the norm and we would appreciate opinions and ideas. The fundamental concept behind our thoughts is domain pollution. We have a need to concentrate upon this as our domains MUST be reused on future systems. In it's extreme form we decided that if a domain knows of other domains 'at all' it would be polluted. A domain provides a service and that 'service' is modelled. These services are used by other domains when the system is created. To this end we discourage external events and sync-services as they indicate a knowledge of an external domain. We have not disallowed them we have mearly encouraged the use of mappings from the internal structure of the domain ie .. attribute - attribute internal_event - internal_event and others. We considered the bridge to be a relationship between two domains and a counterpart mapping to be one 'instance' of said relationship. In this way the domain is analysed in isolation, to the mission statement and domain requirements, the bridges being system knitting elements. We believe this gives us greater flexibility in our bridges and allows greater domain re-use. It also discourages analysts from imposing requirements upon one another as they know little or nothing of other domains. The above requires that the architecture support some form of counterpart mapping and that it supplies a means to call a bridge process without analyst intervention. We have accomplished this by means of an auto bridge tool that inserts bridge calls at the appropriate point and forms mappings held on the bridge. As explanation :- An analyst has analysed a UI domain that has a displayed item. The system requires the user to know of an occurence within two other domains. One is a train domain and one is an alarms domain. In the train domain an object is created when a train arives at a station (how is not discussed) this object is counterpart mapped to the displayed item in the UI domain. The object in the UI domain is an active object and is therefore created via a creation event this event is initiated from the bridge. The originating domain did not explicitly 'fire off' an external event this occurred because the object was created (infact the train object is passive). Similarily the creation of the train object caused an event to be initiated in the alarms domain, this event in turn is mapped to the creation event in the UI domain to display an alarm 'displayed item'. At no time was any external event or sync-service called to 'display' these occurrences to the outside world. The key to this is that the domains know nothing of each other. Each domain deals with objects, attributes and events within its influence and Unbeknown to it actions are performed in other domains as a result of bridge mappings. It can be seen that if in a future system alarms are logged and not displayed a bridge change will accomplish this with no domain change, as the domain knows not that the alarm is displayed. I must admit that I have seen a lot of material on external events and sync-services and am therefore worried that we have missed something. If so could someone please explain a) What we are missing b) What are the flaws in the above approach yours sincerely M.S.French Subject: Re: (SMU) attributes dependent on current state? "Greg Wiley" writes to shlaer-mellor-users: -------------------------------------------------------------------- > I have a simple philosophical question A model that I'm > working on is simplified if the answer is yes. I think the answer is "no." > What I would like to know is: can I create a boolean attribute > that is mathematically dependent on the current state of the > object for which it is defined. > > If you want an example of this, consider the ODMS example from > the PT training course. Imagine that the robot object has a > "is_moving" attribute. I could specify its value in each state > but this would result in redundant data storage because its > value _is_ dependent on the current state of the robot object > (its true except in states 1, 4 and 8). In this case, you are trying to help the architecture with your analysis, which violates the spirit of OOA. The state of an object drives its behavior. If you need that data for anything else, it should be an attribute. OTOH, if the is_moving attribute affects the object's behavior, then the state model may need to change. > (In case anyone's wondering, the reason why its important to get > this right is that I'm looking into harware architectures. A > variable-attribute translates into a register (1 or more latches > or flip-flops) plus the combinatorial logic to work out its > value. A mathematically dependent attribute requires only the > combinatorial logic.) If you need the is_moving attribute as data but don't want to waste the space/time, maybe you need an architecture that allows you to color an attribute to behave in the manner you described so to eliminate explicit assignment in the implementation. But the analysis should still show the writes to the attribute. Providing a function dependent on the current state hides the facts. -greg Subject: Re: (SMU) bridges peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 06:29 PM 9/2/97 +0100, shlaer-mellor-users@projtech.com wrote: >Michael.French@cambridge.simoco.com (Michael S. French x5138) writes to shlaer-mellor-users: >-------------------------------------------------------------------- > ... >In it's extreme form we decided that if a domain knows of other domains 'at >all' it would be polluted. > ... >To this end we discourage external events and sync-services as they indicate a >knowledge of an external domain. While this message could form the basis for a non-trivial consulting relationship, for this forum let me boil the discussion down to a single axis tradeoff: how explicitly/clearly are inter-domain aspects of the system are modeled, versus how simple and pure can the abstractions be kept in a single domain. As with most trade-offs, the "right" answer for each project varies, and it is unlikely that either extreme end of the spectrum is "right" for any project. My opinion - based on some experience - is you want to accomplish the following with bridging: - keep your techniques simple: they are easier to implement, debug, understand, and will convey more meaning to a wider audience - keep most your dependancies explicit - much of the benefit of OOA is through clarity of expression - only use implicit mappings when explicit dependancies would be overly complex and difficult to understand anyway through explicit mappings - BUT minimize and heavily document these "subtleties" Basically, unless you have a fully developed method to express, maintain and debug the sophisticated mappings you had described, then you are "hiding" them from the OOA world. The more you use implicit mappings, the more likely it is that your OOA analysis does not accurately reflect the true nature of the system. Your bridge-free domains may be resistant to change, but I'll bet your bridging data isn't quite so robust. Take a deep breath - take another - now free your mind and envision a single domain: a Turing Machine. It can solve all problems - provided you've bridged it properly to the realized world... OK - exhale. Not fair you say - true. But that is one end of the spectrum. My experience shows that good, solid modeling and a reasonable effort to capture the true of the nature of the system is very powerful - including when a domain realizes it can't do everything itself. Sure - "some maintenance is required", but at least you can see it explicitly. Would you rather change the spark plugs 3 times in 50,000 miles on a '67 Mustang with a 289, or only once in 50,000 miles on a '92 Taurus with a 3.8? I'll do all 8 on the Mustang 5 times before I get the damn back 3 plugs out of the Taurus once. >We considered the bridge to be a relationship between two domains and a >counterpart mapping to be one 'instance' of said relationship. This is a pretty mainstream concept. Get CTN 53 "OOA97" from www.kc.com - they've got a pretty complete set of bridging concepts. > ... >It can be seen that if in a future system alarms are logged and not displayed a bridge >change will accomplish this with no domain change, as the domain knows not that the >alarm is displayed. This "feature" is actually a significant point of concern. One can argue that you might have significant portions of your system that aren't modelled anywhere. >I must admit that I have seen a lot of material on external events and >sync-services and am therefore worried that we have missed something. If so >could someone please explain > > a) What we are missing It appears you have a reasonable grasp on they types of bridging techniques commonly applied. Without understanding the history of your Software Architecture, it is hard to assess if you have properly implemented "standard" bridging concepts. If you haven't, it possible you have condemned a technique when it was merely the support for the technique that needed fixing. > b) What are the flaws in the above approach You can get too far down the end of the tradeoff where you aren't modeling valid elements of your problem space, and your bridging data becomes difficult to understand and maintain. ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice: +01 508-384-1392 | peterf@pathfindersol.com fax: +01 508-384-7906 | ____________________________________________________| Subject: Re: (SMU) bridges "Greg Wiley" writes to shlaer-mellor-users: -------------------------------------------------------------------- > In it's extreme form we decided that if a domain knows of other domains 'at > all' it would be polluted. A domain provides a service and that 'service' is modelled. > These services are used by other domains when the system is created. > > To this end we discourage external events and sync-services as they indicate a > knowledge of an external domain. We have not disallowed them we have mearly encouraged > the use of mappings from the internal structure of the domain ie .. I'm not sure what you mean by 'at all'. Each domain has knowledge of what services it performs for other domains. But each domain also has knowledge of what services it requires of other domains. > As explanation :- > An analyst has analysed a UI domain that has a displayed item. The system requires > the user to know of an occurence within two other domains. One is a train > domain and one is an alarms domain. In the train domain an object is created > when a train arives at a station (how is not discussed) this object is counterpart > mapped to the displayed item in the UI domain. The object in the UI domain is an > active object and is therefore created via a creation event this event is initiated > from the bridge. The originating domain did not explicitly 'fire off' an external > event this occurred because the object was created (infact the train object is > passive). Similarily the creation of the train object caused an event to be > initiated in the alarms domain, this event in turn is mapped to the creation > event in the UI domain to display an alarm 'displayed item'. At no time was any > external event or sync-service called to 'display' these occurrences to the > outside world. > > The key to this is that the domains know nothing of each other. Each domain deals with > objects, attributes and events within its influence and Unbeknown to it actions are > performed in other domains as a result of bridge mappings. But where is the analysis of each specific application? If the train domain stands alone and describes "how trains work" independent of any particular system, then it is probably best used as a service domain for your applications that deal with trains. An application domain may use the services of both the train domain and the UI domain. It seems that in your scenario, you build distinct applications by configuring bridges. This prevents you from capturing a complete analysis of the application domain for each system developed. I think this approach is limited to developing very similar appli- cations or places too much and inappropriate information in the bridges. If, instead, the train domain IS your application domain and you simply wish to implement it on various architectures using inter- changable UI and other service domains, you still don't need to pollute your train domain. Your train domain describes what external services are required. But these service requirements are still expressed in the vocabulary of the application domain. "announce that has entered " is modeled as a wormhole. Since, in this case, train is your application domain, you will know that you require such an external service to realize the domain's mission. The resulting computation in other domains remains unspecified until you attach a specific service to that wormhole via a bridge. -greg Subject: Re: (SMU) bridges Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- Michael S. French x5138 wrote: [...] > In it's extreme form we decided that if a domain knows of other > domains 'at all' it would be polluted. A domain provides a > service and that 'service' is modelled. These services are used > by other domains when the system is created. > > To this end we discourage external events and sync-services as > they indicate a knowledge of an external domain. We have not > disallowed them we have mearly encouraged the use of mappings > from the internal structure of the domain ie .. [...] Your description meshes well with my ideas about bridges. However, I would not go quite as far as you in some ways. I would not go too far down the road of implicit inter-domain mappings. I would, however, make greater use of intra-domain mappings. All stimulation to a domain MUST be via an input wormhole. We never allow an attribute to change, or an event to be generated, without interaction from our analysis of the domain. I am playing with the concept of mapping attibutes to wormholes in much the same way as mathematically dependent attributes are mapped to other attributes. Note that this mapping is entirely within the scope of the domain - its not an inter-domain mapping. There are several ways in which behaviour within a domain can cause output to a wormhole. Again, I like the idea of attribute mappings in some cases (wormhole is dependent on attribute); but not always. There are times when direct wormhole invocation is necessary. The wormholes should always be meaningful from the point of view of the analysed domain. An asynchronous wormhole invocation should be, essentially, a comment. Otherwise you're going to start modelling behaviour. Finally, remember all the wormholes that tend to be lumped into transform processes: a := a * b The multiplication is a wormhole invocation. Normally this goes into the architecture but it might go elsewhere. I may have a dedicated floating point domain; or it might be more obscure. Most of the descriptions I see of bridges assume a very simplistic view of the world, with a hierarchy of application, service, architecture and implementation domains. The world just isn't that simple. A big system will contain many bridges, some will be translation steps and others will be run-time mappings. Some might even be both. Dave. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Tamerton Road, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com For embedded Systems Support mailto:armapps@gpsemi.com Subject: Re: (SMU) Inter-Domain Event Sequencing "Anil K. Arya 6192" writes to shlaer-mellor-users: -------------------------------------------------------------------- Peter J. Fontana writes: > [snip] > OK - let's remind ourselves what we're discussing: rules of event ordering. > The assertion that I made was the rule of OOA about event ordering does not > apply between domains - since each domain is it's own universe. This is what I wanted to know. I have not seen it written down anywhere, and was wondering if it was, and if so, where. > ...If you were to assert that this Software_Architecture > requirement is global to all domains in your system that send > events from a synchronous service, I'd easily agree... Yes, this is what I would assert. > ...If you wanted to say this is a "Rule of OOA", I ask where > you read it, expect you would have no answer... No - I wanted to know whether it was a "Rule of OOA". My concern was that it *was* stated somewhere, but I hadn't spotted it. > ...and wish you were right anyway. Yes, I too wish it was explicitly and clearly stated, as were many other parts of the method. > > Rules aside - I expect that most software architecture developers/vendors > recognize this implicit rule and support the "right" behavior. > Because it's not a "Rule of OOA", i.e. is undefined, then, strictly, we as analysts should not rely upon it. Thus, our models are neutral to changes in architecture. However, it is likely to (greatly) complicate these models. Imposing it as a requirement on the architecture domain seems to be the best solution. -- Anil K Arya Simoco Europe Ltd. anil.arya@cambridge.simoco.com P.O. Box 24, St Andrews Road http://www.simoco.com CAMBRIDGE CB4 1DP, ENGLAND Tel/Fax: +44 1223 586192/314812 (This is not an official communication) Subject: Re: (SMU) bridges -Reply Ed Wegner writes to shlaer-mellor-users: -------------------------------------------------------------------- Dave Whipp wrote: >>> Dave Whipp September 3, 1997 8:20 pm >>> Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- Michael S. French x5138 wrote: [...] I am playing with the concept of mapping attibutes to wormholes in much the same way as mathematically dependent attributes are mapped to other attributes. Note that this mapping is entirely within the scope of the domain - its not an inter-domain mapping. This meshes with two mental models of analysis I have often considered, but until this comment I never considered them in combination. They are: 1. I sometimes like to view all "accessor processes" as wormholes. These would most often be wormholes to the architecture, but in some cases are actually wormholes to (typically, synchronous) services in other domains. 2. I have been internally advocating using synchronous services within the domain where they are defined - and associating each synchronous service to an object. This is because I am often disturbed by how I and others model relatively "complex" state action processes as multiple states - rather than as LARGE actions within a single state. There appears to me to be a missing (or at least largely un-acknowledged) part of an analysis mental model in OOA to address this human modelling error. I suspect it is largely due to most CASE tools not supporting ADFD's (and SDFD's) in favour of action language(s). I take Whipp's suggestion to be a combination of these two. Ed Wegner Tait Electronics Ltd Christchurch, New Zealand Subject: Re: (SMU) Inter-Domain Event Sequencing lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- For those wondering where I was, I took a few days of incredibly well deserved vacation. Everyone who missed me, lean out of your office and shout, "He's baaaaaack!". Responding to Arya... > Thus, if a domain speaks to another which turns a physical light on > and off, then it would invoke services to do so. Two consecutive calls > to LightOn and LightOff, therefore (given that ordering of the events > is indeterminate, should that be the way the services are > implemented), would mean that the client domain cannot be sure whether > the light is actually on or off. The OFF event could overtake the ON > event, leaving the light in a totally unexpected and undesired state. > > How would one overcome this scenario (given that it uses > event-implemented services)? This is a classic problem of asynchronous communications. This problem would exist regardless of the methodology involved. The following is just an amplification of the points made by others but I feel it is important to distinguish between what the problem is, what the OOA assumptions are, and what the architecture can implement. As Fontana pointed out, in the OOA the communications between domains are assumed to be asynchronous (though the *mechanisms* of communications are synchronous, a la the Wormholes Paper). In the asynchronous situation you may not have any control over the ordering of the events. For example, the LightOn event might be routed through a network node that had a glitch and the message spends a while in a queue before continuing on its way. Meanwhile, by the time the router processed the LightOff message it may have known about the glitch and routed it through an alternative path that had no delay. The classical way to deal with this (in the OOA) is simply not to send the LightOff message until you receive an acknowledgement that the LightOn message was processed. [Actually the Wormholes Paper provides a shorcut for this case in that the synchronous service sending the LightOff message can synchronously return an acknowledgement that the event was received (or timed out). In this case that would be good enough. This is a minor variation on the theme proposed by Kearnan.] Whether you use wait states, synchronous aclnowledgements, syncronous data accesses, or whatever, your OOA has to deal with the fact that the communication is asynchronous and, therefore, the order of message delivery may not always be what one would expect. In the OOA the assumption is that interdomain communication is asynchronous since this is the worst case scenario; if it works for asynchronous it works in all cases and is, therefore, independent of the actual architecture and envoironment used. However, if the particular application can be built using a simpler architecture for interdomain communications, then the issue becomes moot. For example, if both domains are in the same task and you choose to use a synchronous architecture, then the wormhole service for the LightOn would simply not return until the light actually had been turned on and any returned acknowledgement code would probably be hard-wired in the bridge. However, this would be an application-specific architectural decision -- the second point that Peter was making. This simplification is reserved for the translation (i.e., the OOA is always asynchronous) because one might have to port the relevant domains to another environment and you want them to Just Work in that new, possibly truly synchronous environment. In summary... To be robust and portable the OOA needs to solve the problem using the assumption of asynchronous inter-domain communications. This occassionally requires some "unnecessary" extra work (e.g., wait states, etc.), though the Wormholes Paper provides support for enough synchronous mechansims so that this should not normally be a major problem. Then, once the OOA is working, you can translate in whatever way is appropriate for the application -- which typically means making a number of simplifying assumptions. In those cases where a complex architeture is required, the formalism of the OOA makes that translation job much easier as well. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) attributes dependent on current state? lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Whipp... > In OOA96 the "current_state" attribute was removed from the > information model and became inaccessable. The main reason > for this was the additional coupling it provided between > objects. > > OOA96 also introduced the concept of methematically dependent > attributes. These allow many transforms to be eliminated from > state actions and allow improved clarity of the information > model. > > What I would like to know is: can I create a boolean attribute > that is mathematically dependent on the current state of the > object for which it is defined. > > If you want an example of this, consider the ODMS example from > the PT training course. Imagine that the robot object has a > "is_moving" attribute. I could specify its value in each state > but this would result in redundant data storage because its > value _is_ dependent on the current state of the robot object > (its true except in states 1, 4 and 8). In this particular case I would argue that whta you want to do is legal. The is_moving attribute seems to describe a characteristic of the object rather than a particular state. That is the value of is_moving is the same in states 1, 4, and 8 -- it is not possible to determine which *particular* state the object is in from the value of the attribute. Therefore the current state is decoupled from the attribute. OTOH, there is mathematical dependence because the value is unambiguously derivable from the current state. The best of both worlds. I think things get a tad trickier if the value of the attribute also allows one to unambiguously determine the specific state of the instance (e.g., the value is the state number or name). Now the coupling is back and I don't think this would be a very good practice. > Of course, I could create a code generator that detects attributes > that are unamibguously assigned a known value in every state; > and which are not assigned from any other object-instance. Having > detected this fact (possibly with coloration) I could treat the > write accessors as a canonical specification of the dependency. > That does seem to be an unduely complex solution. I would vote for colorization. We already do this with a number of domain object attributes that correspond with one (or more) specific registers in hardware. We colorize them with tags (a mechanism supported by our tool) and the translator automatically generates the hardware write as well as the attribute's value write (useful for simlation). Not quite the same thing, but pretty close and the process is pretty straight-forward. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) RPC packages David Yoakley writes to shlaer-mellor-users: -------------------------------------------------------------------- This is an architecture question. Does anyone out there have experience using a commercial RPC package that would give me portability between Solaris and NT at a minimum. I am currently evaluating CORBA and would like a few more options before making a final decision. For the purist out there, I am not asking for UNIX rpc necessarily. What I need is the capability to make synchronous calls across platforms and have support for "in", "out", and "inout" parameters of arbitrary type. Asynchrous support would also nice (e.g. non-blocking when appropriately configured) as well as a least some primitive support for a Name Server. thanks in advance, David Yoakley ________________________________________________________________________ David Yoakley Objective Innovations Inc. Phone: 512.288.5954 14606 Friendswood Lane Fax: 512.288.6381 Austin, TX 78737 Replies: yoakley@oiinc.com ________________________________________________________________________ Subject: Re: (SMU) RPC packages "Dick Taylor" writes to shlaer-mellor-users: -------------------------------------------------------------------- -----Original Message----- From: David Yoakley To: shlaer-mellor-users@projtech.com Date: Monday, September 08, 1997 5:13 PM Subject: (SMU) RPC packages David Yoakley writes to shlaer-mellor-users: -------------------------------------------------------------------- This is an architecture question. Does anyone out there have experience using a commercial RPC package that would give me portability between Solaris and NT at a minimum. I am currently evaluating CORBA and would like a few more options before making a final decision. For the purist out there, I am not asking for UNIX rpc necessarily. What I need is the capability to make synchronous calls across platforms and have support for "in", "out", and "inout" parameters of arbitrary type. Asynchrous support would also nice (e.g. non-blocking when appropriately configured) as well as a least some primitive support for a Name Server. thanks in advance, David Yoakley ________________________________________________________________________ David Yoakley Objective Innovations Inc. Phone: 512.288.5954 14606 Friendswood Lane Fax: 512.288.6381 Austin, TX 78737 Replies: yoakley@oiinc.com ________________________________________________________________________ Hi Dick Taylor contractor working on exactly your problem . I looked at writing and RPC/IPC link myself directly compiled from the OOA database which is Interactive OOA from Kennedy Carter (UK) but we looked at CORBA and for for the cost of a contractor to write the code and port it to NT , HPUX ,WIN 3.11,Solaris. We bought Orbix 10K sterling at the time 2-3 months contractor time. It has some problems , mostly win 3.11 problems . but dead easy to auto genrate. An event has parameters in the tools a simple llokup table genrate IDL . ALL DONE. If you require more info please contact me . Dick Taylor. Subject: Re: (SMU) bridges lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Rewsponding to French... > > > I must admit that I have seen a lot of material on external events and > sync-services and am therefore worried that we have missed something. If so > could someone please explain > > a) What we are missing > b) What are the flaws in the above approach I tend to view counterparts as a mechanism for automating bridge writing -- or at least making it a lot easier. I do not see them (foremost) as a mechanism for reducing domain poullution. Even the tools that directly support counterparts merely replace the wormhole service call with a specific syntax so that it is still visible in the OOA. I think you are carrying things a bit far when you use them to remove evidence of inter-domain comunications from the OOA by making them implicit behind-the-scenes bridge invocations. I agree with Wiley that the wormhole already provides sufficient decoupling of domains; there is nothing in the wormhole invocation that says where the message is going or how it will be fielded. [In fact, we have situations where a single wormhole request actually initiates activities in two service domains and this is completely transparent to the domain invoking the wormhole.] OTOH, it is important to have the inter-domain communications explicit in the OOA because this makes the domain's interface to the outside world verifiable. As Fontana pointed out, one must be able to demonstrate that a domain can satisfy the requirements upon it. Examination and simulation of the domain's external interface (i.e., the wormholes and their context within state actions) is the efficient way to verify this. If this interface is hidden in implicit bridge invocations, then it becomes much more difficult to verify the OOA. [This is an amplification on Whipp's argument concerning the need for input wormholes to stimualte the domain. I further contend that you cannot determine that a client is making the proper requests of a service domain unless you can observe the outgoing wormholes being invoked.] Having said all this, let me hasten to point out an apparent exception. In another thread I indicated that we color certain attributes so that when the write accessor is invoked a bridge function to write hardware registers is also invoked. In this case, there is no specific wormhole in the OOA. So how do I justify the above position in this context? My answer is that, as Whipp pointed out (or something close to it), the write accessor is already a specialized wormhole into the architecture. (In fact, every ADFD process bubble can be regarded as a wormhole into the architecture.) Moreover, though these specialized wormholes usually go to the architecture, the methodology does not preclude their going to other domains. [In fact, this is even the common interpretation for complex algorithmic transforms -- the processing is in realized code in another domain.] Having defended the wormhole view of the write accessor, let me hasten to add that I would still not use this approach except in particular situations. I am still somewhat ambivalent about doing it in our situation. As it happens, I think that if we had better understood how our tool handled counterparts at the time we embarked upon this strategy, we might have chosen that approach instead -- precisely because it would be explicit in the OOA (action language). -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) bridges peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 02:25 PM 9/8/97 -0400, shlaer-mellor-users@projtech.com wrote: >lahman writes to shlaer-mellor-users: > ... >My answer is that, as Whipp pointed out (or something close to it), the >write accessor is already a specialized wormhole into the architecture. >(In fact, every ADFD process bubble can be regarded as a wormhole into >the architecture.) Yes - just like every object, attribute, and relationship.... But isn't that why all of our domain charts have a flow of requirements from every analyzed domain to the Software_Architecture domain? The nature of this "implicit" bridge is explicitly documented our by each project's architecture policy documents - our "Software Architecture Analyst's Guide". I guess the point here is any similar implicit bridging (outside explicit "wormhole" invocations) requires a similar level of documentation. > ... >Having defended the wormhole view of the write accessor, let me hasten >to add that I would still not use this approach except in particular >situations. I am still somewhat ambivalent about doing it in our >situation. As it happens, I think that if we had better understood how >our tool handled counterparts at the time we embarked upon this >strategy, we might have chosen that approach instead -- precisely >because it would be explicit in the OOA (action language). I'd like to underscore this point. ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice: +01 508-384-1392 | peterf@pathfindersol.com fax: +01 508-384-7906 | ____________________________________________________| Subject: (SMU) Atomic actions lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Two of our troops took the PT RD course two weeks ago and the answer to a question about the nature of atomic classes raised in the class seems contrary to my understanding of the methodology, so I would like to verify the answer. Basically the question was: what does the architecture need to guarantee in support of atomic action processing? The answer was: if an instance is executing an action, then the architecture must ensure that any other events directed to the instance are delayed until that action finishes. This seems perfectly reasonable. My problem is that this was defined as the __only__ thing the architecture needs to support. In my understanding an atomic action implies data integrity and relationship consistency as well as some other variations on parallel event processing. So let me try a few examples of things where I think the architecture needs to provide additional support (at least in asynchronous, multi-processor, multi-tasking systems) beyond simply not allowing the instance to accept events when its action is executing. example 1: Suppose I have an action in an instance of A that accesses data in an instance of B: A.density = B.Volume / B.Mass There are two data accesses of B that must be consistent. While the A instance is executing, then the architecture cannot allow either B attribute to be written concurrently with the execution of A's action. The basic problem is that the Mass/Volume pair A extracts might be neither of the cases before or after the writes to B if both attributes are being changed in B. A more subtle problem is deciding which Mass/Volume pair should be relevant to A's action if B is modified concurrently, even if read/write concurrency is eliminated. My understanding is that it should be the one that existed when A's action started. That implies that the architecture must prevent concurrent changes to data accessed by A's action during the entire execution of that action. example 2: Suppose I have a relationship, R1, between A and B. If A has an action containing B_inst = this -> R1 ... A.x = B_inst.z The architecture must ensure that if the relationship exists at the beginning of the action, then it must exist throughout the action (unless the action itself removes it). That is, nobody else can concurrently delete B_inst while A's action is executing. example 3: Suppose I have instances of A and B and I send an event to B that will result in B's access of A.x. I code an A action as: A.x = 5 generate Bn:use_x ... A.x = 10 The question is: when Bn is processed, which value of A.x should the B action access? This one, I think, is moot. The answer should be: Don't Do That. Instead, pass A.x in the data packet for Bn and don't allow B's action associated with Bn to access A.x directly. [This is pretty axiomatic for asynchronous processing in general; the setting of A.x could take place in different actions so that race conditions might exist for which one B's action accessed.] If one models as in the example, then there are major headaches for the architecture and I suspect the behavior would be different (or at least nonintuitive) for synchronous (x=5) and asynchronous (x=10). Intuitively the synchronous case should use A.x = 5 because that is the only value available during the processing until the generate function call returns. However, in the asynchronous case there is no guarantee that Bn can be processed before A's action sets A.x = 10. Thus the only consistent means of handling this would be to always defer processing of Bn until after all the code in A's action has been executed (which would require a thread or somesuch for the synchronous case). However, the result is that B's action would then always access A.x=10, which is not intuitive. Did our troops misunderstand the answer or have I been dancing to a different drummer all these years? -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Atomic actions Eugene Polyakov writes to shlaer-mellor-users: -------------------------------------------------------------------- lahman wrote: > lahman writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Two of our troops took the PT RD course two weeks ago and the answer > to > a question about the nature of atomic classes raised in the class > seems > contrary to my understanding of the methodology, so I would like to > verify the answer. > > Basically the question was: what does the architecture need to > guarantee > in support of atomic action processing? The answer was: if an > instance > is executing an action, then the architecture must ensure that any > other > events directed to the instance are delayed until that action > finishes. > This seems perfectly reasonable. My problem is that this was defined > as > the __only__ thing the architecture needs to support. > I would like to set the record straight here. I am "one of the troops", and it must have been my incoherent babbling that confused H.S. about what was actually said in the class. We were told that the only thing METHODOLOGY RULES say about atomicity of actions is that if an instance is executing an action, then any other events directed to the instance are delayed until that action finishes. We were not told that that was the only thing ARCHITECTURE needs to support. In fact, in class we briefly spoke about dealing with problems arising from two actions running in parallel and accessing the same data as part of the architecture. Eugene Polyakov, Teradyne. Subject: Re: (SMU) Atomic actions Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- Note: In this posting, I'm disagreeing with Lahman's examples, not his basic point (except in the last case). I agree that the achitecture must worry about dataset consistency in all but the most trivial cases. Lahman wrote: > example 1: Suppose I have an action in an instance of A that accesses > data in an instance of B: > > A.density = B.Volume / B.Mass > > There are two data accesses of B that must be consistent. > While the instance is executing, then the architecture cannot > allow either B attribute to be written concurrently with the > execution of A's action. The basic problem is that the > Mass/Volume pair A extracts might be neither of the cases > before or after the writes to B if both attributes are being > changed in B. The problem as stated here is a bit of a non-problem. In an ADFD, both the volume and mass would be read using a single atomic accessor. Data in B would need to be locked against writing only for the short period when reading mass and volume. I.e. the lock is for a single accessor process, not the whole action. But what about consistency between A and B. What happens if another object modifies B after it has been read but before A is written. This is definitely not a problem because the result is indestinguishable from the case where B is changed after A is written. If the assignment to A is done within a state action then the analyst is stating that there is no mathematical dependency between the three variables. If there was such a dependency then this would be identified using (m) attributes. So the analyst is asserting that A and B may be inconsistent with respect to the desity equation. So in the given example there is no problem. We need to make it a bit more complex: lets add another attribute in A: "density_is_correct". This is set false by any action that modifies mass/volume and true by the action that sets the density. Now we have a sequence that can cause an observable failue. 1. write to B and mark A as invalid 2. start action to set A - read B 3. write to B and mark A as invalid 4. complete action to set A - mark A as correct. So yes, we can create a problem. But it doesn't necessarily cover the entire action. > A more subtle problem is deciding which Mass/Volume pair > should be relevant to A's action if B is modified concurrently, > even if read/write concurrency is eliminated. My understanding > is that it should be the one that existed when A's action > started. That implies that the architecture must prevent > concurrent changes to data accessed by A's action during the > entire execution of that action. As I stated above, in the simple case it doesn't matter which consitant mass/volume pair is used. The analyst doesn't know which state action started first - the expected or the intruding. Consider the following sequences: 1. action X starts 2. action Y starts, modifies B and ends 3. action X continues and reads B; then writes A and 1. action Y starts, modifies B and ends 2. action X starts, reads B and then writes A There is no observable difference between the two, so there is no requirement that the dataset of X is captured when the action starts. Similarly, consider: 1. action X starts and reads B. 2. action Y starts, modifies B and ends 3. action X writes A and ends against 1. action X starts, reads B and then writes A 2. action Y starts, modifies B and ends Again, there is no observable difference. Even if we introduce a 3rd action there are no effects that are not the analyst's responsibility. > example 2: Suppose I have a relationship, R1, between A and B. > If A has an action containing > > B_inst = this -> R1 > ... > A.x = B_inst.z > > The architecture must ensure that if the relationship exists at the > beginning of the action, then it must exist throughout the action > (unless the action itself removes it). That is, nobody else can > concurrently delete B_inst while A's action is executing. Again, this requirement is too strict. SM has no instance handles so the above situation would not arise. The accessor that you show fetching B_inst would probably fetch B_inst.z. It is, however, possible to contrive a situation which is similar. Anyway, the scope of any locks may be less than the whole action. > example 3: Suppose I have instances of A and B and I send an > event to B that will result in B's access of A.x. I code an > A action as: > > A.x = 5 > generate Bn:use_x > ... > A.x = 10 Well, this is just a plain bad model and should be rejected during a review. I say this because you are using two write accessors to the same attribute-instance within a single state action, not for the reason you give below: > The question is: when Bn is processed, which value of A.x should > the B action access? This one, I think, is moot. The answer > should be: Don't Do That. Instead, pass A.x in the data packet > for Bn and don't allow B's action associated with Bn to access > A.x directly. [This is pretty axiomatic for asynchronous > processing in general; the setting of A.x could take place in > different actions so that race conditions might exist for which > one B's action accessed.] If you do what you suggest then you start to need the Kennedy Carter proposal for held events. If you pass data in an event then it cannot be ignored - otherwise you lose the data. Thus there is a common idiom of setting an attribute then sending an event to say you've set it. If a receiving event was ignoring the event then its state action when it stops ignoring it will check if the attribute was set. > If one models as in the example, then there are major headaches > for the architecture and I suspect the behavior would be > different (or at least nonintuitive) for synchronous (x=5) and > asynchronous (x=10). Intuitively the synchronous case should use > A.x = 5 because that is the only value available during the > processing until the generate function call returns. However, > in the asynchronous case there is no guarantee that Bn can be > processed before A's action sets A.x = 10. > > Thus the only consistent means of handling this would be to > always defer processing of Bn until after all the code in A's > action has been executed (which would require a thread or > somesuch for the synchronous case). However, the result is > that B's action would then always access A.x=10, which is not > intuitive. I think your experience of "intuitive" is slightly different from mine. I would regard it as unintuitive for the value 5 to be used in either case. I suppose thats because I think in asynchronous terms, even for sychronous systems. I would be really upset if an architecture tried to use A.x=5. That said, it would be easy to construct an architecture with this bug. In an ADFD it is meaningless to show a sequential contraint between two event genertors. I would extend this to say that you must never show a sequential constraint from an event genertor to any other process in an ADFD. All events generated by an action can then always be defered and reordered by the architecture (taking into account the event ordering rules of the method). The dataset of B's action must be consitent with A having completed. This doesn't actually mean that A must have completed; only that data that is read by B (or any subsequent actions) must be consistent. If the code generator is able to correctly position the event generator calls within its code then a synchronous architecture will work correctly in the example. So I don't agree that there is a run-time data consistency problem related to event generation. There is an event ordering issue for sychronous arhcitectures where more than one event is generated in an action. Dave. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Tamerton Road, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com For embedded Systems Support mailto:armapps@gpsemi.com Subject: Re: (SMU) Atomic actions Tim Wadsworth writes to shlaer-mellor-users: -------------------------------------------------------------------- > lahman writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Two of our troops took the PT RD course two weeks ago and the answer to > a question about the nature of atomic classes raised in the class seems > contrary to my understanding of the methodology, so I would like to > verify the answer. > > Basically the question was: what does the architecture need to guarantee > in support of atomic action processing? The answer was: if an instance > is executing an action, then the architecture must ensure that any other > events directed to the instance are delayed until that action finishes. > This seems perfectly reasonable. My problem is that this was defined as > the __only__ thing the architecture needs to support. I think that the types of locking can be broken down as follows: The Method ========== > The answer was: if an instance is executing an action, then the > architecture must ensure that any other events directed to the > instance are delayed until that action finishes. This, as far as I am aware, *is* the __only__ thing the method dictates that the architecture shall support. (Almost) Essential Architectural Locking ======================================== However, it is probably sensible to enforce locking between the information model and state model to prevent: 1. A polymorphic event propagation from finding a half-linked subtype instance (ie. 'link' is interlocked with polymorphic event propagation). 2. A 'find' from finding half-created or half-deleted instances (ie. 'find' is interlocked with 'create'). Strictly speaking it is possible to model around these by, for example, introducing an object which effectively acts as a lock. [In 1, you have to acquire the lock before performing a link and release the lock afterwards. Similarly before sending a polymorphic event to the supertype, the lock must be acquired; the lock is released when the polymorphic event has been processed by the subtype]. Less Essential Architectural Locking ==================================== This is fairly unpleasant, however, and makes the modelling overcomplicated and (I think) less pure. The reason it is overcomplicated is that the locking is between a something synchronous in the instantiation of the information model (create/delete/link) and something asynchronous in the state model (namely event processing). It is much simpler for the analyst to ensure that interaction between information model elements does not violate data integrity, and so such locking is less important. Such locking would interlock: o find/create o link/navigate o unlink/navigate o attribute read/write (single writer, multiple reader lock) Although 'simpler', due to the absence of events in the above, and their asynchronous nature, analysis still becomes complicated. Analyst-Specified Locking ========================= Rather than implementing the 'Less Essential Architectural Locking', we have approached the problem by allowing the analyst to tag/colour active objects with a tag 'X', say, such that all actions of all instances of X-tagged objects are atomic with respect to one another. [Tagging of individual actions would provide finer-grained control]. Tagging in this way allows the analyst to ensure maximum performance: 'maximum' because only actions which require locking have the overhead of lock acquisition and release [although finer-grained control even than actions would be required to ensure maximum concurrency]), but without compromising data integrity and without complicating analysis. It should now be clear that 'Analyst-Specified Locking' can be used as an alternative to 'Less Essential Architectural Locking', but cannot replace '(Almost) Essential Architectural Locking'. Note also that this use of tagging is actually part of the modelling/design, ie. the atomicity tags specify the semantics of the model, whereas tags used to direct code generation or to distribute processing across multiple processors are not part of the modelling because they have nothing to do with the semantics of the model. > example 1: Suppose I have an action in an instance of A that accesses > data in an instance of B: > > A.density = B.Volume / B.Mass > > There are two data accesses of B that must be consistent. While the A > instance is executing, then the architecture cannot allow either B > attribute to be written concurrently with the execution of A's action. > The basic problem is that the Mass/Volume pair A extracts might be > neither of the cases before or after the writes to B if both attributes > are being changed in B. This could be solved by using 'Less Essential' or 'Analyst-Specified' locking. Actually, density is mass per unit volume, but that's not important right now :-) Unfortunately the locks used to implement atomic actions must be mutual exclusion locks (mutex's), whereas single writer multiple reader locks would give maximum concurrency for attribute read/write, so some concurrency is lost with the tagging approach. > A more subtle problem is deciding which Mass/Volume pair should be > relevant to A's action if B is modified concurrently, even if read/write > concurrency is eliminated. My understanding is that it should be the > one that existed when A's action started. If 'Less Essential Architectural Locking' were used, then no. In this case, A's and B's action are not atomic, only read/writes are interlocked, so either the reader or the writer would get there first. If tagging to produce atomic actions were used, then your understanding is correct. > example 2: Suppose I have a relationship, R1, between A and B. If A has > an action containing > > B_inst = this -> R1 > ... > A.x = B_inst.z > > The architecture must ensure that if the relationship exists at the > beginning of the action, then it must exist throughout the action > (unless the action itself removes it). That is, nobody else can > concurrently delete B_inst while A's action is executing. Again, atomic actions would ensure this, but 'Less Essential Architectural Locking' would not. This is a good example of where tagging to ensure that actions are atomic allows simpler modelling. To ensure this without atomic actions would require additional states to prevent the link being altered whilst this action is being executed. > example 3: Suppose I have instances of A and B and I send an event to B > that will result in B's access of A.x. I code an A action as: > > A.x = 5 > generate Bn:use_x > ... > A.x = 10 > > The question is: when Bn is processed, which value of A.x should the B > action access? This one, I think, is moot. The answer should be: Don't > Do That. Instead, pass A.x in the data packet for Bn and don't allow > B's action associated with Bn to access A.x directly. [This is pretty > axiomatic for asynchronous processing in general; the setting of A.x > could take place in different actions so that race conditions might > exist for which one B's action accessed.] As you say, there is a race condition (even with '(Almost) Essential Architectural Locking'). Unless, that is, the action above and the action which the event Bn causes a transition into are both tagged with the same 'atomic action' tag. In which case, the value B will see is 10. > If one models as in the example, then there are major headaches for the > architecture and I suspect the behavior would be different (or at least > nonintuitive) for synchronous (x=5) and asynchronous (x=10). > Intuitively the synchronous case should use A.x = 5 because that is the > only value available during the processing until the generate function > call returns. However, in the asynchronous case there is no guarantee > that Bn can be processed before A's action sets A.x = 10. > > Thus the only consistent means of handling this would be to always defer > processing of Bn until after all the code in A's action has been > executed This is what tagging A and B achieves. > (which would require a thread or somesuch for the synchronous > case). However, the result is that B's action would then always access > A.x=10, which is not intuitive. It is if you consider the semantics of atomic actions. If you want '5', you should pass it as a parameter, as you say. > -- > H. S. Lahman There is nothing wrong with me that > 321 Harrison Av L51 couldn't be cured by a capful of Drano > Boston, MA 02118-2238 > v(617)422-3842 > f(617)422-3100 > lahman@atb.teradyne.com > Tim +---------------------------------------------------------------+ | Voice: +44 (0)1223 586232 Tim.Wadsworth@cambridge.simoco.com | | Fax: +44 (0)1223 314812 | +---------------------------------------------------------------+ Subject: Re: (SMU) Atomic actions lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Whipp... > > example 1: Suppose I have an action in an instance of A that accesses > > data in an instance of B: > > > > A.density = B.Volume / B.Mass > > The problem as stated here is a bit of a non-problem. In an > ADFD, both the volume and mass would be read using a single atomic > accessor. Data in B would need to be locked against writing > only for the short period when reading mass and volume. I.e. > the lock is for a single accessor process, not the whole action. True. I was trying to keep the example simple without side issues. I could have constructed one where the data elements were in two separate instances. I might also point out that in the tools that use an action language instead of ADFDs, there would really be two separate accessors. > But what about consistency between A and B. What happens if another > object modifies B after it has been read but before A is > written. This is definitely not a problem because the result is > indestinguishable from the case where B is changed after A is > written. True. I was concerned with inconsistency between the B attributes used. > If the assignment to A is done within a state action then > the analyst is stating that there is no mathematical dependency > between the three variables. If there was such a dependency then > this would be identified using (m) attributes. So the analyst > is asserting that A and B may be inconsistent with respect to > the desity equation. This is the main problem with the example, A.density is dependent and, therefore, *could* be assigned through the architecture when the relationship is instantiated. A more complex example could have overcome this problem. I do disagree, though, that placing the assignment in the action implies that no mathematical dependency exists. I see the architectural solution as merely an alternative that is convenient when the independent attributes are volatile. In other situations the better solution might be to explicitly make the assignment -- for example if A needs to carry an historical sample value of density rather than the current one. The mathematical dependence is temporal only in the sense that density must be computed from two values that are consistent at the moment of computation. In most real situations it does have wider temporal scope, in which the architectural solution becomes appropriate. > > > So yes, we can create a problem. But it doesn't necessarily > cover the entire action. True. However, the practicalities of enforcing consistency certainly encourage employing the widest scope possible, which is the entire action. I suspect that when somebody actually figures out how to write an efficient compiler for a multiprocessor the ADFD-level dependencies may become useful but until then the practical boundary for resolving these issues is going to be the action. > > A more subtle problem is deciding which Mass/Volume pair > > should be relevant to A's action if B is modified concurrently, > > even if read/write concurrency is eliminated. My understanding > > is that it should be the one that existed when A's action > > started. That implies that the architecture must prevent > > concurrent changes to data accessed by A's action during the > > entire execution of that action. > > As I stated above, in the simple case it doesn't matter which > consitant mass/volume pair is used. The analyst doesn't know > which state action started first - the expected or the intruding. > > Consider the following sequences: > > 1. action X starts > 2. action Y starts, modifies B and ends > 3. action X continues and reads B; then writes A > > and > > 1. action Y starts, modifies B and ends > 2. action X starts, reads B and then writes A > > There is no observable difference between the two, so > there is no requirement that the dataset of X is captured > when the action starts. True. But I think you are overlooking a case I was primarily concerned with: 1. action X starts, reads B 2. action Y starts, modifies B and ends 3. action X writes A Between your first case and this one the value written to A is observably different. My assertion is that if one is going to block at this level, then the blocking must act so that either Y always completes the modification before the X's read or X's read always completes before Y's change. This gets complicated so it is a lot easier to do it at action scope where all you have to do is lock the event to X or Y in the event queue. > > example 2: Suppose I have a relationship, R1, between A and B. > > If A has an action containing > > > > B_inst = this -> R1 > > ... > > A.x = B_inst.z > Again, this requirement is too strict. SM has no instance handles > so the above situation would not arise. The accessor that you > show fetching B_inst would probably fetch B_inst.z. It is, however, > possible to contrive a situation which is similar. Anyway, the > scope of any locks may be less than the whole action. SM does have identifiers that uniquely define data stores so the example works just as well with ADFD accessors as with action language pseudocode, so I do not understand why you don't think the situation would arise: this B_ID B_ID z -------> P_B1: get_linked_B_id -----> ... -----> P_B2: get_z -----> etc. B_ID had better still be valid when the P_B2 process is invoked. > > example 3: Suppose I have instances of A and B and I send an > > event to B that will result in B's access of A.x. I code an > > A action as: > > > > A.x = 5 > > generate Bn:use_x > > ... > > A.x = 10 > > Well, this is just a plain bad model and should be rejected during > a review. I say this because you are using two write accessors to > the same attribute-instance within a single state action, not for the > reason you give below: Alas, this is required by OOA96 -- all transient data must now be attributes. Your point is just one of the many reasons why I think this was a terrible idea. Before you rush to ask why B would want a transient attribute in A, let me cite a case. Suppose the action is operating over a set where it is, among other things, seeking the largest value to assign to A.x. In that iteration it assigns to A.x each time it finds a new largest value. Meanwhile, in other processing associated with a particular set element some unrelated condition indicates Bn needs to be issued and Bn happens to access A.x. [True, you could artifically create a second, real transient attribute and use that to store the intermediary large values until the whole set is processed and then assign that to A.x. However, that is clearly architecture creeping into the OOA.] > > The question is: when Bn is processed, which value of A.x should > > the B action access? This one, I think, is moot. The answer > > should be: Don't Do That. Instead, pass A.x in the data packet > > for Bn and don't allow B's action associated with Bn to access > > A.x directly. [This is pretty axiomatic for asynchronous > > processing in general; the setting of A.x could take place in > > different actions so that race conditions might exist for which > > one B's action accessed.] > > If you do what you suggest then you start to need the Kennedy > Carter proposal for held events. If you pass data in an event > then it cannot be ignored - otherwise you lose the data. Thus > there is a common idiom of setting an attribute then sending > an event to say you've set it. If a receiving event was ignoring > the event then its state action when it stops ignoring it will > check if the attribute was set. This is a new one on me. Since when can't an event be ignored when it has a data packet? The checks you propose are only necessary *if* you care. There are lots of situations where you don't. E.g., GUI window manager sends a gazillion position messages to your application with lots of data but you probably ignore 99% of them with no harm done. > > Thus the only consistent means of handling this would be to > > always defer processing of Bn until after all the code in A's > > action has been executed (which would require a thread or > > somesuch for the synchronous case). However, the result is > > that B's action would then always access A.x=10, which is not > > intuitive. > > I think your experience of "intuitive" is slightly different > from mine. I would regard it as unintuitive for the value 5 > to be used in either case. I suppose thats because I think in > asynchronous terms, even for sychronous systems. I would be > really upset if an architecture tried to use A.x=5. That said, > it would be easy to construct an architecture with this bug. I actually share your view. I just didn't make clear that what would be unintuitive to me was that if I *did* have a synchronous architecure I would still get A.x=10, given the action language. > In an ADFD it is meaningless to show a sequential contraint > between two event genertors. I would extend this to say that > you must never show a sequential constraint from an event > genertor to any other process in an ADFD. All events > generated by an action can then always be defered and > reordered by the architecture (taking into account the > event ordering rules of the method). I generally agree, but as a quibble if I have two event generators directing different events to the same instance, then I may find it useful to order them since the methodology does guarantee that multiple events between the same two instances will arrive in the issued order. > The dataset of B's action must be consitent with A having > completed. This doesn't actually mean that A must have > completed; only that data that is read by B (or any subsequent > actions) must be consistent. > > If the code generator is able to correctly position the > event generator calls within its code then a synchronous > architecture will work correctly in the example. So I > don't agree that there is a run-time data consistency > problem related to event generation. There is an event > ordering issue for sychronous arhcitectures where more than > one event is generated in an action. I assume by "correct positioning" that the code generator would place the call to the Bn action at the end of A's action in the synchronous case. This is one way to do it, but it gets messy if there are complex conditions. As I indicated I would be tempted to use a sleeping thread that would be awakened at the end of the action so that it would be much less dependent upon specific conditions. In either case, I think we are both making the point that implementating synchronous architectures is not just a simple matter of replacing an event generator with a direct action call wherever it appears in the action. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Atomic actions lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- This is a multi-part message in MIME format. --------------98D2561126D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Alas, I my mailer got confused again about the return address so this only went to Eugene and I had to forward my copy: -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com --------------98D2561126D Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <3415C011.1AC2@atb.teradyne.com> Date: Tue, 09 Sep 1997 17:30:57 -0400 From: lahman Reply-To: lahman@atb.teradyne.com Organization: Teradyne/ATB X-Mailer: Mozilla 3.0 (WinNT; U) MIME-Version: 1.0 To: polyakov@bamboo Subject: Re: (SMU) Atomic actions References: <34156534.588F@atb.teradyne.com> <34157BC5.CDEDBCBD@atb.teradyne.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Responding to Polyakov... > I would like to set the record straight here. I am "one of the troops", > and it must have been my incoherent babbling that confused H.S. about > what was actually said in the class. We were told that the only thing > METHODOLOGY RULES say about atomicity of actions is that if an instance > is executing an action, then any other events directed to the instance > are delayed until that action finishes. We were not told that that was > the only thing ARCHITECTURE needs to support. In fact, in class we > briefly spoke about dealing with problems arising from two actions > running in parallel and accessing the same data as part of the > architecture. Jeesh, now I'm being set up by our resident Ukrainian Wetback! With each passing year I identify more and more with Rodney Dangerfield. OK, something seems to have been lost in the translation (to coin a phrase). For me something has been lost in the the semantic distinction between what the architecture enforces and "methodology rules". It seems to me that the things that the architecture is enforcing *are* the methodology rules. The formalization of S-M embodies a number of rules concerning data consistency and referential integrity that the architecture must enforce. In addition the methodology defines the temporal scope during which these rules are enforced, the atomic action. Specifically, In my example 1, when I write A's action I should be able to count on the fact that B.Volume and B.Mass are semantically consistent when I access them within an action. If I am defining integrity etc. at the action boundary, then they should be consistent *throughout* the action execution. The methodology rule is that an action defines the bounds of data model consistency. In my example 2, when I write A's action I should be able to count on the fact that once I obtain a valid instance handle by navigating a relationship then that handle will remain valid during the action as I access its data store. The methodolgy rule is that the data model's referential integrity is preserved within the bounds of the atomic action. In my example 3, when I write A's action, despite the bad modeling technique, I should be able to count on a consistent view of which value of A.x B's instance will access when Bn is processed. The methodology rule to be enforced is that the system behavior will be the same regardless of whether my underlying architecture is synchronous or asynchronous. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com --------------98D2561126D-- Subject: Re: (SMU) Atomic actions lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Wadsworth... In a separate cover I sent a response to Polyakov that I hope cleared up my concern over the fuzziness of what's in the methodology and what's in the architecture. So I won't repeat that here. Instead I will offer up a tenuously related philosophical digression. One thing I would like to expand upon in light of your comments (and to some extent Whipp's) is the level that is appropriate for locking. I don't think this is very well defined in the methodology and there seems to be an unhealthy greyness around locking at the ADFD process level vs. the state action level. As a result this is a personal perspective. I have always viewed the relational data model to be at the heart of the methodology. This is one reason why I see the admonitition that an instance accept no more events until the current action is done to be a minor (albeit important) facet of the overall problem of supporting data integrity in the information model. Thus every time the methodology introduces a data model formalism, I see that as a methodology rule that places requirements upon the architecture. One does not usually thinking of locking data in relational databases at the field level; instead one locks at the row or table level. The analog is the instance or object level. When one throws in the complexities of state machines for flow-of-control the state action seems to me the analogous level for maintaining data integrity. That is, the state action provides a temporal context that corresponds very closely to the instance data -- you lock the all the instance data and you do it for the duration of the action. To think of locking at the level of an ADFD process seems to me to be a mistmatch of scale between the data locking level and the scale of the processing. [Another way to look at this, though a long stretch, is that the action is analogous to a database transaction.] Not only is this aesthetically pleasing, it has practical advantages for the architecture. For example, it is a lot easier to manipulate the event queue than it is to muddle around with individual ADFD processes or provide direct data store locks. So where does that leave the ADFD process in this scheme? Rightly or wrongly the ADFD formalism has always struck me as a means for micromanaging multiple processors (or the registers and pipelines in a RISC processor). That is, it is a formalism that allows efficient processing once the data integrity issues have been resolved at the action level. Thus I don't see the individual find/create, link/navigate, unlink/navigate, or attribute read/write processes as particularly important to locking -- they identify what needs to be locked and their containing action defines when the locks are needed, but they do not place any particular requirements on the architecture. OTOH, the bounds of the state action carries with it a host of requirements for the architecture, essentially all of the data integrity issues. For example, I don't think there is anything "Almost" about your Essential Architectural Locking examples. The methodology says that if I follow the correct formalism (e.g., create instances and link unconditional relationships to them in a single action), then the architecture has to guarantee data and referential integrity is preserved (e.e., that nobody else will concurrently operate on the two instances without their unconditional relationship in place). These and other data integrity issues have very little, if anything, to do with events. As far as tagging is concerned, I view this as an architectural *mechanism*. Such tags are not part of the OOA. The architecture could just figure out the necessary locking from the formalism of the OOA without using tags. I see them as just a translation convenience to address peformance issues. Thus the OOA formalism (i.e., the methodology) defines the requirement that tags or some other mechanism be used by the architecture to preserve data integrity in particular contexts. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Atomic actions Dana Simonson writes to shlaer-mellor-users: -------------------------------------------------------------------- Object Lifecycles:Modeling The World in States, p106: It is the responsibility of the analyst to ensurethat the data required by an action is consistent... This follows a discussion of concurrency which allows for both simultaneous and interleaved actions. I think that this is not an architectural issue. The analyst should use the facilities provided by the architecture to ensure that the data he cares about will not be modified before his action is completed. If you are doing a distributed database application, it may be that you need to get a record lock before you perform a read-proces-write cycle. The architecture can and should not know what to do in all cases. Subject: Re: (SMU) Atomic actions lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Simonson > Object Lifecycles:Modeling The World in > States, p106: It is the responsibility of > the analyst to ensurethat the data required > by an action is consistent... > > This follows a discussion of concurrency > which allows for both simultaneous and > interleaved actions. > > I think that this is not an architectural > issue. The analyst should use the > facilities provided by the architecture to > ensure that the data he cares about will not > be modified before his action is completed. > > If you are doing a distributed database > application, it may be that you need to get > a record lock before you perform a > read-proces-write cycle. The architecture > can and should not know what to do in all > cases. I agree to the issue that it is not purely an architectural issue. In my response to Polyakov I used the phrase, "I can count on..." for all three examples to emphasize that the analyst does have to deal with these issues in the OOA. The methodology formalism provides rules that the analyst can depend upon for help in resolving those issues and these rules must be enforced by the architecture. However, I am not sure I agree with the example in your last paragraph. If your application is the actual database engine, then I would agree that such locks were relavant to that level of abstraction. However, if the application merely uses a database, such as Oracle or Object Store, as a data store then those locks are not relevant to the OOA and become the mechanism the translation uses to enforce the methodology formalism for processing data stores. BTW, I think we are both guilty of guilty of misusing the word "architecture" in this thread and your example happens to make this clear. The architecture merely provides mechanisms for enforcing data and relational integrity. The translation rules actually implement or enforce those rules for a particular application by instantiating the architecture mechanisms. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) How to model this constrained relationship? (LONGISH) Paul Michali writes to shlaer-mellor-users: -------------------------------------------------------------------- Hi, Since I haven't had a chance to use S-M since I took a training class last year, I decided to try to model the objects for a piece of test equipment we use at work. The setup of this equipment is somewhat non- intuitive, so my goal was to use this model as a way of describing the unit to aide in the understanding of how to configure this beast. In doing the model, I came across a tough (for me) set of relationships and was hoping that someone would have some useful suggestions. Here are the main objects and relationships... The subject area is a Load box used to simulate phone calls over T1 digital lines. Each T1 line has 24 channels, each of which can be used to originate or terminate a phone call. There are four T1 lines (96 channels) in the box. Definitions: Channel - a hardware port on the equipment where simulated phone calls are placed. Quantity = 96. Script - A series of commands to the load box to tell it what to do. There are both origination and termination scripts that are used on both ends of a call. There can be multiple scripts in the system, some originating and some terminating. Parameters - Each script uses a group of parameters during operation to specify things like duration of the call, intercall time, and digits to dial. Program - The program ties the above three things together. It specifies a script to use, a channel to operate on and values for all of the parameters used by the script. Each program can contain different parameter values. One mandatory parameter is the "channel number' which identifies the Channel that the program will operate on. Set - Is a collection of programs. The user selects to start a set and that will run the programs in the set (which in turn, perform the actions specified by the scripts using the parameter values in the program). There are exactly four sets. Here is a piece of the model that is giving me some problems: +---------+ +----------+ | | | | | Channel | | Set | | * ID | | * Number | | | | | +---------+ +----------+ /|\ /|\ C | /|\ | | | | | +------------+ | R2 | R1 C | | C | +---------->> | Program | <<------+ is assigned | * ID | contains to | - Script(R)| | | +------------+ C /|\ is used by /|\ | | R3 | \|/ +------------+ | | | Script | | * Number | | - Type | | | +------------+ Note: I didn't show associate objects for some of these relationships. So... A Set contains several Programs. A Program could be used in several different Sets. A Program uses exactly one Script. A Script can be used by several Programs. A Program assigns exactly one Channel. A Channel can be assigned to several Programs. This last clause is where there is an added constraint that I'm having trouble with. The Channel can be assigned to several Programs as long as the programs are not in the same Set. Here are table views of some typical entries. Program | Set Program | Channel 1 | 1 1 | A01 <------+ 2 | 1 2 | A02 <--+ | 3 | 1 3 | A03 | | 401 | 2 401 | A01 <------+ 403 | 2 403 | A05 | 402 | 2 402 | A02 <--+ So, if one was to create a table with "allowable" entries, you could have the following: Set | Program | Channel 1 | 1 | A01 1 | 2 | A02 1 | 3 | A03 2 | 401 | A01 2 | 402 | A02 2 | 403 | A05 but you cannot have an entries in this table like this: Set | Program | Channel 1 | 1 | A01 1 | 500 | A01 ... What happens in the box is that the user "starts" one of the four Sets and that causes all of the Programs in the Set to run on the Channels assigned to the Programs. One cannot have a single channel running two different programs. Any ideas on how I should model this constraint/restriction? Thanks in advance, PCM P.S. There are other items in this model that I've been pondering, like: Each Script uses a group of parameters. The values for the parameters are stored with the program (on a per program basis). One parameter is the channel number and all Scripts use it. Other parameter types vary based on the script. Should I use a Specification object to indicate the various type of parameter and another object to indicate what types are used with a particular script? Should the parameter values be a separate object or attributes of the Program? How do I show that the "channel number" parameter must be in every group of parameters (each program has this common attribute). Maybe I don't need to go to that much detail in this model to give people a flavor of how to configure and use the box. ff | Paul Michali | Phone: (603)-625-4050 x2576 f | Summa Four Inc. | Fax : (603)-668-4491 ssfff | 25 Sundial Avenue | FTP : ftp://ftp.summa4.com s f | Manchester, NH 03103-7251 | Web : http://www.summa4.com s f | | sss f | | Subject: Re: (SMU) How to model this constrained relationship? (LONGISH) lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Michali... > What happens in the box is that the user "starts" one of the four Sets > and that causes all of the Programs in the Set to run on the Channels > assigned to the Programs. One cannot have a single channel running two > different programs. When are the Channels assigned to Programs? Since the program seems to have an attribute for the 'channel number' parameter, I infer that this is fixed when the Program objects are instantiated and that when a user starts a Set, somehow a particular suite of programs is selected (e.g., the associative object on R2 is a Request Type, or somesuch). If this is the case, then the conditionality on R1 and R2 is "hard-wired" at system initialization rather than popping in and out as processing continues. That is, at system initialization all instances and relationships that actually exist will be defined and will remian so throughout the execution. In this situation the crucial issue is that the relationships do not capture the ephemeral nature of an "active" channel that is related to Set through Program only under particular circumstances (e.g., a particular user request). One way would be to define an Active Program object with these relationships: R4::Active Program:Program::1:1::defines channel for:is selected from R5::Active Program:Set::M:1::selects:provides service for R6::Active Program:Channel::1:1::is active for:utilizes The Active Program would have a compound identifier: 'Set' and 'Program ID' where 'Program ID' was the same as Program's 'ID'. Now the R1 relationship allows Channel to be associated with many programs, but the R5 and R6 relationships restrict it to only one program in one Set when it is active. Note that none of the relationships are conditional; Active Program exists only for the duration of an execution of the Set's programs so while it exists the relationships exist. R4 is pretty close to an is-a relationship, so an alternative would be to use subtyping for Program. [This might not be a good idea for reasons below.] I also suspect you might be able to provide a solution with multiple relationships between objects that does the same thing, but that would bury some important stuff in the relationship descriptions (e.g., under what circumstances they were instantiated). THe critical idea here is that there are permanent (for the session) relationships and temporary ones (for execution of a Set's program's). This fact has to be brought out by adding information to the IM in the form of objects and/or more relationships. > P.S. There are other items in this model that I've been pondering, like: > > Each Script uses a group of parameters. The values for the parameters > are > stored with the program (on a per program basis). One parameter is the > channel number and all Scripts use it. Other parameter types vary based > on > the script. Should I use a Specification object to indicate the various > type of parameter and another object to indicate what types are used > with a > particular script? Should the parameter values be a separate object or > attributes of the Program? How do I show that the "channel number" > parameter > must be in every group of parameters (each program has this common > attribute). I assume that a Program always uses the *same* script regardless of the Set accessing the program (otherwise the IM model is incomplete). If this is the case, then only certain parameters are *ever* accessed from a particular Program instance. This argues for subtyping Program so that the Program subtypes contain only the parameter attributes that are relevant to that program's Script and the Program supertype contains 'channel number'. It is generally consider Mildly Bad Form to have attributes that are not relevant (as opposed to it being Very Bad Form to have attributes that sometimes do not have meaningful values) during the life of an instance. If so, I don't think a subtyping solution to the active Channel problem above would be good because this would lead to a combinatorial proliferation of subtypes on the IM that would obscure the important ideas. As you suggest, you could leave 'channel number' in the Program object and create a separate Parameter object with a 1:Mc::Program:Parameter relationship. A possibly more elegant way would be to make the Parameter an associative object on R3 (you can use associatives on relationships other than M:M). This is more explicit about parameters existing solely for communication between Programs and Scripts, so I tend to like it better. > Maybe I don't need to go to that much detail in this model to give > people > a flavor of how to configure and use the box. More is better. | -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) How to model this constrained relationship? (LONGISH) Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- Paul Michali wrote: [description cut] > but you cannot have an entries in this table like this: > > Set | Program | Channel > 1 | 1 | A01 > 1 | 500 | A01 > ... > > What happens in the box is that the user "starts" one of the > four Sets and that causes all of the Programs in the Set to run > on the Channels assigned to the Programs. One cannot have a > single channel running two different programs. > > Any ideas on how I should model this constraint/restriction? It looks to me like there might be an object whose compound identifier is the set and channel ids, and where the program is a descriptive attribute (which will also be referential). This would appear to be an associative object on a relationship between Set and Channel. This assoc object would be have a relationship with Program. You would then want to look again at R1 and R2. Dave. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Tamerton Road, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com For embedded Systems Support mailto:armapps@gpsemi.com Subject: Re: (SMU) How to model this constrained relationship? (LONGISH) Mike Frankel writes to shlaer-mellor-users: -------------------------------------------------------------------- Paul Michali wrote: > > Paul Michali writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Hi, > > Since I haven't had a chance to use S-M since I took a training class > last year, I decided to try to model the objects for a piece of test > equipment we use at work. The setup of this equipment is somewhat non- > intuitive, so my goal was to use this model as a way of describing the > unit to aide in the understanding of how to configure this beast. > In doing the model, I came across a tough (for me) set of relationships > and was hoping that someone would have some useful suggestions. Here are > the main objects and relationships... > > The subject area is a Load box used to simulate phone calls over T1 > digital lines. Each T1 line has 24 channels, each of which can be used > to originate or terminate a phone call. There are four T1 lines (96 > channels) > in the box. Definitions: In the definitions that follow and examples you supply, you are actually describing two separate and very distinct subject matters (domains), yet you are trying to model them together in one. The first domain is that of Channel Management, which addresses phone lines, ports, and channel configurations. The second domain is that of OOA Model Simulation, where the goal is to set up a scenario of instance populations, and event scripts, and run them through a model execution engine. Channel Management is the client in the bridge it has to OOA Model Simulation. If you had one of the popular shlaer/mellor case tools to build your model, which comes with a simulation environment, you wouldn't have to model this domain at all. It would be realized already in your case tool purchase. If you need to write software which will feed "real" events from the real world into your Channel Management OOA model simulation, an extension to the Simulation domain beyond that addressed by the case tool may be needed, requiring some modeling in that subject matter. And if an actual executing piece of software running within a particular environment is your goal, there are likely other domains such as Communications, User I/F, etc.. that you will have to address as well. If you are presenting this example just to practice with the Shlaer/Mellor method, then the above mentioned two domains should keep you busy for a while, and make your mother proud. Your questions further down in your message may still be relevant after you partition the domains. But until you do, I wouldn't bother worrying about them. You have more important issues to take care of first. > > Channel - a hardware port on the equipment where simulated phone calls > are placed. Quantity = 96. > > Script - A series of commands to the load box to tell it what to do. > There > are both origination and termination scripts that are used on > both > ends of a call. There can be multiple scripts in the system, > some > originating and some terminating. > > Parameters - Each script uses a group of parameters during operation to > specify things like duration of the call, intercall time, > and > digits to dial. > > Program - The program ties the above three things together. It specifies > a > script to use, a channel to operate on and values for all of > the > parameters used by the script. Each program can contain > different > parameter values. One mandatory parameter is the "channel > number' > which identifies the Channel that the program will operate on. > > Set - Is a collection of programs. The user selects to start a set and > that > will run the programs in the set (which in turn, perform the > actions > specified by the scripts using the parameter values in the > program). > There are exactly four sets. > > Here is a piece of the model that is giving me some problems: > > +---------+ +----------+ > | | | | > | Channel | | Set | > | * ID | | * Number | > | | | | > +---------+ +----------+ > /|\ /|\ C > | /|\ > | | > | | > | +------------+ | R2 > | R1 C | | C | > +---------->> | Program | <<------+ > is assigned | * ID | contains > to | - Script(R)| > | | > +------------+ > C /|\ is used by > /|\ > | > | R3 > | > \|/ > +------------+ > | | > | Script | > | * Number | > | - Type | > | | > +------------+ > > Note: I didn't show associate objects for some of these relationships. > > So... > > A Set contains several Programs. > A Program could be used in several different Sets. > A Program uses exactly one Script. > A Script can be used by several Programs. > A Program assigns exactly one Channel. > A Channel can be assigned to several Programs. > > This last clause is where there is an added constraint that I'm having > trouble with. The Channel can be assigned to several Programs as long as > the programs are not in the same Set. Here are table views of some > typical > entries. > > Program | Set Program | Channel > 1 | 1 1 | A01 <------+ > 2 | 1 2 | A02 <--+ | > 3 | 1 3 | A03 | | > 401 | 2 401 | A01 <------+ > 403 | 2 403 | A05 | > 402 | 2 402 | A02 <--+ > > So, if one was to create a table with "allowable" entries, you could > have > the following: > > Set | Program | Channel > 1 | 1 | A01 > 1 | 2 | A02 > 1 | 3 | A03 > 2 | 401 | A01 > 2 | 402 | A02 > 2 | 403 | A05 > > but you cannot have an entries in this table like this: > > Set | Program | Channel > 1 | 1 | A01 > 1 | 500 | A01 > ... > > What happens in the box is that the user "starts" one of the four Sets > and that causes all of the Programs in the Set to run on the Channels > assigned to the Programs. One cannot have a single channel running two > different programs. > > Any ideas on how I should model this constraint/restriction? > > Thanks in advance, > > PCM > P.S. There are other items in this model that I've been pondering, like: > > Each Script uses a group of parameters. The values for the parameters > are > stored with the program (on a per program basis). One parameter is the > channel number and all Scripts use it. Other parameter types vary based > on > the script. Should I use a Specification object to indicate the various > type of parameter and another object to indicate what types are used > with a > particular script? Should the parameter values be a separate object or > attributes of the Program? How do I show that the "channel number" > parameter > must be in every group of parameters (each program has this common > attribute). > > Maybe I don't need to go to that much detail in this model to give > people > a flavor of how to configure and use the box. > > ff | Paul Michali | Phone: (603)-625-4050 x2576 > f | Summa Four Inc. | Fax : (603)-668-4491 > ssfff | 25 Sundial Avenue | FTP : ftp://ftp.summa4.com > s f | Manchester, NH 03103-7251 | Web : http://www.summa4.com > s f | | > sss f | | -- ----------------------------------------------- Mike Frankel Director of Software Engineering Esprit Systems Consulting, Inc. 610-436-8290 fax 610-436-9848 mfrankel@EspritInc.com http://www.EspritInc.com -->BASELINE Domain Models -->Object Methods Training and Consulting -->Structured Methods Training and Consulting "Strategies for Computer and Human Systems" ----------------------------------------------- Subject: Re: (SMU) How to model this constrained relationship? (LONGISH) Paul Michali writes to shlaer-mellor-users: -------------------------------------------------------------------- lahman wrote: > > Responding to Michali... > > > What happens in the box is that the user "starts" one of the four Sets > > and that causes all of the Programs in the Set to run on the Channels > > assigned to the Programs. One cannot have a single channel running two > > different programs. > > When are the Channels assigned to Programs? Since the program seems to > have an attribute for the 'channel number' parameter, I infer that this > is fixed when the Program objects are instantiated and that when a user > starts a Set, somehow a particular suite of programs is selected (e.g., > the associative object on R2 is a Request Type, or somesuch). > > If this is the case, then the conditionality on R1 and R2 is > "hard-wired" at system initialization rather than popping in and out as > processing continues. That is, at system initialization all instances > and relationships that actually exist will be defined and will remian so > throughout the execution. Actually, the "user" can assign a channel to the program at any time and therefore it is not fixed at system initialization time. > > In this situation the crucial issue is that the relationships do not > capture the ephemeral nature of an "active" channel that is related to > Set through Program only under particular circumstances (e.g., a > particular user request). > > One way would be to define an Active Program object with these > relationships: Interesting concept, that of having two objects, one that represents an active Program and one that represents the set of all programs. I'm not sure it still applies. I guess one could consider Programs that are in a Set as "active". (Since this is a Mc:Mc between Program and Set, I guess I'd model an associative object "Program In Set" for that relationship). > > R4::Active Program:Program::1:1::defines channel for:is selected from > > R5::Active Program:Set::M:1::selects:provides service for > > R6::Active Program:Channel::1:1::is active for:utilizes > > The Active Program would have a compound identifier: 'Set' and 'Program > ID' where 'Program ID' was the same as Program's 'ID'. Now the R1 > relationship allows Channel to be associated with many programs, but the > R5 and R6 relationships restrict it to only one program in one Set when > it is active. This is where I'm getting hung up. I don't see how R5 and R6 are enforcing the restriction. What I want to show is that a program can be in several sets and a channel can be in several programs, as long as the channel is not in the same set more than once. Can you elaborate? > > P.S. There are other items in this model that I've been pondering, like: > > > > Each Script uses a group of parameters. The values for the parameters > > are > > stored with the program (on a per program basis). One parameter is the > > channel number and all Scripts use it. Other parameter types vary based > > on > > the script. Should I use a Specification object to indicate the various > > type of parameter and another object to indicate what types are used > > with a > > particular script? Should the parameter values be a separate object or > > attributes of the Program? How do I show that the "channel number" > > parameter > > must be in every group of parameters (each program has this common > > attribute). > > I assume that a Program always uses the *same* script regardless of the > Set accessing the program (otherwise the IM model is incomplete). If > this is the case, then only certain parameters are *ever* accessed from > a particular Program instance. This argues for subtyping Program so > that the Program subtypes contain only the parameter attributes that are > relevant to that program's Script and the Program supertype contains > 'channel number'. Yes, the script and the program are tied together. Any set that runs the program will use that script for the program. > As you suggest, you could leave 'channel number' in the Program object > and create a separate Parameter object with a 1:Mc::Program:Parameter > relationship. A possibly more elegant way would be to make the > Parameter an associative object on R3 (you can use associatives on > relationships other than M:M). This is more explicit about parameters > existing solely for communication between Programs and Scripts, so I > tend to like it better. Yes, I had been thinking along the same lines. Probably the only difference is that (co-workers and ) I came up with an associate object called a Parameter Group to represent the "set" of parameters that are applicable to that particular Program and Script pair. PCM -- ff | Paul Michali | Phone: (603)-625-4050 x2576 f | Summa Four Inc. | Fax : (603)-668-4491 ssfff | 25 Sundial Avenue | FTP : ftp://ftp.summa4.com s f | Manchester, NH 03103-7251 | Web : http://www.summa4.com s f | | sss f | | Subject: Re: (SMU) How to model this constrained relationship? (LONGISH) Paul Michali writes to shlaer-mellor-users: -------------------------------------------------------------------- Dave Whipp wrote: > > Paul Michali wrote: > > [description cut] > > but you cannot have an entries in this table like this: > > > > Set | Program | Channel > > 1 | 1 | A01 > > 1 | 500 | A01 > > ... > > > > What happens in the box is that the user "starts" one of the > > four Sets and that causes all of the Programs in the Set to run > > on the Channels assigned to the Programs. One cannot have a > > single channel running two different programs. > > > > Any ideas on how I should model this constraint/restriction? > > It looks to me like there might be an object whose compound > identifier is the set and channel ids, and where the program is > a descriptive attribute (which will also be referential). > > This would appear to be an associative object on a relationship > between Set and Channel. This assoc object would be have a > relationship with Program. Yes, I could make an associative object, say "Channel In Set" that shows what channels are in each set. That would prevent duplicates of channels in a single set. What I can't figure out is how to define that relationship in terms of Channels assigned to Programs and Programs contained in Sets. >From the user interface on the equipment, one can assign a Channel to a Program and add a Program to a Set, but one can't directly allocate a Channel to a Set. So I'm trying to show that in the model and that is what is giving me grief. PCM -- ff | Paul Michali | Phone: (603)-625-4050 x2576 f | Summa Four Inc. | Fax : (603)-668-4491 ssfff | 25 Sundial Avenue | FTP : ftp://ftp.summa4.com s f | Manchester, NH 03103-7251 | Web : http://www.summa4.com s f | | sss f | | Subject: Re: (SMU) How to model this constrained relationship? (LONGISH) lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Frankel... > In the definitions that follow and examples you supply, you are actually > describing > two separate and very distinct subject matters (domains), yet you are > trying > to model them together in one. > > The first domain is that of Channel Management, which addresses phone > lines, > ports, and channel configurations. The second domain is that of OOA > Model > Simulation, where the goal is to set up a scenario of instance > populations, > and event scripts, and run them through a model execution engine. > Channel > Management is the client in the bridge it has to OOA Model Simulation. > If you had > one of the popular shlaer/mellor case tools to build your model, which > comes > with a simulation environment, you wouldn't have to model this domain at > all. > It would be realized already in your case tool purchase. > > If you need to write software which will feed "real" events from the > real world > into your Channel Management OOA model simulation, an extension to the > Simulation > domain beyond that addressed by the case tool may be needed, requiring > some > modeling in that subject matter. I have to disagree with this assessment. I believe the original question *was* an issue for what you call Channel Management. The IM had a problem in that the relationships did not properly capture an important feature of the system: that a Channel could not be related to two Programs in the same Set. This seems to me to be very clearly a constraint when describing the management of channels. In fact, I did not read Michali's original query to suggest anything remotely resembling a simulation issue. Could you elaborate on what you mean by this? -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) Reflexive Relationships croche@tellabs.com writes to shlaer-mellor-users: -------------------------------------------------------------------- Dear S-M Users, I recently came across an interesting question concerning reflexive relationships. Actually, there are two questions. The first question is how to create a set theory graphic defining/describing how reflexive relationships are graphically drawn? For example, I created a set theory graphic which looks like the following for a 1:1 Reflexive relationship: Set A --------- | *A3 \ | *A1 / \ *A4 *A2 | _________/ This is pretty difficult to draw, but A1 is related to A2 and A3 is related to A4 (relationship lines are omitted). Is this correct or should the relationships be chained as in a queue concept: A1<-->A2<-->A3<-->A4 and A4 is related to A1 as well. I was confused with this chaining idea since it violates the 1:1 type because each instance is now related to 2 other instances, not 1. Am I right? Is there a correct set theory graphic for this type of relationship? This is how the second question came about. If there were only one instance in the set, can there be a relationship between the instance and itself (A1 related to A1)? Or even if there were 4 instances in the set, can any one of them be related to themself? This didn't make much sense to me since why would you want to traverse a relationship just to acquire the same instance? Can someone answer these two questions for me? Thanks, -Christina Subject: Re: (SMU) Reflexive Relationships Patrick Greenlee writes to shlaer-mellor-users: -------------------------------------------------------------------- This didn't make much sense to me since why would >you want to traverse a relationship just to acquire the same instance? > >Can someone answer me? > >Thanks, >-Christina A relationship beginning and ending at the same object doesn't imply a relationship between an instance and itself. Think of one instance of an object having a relationship with another instance of the same object. e.g. Think of "teenager has crush on teenager" as involving two teenagers. Patrick Subject: Re: (SMU) Reflexive Relationships croche@tellabs.com writes to shlaer-mellor-users: -------------------------------------------------------------------- > > Patrick Greenlee writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > This didn't make much sense to me since why would > >you want to traverse a relationship just to acquire the same instance? > > > >Can someone answer me? > > > >Thanks, > >-Christina > > A relationship beginning and ending at the same object doesn't imply a > relationship between an instance and itself. Think of one instance of an > object having a relationship with another instance of the same object. > e.g. Think of "teenager has crush on teenager" as involving two teenagers. > > Patrick Patrick, I think you've misinterpreted what my question was. I understand the relationship between one instance of an object and another instance of the same object (i.e. "a teenager having a crush on another teenager"). My question was can an instance be related to itself (the same instance, not a different instance of that same object)? For example if instance A1 is part of the set of instances of object A, can it be related to itself, as opposed to another instance, like A2. i.e. *A1<-- ^ | | | ----- -Christina Subject: Re: (SMU) How to model this constrained relationship? (LONGISH) lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Michali... > > > > R4::Active Program:Program::1:1::defines channel for:is selected from > > > > R5::Active Program:Set::M:1::selects:provides service for > > > > R6::Active Program:Channel::1:1::is active for:utilizes > > > > The Active Program would have a compound identifier: 'Set' and 'Program > > ID' where 'Program ID' was the same as Program's 'ID'. Now the R1 > > relationship allows Channel to be associated with many programs, but the > > R5 and R6 relationships restrict it to only one program in one Set when > > it is active. > > This is where I'm getting hung up. I don't see how R5 and R6 are > enforcing > the restriction. What I want to show is that a program can be in several > sets and a channel can be in several programs, as long as the channel is > not in the same set more than once. Can you elaborate? I was supplementing your diagram, not replacing it. The R1 relationship directly to Program would stil capture the idea that the channel is associated with many Programs which can be in many Sets. A set may have several Atcive Programs running at the same time, which means that several Channels may be active. However, since the Channel is related to only one Active Program and the Active Program is associated with only one Set, any particular Channel instance can get to only one Set via one Active Program in the "active" path. For the Channel instance to be active in more than one program in the Set at the same time, the R6 relation would have to be 1:M with M on the Active Program side. However, you are correct that this does not preclude the same Channel being associated with two Programs referenced by the same Set. This would be valid provided the two Programs are never active at the same time. In the original question I thought the issue was simply to avoid over-allocating a Channel when a Set's active Programs were running. If you truly want to ensure that the Channel is not referenced by more than one Program in the Set, regardless of which Programs are active, then Whipp's solution is better. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) How to model this constrained relationship? (LONGISH) Mike Frankel writes to shlaer-mellor-users: -------------------------------------------------------------------- lahman wrote: > > lahman writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Responding to Frankel... > > > In the definitions that follow and examples you supply, you are actually > > describing > > two separate and very distinct subject matters (domains), yet you are > > trying > > to model them together in one. > > > > The first domain is that of Channel Management, which addresses phone > > lines, > > ports, and channel configurations. The second domain is that of OOA > > Model > > Simulation, where the goal is to set up a scenario of instance > > populations, > > and event scripts, and run them through a model execution engine. > > Channel > > Management is the client in the bridge it has to OOA Model Simulation. > > If you had > > one of the popular shlaer/mellor case tools to build your model, which > > comes > > with a simulation environment, you wouldn't have to model this domain at > > all. > > It would be realized already in your case tool purchase. > > > > If you need to write software which will feed "real" events from the > > real world > > into your Channel Management OOA model simulation, an extension to the > > Simulation > > domain beyond that addressed by the case tool may be needed, requiring > > some > > modeling in that subject matter. > > I have to disagree with this assessment. I believe the original > question *was* an issue for what you call Channel Management. The IM > had a problem in that the relationships did not properly capture an > important feature of the system: that a Channel could not be related to > two Programs in the same Set. This seems to me to be very clearly a > constraint when describing the management of channels. > > In fact, I did not read Michali's original query to suggest anything > remotely resembling a simulation issue. Could you elaborate on what you > mean by this? > Here is a line from Paul's message: "The subject area is a Load box used to simulate phone calls over T1 digital lines." The intent is clearly to model desired behavior of T1 digital lines, and to "poke" at the model with likely scenarios of events directed at likely initial instances of Channels and Lines. The vocabulary of scripts (Simulation) is quite distinct from that of telecom (Channel Management). The constraints that Paul is desiring to model most likely do exist, yet should be embodied in the content of the bridge from Channel Management to Simulation, which defines the initial instances of scripts and parameters which the Simulation domain will use to drive its client domain. This may not appear to be as much fun as using the OIM, but is preferred nonetheless to preserve the relative independent reuse potential of these inherently distinct subject matters. -- ----------------------------------------------- Mike Frankel Director of Software Engineering Esprit Systems Consulting, Inc. 610-436-8290 fax 610-436-9848 mfrankel@EspritInc.com http://www.EspritInc.com -->BASELINE Domain Models -->Object Methods Training and Consulting -->Structured Methods Training and Consulting "Strategies for Computer and Human Systems" ----------------------------------------------- Subject: (SMU) Is a creation state a state? David Stone 5887 writes to shlaer-mellor-users: -------------------------------------------------------------------- I've been reading the OOA96 report, and it seems to me to allow a great deal of latitude in when object instances may be created, so much so that it changes the nature of a creation state. To start from a concrete example: Suppose an object is declared in the information model as: OBJECT OBJ * id val and its state model starts as follows (I have used Kennedy-Carter's ASL, but the issue doesn't depend on the details of ASL). | | object_creation_event() v oh1 = create OBJECT with id = 0 and val = 1 oh2 = create OBJECT with id = 1 and val = 2 generate OBJ1:goto_next() to oh1 generate OBJ1:goto_next() to oh2 found_oh1 = find OBJECT where id = 0 found_oh2 = find OBJECT where id = 1 found_val1 = found_oh1.val found_val2 = found_oh2.val # What are the possible values of found_val1 and found_val2 here? | | goto_next() v this.val = 3 ... I assume the concurrent interpretation of time (Modeling the World in States, p105, item 3a). The creation of multiple instances is explicitly allowed by the OOA96 Report (p42, item 6). The method clearly states that the action of a state is completely executed before the next of that instance (MtWiS, p105, item 4). But which instance does the creation state belong to? Is it neither object instance, in which case (at the comment, starting #) found_val1 might be 1 or 3, and found_val2 might be 2 or 3? Is it the first-created object instance, in which case we could be sure that found_val1 would be 1? Is it (somehow) both object instances? If the answer is in the published method documentation, I should be very grateful for the reference. -- David Stone Sent by courtesy of, but not an official communication from: Simoco Europe, P.O.Box 24, St Andrews Rd, CAMBRIDGE, CB4 1DP, UK Subject: Re: (SMU) How to model this constrained relationship? (LONGISH) Paul Michali writes to shlaer-mellor-users: -------------------------------------------------------------------- Mike Frankel wrote: > > Here is a line from Paul's message: > > "The subject area is a Load box used to simulate phone calls over T1 > digital lines." > > The intent is clearly to model desired behavior of T1 digital lines, and > to "poke" at the model with likely scenarios of events directed at > likely initial instances of Channels and Lines. Ah, I think I see the source of the misunderstanding. The product that I am trying to model acts as a phone call simulator. I am not trying to model (or simulate) phone calls over T1 lines. What am trying to do is model how this Load box is configured and operated (for the purposes of practicing S-M and to use it to describe how this confusing piece of equipment is configured - during that process I have uncovered a "difficult", at least for me, modelling problem). Unfortunately, the terminology used in this domain, overlaps alot with many S/W terms. For example, the Script in the model is actually some source code (readable) written in some proprietary language that is downloaded to the box and then invoked as a result of a user selecting to "start" a Set. . > The vocabulary of > scripts (Simulation) > is quite distinct from that of telecom (Channel Management). Now it should be clear (if I explained well enough above :^) that the scripts are not something that I write as part of simulation, but are in fact part of the domain I am modeling. I see this problem as purely a modelling problem, where I'm trying to describe a relationship that involves three objects. PCM Subject: Re: (SMU) How to model this constrained relationship? (LONGISH) lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Once again I sent the original response only teh individual and had to resend it to SMUG. John/Ralph -- can you fix the SMUG echo so that it places SMUG's URL in the FROM of the echo message rather than the user who sent the original message being echoed? My mailer (Netscape) automatically inserts the FROM URL into the TO address when I respond to a message. Unfortunately I keep forgetting to check for that and the individual's address does not get changed to SMUG. Responding to Frankel... > Here is a line from Paul's message: > > "The subject area is a Load box used to simulate phone calls over T1 > digital lines." > > The intent is clearly to model desired behavior of T1 digital lines, and > to "poke" at the model with likely scenarios of events directed at > likely initial instances of Channels and Lines. The vocabulary of > scripts (Simulation) > is quite distinct from that of telecom (Channel Management). > > The constraints that Paul is desiring to model most likely do exist, yet > should > be embodied in the content of the bridge from Channel Management to > Simulation, which > defines the initial instances of scripts and parameters which the > Simulation domain will > use to drive its client domain. This may not appear to be as much fun as > using the > OIM, but is preferred nonetheless to preserve the relative independent > reuse potential > of these inherently distinct subject matters. OK, I see where you are going with this. It was less clear to me so I did not interpret Script the same way. I assumed Script represented the role player that defined which programs execute in response to a particular user request. In this case Script is not part of the simulation, it is part of your Channel Management because it is part of the system being simulated. Thus I assumed the IM presented was purely a model of the way the real system worked. If Script really is a simulation artifact (e.g., it is a list of user requests to be executed), then I agree that the simulation aspects are a different subject matter and belong in a different domain. Nonetheless I have two caveats (who would expect less of me?). First, I disagree that the relevant constraint would belong in the bridge. The fact that the same Channel instance cannot be associated with two Programs from the Set is a fact of the way the system being simulated works. It remains a fact even if there is no simulation. This is properly modeled as part of Channel Management rather than a bridge. Second, it *may* be more clear to model a counterpart Script object in the domain even though its main subject matter is in another domain. This depends upon the overall application and the intent of the Load Box domain (which we don't know at this point). The Load Box probably might have no use except in an application that simulates T1 processing. If that is the case it may be clearer to have a Script counterpart object in Load Box. In this case Script would effectively be a bridge, but the relationship of the bridge to the domain processing might be clearer. The Simulation domain would still provide the mechanics of sequencing user requests, timing, and the like. In this situation the Script in Channel Management is a high level abstraction of what may actually be complex interactions among several objects in the Simulation domain. However, if Load Box lives solely to service simulation it may be appropriate to explicitly include such an abstraction in that domain. My point is that so long as the level of abstraction of the Script object in Channel Management is different than that of the Simulation domain subject matter, using it is not necessarily a problem. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Reflexive Relationships lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Croche... > I think you've misinterpreted what my question was. I understand the > relationship between one instance of an object and another instance > of the same object (i.e. "a teenager having a crush on another teenager"). > My question was can an instance be related to itself (the same instance, > not a different instance of that same object)? > > For example if instance A1 is part of the set of instances of object A, > can it be related to itself, as opposed to another instance, like A2. > i.e. > *A1<-- > ^ | > | | > ----- I didn't respond to your original question because the last time I took a set theory course was in 1958 and most of the details seeped out through my toes long ago. So you can attach the appropriate skepticism to this Engineer's answer. I think the answer is No. I believe navigation is different than selection. Suppose I have a set of Persons where one attribute is Hair Color. I might resonably have a reflexive relationship of "has the same hair color as". Suppose I am an instance of Person performing some action. If I simply make a query of the set for all Persons with Hair Color = Grey, I would expect that subset to come back including myself. This is a reasonable result because one qualifying instance is no inditinguishable from another in the context of a general set query. However, if I navigate the relationship I would expect to get back a subset that did not include myself. When I navigate relationships I think the idea of connection to Others is implicit; I move from myself to another. The instances in the navigation subset are distinguished from my instance by the fact that they are connected to me. So I agree with your original assessment that connection to oneself is not a useful concept. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Is a creation state a state? lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Stone... > | > | object_creation_event() > v > > oh1 = create OBJECT with id = 0 and val = 1 > oh2 = create OBJECT with id = 1 and val = 2 > generate OBJ1:goto_next() to oh1 > generate OBJ1:goto_next() to oh2 > found_oh1 = find OBJECT where id = 0 > found_oh2 = find OBJECT where id = 1 > found_val1 = found_oh1.val > found_val2 = found_oh2.val > # What are the possible values of found_val1 and found_val2 here? > > | > | goto_next() > v > > this.val = 3 > ... By coincidence there was a thread about basically this issue a couple of weeks ago. You might want to download it from PT when this month's log becomes available. I believe the race conditions you site could apply in any state action. For example, your create state could be a simple action in an object other than OBJ. So the problem is not limited to create states; it is a general issue of data consistency. I believe the answer is simple for an asynchronous architecture. The create accessors invoked are synchronous as are the data accessors. Therefore the translation must ensure that the OBJ1: events are not processed until the action completes because the data in oh1 and oh2 must be consistent throughout the action. That is, in an asynchronous system the time of execution of the events (without architectural intervention in the form of a delay) would be indeterminate and, therefore, the data accessed would be ambiguous and, cosequently, possibly inconsistent. (The examples in the thread were more convoluted to illustrate incorrect computations that result in changing the data behind the action's back.) So in this situation the values should be 1 and 2. For the synchronous case I think the answer is that the translation has to be consistent. It either always executes the events as they occur in the action (accessed values always 3) or it always defers their execution until the end of the action (accessed values 1 and 2). The key issue is that the analyst, when writing the action, must be able to count on a particular, unambiguous behavior. I argued that the deferral is required because the behavior needs to be consistent if the system is ported between synchronous and asynchronous architectures (i.e., porting should be transparent to domain simulation). However, one could counter that this is bending the meaning of "synchronous" quite a bit. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Reflexive Relationships "John D. Yeager" writes to shlaer-mellor-users: -------------------------------------------------------------------- croche@tellabs.com wrote: > > > > > This didn't make much sense to me since why would > > >you want to traverse a relationship just to acquire the same instance? > > > > > >Can someone answer me? > > > > > >Thanks, > > >-Christina > > > ... [Response elided] > > > My question was can an instance be related to itself (the same instance, > not a different instance of that same object)? > > For example if instance A1 is part of the set of instances of object A, > can it be related to itself, as opposed to another instance, like A2. > i.e. > *A1<-- > ^ | > | | > ----- > > -Christina The short answer is yes. However, that will be a particular instance of that relationship. That is, one will typically not have a relationship in which *all* instances are self related. For instance, a contrived example might be a relationship between taxpayers with one end labeled "files tax return under social security number of taxpayer". That is a spouse filing joint return would "point" to the primary taxpayer. What about the primary taxpayer? Are they self related? It depends on how one defines the relationship. It can make the description of processing easier if this relationship is not conditional; that is the primary taxpayer refers to itself. One follows this relationship only to find oneself, but *until* one has followed the relationship one doesn't know this. -- John Yeager Cross-Product Architecture Lucent Technologies, Inc., Bell Labs johnyeager@lucent.com Business Communications Systems voice: (732) 957-3085 200 Laurel Ave, 4C-514 fax: (732) 957-4142 Middletown, NJ 07748 Subject: Re: (SMU) Is a creation state a state? peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 12:20 PM 9/23/97 +0100, shlaer-mellor-users@projtech.com wrote: >David Stone 5887 writes to shlaer-mellor-users: >-------------------------------------------------------------------- > > >I've been reading the OOA96 report, and it seems to me to allow a >great deal of latitude in when object instances may be created, so >much so that it changes the nature of a creation state. >... >To start from a concrete example: >...OBJECT OBJ... * id, val >The method clearly states that the action of a state is completely >executed before the next of that instance (MtWiS, p105, item 4). But >which instance does the creation state belong to? Interesting issue. The Create state belongs with neither instance - it is "static". While stating you subscribe to the "concurrent interpretation of time", this is not a rigorous specification of execution semantics - is it an incomplete assertion. There are significant issues with the "concurrent interpretation of time" perspective - as applied in through the architecture. Rather than study the issue here at length, let me just say that the Software Architecture must provide some mechanical support so the necessary rules of OOA are enforced. In this case, it means the architect must interpret whether a Create accessor must somehow lock an instance population to prevent such problems. One possible detail of a workable interpretation of the "concurrent interpretation of time" is to slightly restrict parallelism: ARCHITECTURE POLICY - a newly created instance is "execution locked" (can receive no events) until the action that created it is complete. - for example. >If the answer is in the published method documentation, I should be >very grateful for the reference. Well, it not available in anything I've read. Subscribing to the "concurrent interpretation of time" should not be interpreted by the architect as a license to freely dream of wonderfully efficient schemes of parallel execution. On the contrary - it is a burden of great magnitude, to discover the true protections of the "interleaved" scheme, and duplicate them through lower-level mechanisms as necessary, while keeping the analysis free of the implementation issues. Good luck. ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice: +01 508-384-1392 | peterf@pathfindersol.com fax: +01 508-384-7906 | ____________________________________________________| Subject: Re: (SMU) Reflexive Relationships Leora Bell writes to shlaer-mellor-users: -------------------------------------------------------------------- lahman wrote: > > lahman writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Responding to Croche... > > > I think you've misinterpreted what my question was. I understand the > > relationship between one instance of an object and another instance > > of the same object (i.e. "a teenager having a crush on another teenager"). > > My question was can an instance be related to itself (the same instance, > > not a different instance of that same object)? > > > > For example if instance A1 is part of the set of instances of object A, > > can it be related to itself, as opposed to another instance, like A2. > > i.e. > > *A1<-- > > ^ | > > | | > > ----- > > I didn't respond to your original question because the last time I took > a set theory course was in 1958 and most of the details seeped out > through my toes long ago. So you can attach the appropriate skepticism > to this Engineer's answer. > > I think the answer is No. I believe navigation is different than > selection. Suppose I have a set of Persons where one attribute is Hair > Color. I might resonably have a reflexive relationship of "has the same > hair color as". Suppose I am an instance of Person performing some > action. > > If I simply make a query of the set for all Persons with Hair Color = > Grey, I would expect that subset to come back including myself. This is > a reasonable result because one qualifying instance is no > inditinguishable from another in the context of a general set query. > > However, if I navigate the relationship I would expect to get back a > subset that did not include myself. When I navigate relationships I > think the idea of connection to Others is implicit; I move from myself > to another. The instances in the navigation subset are distinguished > from my instance by the fact that they are connected to me. So I agree > with your original assessment that connection to oneself is not a useful > concept. > > -- > H. S. Lahman There is nothing wrong with me that > 321 Harrison Av L51 couldn't be cured by a capful of Drano > Boston, MA 02118-2238 > v(617)422-3842 > f(617)422-3100 > lahman@atb.teradyne.com According to Leon Starr, "How to Build Shlaer-Mellor Object Models", Binary Relationships. pages 56 and 57, one instance of an object may indeed associate with itself. A possible application for such a relationship might be where recursion is desired. Subject: re: (SMU) Reflexive Relationships Gordon Colburn writes to shlaer-mellor-users: -------------------------------------------------------------------- Christina, > I was confused with this chaining idea since it > violates the 1:1 type because each instance is now related to 2 other > instances, not 1. Am I right? According to chapter 4 of OOA96, your reflexive relationship with object A does violate the 1:1 cardinality, as A2 is related to both A1 and to A3 in exactly the same sense. Chapter 4 suggests 2 solutions: making the relationship Mc:Mc, or using an asymmetric reflexive relationship (this involves turning A into an isa hierarchy). You can download OOA96 from www.projtech.com for full details. However, before OOA96 came out, my team and I made use of asymmetric relationships between an object and itself (we called these "recursive relationships"). Observing that relationships between two different objects have two different names, cardinalities, and conditionalities, we allowed relationships between an object and itself to have two different "directions" as well. For example: +-------------+ | | | TRAIN_CAR | | |<--+ | | | +-------------+ | ^ | | "precedes" 1c "follows" 1c | | | +-----R1----+ Sure, each TRAIN_CAR may be related to (via R1) two other TRAIN_CARs, but each TRAIN_CAR "precedes" at most one other car, and "follows" at most one other car. Hence the 1:1 cardinality is not violated. > If there were only one instance > in the set, can there be a relationship between the instance and itself (A1 > related to A1)? Or even if there were 4 instances in the set, can any one of > them be related to themself? This didn't make much sense to me since why would > you want to traverse a relationship just to acquire the same instance? I do not see anything wrong in a reflexive relationship with an instance which is related to itself. The following example is from the (hypothetical) information model of a state machine from an architecture domain. Note that the relationship is asymetric: +---------+ | STATE |<<----+ | | | +---------+ "can transition to" Mc ^ | ^ | | | "can transition | +------------+ | from" Mc | | TRANSITION | +------------+<---------| | +------------+ Since, in OOA, it is legal for an event to cause a transition from a state back into the same state, a legal instantiation of this model could have a particular instance of STATE related to itself. As asymmetric reflexive relationships between an object and itself seem not to be supported (or at least recommended) under OOA96, make sure your architecture can deal with bi-directional traversal of such relationships before using them. I have used them with complete success, and have found that the resulting models have fewer objects and, in many cases, are easier to understand than models in which "isa" hierarchies are used to model asymmetric reflexive relationships. However, showing how such relationships are formalized requires a bit of thought. -Gordon Colburn Subject: Re: (SMU) Reflexive Relationships Jay Case writes to shlaer-mellor-users: -------------------------------------------------------------------- > Gordon Colburn writes to shlaer-mellor-users: > -------------------------------------------------------------------- [snipped] > According to chapter 4 of OOA96, your reflexive relationship with object > A does violate the 1:1 cardinality, as A2 is related to both A1 and to A3 in > exactly the same sense. Chapter 4 suggests 2 solutions: making > the relationship Mc:Mc, or using an asymmetric reflexive relationship > (this involves turning A into an isa hierarchy). You can download OOA96 > from www.projtech.com for full details. Since OOA96 came up, one aspect of the 'full details' could use some minor clarification. WRT symmetric reflexive: "To ensure that an instance of the relationship appears only once in the model, always formalize the relationship with an associative object regardless of the multiplicity of the relationship itself." OOA96, Chpt. 4.2, pg 19. Is this a "Rule" or a "Reccomendation"? I'm assuming the latter, as the singularity could equally be maintained by the raw dynamics of the model. The age old question of OIM 'conceptual beauty' vs 'engineering discression'... Thanks - Jay Subject: Re: (SMU) Reflexive Relationships lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Bell... > According to Leon Starr, "How to Build Shlaer-Mellor Object Models", > Binary Relationships. pages 56 and 57, one instance of an object may > indeed associate with itself. A possible application for such a > relationship might be where recursion is desired. So much for a carefully reasoned engineering solution. I'm still not sure I understand what it means to be related to oneself, though. I am also not sure I follow your recursion thought. I think of the IM as a static representation while recursion implies dynamic to me. I can think of situations where one might want to navigate a relationship repeatedly, but these are more in the nature of iteration and wouldn't have much to do with the relationship per se (i.e., require an instance to be related to itself). Do you have an example where recursion might lead to an instance related to itself? -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Reflexive Relationships lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Colburn... > +---------+ > | STATE |<<----+ > | | | > +---------+ "can transition to" Mc > ^ | > ^ | > | | > "can transition | +------------+ > | from" Mc | | TRANSITION | > +------------+<---------| | > +------------+ > > Since, in OOA, it is legal for an event to cause a transition from a state > back into the same state, a legal instantiation of this model could have > a particular instance of STATE related to itself. Very nice example of the point. But why the conditionality? Once you have a valid entry in the STT, it seems to me the relationship becomes unconditional. The conditionality implies an orphan state that never transitions, in or out. > As asymmetric reflexive relationships between an object and itself seem not > to be supported (or at least recommended) under OOA96, make sure your > architecture can deal with bi-directional traversal of such relationships > before using them. I have used them with complete success, and have found > that the resulting models have fewer objects and, in many cases, are > easier to understand than models in which "isa" hierarchies are used to > model asymmetric reflexive relationships. However, showing > how such relationships are formalized requires a bit of thought. I agree insofar as the STATE is concerned. However, for the TRAIN_CAR I would vote for the isa version because it is clearer about circumstance of the conditionality. In TRAIN-CAR there is an awkwardness about the first/last cars that is left as an exercise for the relationship description. Similarly, if STATE really is conditional, I would prefer a more verbose model to make that clear. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Reflexive Relationships Gordon Colburn writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Lahman: > > +---------+ > > | STATE |<<----+ > > | | | > > +---------+ "can transition to" Mc > > ^ | > > ^ | > > | | > > "can transition | +------------+ > > | from" Mc | | TRANSITION | > > +------------+<---------| | > > +------------+ > > > > Since, in OOA, it is legal for an event to cause a transition from a state > > back into the same state, a legal instantiation of this model could have > > a particular instance of STATE related to itself. > > Very nice example of the point. Thanks! > > But why the conditionality? Once you have a valid entry in the STT, it > seems to me the relationship becomes unconditional. The conditionality > implies an orphan state that never transitions, in or out. The relationship is conditional because, while almost all states have a transition in or out, some states (initial states of synchronously created objects) have no transitions in, and some states (final and deletion states) have no transitions out. So, the asymmetric relationship must be conditional in both directions. Of course, you could get terribly explicit and model it as: a state isa initial state, a terminal state, a deletion state, etc. This might remove the conditionality, but at the expense of a more complex model. I would base the decision between explicitness and simplicity on whether there are interesting behavioral differences between initial states, terminal states, etc. -Gordon Colburn Subject: Re: (SMU) Reflexive Relationships lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Colburn... > > > +---------+ > > > | STATE |<<----+ > > > | | | > > > +---------+ "can transition to" Mc > > > ^ | > > > ^ | > > > | | > > > "can transition | +------------+ > > > | from" Mc | | TRANSITION | > > > +------------+<---------| | > > > +------------+ > > The relationship is conditional because, while almost all states have > a transition in or out, some states (initial states of synchronously > created objects) have no transitions in, and some states (final and > deletion states) have no transitions out. So, the asymmetric > relationship must be conditional in both directions. Ah, a good example of why one needs to be careful defining relationship labels. (Not to mention the need for me to *read* them carefully!) If the labels were changed to remove the to/from connotation (e.g., "is connected via transition with") *then* the relationship is symmetric and the conditionality could be removed. On thinking some more about it, I think my preference for the sub/supertype form when there is conditionality is not worthwhile. In a reflexive relationship this will almost always be due to start/end problems. Thus the conditional construct is efffectively an idiom, given the to/from labels, for the situation where there is a start/end. Therefore this should not need more explicit description for anyone familiar with the idiom. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Is a creation state a state? "Greg Wiley" writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to David Stone: > I assume the concurrent interpretation of time (Modeling the World in > States, p105, item 3a). I'm not sure that it matters. > The method clearly states that the action of a state is completely > executed before the next of that instance (MtWiS, p105, item 4). But > which instance does the creation state belong to? I think this is your problem. Instances don't "belong to" a state. They are "in" a state. I regard a create accessor as shorthand for a create in accessor. So in your example, you have created two objects and declared them each to be in that creation state. However, this leads to the question of "when" an instance is in a given state. In Object Lifecycles (p.46), "an action must update the current state attribute to correspond with the state the instance is now occupying as a result of executing the action." And, "but since all actions must do this, some analysts and projects omit this step from the STD by convention." I would venture that the create (in) accessor makes an explicit update to the current state of the created instance. In OOA96 we were denied access to the current state attribute. We were granted an exception, however, in the case of create in acces- sors. So my interpretation still works I think. Now both instances have been created in your creation state but have not yet completed the action by the time you attempt to read the val attributes. The action must complete before either instance may receive events. Thus the values assigned in the creation accessors remain intact. I know that in this case a single invocation of a state action is associated with a state transition for two objects but I don't see a problem with that. Now tell us why you need such a state action. :) -greg Subject: Re: (SMU) Reflexive Relationships Gordon Colburn writes to shlaer-mellor-users: -------------------------------------------------------------------- ...Responding to Lahman: > Ah, a good example of why one needs to be careful defining relationship > labels. Yes. Relationship labels are important on any relationship, but they are absolutely critical in asymmetric reflexive relationships. In the following relationship: +----------+ | EMPLOYEE |<<----+ | | | +----------+ "Supervises"Mc ^ | "is supervised | | by" 1c | +------------+ it is very different to say employee A "supervises" employee B than to say employee A "is supervised by" employee B! This illustrates the importance of querying in the right direction, and the importance of a formalization technique which distinguishes between the two directions of the relationship. -Gordon Colburn Subject: Re: (SMU) Reflexive Relationships Phil Ryals writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Colburn: >Yes. Relationship labels are important on any relationship, but they >are absolutely critical in asymmetric reflexive relationships. In the >following relationship: > >+----------+ >| EMPLOYEE |<<----+ >| | | >+----------+ "Supervises"Mc > ^ | > "is supervised | > | by" 1c | > +------------+ > >it is very different to say employee A "supervises" employee B than to >say employee A "is supervised by" employee B! This illustrates the >importance of querying in the right direction, and the importance of a >formalization technique which distinguishes between the two directions >of the relationship. Seems to me there is a problem with your asymmetric reflexive relationship (as shown) and that is that you have violated the fundamental definition of an object in OOA. A relationship is a mapping from instances of one set of things (that were abstracted as an object) to instances of another set of things (that were abstracted as an object). In the case of a reflexive relationship the two sets are the same (object). In your asymmetric relationship the difference in multiplicity on the two ends infers that different rules and policies apply to the set being pointed to, depending on which way you navigate the relationship--but in this case they are the same set. If different rules apply to some instances versus others we have a clear violation of the definition of an object that states "all instances are subject to and conform to the same rules" (Modeling the World in Data, p. 14), and we really have two objects. Based on that, I contend that the multiplicity and conditionality of a reflexive relationship (in OOA91 notation) has to be the same on both ends. That, in part, was the motivation for changing to the single arrow notation of OOA96 (Fig. 4.1, p. 20). Your asymmetric example above should be modeled as shown in Figure 4.3, p. 21, of the OOA96 report. Subject: Re: (SMU) Reflexive Relationships David Stone 5887 writes to shlaer-mellor-users: -------------------------------------------------------------------- If I have understood Phil Ryals correctly, he is arguing that there should never be asymmetric reflexive relationships. I had read the relevant part of the OOA96 report, but had not thought it was saying that, but only that _many_ asymmetric reflexive relationships should be modelled better using subtypes. One example which seems clear to me: suppose I am modelling items on a circular conveyor belt (for example, the carousels used at airports where passengers retrieve their luggage). +------------------+ | PIECE_OF_LUGGAGE |<-----+ | | | +------------------+ "comes before" 1 ^ | "comes after" 1 | | | +--------------------+ The above seems to be the natural model. It is clearly asymmetric, because the direction of motion means that one piece comes first past any given point, just before another. I cannot see how subtyping would be appropriate here. There is no first or last piece. If such a model is now prohibited, then it seems to me that this is a backward step. -- David Stone Sent by courtesy of, but not an official communication from: Simoco Europe, P.O.Box 24, St Andrews Rd, CAMBRIDGE, CB4 1DP, UK Subject: Re: (SMU) Is a creation state a state? lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Wiley... > Now both instances have been created in your creation state > but have not yet completed the action by the time you attempt > to read the val attributes. The action must complete before > either instance may receive events. Thus the values assigned > in the creation accessors remain intact. I am not I sure I can buy this. The create accessors employed in Stone's example are synchronous processes. I interpret that to mean that when they return to the action where they were invoked, the instance has been created (i.e., its "action" has completed -- put another way, the synchronous accessor *is* the "action"). The created instance is in the correct state at the end of the accessor's processing but that does not require that it remain in that state throughout the processing of the action that invoked the accessor. Whether it needs to be is dictated by what the invoking action needs to do -- it defines the temporal bound for data consistency. If it needs consistent data from the created instance through its execution, then the translation will have to enforce some form of lock on the created instance. If it does not need anything more from the created instance, then the translation need not enforce any locks and someone else can concurrently change its state. Note that the create accessor has nothing to do with any create state that may be available. It is possible to have both mechanisms active for an object so that sometimes you create via event (and must wait for the action to complete) or you create via accessor (possibly to a different state than the create state). I see these as entirely separate mechanisms for asynchronous vs. synchronous modeling. Finally, to maintain referential integrity one *must* define all the relevant unconditional relationships for the instance being created before leaving the action where create accessors are invoked. (And the translation must lock the created instance while the invoking action executes.) To do so you necessarily must have modify access to the referential attributes of the instance being created. > Now tell us why you need such a state action. :) True, the example was contrived to illustrate the point. Clearly the whole problem could have been avoided by using transient data for the initialization values so that they did not have to be accessed later in the action from the created instances. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Reflexive Relationships lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Ryals responding to Colburn... > Seems to me there is a problem with your asymmetric reflexive relationship > (as shown) and that is that you have violated the fundamental definition of > an object in OOA. A relationship is a mapping from instances of one set of > things (that were abstracted as an object) to instances of another set of > things (that were abstracted as an object). In the case of a reflexive > relationship the two sets are the same (object). > > In your asymmetric relationship the difference in multiplicity on the two > ends infers that different rules and policies apply to the set being > pointed to, depending on which way you navigate the relationship--but in > this case they are the same set. If different rules apply to some > instances versus others we have a clear violation of the definition of an > object that states "all instances are subject to and conform to the same > rules" (Modeling the World in Data, p. 14), and we really have two objects. > > Based on that, I contend that the multiplicity and conditionality of a > reflexive relationship (in OOA91 notation) has to be the same on both ends. > That, in part, was the motivation for changing to the single arrow notation > of OOA96 (Fig. 4.1, p. 20). Your asymmetric example above should be > modeled as shown in Figure 4.3, p. 21, of the OOA96 report. I agree Stone. I also agree with you that OOA96 seems to dictate the use of subtypes for asymmetric relations always; the first sentence of the section on p. 20 is pretty clear on that. However, if the justification for this is the logic above, then I believe it is flawed and Stone's counterexample demonstrates that. I believe that the rules and policies that are different for the asymmetric relationship with differing cardinality and conditionality apply to the relationship rather than the set of instances. I contend that the rules and policies that apply to the set of instances are things like requiring unique identifiers. I believe cardinality and conditionality are rules and policies that apply to the relationship itself. In my mind the real argument for using subtypes is that the asymmetric relationship necessarily subdivides the set into subsets that have differing characteristics. In the given example there will always be fewer supervisors than supervisees and there will always be one instance that is never a supervisee. Thus the instances in the various subsets are somehow different and should be modeled that way. The counter management example, analogous to Stone's, is Matrix Management -- which has been described as a slave galley where everyone has a whip in one hand while their other hand is chained to an oar. Now the subsets are identical with each other and the original set, yet the relationship is still asymmetric. In this case the set has not really been subdivided and the asymmetric reflexive relationship still seems appropriate. I do happen to like the idea of using subtypes in prefernce to asymmetric reflexive relationships. However, it has some practical disadvantages. It tends to clutter the IM with objects whose differnces are not dictated by the problem at hand. Worse, it can lead to objects that have no differing data and/or behavior (e.g., the relationship exists for an associative object attached to it). The example in OOA96 Figure 4.3 illustrates this. I can come up with several cases where data is the same for all three objects, there is a single state machine in EMPLOYEE, and yet I need to navigate the relationship. This seems contrary to the point of the underlying data model and the extra objects are superfluous to the problem at hand. One idea that has crystallized for me during this thread is the notion of a notational idiom for reflexive relationships. As Colburn points out, if one is careful about the labeling and precise on the cardinality and conditionality, then there really should not be any misinterpretion in many cases. When I look at supervises:Mc::is supervised by:1c for a single EMPLOYEE object I don't have a problem figuring out what is being modeled because I understand the implicit idiom that says that there is a first-to-last issue where a few instances may not be supervised, most instances may not supervise, and there may be some instances who do both. There is a further implicit implication of the idiom that says that the instances in the set do not differ in any significant way relative the to problem I am solving. Therefore I would propose that the asymmetric reflexive conditional relationship be preserved as a notational idiom that presumes (a) the first-to-last model and (b) otherwise indistinguishable instances. (The unconditional version would accurately describe Stone's baggage carousel situation and would not be an idiom.) As soon as conditionality exists for other reasons than accommodating the first-to-last model or the instances have concrete differences in data or behavior due to the relationship, then one would go to the sub/supertype model. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) Re: Reflexive Relationships Todd Sundsted writes to shlaer-mellor-users: -------------------------------------------------------------------- > Phil Ryals writes to shlaer-mellor-users: > -------------------------------------------------------------------- > Responding to Colburn: > > ... > > > > +----------+ > > | EMPLOYEE |<<----+ > > | | | > > +----------+ "Supervises"Mc > > ^ | > > "is supervised | > > | by" 1c | > > +------------+ > > > > ... > ... > If different rules apply to some instances versus others we have a > clear violation of the definition of an object that states "all > instances are subject to and conform to the same rules" (Modeling > the World in Data, p. 14), and we really have two objects. Perhaps Gordon's example was too concrete. It's too easy to think of EMPLOYEE's being of two types -- workers and supervisors -- with associated differences in information and behavior (and rules). How about this somewhat more abstract model of a tree: > > > > +----------+ > > | NODE |<<----+ > > | | | > > +----------+ "is a parent of" Mc > > ^ | > > | | > > "is a child of" | > > | 1c | > > +------------+ > > In this example a NODE is a node - just like every other node. The _only_ piece of interesting information is its position in the tree relative to other nodes -- its parent and its children. Now you could implement it this way, or with an "isa" relationship. I contend that the above diagram captures the relationship, requires fewer objects, and is easier to understand than the alternate construct. In fact, the "isa" construct would seem to imply that there _is_ some significant difference. You could, of course, also use the OOA 96 reflexive relationship, but then you lose the "parent of"/"child of" information. The order of the relationship, in this case, is significant. Why lose that information? Todd -- tesundst@emss.com Subject: Re: (SMU) Reflexive Relationships Gordon Colburn writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Ryals: > In your asymmetric relationship the difference in multiplicity on the two > ends infers that different rules and policies apply to the set being > pointed to, depending on which way you navigate the relationship--but in > this case they are the same set. If different rules apply to some > instances versus others we have a clear violation of the definition of an > object that states "all instances are subject to and conform to the same > rules" (Modeling the World in Data, p. 14), and we really have two objects. Phil, its good to hear from someone from PT on this topic! But, I disagree with the point that my asymmetric relationship with differences in multiplicity infers that different rules apply to various instances of the set. Actually, all instances of EMPLOYEE are subject to the same rules, specifically: 1. Each employee is supervised by at most one employee and 2. Each employee may supervise any number of (including zero) employees. By not using the isa relationship to differentiate between supervisors, staff, etc., I am capturing the fact that in my (hypothetical) application, there is no interesting behavior or data differences between the various types of employees. It seems to me (as was said by Lahman) that when deciding whether to use an isa to model an asymmetric reflexive relationship, one should consider whether there are differences in behavior or data among the various proposed subtypes, and whether these differences are relevant to the application. If the answer to both questions is "yes", then use an isa hierarchy. If the answer to either is "no", then it might be clearer and simpler to use an asymmetric relationship between the object and itself. -Gordon Colburn Subject: Re: (SMU) Is a creation state a state? "Greg Wiley" writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Lahman: > lahman writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Responding to Wiley... > > > Now both instances have been created in your creation state > > but have not yet completed the action by the time you attempt > > to read the val attributes. The action must complete before > > either instance may receive events. Thus the values assigned > > in the creation accessors remain intact. > > I am not I sure I can buy this. The create accessors employed in > Stone's example are synchronous processes. I interpret that to mean > that when they return to the action where they were invoked, the > instance has been created (i.e., its "action" has completed -- put > another way, the synchronous accessor *is* the "action"). I disagree. The accessor is just an accessor. > The created instance is in the correct state at the end of the > accessor's processing but that does not require that it remain in that > state throughout the processing of the action that invoked the > accessor. Unless the instance is created in the state associated with the action invoking the accessor. If the example had simply created one instance, would you allow that instance to accept events before the action was complete? > Whether it needs to be is dictated by what the invoking > action needs to do -- it defines the temporal bound for data > consistency. If it needs consistent data from the created instance > through its execution, then the translation will have to enforce some > form of lock on the created instance. If it does not need anything more > from the created instance, then the translation need not enforce any > locks and someone else can concurrently change its state. OOA says nothing about locks. It explicitly puts responsibility for data consistency on the shoulders of the analyst. > Note that the create accessor has nothing to do with any create state > that may be available. It is possible to have both mechanisms active > for an object so that sometimes you create via event (and must wait for > the action to complete) or you create via accessor (possibly to a > different state than the create state). I see these as entirely > separate mechanisms for asynchronous vs. synchronous modeling. You always need a create accessor to create a new instance. A create accessor may be invoked in any state action of any object--including that of a creation state of the created instance's object. If it is invoked in a creation state action of the object whose instance it is creating, then the creation state action must complete before the instance may receive events. My argument is that it doesn't matter how many instances are created in this manner--the instances may not receive events until the creation state's action completes. -greg Subject: Re: (SMU) Is a creation state a state? lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Rewsponding to Wiley... Regarding a create accessor being synchronous: > I disagree. The accessor is just an accessor. I think we are miscommunicating here. This was exactly my point. It is synchronous *because* it is just an accessor. > > The created instance is in the correct state at the end of the > > accessor's processing but that does not require that it remain in that > > state throughout the processing of the action that invoked the > > accessor. > > Unless the instance is created in the state associated with the > action invoking the accessor. If the example had simply created > one instance, would you allow that instance to accept events > before the action was complete? The short answer is a definitive Maybe. If the invoking action did not subsequently need consistent data from the instance, as in the original example, the answer is yes. If it did, then the answer is no. The issue of whether the created instance can accept events concurrently exists for *any* instance. That is, this is an issue of data consistency that does not depend upon the instance being created in the action; it could have existed prior to the start of the action accessing its data or if the action were not a create state action. Note that the number of instances created is irrelevant. Each must be considered individually to determine the data consistency issues and any requirements that they may place on the translation. > OOA says nothing about locks. It explicitly puts responsibility for > data consistency on the shoulders of the analyst. This was the issue of concern for the thread a few weeks ago. Locking is, indeed, a translation issue. What OOA provides is some boundaries where the translation may have to provide locks (or some other mechanism) to guarantee data consistency. One of those boundaries is the state action. I contend that the OOA *does* require that the translation provide data consistency for all external data referenced within an action. The analyst *must* be able to count upon this or it would be impossible to write the action. (Similarly, the analyst must be able to count on referential integrity throughout an action.) > You always need a create accessor to create a new instance. A create > accessor may be invoked in any state action of any object--including > that of a creation state of the created instance's object. If it is > invoked in a creation state action of the object whose instance it is > creating, then the creation state action must complete before the > instance may receive events. My argument is that it doesn't matter > how many instances are created in this manner--the instances may not > receive events until the creation state's action completes. I think the problem here is that there is nothing magical about the fact that the fact that the instance is created out of the create action. If the create accessor were invoked directly from some other object's instance the create action would not be executing at all. When an instance is synchronbously created out of the create state (or any other state action from any other object) it comes into being in whatever state was specified in the create accessor. That state might not be the create state and the event that would normally transition into that state would not be the create event, so there is no reason to associate the create action with the instance. OOA96 (pg 40, 1st FAQ) specifically states that the action of that state is not executed. This would still apply if the state actually was the create state. The key issue here is that particular instance is not executing *any* action because it has not yet seen a transition. The original create event was effectively directed at the object, it was consumed before the instance existed, and its action is not associated with any particular instance. The create state's action is no different than an arbitrary action in another object that happened to invoke a synchronous create accessor to create the instance (i.e., the instance's create action is not executing) -- the created instance can accept events as soon as the create accessor completes. The exception occurs in the original example when the already-running action tah tinvoked the create accessor happens to require data consistency in the instance(s) that it just created. If that is the case, the translation must enforce this, possibly by preventing the newly created instance from accepting events. The same situation would exist regardless of whether the action was a create state action or not. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Reflexive Relationships Steve Mellor writes to shlaer-mellor-users: -------------------------------------------------------------------- At 12:13 PM 9/25/97 -0500, you wrote: >Gordon Colburn writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >Responding to Ryals: > >> In your asymmetric relationship the difference in multiplicity on the two >> ends infers that different rules and policies apply to the set being >> pointed to, depending on which way you navigate the relationship--but in >> this case they are the same set. If different rules apply to some >> instances versus others we have a clear violation of the definition of an >> object that states "all instances are subject to and conform to the same >> rules" (Modeling the World in Data, p. 14), and we really have two objects. > >Phil, its good to hear from someone from PT on this topic! > >But, I disagree with the point that my asymmetric relationship with >differences in multiplicity infers that different rules apply to >various instances of the set. Actually, all instances of EMPLOYEE are >subject to the same rules, specifically: > >1. Each employee is supervised by at most one employee and > >2. Each employee may supervise any number of (including zero) >employees. > >By not using the isa relationship to differentiate between >supervisors, staff, etc., I am capturing the fact that in my >(hypothetical) application, there is no interesting behavior or data >differences between the various types of employees. > >It seems to me (as was said by Lahman) that when deciding whether to >use an isa to model an asymmetric reflexive relationship, one should >consider whether there are differences in behavior or data among the >various proposed subtypes, and whether these differences are relevant >to the application. If the answer to both questions is "yes", then use >an isa hierarchy. If the answer to either is "no", then it might be >clearer and simpler to use an asymmetric relationship between the >object and itself. I have been following this thread with some interest for the last week because this is a subject that has been the cause of some heartburn for us. Said heartburn motivated me to look back over less recent E-SMUG traffic. In response to Yves van de Vijver in Dec. 1996, David Whipp wrote: >I have actually come to view any reflexive relationship >with distrust. They seem to cause more trouble than is >justified by the abstractions they represent. They can >always be eliminated through the introduction of a >"node" object, which generally produces a more stable >model and frequently does not increase the number of >objects. We recently purged the last remaining reflexive >relationship from our models because of the potential >maintenance problems. My own view falls somewhere between Messrs Colburn and Whipp: it's better if we don't use them, but if the trouble involved in modelling the problem outweighs the benefit to be gained, then just go ahead. Reflexive relationships are 'difficult' because they're a puzzle. Whenever we see one we wonder if we got it right, if there's a better way, or maybe if we shouldn't use this construct at all. So my view is the pragmatic one. The group has already provided the technical answers: abstract objects for common behavior and data, consider the relevance of any differences in same, build sub/supertype hierachies when there are differences in data, behavior _or relationships_. Schedule pressures in a project require us to make a decision. Just so long as the resulting model follows the rules of the formalism... -- steve mellor Subject: Re: (SMU) Reflexive Relationships Phil Ryals writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Stone: >If I have understood Phil Ryals correctly, he is arguing that there >should never be asymmetric reflexive relationships. I didn't mean to give the impression that reflexive relationships couldn't be asymmetric. I was just questioning the validity of having different multiplicities and conditionalities on the two ends of the relationship. [snip] >+------------------+ >| PIECE_OF_LUGGAGE |<-----+ >| | | >+------------------+ "comes before" 1 > ^ | > "comes after" 1 | > | | > +--------------------+ > >The above seems to be the natural model. It is clearly asymmetric, >because the direction of motion means that one piece comes first past >any given point, just before another. I think this is a perfectly fine model. Phil Subject: Re: (SMU) Is a creation state a state? "Greg Wiley" writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Lahman > > Rewsponding to Wiley... > > Regarding a create accessor being synchronous: > > > I disagree. The accessor is just an accessor. > > I think we are miscommunicating here. This was exactly my point. It is > synchronous *because* it is just an accessor. > > > > The created instance is in the correct state at the end of the > > > accessor's processing but that does not require that it remain in that > > > state throughout the processing of the action that invoked the > > > accessor. > > > > Unless the instance is created in the state associated with the > > action invoking the accessor. If the example had simply created > > one instance, would you allow that instance to accept events > > before the action was complete? > > The short answer is a definitive Maybe. If the invoking action did not > subsequently need consistent data from the instance, as in the original > example, the answer is yes. If it did, then the answer is no. The > issue of whether the created instance can accept events concurrently > exists for *any* instance. That is, this is an issue of data > consistency that does not depend upon the instance being created in the > action; it could have existed prior to the start of the action accessing > its data or if the action were not a create state action. I'm going to stick to my guns here. We agree that the number of instances created is unimportant. In the example, the state that invoked the accessors is a creation state by definition. Further, also by definition, the instances are self-created. By the rules for state actions, at most one action of a given state machine can be in execution at any point in time. I claim that a self-created instance comes into being at a point in time when a state action in its own machine is executing. The notation sup- ports this by depicting a transition from no state to a creation state. > I think the problem here is that there is nothing magical about the fact > that the instance is created out of the create action. Yes there is. The terminology distinguishes between self-created and non-self-created instances. Modeling as if a self-created instance can receive events before the corresponding creation state action completes unnecessarily complicates the models. I am only talking about self-created instances here. Non-self- created instances are created "ready-to-go." I think the distinction tends to limit non-self-creation to passive objects and well- considered scenarios in practice--a good thing. :) The most important thing here is to agree on the semantics of creation state actions. I think the future of OOA/RD depends on the interoperability and re-usability of our models. -greg 'archive.9710' -- Subject: Re: (SMU) Is a creation state a state? lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Wiley... > I'm going to stick to my guns here. Didn't John Paul Jones say something like that? B-) > We agree that the number of instances created is unimportant. In the > example, the state that invoked the accessors is a creation state > by definition. Further, also by definition, the instances are > self-created. This seems to be the core of our disagreement. In the example it *happened* to be the creation state. However, it could have been a non-create action in another object's state machine. In that situation that action would clearly *not* be a creation state and the created instance's create state, if any, would not be excuted at all. > By the rules for state actions, at most one action of a given state > machine can be in execution at any point in time. I claim that > a self-created instance comes into being at a point in time when a > state action in its own machine is executing. The notation sup- > ports this by depicting a transition from no state to a creation > state. True -- at the instance level. But if I have two instances each can be executing the state machine at the same time. The *instance* cannot accept another event while it is still executing an action but other instances that are not executing an action may accept events. I contend that the in the original example the create state being executed was not associated with either of the instances that happened to be created by that state. It couldn't be because it started before they existed. Therefore they were free to accept events even while that create state was executing. This is what I meant about there being nothing magic about the create state. If the instances were created from a non-create action in another object, then one would not associate that instance with that action (i.e., say that it could not accept events until that action finished) because it was clearly not an action that the created instance was executing -- it would not even be an action in that instance's state machine! It seems to me that it would be inconsistent to say that the created instance was somehow executing the invoking action if teh invoking action *happened* to be the create state for that object. The only restriction that *might* be valid would be to say that no more that one create event could be consumed by an *object* at a time. However, I don't really see the need for this restriction, given that the translation is going to have to provide data consistency and relational integrity during the execution of the action anyway; let the translation solve any problems. Moreover, there is no such restriction on the synchronous create accessors where any arbtrary number could be invoked concurrently from various actions in various instances. So why restrict create events? > > I think the problem here is that there is nothing magical about the fact > > that the instance is created out of the create action. > > Yes there is. The terminology distinguishes between self-created > and non-self-created instances. Modeling as if a self-created > instance can receive events before the corresponding creation state > action completes unnecessarily complicates the models. I am not sure I understand that distinction. The only place where I am aware of this showing up is in OOA96 (pg 40) and in that case the distinction only seemed to apply to whether one could specify the state of the created instance when the create accessor compeleted. Could you point at a context where you saw that distinction relevant to this discussion? I do not see that the complexity is any different for an instance created from a create state than for one created from a non-create state. In either case data consistency and referential integrity are still issues for the translation during the execution of the creating action, as this thread has discussed. But they should not be issues for the analyst -- the analyst should be able to count on the translation resolving these issues within the bounds of the state action, regardless of whether it is a create action or non-create action. I would agree that it presents some headaches for the Architect, but the issues have to be resolved anyway for non-create state and it would probably be easier to view all actions consistently than to do exception processing for create states if one associates the create state with the created instances. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Is a creation state a state? Steve Mellor writes to shlaer-mellor-users: -------------------------------------------------------------------- At 08:42 AM 10/1/97 -0400, you wrote: >lahman writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >Responding to Wiley... > >> I'm going to stick to my guns here. > >Didn't John Paul Jones say something like that? B-) > >> We agree that the number of instances created is unimportant. In the >> example, the state that invoked the accessors is a creation state >> by definition. Further, also by definition, the instances are >> self-created. > >This seems to be the core of our disagreement. In the example it >*happened* to be the creation state. However, it could have been a >non-create action in another object's state machine. In that situation >that action would clearly *not* be a creation state and the created >instance's create state, if any, would not be excuted at all. It seems to me we have two objects here: a creat_ing_ state which creates an instance of some object, and a creat_ion_ state, the state in which an instance is created. Often, a creation and creating state are the same, such as when I self-create. I believe that this distinction will make the discussion clearer, though I'm that keen on the object names.... -- steve mellor Subject: Re: (SMU) Is a creation state a state? lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Mellor... > It seems to me we have two objects here: a creat_ing_ state > which creates an instance of some object, and a creat_ion_ > state, the state in which an instance is created. Often, > a creation and creating state are the same, such as when > I self-create. > > I believe that this distinction will make the discussion clearer, > though I'm that keen on the object names.... OK. But I think the ambiguity of the action associated with the creation state is the real source of a lot of our hand-waving. When the creating state is the same as the creation state, as it was in the original example, who "owns" the associated action? It seems to me that this action is in a kind of limbo -- unlike all other state actions, its execution isn't associated with *any* instance. It clearly isn't owned by the instance that sent the create event because it doesn't live in that instance's FSM, yet it doesn't seem to be owned by the instances that it creates (i.e., how can it be claimed by an instance that does not yet exist when the action starts execution?). If the creation state action is, in fact, associated with all of the instances that it creates, then I would have to agree with Wiley that those instances cannot accept events until that action terminates. But it doesn't seem to be and I have always resolved this ambiguity by opining that the creation state is "special" and its execution is associated with the object rather than specific instances. Alas, I don't recall (my recollection being a mechanism of legendary unreliability) anything in the exposition of the methodology that substantiates this concept. Care to roll out a Pearl of Wisdom or three on where a creation state action lives? -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Is a creation state a state? Dana Simonson writes to shlaer-mellor-users: -------------------------------------------------------------------- FWIW, In the PT RD course and in our C++ architecture, the create state is translated as a class method. Subject: Re: (SMU) Is a creation state a state? "Greg Wiley" writes to shlaer-mellor-users: -------------------------------------------------------------------- Thanks for your input, Steve. To clarify the question as I see it: A creation state of an object is a state that does (or can) create instances of that object and has the property that events causing the state's action to execute contain only supplemental data. An instance of an object created by the action of a creation state of that object is a self-created instance. Each *instance* of an active object is associated with a state machine described by the object's state transition diagram. Each state machine may be executing at most 1 state action at any point in time. Now the question is: Is the action execution of a creation state an action execution of the state machines of any self-created instances created by that invocation? If so, then a self-created instance may not receive any events until the corresponding creation state action completes. If not, a self-created instance may move along in its lifecycle before the creation state action completes. I think it is clear, at least, that the answer is neither in Object Lifecycles nor OOA96. Both Lahman and I have reasonable interpretations but our models will not generally interoperate. So what do we do now? :) -greg Subject: (SMU) Write Access to Identifying Attributes "Wilson,Douglas" writes to shlaer-mellor-users: -------------------------------------------------------------------- This posting concerns the legitimacy of allowing write accessors on identifying attributes after instance creation. My apologies if this has been discussed in previous threads, but I was out of the SMUG loop for a while... Is it appropriate to allow identifying attributes to change during system execution? For the most part, our team has taken the simplifying approach that identifying attributes are inherent to the instance of an object. If an identifying attribute changes, then we questioned whether the attribute was identifying, or merely a non-identifying "naming" attribute. This assumption has served us relatively well, and in the cases where we derived arbitrary identifiers, we felt we could adequately justify their use. We have come across an example where the use of this approach would compromise the analysis. A user can execute many different protocols in our system. These protocols are identified by a numeric label and a status. Typically, protocols arrive as (protocol 12, status = primary). Later the user desires to execute a new protocol of the same type (protocol = 12, status = secondary) and compare its performance to the primary protocol. Eventually the user decides the new protocol is acceptable and wants it to become the primary protocol. They will remove the primary protocol and promote the secondary protocol to primary status. (the goal is to keep all historical data and migrate it along with the secondary protocol) If, as we have in the past, we replace these compound identifiers with an arbitrary identifier, the problem goes away. The status is a descriptive (or non-identifying naming) attribute and can be changed freely and the identifier never changes. In doing so, we have lost the ability to represent the combination of protocol number and status as unique identifiers of each instance, and this we see as not representative of our problem. In rereading the "Modeling the World In Data" book, section 4.3.2 describes naming attributes as "...facts about the arbitrary labels and names carried by each instance of an object." It also goes on to state that "...you can change the names or labels of each instance of the object without changing anything else. That is, I can re-number an airplane, but it is still the same airplane." It also states that naming attributes can be used as identifiers (p. 34). This description makes sense to me. If I rename my dog, isn't it still housebroken? If I am analyzing a LAN account system, I can uniquely identify accounts with a logon ID. These are unique across all accounts and can naturally serve as identifiers in my system. If a user changes their logon to another ID, does it mean that they are not the same account? They still retain their status (state) and privileges (related objects) and other descriptive information. It seems logical (and representative of the real-world) that I can simply alter its identifier, verify uniqueness of the identifier, ensure that any formalizations to that are in synch with the update, and call it done. Does anyone have any opinions or issues in analysis and architecture that we should watch out for or should make us reconsider allowing this approach? ============================================================ Doug Wilson The opinions expressed here are Abbott Laboratories my own, and not in any way representative of (847) 938-6509 coherent thought, or of Abbott Laboratories. ============================================================ Subject: Re: (SMU) Write Access to Identifying Attributes Neal Welland writes to shlaer-mellor-users: -------------------------------------------------------------------- Wilson,Douglas wrote: > > "Wilson,Douglas" writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > This posting concerns the legitimacy of allowing write accessors on > identifying attributes after instance creation. My apologies > if this has been discussed in previous threads, but I was out of the SMUG > loop for a while... > Snipp... > > We have come across an example where the use of this approach would > compromise the analysis. A user can execute > many different protocols in our system. These protocols are identified by a > numeric label and a status. Typically, > protocols arrive as (protocol 12, status = primary). Later the user desires > to execute a new protocol of the same type > (protocol = 12, status = secondary) and compare its performance to the > primary protocol. Eventually the user decides the > new protocol is acceptable and wants it to become the primary protocol. They > will remove the primary protocol and > promote the secondary protocol to primary status. (the goal is to keep all > historical data and migrate it along with > the secondary protocol) > > If, as we have in the past, we replace these compound identifiers with an > arbitrary identifier, the problem goes away. The > status is a descriptive (or non-identifying naming) attribute and can be > changed freely and the identifier never changes. > In doing so, we have lost the ability to represent the combination of > protocol number and status as unique identifiers > of each instance, and this we see as not representative of our problem. > Every instance of an object is unique. The identifier of an object must guarantee to select exactly one instance. The attributes that you have selected as an identifier, do not guarantee this essential uniqueness. They are therefore not suitable as an indentifier. You must be careful in selecting "naming" attributes as identifiers for this very reason. > In rereading the "Modeling the World In Data" book, section 4.3.2 describes > naming attributes as "...facts about the > arbitrary labels and names carried by each instance of an object." It also > goes on to state that "...you can change > the names or labels of each instance of the object without changing anything > else. That is, I can re-number an > airplane, but it is still the same airplane." It also states that naming > attributes can be used as identifiers (p. 34). > I think the is a rather misleading example. You certainly can change the value of a naming attribute, without changing anything else, BUT this only applies if the naming attribute is NOT utilised as an identifier. The example that you mention is perfectly correct, but the same object is used in section 4.4 to describe identifying attributes. In this example, the aircraft_ID is now an identifying attribute for the object. This was not the case for the example in section 4.3.2. Changing the value of the attribute is the new example is not allowed, since it breaks the formalism. You could inadvertently create an AIRCRAFT with the same identifier value as an existing instance. This is impossible based on the table rules. The *ONLY* place identifier values may legitimately be modified, is within the create and delete accessors. Snipp.... Subject: Re: (SMU) Write Access to Identifying Attributes lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Douglas... > Does anyone have any opinions or issues in analysis and architecture that we > should watch out for or should make us > reconsider allowing this approach? I think this depends upon how rigorously S-M wants to pursue the relational data model. If one is a purest then I think the only way to change the identifier is via delete/re-create. I think there are two levels at which relational integrity must be preserved. One is the higher level of explicit relationships in the OOA. This one can be managed through a combination of analysis guidelines and translation rules (e.g., redefine all the relationships in the same action that the identifier is changed). The second is the lower level of the underlying database (data store) engine. The architecture must be able to efficiently handle things like Finds. To do this it will implement mechanisms like sorted lists of identifiers. This is the level where changing an identifier can get you into trouble. If the architecture assumes a rigorous data model, then it would assume that the identifier is invariant and the sorted lists would only be updated during deletes and creates. Changing the identifier would allow the archtitecture internals to get out of synch because the architeture's lists internal lists would no longer be correct since they would not reflect the identifier change. One could argue that the rigorous data model was developed with relational database engines in mind, particularly in this respect, which may not be relevant in the S-M situation. In S-M the architecture is regarded as part of the development and one is free to support whatever translation rules and architectural mechanisms one wants. This would allow, for example, updating of any internal sorted lists whenever the value of an identifier is changed (i.e., by coloring the write accessor for the identifier attribute in the translation). Thus S-M *might* be able to relax the constraint of invariant identifiers to allow more intuitive modeling of the examples that you cited. OTOH, I think commercial plug&play OTS architectures are a highly desirable thing in the long term. If this is to become a reality, then they all have to share some common rules. The most logical set of rules is that of the rigorous relational data model since this is an existing, time-tested standard. Alas, I am not sure what the methodology's view is on this issue -- though I would probably bet that it comes down in favor of the more rigorous view. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Write Access to Identifying Attributes lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Welland... I basically agree with you about the invariance of identifiers, but I have a couple of quibbles about the details Regarding the protocol example: > Every instance of an object is unique. The identifier of an object must > guarantee to select exactly one instance. The attributes that you have > selected as an identifier, do not guarantee this essential uniqueness. > They are therefore not suitable as an indentifier. You must be careful > in selecting "naming" attributes as identifiers for this very reason. As I read the example there can be at most two instances with the same protocol number and these are distinguished by whether their status is primary or secondary and there can only be one instance of each status for a protocol. Thus the compound identifier of Protocol and Status is always unique. As I read it the situation is that if one has both a primary and a secondary protocol, one could delete the current primary version and migrate the existing secondary to become primary. Subsequently one could then add a new secondary protocol. As I understand Douglass' issue, it is around the middle step of migrating the secondary instance to become primary. During all three steps, though, the identifiers of existing instances are unique (i.e., when the instance is migrated from secondary to primary, only one instance with that protocol numebr exists). Regarding the OOSA:MWD examples: Actually, I don't see anything persuasive in *any* of the examples that says that an instance identifier *must* be invariant throughout its life. As I read those examples, all they say is that the identifiers must have unique values within th context of any execution of the model. But that begs the point of whether one can change a particular identifier from one unique value to another unique value. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Is a creation state a state? "Greg Wiley" writes to shlaer-mellor-users: -------------------------------------------------------------------- For some reason, this didn't show up on the list so here it is again. Apologies if it shows up twice. --------------------------------------------------------- Thanks for your input, Steve. To clarify the question as I see it: A creation state of an object is a state that does (or can) create instances of that object and has the property that events causing the state's action to execute contain only supplemental data. An instance of an object created by the action of a creation state of that object is a self-created instance. Each *instance* of an active object is associated with a state machine described by the object's state transition diagram. Each state machine may be executing at most 1 state action at any point in time. Now the question is: Is the action execution of a creation state an action execution of the state machines of any self-created instances created by that invocation? If so, then a self-created instance may not receive any events until the corresponding creation state action completes. If not, a self-created instance may move along in its lifecycle before the creation state action completes. I think it is clear, at least, that the answer is neither in Object Lifecycles nor OOA96. Both Lahman and I have reasonable interpretations but our models will not generally interoperate. So what do we do now? :) -greg Subject: Re: (SMU) Is a creation state a state? Sally Shlaer writes to shlaer-mellor-users: -------------------------------------------------------------------- At 10:50 AM 10/3/97 -0700, you wrote: >"Greg Wiley" writes to shlaer-mellor-users: >-------------------------------------------------------------------- Dear all, I'll use Greg's last article as a base for telling you how I think about some of issues that came up in this thread. First let me restrict this answer to architectures where the unit of interleaving is the action. That is, only one action of _any_ instance can be in execution at any time. I'm not going to tackle the simultaneous interpretation of time yet -- as Peter Fontana points out, there are many issues (probably not even all identified) involved there. And, as H.S. observes, the analyst must think in terms of of action interleaving, because a more general interpretation is just too difficult. _________________________ >A creation state of an object is a state that does (or can) >create instances of that object and has the property that >events causing the state's action to execute contain only >supplemental data. An instance of an object created by >the action of a creation state of that object is a >self-created instance. Agreed. We are talking about self-created instances here (just a reminder). We (steve, neil, myself) did not say anything about creating _multiple_ instances in the same execution of the action of a creation state because it simply didn't occur to us. It seems to me that self-creation of multiple instances in the creation state is a reasonable extension of OOA as we know it. (My criteria for "reasonable" are (1) there is a need for it and (2) it does not lead to inconsistencies in the method as so far defined.) So what inconsistencies could arise? 1. In a textual action language, how would "self" or "this" be defined? My recommendation is that they be UNDEFINED in the interests of interoperability -- and clarity, maintenance, etc. 2. I'd always assumed (but did we ever state it?) that the create accessor used for self-creation in a creation state would be C1 or C2 (referring to p50 of the OOA96 report). That is, any instances self-created in a creation state would be in the creation state when control is returned from the creation accessor. Since the only way you can change the state of an instance is to allow it to receive an event, it follows that a newly self-created instance will be in the creation state when the action is complete. 3. We could investigate the idea of allowing a C3 or C4 accessor for self-creation in a creation state, but that has not yet been done. Do we need this? I would think that a better approach would be to make additional creation states that use C1 or C2. Comments anyone? >Each *instance* of an active object is associated with a >state machine described by the object's state transition >diagram. Each state machine may be executing at most >1 state action at any point in time. >Now the question is: Is the action execution of a creation >state an action execution of the state machines of any >self-created instances created by that invocation? I would say yes: the action is executing on behalf of all multiple self-created instances. While this may be a slight extension of the assumption of interleaving at the action level, I do not see that it leads to an inconsistency anywhere in the method. Do you see anything that would cause problems? >If so, then a self-created instance may not receive any >events until the corresponding creation state action >completes. Agreed. >If not, a self-created instance may move along >in its lifecycle before the creation state action completes. Disagreed. This is the kind of thing HS refers to when he observes that the analyst must think in terms of action interleaving. To use his words, which are slightly more general, HS>What OOA provides is some boundaries where the translation HS>may have to provide locks (or some other mechanism) to guarantee HS>data consistency. One of those boundaries is the state action. HS>I contend that OOA *does* require that the translation provide HS>data consistency for all external data referenced HS>within an action. The analyst *must* be able to count upon this or it HS>would be impossible to write the action. (Similarly, the analyst must HS>be able to count on referential integrity throughout the action.) >I think it is clear, at least, that the answer is neither in >Object Lifecycles nor OOA96. Both Lahman and I have reasonable >interpretations but our models will not generally interoperate. Um, HS, would you be so kind as to summarize your interpretation as Greg did? I'm not confident I can pull it out of this thread -- partially because of all the embedded quotes and a moving context. Best to all, Sally P.S. Sorry for taking so long to get into this discussion. One reason I tend to delay is that so many questions get answered even before I pick up my e-mail (which is only about once a day). Also, I learn a lot from watching the discussion evolve: sometimes technical or practical implications about the method, sometimes issues that we haven't addressed or have explained rather poorly. This is a big help to me! Subject: Re: (SMU) Is a creation state a state? David Stone 5887 writes to shlaer-mellor-users: -------------------------------------------------------------------- As the originator of this thread, perhaps I might explain why I originally raised the question. We have implemented an architecture which _does_ implement the simultaneous interpretation of time. We allow analysts to use tagging (colouring) to say that the interleaved interpretation applies within particular groups of objects, but in general instances execute concurrently. Then I read the OOA 96 Report, in particular section 8.3 question 6 on page 42, which says: "Can a creation state create multiple instances of itself? - Yes. Note that all such instances would be self-created." Currently we do not permit a creation state to create multiple instances of itself - we trap this as a run-time error. I was trying to think what exactly the item in the report meant, with a view to extending our architecture in the future, and hence my question. It seems fairly clear to me, especially after Sally Shlaer's contribution, that the answer is not currently defined. Different people have made different suggestions, each with good reasons, but there is no one answer at present. If the method were defined in a formal standard (ISO/ANSI/IEEE...) I would now want to raise a formal Defect Report for consideration by the appropriate technical committee. Is there any such procedure? -- David Stone Sent by courtesy of, but not an official communication from: Simoco Europe, P.O.Box 24, St Andrews Rd, CAMBRIDGE, CB4 1DP, UK Subject: Re: (SMU) Is a creation state a state? lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Shlaer... > First let me restrict this answer to architectures where > the unit of interleaving is the action. That is, only > one action of _any_ instance can be in execution at any > time. Unfortunately I think this can be interpreted two ways. As a clarification, do you mean "only one action of _any_ instance " or "only one action of _any_ instance"? My understanding of action interleaving was the latter case so that one could have simultaneous execution of actions from different instances of the same object. > 3. We could investigate the idea > of allowing a C3 or C4 accessor for self-creation in a > creation state, but that has not yet been done. Do we > need this? I would think that a better approach would be > to make additional creation states that use C1 or C2. > Comments anyone? Since you are coming down on the side of associating the creating create state action with the instances being created (below), then I think it would be more consistent (aesthetically pleasing?) to limit the accessors to C1 and C2. It would bother me to have those instances executing the create state but wind up in another state without a transition. > >Now the question is: Is the action execution of a creation > >state an action execution of the state machines of any > >self-created instances created by that invocation? > > I would say yes: the action is executing on behalf of all > multiple self-created instances. While this may be a slight > extension of the assumption of interleaving at the action > level, I do not see that it leads to an inconsistency anywhere > in the method. Do you see anything that would cause > problems? I like that phrase, "on behalf of". Since it implies only one action is still executing, it gets around the problem of each created instance having a distinct action executing. This eliminates "race" conditions about where one is in each action. [The obscure problem I am thinking about would be to replace the original events issued to the created instances with synchronous accessors. If there were separate actions executing slightly out of process-by-process synch, the data accesses would be ambiguous. Assuming a single, shared action removes this problem.] Though I cannot come up with a practical case where one would get trashed off the top of my head, I am still bothered by the potential inconsistency if synchronous accessors are used. If one were executing a non-create action from an instance then no other action should be able to read/write to that instance's data store. However, this is not the case here because the creating action could write to _any_ of the created instances. Since each created instance "owns" the create action being executed, any of the created instances can effectively write to the other instance's data stores while their action is executing. Now I think you could eliminate my worries about this by placing an additional restriction on the create state: it cannot access the created instance's data store other than through the C1/C2 accessor. I don't think this would be a problem; the original example was admittedly contrived -- it is hard to imagine a case where one would be seriously inconvenienced by such a restriction. > >I think it is clear, at least, that the answer is neither in > >Object Lifecycles nor OOA96. Both Lahman and I have reasonable > >interpretations but our models will not generally interoperate. > > Um, HS, would you be so kind as to summarize your interpretation > as Greg did? I'm not confident I can pull it out of this > thread -- partially because of all the embedded quotes and a > moving context. I was arguing that the creating create state is _not_ associated with the created instances. Therefore they are not executing an action and can accept events even though the creating create state is still executing. My reasoning for this was: * When the instance is created it cannot know how it got to that state by the FSM rules. * The instance could have been created by a create accessor (C3/C4) from another object's instance's action. In that case it would clearly not be executing an action at the time of creation. * If the create action is associated with the instance, then the instance _is_ executing that action at the time of creation. * The behavior of the created instance is different depending upon context and this is a contradiction. Therefore the created instance cannot be executing the create action. Now coming up with a practical reason why this apparent contradiction would be a problem is whole new issue. At heart I don't really have a problem with extending some "specialness" to the creation of instances, other than what I mention above. As an aside, this is similar to the issue in another thread about changing the value of an identifier. In my mind S-M represents a solution to a different or broader problem than that of relational databases despite the fact that the relational data model is central to the methodology. S-M has a write accessor that can be colorized to enforce specific rules during translation. Thus at the OOA level it may not be necessary to enforce the delete-to-change rule as one might have to do in a relational database engine. This seems similar to me in that one could relax the FSM context-dependence rule under special circumstances where the OOA provides constructs (accessors) that can be handled properly in translation. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: (SMU) How to Comply with the UML "Ralph L. Hibbs" writes to shlaer-mellor-users: -------------------------------------------------------------------- Hello ESMUG, If your project has to comply with the UML while continuing to gain the advantages of the Shlaer-Mellor process, you may find it helpful to take a look at: http://www.projtech.com/news/whatsnew.html There you will find a technical paper that demonstrates how to use the UML to represent Shlaer-Mellor work products. There is also a press release dated September 29, 1997 in which Sally and Steve indicate their support for the UML. If you are using the Shlaer-Mellor notation today, and you wish to continue to do so indefinitely, there is no change. I apologize for the slight delay in getting the announcement to ESMUG, but our ISP was having some problems. Now that those problems are gone, your downloads should be problem-free. Sincerely, Ralph Hibbs ----- Shlaer-Mellor Method: Real-Time Software Development ------ Ralph Hibbs Tel: (510) 567-0255 ext. 629 Director of Marketing Fax: (510) 567-0250 Project Technology, Inc. email: rlh@projtech.com 10940 Bigge Street URL: http://www.projtech.com San Leandro, CA 94577 -------------------- Real-Time, On Time ------------------------- Subject: (SMU) ROOM vs- OOA David Yoakley writes to shlaer-mellor-users: -------------------------------------------------------------------- I am looking for additional information/documentation which compares the ROOM method with OOA/OOD. Does PT or anyone else have a white paper on this topic? ________________________________________________________________________ David Yoakley Objective Innovations Inc. Phone: 512.288.5954 14606 Friendswood Lane Fax: 512.288.6381 Austin, TX 78737 Replies: yoakley@oiinc.com ________________________________________________________________________ Subject: (SMU) Request for project metrics Jeff.Bevan@cambridge.simoco.com (Jeff Bevan x6093) writes to shlaer-mellor-users: -------------------------------------------------------------------- I am looking for information/documentation on real-world projects using the Shlaer-Mellor Method. I am interested in both: - Development effort statistics - Shlaer-Mellor OOA model statistics The kind of information includes: - The nature of the project - Development effort for the project, ideally broken down into domains, objects, state models etc. In terms of time and number of analysts/architects. - Statistics on the size of the final model such as the number of domains, objects, state models, attributes number and types per object, number and types of relationships and bridges. - Statistics on the run-time behaviour of the system such as the level of instance population, high and low watermarks for the number of instances at any point of time, as well as any performance data. Basically, whatever information is available. Does PT or anyone else have a paper on this topic? Subject: (SMU) Is a creation state a state? Sally Shlaer writes to shlaer-mellor-users: -------------------------------------------------------------------- > >lahman writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >Responding to Shlaer... > SS>> First let me restrict this answer to architectures where >> the unit of interleaving is the action. That is, only >> one action of _any_ instance can be in execution at any >> time. SS: Argh, it is SO difficult to state these things precisely. I thought I had, but . . . HS>Unfortunately I think this can be interpreted two ways. As a >clarification, do you mean "only one action of _any_ instance domain>" Yes. And thank you for reminding us that the thread of control can go through a wormhole and so cause an action of another instance _in another domain_ to execute before we can complete the action containing the wormhole. HS>or "only one action of _any_ instance"? My >understanding of action interleaving was the latter case so that one >could have simultaneous execution of actions from different instances of >the same object. Hmmm. This may be why I had trouble following some of the articles in this thread. SS>> 3. We could investigate the idea >> of allowing a C3 or C4 accessor for self-creation in a >> creation state, but that has not yet been done. Do we >> need this? I would think that a better approach would be >> to make additional creation states that use C1 or C2. >> Comments anyone? HS>Since you are coming down on the side of associating the creating >create state action with the instances being created (below), then I >think it would be more consistent (aesthetically pleasing?) to limit the >accessors to C1 and C2. It would bother me to have those instances >executing the create state but wind up in another state without a >transition. SS: As you know, my personal philosophy (which is consistent with Steve's) is NOT to make rules unless they are required to (a) make it possible to model some situation we have not anticipated and (b) keep the method consistent. In this case, I would prefer to assert a _guideline_ based (at the moment) solely on aesthetic grounds: Use the C1 and C2 accessors only for self-creation and the C3/C4 accessors only for non-self-creation. greg wiley>> >Now the question is: Is the action execution of a creation >> >state an action execution of the state machines of any >> >self-created instances created by that invocation? SS>> I would say yes: the action is executing on behalf of all >> multiple self-created instances. While this may be a slight >> extension of the assumption of interleaving at the action >> level, I do not see that it leads to an inconsistency anywhere >> in the method. Do you see anything that would cause >> problems? HS>I like that phrase, "on behalf of". Since it implies only one action is >still executing, it gets around the problem of each created instance >having a distinct action executing. This eliminates "race" conditions >about where one is in each action. [The obscure problem I am thinking >about would be to replace the original events issued to the created >instances with synchronous accessors. If there were separate actions >executing slightly out of process-by-process synch, the data accesses >would be ambiguous. Assuming a single, shared action removes this >problem.] > HS>Though I cannot come up with a practical case where one would get >trashed off the top of my head, I am still bothered by the potential >inconsistency if synchronous accessors are used. SS: By "synchronous accessors" here, do you mean non-self creation accessors? (As a reminder to all the lurkers, ALL accessors are synchronous _with respect to the action from which they are invoked_.) HS>If one were executing a non-create action . . . SS: (an action associated with a non-creation state?) HS>. . .from an instance then no other action should be able >to read/write to that instance's data store. ss: Here is where we differ. In the interleaved interprettion of time, only one action can be executing in each domain. So if one action is running, no other one can be and therefore we need place no restrictions on other actions to prevent interference. HS>However, this is not the >case here because the creating action could write to _any_ of the >created instances. Since each created instance "owns" the create action >being executed, any of the created instances can effectively write to >the other instance's data stores while their action is >executing. HS>Now I think you could eliminate my worries about this by placing an >additional restriction on the create state: it cannot access the created >instance's data store other than through the C1/C2 accessor. I don't >think this would be a problem; the original example was admittedly >contrived -- it is hard to imagine a case where one would be seriously >inconvenienced by such a restriction. SS: Agreed (as above) that only C1/C2 accessors should be used for self-creation in a creation state. However, there is no reason why that same action -- the one of the creation state -- shouldn't use write (or even read or delete) accessors to access the newly self-created instance. > >> SS>> Um, HS, would you be so kind as to summarize your interpretation >> as Greg did? I'm not confident I can pull it out of this >> thread -- partially because of all the embedded quotes and a >> moving context. > HS>I was arguing that the creating create state is _not_ associated with >the created instances. Therefore they are not executing an action and >can accept events even though the creating create state is still >executing. My reasoning for this was: > >* When the instance is created it cannot know how it got to that state >by the FSM rules. > >* The instance could have been created by a create accessor (C3/C4) from >another object's instance's action. . . . SS: But this is contrary to your hypothesis, namely that the the newly created instance was created in a creation state of the object of which it is an instance (gads what an awkward sentence :-( ) HS>. . . In that case it would clearly not >be executing an action at the time of creation. > >* If the create action is associated with the instance, then the >instance _is_ executing that action at the time of creation. > >* The behavior of the created instance is different depending upon >context and this is a contradiction. Therefore the created instance >cannot be executing the create action. > SS: I don't really see the contradiction. It would seem peculiar, but what really forbids us from self-creating an instance of object A and non-self creating an instance of A in the FSM for object B? HS>Now coming up with a practical reason why this apparent contradiction >would be a problem is whole new issue. At heart I don't really have a >problem with extending some "specialness" to the creation of instances, >other than what I mention above. > HS>As an aside, this is similar to the issue in another thread about >changing the value of an identifier. In my mind S-M represents a >solution to a different or broader problem than that of relational >databases despite the fact that the relational data model is central to >the methodology. S-M has a write accessor that can be colorized to >enforce specific rules during translation. Thus at the OOA level it may >not be necessary to enforce the delete-to-change rule as one might have >to do in a relational database engine. This seems similar to me in that >one could relax the FSM context-dependence rule . . . SS:I'm not clear on what FSM context-dependence rule you are referring to. HS>. . .under special >circumstances where the OOA provides constructs (accessors) that can be >handled properly in translation. > ----- Shlaer-Mellor Method: Real-Time Software Development ------ Sally Shlaer Tel: (510) 567-0255 ext. 617 Director of Research Fax: (510) 567-0250 Project Technology, Inc. email: sally@projtech.com 10940 Bigge Street URL: http://www.projtech.com San Leandro, CA 94577 -------------------- Real-Time, On Time ------------------------- Subject: Re: (SMU) Request for project metrics "Ralph L. Hibbs" writes to shlaer-mellor-users: -------------------------------------------------------------------- At 09:37 AM 10/15/97 +0100, you wrote: >Jeff.Bevan@cambridge.simoco.com (Jeff Bevan x6093) writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >I am looking for information/documentation on real-world >projects using the Shlaer-Mellor Method. I am interested >in both: > > - Development effort statistics > - Shlaer-Mellor OOA model statistics > > >Basically, whatever information is available. Does PT or >anyone else have a paper on this topic? > Jeff, I have checked our archived paper files. I have found two items that will be of some use in your goals: 1) Object-Oriented Development Using the Shlaer-Mellor Method More than 2,000 projects have used the Shlaer-Mellor Method since its inception. This paper will characterize three such projects: an embedded controller, a client-server information system, and a military avionics project. Each was chosen to illustrate real-world uses of the Method and the unique characteristics of the Method the projects exploited. This paper is located at: http://www.projtech.com/pubs/papers.html 2) Time Metrics Using the Shlaer-Mellor Method: "How long is this going to take?" This is a paper on various time metrics for applying the Shlaer-Mellor Method, along with an extended case study of a real project. This paper is previously unpublished. In response to your request, I've asked our web team to add it to our web site. It should be available in about a week. Once this paper is available, I'm interested in peoples feedback on the paper contents usefulness. Also, I'm interested in seeing contributions from others in the Shlaer-Mellor community. Regrads, Ralph ----- Shlaer-Mellor Method: Real-Time Software Development ------ Ralph Hibbs Tel: (510) 567-0255 ext. 629 Director of Marketing Fax: (510) 567-0250 Project Technology, Inc. email: rlh@projtech.com 10940 Bigge Street URL: http://www.projtech.com San Leandro, CA 94577 -------------------- Real-Time, On Time ------------------------- Subject: Re: (SMU) ROOM vs- OOA "Ralph L. Hibbs" writes to shlaer-mellor-users: -------------------------------------------------------------------- At 11:18 AM 10/14/97 -0400, you wrote: >David Yoakley writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >I am looking for additional information/documentation which compares >the ROOM method with OOA/OOD. Does PT or anyone else have a white >paper on this topic? > I have checked our archived white paper files, and PT does not have any papers comparing the ROOM Method and Shlaer-Mellor Method. We are interested in anything the user community might have on this topic. If anybody has something, I'm willing to post it our web site for general availability. Regards, Ralph ----- Shlaer-Mellor Method: Real-Time Software Development ------ Ralph Hibbs Tel: (510) 567-0255 ext. 629 Director of Marketing Fax: (510) 567-0250 Project Technology, Inc. email: rlh@projtech.com 10940 Bigge Street URL: http://www.projtech.com San Leandro, CA 94577 -------------------- Real-Time, On Time ------------------------- Subject: Re: (SMU) Is a creation state a state? lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Shlaer... > HS>Unfortunately I think this can be interpreted two ways. As a > >clarification, do you mean "only one action of _any_ instance >domain>" > > Yes. And thank you for reminding us that the thread of > control can go through a wormhole and so cause an > action of another instance _in another domain_ to execute > before we can complete the action containing the wormhole. > > HS>or "only one action of _any_ instance"? My > >understanding of action interleaving was the latter case so that one > >could have simultaneous execution of actions from different instances of > >the same object. > > Hmmm. This may be why I had trouble following some of the > articles in this thread. Fascinating (with full pointy-eared emphasis). You are correct that things were probably hard to follow because I was always dealing with the simultaneous view of concurrency, because that is the one that was interesting in the example. (See below) > In this case, I would prefer to assert a _guideline_ based (at > the moment) solely on aesthetic grounds: Use the C1 and C2 > accessors only for self-creation and the C3/C4 accessors only > for non-self-creation. Lacking concrete contrarian evidence, it sounds good to me. > HS>Though I cannot come up with a practical case where one would get > >trashed off the top of my head, I am still bothered by the potential > >inconsistency if synchronous accessors are used. > > SS: By "synchronous accessors" here, do you mean non-self creation accessors? > (As a reminder to all the lurkers, ALL accessors are synchronous _with > respect to the action from which they are invoked_.) Yes, I was referring to simple data store write accessors. In the original example the action for the event generated caused the data store to be changed in the created instance. The issue was whether a subsequent (after the point of event generation) read accessor in the creating create state would "see" the change. I was merely substituting a write accessor for the event generation. This would make no difference in the interleaved view because the event's action could never execute before the read accessor but it potentially makes a difference in the simultaneous view. > HS>If one were executing a non-create action . . . > > SS: (an action associated with a non-creation state?) Yes. > HS>. . .from an instance then no other action should be able > >to read/write to that instance's data store. > > ss: Here is where we differ. In the interleaved interprettion of time, > only one action can be executing in each domain. > So if one action is running, no other one can be and therefore > we need place no restrictions on other actions to prevent interference. Yes, this is where we differ. But only because I had mentally dismissed the interleaved view as uninteresting. In the interleaved view the event never gets executed until after the creation state completes. Therefore the data store value is always deterministic under OOA simulation. In the simultaneous view the event's action _might_ get executed before the creation state action completed and this could result in a non-deterministic value for the data store. In this case you need some sort of translation rule to achieve consistency at the end of the creation action so that an architectural dependence is avoided in the OOA -- an the OOA analyst has to know what the rule is. To me the interleaved view is synonymous with a synchronous architecture while the simultaneous view is synonymous with asynchronous architectures. Thus I have always viewed the interpretation of time as an architectural decision. That is, the analyst doing an OOA should not be concerned with the view of time. This is the philosophical basis for my arguing in the thread that OOA imposes a *lot* of rules on the translation and architecture in order to preserve data and relational integrity. This allows the analyst to count on "magic" during the translation that preserves consistency, regardless of what the analyst does with a given state action. Thus the original example was interesting to me because it seemed to argue that the behavior of the OOA under simulation would be different, depending upon whether the underlying architecture (and time view) was synchronous or asynchronous. To enforce consistency one would have to impose a translation rule that forced the generated event to be actually generated at the end of the action in the asynchronous case. This is the only way that the OOA would simulate in a consistent manner for both synchronous and asynchronous architectures (time views). > SS: Agreed (as above) that only C1/C2 accessors should be used > for self-creation in a creation state. However, there is no reason > why that same action -- the one of the creation state -- shouldn't > use write (or even read or delete) accessors to access the > newly self-created instance. Sure. Since the accessor is, by definition, synchronous the state of the data store at the end of the action should be consistent. > HS>I was arguing that the creating create state is _not_ associated with > >the created instances. Therefore they are not executing an action and > >can accept events even though the creating create state is still > >executing. My reasoning for this was: > > > >* When the instance is created it cannot know how it got to that state > >by the FSM rules. > > > >* The instance could have been created by a create accessor (C3/C4) from > >another object's instance's action. . . . > > SS: But this is contrary to your hypothesis, namely that > the the newly created instance was created in a creation > state of the object of which it is an instance (gads what > an awkward sentence :-( ) Sorry, one of the problems with incipient senility is conceptual dyslexia. My original missive should have read "... accessor (C1/C2)...". My intent was that the created instance _did_ wind up in the create state. Thus the only difference would be whether the action associated with the state got executed, and that would be context dependent (i.e., it would inappropriate to associate the create action with the created instance in a context-dependent manner). > >* The behavior of the created instance is different depending upon > >context and this is a contradiction. Therefore the created instance > >cannot be executing the create action. > > > > SS: I don't really see the contradiction. It would seem peculiar, > but what really forbids us from self-creating an instance of object A > and non-self creating an instance of A in the FSM for object B? There is nothing that forbids either case, which is my point. If I create the instance synchronously from another object's action, the created instance is not associated with that action in any way (i.e., the created instance is _not_ executing _any_ action). But if I create that same instance via an event the instance _is_ associated with the execution of that action (i.e., the instance _is_ executing an action). To me this says that the _instance_ has to know _how_ it came to be created to behave correctly. > HS>Now coming up with a practical reason why this apparent contradiction > >would be a problem is whole new issue. At heart I don't really have a > >problem with extending some "specialness" to the creation of instances, > >other than what I mention above. > > > HS>As an aside, this is similar to the issue in another thread about > >changing the value of an identifier. In my mind S-M represents a > >solution to a different or broader problem than that of relational > >databases despite the fact that the relational data model is central to > >the methodology. S-M has a write accessor that can be colorized to > >enforce specific rules during translation. Thus at the OOA level it may > >not be necessary to enforce the delete-to-change rule as one might have > >to do in a relational database engine. This seems similar to me in that > >one could relax the FSM context-dependence rule . . . > > SS:I'm not clear on what FSM context-dependence rule > you are referring to. I was referring the the fact that the behavior of a state can't depend upon how one got to that state. The behavior being whether the instance is executing the create state action or not. Here I am arguing that maybe this is not a big deal in the OOA and could be relaxed, given the interactions of create accessors, create actions, and a consistent view of time that allow the translation to keep everything consistent. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Request for project metrics "Ralph L. Hibbs" writes to shlaer-mellor-users: -------------------------------------------------------------------- At 04:36 PM 10/15/97 -0700, you wrote: >2) Time Metrics Using the Shlaer-Mellor Method: "How long is this going to >take?" > >This is a paper on various time metrics for applying the Shlaer-Mellor >Method, along with an extended case study of a real project. > >This paper is previously unpublished. In response to your request, I've >asked our web team to add it to our web site. It should be available in >about a week. The paper I mentioned a few days ago is now available for downloading from our web site. You can use the following link to reach it: http://www.projtech.com/news/whatsnew.html I'm interested in peoples feedback on the paper content's usefulness. This feedback can come directly to me or be sent to ESMUG. Sincerely, Ralph ----- Shlaer-Mellor Method: Real-Time Software Development ------ Ralph Hibbs Tel: (510) 567-0255 ext. 629 Director of Marketing Fax: (510) 567-0250 Project Technology, Inc. email: rlh@projtech.com 10940 Bigge Street URL: http://www.projtech.com San Leandro, CA 94577 -------------------- Real-Time, On Time ------------------------- Subject: (SMU) Defect Reports Sally Shlaer writes to shlaer-mellor-users: -------------------------------------------------------------------- >David Stone 5887 writes to shlaer-mellor-users: >-------------------------------------------------------------------- > > [good technical stuff snipped] >If the method were defined in a formal standard (ISO/ANSI/IEEE...) I >would now want to raise a formal Defect Report for consideration by >the appropriate technical committee. > >Is there any such procedure? Yes, and you have already executed it. Now for the longer answer: Several years ago (before we were building and selling SM tools), we invited all SM toolmakers to participate in a program aimed at ensuring that all tools were consistent with the method as defined. All but one (Cadre) refused to participate -- even with non-disclosure paperwork in place and procedures defined so that there would be no leakage from one vendor to another. (H.S., this may add to the answer I sent you earlier with respect to interoperability -- a goal that PT still supports.) This leaves PT in the de facto position of being the standards organization for OOA/RD. I am more comfortable with that today than I was earlier -- in part because we now have this forum which acts as an extended advisory committee. As far as a procedure goes, you have already submitted a Defect Report simply posing a question that led to a thread demonstrating this gap. We keep a list of such method defects/unclear explanations/etc. and will address them as soon as we can. Best to all, Sally Subject: (SMU) How to think about time Sally Shlaer writes to shlaer-mellor-users: -------------------------------------------------------------------- I believe that we have a solid definition of time **assuming that the unit of interleaving is the action**: Only one action in a domain can be executing at a time. This interpretation makes it possible for an analyst to build sensible models, which is all we really care about during OOA proper. I also believe that we do NOT have a real definition of the simultaneous interpretation of time. After some meditation on the articles in the "creation state" thread, I finally think I know why: We asked the wrong question! The question we SHOULD be answering is "what is the unit of interleaving? The answer may be different for each architecture. Having once decided, we have the concepts needed (namely coloring) to express a unit of interleaving. As I read David Stone's article (portions of which are copied below), this is the approach he has taken. Comments? Sally ===== >We have implemented an architecture which _does_ implement the >simultaneous interpretation of time. We allow analysts to use tagging >(colouring) to say that the interleaved interpretation applies within >particular groups of objects, but in general instances execute >concurrently. > > Subject: common colorings [Formerly: (SMU) How to think about time] Kenneth Cook writes to shlaer-mellor-users: -------------------------------------------------------------------- At 09:30 AM 10/18/97 PDT, Sally Shlaer wrote: >I believe that we have a solid definition of time **assuming that >the unit of interleaving is the action**: Only one action in a >domain can be executing at a time. This interpretation makes >it possible for an analyst to build sensible models, which is >all we really care about during OOA proper. > > [snip] > >The question we SHOULD be answering is "what is the unit >of interleaving? The answer may be different for each >architecture. > >Having once decided, we have the concepts needed >(namely coloring) to express a unit of interleaving. >As I read David Stone's article (portions of which >are copied below), this is the approach he has taken. > >Comments? On an architecture involving multiple processors, there isn't necessarily *any* interleaving. Our architecture uses kernal threads and shared memory to store object instance state. On a multiprocessor machine, this means object instance state can be accessed simultaneously by several users. Someone (lahman?) said that it is better if modelers are not aware of of time interpretations when modeling. We felt it would be a terrible burden to ask modelers to manage object locking, so object access is managed within the architecture. Thus we require no colorings. I agree, though, that other architectures may require coloring which allow modelers to manage the architecture's unit of interleaving. Looking over the fence to see how this is done with CORBA, the Concurrency and Life Cycle service interfaces are defined to handle these problems. This makes me think it might be possible to color common architectural services in common ways. Ken Cook Softwire Corporation http://www.softwire.com ken.cook@softwire.com Subject: Re: (SMU) How to think about time "Greg Wiley" writes to shlaer-mellor-users: -------------------------------------------------------------------- Sally Shlaer wrote: >Having once decided, we have the concepts needed >(namely coloring) to express a unit of interleaving. >As I read David Stone's article (portions of which >are copied below), this is the approach he has taken. The problem with this approach is that coloring then becomes an application analysis activity. Even worse, this particular choice of color can profoundly impact the OOA. That is, color A leads to a much different model than color B. Coloring is orthogonal to OOA. It is what the integrators and designers do to implement an OOA given the environmental and performance restrictions of a target system. It should not influence a domain analysis. Currently, an analyst has to choose from only two interpretations. Further, domains modeled as if actions can execute simultaneously will probably work on architectures that interleave all actions. Placing more discretion over interleaving in an analyst's hands will lead to decreased interoperability. In fact, I would like to see a unified interpretation of time. Domain modeling in OOA is supposed to shield analysts from the architecture and when I need to purchase a domain model, I do not want to find that it requires my architectures to support "Big Tad's Interleaving Model (TM)" or somesuch. If it comes down to picking a standard interpretation, I favor the simultaneous interpretation because it more naturally models the real world (e.g. two dogs can bark at the same time) . But my overriding interest is the model as an asset so I wouldn't really mind either interpretation becoming the standard. I simply want my models to work on any given archi- tecture. -greg Subject: (SMU) common coloring Kenneth Cook writes to shlaer-mellor-users: -------------------------------------------------------------------- At 03:39 PM 10/20/97 -0700, Greg Wiley wrote: >"Greg Wiley" writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >If it comes down to picking a standard interpretation, >I favor the simultaneous interpretation because it >more naturally models the real world (e.g. two dogs >can bark at the same time) . But my overriding >interest is the model as an asset so I wouldn't really >mind either interpretation becoming the standard. I >simply want my models to work on any given archi- >tecture. Agreed. As I tried to show by using our architecture as an example, modelers need not worry about the interpretation of time at all. One of the advantages OOA/RD over paradigms like CORBA is that many of the Common Object Services (COS) can be provided by the architecture, and the model gives all the control necessary without any coloring. For example, Concurrency Service (object locking) can be built into the architecture. Transactional Service can also be built entirely into the architecture, without any coloring needed. While CORBA users are busy learning COS interfaces, OOA/RD users are modeling applications. In cases were architectural services must be controlled with coloring, I agree with Wiley that these decisions should be orthogonal to the analysis. For example, to color an object to be persistent does not greatly affect the analysis thought process. However, some architectures will need help where others do not. While it is not desirable, some architectures may require coloring for Concurrency control. Most architectures that provide persistence need coloring to indicate which objects are persistent. Since the industry (as defined by OMG) has come to define some common object services and has standardized on interfaces to these services, it seems reasonable that standardized colorings could be used to control and access these features from within an OOA/RD model. If I want to map an IDL description of a service domain to a model, it is a fairly straight forward excercise. Interfaces map to Objects, attributes map to attributes. However, if the service is implemented by an OOA/RD architecture domain, it is no longer useful to have an object model representation of that service. Some of that IDL description would now map to colorings. Is there a common way to think about how such service interfaces would map to colorings? While colorings extend the data of a model, might we also need to extend behavior? (as is done in OOP inheritance) Are colorings the only way we should indicate architectural choices? What about UML's three avenues of extension: tags (colors), stereotypes, and constraints? Might stereotypes and constraints play a role? It seems the OOP paradigm has found a standard way to represent new architectural features: an IDL definition. How might the OOA/RD paradigm follow suit? Ken Cook Softwire Corporation http://www.softwire.com ken.cook@softwire.com Subject: Re: (SMU) How to think about time lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Shlaer... Alas, my mail server was down for awhile so Wiley and Cook beat me to it. Basically I agree with both, especially on the issue that coloring should not affect the analysis -- rather it should be regarded as a specification for the RD. I am also bunked in the camp that holds that the OOA should not care about the model of time -- the analyst should be able to simply count on data and relational integrity at the boundary of actions regardless of the time model. Finally, I agree with Wiley that the simultaneous view is the more practical view for real, high-performance, and/or threaded systems. > I also believe that we do NOT have a real definition > of the simultaneous interpretation of time. After some > meditation on the articles in the "creation state" thread, > I finally think I know why: We asked the wrong question! > > The question we SHOULD be answering is "what is the unit > of interleaving? The answer may be different for each > architecture. I don't think the _temporal_ unit of interleaving is critical per se. I think that is an issue for the computing environment (i.e., RD). The OOA defines boundaries -- process, action, object -- that imply certain constraints on data and relational integrity within those boundaries. In principle this is fairly basic in the RD: write locks on data stores and maintaining pointer validity. The complexity comes in recognizing when to engage the protective mechanisms. The OOA does provide extremely powerful tools for the RD to solve the problem of preserving integrity under the simultaneous view. There is a directed graph at each level -- process models, state machines, and the OCM. In addition the IM rigorously defines the data stores and relationships among them. Clearly the dependencies are deterministic so that locking or other mechanisms can be instantiated. The only potential problem I see is deadlocking because of graph cycles. But these can be detected at code generation time. The analyst can then color them or the code generator can default to single process/action/object interleave for that set. Thus the choice of unit of interleave is determined by the particular graph level being processed, which could be a dynamic run time issue. It may be more convenient to lock at the instance or object level, but I see no reason why that would have to be applied to all processing; presumeably one would prefer to lock at the finest grain possible for a given situation. So long as the analyst does not violate some basic rules (e.g., does not instantiate unconditional relationships in a different action than the instances are created), then this should be a solvable problem for the RD. [Note I didn't say easily. It might be real helpful to have the analyst assist the RD after the OOA is done through colorization (mostly to identify situations where locks were _not_ necessary), but that should not be necessary. And to really optimize one might need a pretty sophisticated run time engine to dynamically handle lookahead locking.] -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) How to think about time "John D. Yeager" writes to shlaer-mellor-users: -------------------------------------------------------------------- Well, I need to disagree with everyone to some degree; guess it's just my nature: a) I disagree with Sally that the model of time should be on a per architecture basis. b) I disagree with various responders that the analysis should be completely independent of the model of time. I think having exactly two models is a good idea (alright, I guess I'm agreeing with the Lifecycles book). There are significant shortcuts available when one knows that the model is action-interleaved which is worthwhile, although this model is too constraining when building a real-time distributed system. I would like to see the simultaneous model expanded to define which process types are "atomic" and which are not. I would think that, for example, one could define that any single-instance accessor (R1, W1, C1, C2, C3, C4, and D1) should be viewed as atomic. While for some architectures, the instance may be distributed across multiple processing domains, this should not influence the models. One the other hand, if someone wants to find all instances meeting a specific criterion, it is better that the models explicitly serialize against concurrent modification of these attributes if they need a consistent snapshot; additionally, the semantics of the R2, R3, EW2, and D2 accessors in the presence of modifications needs to be defined (for instance do they guarantee that they will find all instances which have met the criterion for the full duration of the accessor and will only lose some that were in flux, or are all bets off [as might be the case if equivalence classes are being used and traversing the chain while in flux may miss entries]). Given this level of definition, one can build portable models which can be rigourously checked for safety and liveness conditions. These properties are precisely the hard problem in programming a concurrent system and having them made clear in the analysis could be really help expose such problems without burdening the archtiecture to serialize everything. It is possible that an architecture might provide optional, less rigourous versions of these processes available by coloring to assure safety, but one would need to be aware that the analysis no longer proves safety. -- John Yeager Cross-Product Architecture Lucent Technologies, Inc., Bell Labs johnyeager@lucent.com Business Communications Systems voice: (732) 957-3085 200 Laurel Ave, 4C-514 fax: (732) 957-4142 Middletown, NJ 07748 Subject: Re: (SMU) How to think about time "Greg Wiley" writes to shlaer-mellor-users: -------------------------------------------------------------------- John D. Yeager wrote: > b) I disagree with various responders that the analysis should be > completely independent of the model of time. That is not what I was suggesting. The analysis *can be entirely dependent* on the model of time. That is why I do not want analysts to have much freedom in that choice. Analysts should have a well-defined and complete set of axioms for the generalized RD machine so that independently deve- loped domains can interoperate. As it stands, a domain modeler has to choose from just two interpretations. Once chosen, any compu- tational problem (we think, but it should probably be proven sometime) can be expressed in that flavor of OOA. I would rather not have a set of time adorn- ments (coloring) used in analysis to drive the archi- tecture. These would be superfluous and would introduce concepts that are not generally part of the subject matter of a given domain. Using coloring in a domain analysis to specify architec- tural requirements is the elaborational approach to system development, which is fundamentally different from the RD translational approach. An OOA domain stands alone as a description of a subject regardless of how it is eventually used. Instead, coloring is a tool provided by *some* architec- tures to let implementers guide translation. Coloring is not part of the formalism. -greg Subject: Re: (SMU) How to think about time lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Yeager... > b) I disagree with various responders that the analysis should be > completely independent of the model of time. > I think having exactly two models is a good idea (alright, I guess I'm > agreeing with the Lifecycles book). There are significant shortcuts available > when one knows that the model is action-interleaved which is worthwhile, > although this model is too constraining when building a real-time distributed > system. Do you have an example of a shortcut that the analyst would make for an action interleave that could not be resolved in the simultaneous mode? It seems to me that the models would look the same in either case but the RD could be a lot simpler for the interleave model by being a synchronous architecture. If the simultaneous model is used, then the RD gets more complicated because it must supply mechanisms like instance/object locking to preserve the consistency as well as performing the graph analysis to determine the scope of the mechanisms. > I would like to see the simultaneous model expanded to define which > process types are "atomic" and which are not. I would think that, for example, > one could define that any single-instance accessor (R1, W1, C1, C2, C3, C4, and > D1) should be viewed as atomic. While for some architectures, the instance may > be distributed across multiple processing domains, this should not influence the > models. One the other hand, if someone wants to find all instances meeting a > specific criterion, it is better that the models explicitly serialize against > concurrent modification of these attributes if they need a consistent snapshot; > additionally, the semantics of the R2, R3, EW2, and D2 accessors in the presence > of modifications needs to be defined (for instance do they guarantee that they > will find all instances which have met the criterion for the full duration of > the accessor and will only lose some that were in flux, or are all bets off [as > might be the case if equivalence classes are being used and traversing the chain > while in flux may miss entries]). The thought of a distributed _instance_ tends to make the mind mushy. I can't think of a way offhand where one would get screwed, but instinctively this seems like a Don't Go There place. As far as the subset of instances is concerned, I think the the same rules apply: the analyst must be able to assume consistency of the subset throughout action execution. That is, during the action execution the subset data stores don't change, none are deleted, and no other instances are created/modified so that they should be included in the subset. (E.g., when a set is involved, RD locks would be at the object level rather than the instance level.) If the analyst can assume this, then I see no reason, in theory, to to do any special serialization in the OOA regardless of the underlying architecture or time model. The translation and architecture can take care of the enforcement through locking mechanisms or whatever. OTOH, I think you have a good example in that it may be difficult for the translation/architecture to provide _efficient_ support for consistency without help. In relational database design one normally has to design the db with the potential deadlocks in mind because the existing deadlock resolution mechanisms in the underlying db engine tend to be pigs. However, even here I think would still argue that this is a job for RD. Unlike the db case, translation offers mechanisms (e.g., colorization) to guide code generation and the architecture itself may be application-specific. Thus there would be nothing to prevent, for example, introducing the serialization you suggest during the translation. > Given this level of definition, one can build portable models which can be > rigourously checked for safety and liveness conditions. These properties are > precisely the hard problem in programming a concurrent system and having them > made clear in the analysis could be really help expose such problems without > burdening the archtiecture to serialize everything. Having said all the above, I don't think I am disagreeing with what you are saying per se. My issue is just _where_ one deals with the problem -- in the OOA or in the RD. I argue that in the OOA there are higher level guarantees for actions -- data consistency and relational consistency. I also believe these are sufficient for the analyst to generate a proper, portable OOA. The analyst should not have to worry about how these are enforced in a particular implmentation. Thus I relegate the time model to the RD as an implementation issue for a particular application. In application X it might be interleave for a synchronous architecture and in application Y it might be simultaneous for an asynchronous architecture. The analyst's OOA should not have to change just because the implementation architecture changes. -- H. S. Lahman There is nothing wrong with me that 321 Harrison Av L51 couldn't be cured by a capful of Drano Boston, MA 02118-2238 v(617)422-3842 f(617)422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) How to think about time "John D. Yeager" writes to shlaer-mellor-users: -------------------------------------------------------------------- lahman wrote: > Do you have an example of a shortcut that the analyst would make for an > action interleave that could not be resolved in the simultaneous mode? > It seems to me that the models would look the same in either case but > the RD could be a lot simpler for the interleave model by being a > synchronous architecture. If the simultaneous model is used, then the > RD gets more complicated because it must supply mechanisms like > instance/object locking to preserve the consistency as well as > performing the graph analysis to determine the scope of the mechanisms. > I think we aren't refering to the same "simultaneous model of time." If multiple instances may have their actions executing concurently, then a process sequence which does a read-transformation-write may not be safe unless the analyst provides some form of serialization (such as using a single instance as a monitor, etc). For the interleaved action model of time, the safety of such a process chain is guaranteed. The simplifications are similar to those available when using cooperative multitasking versus preemptive multitasking or true concurrency. John Wolfe and others have argued for a replacement for the simultaneous model of time in which single-action data consistency is guaranteed by the architecture. This is more akin to what I think you are describing as similar. The only shortcuts then available to the user of an interleaved model would be for cases where they require a true serialized "snapshot" of the state of the system at a single point in time. (An example would be a banking system in which my account has transactions related to it. An action which wanted to sum up these transactions to compute a balance may get a number which does not reflect the set of transactions at any instant in time even in the consistency model if other instances may be adding transactions while it is processing; in the interleaved model these are serialized). The problem I have with this model is that it is still too onerous for the architecture to have to support as the "least restrictive" case. When the problem space is a distributed real-time system, it is reasonable for the analyst to understand and control concurrency and the limitations on the architecture to have to support this level of serialization is expensive when the implementation is truely distributed. > > The thought of a distributed _instance_ tends to make the mind mushy. I > can't think of a way offhand where one would get screwed, but > instinctively this seems like a Don't Go There place. Yeah, it seems a little far fetched, but certainly there are cases where at least a presence of the object exists on multiple processors (proxy caching of data). > As far as the subset of instances is concerned, I think the the same > rules apply: the analyst must be able to assume consistency of the > subset throughout action execution. That is, during the action > execution the subset data stores don't change, none are deleted, and no > other instances are created/modified so that they should be included in > the subset. (E.g., when a set is involved, RD locks would be at the > object level rather than the instance level.) If the analyst can assume > this, then I see no reason, in theory, to to do any special > serialization in the OOA regardless of the underlying architecture or > time model. The translation and architecture can take care of the > enforcement through locking mechanisms or whatever. The problem here is that forcing the architecture to lock a set of instance when they may not be needed (for instance only this state machine manipulates these instances or the purpose of the accessor doesn't require that robust a function) seems like overkill. > > Having said all the above, I don't think I am disagreeing with what you > are saying per se. My issue is just _where_ one deals with the problem > -- in the OOA or in the RD. I argue that in the OOA there are higher > level guarantees for actions -- data consistency and relational > consistency. I also believe these are sufficient for the analyst to > generate a proper, portable OOA. > > The analyst should not have to worry about how these are enforced in a > particular implmentation. Thus I relegate the time model to the RD as > an implementation issue for a particular application. In application X > it might be interleave for a synchronous architecture and in application > Y it might be simultaneous for an asynchronous architecture. The > analyst's OOA should not have to change just because the implementation > architecture changes. > I guess this is the point in which we disagree. The formalism of the models provides a richer environment for checking that safety and liveness conditions are met than the typical coloring environment. Just looking at the problems one sees in Java programs with people leaving out their "coloring" (synchronized) and the deadlocks which occur from using it incorrectly points out why we need to leverage the expressive power of the models to make this explicit when the problem requires this type of parallelism. Again, I wouldn't throw out the interleaved interpretation -- this is also a useful one when the problem space doesn't seem to require significant parallelism. John -- John Yeager Cross-Product Architecture Lucent Technologies, Inc., Bell Labs johnyeager@lucent.com Business Communications Systems voice: (732) 957-3085 200 Laurel Ave, 4C-514 fax: (732) 957-4142 Middletown, NJ 07748 Subject: Re: (SMU) How to think about time "Greg Wiley" writes to shlaer-mellor-users: -------------------------------------------------------------------- John D. Yeager wrote: >The problem I have with this model is that it is still too onerous for the >architecture to have to support as the "least restrictive" case. Right. The atomicity of an action should not (and I think the literature explicitly states so) be thought of as a guarantee of data consistency, but rather gives the analyst a processing boundary in which to perform computations that must leave the domain consistent upon completion. This puts responsibility for all the concurrency-related issues of a subject matter on the shoulders of the domain analyst. To make the architecture responsible leads to mechanisms which are too general and pessimistic. This does not mean that the architecture will not have concurrency problems to solve. For instance, an architecture that runs an interleaved- interpretation-of-time domain on a multiprocessing system will have to ensure that the system behaves as if only one action can execute at a time *from the perspective of the domain*. -greg Subject: Re: (SMU) How to think about time lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Yeager... > John Wolfe and others have argued for a replacement for the > simultaneous model > of time > in which single-action data consistency is guaranteed by the > architecture. This > is more akin to what I think you are describing as similar. The only > shortcuts > then available to the user of an interleaved model would be for cases > where they > require a true serialized "snapshot" of the state of the system at a > single > point in time. (An example would be a banking system in which my > account has > transactions related to it. An action which wanted to sum up these > transactions > to compute a balance may get a number which does not reflect the set > of > transactions at any instant in time even in the consistency model if > other > instances may be adding transactions while it is processing; in the > interleaved > model these are serialized). Yes, this is more in line with the model that I envision. However, I think mine is a bit stronger. I would argue that the action cannot execute until the architecture has determined that it can do so in a safe manner. That is, the architecture acquires the necessary locks prior to consuming the event. If all the locks cannot be acquired, those acquired already are released and an attempt is made to consume some other event. If all were acquired, then the event is consumed, the action executes, and then the locks are released. Thus in my model with your example, other transactions could not be added until the summing action completed (i.e., analogous to a table write lock). The sum would reflect a consistent view of the transactions throughout the action execution. (Of course, if the sum were passed on to another action, it would not necessarily represent the state of the transactions when the second action processed it; it _would_ represent the state of the transactions at the time it was computed, but that's all an OOA promises anyway.) > > > The problem I have with this model is that it is still too onerous for > the > architecture to have to support as the "least restrictive" case. When > the > problem space is a distributed real-time system, it is reasonable for > the > analyst to understand and control concurrency and the limitations on > the > architecture to have to support this level of serialization is > expensive when > the implementation is truely distributed. I agree that it may be quite onerous to support. But then you are free, on an application-by-application basis, to implement the interleaved view. Whether the underlying implementation will be distributed or not is an implementation issue that I think should not be of concern to the OOA analyst. > The problem here is that forcing the architecture to lock a set of > instances when they may not be needed (for instance only in this state > machine manipulates these instances or the > purpose of the accessor doesn't require that robust a function) seems > like > overkill. You also have colorization to transition between the OOA and the RD to eliminate the overhead when it is not necessary because of the nature of the problem. The thing I like about this is that the colorization can be application-by-application. One can imagine situations where this type of safety is dependent upon the domain context. For example, different hardware models might support different sets of interrupts. If only a subset of the interrupts supported by the domain raised a safety issue, then you could colorize the application for the hardware version that didn't provide those interrupts to ignore the locking. > > > I guess this is the point in which we disagree. The formalism of the > models > provides a richer environment for checking that safety and liveness > conditions > are met than the typical coloring environment. Just looking at the > problems one > sees in Java programs with people leaving out their "coloring" > (synchronized) > and the deadlocks which occur from using it incorrectly points out why > we need > to leverage the expressive power of the models to make this explicit > when the > problem requires this type of parallelism. Again, I wouldn't throw > out the > interleaved interpretation -- this is also a useful one when the > problem space > doesn't seem to require significant parallelism. > Here I would argue that this is a matter of coloring technology. Currently colorization seems to be limited to independently tagging specific items in the OOA. I would agree that one really needs a more versatile suite of mechanisms (e.g., tagging sets of things or combinations of events and data stores). However, this is an issue for an RD formalism and the supporting tool implementations. What it really comes down to is data integrity and every (O)DBMS on the market has to solve the same problems. As I indicated earlier, I think S-M already provides a richer suite of tools that allows -- in theory -- a better separation application developer and the architectural implementer than is available between the database designer and the database engine implementer. As a result the poor database designer is stuck with having to worry about implementation problems like deadlocks when trying to solve a much higher level problem. Subject: Re: (SMU) How to think about time lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- > Right. The atomicity of an action should not (and I think the > literature > explicitly states so) be thought of as a guarantee of data > consistency, > but rather gives the analyst a processing boundary in which to perform > > computations that must leave the domain consistent upon completion. We are either talking about different things or we disagree a whole lot here. Let's consider two cases. First, the relational integrity issue: x_handle = find Some_Object where Attr_1 = GREEN. ... z = x_handle.Attr_2 In this case the instance handle (identifier in the ADFD) had better still be valid by the time I access its data store in the action. I contend that there _must_ be a delete lock on that instance at least until the store is accessed or my action is useless. Now let's look at a data consistency example. Suppose I am running a balance sheet report out of a General Ledger system. The action that grabs the data and sums it might look something like {Asset_set} = Find-all Transaction where Type = ASSET // set accessor asset_sum = Sum_It ({Asset_set}) // transform ... {Liability_set} = Find-all Transaction where Type = LIABILITY // set accessor liability_sum = Sum_It ({Asset_set}) // transform As the name implies, the Balance Sheet must balance. When my action grabs all the asset Transactions and sums them and then grabs all the liability Transactions and sums them, those two sums had better match up. This means that no one can be adding, deleting, or modifying transactions while I am extracting either of those two subsets of transactions or in the time _between_ the extract ions. I cannot write that action unless I can count on this fact. Moreover, there is no reasonable way to write the OOA itself to guarantee the integrity without bringing the underlying DBMS implementation into the OOA. > > > This puts responsibility for all the concurrency-related issues of a > subject > matter on the shoulders of the domain analyst. To make the > architecture > responsible leads to mechanisms which are too general and pessimistic. In my GL example, I don't _want_ to have to think about this because it is not the least bit relevant to the problem I am solving -- printing a report. Now the RD developer (who may be me) will very much want to know how much aggravation is ahead in supporting the data consistency, so when he asks me my answer will be, "Gee, Huck, I think you have a Big Problem." The point is that the OOA analyst is solving one problem while the RD developer is solving another; they may have to communicate, but they are looking at things from a very different perspective. As it happens, in this example the architecture can very probably do it much more efficiently than I could possibly hope to do in the OOA simply because it has access to the underlying GL DBMS and that DBMS will already have triggers that will Do The Right Thing. Subject: (SMU) Architecture independence Tim Wadsworth writes to shlaer-mellor-users: -------------------------------------------------------------------- Hello, I would like to ask a philosophical question: Should analysis be "pure" in that it be independent of the architecture? To answer my own question: It is my belief that if it is not possible for analysis to be architecturally independent, then it points to a lack of rigour in the method. By analogy, iff the ANSI 'C' standard is rigorous then an ANSI 'C' compliant program will be independent of the (ANSI) 'C' compiler used to compile it. Tim. Subject: Re: (SMU) How to think about time Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- > Right. The atomicity of an action should not (and I think the > literature explicitly states so) be thought of as a guarantee of > data consistency, but rather gives the analyst a processing > boundary in which to perform computations that must leave the > domain consistent upon completion. This is not quite right. Rule 1 on page 106 of object lifecycles (Rules about consistent data) states: "When an action completes, it must leave the system consistent, either by writing data to paint a consistent picture or by generating events to cause other state machines to come into conformance with the data changes made by the sender of the event." Thus there is no requirement that the system be in a consistent state upon completion of an action. Indeed, in a complex system with many interacting threads, the system may never be completely consistent with the information model! Dave. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Tamerton Road, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com For embedded Systems Support mailto:armapps@gpsemi.com Subject: Re: (SMU) Architecture independence "Stephen R. Tockey" writes to shlaer-mellor-users: -------------------------------------------------------------------- > Tim Wadsworth writes: > -------------------------------------------------------------------- > > I would like to ask a philosophical question: > > Should analysis be "pure" in that it be independent of the > architecture? I think the obvious answer is, "Yes". However this answer isn't where the interesting discussion lies. IMHO, everyone will agree that the analysis should be independent of the architecture. But I don't for a moment think we all really agree what aspects of a system are "architectural" and what aspects arent. Without intending to disparage OOA/RD (as I think it's clearly one of the best approaches available), I have some disagreement with some of the things found in a S/M-OOA model on the basis that I believe they represent premature architectural decisions. Others disagree and see no problem putting these things in. > To answer my own question: > > It is my belief that if it is not possible for analysis to be > architecturally independent, then it points to a lack of rigour in the > method. "Mainstream" (is that the "politically correct" term these days?) OOD can be incredibly rigorous without being architecturally independent. I think rigour and architectural independence are orthagonal issues. To me, it's more a question of "value" than rigour, anyway: Is an architecturally independent method more valuable than a non-architecturally independent method? (To me: yes) Is a rigourous method more valuable than a non-rigorous method? (To me: it depends. But in general I'm inclined to also answer yes). Cheers, -- steve Subject: Re: (SMU) Architecture independence lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Wadsworth... > I would like to ask a philosophical question: I love philosophical questions! They allow one to pontificate without the encumbrances of technical correctness or practicality. > > > Should analysis be "pure" in that it be independent of the > architecture? Yes. > > > To answer my own question: > > It is my belief that if it is not possible for analysis to be > architecturally independent, then it points to a lack of rigour in the > > method. I would agree. I _suspect_ that there are practical situations where one has to do things in the OOA that unavoidably reflect the architecture, but so far I have not encountered a concrete example. The couple of times that I thought I had Steve and Sally nailed it turned out that I was just not modeling as generally as I might have or the level of abstraction was incorrect. Subject: Re: (SMU) How to think about time lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Whipp... > "When an action completes, it must leave the system consistent, > either by writing data to paint a consistent picture or by > generating events to cause other state machines to come into > conformance with the data changes made by the sender of the > event." > > Thus there is no requirement that the system be in a consistent > state upon completion of an action. Indeed, in a complex system > with many interacting threads, the system may never be completely > consistent with the information model! > I recognize that you were driving at a different point, but for the sake of clarification...I think this is an issue of wheels within wheels. As I read that quote, it was referring to the system as a whole. In particular, I believe it is directed at consistency issues that are quite properly part of the OOA. For example, if I create a new instance in my Crusades Simulation of some critter, say Monthly Pillage Count, that represents a data point in a temporal sequence and I have some other object that maintains a Running Average Pillage Count I am obligated to make sure that Running Average Pillage Count somehow gets updated when I am done adding the new instance. This stems directly from the algorithms, protocols, or whatnot of the OOA problem space so the OOA analyst is responsible for enforcing it. I believe the data consistency at issue in this thread is at a lower level. In an action I have to be able to count on some level of consistency in the data that I access. The simplistic example is calculating Density from Mass and Volume; the values of Mass and Volume must be consistent with each other when I use them in the calculation. I can make life easier for the translation if I postulate an accessor in the OOA that obtains both values at the same time. However, I am not _required_ to do that by the methodology, so I could use two separate read accessors. If I do use two read accessors, then the values returned still have to be consistent over the time interval of the two accessor invocations. [One could, of course, construct a more complex example where the independent attributes were in different objects, so two accessors would always be required and this is not even a modeling style issue.] I see this level of consistency as necessary to make action writing feasible and, therefore, it becomes a given that the translation/architecture must support it. At this level the only consistency the OOA analyst needs to enforce is to make sure Mass and Volume are accessed within the same action. Subject: Re: (SMU) Architecture independence Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- Tim Wadsworth wrote: > Should analysis be "pure" in that it be independent of the > architecture? Yes. However, there are a couple of other issues that are sometimes overlooked in this area: An analysis should also be independent of any service somains that it uses. It should assume that any service it requires exists in the form that it wishes to use. This is not generally a problem, though bridging technology could use some improvement. The analysis should also be independent of the tool used to capture it. Each CASE tool uses a different interpretation of the method. I use a fairly primative tool. Its method support is pre-OOA96. There are stong arguments that I should use the method support by the tool, not SM. I tend to resist these and use pencil and paper. But at the end of the day, any model that I construct must be simulatable on the tool. Thus my paper model must be manually reduced to something the tool can handle. I am of the opinion that tool dependencies are the worst type. Architectural and service domain pollution can be corrected during reviews. Tool pollution is more fundamental. If you think about questions like ADFDs Vs action language; use of link/unlink for relationships; the definition of splicing in subtype relationships; and many others then your answer tends to depend on your tool experience. Dave. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Tamerton Road, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com For embedded Systems Support mailto:armapps@gpsemi.com Subject: Re: (SMU) Architecture independence lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Tockey... > "Mainstream" (is that the "polictically correct" term these days?) OOD > can be incredibly rigorous without being architecturally independent. I would have to disagree with that statement. You can accurately describe any C++ program you might write after the fact in UML and that is _not_ a Good Thing. Many badly written C++ programs could never be expressed in an OOA because neither the notation nor the methodology would allow it. The UML crowd relies solely upon the analyst's judgement and experience to prevent creating bad programs while S-M's rigor can prevent large classes of bad designs because you aren't allowed to express those designs in the OOA. > To me, it's more a question of "value" than rigour, anyway: > > Is an architecturally independent method more valuable than a > non-architecturally independent method? (To me: yes) I submit that it is crucial to software reuse, porting, and system maintenance. It is hard to imagine a modern system where none of these issues is relevant. > > > Is a rigourous method more valuable than a non-rigorous method? > (To me: it depends. But in general I'm inclined to also answer > yes). > This was one of the irreconcilable differences in last year's debates with Robert Martin. He allowed as how S-M provided more rigor, but in his view that rigor could be an impediment to creativity in the design so the analyst should be free to choose the rigor to apply on a case-by-case basis. As near as I can tell this view is fairly representative of the "mainstream". One of our other divisions recently opted for "mainstream" over S-M precisely for this reason. A cynic might argue that they really wanted to keep writing code the same way they always had and S-M would not let them -- but I wouldn't dream of doing that. I am reminded of an anecdote from many years ago. A rather famous software guru with credentials beginning in the '70s (who is still doing a lot of writing) once wrote a piece in the Computer Language magazine that defended the goto as soemthing you might want to do _sometimes_. He provided a code fragment as an example of a case that supposedly justified the use of a goto. The fragement had about 15 lines of code and about ten gotos. It was the second worst fragment of code I have ever seen. It was virtually incomprehensible and when you finally did figure out what it was doing it had three errors in it. The author got so lambasted in the next Letters section that I did not see another code fragment in his articles for nearly a decade! The moral I attribute to the anecdote: Nobody's judgement is so good that they can skip the rigor when it is available. Subject: Re: (SMU) Architecture independence "Stephen R. Tockey" writes to shlaer-mellor-users: -------------------------------------------------------------------- > Responding to lahman > > Responding to Tockey... > > > "Mainstream" (is that the "polictically correct" term these days?) OOD > > can be incredibly rigorous without being architecturally independent. > > I would have to disagree with that statement. You can accurately > describe any C++ program you might write after the fact in UML and that > is _not_ a Good Thing. Many badly written C++ programs could never be > expressed in an OOA because neither the notation nor the methodology > would allow it. The UML crowd relies solely upon the analyst's > judgement and experience to prevent creating bad programs while S-M's > rigor can prevent large classes of bad designs because you aren't > allowed to express those designs in the OOA. Maybe I didn't express it very well, but you seem to have missed my point. Tim Wadsworth's original posting (to me anyway) equated architectural independence with rigour. I was simply trying to explain that these are orthagonal issues. That a particular model is architecturally independent or not is a completely separate issue from whether it is rigorous or not. Any given model may or may not be: Architecturally independent and rigorous Architecturally independent but not rigorous Architecturally dependent and rigorous Architecturally dependent and not rigorous Could it be that we have different definitions of "rigor"? I'm equating rigor with formality in the mathematical (i.e., formal language) sense. Are you using a different meaning? > > To me, it's more a question of "value" than rigor, anyway: > > > > Is an architecturally independent method more valuable than a > > non-architecturally independent method? (To me: yes) > > I submit that it is crucial to software reuse, porting, and system > maintenance. It is hard to imagine a modern system where none of these > issues is relevant. > > > Is a rigourous method more valuable than a non-rigorous method? > > (To me: it depends. But in general I'm inclined to also answer > > yes). > > > > This was one of the irreconcilable differences in last year's debates > with Robert Martin. He allowed as how S-M provided more rigor, but in > his view that rigor could be an impediment to creativity in the design > so the analyst should be free to choose the rigor to apply on a > case-by-case basis. As near as I can tell this view is fairly > representative of the "mainstream". One of our other divisions recently > opted for "mainstream" over S-M precisely for this reason. A cynic > might argue that they really wanted to keep writing code the same way > they always had and S-M would not let them -- but I wouldn't dream of > doing that. Realize that I was not trying to argue in favor of "mainstream" OO. I'm fairly certain that we agree that SM is more likely to result in a good quality, maintainable, portable product than MSOO. I was only using MSOO as an example of a method that could be as rigorous as one wanted it to be without necessarilly being architecturally independent. Remember that I'm only trying to point out that rigor != architectural independence. IMHO, it's the combination of those two things (architectural independence *together with* rigor) that makes SM/OOA better than UML. It's not architectural independence alone and it's not rigor alone. It's both. I was waffling a bit on my "rigor is always good" statement only because not every program is that critical. Where the result is critical to a corporation, rigor and architectural independence are warranted. Where the result is not that critical, rigor and architectural independence is less important. I just completed a small application for home use. It's a program that applies temperature correction factors to before- and after-fermentation specific gravity readings for homebrew beer (this is necessary to get accurate computations of % alcohol by volume). The whole program is in the 200 SLOC range. Were architectural independence and method rigor that important? I don't think so. But I think we would both agree that the real trouble is when one develops mission critical software *without the aid of architectural independence and rigor*. -- steve Subject: Re: (SMU) Architecture independence Mike Frankel writes to shlaer-mellor-users: -------------------------------------------------------------------- Tim Wadsworth wrote: > > Tim Wadsworth writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Hello, > > I would like to ask a philosophical question: > > Should analysis be "pure" in that it be independent of the > architecture? > > To answer my own question: > > It is my belief that if it is not possible for analysis to be > architecturally independent, then it points to a lack of rigour in the > method. Tim, your innocent question has sparked some interesting debate. Unfortunately, a lot of what has transgressed so far seems to me to miss the point of why we are doing all of this in the first place: We are using a solution created by humans to address problems created by humans. There is bound to be some imperfection in there somewhere! Should analysis be purely independent of architecture, or of tool support? - Of course! Can analysis be purely independent of architecture, or of tool support? - Of course not! Esprit is in the methods education and OOA model content business, not the tool business, so we are without a doubt biased towards doing better OOA instead of fudging or relying on architectural or tool nuances for completeness, accuracy, or performance. However, we have found that there are basically 3 levels of independence one may hope or want to achieve in an OOA model: 1. Completely independent - necessary to market reusable domain OOA models across many industries, so that the behavior is correct regardless of physical concurrency or platform and language variations. This is the level of independence we have strived for in our BASELINE domain model library. Even in this situation though, a model is just as dependent on an architecture because of the things we don't have to model (event queues, for example) as we are for the things we do have to model, or possibly are not allowed to model because of architectural restrictions (like not supporting assigners, for some reason). 2. Technology dependent - necessary to achieve reusability of a domain OOA model within a vertical business area, or a product line produced by one company, where there is a consistent set of platforms or service domains in place. It is simply a fact of software development that some subject matters exist soley because we have introduced a specific technology and architecture into our project. To model beyond the requirements necessary to keep the product line running and developed on time would be a waste of resources. 3. Architecture dependent - necessary to achieve accurate behavior in the model in a very short time frame, where the need for the model is quite transitory. For example, protoyping a proof of concept for a new product, which has as much likelihood of being rejected as accepted, or for multi-phased project deliverables, where a domain acts as a stepping stone solution for phase 1 and is to be replaced by a different, "deployable" technology in all subsequent phases. You better belive that I am going to recommend to my clients that they spend the least amount of time necessary, and make use of whatever architectural dependencies they can get their hands on to get this domain out the door as soon as possible. To not recognize that every decision about how independent an OOA model should be made in the context of the project situation, company goals, expected platform changes, etc.., is not being a practical software development organization. The question that every analyst should be asking is: "How independent does this OOA model *need* to be to accomplish my or my company's goals?" -- ----------------------------------------------- Mike Frankel Director of Software Engineering Esprit Systems Consulting, Inc. 610-436-8290 fax 610-436-9848 mfrankel@EspritInc.com http://www.EspritInc.com -->BASELINE Domain Models -->Object Methods Training and Consulting -->Structured Methods Training and Consulting "Strategies for Computer and Human Systems" ----------------------------------------------- Subject: Re: (SMU) Architecture independence -Reply Jerry L. Bundt writes to shlaer-mellor-users: -------------------------------------------------------------------- We have been doing OMT for about a year now. We basically capture requirements and do the analysis, then hand-off the analysis to a design contractor for implementation. In doing the requirements analysis, we have found that a poorly developed architecture (which was under the control of the implementation team) constrains the analysis, not only in methodology, but also in content. In our case, the RDBMS structure was driving the analysis. We have since raised our concern to the appropriate management levels and have been heard. Therefore, we see architecture as a prime factor in developing any OOA. They go hand in hand and should be as incremental and iterative as the OOA/D. Don't make the mistake and let the data structure drive your analysis. I can honestly say it doesn't produce or allow for true object-oriented development. This is a definite lesson-learned for our development team. Jerry Bundt Sumaria Systems, Inc. Subject: Re: (SMU) Architecture independence lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding Tockey wrote: > Could it be that we have different definitions of "rigor"? I'm > equating > rigor with formality in the mathematical (i.e., formal language) > sense. > Are you using a different meaning? Actually I was responding to the statement that "'mainstream' OOD can be incredibly rigorous". I don't think that it is for the reason I gave. But while we are on the subject of orthogonality between OOA rigor and architectural dependence, I am not convinced that they are orthogonal _in the S-M context_. In general, I agree. However, there is a causal relationship between OOA and RD. I would argue that an OOA cannot be architecturally independent of the RD unless it is rigorous; anything else would be serendipity, at best. Put another way, I would argue the following possibilities in practice: A independent and rigorous -- always true for S-M and usually for ROOM by intent A independent and ~rigorous -- many snowballs melt below; correlated with sunspots A dependent and rigorous -- but was it good for you? A dependent and ~rigorous -- the easy, mainstream way -- a million lemmings can't be wrong (a great quote from Bertrand Meyer that I have been waiting to use). It seems to me that the causal relation determines the first and last while the middle two options are non sequitors. > Realize that I was not trying to argue in favor of "mainstream" OO. > I'm > fairly certain that we agree that SM is more likely to result in a > good quality, maintainable, portable product than MSOO. I was only > using MSOO as an example of a method that could be as rigorous as one > wanted it to be without necessarilly being architecturally > independent. > Remember that I'm only trying to point out that rigor != architectural > > independence. I was just agreeing with your assessments with a more valkyrian tone.. > I was waffling a bit on my "rigor is always good" statement only > because > not every program is that critical. Where the result is critical to a > corporation, rigor and architectural independence are warranted. Where > > the result is not that critical, rigor and architectural independence > is less important. I just completed a small application for home use. > It's a program that applies temperature correction factors to before- > and after-fermentation specific gravity readings for homebrew beer > (this is necessary to get accurate computations of % alcohol by > volume). > The whole program is in the 200 SLOC range. Were architectural > independence and method rigor that important? I don't think so. But > I think we would both agree that the real trouble is when one develops > > mission critical software *without the aid of architectural > independence > and rigor*. > I would agree that I probably would not bring S-M to bear on a 200 SLOC, one-shot, personal program -- but for different reasons. There is a fixed overhead in applying the methodology that would not be worth the price. However, make that 20L SLOC in the same circumstances and I would use S-M. I would use S-M for three reasons. First, it is closely aligned with defect prevention by forcing one to think about things earlier. Second, it will cut down the test & debug time. Third, if it is that large I will almost certainly have to modify it at some point and that will be a lot easier to do. All of these things indirectly derive from the rigor that I believe is an asset. I believe architectural independence comes for free with S-M once you decide to use it; it is a cornerstone of the methodology. If you let the architecture creep into the OOA you risk developing bad habits that might be difficult to lose when you can't afford them. Subject: Re: (SMU) Architecture independence lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Frankel... > > > Can analysis be purely independent of architecture, or of tool > support? > - Of course not! > To not recognize that every decision about how independent an > OOA model should be made in the context of the project situation, > company goals, expected platform changes, etc.., is not being > a practical software development organization. The question > that every analyst should be asking is: "How independent does > this OOA model *need* to be to accomplish my or my company's > goals?" > My impression is that there is a fairly pervasive view that it is not possible to build an OOA model that is truly independent on the architecture. You comments seem to be a variation on that theme in that they imply that there is extra work to make it independent that may not be warranted in a particular context. I agree with you, Whipp, and others that there is a problem with the tools, particularly related to supporting RD in the form of code generation. This is mainly an historical artifact; RD was not defined with the rigor of OOA and the tool vendors had to implement something to support it. However, I think this is a separate issue from whether one can build an OOA that is theoretically independent of the architecture and whether there is a cost associated with doing that. The theoretical issue is the one that I think Wadsworth was after. Assume that you were going to manually do the RD so that tools were not an issue. Would you still feel that it would not be possible to make an OOA that was independent of the architecture or, if it were possible, that it would require extra effort? If so, do you have a concrete example of such a case? As I indicated earlier, I have this niggling feeling that there are situations where an OOA will unavoidably have architecture creep. However, I can't come up with a plausible example. Nor have I seen one in the couple of years I have monitored this forum. The lack of specific examples makes me wonder if my instinct (and perhaps others') really just reflects a belief from the reptillian brain stem that the methodology hype is too good to be true. Your spin concerning the extra work is an interesting one. A few years ago we did a domain for some new hardware that had iterations, one nested within the other. These iterations were at the OOA level because they spanned multiple states in multiple objects. One loop was on frequency while the other was on bias current. At the time we did not know which had bigger overhead in the hardware for changes. We guessed and the guess happened to be correct for real hardware. For a long time I felt this was an example of implementation creeping into the OOA because whichever iteration was the outer one needed to be the one with the largest overhead for changes and that was dependent upon the implementation of another domain. Then Greg Eakman pointed out that the iterations could be generic. Since loops were implemented with events, one could simply have an "if" that chooses which event to send (i.e., to initiate either frequency processing or bias current processing) based upon the value of an attribute in a hardware specification object. When the processing finished a similar "if" could determine the appropriate return event (to the inner iteration or exit from the outer iteration). This is a nice, general solution that makes the order of the loops a run-time dynamic decision based upon a specification (i.e., which has higher overhead in the hardware at hand). So I had to kiss this "definitive" example off as a proof of implementation creep. However, there was extra work involved in making the nesting of the iterations interchangeable -- two new "if" statements and added specification elements, which brings me back to your implication that there may be unjustified work associated with the independence. In this case it was pretty minor but one can envision situations where it might be nontrivial. I am prepared to argue that this "extra" work is really good modeling. A requirement was good performance and since the order of loops would affect performance AND we had no idea which was processing had the most overhead for changes, the only proper choice was to do things generically. We also knew in practice that the hardware guys were going to tinker with the hardware and they might even reverse the overhead in a new hardware version. However, this admittedly takes us into a grey area of what we "know" and what the implied requirements are. In this situation I think the generic approach was proper, but Iwonder if there might be much mushier situations where things would not be so clear. Subject: Re: (SMU) Architecture independence bruce.levkoff@cytyc.com (Bruce Levkoff) writes to shlaer-mellor-users: -------------------------------------------------------------------- shlaer-mellor-users@projtech.com,Internet writes: lahman writes... >As I indicated earlier, I have this niggling feeling that there are >situations where an OOA will unavoidably have architecture creep. >However, I can't come up with a plausible example. Nor have I seen one >in the couple of years I have monitored this forum. The lack of >specific examples makes me wonder if my instinct (and perhaps others') >really just reflects a belief from the reptillian brain stem that the >methodology hype is too good to be true. My favorite example on our multiprocessor machine is the modeling of bar code scanning. The motor that turns the vial with the bar code on it is controlled by processor B. The bar code scanner is on processor A. Our "scan operation" object is being modeled to prevent an unnecessary communication of the bar code data from processor B to A. To me, this is an example of architecture (albeit, not only software but system as well) affecting analysis. Does this meet your criteria? Bruce Subject: Re: (SMU) Architecture independence lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Levkoff... > My favorite example on our multiprocessor machine is the modeling of > bar code scanning. The motor that turns the vial with the bar code on > > it is controlled by processor B. The bar code scanner is on processor > > A. Our "scan operation" object is being modeled to prevent an > unnecessary communication of the bar code data from processor B to A. > > To me, this is an example of architecture (albeit, not only software > but system as well) affecting analysis. Does this meet your criteria? > > I don't know. I think I would need more information about what is being modeled. In particular, I don't know what "'scan operation' object" is or the nature of the unnessary communication being prevented. Superficially the idea of a Vial Turner object and a Scanner object being related and communicating with one another seems reasonable without implying anything about separate processors. The fact that they are on separate processors and that they might be executing actions simultaneously seems like an architecture issue. I guess it turns on exactly what needs to be modeled concerning that 'unnecessary communication'. Subject: Re: (SMU) Architecture independence Mike Frankel writes to shlaer-mellor-users: -------------------------------------------------------------------- lahman wrote: > > > My impression is that there is a fairly pervasive view that it is not > possible to build an OOA model that is truly independent on the > architecture. You comments seem to be a variation on that theme in that > they imply that there is extra work to make it independent that may not > be warranted in a particular context. > > I agree with you, Whipp, and others that there is a problem with the > tools, particularly related to supporting RD in the form of code > generation. This is mainly an historical artifact; RD was not defined > with the rigor of OOA and the tool vendors had to implement something to > support it. However, I think this is a separate issue from whether one > can build an OOA that is theoretically independent of the architecture > and whether there is a cost associated with doing that. The theoretical > issue is the one that I think Wadsworth was after. > > Assume that you were going to manually do the RD so that tools were not > an issue. Would you still feel that it would not be possible to make an > OOA that was independent of the architecture or, if it were possible, > that it would require extra effort? If so, do you have a concrete > example of such a case? > > As I indicated earlier, I have this niggling feeling that there are > situations where an OOA will unavoidably have architecture creep. > However, I can't come up with a plausible example. Nor have I seen one > in the couple of years I have monitored this forum. The lack of > specific examples makes me wonder if my instinct (and perhaps others') > really just reflects a belief from the reptillian brain stem that the > methodology hype is too good to be true. > > Your spin concerning the extra work is an interesting one. A few years > ago we did a domain for some new hardware that had iterations, one > nested within the other. These iterations were at the OOA level because > they spanned multiple states in multiple objects. One loop was on > frequency while the other was on bias current. At the time we did not > know which had bigger overhead in the hardware for changes. We guessed > and the guess happened to be correct for real hardware. > > For a long time I felt this was an example of implementation creeping > into the OOA because whichever iteration was the outer one needed to be > the one with the largest overhead for changes and that was dependent > upon the implementation of another domain. Then Greg Eakman pointed out > that the iterations could be generic. Since loops were implemented with > events, one could simply have an "if" that chooses which event to send > (i.e., to initiate either frequency processing or bias current > processing) based upon the value of an attribute in a hardware > specification object. When the processing finished a similar "if" could > determine the appropriate return event (to the inner iteration or exit > from the outer iteration). > > This is a nice, general solution that makes the order of the loops a > run-time dynamic decision based upon a specification (i.e., which has > higher overhead in the hardware at hand). So I had to kiss this > "definitive" example off as a proof of implementation creep. However, > there was extra work involved in making the nesting of the iterations > interchangeable -- two new "if" statements and added specification > elements, which brings me back to your implication that there may be > unjustified work associated with the independence. In this case it was > pretty minor but one can envision situations where it might be > nontrivial. > > I am prepared to argue that this "extra" work is really good modeling. > A requirement was good performance and since the order of loops would > affect performance AND we had no idea which was processing had the most > overhead for changes, the only proper choice was to do things > generically. We also knew in practice that the hardware guys were going > to tinker with the hardware and they might even reverse the overhead in > a new hardware version. However, this admittedly takes us into a grey > area of what we "know" and what the implied requirements are. In this > situation I think the generic approach was proper, but Iwonder if there > might be much mushier situations where things would not be so clear. Since you requested it, lets separate the two issues: 1) Is it possible (theoretically or otherwise) to create an OOA model that is completely independent of architecture, and 2) Should an OOA model be independent of architecture? First, number 2: For me, it is not a question of good or bad, rather is it necessary. Taken to an extreme, to create an OOA model that is independent (assuming answer to 1 is yes), when the intent is to throw it away, and if it doesn't run by the end of the week for the prospective client I lose my job, then that is bad. Obviously, that is a silly example, yet I want to emphasize that degree of independence should be determined by circumstances, not some arbitrary definition of good models verses bad ones. As for number 1, my experience is that even in models that you would consider independent (I am assuming that is a pretty high standard), there exists a wonderful, and dare I say beautiful, symbiosis between the OOA model and the architecture. For example, at a very basic level, we define base types (integer, float, string, id, etc...) that the architecture agrees to support implicitly. The simple OOA modeling act of adding two integers together has dependence on the architecture to support this function. We do not (usually) have to model in our action language the bit manipulation required to achieve this addition. One could argue that these are the types defined by the formalism, we need no more and no less. And so long as we stick to only these types, OOA models can remain forever independent from architectures. I see this line as a moving boundary, which just happened to be captured in a snapshot when the case vendors decided on their RD environments. Some support more types than others. Why were these types chosen, and not some other set? My answer would be that these were the most common, and the most straightforward, for which to provide architecture support. Why not POSITION types, which are used in many systems these days that employ some GPS technology domain. Or what about IMAGE types, for the growing number of applications that track graphics, and need to perform functions like MERGE (Image1, Image2) return New Image. Why are these types not chosen for implicit architecture support? I argue that at some point in the not too distant future, they will be as commonly supported implicitly by architectures as Integer and Boolean are today, and when that happens, the OOA models which implicitly reference those types will be dependent on the architectures that support them. Most of us are so used to thinking about Integer and String types as so inherent to software development, that we forget there was a time when some of them were new, or not yet explicitly supported by compilers. So, OOA models can never be, even theoretically, independent from architectures. They are two sides of the same coin. Without one, the other makes no sense. -- ----------------------------------------------- Mike Frankel Director of Software Engineering Esprit Systems Consulting, Inc. 610-436-8290 fax 610-436-9848 mfrankel@EspritInc.com http://www.EspritInc.com -->BASELINE Domain Models -->Object Methods Training and Consulting -->Structured Methods Training and Consulting "Strategies for Computer and Human Systems" ----------------------------------------------- Subject: Re: (SMU) Architecture independence lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Frankel... > Since you requested it, lets separate the two issues: > > 1) Is it possible (theoretically or otherwise) to create an OOA model > that is completely independent of architecture, and > > 2) Should an OOA model be independent of architecture? > > First, number 2: For me, it is not a question of good or bad, rather > is it necessary. > Taken to an extreme, to create an OOA model that is independent > (assuming answer to > 1 is yes), when the intent is to throw it away, and if it doesn't run > by the > end of the week for the prospective client I lose my job, then that is > bad. Obviously, > that is a silly example, yet I want to emphasize that degree of > independence should > be determined by circumstances, not some arbitrary definition of good > models verses > bad ones. But if it costs nothing (i.e., it takes no extra time to do an architecturally independent OOA than a dependent one), why would this be an issue? My point was that S-M is designed to provide architectural independence in the OOA (i.e., it comes for free if the methodology is applied properly). In addition, it *appears* that there may be no extra work because when one does allow architecture to creep into the OOA one can make a case for incorrect modeling based upon the requirements rather than architectural independence (i.e., architectural dependence is a symptom of the real problem problem). > As for number 1, my experience is that even in models that you would > consider independent (I am assuming that is a pretty high standard), > there exists > a wonderful, and dare I say beautiful, symbiosis between the OOA model > and > the architecture. > > For example, at a very basic level, we define base types (integer, > float, string, id, etc...) > that the architecture agrees to support implicitly. The simple OOA > modeling act of > adding two integers together has dependence on the architecture to > support this function. > We do not (usually) have to model in our action language the bit > manipulation required to > achieve this addition. These types are implementation issues that are tool-dependent, particularly when one uses an action language instead of an ADFD in the OOA. In my view this is the crucial argument for using ADFDs over action languages; it is very difficult to avoid implementation level typing in an action language. The methodology merely defines an attribute as an atomic characteristic. It is up to the RD to determine how that characteristic is expressed. > Why not POSITION types, which are used in many systems these days that > employ some > GPS technology domain. Or what about IMAGE types, for the growing > number of applications > that track graphics, and need to perform functions like MERGE (Image1, > Image2) return New Image. > Why are these types not chosen for implicit architecture support? Whether one can have an attribute for, say, an Image depends upon the level of abstraction of the domain. If the all the domain needs to do is keep track of it, then an Image might be a valid attribute because at the domain's level of abstraction the Image is atomic. However, when the Image is processed by the architecture or by another domain it cannot be an attribute because that processing cares about pixels and other characteristics. Typically the way this is handled is that the domain that merely has to keep track of it has an attribute somewhere called Image whose domain is described as something like, "handle to a standard GIF image". That domain knows nothing about GIF formats (or handles for that matter) and does not process the data in any way other than to pass it to realized code (the architecture) or another domain. If that image is passed to another domain (e.g., the UI domain), then that domain may have to have a more detailed representation of an image at a slightly lower level of abstraction that knows about Height, Width, etc. In this case the bridge (an architectural element) will have to have realized code to update those elements in UI domain from the image handle. (Note that the UI domain probably does not know about individual image pixels; it will know about a Bitmap and will pass that as is to some window manager function in the architecture that does care about individual pixels.) > So, OOA models can never be, even theoretically, independent from > architectures. They are two sides of the same coin. Without one, the > other makes no sense. > For the reasons above, I don't agree that your typing example demonstrates this assertion. The real issue is the level of abstraction for the subject matter of the domain (a favorite topic of Peter Fontana's). At high levels of abstraction almost anything can be an attribute because it will be relatively atomic at that level. As soon as the level of abstraction is reduced (e.g., typically in moving down the domain chart through the implementation domains) previously aggregated attributes must be disassembled into the atomic attributes appropriate for that level of abstraction. Eventually one gets to the architecture where things like 32-bit integers are relevant, but at any higher level of abstraction the domain of an attribute is simply are arbitrary characteristic definition. Subject: (SMU) error handling on bridges Michael.French@cambridge.simoco.com (Michael S. French x5246) writes to shlaer-mellor-users: -------------------------------------------------------------------- I am looking for information on error handling responses for inter-domain comms (bridges). I am just trying to formulate our approach to this area and wondered if anyone has addressed this problem before. Specifically once a bridge has been called if there has been an error in the interpretation of the data (or some such) what would you expect happen. The calling domain may have no notion of an error being returned. If the error is logged but no preventative action taken, the calling domain may be awaiting some form of response. This could go on add infinitum, until say the number of waiting instances crashes the system. Clearly some form of error handling policy needs to be defined and I am looking for a start along this line. thanks mike french Subject: Re: (SMU) error handling on bridges Carolyn Duby writes to shlaer-mellor-users: -------------------------------------------------------------------- > > Michael.French@cambridge.simoco.com (Michael S. French x5246) writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Specifically once a bridge has been called if there has been an error in > the interpretation of the data (or some such) what would you expect happen. > The calling domain may have no notion of an error being returned. The service domain in this example is between a rock and a hard place. If the server sends back a response as if everything was ok, the client domain will go on with its behavior. This might have disasterous results, especially if your service domain is controlling hardware. If the server does not send a response, the client will just sit and wait forever or until it times out. > Clearly some form of error handling policy needs to be defined and I am looking > for a start along this line. Here is the strategy that we use for handling errors across domain boundaries. Each service of the server domain that could fail should take two additional parameters. One parameter tells the server domain how to respond after success and the other tells the server domain how to respond after failure. Architecturally, each parameter is an instance of an event that has not been entered in the event queue. The client object creates the event instances when it calls the service. The client object fills in the identifer event data of each event instance. Finally the client, passes the event instances to the server. The server merely performs the desired service and enqueues the proper response event depending on the success or failure of the service. We call this method of bridging Indirect Events. The main advantage of Indirect Events is the server domain can be reused by many different clients without any changes. Indirect Events are a flexible, general-purpose mechanism for communicating across domain boundaries. Carolyn -- ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Carolyn Duby voice: +01 508-384-1392| carolynd@pathfindersol.com fax: +01 508-384-7906| ____________________________________________________| Subject: Re: (SMU) Architecture independence Mike Frankel writes to shlaer-mellor-users: -------------------------------------------------------------------- lahman wrote: > > But if it costs nothing (i.e., it takes no extra time to do an > architecturally independent OOA than a dependent one), why would this be > an issue? That is quite an impressive feat. If you are saying that it takes no extra time to make an OOA model architecturally independent than it does to make it dependent, the the OOA models must be equal, and then dependence equals independence. It must *always* take *some* time to do the extra work required to make it independent. And in most cases I think the extra work, and time, is warranted because of the long term reuse benefits. My point was that S-M is designed to provide architectural > independence in the OOA (i.e., it comes for free if the methodology is > applied properly). In addition, it *appears* that there may be no extra > work because when one does allow architecture to creep into the OOA one > can make a case for incorrect modeling based upon the requirements > rather than architectural independence (i.e., architectural dependence > is a symptom of the real problem problem). Do models have to be only good or bad, correct or incorrect, black or white? Why not good enough, or correct enough, or independent enough? > > > > > For example, at a very basic level, we define base types (integer, > > float, string, id, etc...) > > that the architecture agrees to support implicitly. The simple OOA > > modeling act of > > adding two integers together has dependence on the architecture to > > support this function. > > We do not (usually) have to model in our action language the bit > > manipulation required to > > achieve this addition. > > These types are implementation issues that are tool-dependent, > particularly when one uses an action language instead of an ADFD in the > OOA. In my view this is the crucial argument for using ADFDs over > action languages; it is very difficult to avoid implementation level > typing in an action language. The methodology merely defines an > attribute as an atomic characteristic. It is up to the RD to determine > how that characteristic is expressed. I don't think using an ADFD is going to eliminate the issue that an architecture, while most likely implicitly supporting integer data, may or may not support more advanced operations like square root. An OOA model referencing that operation, relying on an architecture to support it, is now dependent on architectures to continue to do so from this point forward. This is not good or bad, it simply is. > > The real issue is the level of abstraction for the subject matter of the > domain (a favorite topic of Peter Fontana's). At high levels of > abstraction almost anything can be an attribute because it will be > relatively atomic at that level. As soon as the level of abstraction is > reduced (e.g., typically in moving down the domain chart through the > implementation domains) previously aggregated attributes must be > disassembled into the atomic attributes appropriate for that level of > abstraction. Eventually one gets to the architecture where things like > 32-bit integers are relevant, but at any higher level of abstraction the > domain of an attribute is simply are arbitrary characteristic > definition. As soon as you build an OOA model which introduces a new data type, like an IMAGE type, you should expect "implicit" support for those types by the architecture. That is, because it has been characterized as a data type, by definition it requires recognition and support by the architecture domain. Now, just because the current default architectures available now in case tools don't directly support that instance of data type (in the arch OOA ), doesn't change the fact that it is inherently a requirement being levied on the architecture domain. What is usually required in the meantime, is either an augmentation of the default architecture to provide direct support, or inclusion of a makeshift service domain to handle the support for this additional type. In the latter case, it becomes an unfortunate circumstance that the architecture domain has been divided and represented in two forms: template files and an OOA model. Eventually, it will most likely be absorbed by the template files if the type is used often enough by many client domains. Regardless of the form the architecture support takes, there either exists support, or not. Any OOA model with an attribute of type IMAGE will be dependent on architectures that implicitly support that type. Only OOA models which do not have any attributes of IMAGE type will be free to choose architectures that support the more common Integer, etc... -- ----------------------------------------------- Mike Frankel Director of Software Engineering Esprit Systems Consulting, Inc. 610-436-8290 fax 610-436-9848 mfrankel@EspritInc.com http://www.EspritInc.com -->BASELINE Domain Models -->Object Methods Training and Consulting -->Structured Methods Training and Consulting "Strategies for Computer and Human Systems" ----------------------------------------------- Subject: Re: (SMU) Architecture independence Kenneth Cook writes to shlaer-mellor-users: -------------------------------------------------------------------- At 06:20 PM 10/28/97 -0500, you wrote: >Mike Frankel writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >lahman wrote: >> > >> But if it costs nothing (i.e., it takes no extra time to do an >> architecturally independent OOA than a dependent one), why would this be >> an issue? > >That is quite an impressive feat. If you are saying that it takes no >extra >time to make an OOA model architecturally independent than it does to >make it dependent, the the OOA models must be equal, and then dependence >equals >independence. It must *always* take *some* time >to do the extra work required to make it independent. I think you have it backward. I think it takes more time to make an architecture dependent model, than an independent one. Take your datatype example. If the there were no typing, you'd build a model that moved typeless data around. Once you have typing, you have to add thought as to which types to use. I'm not saying (yet) whether typing is architecture dependence, or whether models should have this or other types of architecture dependence. But, nearly by definition, I'd say it takes more time to add architecture dependence. -Ken Subject: Re: (SMU) Architecture independence Dana Simonson writes to shlaer-mellor-users: -------------------------------------------------------------------- In ref to: Kenneth Cook ... Mike Frankel ... lahman et. al. What data types are you addressing? We have both analysis (Domain) and architecture types. Both relate to our base types. Base types: Number String Boolean Enumeration Time Transfer Vector The analysis defines it types with any names the analyst chooses using these base types. For example, a Site may be a type defined as a number between 1 and 240. Age may be a number greater than 0 with a precision of 3 (3 decimal places). Name may be a string with a max length of 200. The architecture takes the analysis types and converts them into something it can represent. It may choose to make Site an int, a short or a char. To the analysis it doesn't matter. Age may be float, a double, or maybe some version of offset binary, again, it doesn't matter to the analysis. Likewise, Name could be implemented as a string class or a char array. If we were to decide to handle images, we would add a base type of Image and then allow the analyst to specify his types as particular Image types, maybe Image with a size and color depth. The architecture would then need to support the base type, translating the analysis type into something it could store (2D array, image class, bitmap, GIF, whatever...) Subject: Re: (SMU) error handling on bridges lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to French... > Clearly some form of error handling policy needs to be defined and I > am looking > for a start along this line. > We do two different things in our current system. Our core hardware driver has to be VXI Plug&Play compatible, so it has to have a synchronous C interface even though the domain internals use FSMs. We place an event on the queue and start the queue manager in the bridge call itself so that the bridge call cannot return until all events are exhausted (i.e., the queue manager startup call returns). At that time the bridge can tell whether there has been an error and return the appropriate thing to the client. In our application this works fine, but it has some potentially nasty side effects that could lead to lockups or infinite loops in certain situations. I would be very cautious in using this approach. Another approach we use when handling certain asynchronous hardware interrupts is to provide a client bridge that is effectively a callback. The service domain invokes the callback bridge if something goes awry. The callback bridge sets a status attribute in the client domain that the client domain needs to poll. The overhead might not be so bad if the polling is only done when waiting for specific, error-prone operations to complete. A variation on this theme, similar to Duby's suggestion, is for the callback bridge to simply place a different event on the queue than would be placed there as a result of succesful processing. Subject: Re: (SMU) Architecture independence lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Frankel... > That is quite an impressive feat. If you are saying that it takes no > extra time to make an OOA model architecturally independent than it > does to make it dependent, the the OOA models must be equal, and then > dependence equals independence. It must *always* take *some* time to > do the extra work required to make it independent. And in most cases > I think the extra work, and time, is warranted because of the long > term reuse benefits. No, we seem to be talking past each other here. I am saying that the methodology is designed to build an OOA in an architecturally independent manner during the normal course of development. That is, if you build an OOA according to the methodology it should be architecturally independent. I believe the issue of this thread is the assertion that this is not possible, at least without added work. My counter assertion is that it is possible and I have seen no persuasive counter example. > Do models have to be only good or bad, correct or incorrect, black or > white? Why not good enough, or correct enough, or independent enough? An assumption of S-M is that architectural dependence in an OOA is a symptom of bad modeling because the OOA is supposed to be architecturally independent. The methodology is *designed* to provide this in the normal course of problem analysis. The issue is whether there are situations where architectural independence cannot be eliminated (i.e., there is no "correct" alternative model) or that the corrective modeling requires extra work specifically to eliminate the architectural dependence (i.e., work that cannot be traced to requirements).Regarding data typing: > I don't think using an ADFD is going to eliminate the issue that an > architecture, while most likely implicitly supporting integer data, > may > or may not support more advanced operations like square root. An OOA > model referencing that operation, relying on an architecture to > support > it, is now dependent on architectures to continue to do so from this > point forward. This is not good or bad, it simply is. There is no assumption in an ADFD of implementation typing. The only place anything remotely resembling such typing enters the picture is in the description of the attributes. Ultimately this is just a text description. One can imagine a natural language translation engine that simply parsed these ASCII descriptions and somehow generated appropriate implementation types. > As soon as you build an OOA model which introduces a new data type, > like > an IMAGE type, you should expect "implicit" support for those types by > > the architecture. That is, because it has been characterized as a > data type, by definition it requires recognition and support by the > architecture domain. Now, just because the current default > architectures available now in case tools don't directly support that > instance of data type (in the arch OOA ), doesn't change the fact that > it is inherently > a requirement being levied on the architecture domain. I agree with this so long as we are clear that in the OOA IMAGE is an abstract type that does not imply any particular implementation and that the domain needs to know nothing more about it other than the fact that it is treated as an atomic entity. An architecture (or service domain) will have to be provided that does understand _some_ implementation (or lower level abstraction) of it if it is to be at all useful. > What is usually required in the meantime, is either an augmentation of > the default > architecture to provide direct support, or inclusion of a makeshift > service domain to > handle the support for this additional type. In the latter case, it > becomes > an unfortunate circumstance that the architecture domain has been > divided > and represented in two forms: template files and an OOA model. > Eventually, > it will most likely be absorbed by the template files if the type is > used > often enough by many client domains. > > Regardless of the form the architecture support takes, there either > exists > support, or not. Any OOA model with an attribute of type IMAGE will > be > dependent on architectures that implicitly support that type. Only > OOA > models which do not have any attributes of IMAGE type will be free to > choose architectures that support the more common Integer, etc... > I agree with all this, but I do not understand the point. The methodology has always specified that an architecture is application-specific. As it happens some of the core stuff that needs to be supported can be reused in multiple applications of the same general class (e.g., synchronous vs. asynchronous) -- I assume this is what you mean by a "default architecture". The architecture and translation rules define the implementation for an application. That is what RD is all about. I just do not see that the fact that all this stuff needs to be defined in the implementation of a particular application has anything to do with the fact that the OOA is independent of whatever implementation -- from among several alternatives -- that one may choose. Since the OOA does not define it, then the RD must. Subject: Re: (SMU) Architecture independence "Stephen R. Tockey" writes to shlaer-mellor-users: -------------------------------------------------------------------- > lahman writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Actually I was responding to the statement that "'mainstream' OOD can be > incredibly rigorous". I don't think that it is for the reason I gave. While I certainly agree with you that (as it is widely practiced) MSOO is not rigorous, there's nothing that really *prevents* it from being rigorous. Let me rephrase that a bit: there's nothing *technical* preventing it. Culturally, yes. Technically, no. But this is not a big deal so I'll cut it off here. There's much more interesting things to discuss, below. > But while we are on the subject of orthogonality between OOA rigor and > architectural dependence, I am not convinced that they are orthogonal > _in the S-M context_. In general, I agree. However, there is a causal > relationship between OOA and RD. I would argue that an OOA cannot be > architecturally independent of the RD unless it is rigorous; anything > else would be serendipity, at best. Ok. > Put another way, I would argue the following possibilities in practice: > > A independent and rigorous -- always true for S-M and usually for ROOM > by intent > A independent and ~rigorous -- many snowballs melt below; correlated > with sunspots > A dependent and rigorous -- but was it good for you? > A dependent and ~rigorous -- the easy, mainstream way -- a million > lemmings can't be wrong (a great quote from Bertrand Meyer that I have > been waiting to use). Hmmm. Maybe we have differing definitions of architectural independence? I don't think there's any disagreement that OOA/RD is rigorous, however personally I don't think (as practiced) it is as architecturally independent as it *could* be. Again, don't get me wrong. I think there's nothing out there in the "COTS methods marketplace" that even comes close to OOA/RD. I'm just saying that per my understanding of the term there's still some room for improvement. > I would agree that I probably would not bring S-M to bear on a 200 SLOC, > one-shot, personal program -- but for different reasons. There is a > fixed overhead in applying the methodology that would not be worth the > price. However, make that 20L SLOC in the same circumstances and I > would use S-M. I would use S-M for three reasons. First, it is closely > aligned with defect prevention by forcing one to think about things > earlier. Second, it will cut down the test & debug time. Third, if it > is that large I will almost certainly have to modify it at some point > and that will be a lot easier to do. All of these things indirectly > derive from the rigor that I believe is an asset. I strongly agree with your three reasons. But as you point out (and I also agree), there is the overhead associated with the rigor. I see it as a benefit/cost issue. At 200 SLOC, the cost overhead dominates the benefit. At 20K SLOC, the benefit dominates the cost. Where's the break-even point (equal benefit/cost of either alternative)? I don't know. Without good data it would be a matter of personal taste anyway. But my point here is that when to use or not use OOA/RD should be an *engineering* decision (i.e., based on the level of investment required and the return on that investment). Blanket statements such as "OOA/RD is always good" always cause me to try to come up with a counter-example. > I believe architectural independence comes for free with S-M once you > decide to use it; it is a cornerstone of the methodology. If you let > the architecture creep into the OOA you risk developing bad habits that > might be difficult to lose when you can't afford them. To me, architectural independence is a mindset. You simply have to establish criteria that filter architecturally dependent stuff from -independent stuff then deal with it appropriately. There is some cost involved in making it happen (applying the filter criteria) but that cost is really minute in comparison to the benefit. Reiterating what I said above and what I was really trying to point out in my original response to Tim Wadsworth, I think the real interesting discussion is not whether OOA/RD is rigorous or not, or whether it is architecturally independent or not. My feeling is that the infinitely more interesting discussion would be on the different criteria that people use to decide whether a particular system detail (e.g., a particular requirement) is architecturally independent or not. Cheers, -- steve Subject: Re: (SMU) error handling on bridges Sally Shlaer writes to shlaer-mellor-users: -------------------------------------------------------------------- Hi, Carolyn! Good to see you here. :-) Just a note on terminology: what Carolyn describes as an Indirect Event is known in RD as a transfer vector. You can read more about it in the Bridges and Wormholes article on the PT website (www.projtech.com). Best to all, Sally At 05:11 PM 10/28/97 -0500, >Carolyn Duby writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >Here is the strategy that we use for handling errors across >domain boundaries. Each service of the server domain that >could fail should take two additional parameters. One parameter >tells the server domain how to respond after success and the other >tells the server domain how to respond after failure. > >Architecturally, each parameter is an instance >of an event that has not been entered in the event queue. >The client object creates the event instances when it calls the >service. The client object fills in the identifer event data >of each event instance. Finally the client, passes the >event instances to the server. The server merely performs >the desired service and enqueues the proper response event >depending on the success or failure of the service. We call >this method of bridging Indirect Events. The main advantage >of Indirect Events is the server domain can be reused by many >different clients without any changes. Indirect Events are a >flexible, general-purpose mechanism for communicating >across domain boundaries. > >Carolyn >-- Subject: (SMU) Re: error handling on bridges Jon Monroe writes to shlaer-mellor-users: -------------------------------------------------------------------- Michael French wites: > I am looking for information on error handling responses for inter-domain > comms (bridges). I am just trying to formulate our approach to this area > and wondered if anyone has addressed this problem before. > Specifically once a bridge has been called if there has been an error in > the interpretation of the data (or some such) what would you expect happen. > The calling domain may have no notion of an error being returned. If the > error is logged but no preventative action taken, the calling domain may be > awaiting some form of response. This could go on add infinitum, until say > the number of waiting instances crashes the system. > Clearly some form of error handling policy needs to be defined and I am > looking for a start along this line. You might want to check out the Kennedy-Carter's "OOA 97" paper on their web site (www.kc.com). They propose extensions to the method for exception handling. To summarize, I think it goes something like this: A client domain invokes a bridge service in a service domain. If the service domain can not successfully carry out the service, it raises an exception. This causes an exception handler to be called in the client domain, within the scope of the instance which invoked the bridge service. It is up to the analyst of the client domain to define the behavior of the exception handlers (recovery, notifications, etc.). Clearly, there are some cases when this approach is useful, and other times when you just want to pass back a status code or a different event. I would be interested in hearing the experience of anyone who tried to use exception handling on a large scale basis. Jonathan Monroe Abbott Laboratories - Diagnostics Division North Chicago, IL monroej@ema.abbott.com Subject: Re: (SMU) Architecture independence Mike Frankel writes to shlaer-mellor-users: -------------------------------------------------------------------- Dana Simonson wrote: > > Dana Simonson writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > In ref to: Kenneth Cook ... Mike Frankel ... > lahman et. al. > > What data types are you addressing? We have > both analysis (Domain) and architecture > types. Both relate to our base types. > > Base types: > Number > String > Boolean > Enumeration > Time > Transfer Vector > Your list above, minus the Transfer Vector which is not an OOA attribute type, and splitting Number into Integer vs. Real, would be the list of base types that most case vendors, or in-house architectures, implicitly support. Our OOA techniques also employ Event Vectors (similar to pathfinder's indirect event, but also providing for dynamic event parameter derivation at the time of queuing), and Attribute Vectors (an attribute access address into a client domain), both of which can also be used as OOA domain attribute types. OOA models which use these latter types, are dependent on architectures that support them. > The analysis defines it types with any names > the analyst chooses using these base types. > For example, a Site may be a type defined as > a number between 1 and 240. Age may be a > number greater than 0 with a precision of 3 > (3 decimal places). Name may be a string > with a max length of 200. The implicit support by the architecture is for the base types, while the analyst may subtype them as well to add range constraints, which the architecture may or may not use in the code production. > > The architecture takes the analysis types > and converts them into something it can > represent. It may choose to make Site an > int, a short or a char. To the analysis it > doesn't matter. Age may be float, a > double, or maybe some version of offset > binary, again, it doesn't matter to the > analysis. Likewise, Name could be > implemented as a string class or a char > array. This is precisely what the "support" is: the ability to recognize the type name and convert it into the appropriate environment language type. > > If we were to decide to handle images, we > would add a base type of Image and then > allow the analyst to specify his types as > particular Image types, maybe Image with a > size and color depth. The architecture > would then need to support the base type, > translating the analysis type into something > it could store (2D array, image class, > bitmap, GIF, whatever...) Exactly. And not supporting an IMAGE type at all would restrict the OOA model from having attributes of that type (one form of dependence), or force it to find another architecture which does support it (another form of dependence). -- ----------------------------------------------- Mike Frankel Director of Software Engineering Esprit Systems Consulting, Inc. 610-436-8290 fax 610-436-9848 mfrankel@EspritInc.com http://www.EspritInc.com -->BASELINE Domain Models -->Object Methods Training and Consulting -->Structured Methods Training and Consulting "Strategies for Computer and Human Systems" ----------------------------------------------- Subject: Re: (SMU) Architecture independence Mike Frankel writes to shlaer-mellor-users: -------------------------------------------------------------------- Dana Simonson wrote: > > Dana Simonson writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > In ref to: Kenneth Cook ... Mike Frankel ... > lahman et. al. > > What data types are you addressing? We have > both analysis (Domain) and architecture > types. Both relate to our base types. > > Base types: > Number > String > Boolean > Enumeration > Time > Transfer Vector > Your list above, minus the Transfer Vector which is not an OOA attribute type, and splitting Number into Integer vs. Real, would be the list of base types that most case vendors, or in-house architectures, implicitly support. Our OOA techniques also employ Event Vectors (similar to pathfinder's indirect event, but also providing for dynamic event parameter derivation at the time of queuing), and Attribute Vectors (an attribute access address into a client domain), both of which can also be used as OOA domain attribute types. OOA models which use these latter types, are dependent on architectures that support them. > The analysis defines it types with any names > the analyst chooses using these base types. > For example, a Site may be a type defined as > a number between 1 and 240. Age may be a > number greater than 0 with a precision of 3 > (3 decimal places). Name may be a string > with a max length of 200. The implicit support by the architecture is for the base types, while the analyst may subtype them as well to add range constraints, which the architecture may or may not use in the code production. > > The architecture takes the analysis types > and converts them into something it can > represent. It may choose to make Site an > int, a short or a char. To the analysis it > doesn't matter. Age may be float, a > double, or maybe some version of offset > binary, again, it doesn't matter to the > analysis. Likewise, Name could be > implemented as a string class or a char > array. This is precisely what the "support" is: the ability to recognize the type name and convert it into the appropriate environment language type. > > If we were to decide to handle images, we > would add a base type of Image and then > allow the analyst to specify his types as > particular Image types, maybe Image with a > size and color depth. The architecture > would then need to support the base type, > translating the analysis type into something > it could store (2D array, image class, > bitmap, GIF, whatever...) Exactly. And not supporting an IMAGE type at all would restrict the OOA model from having attributes of that type (one form of dependence), or force it to find another architecture which does support it (another form of dependence). -- ----------------------------------------------- Mike Frankel Director of Software Engineering Esprit Systems Consulting, Inc. 610-436-8290 fax 610-436-9848 mfrankel@EspritInc.com http://www.EspritInc.com -->BASELINE Domain Models -->Object Methods Training and Consulting -->Structured Methods Training and Consulting "Strategies for Computer and Human Systems" ----------------------------------------------- Subject: (SMU) >>> Mike Frankel 10/29/97 11:31am Dana Simonson writes to shlaer-mellor-users: -------------------------------------------------------------------- >>> Mike Frankel 10/29/97 11:31am >>> >Your list above, minus the Transfer Vector which is not an OOA >attribute type I beg to differ, see page 3 of the "Bridges and Wormholes" paper (avail. form Project Technologies Web site) which effectively defines the transfer vector as the OOA representation of a 'return address' for a wormhole. It does not imply how an architecture will implement the underlying mechinism, it only allows the analysis the ability to pass and store it for later use. > Attribute Vectors (an attribute access address into a client > domain) I believe direct access of attributes was disallowed under the bridges and wormholes / OOA96 view of the method. To get attributes from a different domain a wormhole must be created. >This is precisely what the "support" is: the ability to recognize >the type name and convert it into the appropriate environment >language type. Please define the difference between translating type information and translating processes. When I put a read accessor on a model, I expect the architecture to know how to perform the read function. I cannot use an architecture which does not support read accessors. Yes, they are therefore dependent since I cannot use an architecture to generate code without the existance of an analysis or vice versa. Subject: Re: (SMU) >>> Mike Frankel 10/29/97 kearnan@Summa4.COM (Gregg Kearnan) writes to shlaer-mellor-users: -------------------------------------------------------------------- Subject: Re: (SMU) >>> Mike Frankel 10/29/97 Mike Frankel writes to shlaer-mellor-users: -------------------------------------------------------------------- Dana Simonson wrote: > > Dana Simonson writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > >>> Mike Frankel 10/29/97 11:31am >>> > > >Your list above, minus the Transfer Vector which is not an OOA > >attribute type > > I beg to differ, see page 3 of the "Bridges and Wormholes" paper > (avail. form Project Technologies Web site) which effectively defines > the transfer vector as the OOA representation of a 'return address' > for a wormhole. It does not imply how an architecture will implement > the underlying mechinism, it only allows the analysis the ability to > pass and store it for later use. My recollection from reading the paper many months ago was that the transfer vector was an addition to the OOA model made at bridging time. After reading Sally's comment in another thread that the transfer vector is the same as pathfinder's indirect event, which I know is the same as esprit's event vector, I reread the paper. Although the transfer vector value is shown as data being manipulated in an ADFD of the service domain, there is no example showing the transfer vector as an essential OOA attribute of the Request Monitor object. However, that may in fact be the intention. > > > Attribute Vectors (an attribute access address into a client > > domain) > > I believe direct access of attributes was disallowed under the > bridges and wormholes / OOA96 view of the method. To get attributes > from a different domain a wormhole must be created. OOA96 has not yet been adopted as the industry standard. The closest subset of a common standard is probably a lot closer to OOA91 + self-directed events and a few other handy improvements. Our practice of OOA/RD does not include wormholes (syntactically), because of two reasons: 1) In a client domain, wormholes represent an "intent to bridge", which we consider to be a form of domain pollution. An OOA model is reusable across projects or industries only when it does not contain information that reflects a particular bridging link used on a particular project. Since we expect that the entire OOA model will be translated into code through the architecture, and/or through substitution or injection mapping bridges to service domains, we find no need whatsoever to indicate in the OOA model itself that we have an "intent to bridge". The bridge specification, as a project-specific document distinct from the OOA models, enumerates all inter-domain links. 2) In a service domain, we simply include event vectors and attribute vectors as normal OOA attributes which are processed, using the wonderfully capable notation and semantics discussed in OOA91. Since these are new data types, we expect the architecture will support their data structure and any defined action language operations on those types. We accomplish the same semantic goal: transfer of control between domains, but we use the original notation to do it. > > >This is precisely what the "support" is: the ability to recognize > >the type name and convert it into the appropriate environment > >language type. > > Please define the difference between translating type information and > translating processes. When I put a read accessor on a model, I > expect the architecture to know how to perform the read function. I > cannot use an architecture which does not support read accessors. > Yes, they are therefore dependent since I cannot use an architecture > to generate code without the existance of an analysis or vice versa. >From a dependence point of view, there is no difference. Your comment is exactly what I meant. There is dependence in many areas of an OOA model on an architecture. I was just using data types as an example of one such dependence. -- ----------------------------------------------- Mike Frankel Director of Software Engineering Esprit Systems Consulting, Inc. 610-436-8290 fax 610-436-9848 mfrankel@EspritInc.com http://www.EspritInc.com -->BASELINE Domain Models -->Object Methods Training and Consulting -->Structured Methods Training and Consulting "Strategies for Computer and Human Systems" ----------------------------------------------- Subject: Re: (SMU) >>> Mike Frankel 10/29/97 kearnan@Summa4.COM (Gregg Kearnan) writes to shlaer-mellor-users: -------------------------------------------------------------------- Sorry about the incomplete reply to this message earlier, slip of the mouse;) > > Dana Simonson writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > >>> Mike Frankel 10/29/97 11:31am >>> > > >Your list above, minus the Transfer Vector which is not an OOA > >attribute type > > I beg to differ, see page 3 of the "Bridges and Wormholes" paper > (avail. form Project Technologies Web site) which effectively defines > the transfer vector as the OOA representation of a 'return address' > for a wormhole. It does not imply how an architecture will implement > the underlying mechinism, it only allows the analysis the ability to > pass and store it for later use. > > One of the things about the transfer vector concept which was left undefined in "Bridges and Wormholes" was how one creates a transfer vector and how one replies using a transfer vector. I could imagine replying by using an ADFD process that is similar to event generation. How is a transfer vector created, and how does one define the response of the domain which created it? If these are left undefined by the method, they will have to be defined by the tool vendors, or worse, by the architect who has to support them. While normal data types do not tend to be architecturally dependent, data types which ultimately have a life of their own as analysis constructs must be defined with the same rigor as events in SMOOA. Unless I didn't read "Bridges and Wormholes" well enough, transfer vectors seem to be a less than adequately defined analysis construct. Question for the group: Are the tools you are using supporting transfer vectors, or have you developed your own scheme for implementing them? Subject: Re: (SMU) transfer vector support peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 06:07 PM 10/29/97 -0500, shlaer-mellor-users@projtech.com wrote: >kearnan@Summa4.COM (Gregg Kearnan) writes to shlaer-mellor-users: > ... >Question for the group: Are the tools you are using supporting >transfer vectors, or have you developed your own scheme for implementing >them? As Sally indicated earlier, we provide transfer vector capability via our Indirect Event, which is fully supported by our translation, checking and verification support, and an integral part of our architecture family. ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice: +01 508-384-1392 | peterf@pathfindersol.com fax: +01 508-384-7906 | ____________________________________________________| Subject: Re: (SMU) Architecture independence lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Simonson... > What data types are you addressing? We have > both analysis (Domain) and architecture > types. Both relate to our base types. > > Base types: > Number > String > Boolean > Enumeration > Time > Transfer Vector In OOSA:MWD (pg 38-39) the domains of attributes are defined in a highly abstract and basically descriptive manner. The only one from your list directly supported there is Enumeration, which is already an abstraction that happens to have an obvious implementation. The Transfer Vector abstraction was added by the Wormholes Paper. One can make a case implicitly for Number through the explicit support of the abstract Range. But String, Boolean, and Time do not seem to be represented. At another level, one can arbitrarily assign any description for the domain of an attribute (e.g., citations and acceptance rules are can be arbitrary) and it is convenient to use a shorthand "type" for this descriptive information. At this level Boolean and String are reasonable abstractions. However, the point I was making earlier in the thread is that this "type" is nothing more than a placeholder for a particular description that will have to be resolved during translation into a specific implementation, typically by making an informed choice from among alternative implementations -- the process described in the remainder of your message. This branch of the thread arose because of the assertion that types like Integer and String that appear in the OOA demonstrated architectural dependence. My argument was that they are artifacts of action languages and they don't belong in the OOA for the reasons above. More precisely, they need to be properly interpreted as conceptual placeholders rather than implementations. We use an action language but we disguise the Integers, etc. provided with the action language with our own conceptual types, such as Seconds, Voltage, and whatnot so that there is no confusion about the level of abstraction with which we are dealing. Subject: Re: (SMU) Architecture independence lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Tockey... > While I certainly agree with you that (as it is widely practiced) MSOO > > is not rigorous, there's nothing that really *prevents* it from being > rigorous. Let me rephrase that a bit: there's nothing *technical* > preventing > it. Culturally, yes. Technically, no. But this is not a big deal so > I'll > cut it off here. There's much more interesting things to discuss, > below. I just believe that if an analyst does use MSOO in a rigorous way, that analyst is bringing more to the table than MSOO provides. Those rules the analyst unilaterally imposes provide the rigor, not MSOO. > Hmmm. Maybe we have differing definitions of architectural > independence? > I don't think there's any disagreement that OOA/RD is rigorous, > however > personally I don't think (as practiced) it is as architecturally > independent > as it *could* be. I agree with that. Though OOA/RD is more rigorous than MSOO there are still lots of ways to go wrong. I would even agree that it is relatively easy to sneak implementation into the OOA and that it takes a fair amount of experience to avoid doing so. The only thing I am arguing against in this thread is the assertion that there are situations where is is _unavoidable_ to bring implementation into the OOA. > Blanket statements such as "OOA/RD is always good" always cause me to > try to come up with a counter-example. I think Steve and Sally have been very up front about situations where OOA/RD may not be appropriate. I happen to think it can be used in some of the situations where they don't, but I also agree that a lot of code gets written in a project that does not appear in ADFDs or the action language. We have a couple of domains where only the IM is done to define the data structures and the code is written, essentially procedurally, directly from there. > To me, architectural independence is a mindset. You simply have to > establish criteria that filter architecturally dependent stuff from > -independent stuff then deal with it appropriately. There is some cost > > involved in making it happen (applying the filter criteria) but that > cost is really minute in comparison to the benefit. > > Reiterating what I said above and what I was really trying to point > out > in my original response to Tim Wadsworth, I think the real interesting > > discussion is not whether OOA/RD is rigorous or not, or whether it is > architecturally independent or not. My feeling is that the infinitely > more interesting discussion would be on the different criteria that > people > use to decide whether a particular system detail (e.g., a particular > requirement) is architecturally independent or not. I guess this is a source of our difference. I contend that the methodology is geared to produce an architecturally independent OOA during the normal course of development of the OOA. That is, the independence should for free as an expected byproduct of the analysis process. To the extent that it is possible in practice to let implementation creep into the OOA in subtle ways, I would agree that one needs a mindset forged upon experience to avoid this. Subject: (SMU) Responding to: Dana Simonson writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to: >>> lahman 10/30/97 08:02am >>> lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- >This branch of the thread arose because of the assertion that types >like Integer and String that appear in the OOA demonstrated >architectural dependence. My argument was that they are artifacts >of action languages and they don't belong in the OOA for the reasons >above. More precisely, they need to be properly interpreted as >conceptual placeholders rather than implementations. We use an >action language but we disguise the Integers, etc. provided with the >action language with our own conceptual types, such as Seconds, >Voltage, and whatnot so that there is no confusion about the level >of abstraction with which we are dealing. Simply for explanation, we do direct translation from models to code. Since there is no action language or other manual intervention, the models must specify all needed information. The use of domain types, defined as constrained base types, allows us to specify the attribute type in a manner which can be parsed directly by the translator without allowing the analysis to specify the architectural type. This type assigned as part of the attribute definition (description + type) is limited to one of these domain types. (You can add as many domain types as needed.) Since the analysis works only with Voltage, which the architecture may represent as an int, I feel we are meeting the intent of the methodology for isolation between analysis and implementation. I believe both of our methods strive to achieve the same end via different routes. By the way, our implementation of Transfer Vector as a base type is also driven by the direct translation approach. It was necessary to implement the asynchronous wormhole interface. Subject: Re: (SMU) >>> Mike Frankel 10/29/97 lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Kearnan... > One of the things about the transfer vector concept which was left > undefined in the "Bridges and Wornholes" was how one creates a > transfer vector and how one replies using a transfer vector. I could > imagine replying by using an ADFD process that is similar to event > generation. > > How is a transfer vector created, and how does one define the response > > of the domain which created it? If these are left undefined by the > method, they will have to be defined by the tool vendors, or worse, > by the architect who has to support them. I believe the definition you seek was left out intentionally because it is strongly dependent upon the computing environment. All they are saying is that the service domain has to store the transfer vector and provide services so that a response can be properly addressed. Architecturally this can be done in a variety of ways. The synchronous service portion of the bridge in the service domain will understand the chosen mechanism for that domain and Do The Right Thing with the incoming transfer vector. Similarly, it is up to the architecture of that service domain to keep track of the responses and access the correct stored transfer vector for the outgoing event. I think these are all issues for the architecture of that particular service domain. Note that the receiving domain does not have to know the semantics of the transfer vector; only the client domain that issued it needs to understand it. When the receiving domain responds, it merely pastes the transfer vector it stored onto the response and lets the client worry about interpreting it. At another level, the bridge itself needs to know something of the semantics of the transfer vector (e.g., to allow proper storage one needs to know the size or to address the proper domain the bridge might need an embedded IP address). However, this is true to some extent of all bridges and I don't see anything here that requires special definition for transfer vectors vs. other data packets -- especially to a "normal" bridge that has to deal with what Whipp elegantly refers to as a "protocol shift" as well as syntactic shifts. On the create side the domain needs to have a mechanism for recognizing certain responses that it issues require particular actions in the domain. The synchronous service that issues the event creates some arbitrary transfer vector that identifies the particular action to take when the response to that event comes back. Again, there are lots of ways to do this and the architecture for that domain is free to select the most appropriate one for its environment. It just needs to be able to Do The Right Thing when an event comes in with a particular transfer vector pasted on it. Note that no storage of transfer vectors is _required_ on the create side; one could, for example, use odd/even numbers as transfer vectors and generate one event for even numbers returned and a different one for odd ones returned. In practice the architectural solution for a given domain is going to be more complicated because it will be more efficient to store additional information with the transfer vector and whatnot. However, these complexities will be very dependent upon the particular environment. So I agree in general with keeping the mechanism as generic and abstract as possible at the OOA level. While individual vendors may come up with their own OTS architectures that handle transfer vectors differently, the same OOA should be usable with them all. It would be nice if there was some standardization among architectures to eliminate some manual drudgery in writing bridges, but I think this is a different level than the OOA formalism. I have the impression that you are looking for some standardized format for the incoming transfer vector that all domains' architectures could count upon. But, I think this is difficult to do without placing too many restrictions on bridging. Bridges are supposed to iron out syntactic differences (e.g., sending millivolts and expecting microvolts), which is why they are generally regarded as an application-specific part of the architecture. For example, the format of the transfer vector may be quite different for CORBA or DCOM communications. Having said all this, I do have one problem with the specification thus far. Suppose I have a domain that receives three events and must respond with different data to each event. Also assume that the data returned is determined by activities at the OOA level (e.g., particular events are processed). In this case when a particular packet of data is ready the OOA needs to invoke a wormhole to send the data back in response to a particular event. How does one indicate to the wormhole which event the data packet goes with? My problem is that the wormhole needs some criteria to use to find the correct transfer vector to paste onto the outgoing response and that element needs to be specified in the OOA as the wormhole is invoked. I *think* the way this is supposed to work is that the architecture establishes its own, arbitrary id for the transfer vector and that is passed into the domain via the incoming wormhole. The OOA keeps track of that abstract identifier and passes it back to the outgoing wormhole (along with the relevant data packet) so that the architecture can find the right transfer vector to paste onto the outgoing event that returns the data to the client. The thing that bothers me about this is the vagueness associated with knowing whether a wormhole requires this magic id or not. It seems to me that the OOA should have some formalism around the types of wormholes, similar to that associated with different types of create accessors. Subject: (SMU) Safety Requirements and OOA/OOD bberg@techreps.com (Bryan K. Berg) writes to shlaer-mellor-users: -------------------------------------------------------------------- TWIMC I am an IV&V contractor working in the arena of nuclear weapon safety...As a part of this process we specify in government documents (Air Force Manuals and Instructions) the requirements to be placed upon software to be used in controlling the nuclear weapon..Previously, our documents were written strictly by people who had very little knowledge of software and what knowledge they possessed was not in an OOA/OOD arena......Consequently, a lot of our requirements were not applicable to an OOA/OOD..We are now in the process of rewriting our requirements and I am asking fellow S-M users/analysts to provide me with their input...Any input from Sally or Steve would be especially appreciated.....I can be contacted either through the users group or directly.....Thanks and Cheers Bryan K. Berg Senior Engineer Tech Reps Inc bberg@techreps.com Subject: (SMU) Transfer Vectors Dana Simonson writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Kearnan... > How is a transfer vector created, and how does one define the response I can't speak for PT and the Methodology, the following only reflects our implementation. >From the client side, a wormhole is invoked much like an event generator. Local data can flow into the wormhole and an event or dataflow comes out. The event can contain both local data and data received from the wormhole (specified by name in the wormhole signature). On the server side, the transfer vector is received on an inflow in the SDFD. Any name can be used as long as it's domain type is associated with the base type TRANSFER_VECTOR. This vector can be saved or sent on an event anywhere within the server domain. At some later point an Async Return process receives the transfer vector on an inflow along with any data to be returned. Management of the event generation and dispatch in the client domain is handled by the architecture. The architecture is also responsible for tracking the number of instances of the transfer vector and releasing all memory associated with it and its datasets when the last instance goes out of scope. (When all object instances in which it has been stored are deleted and all events carrying it as a parameter have been processed.) >From an OOA perspective, the server only knows that it has requested an event be thrown with a given dataset and the client only knows that someone requested something and that the transfer vector will magically get the return data where it needs to go. Subject: Re: (SMU) Transfer Vectors kearnan@Summa4.COM (Gregg Kearnan) writes to shlaer-mellor-users: -------------------------------------------------------------------- > >From the client side, a wormhole is invoked > much like an event generator. Local data > can flow into the wormhole and an event or > dataflow comes out. The event can contain > both local data and data received from the > wormhole (specified by name in the wormhole > signature). > This is the "transfer vector" create process that I was talking about. Implicit in this usage is the fact that the object to which the event is targeted will have the processing clearly defined in the OOA. You can look at the OOA and determine how the transfer vector will be handled. > On the server side, the transfer vector is > received on an inflow in the SDFD. Any name > can be used as long as it's domain type is > associated with the base type > TRANSFER_VECTOR. This vector can be saved > or sent on an event anywhere within the > server domain. At some later point an > Async Return process receives the transfer > vector on an inflow along with any data to > be returned. The Async Return process is the formal notation for a reply that I would like to see as part of the method. > > >From an OOA perspective, the server only > knows that it has requested an event be > thrown with a given dataset and the client > only knows that someone requested something > and that the transfer vector will magically > get the return data where it needs to go. > > While I won't say that indirect events should be the industry standard for transfer vectors, I would like to see the method give a formal definition of the processes needed for using transfer vectors. It sounds as if indirect events are a possible candidate. Valid OOA constructs should be rigorously defined. A tool vendor or architect may decide not to use the notation, but at least there will be a guideline so that they (hopefully) won't deviate too far from the standard. As it stands right now, it is up to the architecture to define how one creates/uses transfer vectors, making any OOA that uses them architecture dependent. 'archive.9711' -- Subject: (SMU) Events to Self Jason Capstick writes to shlaer-mellor-users: -------------------------------------------------------------------- Hi My question is does the method allow for a state to generate more than one event to self? If so how could the analysis be justified as the second event could/should be generated from the state that the first event caused the model to transition to. My belief is that there is no situation that more than one event to self in a state would be the most correct modeling of the lifecycle of the object concerned. Thanks Jas Subject: Re: (SMU) Events to Self Neil Lang writes to shlaer-mellor-users: -------------------------------------------------------------------- At 02:38 PM 11/4/97 +1200, >Jason Capstick writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >Hi > >My question is does the method allow for a state to generate more than >one event to self? The method doesn't prevent an analyst from so doing, but I can't envision a situation where one would want to do so. I have always thought of the self-directed event as a way to capture in an OOA model that upon completion of an action in a state, the state machine needs to transition (irrespective of any other posted events) to some other state and only then deal with any possible events after the transition. I can imagine implementation stategies for self directed events that bypass the regular event handling mechanism in the architecture in favor of a direct invocation of the new state's action. > >If so how could the analysis be justified as the second event >could/should be generated from the state that the first event caused the >model to transition to. > >My belief is that there is no situation that more than one event to self in a >state would be the most correct modeling of the lifecycle of the object >concerned. > I concur Neil ---------------------------------------------------------------------- Neil Lang nlang@projtech.com Project Technology, Inc. 510-567-0255 x623 10940 Bigge Street San Leandro, CA 94577 http://www.projtech.com ---------------------------------------------------------------------- Subject: Re: (SMU) Events to Self lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Capstick... > My question is does the method allow for a state to generate more than > > one event to self? Yes. > > > If so how could the analysis be justified as the second event > could/should be generated from the state that the first event caused > the > model to transition to. > > My belief is that there is no situation that more than one event to > self in a > state would be the most correct modeling of the lifecycle of the > object > concerned. > While I agree that one probably never _has_ to generate multiple events, this is not harmful (assuming OOA96) and there are practical situations where it is the natural way to do things.First, let me point out that prior to OOA96 you _had_ to use self directed events to implement a depth first iteration. ADFDs did not support a mechanism for an iteration on a set where each element of the set needed to be processed through all the steps before processing the next element (e.g., a sort). One way to do this was to have one state simply queue up N events to another state with the N-iteration body for processing a single set element. Worse, self-directed events were not given priority to block external actions from screwing up the sequence, so you had to put all the events that carried instance sets on the queue at once. Second, even after OOA96 provided a mechanism for depth-first iteration, there are still situations where the natural way to describe an iteration would be to queue up a set of self directed events. Remember that one of the rules for events is that multiple events between the same two instances must arrive in the same order that they were issued. This allows two instances, or states within the same instance, to perform an iteration that spans states. Consider the following, which combines the first two points: S1 -----------> S2 -------------> S3 E1 E3 Unfortunately my mailer uses a proportional font that won't line up so you will have to imagine an event E2 that goes from S2 back to S1. A depth-first iteration is performed between S1 and S2 which might be a E1:do_next and E2:get_next sort of thing. The problem is that S2 does not know when the iteration is done (i.e., E3 should be issued rather than E2). However, S1 may well know this (e.g., it may be doing a fixed-count iteration). Therefore S1 could generate all of the events, provided the E2 event does not carry data specific to the input E1 event. Now you could model this differently to eliminate the multiple events, especially in this simple case where one could just pass a flag on the E1 event for the end of the iteration. But I argue that in some more complex situations having S1 generate pairs of E1/E2 events with a final E1/E3 pair may be more natural. For example, if E1 could also be issued by external entities, the inclusion of that flag on the event would represent specific knowledge of an artifact of the internal processing of the FSM, which is probably bad form for the external entity. Subject: Re: (SMU) Events to Self Andrew McKinley writes to shlaer-mellor-users: -------------------------------------------------------------------- Jason Capstick wrote: > > Hi > > My question is does the method allow for a state to generate more than > one event to self? How is this different than generating more than one event to some other object instance? I don't know anyplace where it is forbidden. > > If so how could the analysis be justified as the second event > could/should be generated from the state that the first event caused the > model to transition to. Again, this issue must be dealt with when generating multiple events to other object instances. > > Thanks > Jas enjoy, andy Subject: Re: (SMU) Events to Self "John D. Yeager" writes to shlaer-mellor-users: -------------------------------------------------------------------- Andrew McKinley wrote: > > Andrew McKinley writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Jason Capstick wrote: > > > > My question is does the method allow for a state to generate more than > > one event to self? > > How is this different than generating more than one event to some other > object instance? I don't know anyplace where it is forbidden. > There are two differences between self-directed events and normal events; one is the self-directed event rule of OOA96 in which the actions precipitated by self-directed events precede any other actions of the instance generated by other events. Clearly this does not preclude an action sending multiple events to the acting instance. The other is that given the rule described above, it is reasonable for an architecture to try to send the self-directed events in a synchronous manner rather than relying on queueing. This may be acheived by directly calling the second action or by concatanating the generated code. However, this becomes problematic if multiple self-directed events are envisioned. There is a further complication I have noted before; the non-explicitly self-directed event. Consider the case where an action follows various relationships to find an instance to which it must send an event (for instance finds an object with a work item associated with a given resource and sends it an event to take control of the resource). If the target instance *happens* to be the acting instance, one typically does *not* want to require architecture to accelerate the event; this is still further complicated if the instance then sends an explicitly self-directed event. In this case, one would typically want to process the explicitly self-directed event first and then process other events, including the generically sent self-directed event. Thus a resource consumer can move to a "waiting for work" state prior to receiving the next "resource available" event. It is less clear that one would want to send multiple events to any single instance explicitly (I still need to digest Lahman's example to see if it provides the clear example of a case requiring this). Again, it is possible that one may send events to various instances which may coincidentally be the same instance based on relationships and attributes at the time. >From an analysis point of view, I would defined "explicitly self-directed" as an event which the identifier coming into the event generator is the identifier from the event which dispatched the current action and the event is generated to the same object or one of its supertypes. Coincidentally self-directed events are cases where the identifier obtained by accessors and/or transformations *happens* to be the same as the event which dispatched the current action. In the case of actions responding to creation events, a self-directed event would be one whose identifier is either the identifying attributes written to the creation process or the unique identifier returned by the creation process. Note that if multiple instances are self-created by the action, they may all receive explicitly self-directed events by this definition (which I think is desirable). -- John Yeager Cross-Product Architecture Lucent Technologies, Inc., Bell Labs johnyeager@lucent.com Business Communications Systems voice: (732) 957-3085 200 Laurel Ave, 4C-514 fax: (732) 957-4142 Middletown, NJ 07748 Subject: RE: (SMU) Safety Requirements and OOA/OOD "Lynch, Chris D. SD" writes to shlaer-mellor-users: -------------------------------------------------------------------- Bryan Berg wrote: >TWIMC > I am an IV&V contractor working in the arena of nuclear weapon >safety...As a part of this process we specify in government documents (Air >Force Manuals and Instructions) the requirements to be placed upon software >to be used in controlling the nuclear weapon..Previously, our documents were >written strictly by people who had very little knowledge of software and >what knowledge they possessed was not in an OOA/OOD arena......Consequently, >a lot of our requirements were not applicable to an OOA/OOD..We are now in >the process of rewriting our requirements and I am asking fellow S-M >users/analysts to provide me with their input You can look at safety several ways: 1. At the system level. Example requirements: * No single-point failure shall lead to ignition of the nuclear fuel. * It shall not be possible to arm the weapon through the XYZ interface without supplying the authentication code per document nnn.mmm. 2. At the project/people level: * A safety review shall be conducted at each major design baseline and before final delivery to the customer. * Good engineering practice as defined by DOD nnnn shall be performed and accompanying objective evidence shall be produced in support of certification of compliance * OOA models shall be reviewed according to the same rules as for the SRS 3. At a software black box level * Each hazard identified in the system hazard analysis as "software-mitigated" shall be referenced to the SRS and treated in that document. Example: Failure of the primary clock to maintain .1% accuracy over any 5 second period shall be detected by the software and result in a Malfunction xxx alarm. 3. At the OOA level: * Models shall be analyzed for deadlock and certified to be free of such deadlocks. (Same with live-locks.) 4. In the implementation: * If an event queue receives an event while it is full, a fatal system error shall be announced and a system- restart initiated. Of course, these are only examples. In any event, I don't believe it is practical to try to express the above types of requirements with models. Hope this helps, Chris Lynch Abbott AIS LYNCHCD@HPD.ABBOTT.COM Subject: Re: (SMU) Events to Self lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Yeager... > There are two differences between self-directed events and normal > events; one is the > self-directed event rule of OOA96 in which the actions precipitated by > self-directed > events precede any other actions of the instance generated by other > events. Clearly > this does not preclude an action sending multiple events to the acting > instance. The > other is that given the rule described above, it is reasonable for an > architecture to > try to send the self-directed events in a synchronous manner rather > than relying on > queueing. This may be acheived by directly calling the second action > or by concatanating > the generated code. However, this becomes problematic if multiple > self-directed events > are envisioned. I am not sure why this is "problematic". Each event generation could be replaced by a synchronous call; each call would return before the next event was "generated" and the calling action would not complete until all events had been "generated". It seems to me that this is just a locally synchronous implementation. If there are asynchronous issues (e.g., the invoked actions might change data that the calling action subsequently accessed), one could chain the calls to the end of the calling action -- though the overhead might be more than an efficient event queue manager. > There is a further complication I have noted before; the > non-explicitly self-directed event. > Consider the case where an action follows various relationships to > find an instance to which it must > send an event (for instance finds an object with a work item > associated with a given resource and > sends it an event to take control of the resource). If the target > instance *happens* to be > the acting instance, one typically does *not* want to require > architecture to accelerate the > event; this is still further complicated if the instance then sends an > explicitly self-directed > event. In this case, one would typically want to process the > explicitly self-directed event > first and then process other events, including the generically sent > self-directed event. Thus > a resource consumer can move to a "waiting for work" state prior to > receiving the next "resource available" event. I wonder if this isn't more of an OOA issue. That is, invoking the acting instance probably has a real problem space difficulty that the OOA should explicitly avoid. For example, when selecting the instance one might wish to explicitly exclude the acting instance (and take some appropriate action, like going to a wait state, if there is no other available, non-acting instance). > It is less clear that one would want to send multiple events to any > single instance explicitly (I still need to digest Lahman's example to > see if it provides the clear example of a case requiring this). > Again, it is possible that one may send events to various instances > which may coincidentally be the same instance based on relationships > and attributes at the time. Don't cogitate too long -- I explicitly said I didn't think there were cases where it would be _required_; merely that it might allow a more natural (intuitive?) model in some cases. > From an analysis point of view, I would defined "explicitly > self-directed" as an event which the identifier coming into the event > generator is the identifier from the event which dispatched the > current action and the event is generated to the same object or one of > its supertypes. Coincidentally self-directed events are cases where > the identifier obtained by accessors > and/or transformations *happens* to be the same as the event which > dispatched the current action. I am confused by the overloading of "identifier" here. When I generate an event I specify only three things: the identifier of the target instance; the type of event (event identifier, if you will), and the data packet. You seem to be suggesting that there is another identifier that somehow determines whether the event was intentionally self directed or coincidentally self-directed. I assume this identifier would be that of the generating instance if it was "explicitly self-directed" and it would be the identifier of the last instance in the relationship chain if one walked relationships. But what if the action simply accessed its own data store to get an instance? In that case it might get back itself, depending upon the accessor criteria. How would this be different than an "explicitly self-directed" identifier? It seems to me that the best one can do with self-directed events is what OOA96 proposes: if the event was generated in an action of the same instance to which it is directed, then it is explicitly self-directed, regardless of how one got the target address. If assuming this rule could cause a problem in the simulation, as in your "acting instance" example, then the OOA would have to deal with this contingency, presumably by qualifying its "non-explicit" search. I think the architecture can handle the rules easily for the OOA96 case if the generating instance's id is attached to the event (or the event generator checks the target id against itself and sets a flag, etc.). If the architecture has to be more psychic about the intent of the analyst (i.e., do some complex analysis of the action itself) to figure out what is going on, then I think there will be an unnecessary overhead problem. Subject: (SMU) Data types in OOA (was Architecture Independence) Sally Shlaer writes to shlaer-mellor-users: -------------------------------------------------------------------- In the thread on Architecture Independence, discussion developed around some side issues involving data types. To clarify where we are at in "OOA97", we have posted a little paper on our website. The paper is entitled "Data Types in OOA". Note that this is an excerpt from a very early chapter in the RD book. In a subsequent chapter (Bridges and Wormholes, which is also on the website) we add two (three) more base types: transfer vector, return coordinates, and -- their supertype, if you will -- client return. Hope this helps. Sally ----- Shlaer-Mellor Method: Real-Time Software Development ------ Sally Shlaer Tel: (510) 567-0255 ext. 617 Director of Research Fax: (510) 567-0250 Project Technology, Inc. email: sally@projtech.com 10940 Bigge Street URL: http://www.projtech.com San Leandro, CA 94577 -------------------- Real-Time, On Time ------------------------- Subject: (SMU) Hi Ralph, Jan Noordhof writes to shlaer-mellor-users: -------------------------------------------------------------------- Hi Ralph, Test msg received. Brilliant weather here. Hope you've recovered from the ESC at San Jose. Nice to meet you there. Cheers ------------------------------------------------- Dr Jan Noordhof Advanced Technology Division Tait Electronics Ltd P.O. Box 1645 ph. (64)(3)(358 6645) fax (64)(3)(358 0432) email: jan_noordhof@tait.co.nz Subject: Re: (SMU) Data types in OOA (was Architecture Independence) lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Sally, > In the thread on Architecture Independence, discussion > developed around some side issues involving data types. > To clarify where we are at in "OOA97", we have posted > a little paper on our website. The paper is entitled > "Data Types in OOA". It is clearly a good idea to publish these. But now that they are published, I have some questions, as you probably expected. The one I have a problem with is the Numeric type. First a quibble: for a methodology that is geared to R-T/E systems I find it seriously weird that bitwise operations are not among the allowed operators. We have domains where 80% of the attributes are register values and these must be manipulated with bitwise operators. In this environment it is rather unnatural to use *2 and /2 for shifts. It is downright bizarre (not to mention complicated and error-prone) to do masking operations without bitwise operators. I would suggest adding a base type for "digital numeric" that would allow the bitwise operators for that particular type. Taking this a step further, you allowed types may not be valid for some numeric types. For example, what is the meaning of % or > for a register full of flag bits? So when you say that the set of operators are "permitted" do you mean _all_ of them can be applied to _all_ variables of type "numeric"? If so, I have a big problem with that interpretation. If not, then I don't see why bitwise operators can't be included. At the OOA level I manipulate that register of flag bits as a single value because the semantics of the individual flags are not relevant in the domain. That is, I have an event like E1:Read_modifiy_write (value) where "value" comes from a bridge. But only a very small subset (mostly missing from your subset) of numeric operators are valid for servicing that event. My other problem is how one defines more complicated numeric types, such as the ubiquitous complex variable. Does one do something like data type quadrature is numeric real range is 0.00 to 3.60 imaginary range is 0.00 to 3.60 units are volts precision is 0.01 or is one supposed to create a Quadrature instance with a Real attribute and an Imaginary attribute with its own set of Add, Multiply, etc. operations and a gazillion relationships to other objects on the IM? I don't like the second approach for a gaggle of reasons, but your specification seems to preclude the former by implication of being single-valued. When dealing with robotic handlers in production lines you can get coordinate variables that have a dozen or more component values (dimensions). In the OOA the level of abstraction is such that one does not want to think about what adding two coordinates implies or what the individual component values are; one wants to deal with the Coordinate attribute as a single entity. However, one still needs to provide enough descriptive information about that attributes so that the translation can Do the Right Thing for accessors, data types, and numeric operations. Where this specification seems to be aimed is to define sufficient information in the OOA so that the translation can Do the Right Thing. However, I think this paints you into a corner that is not consistent with the level of abstraction in the OOA, especially when one has complicated data like a robot coordinate that is conceptually a single value in a particular OOA domain. In these cases I think the OOA only needs a tag for the type, like Robot Coordinate, and the actual description can be left to the translation rules where the storage and processing issues are defined. Note that this approach also handles the issue of what operators are available. You can specify a much wider variety of operators as _syntactically available_ but the translation rules define what is actually available on a case-by-case basis. If the % operator is not defined in the translation rules for a Robot Coordinate, you will hear about it real quick in the simulator or the code generator. [Model simulation is theoretically a difficulty, but in practice all the simulators just instrument generated code anyway so this is not so much of an issue.] Subject: (SMU) >>> lahman wrote: Dana Simonson writes to shlaer-mellor-users: -------------------------------------------------------------------- >>> lahman wrote: > I find it seriously weird that bitwise operations are not among the > allowed operators. We have domains where 80% of the attributes are > register values and these must be manipulated with bitwise > operators. I would suggest that in the domain which deals with the registers, there should be register objects with boolean attributes. In client domains where the register value is stored but not manipulated, it can be stored as a number or an identifier of the register could be used. Bitwise operations are not required, merely convenient. > My other problem is how one defines more complicated numeric types, > such as the ubiquitous complex variable. A complex arithmetic domain could be used. Complex numbers were used long before they were directly supported by compilers. However, since current compilers are now providing direct support for complex numbers, one would like to specify this type directly. > When dealing with robotic handlers in production lines you can get > coordinate variables that have a dozen or more component values > (dimensions). This could also be handled with identifiers to an object in another domain. The robot control domain would store the n-dimensional coordinate and pass an identifier to the client. Since the client does not need to know the contents of the coordinate, an identifier would be sufficient. I don't think additional types are required, however, there are cases when they would be extremely useful. I would like to see them handled like processes. A minimum set would be defined, but specific architectures would be free to add support for additional types as needed. Subject: Re: (SMU) Data types in OOA Dana Simonson writes to shlaer-mellor-users: -------------------------------------------------------------------- In reference to the paper "Data Types in OOA" by Sally Shlaer and Steve Mellor: In section 3, it is stated that every supplemental data item on a event needs to have a data type specified. Under the OOA96 rule in chapter 9 requiring all event data be an attribute of an object, the type for any data item can be derived from the context of the attribute being placed into the event generator. Does the inclusion of separate type information for supplemental data items imply that transient data will now be allowed on events? Subject: Re: (SMU) Data types in OOA Neil Lang writes to shlaer-mellor-users: -------------------------------------------------------------------- At 02:58 PM 11/6/97 -0600, >Dana Simonson writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >In reference to the paper "Data Types in >OOA" by Sally Shlaer and Steve Mellor: > > >In section 3, it is stated that every >supplemental data item on a event needs to >have a data type specified. Under the OOA96 >rule in chapter 9 requiring all event data >be an attribute of an object, the type for >any data item can be derived from the >context of the attribute being placed into >the event generator. Does the inclusion of >separate type information for supplemental >data items imply that transient data will >now be allowed on events? > > Correct. We crafted that rule in OOA96 to ensure that the type of every item of event data could be unambigously determined. In retrospect, we realized that was much too restrictive. Analysts can define whatever event data they want and simply type them as the events are specified. Another result of lifting this restriction is that event names in the event specification become somewhat akin to formal parameters in a procedure call. In a Generate Event process these "formal parameters" are assigned actual values which may be values of specific attributes in the model, temporary or transient values previously computed by another process, or even constant values. Neil ---------------------------------------------------------------------- Neil Lang nlang@projtech.com Project Technology, Inc. 510-567-0255 x623 10940 Bigge Street San Leandro, CA 94577 http://www.projtech.com ---------------------------------------------------------------------- Subject: Re: (SMU) >>> lahman wrote: lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Simonson... > I would suggest that in the domain which deals with the registers, > there should be register objects with boolean attributes. In client > domains where the register value is stored but not manipulated, it > can be stored as a number or an identifier of the register could be > used. Bitwise operations are not required, merely convenient. I don't disagree that they are merely convenient -- compared to using the allowed arithmetic operators. However, I do disagree that modeling with objects is the proper way to go.This is not an acceptable solution for a variety of reasons. The main one, though, is that the semantics of the individual bit values are not relevant at the domain's level of abstraction. The only thing the domain cares about is where the register is is (in which object it lives combined with the individual attribute id) and that it has some value that needs to be updated. Therefore individual bit booleans are an obfuscation in the domain. Given the level of abstraction of the domain as I have described it, this would be bad modeling. At the next level up, a proliferation of register objects (our hardware has in excess of 10**3 _different_ registers that each would have different boolean attributes) would make the IM unreadable. Not to mention the trees killed when the domain notebook gets printed out. At the lowest level, let's say I have a generic Register with Bit_1, Bit_2, etc. as attributes. How do I do a read-modify-write? If the register was a value, the bridge can conveniently provide a value and a mask (or value type enumeration that is used to locate the mask) and the operations are trivial. But if individual booleans are used the update starts to get really messy with tens of lines of action language code (or dozens of ADFD processes) to break down the value into individual Bit_n values. Plus the bridge needs to provide syntactically more complex information about how the value breaks down into bits (e.g., a list of bits which booleans are affected). This gets real ugly real quick with a major downside for reading comprehension. > > My other problem is how one defines more complicated numeric types, > > such as the ubiquitous complex variable. > > A complex arithmetic domain could be used. Complex numbers were used > long before they were directly supported by compilers. However, > since current compilers are now providing direct support for complex > numbers, one would like to specify this type directly. A complex arithmetic domain would reside in the architecture. I have no problem with that, but my issue lies with the specification of the attribute of that type in a higher level domain. As I read Sally's spec the implication is that a numeric attribute must be single valued with a range, precision, and unit value specified. A complex number does not fit in this mold but one can have abstract values in a domain that happen to be complex numbers in the implementation when the domain's level of abstraction is not concerned with their real and imaginary elements. The other side of my point is that I agree with the spec's intent that one cannot start adding base types for things like complex numbers. I think the types in the spec are sufficient for the needs of an OOA. When one needs additional types I would prefer that the user specify a user defined type, say Complex, which is only defined as base type numeric in the OOA to preserve abstraction and allow certain syntactic associations (e.g., numeric operators). But that user defined type name should also be an associated natural language description that provides sufficient information so that reasonable translation rules can be specified in the RD. (I choose natural language to indicate the content is not part of the OOA; if one had a language specific to the RD, that would be fine.) Things like range and precision are crucial to the RD but they usually don't add anything to the OOA itself. In the rare cases when they do, then one still has the supplementary description for the RD. Subject: Re: (SMU) Data types in OOA lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Simonson... > In section 3, it is stated that every > supplemental data item on a event needs to > have a data type specified. Under the OOA96 > rule in chapter 9 requiring all event data > be an attribute of an object, the type for > any data item can be derived from the > context of the attribute being placed into > the event generator. Does the inclusion of > separate type information for supplemental > data items imply that transient data will > now be allowed on events? OOA96 also said that all data on events AND data flows had to be attributes (or time), which effectively eliminated transient data except within a process. I still regard this as the single most unworkable change in OOA96, so I hope you are correct in your speculation. Alas, I think the intent was that the _receiving_ instance needs to know the type and the receiver cannot know about the context of the event generation. So the event data packet must carry this information. Subject: (SMU) Re: Data types in OOA Kenneth Cook writes to shlaer-mellor-users: -------------------------------------------------------------------- At 02:04 PM 11/6/97 -0600, you wrote: >Dana Simonson writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >>>> lahman wrote: > >> I find it seriously weird that bitwise operations are not among the >> allowed operators. We have domains where 80% of the attributes are >> register values and these must be manipulated with bitwise >> operators. > >I would suggest that in the domain which deals with the registers, >there should be register objects with boolean attributes. In client >domains where the register value is stored but not manipulated, it >can be stored as a number or an identifier of the register could be >used. Bitwise operations are not required, merely convenient. Sounds slow, unless the Register object is hand-coded. I don't feel it matters whether the bitwise operations are required or convenient. The example simply points out that there is no way to add operators for a user defined type. IMO, the solutions we are looking for meet these criteria 1. Datatypes can be defined and used in the analysis without any dependency on a specific architecture. 2. The OOA provides a way for the analyst to model everything they might want to do with the datatype. 3. There is enough information in the model for model compilers to generate the right thing, and to do it optimally. And I think many would be please if 4. Modeled objects can be used as types. I think the posted paper handles #3 well, #1 ok, and #2 poorly. The method's support for #4 seems to be tool dependent. What the paper seems to be saying is that user-defined types literally inherit the interface of the base type. The implementation of these interfaces for both the base and user-defined types is left up to the architecture. But there is no provision (that I see) for defining new type interfaces, or extending existing ones. Folks in our group have been suggesting that we follow the CORBA meta-model for types, rather than the OOA's. CORBA had to solve some of the same problems, "how do we generate code from a language independent description?" When it comes to dataypes, CORBA has pre-defined datatypes tkLong tkOctet tkString user-defined datatypes, that can have structure tkSequence tkArray tkStruct objects can be used as datatypes interface RobotCoord { tkLong position1; tkShort angle2; tkLong position3; RobotCoord add( in RobotCoord, in RobotCoord ); }; // pardon any IDL syntax errors They don't have to solve the problem of an interface for a user-defined type, but the analyst can certainly define a new object and it's interface in IDL. I don't think I could satisfactorily solve the RobotCoordinate and Register problems posed by lahman using OOA97. -Ken Subject: (SMU) Re: Data types in OOA Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- Kenneth Cook wrote: > The example simply points out that there is no way to add operators > for a user defined type. > > IMO, the solutions we are looking for meet these criteria > > 1. Datatypes can be defined and used in the analysis without any > dependency on a specific architecture. > 2. The OOA provides a way for the analyst to model everything > they might want to do with the datatype. > 3. There is enough information in the model for model compilers > to generate the right thing, and to do it optimally. > > And I think many would be please if > > 4. Modeled objects can be used as types. > > I think the posted paper handles #3 well, #1 ok, and #2 poorly. > The method's support for #4 seems to be tool dependent. I think that one of the problems is that the paper is formulated in terms of types, not classes. Classes define the ways in which a quantity can be manipulated; the type describes how it is realsised. The two concepts seem to have got muddled up. The concepts described by the paper have the characteristics of classes, not types. However, they are very restrictive, and seem to assume a more-or-less starndard computational architecture and a very limited set of operations. While being restictive, there is also some redundancy. Boolean, enumerated and extended boolean all have identical characteristics - they are all enumerated types. The ordered type is also an enumerated type; that has had the orthogonal concept of linkage via a graph added. Finite numeric types are also nothing more that an ordered type with a linear graph. Infinite numeric types and infinite symbolic types are also equivelent. It probably is important for an analyst to specify the underlying structure of values for a type. Even if all quantities will be implemented as the type "std_logic_vector" then ordering may be important if we want to, say, minimise the hamming distance between adjacent values. The type should therefore be described as either: . finite or infinite . ordered or unordered . value or handle (finite types should specify the number of valid values; ordered types should specifiy the ordering network. Some of this information may be dependent on the system in which the type is used. Oh, and even inite types must be constrained to a finite range.) Everything else about the types is semantic information that defines the meaning of a value from the point of view of the type's user. From the point of view of a client domain, the most important thing is to define what operations (transforms?) can be used. To do this, we should forget about types, than consider classes. All that is needed to specify the characteristics of a class is a list of operations that can be applied to it. The list of operations could be domain specific - they would represent wormholes that are mapped onto bridges and thus onto 'normal' wormholes of a service domain. This way of thinking about "types" seems to be consistent with your requements 1..3; and is how I tend to think about types when doing a paper model (our CASE tools are much more primative). However, it does not allow your requirement <4>. An object in a domain cannot be used as a type in its own domain; and it cannot be visible from other domains. However, a Domain can export an interface that can be mapped onto a type in another domain; so I think that the intent of <4> is achieved. I know that its probably a bit late to be saying these things now. The RD book is already slightly overdue. However, I would like to see a way of linking the wormholes of one domain onto type-based operations in another. Dave. Not speaking for GPS. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Tamerton Road, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com For embedded Systems Support mailto:armapps@gpsemi.com Subject: Re: (SMU) Re: Data types in OOA lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Whipp... > I think that one of the problems is that the paper is formulated > in terms of types, not classes. Classes define the ways in which > a quantity can be manipulated; the type describes how it is > realsised. The two concepts seem to have got muddled up. I am not sure I agree with your implied definitions of Class and Type, especially in an OO context. However, I like the basic idea of distinguishing the way in which things are manipulated from the way they are structured. In an OOA the structure of the atomic elements is not of concern, while in an RD it is of great concern. OTOH, in an OOA one is interested What specific ways an atomic element can operated upon while in an RD one is very interested in the details of How those operations work. > It probably is important for an analyst to specify the underlying > structure of values for a type. Even if all quantities will be > implemented as the type "std_logic_vector" then ordering may > be important if we want to, say, minimise the hamming distance > between adjacent values. I agree, but my issue is where? I don't think typing is part of the OOA; I feel it belongs in the RD. Things related to the structure, such as the range of integer values, are not of concern in the domain OOA. The Data Type specification implies that it belongs in the OOA. I would rather see your class view and type view separated with the class view appearing in the OOA but the type view in the RD . However, the same analyst would supply both. [The analyst already has to supply a passle of application-specific, non-OOA information to the RD, such as expected instance counts and frequency of create/delete so that the implementation can meet performance requirements, so this separation is not unprecedented.] Subject: Re: (SMU) Re: Data types in OOA Kenneth Cook writes to shlaer-mellor-users: -------------------------------------------------------------------- At 11:04 AM 11/7/97 -0500, you wrote: >lahman writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >Responding to Whipp... > >> I think that one of the problems is that the paper is formulated >> in terms of types, not classes. Classes define the ways in which >> a quantity can be manipulated; the type describes how it is >> realsised. The two concepts seem to have got muddled up. > >I am not sure I agree with your implied definitions of Class and Type, >especially in an OO context. However, I like the basic idea of >distinguishing the way in which things are manipulated from the way they >are structured. In an OOA the structure of the atomic elements is not >of concern, while in an RD it is of great concern. OTOH, in an OOA one >is interested What specific ways an atomic element >can operated upon while in an RD one is very interested in the details >of How those operations work. Well said. Separation data definition, interface, and behavior is goodness. In OOA, that separation, if any, is left up to the architecture. With data types, I think we are seeing another place were OOA needs to provide a way to specify just one or two of the three. Bridges are an example of another place. > >> It probably is important for an analyst to specify the underlying >> structure of values for a type. Even if all quantities will be >> implemented as the type "std_logic_vector" then ordering may >> be important if we want to, say, minimise the hamming distance >> between adjacent values. > >I agree, but my issue is where? I don't think typing is part of the >OOA; I feel it belongs in the RD. Things related to the structure, >such as the range of integer values, are not of concern in the domain >OOA. The Data Type specification implies that it belongs in the OOA. >I would rather see your class view and type view separated with the >class view appearing in the OOA but the type view in the RD >. However, the same analyst would supply both. [The >analyst already has to supply a passle of application-specific, non-OOA >information to the RD, such as expected instance counts and frequency of >create/delete so that the implementation can meet performance >requirements, so this separation is not unprecedented.] Specification for the RD. When I wrote about common colorings a week or two back, I was flirting with this same idea, that there is this "thing" between the OOA and a specific architecture that we are starting to learn something about. If you will, it is a "Bridge" between the OOA and the architecture. Since nothing in the OOA can inherit from anything in the architecture, the way it is done in OOP, then it makes sense that we'd be able to specify some "bridge" between the service/application domains and the architecture domain. Specifying datatypes as part of the "RD" seems to me one step in creating a formalism for the RD. Who knows, someday we may have pictures and arrows for this (I hear clouds are up for grabs again :-) Ken Cook Softwire Corporation http://www.softwire.com Subject: (SMU) Data types in OOA Sally Shlaer writes to shlaer-mellor-users: -------------------------------------------------------------------- After perusing your feedback on the datatypes paper . . . 1. Bit Field. We will correct the obvious omission of bit field as a base type. The legal operations will include and, or, shift, etc. 2. Purpose of the paper. Our intention is to define the minimum set of **atomic** base types that toolmakers need to support -- a set sufficient to support most OOA models. We would certainly have no problem with a user defining additional atomic base types in the same spirit as the standard (i.e., the ones listed in the paper) base types. 3. Compound data types. There never has been a rule against using structures as attribute values -- in fact, our first translation project (1982!!) defined attributes that were, in fact, matrices. What you are prohibited from doing is *directly* accessing parts of a compound data element. That is, an attribute must appear to the analyst to be atomic. If the analyst needs matrices and, say, the elements of the primary diagonal, then the architecture will need to supply a facility that takes, as input, a given matrix and returns the multiple data elements that constitute the diagonal. We need to add to the method explicit rules for how to define and handle compound data types. I expect to do this in much the same style as was done with the date data type in the paper. It will be the responsibility of the architecture to implement whatever operations that are needed by the client domains. 4. Types or Classes. The fact that we discussed the legal operations for the datatypes was due to my completeness and precision genes. It was not intended to imply that there had to be classes underlying the base types. How the base types are to be implemented -- as a class, the use of a type supported by the target language, . . . -- is not stated. It is the responsibility of the architecture to support any base types needed by its clients. 5. Use of operations. Just a reminder: the _only_ place an operation can come into play is in a test or transformation. Most action languages require the analyst to define tests and transformations "out of line", just as is done in an ADFD with process descriptions. It is up to your tool supplier and/or toolsmiths to ensure that you don't do something silly in the (formal) process descriptions: adding a numeric quantity to a character string, for example. Many thanks for your input. It really helps! Sally ----- Shlaer-Mellor Method: Real-Time Software Development ------ Sally Shlaer Tel: (510) 567-0255 ext. 617 Director of Research Fax: (510) 567-0250 Project Technology, Inc. email: sally@projtech.com 10940 Bigge Street URL: http://www.projtech.com San Leandro, CA 94577 -------------------- Real-Time, On Time ------------------------- Subject: (SMU) Between OOA and RD (was Data Types in OOA) Sally Shlaer writes to shlaer-mellor-users: -------------------------------------------------------------------- Thank you all for your feedback on the Data Types in OOA article. Before getting down to specific requests (most of which we will be incorporating), let me pick up with a quote from HS: HS> I don't think typing is part of HS> the OOA: I feel it belongs in the RD. Things related to the structure, HS> such as the range of integer values, are not of concern in the domain HS> OOA. The Data Type specification implies that it belongs in the OOA. >From my perspective, there isn't a clear line between OOA and RD. Our training materials imply such a line by placeing such emphasis on how to build certain models, each of which is clearly associated with OOA or RD. But as Ken Cook points out: Ken> . . . When I wrote about common colorings a week Ken> or two back, I was flirting with this same idea, that there Ken> is this "thing" between the OOA and a specific architecture that we Ken> are starting to learn something about. If you will, it is a "Bridge" Ken> between the OOA and the architecture. . . . Yes, we are starting to get some structure on how one proceeds from the OOA models to the architecture (I would vastly rather you not call it a "Bridge" -- suggestions anyone?). To give you a preview, let's look a little at what is coming up in the "somewhat overdue" RD book. We see three **roles** in the OOA/RD process. 1. Analysts. Of course, the analysts build the OOA models. They can also go forward to do certain tasks that rely on the OOA models only: For example, building the instance database for their domain and populating it with any pre-existing instances that come from the real world. Part I of the book is aimed at the analysts. It includes some new information on building OOA models (this material will later be recycled into an up-to-date OOA book, where it really belongs), such as the description of synchronous services and an action language. Part I also contains some new material that you need to do to "prep" the OOA models for RD. Declaring datatypes is one of these prep jobs. 2. Architects. The architects select or specify and build the architecture. This team will certainly include at least one senior architect and probably some architects-in-training. We have also had very positive experiences incorporating (junior) programmers in this team. Part II of the book is aimed at the architecture team. It provides some structure on the process of building the architecture -- what you need to look for in the client OOA models, for example. 3. Toolsmiths/Construction Crew These are the people who are responsible for the actual construction of most of the system. You need a couple of senior programmers here -- senior in the sense that they understand commonly available tools, the selected OOA/RD automation suite, database systems,etc. Most important is that the seniors understand how all these tools can be fit together. We are talking here about computer scientists par exellance. Less experienced programmers can work on this team also. They will generally work on a single program or tool at a time; over time they are likely to develop a larger view and take over bigger and bigger projects. Part III of the book is oriented towards the toolsmiths. Aside from setting up the construction itself, they will surely be called upon to build both little tools to complement the automation suite: things to make the analysts and architects job easier. They may also need to build special tools to develop the architecture under construction: special-purpose colorizers, thread extractors, etc. And, oh yes, Part IV is for everyone. It contains a complete example of a system that uses a non-trivial architecture. Now I'll write the article that I really started out to do: comments on the datatypes feedback. Best to all, Sally ----- Shlaer-Mellor Method: Real-Time Software Development ------ Sally Shlaer Tel: (510) 567-0255 ext. 617 Director of Research Fax: (510) 567-0250 Project Technology, Inc. email: sally@projtech.com 10940 Bigge Street URL: http://www.projtech.com San Leandro, CA 94577 -------------------- Real-Time, On Time ------------------------- Subject: Re: (SMU) Data types in OOA Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- Sally Shlaer wrote: > 5. Use of operations. Just a reminder: the _only_ place an > operation can come into play is in a test or transformation. > > Most action languages require the analyst to define tests and > transformations "out of line", just as is done in an ADFD with > process descriptions. It is up to your tool supplier and/or > toolsmiths to ensure that you don't do something silly in the > (formal) process descriptions: adding a numeric quantity to a > character string, for example. I'd just like a bit of clarification on this. Operations are only used in Transforms and Tests. However, the characteristics of the underlying operations are provided by the domain that provides the base types on the participating dataflows - either the architecture, an implementation domain, or a service domain or another application domain. So it appears that the process descriptions form a layer between ADFDs and a set of wormholes. But wormholes are also first-class components of an ADFD. Are the mechanisms for interacting with wormholes the same for both ADFDs and process descriptions? Are P-specs a form of hierarchical ADFD? I can argue round in circles about precisely what wormholes are; and to which elements of a model they can be attached; and whether there is a distinction between a wormhole and an operation. As an aside, could I ask for some clarification on mathematically dependent attributes. Whose responsibility is it to maintain the value of an attribute that is mathematically dependent on others? If it is the analyst's then that is unfortunate. If it is the architecture's, then this is surely another place where operations may be used. Dave. Not Speaking for GPS. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com Subject: Re: (SMU) Between OOA and RD (was Data Types in OOA) "Dean S. Anderson" writes to shlaer-mellor-users: -------------------------------------------------------------------- Sally Shlaer wrote: > > Sally Shlaer writes to shlaer-mellor-users: > -------------------------------------------------------------------- > [snip] > > Yes, we are starting to get some structure on how one proceeds from the > OOA models to the architecture (I would vastly rather you not call it a > "Bridge" -- suggestions anyone?). To give you a preview, let's look a little at > what is coming up in the "somewhat overdue" RD book. > [snip] Based on what I have seen in the training classes and read in the books, I believe you already call this a "Bridge". All of the domain chart examples I have seen bridge the analysis domains to a domain call "Software Architecture (SA)". This SA domain then bridges to various domains such as "Programming Language" and "Operating System". Since we have been working on an automated toolset I have had several ideas regarding the domain chart. This is probably as good a time as any to throw them out: 1) Our toolset is graphical in nature. We parse most of our critical information directly from diagrams. This includes the domain chart which guides and provides the framework for the rest of the parsing. What we found when working on the Domain Chart parsing was that the "classical" domain chart had information on it that we did not need or care about. Specifically, the "Software Architecture" domain and anything that it was the only client of. It turns out that these items were already encapsulated in our architecture (amazing, just what you would expect based on the classical domain chart!). We only needed the domains being analyzed and bridges to "realized" domains (except the SA, the parsing & translating is the bridge to the SA). 2) All of the analysis domains in the classical charts seem to bridge to the SA. Two impacts of this seem to be: A) It can make for a messy chart, and B) Since it is something that "everyone" knows, it is probably redundant information. 3) From all of the above (item 1, 2 and the comment from Sally), I suggest dropping the SA and it's servers from the domain chart. They don't provide significant information to a translation process. Instead, what is needed is some type of diagram (in addition to the domain chart) that "maps" process types to service domains such as "Database", "TCP/IP", "O/S", etc. I still don't know what this should look like but it needs to provide a framework to guide the translation of processes to code just as the domain chart provides the framework for the analysis. [After reading the above, I don't know if I get my ideas across very well, but haven't got any better wording I can think of.] The analogy I have been currently using is that the Analysis is one side of a coin and the Software Architecture is the other side. The "metal" between the faces represents the continuous connection between the analysis and architcture (see item 2 above). On another note, I have implemented several different methodologies at various companies and have found that the Shlaer-Mellor methodology is by far the best I have worked with. While nothing is perfect, the S-M work we have been doing has had the fewest problems of any other method. I want to thank Sally and Steve for all their good work and I anxiously await the new book. Dean S. Anderson Transcrypt International/EF Johnson Radio Products (ka0mcm@winternet.com) Subject: Re: (SMU) Between OOA and RD (was Data Types in OOA) lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Shlaer... > From my perspective, there isn't a clear line between OOA and RD. Our > training > materials imply such a line by placeing such emphasis on > how to build certain models, each of which is clearly associated with > OOA or > RD. But as Ken Cook points out: I always thought the line was defined by implementation-dependence. Isn't that the whole point of Translation? It seems to me that the line in the sand has General Abstract Descriptions on one side and Lots of Geeky Computer Stuff on the other side. > Yes, we are starting to get some structure on how one proceeds from > the > OOA models to the architecture (I would vastly rather you not call it > a > "Bridge" -- suggestions anyone?). To give you a preview, let's look a > little at > what is coming up in the "somewhat overdue" RD book. I agree that "bridge", besides being overloaded, implies a Thing while translation is a _process_ that operates on Things (like an OOA of the Architecture). Wait, I think I have it! How about Translation Process -- or Translation for short? (Sorry, my reptilian brain stem made me do it.) > Part I also contains some new material that you need to do to "prep" > the > OOA models for RD. Declaring datatypes is one of these prep jobs. I infer by this that you regard the typing more as a documentation for the translator than as an element of the OOA proper. That is, the typing is associated with the OOA attributes simply because it is notationally more natural and this should be regarded as a sort of colorization. > 2. Architects. The architects select or specify and build the > architecture. > This team will certainly include at least one senior architect and > probably > some architects-in-training. We have also had very positive > experiences > incorporating (junior) programmers in this team. > > Part II of the book is aimed at the architecture team. It provides > some > structure on the process of building the architecture -- what you need > > to look for in the client OOA models, for example. But given the toolsmiths below, what do these guys actually do? Beyond providing the one-time handful of reusable core subsystems common to all architectures (e.g., the event manager, an error handler, etc.) I don't see a lot to keep them busy on an ongoing basis. With a little luck in a few years all the true Architecture software will be available OTS. I see the situation as analogous to when the C language was developed for writing parsers and lexical analyzers on small systems. The first major programs developed in C were lex and yacc, obviating the need for C in the niche for which it was designed. I see the same sort of self-created unemployment for Architects. Once they do one Architecture they have done them all. > Part III of the book is oriented towards the toolsmiths. Aside from > setting up the construction itself, they will surely be called upon > to build both little tools to complement the automation suite: > things to make the analysts and architects job easier. They > may also need to build special tools to develop the architecture > under construction: special-purpose colorizers, thread extractors, > etc. Why wouldn't those "special tools" include the nuts&bolts stuff like the Event Manager? I guess my problem is that I don't see anything the distinguish the tools that the Architect builds from the tools that these guys build. I don't see an Event Manager as being substantively different than, say, a Linked List -- they are both reusable building blocks that are mushed together during Translation. At best the Architectural tools are more reusable across a variety of systems. I can sort of see a distinction between Architects and the Construction Crew if the Architects do the tool building and the Construction Crew does the gluing. But as you have defined it I think there is a real fuzzy boundary. Except maybe in salary; Architect is a much fancier title than Toolsmith. Subject: Re: (SMU) Data types in OOA lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Shlaer... > After perusing your feedback on the datatypes paper . . . > > 1. Bit Field. We will correct the obvious omission of bit field as a > > base type. The legal operations will include and, or, shift, etc. After raising this issue it was pointed out to me offline that everything for my register example could be accommodated by a write accessor that accepted the Value and a Value Type (or Value Mask) and wrote to the attribute value.However, I still support the addition of the Bit Field with appropriate bitwise operators. One still has to deal with transient data, it would make life easier for using action languages and simulators, and I believe there are situations where one would like to expose the "algorithm" in the OOA. > 5. Use of operations. Just a reminder: the _only_ place an > operation can come > into play is in a test or transformation. > > Most action languages require the analyst to define tests and > transformations > "out of line", just as is done in an ADFD with process descriptions. > It is up to your tool supplier and/or toolsmiths to ensure that you > don't do > something silly in the (formal) process descriptions: adding a > numeric > quantity to a character string, for example. The inference is that one can develop arbitrary operators for compound data types since I can define a "#" transform as easily as I can define a "+" transform. This plays fine in an ADFD, but how does it carry over to the action languages? Syntactically I can see a disaster like C++'s operator overloading coming. Hopefully when you define the handling of compound data types you will avoid this. FWIW, I am in the camp of trying to be faithful to the ADFD approach at the expense of key strokes in the syntax (e.g., use a function call-like syntax for compound data transforms rather than defining or redefining operator symbols). Subject: Re: (SMU) Between OOA and RD (was Data Types in OOA) Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- Sally Shlaer wrote: > Yes, we are starting to get some structure on how one proceeds > from the OOA models to the architecture (I would vastly rather > you not call it a "Bridge" -- suggestions anyone?). To give > you a preview, let's look a little at what is coming up in the > "somewhat overdue" RD book. > > We see three **roles** in the OOA/RD process. I see other people have been giving their opinions on what OOA and RD are - so I'll let you know the lines that I'm thinking along at the moment. I've recently started using Microsoft environment, and so am getting up to speed with all sorts of things like ActiveX, DAO and ODBC. The current state of these technologies allows me to completely separate the tools from the data. When I want to edit a model then I can either edit it in Access(tm) or write an ActiveX control to edit a specific view. The control does a query on the database to get its information and then gives me either a graphical or textual editor. (for example, I may use an STT control, or a STD control - it depends how I feel). The system does need some polish to make it feel like an application rather than a set of controls. The important bit comes next. The model is stored in a relational database, whose scheme is defined by the OOA-of-OOA. An architecture can be defined as a different scheme. If I'm going to hardware then I have architectural components like registers, state machines, buses, etc. If its software then I'd find different high level concepts. Its important to remember that an architecture defines the structure of code, not the code itself. Once I've defined the schemes of both databases, I need to write translation rules between the two. These can be written in a variety of ways. SQL queries are a well understood way of generating a set of tables from a database. Thus the OOA-to-architecture translation step is a set of SQL queries. (though there may be a bit of DAO for the more difficult bits). However, there are usually some gaps in the output of the queries. Bits of information needed by the architecture that aren't in the OOA-of-OOA. There are three ways of rectifying this: I can add bits to my source scheme; add something to the generation process for the new database or edit the achitectural database (possibly using a specifically written ActiveX control). All three methods have their uses; obviously editing the architecture database is a bit undesirable The final step - code generation - is the relatively simple task of producing a report from the architectural database. Because the database scheme is designed for the structure of code that I want to generate, this step is very simple. So we have three phases - possibly corresponding to Sally's: populating the Analysis database, Constructing the Architectural scheme, and producing the Queries that map one to the other. There is actually a Fourth step, that Sally doesn't mention, which is very important (especially when constructing hardware). That is the population database. The information that my hardware architectures require depend significantly on the populations. In fact, I have even needed to restrict attribute domains of referential attributes on a per-instance basis to minimise the number of multiplexors in a design. When I think about Recursive Design, the term "Recursive" must mean something. It is quite common, when constructing queries, to base one query upon the results of another. If we construct an intermediate database scheme between the Analysis and the Final Architecture, then we effectively apply the same technique for the second set of mappings as the first. Perhaps this is what "Recursive Design" means. Finally, Sally asked for an alternative to the term "bridge" for architectural mappings. Well, I use the term "architectural Mapping". Dave. p.s. I've spoken in this email as if I really have this setup working. I don't. I just have little bits of it. Populating the architecture still a manual process for my hardware architectures - though I still like to automate the final, code generation, step. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com Subject: Re: (SMU) Between OOA and RD (was Data Types in OOA) Mike Frankel writes to shlaer-mellor-users: -------------------------------------------------------------------- Dean S. Anderson wrote: > > "Dean S. Anderson" writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Sally Shlaer wrote: > > > > Sally Shlaer writes to shlaer-mellor-users: > > -------------------------------------------------------------------- > > > [snip] > > > > Yes, we are starting to get some structure on how one proceeds from the > > OOA models to the architecture (I would vastly rather you not call it a > > "Bridge" -- suggestions anyone?). To give you a preview, let's look a little at > > what is coming up in the "somewhat overdue" RD book. > > > [snip] > > 1) Our toolset is graphical in nature. We parse most of our critical > information directly from diagrams. This includes the domain chart > which guides and provides the framework for the rest of the parsing. > What we found when working on the Domain Chart parsing was that > the "classical" domain chart had information on it that we did not > need or care about. Specifically, the "Software Architecture" domain > and anything that it was the only client of. It turns out that these > items were already encapsulated in our architecture (amazing, just > what you would expect based on the classical domain chart!). We only > needed the domains being analyzed and bridges to "realized" domains > (except the SA, the parsing & translating is the bridge to the SA). Excellent observation! We have experienced the same phenomenon for many years. We always make it a point to distinguish between the theoretical bridges and bridges that actually have to be "filled in" by the project analysts. Of course there is a theoretical bridge between the OOA'd domains and the architecture, but in real projects it does not manifest itself in the same way as bridges between OOA models do. Even though we understand that the theoretical bridge exists, we don't usually call it a bridge on a day-to-day basis with new SM-ers because it only serves to confuse how the process works. Rather, we call it the object-to-architecture mapping. We have found that success with the SM method does not always require everyone on the project to understand all the theory behind it. Of course, we have to teach the theory to at least one person on the project or we wouldn't have any fun debates! > > 2) All of the analysis domains in the classical charts seem to bridge > to the SA. Two impacts of this seem to be: > A) It can make for a messy chart, and > B) Since it is something that "everyone" knows, it is probably > redundant information. > > 3) From all of the above (item 1, 2 and the comment from Sally), I > suggest > dropping the SA and it's servers from the domain chart. They don't > provide significant information to a translation process. The part of the domain chart from the SA domain "down", is still significant information, especially to the architecture team. Most of our clients find a natural separation between the top and bottom parts of the chart. The project should really have two domain charts: one for domains to be OOA'd, and one for the architecture and implementation domains. Regarding the top domain chart, there is another real project bridge that we have found exists which is the real bridge from a theoretical "Customer" domain to the application domain usually found at the top of most domain charts. While this Customer domain will not be modeled, its bridge to the application must be filled in, because this is where the initial instance set for the application domain is defined. Each customer purchasing the software may want a different configuration of the application domain object instances. Each instance set is defined in the bridge from that particular customer to the application domain, formerly at the top of the chart. > > The analogy I have been currently using is that the Analysis is one side > of a coin and the Software Architecture is the other side. The "metal" > between the faces represents the continuous connection between the > analysis > and architcture (see item 2 above). I used that same analogy very recently on this list. Either you read my message, or we think so alike that the same analogies come to mind! > > On another note, I have implemented several different methodologies at > various companies and have found that the Shlaer-Mellor methodology > is by far the best I have worked with. While nothing is perfect, the > S-M work we have been doing has had the fewest problems of any other > method. Hands-down - the best software process to date. -- ----------------------------------------------- Mike Frankel Director of Software Engineering Esprit Systems Consulting, Inc. 610-436-8290 fax 610-436-9848 mfrankel@EspritInc.com http://www.EspritInc.com -->BASELINE Domain Models -->Object Methods Training and Consulting -->Structured Methods Training and Consulting "Strategies for Computer and Human Systems" ----------------------------------------------- Subject: Re: (SMU) Between OOA and RD (was Data Types in OOA) lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Anderson... > 1) Our toolset is graphical in nature. We parse most of our critical > information directly from diagrams. This includes the domain chart > > which guides and provides the framework for the rest of the > parsing. > What we found when working on the Domain Chart parsing was that > the "classical" domain chart had information on it that we did not > need or care about. Specifically, the "Software Architecture" > domain > and anything that it was the only client of. It turns out that > these > items were already encapsulated in our architecture (amazing, just > what you would expect based on the classical domain chart!). We > only > needed the domains being analyzed and bridges to "realized" domains > > (except the SA, the parsing & translating is the bridge to the SA). > > 2) All of the analysis domains in the classical charts seem to bridge > to the SA. Two impacts of this seem to be: > A) It can make for a messy chart, and > B) Since it is something that "everyone" knows, it is probably > redundant information. I am not sure that the domain chart was designed to be used as a translation input, other than to possibly to identify domains. The domain chart is generally done very early in the development process to get a handle on the overall structure of the system. In particular, it is used to describe the flow of requirements form one domain to another. In this sense it is more of a requirements document than a design document. I believe keeping the SA domain is useful to the design as well. Mainly because you can label it to indicate _which_ architecture this particular application will be built with. Remember that a domain chart describes a particular application because the implementation domains are included. We have a number of very similar products where much of the difference lies in the implementation domains (e.g., Unix vs. NT or MFC vs. Rogue Wave) and we find it useful to focus on the essential differences in the domain chart when embarking on a new port or whatever. It is also sometimes used as a simple graphical representation at things like Executive Briefings because the system components are easily grasped from the diagram without getting into geeky detail. In this context it is useful to have the implementation domains present. I agree about the domain clutter for the bridges to ubiquitous implementation domains; generally we do not draw bridges across the implementation/service boundary. When we do include such bridges it is more to indicate that the particular implementation domain only has a few clients. Subject: Re: (SMU) Between OOA and RD (was Data Types in OOA) "Dean S. Anderson" writes to shlaer-mellor-users: -------------------------------------------------------------------- Mike Frankel wrote: > > Mike Frankel writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Dean S. Anderson wrote: > > > > > > The analogy I have been currently using is that the Analysis is one side > > of a coin and the Software Architecture is the other side. The "metal" > > between the faces represents the continuous connection between the > > analysis > > and architcture (see item 2 above). > > I used that same analogy very recently on this list. Either you read my > message, or we think so alike that the same analogies come to mind! > I don't remember seeing the message you reference above. I had been thinking along the lines of the wormhole "pane of glass" but realized that there is actually substance between the two parts. I could have easily stuck your reference in the back of my head and pulled it out when I was thinking about these things last week. It makes sense to me anyway (maybe great minds think alike :-). Dean S. Anderson Transcrypt International / EF Johnson Radio Products (ka0mcm@winternet.com) Subject: Re: (SMU) Between OOA and RD (was Data Types in OOA) Neil Lang writes to shlaer-mellor-users: -------------------------------------------------------------------- At 12:23 PM 11/18/97 -0500, >Mike Frankel writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >Dean S. Anderson wrote: >> >> "Dean S. Anderson" writes to shlaer-mellor-users: >> -------------------------------------------------------------------- >> >> Sally Shlaer wrote: >> > >> > Sally Shlaer writes to shlaer-mellor-users: >> > -------------------------------------------------------------------- >> > >> [snip] >> > >> > Yes, we are starting to get some structure on how one proceeds from the >> > OOA models to the architecture (I would vastly rather you not call it a >> > "Bridge" -- suggestions anyone?). To give you a preview, let's look a little at >> > what is coming up in the "somewhat overdue" RD book. >> > >> [snip] > >> >> 1) Our toolset is graphical in nature. We parse most of our critical >> information directly from diagrams. This includes the domain chart >> which guides and provides the framework for the rest of the parsing. >> What we found when working on the Domain Chart parsing was that >> the "classical" domain chart had information on it that we did not >> need or care about. Specifically, the "Software Architecture" domain >> and anything that it was the only client of. It turns out that these >> items were already encapsulated in our architecture (amazing, just >> what you would expect based on the classical domain chart!). We only >> needed the domains being analyzed and bridges to "realized" domains >> (except the SA, the parsing & translating is the bridge to the SA). > > >Excellent observation! We have experienced the same phenomenon for many >years. We always make it a point to distinguish between the theoretical >bridges and bridges that actually have to be "filled in" by the project >analysts. Of course there is a theoretical bridge between the OOA'd >domains and the architecture, but in real projects it does not manifest >itself in the same way as bridges between OOA models do. Even though >we understand that the theoretical bridge exists, we don't usually call >it >a bridge on a day-to-day basis with new SM-ers because it only serves to >confuse how the process works. Rather, we call it the >object-to-architecture >mapping. We have found that success with the SM method does not always >require everyone on the project to understand all the theory behind it. >Of >course, we have to teach the theory to at least one person on the >project >or we wouldn't have any fun debates! A couple of esmuggers have commented on the bridge between the application/service domains and the architecture domain. A student in one of my classes a couple of years ago also noticed this and proposed a 3-dimensional view of a domain chart. The application and service domains and their bridges lie in a horizontal plane. The architecture domain lies below this plane with a single vertical "bridge" pointing down to it from the application/service plane. I've always been fond of this particular representation because it emphasizes that the mapping to the architecture is fundamentally different than the application to server domain mappings. > > > >> >> 2) All of the analysis domains in the classical charts seem to bridge >> to the SA. Two impacts of this seem to be: >> A) It can make for a messy chart, and >> B) Since it is something that "everyone" knows, it is probably >> redundant information. >> >> 3) From all of the above (item 1, 2 and the comment from Sally), I >> suggest >> dropping the SA and it's servers from the domain chart. They don't >> provide significant information to a translation process. > > >The part of the domain chart from the SA domain "down", is still >significant information, especially to the architecture team. Most of >our clients find a natural separation between the top and bottom >parts of the chart. The project should really have two domain charts: >one for domains to be OOA'd, and one for the architecture and >implementation >domains. > >Regarding the top domain chart, there is another real project bridge >that >we have found exists which is the real bridge from a theoretical >"Customer" >domain to the application domain usually found at the top of most domain >charts. While this Customer domain will not be modeled, its bridge to >the >application must be filled in, because this is where the initial >instance >set for the application domain is defined. Each customer purchasing the >software may want a different configuration of the application domain >object instances. Each instance set is defined in the bridge from that >particular customer to the application domain, formerly at the top of >the >chart. Actually I believe that there are bridges from this "customer" domain to many if not all of the other domains as well. The bridges on the domain chart (in the earliest phases of a Shlaer-Mellor development) represent a flow of requirements. The customer makes requirements not only on the application domain but on others -- they may specify a certain GUI, db, hardware controller. And of course they make all sorts of performance requirements which impinge directly on the software architecture domain. A couple of years ago I started to draw a giant circle around the domain chart -- everything outside the circle represents the published product requirements (analagous to Mike's customer domain)-- and to add bridges to show how those requirements get parcelled out to all of the domains. Neil ---------------------------------------------------------------------- Neil Lang nlang@projtech.com Project Technology, Inc. 510-567-0255 x623 10940 Bigge Street San Leandro, CA 94577 http://www.projtech.com ---------------------------------------------------------------------- Subject: Re: (SMU) Between OOA and RD (was Data Types in OOA) Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- Neil Lang wrote: > A student in one of my classes a couple of years ago also > noticed this and proposed a 3-dimensional view of a domain > chart. The application and service domains and their bridges > lie in a horizontal plane. The architecture domain lies below > this plane with a single vertical "bridge" pointing down to it > from the application/service plane. I've always been fond > of this particular representation because it emphasizes that > the mapping to the architecture is fundamentally different > than the application to server domain mappings. I too, am fond of the notion of the 3-D, Plane-based domain chart. However, about a year ago I cam across an interesting domain that had both horizontal and vertical domains. The architecture of the system was a bus based system. Every variable attribute was realised as a register that was accessed using a bus. The architectural mapping included things like the memory map, and the structure of bits within registers. The Interesting domain that I found was a DMA controller. This had various objects, whose attributes are mapped to registers on the bus. Thus it has "vertical" bridges. However, its functionality required it to explicity manipulate the bus - a "horizontal" bridge. I think that 3-d domain chart is a useful concept - but domains don't always fit into a nice, planar, structures with orthognal bridges. A secondary point is that there are more than 2 planes in the system. Not all "mapping" domains go directly to the architecture. When building software models of systems we have a 3rd plane below the hardware/bus architectural plane for the software architecture. I beleive that both types of connections - bridges and mappings - can exist anywhere in the domain chart. Dave. Not speaking for GPS. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com Subject: Re: (SMU) Data types in OOA Neil Lang writes to shlaer-mellor-users: -------------------------------------------------------------------- At 08:42 AM 11/18/97 +0000, >Dave Whipp writes to shlaer-mellor-users: >-------------------------------------------------------------------- > > >As an aside, could I ask for some clarification on mathematically >dependent attributes. Whose responsibility is it to maintain the >value of an attribute that is mathematically dependent on others? >If it is the analyst's then that is unfortunate. If it is the >architecture's, then this is surely another place where operations >may be used. > > > As one of the folk at PT responsible for OOA96, let me shed some light on mathematically dependent attributes. All attributes have to have values. Some attributes have "pre-existing values" determined prior to run-time. Some attributes have values determined by other domains and we may see nothing in our domain model to indicate when and how their values are updated. And then there are attributes whose values must be maintained directly by our domain model (typically by computing them from other attributes in the domain). Consider the following 2 versions of the car object in which PIO is responsible for measuring hardware values CAR CAR * id * id . velocity . velocity . elapsed time . elapsed time . distance travelled . distance travelled (M) The first representation implies that the three descriptive attributes are each fundamentally measured; the fact that we distance probably equals valocity * elapsed time is coincidental. The second representation is meant to convey that our domain will take responsibility for determining the distance travelled (presumably by using the prior formula), and therefore we guarantee that the attributes have the desired dependency. I felt then (and still do) that the (M) notation was a reminder to the analyst to incorporate in the reminder of the model sufficient processing to ensure the desired mathematical dependency. So in response to your query it's the analyst's responsibility to specify processing in the appropriate action(s) to compute and update the attribute. I'm intrigued by your desire to make it the architecture's responsibility. How can the architecture implement the correct processing, if the analyst doesn't state when and how to do the computation? Neil ---------------------------------------------------------------------- Neil Lang nlang@projtech.com Project Technology, Inc. 510-567-0255 x623 10940 Bigge Street San Leandro, CA 94577 http://www.projtech.com ---------------------------------------------------------------------- Subject: [Fwd: Re: (SMU) Between OOA and RD (was Data Types in OOA)] Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- This is a multi-part message in MIME format. --------------7D79589C6C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The message I sent didn't appear on the list - am I getting caught in anti-spam code? Dave. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com --------------7D79589C6C Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <34794271.12BF@gpsemi.com> Date: Mon, 24 Nov 1997 09:01:37 +0000 From: Dave Whipp Organization: GEC Plessey Semiconductors X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: shlaer-mellor-users@projtech.com Subject: Re: (SMU) Between OOA and RD (was Data Types in OOA) References: <199711212226.OAA15811@projtech.projtech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Neil Lang wrote: > A student in one of my classes a couple of years ago also > noticed this and proposed a 3-dimensional view of a domain > chart. The application and service domains and their bridges > lie in a horizontal plane. The architecture domain lies below > this plane with a single vertical "bridge" pointing down to it > from the application/service plane. I've always been fond > of this particular representation because it emphasizes that > the mapping to the architecture is fundamentally different > than the application to server domain mappings. I too, am fond of the notion of the 3-D, Plane-based domain chart. However, about a year ago I cam across an interesting domain that had both horizontal and vertical domains. The architecture of the system was a bus based system. Every variable attribute was realised as a register that was accessed using a bus. The architectural mapping included things like the memory map, and the structure of bits within registers. The Interesting domain that I found was a DMA controller. This had various objects, whose attributes are mapped to registers on the bus. Thus it has "vertical" bridges. However, its functionality required it to explicity manipulate the bus - a "horizontal" bridge. I think that 3-d domain chart is a useful concept - but domains don't always fit into a nice, planar, structures with orthognal bridges. A secondary point is that there are more than 2 planes in the system. Not all "mapping" domains go directly to the architecture. When building software models of systems we have a 3rd plane below the hardware/bus architectural plane for the software architecture. I beleive that both types of connections - bridges and mappings - can exist anywhere in the domain chart. Dave. Not speaking for GPS. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com --------------7D79589C6C-- Subject: Re: (SMU) Data types in OOA Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- Neil Lang wrote: > I felt then (and still do) that the (M) notation was a reminder > to the analyst to incorporate in the reminder of the model > sufficient processing to ensure the desired mathematical > dependency. So in response to your query it's the analyst's > responsibility to specify processing in the appropriate action(s) > to compute and update the attribute. > > I'm intrigued by your desire to make it the architecture's > responsibility. How can the architecture implement the correct > processing, if the analyst doesn't state when and how to do > the computation? I am a great beleiver in "one fact in one place". If, as part of a (formal) attibrute description, the mathematical dependency is explicitly stated; then, any additional specifications of that dependency, for example as transforms and assignments in state actions, are redundant. Whenever I see a rule of the form "Whenever you do X, you must also do Y", I start thinking that I only need to "do X", and then write a script to add in all the "Do Y"s. In the context of OOA, this generally seems to imply some architectural mechanism. So if we have a rule that says: "whenever you update the time attribute, you must also update the distance attribute", then I try to automate the update to the distance. If you are able to specify a specific output-set of a mathematical dependency, which are never written to explicity, then it is simple to see architectural mechanisms that calculate their values using either early- or late- evaluation as appropriate. There is, unfortunately, a problem of inverses. If there is no such output set then things get a bit more complex. The set of dependent attributes would have to be kept consistant regardless of which was written to - that would be difficult and would require additional information when 3 or more variables are involved. However, the mathematical relationship would already be part of the analysis, so I wouldn't wany to re-specify it. Neil asked: "... if the analyst doesn't state when ..." The "when" is of no concern to the analyst - I doesn't matter when the calculation is performed as long as the correct value is returned when the dependent attribute is read. If an attribute is frequently read, and rarely written, then early evaluation may be appropriate. If its frequently written, but rarely read, then late evaluation may be appropriate. This is an architectural issue and could be tuned through coloration. Dave. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com Subject: Re: (SMU) Data types in OOA lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Whipp... > I am a great beleiver in "one fact in one place". If, as > part of a (formal) attibrute description, the mathematical > dependency is explicitly stated; then, any additional > specifications of that dependency, for example as transforms > and assignments in state actions, are redundant. I agree in principle with everything you said. My one tangential caveat is that one needs to be able to distinguish the architectural issues from the OOA issues when one places the facts in one place. Otherwise it becomes easy to let the architectural issues creep into the OOA. I think this issue is clearer for data types. If I have a complex number that I am representing as a single attribute, then the ranges on the real and imaginary elements should not be relevant to the OOA but I would like to specify them with the other attribute documentation because they are part of the problem space definitions of the attribute and need to be considered by the RD. The data types paper seemed to be trying to do this by restricting the things the OOA could describe, so that anything else had to be RD. But I would like something stronger, like a formal two-part definition of the attribute: one for the OOA and one for the RD. This allows trivial checklist reviewing of the OOA to catch any references or dependencies on the RD portions. Subject: Re: (SMU) Data types in OOA Carolyn Duby writes to shlaer-mellor-users: -------------------------------------------------------------------- > > Neil Lang writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > >As an aside, could I ask for some clarification on mathematically > >dependent attributes. Whose responsibility is it to maintain the > >value of an attribute that is mathematically dependent on others? > >If it is the analyst's then that is unfortunate. If it is the > >architecture's, then this is surely another place where operations > >may be used. > I'm intrigued by your desire to make it the architecture's responsibility. > How can the architecture implement the correct processing, if the analyst > doesn't state when and how to do the computation? > Mathematically dependent attributes can be updated by the architecture. The analyst must color the attribute with its formula based on other attributes. The attribute may be mapped in the following ways: 1. The value of the dependent attribute is not stored in the class. The generated read accessor for the attribute calculates the value of the mathematically dependent attribute each time it is read. This is good for a simple calculation that is not done frequently. 2. If the formula takes time to calculate or the mathematically dependent attribute is read frequently, the dependent attribute could be stored in the class and recalculated each time one of the attributes used in its formula is changed. The recalculation would be done in the write accessor. Note that this option although more efficient is more difficult to implement since the translator must be able to parse the formula and pick out the attributes that the formula depends on. In option 1, the formula can just be "pasted" into the code for the read accessor. Carolyn -- ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Carolyn Duby voice: +01 508-384-1392| carolynd@pathfindersol.com fax: +01 508-384-7906| ____________________________________________________| Subject: Re: (SMU) Data types in OOA lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Lang...Consider the following 2 versions of the car object in which > PIO is responsible for measuring hardware values > > CAR CAR > * id * id > . velocity . velocity > . elapsed time . elapsed time > . distance travelled . distance travelled (M) > > I felt then (and still do) that the (M) notation was a reminder to the > > analyst to incorporate in the reminder of the model sufficient > processing to ensure the desired mathematical dependency. So in > response to your query it's the analyst's responsibility to > specify processing in the appropriate action(s) to compute and update > the attribute. I agree with Whipp that most of the time that dependence should be implemented architecturally. This is very clear to me when both velocity and time are updated together (e.g., on the same event into the domain). It would also be clear when only time was changing. I would argue that in some cases it would be correct even if the independent attributes could both be updated separately -- when the value of the dependent attribute could always be regarded as consistent with the current values of the independent attributes, regardless of their updating. There are two situations where I think it would be appropriate for the OOA to handle the updating. The first is when both velocity and elapsed time are updated, but it occurs in separate actions (e.g., different events into the domain). Now an inconsistent value of the dependent variable could exist in the domain between events. If this is important to the flow of control of the OOA (i.e., somebody could access the dependent value between updates), then the OOA is going to have to handle this with a Wait state somewhere so that the independent attributes are updated in the same action. (Note that the architecture could still handle the calculation of the dependent variable; the OOA merely has to constrain when this is done.) The second situation would arise if there were something special about the way the dependent variable was computed. For example, suppose one obtains New Velocity and New Elapsed Time as event data and the calculation of distance was incrementally calculated based upon the differences between these and the velocity and elapsed time. Now the calculation _must_ wait until both values are available, regardless of whether anyone might access the dependent variable between the arrival of New Velocity and New Elapsed Time. Otherwise the calculation of distance would still be incorrect after both independent values were updated. (Again, the architecture could handle the calculation but the OOA needs to constrain when this happens -- either as a write accessor or transform that accepts all four relevant values.) Subject: Re: (SMU) Data types in OOA Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- Carolyn Duby wrote: > Mathematically dependent attributes can be updated by the > architecture. The analyst must color the attribute with > its formula based on other attributes. Coloring is use to provide implementation hints, not to specify functionality. The formula specifies functionality, so coloring is not appropriate - its part of the OOA. Dave. Not speaking for GPS. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com Subject: Re: (SMU) Data types in OOA Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- lahman wrote: > The second situation would arise if there were something special > about the way the dependent variable was computed. For example, > suppose one obtains New Velocity and New Elapsed Time as event > data and the calculation of distance was incrementally calculated > based upon the differences between these and the > velocity and elapsed time. Now the calculation > _must_ wait until both values are available You seem to be suggesting a mathematical dependence between event data and attributes. This goes beyond my definition. I think of mathematical dependence as being a relationship between the _current_ values of a set of attributes. The debate of implicit vs explicit update is similar to a previous discussion regarding explicit linking of relationships. I see no problems with the concept of a mathematically dependent referential attribute whose value is maintained by the architecture. Does anyone disagree? Dave. Not speaking for GPS. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com Subject: Re: (SMU) Data types in OOA peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 03:10 PM 11/25/97 +0000, shlaer-mellor-users@projtech.com wrote: >Dave Whipp writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >Carolyn Duby wrote: >> Mathematically dependent attributes can be updated by the >> architecture. The analyst must color the attribute with >> its formula based on other attributes. > >Coloring is use to provide implementation hints, not to >specify functionality. The formula specifies functionality, >so coloring is not appropriate - its part of the OOA. I agree that coloring implies design info. Since Neil indicated that OOA-96 never intended to specify how you should capture the (M) information, then this must be done through an "additional property" - summplementing the analysis. Most current SMOOA CASE environments do not support this level of customization, so the analyst must resort to *coloring* to capture this information and get it through to translation. So Dave - how do *you* capture (M) formulas? ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice: +01 508-384-1392 | peterf@pathfindersol.com fax: +01 508-384-7906 | ____________________________________________________| Subject: Colorations (was (SMU) Data types in OOA) David Yoakley writes to shlaer-mellor-users: -------------------------------------------------------------------- Dave Whipp wrote: > > Dave Whipp writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Carolyn Duby wrote: > > Mathematically dependent attributes can be updated by the > > architecture. The analyst must color the attribute with > > its formula based on other attributes. > > Coloring is use to provide implementation hints, not to > specify functionality. The formula specifies functionality, > so coloring is not appropriate - its part of the OOA. > I agree. Attr formulas belong somewhere in the formalism and should be standardized. Then the RD can decide the hows and whens. New topic... I have been using the term "annotation" for quite a while and frankly do not know where I picked it up. I think I may have heard Steve M. mention it in the PT RD class I attended. At any rate, I describe hints to the translator as annotations and design dictations as colorations. One of my first examples of an annotation was the need to capture maximum instance populations. This came up when implementing a specific design but later was used as input to the translator to determine other optimizations. Clearly this is still related to design choices so the term coloration is not terribly inappropriate. I tend to gravitate towards abstracting properties from the OOA of OOA that *trigger* design decisions. Calling this an annotation clinched this concept for because I was already thinking of a coloration as a design decision. I like the concept (if not the new term) because I think that annotations have much more potential for standardization than colorations and therefore get us closer to model portability. That is, not only would the model port but its coloration data. I am not opposed to a broader meaning for coloration since to most analysts the distinction is subtle (making the implication here that analysts will often need to be able to effectively use the translators and thus need to understand the terminology). Most of all I would like the terminology standardized. Any opinions? Any hints on what terminology is used by the PT RD book? dy ________________________________________________________________________ David Yoakley Objective Innovations Inc. Phone: 512.288.5954 14606 Friendswood Lane Fax: 512.288.6381 Austin, TX 78737 Replies: yoakley@oiinc.com ________________________________________________________________________ If it weren't for electricity we'd all be watching television by candlelight. George Gobel Subject: Re: (SMU) Data types in OOA Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- Peter J. Fontana wrote: > I agree that coloring implies design info. Since Neil indicated > that OOA-96 never intended to specify how you should capture the > (M) information, then this must be done through an "additional > property" - summplementing the analysis. Most current SMOOA > CASE environments do not support this level of customization, so > the analyst must resort to *coloring* to capture this information > and get it through to translation. > > So Dave - how do *you* capture (M) formulas? Thre are really two questions here: how do I model (M) information and how do I capture it. The case tool we use is rather primative (pre-OOA96). Our architecture is currently constrained so that simulation on the CASE tool matches genreated code (although reordering of events and data is allowed). We therefore cannot add functional information (like (M) information) except as part of an attribute (or process) description. There is no point in setting an (M) formulae as a property because the information is already explicitly in the model. However, if I'm working outside of the CASE tool then the rules are different. My aim is then to construct a clean analysis model. This may be done using a word processor, a database application, a speadsheet or even pencil & paper. Probably a mixture. In this environment, I simply specify a (M) dependency as an equation, algorithm or a mapping table. As an example, in a description of a simple interface cell (a parallel port) I have an object called 'Pin' and an object called 'Channel'. 'Pin' includes: Pin.nominal_direction and Pin.is_tristated. Channel include: Channel.is_sending. Pin.is_trisated <= FALSE when Pin.nominal_direction = OUTPUT and Channel(Pin.channel_id).is_sending = TRUE else TRUE; There is also a wormhole that allows the value of the is_tristated attribute to be mapped onto an appropriate tristate_enable pin of a buffer (in the IO domain). In implementation terms, this is a multiplexor and an AND gate, feeding into a tristateable output driver. The actual model is a bit more complex than this. (I do not consider the 'is_tristated' attribute to be domain polution because it is explicitly part of the protocol being modelled). There are various ways I can put this information into an SM model. The example above uses a VHDL based pseudo-code because hardware engineers understand it. With no standard action language in SM, its as good an any. (In fact, its better than many because VHDL has the correct semantics for signal updates in state actions - they don't occur until an action is complete) In SM, the sychronous service for a wormhole must be explicitly invoked. You can't set up sensitivity lists. Therefore whatever updates the tristate attribute must also invoke the wormhole. I would probably have to find where the pin direction and channel mode is set (there is more than one state where a channel is sending data) and, in all these places, explicitly recalculate the value of the is_tristated attribute and invoke the wormhole. You can argue that the purpose of analysis is to expose all possible information; and that identifying all actions that change the value of the attribute is necessary. However, my feeling is that, in this example, exposing the information actually confuses the issue and swamps the real issues. I can see arguements for both points of view. However, from a practical point of view, generating tight VHDL from the fully exposed model is vastly more complex (remember - its only 2 gates plus a tristate driver!). Of course, if the model is simple, then I can translate direct to code, without going via any CASE tools. The fact that the model isn't pure SM-OOA doesn't matter because the meta-model, the population data and the translation scripts are all treated as module-specific source code. Reuse may be compromised, but that isn't really an issue becuase the module as a whole is still reusable. Dave. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com Subject: Re: (SMU) Data types in OOA lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Whipp... > lahman wrote: > > The second situation would arise if there were something special > > about the way the dependent variable was computed. For example, > > suppose one obtains New Velocity and New Elapsed Time as event > > data and the calculation of distance was incrementally calculated > > based upon the differences between these and the > > velocity and elapsed time. Now the calculation > > _must_ wait until both values are available > > You seem to be suggesting a mathematical dependence between > event data and attributes. This goes beyond my definition. > I think of mathematical dependence as being a relationship > between the _current_ values of a set of attributes. What I was doing was citing a case where the circumstances of the problem space -- that New Velocity and New Elapsed time were input on different events and "distance" was computed incrementally -- presented a situation where the update could not be done correctly in the architecture without some explicit OOA modeling. distance = distance + ((New Velocity + velocity) / 2) * (New Elapsed Time - elapsed time)) requires that both values be available and that they be consistent. To do this correctly the OOA must wait until both New Velocity and New Elapsed Time are available before updating velocity and elapsed time so that the architecture can update distance. If the OOA immediately updates velocity or elapsed time when New Velocity or New Elapsed Time arrives the architecture cannot cope. Having said this, I _was_ talking about a mathematical dependence because I thought that was what this thread was about -- situations around the (M) notation. > The debate of implicit vs explicit update is similar to > a previous discussion regarding explicit linking of > relationships. I see no problems with the concept of a > mathematically dependent referential attribute whose value > is maintained by the architecture. Does anyone disagree? I assume you are not proposing that the instance identifiers are changed (i.e., the same two instances are related but somehow one has to change the name of one of them algorithmically). If you only meant that when a relationship is instantiated this can be done implicitly by the architecture algorithmically, then I agree. Subject: Re: (SMU) Between OOA and RD (was Data Types in OOA) Neil Lang writes to shlaer-mellor-users: -------------------------------------------------------------------- At 02:00 PM 11/19/97 -0500, you wrote: >lahman writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >Responding to Anderson... > >> 1) Our toolset is graphical in nature. We parse most of our critical >> information directly from diagrams. This includes the domain chart >> >> which guides and provides the framework for the rest of the >> parsing. >> What we found when working on the Domain Chart parsing was that >> the "classical" domain chart had information on it that we did not >> need or care about. Specifically, the "Software Architecture" >> domain >> and anything that it was the only client of. It turns out that >> these >> items were already encapsulated in our architecture (amazing, just >> what you would expect based on the classical domain chart!). We >> only >> needed the domains being analyzed and bridges to "realized" domains >> >> (except the SA, the parsing & translating is the bridge to the SA). >> >> 2) All of the analysis domains in the classical charts seem to bridge >> to the SA. Two impacts of this seem to be: >> A) It can make for a messy chart, and >> B) Since it is something that "everyone" knows, it is probably >> redundant information. > >I am not sure that the domain chart was designed to be used as a >translation input, other than to possibly to identify domains. The >domain chart is generally done very early in the development process to >get a handle on the overall structure of the system. In particular, it >is used to describe the flow of requirements form one domain to >another. In this sense it is more of a requirements document than a >design document. > I actually view the domain chart as a rather significant design document for organizing software. If you view each domain as a separate level of abstraction, or layer of indirection in your final software ( for instance each layer in the OSI network model can be represented as a separate domain), then the domain chart defines how many such levels you've chosen to organize your software. This in turn determines how modular and extensible your software will be. But more domains mean more models (albeit simpler ones) and more bridges to be developed as well as potentially more overhead in the final executable code. Like all system/software design issues, there are design criteria and associated trade-offs to be considered. And the domain chart is the document that captures all of this design effort. Since the code that you ultimately produce depends upon your choice of domains, I would definitely assert that a domain chart is a primary design document. Neil ---------------------------------------------------------------------- Neil Lang nlang@projtech.com Project Technology, Inc. 510-567-0255 x623 10940 Bigge Street San Leandro, CA 94577 http://www.projtech.com ---------------------------------------------------------------------- Subject: Re: (SMU) Data types in OOA Neil Lang writes to shlaer-mellor-users: -------------------------------------------------------------------- At 05:49 PM 11/24/97 -0800, >Neil Lang writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >I'm intrigued by your desire to make it the architecture's responsibility. >How can the architecture implement the correct processing, if the analyst >doesn't state when and how to do the computation? > then Dave Whipp writes: >The "when" is of no concern to the analyst - I doesn't matter >when the calculation is performed as long as the correct >value is returned when the dependent attribute is read. > >If an attribute is frequently read, and rarely written, then >early evaluation may be appropriate. If its frequently >written, but rarely read, then late evaluation may be >appropriate. This is an architectural issue and could be tuned >through coloration. Then HS in another posting shows examples where this is inappropriate: >There are two situations where I think it would be appropriate for the >OOA to handle the updating. The first is when both velocity and elapsed >time are updated, but it occurs in separate actions (e.g., different >events into the domain). Now an inconsistent value of the dependent >variable could exist in the domain between events. If this is important >to the flow of control of the OOA (i.e., somebody could access the >dependent value between updates), then the OOA is going to have to >handle this with a Wait state somewhere so that the independent >attributes are updated in the same action. (Note that the architecture >could still handle the calculation of the dependent variable; the OOA >merely has to constrain when this is done.) > >The second situation would arise if there were something special about >the way the dependent variable was computed. For example, suppose one >obtains New Velocity and New Elapsed Time as event data and the >calculation of distance was incrementally calculated based upon the >differences between these and the velocity and >elapsed time. Now the calculation _must_ wait until both values are >available, regardless of whether anyone might access the dependent >variable between the arrival of New Velocity and New Elapsed Time. >Otherwise the calculation of distance would still be >incorrect after both independent values were updated. (Again, the >architecture could handle the calculation but the OOA needs to constrain >when this happens -- either as a write accessor or transform that >accepts all four relevant values.) > > HS's examples reveal the real and complete job the analyst must do. In some cases it may be ok to update the dependent attribute immediately upon change in any of its constituents. But the world being modeled may be somewhat more complicated, and the analyst must first understand the constraints imposed by that world before he/she can specify when it's appropriate to recompute. But only the analyst knows this (there may be special cases where the decision can be inferred from structures in the model but I don't expect this to be the general case) and so I still stand by my original statement: >How can the architecture implement the correct processing, if the analyst >doesn't state when and how to do the computation? Neil ---------------------------------------------------------------------- Neil Lang nlang@projtech.com Project Technology, Inc. 510-567-0255 x623 10940 Bigge Street San Leandro, CA 94577 http://www.projtech.com ---------------------------------------------------------------------- Subject: Re: (SMU) Mathematical Dependence Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- Neil Lang wrote: > HS's examples reveal the real and complete job the analyst > must do. In some cases it may be ok to update the dependent > attribute immediately upon change in any of its constituents. > But the world being modeled may be somewhat more complicated, > and the analyst must first understand the constraints imposed > by that world before he/she can specify when it's appropriate > to recompute. But only the analyst knows this (there may be > special cases where the decision can be inferred from > structures in the model but I don't expect this to be the > general case) and so I still stand by my original statement: > >> How can the architecture implement the correct processing, if >> the analyst doesn't state when and how to do the computation? I must be missing something. By definition, mathematical dependence is independent of state. The definition, in OOA96, is: "An attribute Y is said to be mathematically dependent on a set of attributes X if, and only if, given values of attributes in X, the value of Y can be determined by a formula or algorithm." cannot see how this definition allows any special cases. If, given values of X, the value of Y cannot be unambiguously calculated, then Y is not mathematically dependent on X. It may be, that given a special case, S, that Y can be calculated given values of X and S. In that case, Y is mathematically dependent on (X union S). This expression could be substituted for X in the definition above. You may wish to argue that mathematical dependence is rare, but that is a different issue. OOA96 assumes (page 8) "... attributes of this nature arise fairly commonly in applications ..." - who am I to argue? ;-) Dave. Not speaking for GPS. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com Subject: Re: (SMU) Mathematical Dependence Mike Frankel writes to shlaer-mellor-users: -------------------------------------------------------------------- The problem that is introduced by Mathematical Dependence is that the formula which defines the dependence is a transformation process which has no "home" in asynchronous (state actions) or synchronous (synch services) part of the model. The analyst has no way to define which it is to be. I have no problem with the concept, in fact we find it useful from time to time. However, you can't have your cake and eat it to. You can't introduce a mechanism for defining transformations outside the scope of state actions and synch services, and then say that the analyst must account for when it is to be executed, when in fact that very capability has been taken away. By introducing the concept of mathematical dependence, a third and separate execution semantic has been added. Imagine an OOA model has 10 mathematically dependent attributes, with their formulas defined in the data dictionary. By stating these transformations in this fashion as opposed to making them explicit state actions, the analyst is saying: "I don't care when these attributes get updated, so long as the values are *as accurate as I need them to be*". It is then up to the architecture team to provide strategies for "when" to perform the transformations, and to color the attributes accordingly. In a previous message Carolyn Duby introduced 2 architectural strategies: 1. Execute formula upon update to any input attribute 2. Execute formula upon request to access dependent attribute There is also another strategy which we have used which is: 3. Execute formula every n seconds, where n is often enough to provide necessary accuracy. 5 of the 10 dependent attributes could be colored to be updated on a 10 ms cycle, while 2 are updated upon request, and the remaining 3 are updated whenever their input variables change. There is no way around it. Mathematical Dependence extends the SM execution semantics. We now have asynchronous, synchronous, and mathematically dependent. If the unknown "when" of the formula execution is a problem for the analyst, they either have to be confident that the architecural team will provide a satisfactory strategy to map to, or they should simply stick to explicit state action transformations. They can't have both. -- ----------------------------------------------- Mike Frankel Director of Software Engineering Esprit Systems Consulting, Inc. 610-436-8290 fax 610-436-9848 mfrankel@EspritInc.com http://www.EspritInc.com -->BASELINE Domain Models -->Object Methods Training and Consulting -->Structured Methods Training and Consulting "Strategies for Computer and Human Systems" ----------------------------------------------- 'archive.9712' -- Subject: Re: (SMU) Between OOA and RD (was Data Types in OOA) lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Lang... > I actually view the domain chart as a rather significant design > document > for organizing software. If you view each domain as a separate level > of > abstraction, or layer of indirection in your final software ( for > instance > each layer in the OSI network model can be represented as a separate > domain), > then the domain chart defines how many such levels you've chosen to > organize > your software. This in turn determines how modular and extensible your > > software will be. But more domains mean more models (albeit simpler > ones) > and more bridges to be developed as well as potentially more overhead > in the final executable code. Like all system/software design issues, > there are design criteria and associated trade-offs to be considered. > And the domain chart is the document that captures all of this design > effort. An interesting spin and I can certainly see how it might apply in certain situations. But we tend to have a lot of domains because we like the firewalls that they provide so that we can have developers working in parallel. (Defining the bridge firewalls sets the requirements for the domains, allowing parallel development without stepping upon one another's toes.) As a result most of the domains in a given area of our domain chart will tend to be at the same level of abstraction (e.g., Service domains lower than Application and Implementation domains lower than Service domains). > Since the code that you ultimately produce depends upon your choice of > domains, > I would definitely assert that a domain chart is a primary design > document. BTW, I was not arguing that it is not a significant design document. My point was that it is at such a high level (i.e., closer to requirements than implementation) that I don't see much information that could be used directly by the translation by simply parsing the diagram. Subject: Re: (SMU) Data types in OOA lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Lang... > HS's examples reveal the real and complete job the analyst must do. > In > some cases it may be ok to update the dependent attribute immediately > upon change in any of its constituents. But the world being modeled > may > be somewhat more complicated, and the analyst must first understand > the constraints imposed by that world before he/she can specify when > it's appropriate to recompute. But only the analyst knows this (there > > may be special cases where the decision can be inferred from > structures in the model but I don't expect this to be the general > case) > and so I still stand by my original statement: > > >How can the architecture implement the correct processing, if the > analyst > >doesn't state when and how to do the computation? I am not sure that this is the issue. You are correct that somebody has to define the computation and this is logically the analyst who is familiar with the problem space. But as I see it the issue is _where_ that statement is placed: the OOA or the architecture. In each of my examples that you quoted, I was careful to note that the architecture could handle the calculation. My intent was to underscore the idea that some stuff related to the problem space can be defined in the RD even when one must explicitly deal with some facets in the OOA. My point in the examples was that there are _some_ situations where one needs to handle things explicitly in the OOA. However, I generally agree with Whipp in that I tend to view these situations as the exception rather than the rule. If there is a general rule, I would think it might go something like this: If there is an aspect of the calculation that might affect flow of control at the level of abstraction of the domain, then the analyst needs to account for that aspect in the domain OOA; but all other aspects of the calculation specification that do not affect domain flow of control belong in the RD. Subject: Re: (SMU) Mathematical Dependence lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Frankel ... > The problem that is introduced by Mathematical Dependence is > that the formula which defines the dependence is a transformation > process which has no "home" in asynchronous (state actions) or > synchronous (synch services) part of the model. The analyst has no > way to define which it is to be. I have no problem with the > concept, in fact we find it useful from time to time. However, > you can't have your cake and eat it to. I am not sure I buy this assessment. I have always regarded the (M) update as being an issue for a synchronous accessor. As Duby suggested this would typically be the dependent read accessor or the independent write accessor. I would add that it could also be the dependent write accessor, per the example below. > By introducing the concept of mathematical dependence, a third and > separate execution semantic has been added. > > There is also another strategy which we have used which is: > > 3. Execute formula every n seconds, where n is often enough to provide > > necessary accuracy. > > 5 of the 10 dependent attributes could be colored to be updated on > a 10 ms cycle, while 2 are updated upon request, and the remaining > 3 are updated whenever their input variables change. The last five are clearly just selections of read or write accessors for the update in the RD. But the first five are interesting because they do not seem to be associated with read/write accessors. Still I am not convinced that this is a new execution semantic. First, let's look at the case where the nature of the updating is somehow important to the domain (i.e., the 10 ms cycle needs to be explicit through some sort of timing events in the OOA). Now the OOA is handling the issue of when the data is consistent and the architecture could handle the update via a simple minded write accessor for the dependent attributes (arguments would be instance identifiers rather than attribute values). In this case the architecture's job is routine -- it merely has to ensure that no one is changing the values of the independent attributes in the scope of the write accessor. No different semantic here. The interesting case is where one decides to move the entire strobe timing process into the Architecture. Now the independent attributes are being updated asynchronously at random intervals while the dependent attributes are being updated synchronously on a fixed interval that is unknown in the OOA. I would argue that in this case the dependent attributes are updated through the same synchronous write accessors as in the preceding paragraph. The difference is that these accessors are invoked by a bridge from the timing routines in the architecture. I don't see a different execution semantic here because this is exactly what would happen if there were no independent attributes (i.e., the "dependent" attributes were written directly from a bridge that happened to supply the values to write). The difference lies only in where the architecture gets the values to write into the "dependent" attributes when the bridge from the Architecture is invoked. > If the unknown "when" of the formula execution is a problem for > the analyst, they either have to be confident that the architecural > team will provide a satisfactory strategy to map to, or they should > simply stick to explicit state action transformations. They can't > have both. In the strobe-and-average example the "when" is reflected in whether the timing of the update is important to the domain. If it is, then there have to be timing events and the update is controlled in the OOA in response to those events. This would be the case if the dependent attributes were means but you also needed to occasionally compute variances that were not attributes. The data elements used for the variance calculation had better by consistent with the value of the mean used, so the OOA is going to have to explicitly guarantee this. If the timing is not important in the domain, then all the timing issues may be moved to the RD and enforcement of data consistency is at least as simple as it would be for multiple, non-dependent data accesses in an action. This might be the case if the dependent attributes were running averages with different periods and the sample size was sufficiently large so that they could be computed independently. In either case the Analyst is going to have to specify the timing issues (i.e., either in the OOA or in the RD). I regard this is part of the definition of the dependence of the attributes. The Analyst is also going to have to decide whether exposing the timing in the OOA is necessary to satisfy the requirements of the problem space. Once the decisions are made and the timing specified, everything should Just Work because the architecture team will have sufficient information to guarantee data consistency. Subject: Re: (SMU) Mathematical Dependence Mike Frankel writes to shlaer-mellor-users: -------------------------------------------------------------------- lahman wrote: > > lahman writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Responding to Frankel ... > > > The problem that is introduced by Mathematical Dependence is > > that the formula which defines the dependence is a transformation > > process which has no "home" in asynchronous (state actions) or > > synchronous (synch services) part of the model. The analyst has no > > way to define which it is to be. I have no problem with the > > concept, in fact we find it useful from time to time. However, > > you can't have your cake and eat it to. > > I am not sure I buy this assessment. That's okay. It's not for sale. I have always regarded the (M) > update as being an issue for a synchronous accessor. As Duby suggested > this would typically be the dependent read accessor or the independent > write accessor. I would add that it could also be the dependent write > accessor, per the example below. OOA96 says *nothing* about when the formula which defines the dependence is to be executed. Just that there is a formula which must be defined. That formula, by definition, is part of the OOA of the domain, just as much as any state action block, or attribute definition. >From an accessor point of view, the value just needs to be there, regardless of how it gets there, similar to the notion of sensor-based attributes. Except these are formula-based attributes. > > > By introducing the concept of mathematical dependence, a third and > > separate execution semantic has been added. > > > > > There is also another strategy which we have used which is: > > > > 3. Execute formula every n seconds, where n is often enough to provide > > > > necessary accuracy. > > > > 5 of the 10 dependent attributes could be colored to be updated on > > a 10 ms cycle, while 2 are updated upon request, and the remaining > > 3 are updated whenever their input variables change. > > The last five are clearly just selections of read or write accessors for > the update in the RD. But the first five are interesting because they > do not seem to be associated with read/write accessors. Still I am not > convinced that this is a new execution semantic. > > First, let's look at the case where the nature of the updating is > somehow important to the domain (i.e., the 10 ms cycle needs to be > explicit through some sort of timing events in the OOA). If the timing (when) of the formula execution is inherent to the domain, then the formula should be specified in the context of a state action block responding to a timing event. If the formula needs to be "invoked" from more than one state action block, it can be factored out into an object-level synch service (a common OOA case tool feature), or repeated in each corresponding action block. If the author of OOA96 wants to be more explicit about when the formula is to be executed, they could introduce a reference in action language which would cause the formula defined in the dictionary to be invoked upon any reference to the attribute. For example: Generate OB1:Event ( M(attribute)) could force calculation of a dependent attribute at that moment of reference, while the same statement without the M would reference the last value calculated. OOA96 was not complete in its treatment of this concept, and leaves too much open to conjecture, impeding its own adaptation as a standard. Until completed, or abandoned, we can all come up with our own solutions so long as they make our lives and projects easier to manage. It is likely that the final result will be a mixture of all our experiences. Real projects wait for no man! -- ----------------------------------------------- Mike Frankel Director of Software Engineering Esprit Systems Consulting, Inc. 610-436-8290 fax 610-436-9848 mfrankel@EspritInc.com http://www.EspritInc.com -->BASELINE Domain Models -->Object Methods Training and Consulting -->Structured Methods Training and Consulting "Strategies for Computer and Human Systems" ----------------------------------------------- Subject: (SMU) Dependency Nomenclature Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- I have a question regarding the nature of client-server relationships on the domain chart. I think I have the concepts nailed down - its just that words seem to be multiply overloaded. On a domain chart, arrows are drawn, depicting the direction of a client-server relationship. This relationship is defined by the propogation of instance information. The client is the domain that controls what instances are needed in the server (though, of course, it doesn't know what those instances are!) For example, in the train controller example, the application domain knows what trains exist, so it controls what icons are needed in the user interface domain. It is therefore the client and the UI is the server. However, it doesn't know that the user interface is using icons. I thinks thats fairly straight forward. However, when you talk about implementation, you get a different set of client-server relationships. These tend to be based around the concept of thread-of-control. The client makes requests of the server. So, if the UI asked the train controller [bridge] how many icons it needs, then the UI would be the client and the train controller is the server. At really low levels of implementation detail, the client- server relationship may be defined in terms of caller and callee of a function. At this point, the client- server relationship is generally defined between bridges and domains (a bridge may be either a client or a server, depending on its interactions) So, I have several different concepts, but they all seem to be called client-server relationships. Documents can become rather confusing if its not clear which concept is being discussed. So I am wondering how the wider SM community deals with naming all these concepts. Dave. Not speaking for GPS. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com Subject: Re: (SMU) Mathematical Dependence lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Frankel... > OOA96 says *nothing* about when the formula which defines the > dependence > is to be executed. Just that there is a formula which must be > defined. > That > formula, by definition, is part of the OOA of the domain, just as much > > as > any state action block, or attribute definition. I have to disagree. The formula would never appear in the OOA. I believe it would always live in either a read/write accessor or in a transform. As such it would always be realized code. Therefore it is more properly a specification for the RD. I would think the proper place for the algorithm description would be in the ADFD process description. This is quite different than a state action description. The state action is part of the simulatable model and it is the basis for the ADFD. OTOH, the process description is not simulatable and it is an instruction to the code generator. > If the author of OOA96 wants to be more explicit about when the > formula > is to > be executed, they could introduce a reference in action language which > > would > cause the formula defined in the dictionary to be invoked upon any > reference > to the attribute. For example: Generate OB1:Event ( M(attribute)) > could > force calculation of a dependent attribute at that moment of > reference, > while > the same statement without the M would reference the last value > calculated. As I indicated above, I believe the mechanism already exists in ADFD accessors and transforms. Subject: Re: (SMU) Mathematical Dependence Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- lahman wrote: > > lahman writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Responding to Frankel... > > > OOA96 says *nothing* about when the formula which > > defines the dependence is to be executed. Just that > > there is a formula which must be defined. That > > formula, by definition, is part of the OOA of the > > domain, just as much as any state action block, or > > attribute definition. > > I have to disagree. The formula would never appear in > the OOA. I believe it would always live in either a > read/write accessor or in a transform. As such it would > always be realized code. Therefore it is more properly > a specification for the RD. I would think the proper > place for the algorithm description would be in the ADFD > process description. This is quite different than a > state action description. The state action is part of > the simulatable model and it is the basis for the ADFD. > OTOH, the process description is not simulatable and it > is an instruction to the code generator. I have to disagree. (How's that for a bit of agreement :-)) The OOA96 view appears to be that the formula is part of the attribute description. I would agree that it is associated with the attribute, but would give it a more formal status. Consider referential attributes. Formalisation is not needed to execute an OOA model. All relationship navigations can be expressed as searches using the referential attribute as a key. Some action languages permit shortcut navigations (A -> B) but that is not part of OOA. Similarly, the link/unlink operations are not part of OOA. It is therefore possible to argue that formalisation is part of RD, not OOA. However, relationship formalisation does form an important part of the analysis activity - they let you validate your information model. Similarly, Mathematical dependencies are important. However, unlike formalisation, it is not possible to execute a model that uses mathematical dependence unless the formula is explicity stated (unless you calculate the dependency explicitly in the state actions). Mathematical dependence is not a property of an accessor - its a property of an attribute. If you insist on the analyst choosing where/when the calculation is performed, what critera are used to decide which execution model to use - early, late, continuous and periodic evaluation are all possible. You can't put the formula in the RD because its needed in the OOA. You can't but the when/where in the OOA because its dependent on the implementation. However, you can put the formula in the OOA and and when/where in the RD. The when/where should not effect the results of model execution (except as allowed within the OOA execution rules). The contract with the architecture is clear. When an attribute is read, the correct value is returned. Dave. Not speaking for GPS. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com Subject: Re: (SMU) Dependency Nomenclature lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Whipp... > So, I have several different concepts, but they all seem to be > called client-server relationships. Documents can become rather > confusing if its not clear which concept is being discussed. > > So I am wondering how the wider SM community deals with naming > all these concepts. I agree that the phrase is badly overloaded. (In fairness to S-M, I don't recall the bibles specifically referring to "client-server"; usually they express the ideas in terms of "clients" and "services".) Since "client-server" in the domain chart is significantly different than the conventional definition, I would argue for not using that. It tends to be very confusing for newcomers to S-M; one keeps hearing the question, "In a GUI application the message loop is the core of the system and it is the source of all service demands, so why do you bury it in a low level service or implementation domain rather than putting it in the Application domain?" I think one needs a word to describe domains that set requirements and another word for domains that satisfy requirements. Unfortunately, "client" and "service" seem to do nicely and everything else I come up with sounds stilted (demander, requireer, provider, etc.). So we have just not used the phrase "client-server". Instead we just refer to the Bridges, which are tacitly defined as a set of requirements. Alas, this also overloads "bridge". All in all, I would be happier if we referred to the links between domains on the Domain Chart simply as "requirements" or "requirement flows". Given the current, rather specialized MIS definition of "client-server", we tend not to use it at any level. At the individual bridge request level, we do not describe things in terms of clients or services at all. The problem is that sometimes the service domain needs more information and it initiates a request for that information to the original client. (Diagnostics is a classic example: the domain providing diagnostic services needs to have the probe placed in a different spot and the test rerun, so it requests this through its client since it knows only about UUT circuits and nothing about specific tester hardware.) Instead we usually treat the individual bridges simply as communications. Subject: Re: (SMU) Mathematical Dependence lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Whipp... > I have to disagree. (How's that for a bit of agreement :-)) But I disagreed first! > The OOA96 view appears to be that the formula is part of the > attribute description. I would agree that it is associated > with the attribute, but would give it a more formal status. OOA96 is in the eye ot the beholder. The (M) designation is certainly associated with the attribute, but I didn't see anything about where the formula was placed. It never occurred to me that it would be put anyplace else than in a process description. > Consider referential attributes. Formalisation is not needed > to execute an OOA model. All relationship navigations can > be expressed as searches using the referential attribute as > a key. Some action languages permit shortcut navigations > (A -> B) but that is not part of OOA. Similarly, the > link/unlink operations are not part of OOA. It is therefore > possible to argue that formalisation is part of RD, not OOA. Perhaps we have a different view of "formalization". I would argue that the referential attributes represent a high degree of formalization of the relationship -- precisely because they do allow execution of an OOA model. But I agree with the last two sentences. (Though Lang and I have debated the utility of link/unlink offline and he has some persuasive arguments that they do add something to the OOA, but that's another story...) > However, relationship formalisation does form an important > part of the analysis activity - they let you validate your > information model. Similarly, Mathematical dependencies are > important. However, unlike formalisation, it is not possible > to execute a model that uses mathematical dependence unless > the formula is explicity stated (unless you calculate the > dependency explicitly in the state actions). Mathematical > dependence is not a property of an accessor - its a property > of an attribute. As far as executing the model is concerned, I see no difference between a mathematical dependency and a transform that computes the value to be stored in an independent attribute. By the time the attribute value is accessed and tested to modify flow of control in the model execution, it would not matter whether it was computed in the transform or as a mathematical dependence -- your ability to execute the model would still depend upon knowing what went on in the computation. If that information is not available to the OOA in the transform case, why should it be available in the dependency case? Conversely, why would you not store (document) the dependency calculation in the same way you would store (document) the transform calculation? > If you insist on the analyst choosing where/when the > calculation is performed, what critera are used to decide > which execution model to use - early, late, continuous > and periodic evaluation are all possible. I think making this choice is unavoidable for the analyst in certain situations, as I hope a couple of my examples posted earlier demonstrated. Whenever data consistency issues extend beyond the scope of an action because of problem space considerations, the analyst has the responsibility of dealing them. In these special situations I see the analyst making two decisions. The first is to determine where the calculation will reside -- this is usually just a choice of which accessor the calculation will live in. (The periodic case is somewhat more complicated, but basically a decision over whether to include the timing in the OOA or the architecture.) The second decision is to construct the OOA so that it works correctly, given the first decision and the problem space requirements. This second part is no different than any other modeling where one has to account for the vagaries of asynchronous processing -- the problem space determines what can happen and the analyst provides for it. If the situation is not particularly special, the analyst simply has to decide which accessor the calculation should go in and lets the translation do the rest. Subject: Re: (SMU) Mathematical Dependence Mike Frankel writes to shlaer-mellor-users: -------------------------------------------------------------------- lahman wrote: > > lahman writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > > I have to disagree. The formula would never appear in the OOA. I > believe it would always live in either a read/write accessor or in a > transform. As such it would always be realized code. Therefore it is > more properly a specification for the RD. I would think the proper > place for the algorithm description would be in the ADFD process > description. In the middle of writing a response to this which stated that you must be using SM on another planet, I realized that there are a couple issues which are core to the resolution which are being confused. First, forget ADFDs vs. Action Language. You apparently like ADFDs, where we prefer Action Language blocks in states. So, for argument sake, I'll play in your ballpark. Forget specification vs. formula. There is an algorithm, whether it is query based or equation based or both, for deriving an attribute value from one or more other attribute values. This algorithm is the product of the domain subject matter expert, and therefore an element of the domain OOA. In your ballpark, this normally appears as the specification of a transformation process on an ADFD. In the case of mathematical dependence, the algorithm appears as part of the definition of the attribute. Only an expert in the subject matter of business finances can produce the correct algorithm for deriving the profit attribute value from the existing expense and revenue attribute values. There may even be 5 different worthwhile and industry accepted algorithms, though they are all products of the minds of business finance domain subject matter experts. It is *not* within the realm of architecture definition to define the algorithm for producing a profit value from expense and revenue values. Of course, every algorithm in the OOA, whether it appears in an ADFD transformation process spec, synch service spec, or a dependent attribute definition, will have to be translated by the architecture into an executable code version. Maybe this is what you are calling the formula. Second, there appears to be some expectation that because the algorithm for deriving the dependent attribute is "extra", that is, not really necessary for executing the rest of the OOA model, that it is not the product of the domain subject matter expert. I say this is a fallacy, because even though it is functionally redundant within the OOA, it is still *within* the OOA. If you still disagree, I will have to revert back to the "other planet" theory. -- ----------------------------------------------- Mike Frankel Director of Software Engineering Esprit Systems Consulting, Inc. 610-436-8290 fax 610-436-9848 mfrankel@EspritInc.com http://www.EspritInc.com -->BASELINE Domain Models -->Object Methods Training and Consulting -->Structured Methods Training and Consulting "Strategies for Computer and Human Systems" ----------------------------------------------- Subject: Re: (SMU) Dependency Nomenclature David Yoakley writes to shlaer-mellor-users: -------------------------------------------------------------------- Dave Whipp wrote: > > Dave Whipp writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > I have a question regarding the nature of client-server > relationships on the domain chart. I think I have the concepts > nailed down - its just that words seem to be multiply > overloaded. > > On a domain chart, arrows are drawn, depicting the direction of > a client-server relationship. This relationship is defined by > the propogation of instance information. The client is the > domain that controls what instances are needed in the server > (though, of course, it doesn't know what those instances are!) > > For example, in the train controller example, the application > domain knows what trains exist, so it controls what icons are > needed in the user interface domain. It is therefore the client > and the UI is the server. However, it doesn't know that the user > interface is using icons. > > I thinks thats fairly straight forward. However, when you talk > about implementation, you get a different set of client-server > relationships. These tend to be based around the concept of > thread-of-control. The client makes requests of the server. So, > if the UI asked the train controller [bridge] how many icons it > needs, then the UI would be the client and the train controller > is the server. > > At really low levels of implementation detail, the client- > server relationship may be defined in terms of caller and > callee of a function. At this point, the client- server > relationship is generally defined between bridges and domains > (a bridge may be either a client or a server, depending on its > interactions) > > So, I have several different concepts, but they all seem to be > called client-server relationships. Documents can become rather > confusing if its not clear which concept is being discussed. > > So I am wondering how the wider SM community deals with naming > all these concepts. > I share your frustration. I recently implemented domain distribution using CORBA and the terminology only got worse. Using CORBA, any entity that fields requests is a server. Because the client domains often fielded responses from servers, the clients were considered servers to CORBA. I found it helpful to think in terms of OOA but I still had to do lots of explaining when talking about implementation. Maybe I should have coined the terms OOA Client and OOA Server and XXX Client and XXX Server where XXX was Corba in this case. Now things still got confusing at the OOA level when thinking and talking about cases were servers asynchronously respond to clients. This is the case you refered to. I prefer not to view this as a server playing a client role. I prefer to think of it as a special server service which I call "server callback". To me this is the very essence of client-server. We want servers to be re-usable. But how can they be re-usable if they know anything about clients (e.g. the client id, or even the client service to invoke)? Part of the answer is the tranfer vector compliments of OOA-96. This allows clients to register themselves with the server so that the server has no knowledge of who is making a request. The second part deals with the actual service invoked by the server. This is handled by requiring the server to define exactly which service callback it can make. The clients must provide corresponding services and the bridges must provide the mapping. Quick note on Lahman's response regarding UIS/GUI. I still see the UIS as a service. It can have a message loop but in order to promote good re-use it should not be considered a client. Ask yourself how the UIS knows what features are appropriate to enable to the user? They correspond to specific application states. So I agrue that the application is still in control. The application decides what types of inputs it wants and it asks for them. These input requests map to UI widgets that get enabled and UI callbacks that get registered for. ________________________________________________________________________ David Yoakley Objective Innovations Inc. Phone: 512.288.5954 14606 Friendswood Lane Fax: 512.288.6381 Austin, TX 78737 Replies: yoakley@oiinc.com ________________________________________________________________________ Did you ever notice when you blow in a dog's face he gets mad at you? But when you take him in a car he sticks his head out the window! Steve Bluestone Subject: Re: (SMU) Mathematical Dependence David Yoakley writes to shlaer-mellor-users: -------------------------------------------------------------------- OOPS. I accidentally posted this directly to lahman earlier today. lahman wrote: > > lahman writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Responding to Frankel... > > > OOA96 says *nothing* about when the formula which defines the > > dependence > > is to be executed. Just that there is a formula which must be > > defined. > > That > > formula, by definition, is part of the OOA of the domain, just as much > > > > as > > any state action block, or attribute definition. > > I have to disagree. The formula would never appear in the OOA. I > believe it would always live in either a read/write accessor or in a > transform. As such it would always be realized code. Therefore it is > more properly a specification for the RD. I find this statement very confusing. You argue that it is not in the OOA and then argue that it is in a read/write accessor or in a transform. Are these not part of the OOA? Your point is well taken that the formula is a specification to the RD. But then again so is everything in the OOA. I have to side with Dave Whipp. The formula should be part of the attribute description. NOT a new state process. NOT a new attribute domain. But maybe there is some middle ground. There is processing going on so it makes sense that the formula be a process. The transform seems to fit the bill in terms of the types of processes offered. Maybe all we are saying is that a mathematically dep. attribute has a transform process attached to the attribute description. The RD is free to choose implementation as long as the accessors to the attribute are guaranteed that the value "returned" is consistent with the inputs (e.g. inputs change, formula must be re-evaluated). Could the fact that your CASE tool treats transforms as RD specs (free text) be slanting your view? I also would like to see some examples of how attaching the formula to the attribute description limits the RD implementation. dy Subject: Re: (SMU) Mathematical Dependence lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Yoakley... > > I have to disagree. The formula would never appear in the OOA. I > > believe it would always live in either a read/write accessor or in a > > > transform. As such it would always be realized code. Therefore it > is > > more properly a specification for the RD. > > I find this statement very confusing. You argue that it is not in the > > OOA and then argue that it is in a read/write accessor or in a > transform. Are these not part of the OOA? Your point is well > taken that the formula is a specification to the RD. But then > again so is everything in the OOA. The accessors and transforms are certainly part of the OOA. However the _content_ of ADFD processes is not part of the OOA. At best one has a free-form description of the process that has no formal syntax or guidelines for semantics. ADFD processes contain realized code that does not affect flow of control in the model (i.e., events can only be generated from event generator processes). Thus the description is simply a means to describe to the writer of the realized code what needs to be done (or what library routine in the architecture needs to be called). The realized code, by definition, is not in the domain being modeled. In practice the action languages allow the analyst write the processes, but in so doing this is an extension beyond the ADFD paradigm. In my view the OOA description stops at the ADFD process boundary. > I have to side with Dave Whipp. The formula should be part of the > attribute description. NOT a new state process. NOT a new > attribute domain. But maybe there is some middle ground. There is > processing going on so it makes sense that the formula be a process. > The transform seems to fit the bill in terms of the types of processes > > offered. I agree it does not require a new state process or attribute domain. I would argue that a transform _exactly_ fits the bill and that is the crux of my argument. I see no difference between a transform that computes a dependency calculation vs. a transform that modifies data prior to storing it in an attribute. Both transforms execute a calculation and when you access the attribute after the data is stored the result is identical in both cases. Moreover, any complications related to when it is appropriate to invoke the transform apply in the same way in both cases. That is, the inputs to the transform that modifies data prior to storing it have to be consistent just as the independent attributes have to be consistent. As it happens I see no reason why the dependency calculation can't also be in a read or write accessor as well. One is already allowed to massage data (e.g., convert meters to furlongs) when storing or accessing attributes, so I see no to limit dependency calculations to transforms. > I would like to see some examples of how attaching the formula to > the attribute description limits the RD implementation. I am not saying that attaching it to the attribute won't work. I am just saying that it would be inconsistent to do that when one already attaches realized calculations to ADFD processes. Why not use the mechanism that already exists in the methodology for holding realized calculations? Subject: Re: (SMU) Mathematical Dependence Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- I've been trying to think of a good meaphor for my view of mathematical dependance. I think I've found it. A speadsheet is essentially a big table, in which each cell can hold a value. It is possible to organise a speadsheet so that distinct areas can represent different tables. Each of these tables can represent an object. The column headings describe the object and the rows of the table represent instances of these objects. Thus the columns are the attribute values of instances. I'm sure there's nothing too strange there. A speadsheet also allows you to define a cell's value by assigning it a formula. Such formulae can generally be applied to a column fairly easily. In the days of old, slow, computers it was necessary to use a "calculate speadsheet" command before you used the values of the calculated columns. On faster machines you can just turn on auto-calculate. I think these two modes of operation are reasonably analagous to early- and late- evaluation techniques; though its possible that the auto-calculation mode may be periodic. Whichever technique is used, the caculation is uneffected. The calculation is associated with the table itself - not with people sitting down and using the spreadsheet. A user can turn auto-calculate mode on or aff as appropriate for the speed of the machine at that time. This might vary depending on time of day on a multi-user machine. Either way, before they printed out the results they would make sure they were up-to-date. Image the situation of the calculation was placed outside the spreadsheet, in a transform process. The speadsheet would never need to be recalculated because there would be no dependent cells. But it wouldn't be very useful. Dave. Not speaking for GPS. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com Subject: Re: (SMU) Mathematical Dependence lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Frankel... > In the middle of writing a response to this which stated that you must > > be using SM on another planet, I realized that there are a couple > issues > which are core to the resolution which are being confused. > > First, forget ADFDs vs. Action Language. You apparently like ADFDs, > where > we prefer Action Language blocks in states. So, for argument sake, > I'll > play > in your ballpark. As it happens we use an action language. However, the current official statement of the methodology is in terms of ADFDs. Until the Long Awaited RD Book introduces an action language specification into the methodology it is best to stick with the ADFD view because this avoids getting embroiled in issues around action language extensions. One of the major extensions that action language currently provide is no clear distinction between state actions and realized code in synchronous services. This severely blurs the boundary between the architecture and the OOA. When one writes an action language synchronous service for an algorithm one has the illusion of simply extending the state action when, in fact, one is often writing architectural code. > Forget specification vs. formula. There is an algorithm, whether it > is > query > based or equation based or both, for deriving an attribute value from > one or more other > attribute values. This algorithm is the product of the domain subject > > matter > expert, and therefore an element of the domain OOA. In your ballpark, > > this > normally appears as the specification of a transformation process on > an > ADFD. > In the case of mathematical dependence, the algorithm appears as part > of > the > definition of the attribute. Here we disagree. The only thing that currently is attached to the attribute is the (M) designation that indicates that a dependency _exists_. I did not see anything in OOA96 about where the description of the algorithm goes or where one even identifies which independent attributes go with the dependent attribute. However, the methodology already defines a place to encapsulate realized code for algorithms: the ADFD process. > It is *not* within the realm of architecture definition to define the > algorithm for > producing a profit value from expense and revenue values. Nobody says the architecture defines problem space issues. However, not all problem space issues are relevant to the OOA. Some are only relevant to the RD. As a general rule most algorithmic processing is captured in realized code that is not directly expressed in the OOA. Why would a dependency calculation be different than, say, converting milliseconds to seconds when accessing an attribute? > Second, there appears to be some expectation that because the > algorithm > for deriving the dependent attribute is "extra", that is, not really > necessary for executing the rest of the OOA model, that it is not the > product of the domain subject matter expert. I say this is a fallacy, > > because even though it is functionally redundant within the OOA, it is > > still *within* the OOA. Yes, I think that the dependency algorithm itself is usually not relevant to the OOA. (I won't repeat the examples I cited earlier in the thread about situations where the the timing of the calculation needs to be explicitly accounted for in the OOA.) But this is another facet of the same assumption you seem to have that all problem space issues need to be reflected in the OOA. This is clearly not true for things like performance requirements, networking context, databases to be used, and a flock of other things that may well be key business requirements but that are only relevant to the RD. Typically the only algorithms that are explicitly represented in the OOA are the high level flow-of-control algorithms for the overall application. Most algorithms are represented in the 50-80% of the code that is realized within bridges and ADFD processes. This is not part of the OOA formalism and the descriptions of the processing that appear in ADFD process descriptions are, in effect, instructions to the RD. It happens to be convenient to capture some of these RD instructions in OOA descriptive text. In keeping with Whipp's admonition of one-fact-one-place I think I would like to see more RD formalism incorporated in the OOA documentation. However, if that is done I would want it to be crystal clear which information is relevant to the OOA and which is relevant to the RD so that implementation does not creep into the OOA. > If you still disagree, I will have to revert back to the "other > planet" > theory. I still disagree. Just don't beam me up, Scotty. Subject: Re: (SMU) Mathematical Dependence Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- Lahman wrote: > I agree it does not require a new state process or attribute > domain. I would argue that a transform _exactly_ fits the > bill and that is the crux of my argument. Well, this comes back to the definition of a transform. Calculation of dependency undoubtedly requires accessors as well as transforms because we have to read all the source attributes and then write the dependent one. If you allow transforms to access data then the dependency could be expressed as a transform. However, I'd be tempted to use DFD of some variety (I don't think that either ADFDs or SDFDs quite fit; perhaps I want a "Monitor" DFD [MDFD?] that watches over the model ... or perhaps that'd be feature creap) > Typically the only algorithms that are explicitly represented > in the OOA are the high level flow-of-control algorithms for > the overall application. Most algorithms are represented in > the 50-80% of the code that is realized within bridges and > ADFD processes. This is not part of the OOA formalism and the > descriptions of the processing that appear in ADFD process > descriptions are, in effect, instructions to the RD. Taking this view then I would revert to arguing that the dependence is described in the Attribute Description. I'll use the one-fact-one-place argument: Every Attribute may be read and written from many places - both from state actions and synchronous services. The OAM shows this. If you place the calculation of dependency in the accessor process decriptions then you would have to place it in all accessor process that interact with any of the attributes in the dependency set. You might let some implementation detail creap in and decode to limit it to either only the read accessors or only the write accessors. I know you can reduce the workload by considering the difference between base and derived processes; but there may still be many base processes the read or write a given attribute. If you place the dependency in the attribute description then you only have to put it in one place. The RD can refer to it, as appropriate, depending on the evaluation scheme being used. However, if you want to simulate the model then you need something a bit more formal than an attribute description. Personally I'd like to see an unamiguous specification of all processes within the OOA. languages like VDM or Z may be more appropriate the procedural action languages that are commonly used. Dave. Not speaking for GPS. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com Subject: Re: (SMU) Mathematical Dependence David Yoakley writes to shlaer-mellor-users: -------------------------------------------------------------------- lahman wrote: > > lahman writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Responding to Yoakley... > > > > I have to disagree. The formula would never appear in the OOA. I > > > believe it would always live in either a read/write accessor or in a > > > > > transform. As such it would always be realized code. Therefore it > > is > > > more properly a specification for the RD. > > > > I find this statement very confusing. You argue that it is not in the > > > > OOA and then argue that it is in a read/write accessor or in a > > transform. Are these not part of the OOA? Your point is well > > taken that the formula is a specification to the RD. But then > > again so is everything in the OOA. > > The accessors and transforms are certainly part of the OOA. However the > _content_ of ADFD processes is not part of the OOA. At best one has a > free-form description of the process that has no formal syntax or > guidelines for semantics. ADFD processes contain realized code that > does not affect flow of control in the model (i.e., events can only be > generated from event generator processes). Thus the description is > simply a means to describe to the writer of the realized code what needs > to be done (or what library routine in the architecture needs to be > called). The realized code, by definition, is not in the domain being > modeled. > > In practice the action languages allow the analyst write the processes, > but in so doing this is an extension beyond the ADFD paradigm. In my > view the OOA description stops at the ADFD process boundary. > I now see that Frankel's post was pretty accurate in pointing out that much of the confusion is due to the difference in ADFD and action language. I confess that I have not used ADFD in practice. I do question your basis for stating that transforms describe realized code. If this is the case, shouldn't the analyst use a wormhole and save transforms for domain internal calculations? I also would like to point out that expressing a MD attr. as a transform would not be complete. The transform would need supporting accessors to feed it data. This leads me to think that to express a MD using the ADFD paradigm, there is actually a complete action associated with the attribute description. I think the same argument holds for the action language based approach. ________________________________________________________________________ David Yoakley Objective Innovations Inc. Phone: 512.288.5954 14606 Friendswood Lane Fax: 512.288.6381 Austin, TX 78737 Replies: yoakley@oiinc.com ________________________________________________________________________ Did you ever notice when you blow in a dog's face he gets mad at you? But when you take him in a car he sticks his head out the window! Steve Bluestone Subject: (SMU) > ... the _content_ of ADFD processes is not part of the Dana Simonson writes to shlaer-mellor-users: -------------------------------------------------------------------- > ... the _content_ of ADFD processes is not part of the OOA. At > best one has a free-form description of the process that has no > formal syntax or guidelines for semantics. ADFD processes contain > realized code ... Two cents from someone using direct translation from graphical models. All processes except for transforms can be directly translated to code. The process type and connected flows (along with an expression parser for the 'Read Where...' type processes to handle the comparisons; EQUAL, NOT EQUAL..., and logical groupings; AND, OR... ) defines all necessary information. In our particular case, [NOTE THIS IS A DEVIATION FROM THE METHOD] we replaced the transform with two processes; Call and Set. Set is translated using an expression parser which allows normal math type functions on attributes. The Call places a function call in the generated code. That function must be provided as realized code. This could have been handled with just a transform process, but the line between analyzed and realized would be blurred. Text descriptions are merely comments. One final nit: > ... transform that computes a dependency calculation vs. a > transform that modifies data prior to storing it in an attribute Per OOA96 transforms cannot access data stores. Placing the calculation in a transform forces the analyst to insert a process to handle updating the attribute before each use thereby eliminating any functionality of a dependent attribute. It is now just an attribute handled like all others. The (M) becomes merely documentation. Subject: Re: (SMU) Mathematical Dependence lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Whipp... > A speadsheet also allows you to define a cell's value by > assigning it a formula. Such formulae can generally be applied > to a column fairly easily. In the days of old, slow, computers > it was necessary to use a "calculate speadsheet" command before > you used the values of the calculated columns. On faster > machines you can just turn on auto-calculate. > > I think these two modes of operation are reasonably analagous > to early- and late- evaluation techniques; though its > possible that the auto-calculation mode may be periodic. > > Whichever technique is used, the caculation is uneffected. > The calculation is associated with the table itself - not > with people sitting down and using the spreadsheet. A user > can turn auto-calculate mode on or aff as appropriate for > the speed of the machine at that time. This might vary > depending on time of day on a multi-user machine. Either way, > before they printed out the results they would make sure > they were up-to-date. It's a nice metaphor as far as it goes and it works fine for most situations, but I think it does not always handle data consistency correctly. Even in auto-calc mode a spreadsheet does an elementary form of lockout: it simply doesn't allow any cell updates during the calculation. The user typically doesn't notice this because the calculations are usually simple and incremental, but for more complicated ones the user will get an hourglass. However, in an asynchronous OOA model assuming the simultaneous time model, this lockout is not guaranteed. So when values from two independent cells are needed it is quite possible for the second to be updated between the accesses of the first and second values. If the problem space demands that the values used be consistent, then the analyst is going to have to be picky about exactly when the calculation is performed and this can only be done explicitly in the OOA. > Image the situation of the calculation was placed outside > the spreadsheet, in a transform process. The speadsheet would > never need to be recalculated because there would be no > dependent cells. But it wouldn't be very useful. First, using this logic says that _any_ transform could be eliminated by placing formulas in the cells (since OOA96 made all transient data into attributes). This simply supports my contention that a calculation in a non-dependent transform and a dependency calculation are interchangeable. Second, I would not use a transform for the calculation. I was just using the transform idea to demonstrate the fact that an algorithm is an algorithm is an algorithm and transforms already set a precedent for storing and describing algorithms with ADFD processes. If one defines a read or write accessor as trigger for the calculation, it seems to me this matches your spreadsheet metaphor exactly. [One could define a special transform to trigger dependent calculations, but that seems unnecessary given read/write accessors.] Third, I don't see that the transform changes the metaphor even if one does use a transform. The transform is a place holder in the ADFD for a calculation. This could be interpreted in the dependency case as simply a trigger, analogous to DBMS triggers, which causes the embedded spreadsheet calculation to be done. Thus when the placement of the transform in the scheme of things could simply be viewed as the analyst saying, "OK, it's safe to do your thing, Spreadsheet". Subject: (SMU) > ... the _content_ of ADFD processes is not part of the Dana Simonson writes to shlaer-mellor-users: -------------------------------------------------------------------- > ... the _content_ of ADFD processes is not part of the OOA. At > best one has a free-form description of the process that has no > formal syntax or guidelines for semantics. ADFD processes contain > realized code ... Two cents from someone using direct translation from graphical models. All processes except for transforms can be directly translated to code. The process type and connected flows (along with an expression parser for the 'Read Where...' type processes to handle the comparisons; EQUAL, NOT EQUAL..., and logical groupings; AND, OR... ) defines all necessary information. In our particular case, [NOTE THIS IS A DEVIATION FROM THE METHOD] we replaced the transform with two processes; Call and Set. Set is translated using an expression parser which allows normal math type functions on attributes. The Call places a function call in the generated code. That function must be provided as realized code. This could have been handled with just a transform process, but the line between analyzed and realized would be blurred. Text descriptions are merely comments. One final nit: > ... transform that computes a dependency calculation vs. a > transform that modifies data prior to storing it in an attribute Per OOA96 transforms cannot access data stores. Placing the calculation in a transform forces the analyst to insert a process to handle updating the attribute before each use thereby eliminating any functionality of a dependent attribute. It is now just an attribute handled like all others. The (M) becomes merely documentation. Subject: Re: (SMU) Mathematical Dependence lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Whipp... > Well, this comes back to the definition of a transform. > Calculation of dependency undoubtedly requires accessors > as well as transforms because we have to read all the source > attributes and then write the dependent one. If you allow > transforms to access data then the dependency could be > expressed as a transform. However, I'd be tempted to use > DFD of some variety (I don't think that either ADFDs or > SDFDs quite fit; perhaps I want a "Monitor" DFD [MDFD?] > that watches over the model ... or perhaps that'd be > feature creap) I think I already addressed this in another message, but I am doing them at different times and senility is always a possible factor. True, a transform cannot access data stores; a laudable enhancement of OOA96. I was using the transform idea to show that calculations for dependencies are really no different than other calculations. So if there was a precedent for associating algorithms with transform processes, why not associate dependency algorithms with processes. > Taking this view then I would revert to arguing that the > dependence is described in the Attribute Description. I'll > use the one-fact-one-place argument: > > Every Attribute may be read and written from many places - > both from state actions and synchronous services. The > OAM shows this. If you place the calculation of dependency > in the accessor process decriptions then you would have to > place it in all accessor process that interact with any > of the attributes in the dependency set. You might let > some implementation detail creap in and decode to limit it > to either only the read accessors or only the write > accessors. I am not sure I see why one-fact-one-place is violated when using accessors. Presumably only one accessor would be designated to trigger the calculation and that accessor would be associated with a particular object. The fact that it it might be invoked in many places would not change the fact that it was a single process. For example, if I designate the read accessor for the dependent attribute as the trigger, it seems to me that the accessor is just a surrogate for the attribute. > However, if you want to simulate the model then you need > something a bit more formal than an attribute description. > Personally I'd like to see an unamiguous specification of > all processes within the OOA. languages like VDM or Z may > be more appropriate the procedural action languages that > are commonly used. This is a whole other issue, but this discussion reminded me of it. My problem with the ADFD approach is: X Y Y ------> [complex transform] --------> [write accessor] ------->| attribute store| Now suppose somewhat later I access Y and perform some test on it that results in the E1 event being generated if the test passes or the E2 event being generated if it fails. The value of Y determines flow-of-control at the OOA level. However, the model cannot be simulated because what goes on in the transformation of X to Y is not known to the OOA so the simulator does not know the value of Y. (Technically, it does not even know what the test is testing, either!) The best one could do is arbitrarily pick one event to generate on one pass through the model and then pick other event on another pass. Having done a lot of economic modeling over the years, I can testify that this is not a good way to simulate complex systems; the relationship between X and Y needs to be explicitly modeled. Thus the simulators that operate off instrumented action languages have a big advantage over pure ADFD simulators. Subject: Re: (SMU) Mathematical Dependence David Yoakley writes to shlaer-mellor-users: -------------------------------------------------------------------- lahman wrote: > However, in an asynchronous OOA model assuming the simultaneous time > model, this lockout is not guaranteed. So when values from two > independent cells are needed it is quite possible for the second to be > updated between the accesses of the first and second values. If the > problem space demands that the values used be consistent, then the > analyst is going to have to be picky about exactly when the calculation > is performed and this can only be done explicitly in the OOA. > I think this is much over stated. The fact that the OOA is doing a read of an (M) attribute means that the attribute must be consistent or else the OOA is incorrect. Consistent in this context means that the attributes depended on are consistent. Therefore the only rule the architecture must follow in this regard is to provide a result consistent with the input attributes. The input attributes can be read at the time the (M) attribute is accessed or at any other convenient time as long as the expression has been re-evaluted *after* any input (depended on) attributes have changed. ________________________________________________________________________ David Yoakley Objective Innovations Inc. Phone: 512.288.5954 14606 Friendswood Lane Fax: 512.288.6381 Austin, TX 78737 Replies: yoakley@oiinc.com ________________________________________________________________________ Did you ever notice when you blow in a dog's face he gets mad at you? But when you take him in a car he sticks his head out the window! Steve Bluestone Subject: Re: (SMU) Mathematical Dependence Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- Lahman wrote: > I am not sure I see why one-fact-one-place is violated when > using accessors. Presumably only one accessor would be > designated to trigger the calculation and that accessor > would be associated with a particular object. The fact that > it it might be invoked in many places would not change the > fact that it was a single process. For example, if I > designate the read accessor for the dependent attribute as > the trigger, it seems to me that the accessor is just a > surrogate for the attribute. If you place the algorithm in write accessors then its easy to see how there is more than one accessor (if a = i * j then the write accessors for i anc j would both need to calculate a). And then there are create and delete accessors. However, perhaps you can argue that only one read accessor is needed. Consider the following accessors: read X(id).a Find-any X where X.a == 7 Find-all X where oddp(X.a) read X(id).[a,b,c] -- vector read read [X.(id_list}].a -- another vector read You could argue, from an implementation point of view, that all the reads of a in these cases are part of the same accessor. I'm not so sure. Dave. Not speaking for GPS. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com Subject: Re: (SMU) Mathematical Dependence "Dean S. Anderson" writes to shlaer-mellor-users: -------------------------------------------------------------------- lahman wrote: [.....] > Second, I would not use a transform for the calculation. I was just > using the transform idea to demonstrate the fact that an algorithm is an > algorithm is an algorithm and transforms already set a precedent for > storing and describing algorithms with ADFD processes. If one defines a > read or write accessor as trigger for the calculation, it seems to me > this matches your spreadsheet metaphor exactly. [One could define a > special transform to trigger dependent calculations, but that seems > unnecessary given read/write accessors.] > > Third, I don't see that the transform changes the metaphor even if one > does use a transform. The transform is a place holder in the ADFD for a > calculation. This could be interpreted in the dependency case as simply > a trigger, analogous to DBMS triggers, which causes the embedded > spreadsheet calculation to be done. Thus when the placement of the > transform in the scheme of things could simply be viewed as the analyst > saying, "OK, it's safe to do your thing, Spreadsheet". As Dana said earlier, I'll toss in my two cents also. Since I have been involved in developing a graphical toolset (the one Dana is using), here is how I would implement mathematical dependence: 1) The attribute description would contain the formula for calculating the attribute. 2) I would add a process type to the ADFD (call it "Calculate" or "Update") that would be invoked in a process model when the analyst determined it was time to update the attribute. I feel that it is the anaylst's job to say "when" the attribute is updated since he/she is the only one who can be certain when the dependencies for update are met. Dean S. Anderson Transcrypt International / EF Johnson Radio Systems (ka0mcm@winternet.com) Subject: Re: (SMU) Mathematical Dependence Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- Dean S. Anderson wrote: > 2) I would add a process type to the ADFD (call it "Calculate" > or "Update") that would be invoked in a process model when the > analyst determined it was time to update the attribute. I feel > that it is the anaylst's job to say "when" the attribute is > updated since he/she is the only one who can be certain when > the dependencies for update are met. It feels like we're going round in circles. By definition, the mathematical dependence always has a value: if a=b*c then, whenever 'a' is read, it will have the value b*c. It is possible that 'b' and 'c' may be updated in different actions and so the value of 'a' may be incorrect. But there is no need for an analyst to explicitly put an "update" process in any ?DFD. The analyst mearly has to ensure that 'a' is not read (or is ignored) when its value is incorrect. This is just like ensuring a relationship isn't navigated when it is inconsistant. By mandating that an update process be used, you would force an implementation to have some storage space associated with 'a'. The implementation would not be able to refer to the values of 'b' and 'c' to calculate 'a' on the fly (except in some special cases). You could not implement a read accessor for 'a' as a function that reads 'b' and 'c' and returns their product. Dave. Not speaking for GPS. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com Subject: Re: (SMU) Mathematical Dependence Dana Simonson writes to shlaer-mellor-users: -------------------------------------------------------------------- Given an dependent attribute x where x = f(y,z) If y or z change, by the next time x is read, it must have been updated. Simple enough. But, can x be written to? If so, do y and z need to be marked as dependent on x or does x have an inverse function associated with it? Subject: Re: (SMU) Mathematical Dependence Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- lahman wrote: > First, using this logic says that _any_ transform could be eliminated > by placing formulas in the cells (since OOA96 made all transient data > into attributes). This simply supports my contention that a > calculation in a non-dependent transform and a dependency calculation > are interchangeable. > [...] If one > defines a read or write accessor as trigger for the calculation, it > seems to me this matches your spreadsheet metaphor exactly. [One > could define a special transform to trigger dependent calculations, > but that seems unnecessary given read/write accessors.] Yes, but transforms within an ADFD or SDFD are only activated when well defined conditions are met. Thus if you had auto-calculation turned on then all the transforms would do their stuff at the wrong times unless you added some boolean cells to mark when things should happen. If you did this, then a speadsheet would almost be an OOA simulator - not just a data holder. My point of using the spreadsheet was partly to show that the mathematical dependence does not require any special triggers. Auto-calculation is an adequate update mechanism. This is not true of transforms. > Second, I would not use a transform for the calculation. I was just > using the transform idea to demonstrate the fact that an algorithm is > an algorithm is an algorithm and transforms already set a precedent > for storing and describing algorithms with ADFD processes. Yes, an algorithm is associated with a transform. However, I do not see that this association must be a 1:1 unconditional relationship. An algorithm is an algorithm and a transform is a transform. This doesn't prove an algorithm is a transform nor that a transform is an algorithm. If you consider an OIM for OOA-of-OOA then a transform would be a subtype of a process and would he a relationship: TRANSFORM implements (Mc:1) ALGORITHM ALGORITHM is implemented in (1:Mc) TRANSFORM ALGORITHM may take part in other relationships: ALGORITHM defines (1:Mc) MATHEMATICAL_DEPENDENCY I'm not sure that this would be a correct model - I only present it as a posibility. If you were to associate a DFD with a mathematical dependency then you could use a transform within that DFD for the algorithm. Dave. Not speaking for GPS. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com Subject: Re: (SMU) > ... the _content_ of ADFD processes is not part of lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Simonson... > Two cents from someone using direct translation from graphical > models. > > All processes except for transforms can be directly translated to > code. The process type and connected flows (along with an expression > parser for the 'Read Where...' type processes to handle the > comparisons; EQUAL, NOT EQUAL..., and logical groupings; AND, OR... ) > defines all necessary information. But aren't you adding your own formalism here to the ADFD descriptions? The descriptions on our tests (back when we did ADFDs) sometimes had descriptions like, "check for duplicates". Also, for read/write accessors there can sometimes be data massaging, typically units conversions. > In our particular case, [NOTE THIS IS A DEVIATION FROM THE METHOD] we > replaced the transform with two processes; Call and Set. Set is > translated using an expression parser which allows normal math type > functions on attributes. The Call places a function call in the > generated code. That function must be provided as realized code. > This could have been handled with just a transform process, but the > line between analyzed and realized would be blurred. > > Text descriptions are merely comments. But where do you get the expression to parse? The only place in the ADFD for this to go is the free-form process text descriptions (or the process label, which would be seriously clunky). Without a formalism you start to get things like, "Compute net profit", which is pretty intuitive to the analyst when the input data are Revenue, Expenses, and Taxes but it gets kind of tricky for software. Again, it seems to me that you are adding your own formalism beyond that of the current methodology to the process descriptions to accommodate your parser. > Per OOA96 transforms cannot access data stores. Placing the > calculation in a transform forces the analyst to insert a process to > handle updating the attribute before each use thereby eliminating any > functionality of a dependent attribute. It is now just an attribute > handled like all others. The (M) becomes merely documentation. True, but that was not my point so I did not belabor the example with the implied store. I was simply pointing out that non-dependent attributes whose values are computed in transforms are pretty much the same as dependent attributes whose values are computed in accessor. Subject: Re: (SMU) Mathematical Dependence David Yoakley writes to shlaer-mellor-users: -------------------------------------------------------------------- Dean S. Anderson wrote: > I feel that it is the anaylst's job to > say > "when" the attribute is updated since he/she is the only one who can be > certain when the dependencies for update are met. And the analyst of course must not access the (M) attribute before it has been calculated. So why not just make execution of the calculation implicit? Again all I think that is needed is a rule that states the calculation must be done sometime after any updates to depended on attribute but before any read access. I am missing something here? ________________________________________________________________________ David Yoakley Objective Innovations Inc. Phone: 512.288.5954 14606 Friendswood Lane Fax: 512.288.6381 Austin, TX 78737 Replies: yoakley@oiinc.com ________________________________________________________________________ Did you ever notice when you blow in a dog's face he gets mad at you? But when you take him in a car he sticks his head out the window! Steve Bluestone Subject: Re: (SMU) Mathematical Dependence lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Yoakley... > I think this is much over stated. The fact that the OOA is doing a > read of an (M) attribute means that the attribute must be consistent > or else the OOA is incorrect. Consistent in this context means that > the attributes depended on are consistent. Therefore the only rule > the architecture must follow in this regard is to provide a result > consistent with the input attributes. The input attributes can be > read at the time the (M) attribute is accessed or at any other > convenient time as long as the expression has been re-evaluted *after* > > any input (depended on) attributes have changed. Let me recall one of my previous examples with a bit more detail. In the calculation tmp_velocity = (A.velocity + E_velocity) / 2 A.distance = A.distance + tmp_velocity * (E_elapsed time - A.elaspsed_time) let us assume that A.velocity and A.elapsed time are updated via different events from bridges carrying the data E_velocity or E_elapsed time. Since these values come into the domain on different events they must be handled in different actions. However, the nature of the calculation demands that we need all four values: A.velocity, E_velocity, A.elapsed_time, and E_elapsed_time. This means that one cannot simply update A.velocity or A.elapsed time as the events are processed. Moreover, A.distance cannot be correctly calculated until both events have been processed. There are several solutions to this dilemma, but they will all be reflected explicitly in the OOA in some manner (e.g., by adding some more attributes to hold the event values until the calculation is performed). This level of consistency enforcement cannot be left to the architecture's handling of accessors. Though this sort of situation is unusual, it exists as this rather plausible example illustrates. Subject: Re: (SMU) Mathematical Dependence Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- Dana Simonson wrote: > Given an dependent attribute x where > x = f(y,z) > > If y or z change, by the next time x is > read, it must have been updated. Simple > enough. > > But, can x be written to? If so, do y and z > need to be marked as dependent on x or does > x have an inverse function associated with > it? This is a issue that I broached some time ago on this thread. If the equation thought of as a constraint that the analyst must satisfy (i.e. its not an architectural issue); then the answer would be that any of x, y and z can be written to; and that enalyst must ensure that they are left in a consistant state; or that action is initated that will lead to their being consistant. However, we (I) have been arguing that mathematical dependence is stronger than a constraint. If I go back to OOA96 and use its definition (on page 8) then two things are apparent: 1. The dependence can be stated as an algorithm. An algorithm could be interpretted as a constraint; but it does suggest unidirectional processing 2. The definition is phrased as: Y is dependent on X iff X determines Y. There is no reference to "Y determines X". Whilst there is not enough detail to make definite conclusions, it is reasonable to suggest that an architecture would not be expected to maintain the reverse dependency unless the inverse equation or algorithm was explicitly defined. Incidently, In re-reading the section in OOA96, I note that the last bullet point at the bottom of page 8 does associate the formula/algorithm with the attribute description. Dave. Not speaking for GPS. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com Subject: Re: (SMU) Mathematical Dependence lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Whipp... > If you place the algorithm in write accessors then its easy > to see how there is more than one accessor (if a = i * j > then the write accessors for i anc j would both need to > calculate a). And then there are create and delete accessors. Sure, but this is one reason why I think the read accessor would be the best place to do it. If the independent attributes are update in pairs in a particular order, you could elect only one accessor. > However, perhaps you can argue that only one read accessor is > needed. Consider the following accessors: > > read X(id).a > Find-any X where X.a == 7 > Find-all X where oddp(X.a) > read X(id).[a,b,c] -- vector read > read [X.(id_list}].a -- another vector read > > You could argue, from an implementation point of view, > that all the reads of a in these cases are part of the > same accessor. I'm not so sure. I agree that in ADFD land the three reads would be three different accessors. I overlooked that case. But I think I could argue that the different accessors actually represented different locking constraints, etc. but at the lower implementation levels one still gets to the same point of grabbing a particular field in a table row for ".a". Then one could argue that is the place for the calculation trigger -- as in your spreadsheet metaphor. Subject: Re: (SMU) Mathematical Dependence lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Anderson... > As Dana said earlier, I'll toss in my two cents also. Since I have > been > involved in developing a graphical toolset (the one Dana is using), > here > is how I would implement mathematical dependence: > > 1) The attribute description would contain the formula for calculating > > the attribute. > > 2) I would add a process type to the ADFD (call it "Calculate" or > "Update") > that would be invoked in a process model when the analyst determined > it > was > time to update the attribute. I feel that it is the anaylst's job to > say > "when" the attribute is updated since he/she is the only one who can > be > certain when the dependencies for update are met. But isn't this just a pre-OOA96 transform that was allowed to do data store writes? The only difference is that it would have to go to the attribute description to get the formula rather than the transform description. I think there was value in limiting the things transforms could do and I would not like to backstep. I am also not sure why you feel it would be better to do this in a special transform than in an accessor. The methodology notation is nice and lean; I would prefer not to add notational constructs without a good reason when existing constructs can do the job. If the "when" is an issue, then the analyst can control the placement of an accessor as well as a transform. Subject: (SMU) > Responding to lahman tmp_velocity = (A.velocity + Dana Simonson writes to shlaer-mellor-users: -------------------------------------------------------------------- > Responding to lahman tmp_velocity = (A.velocity + E_velocity) / 2 > A.distance = A.distance + tmp_velocity * (E_elapsed time - > A.elaspsed_time) > let us assume that A.velocity and A.elapsed time are updated via > different events from bridges carrying the data E_velocity or > E_elapsed time. Since these values come into the domain on > different events they must be handled in different actions. > However, the nature of the calculation demands that we need all > four values: A.velocity, E_velocity, A.elapsed_time, and > E_elapsed_time. This means that one cannot simply update > A.velocity or A.elapsed time as the events are processed. > Moreover, A.distance cannot be correctly calculated until > both events have been processed. I think the above implies an additional element not included. The attributes A.velocity, E_velocity, A.elapsed_time, and E_elapsed_time have an attribute domain of some range of values and UNDEFINED. In the calculation of tmp_velocity and A.distance, if any of the attributes are UNDEFINED the the result is also UNDEFINED. The architecture can calculate these values at any time it chooses. If the analysis needs to identify the UNDEFINED case and do something special, like wait for a valid value, then that action should be analyzed not the calculation of the dependent attribute. Subject: RE: (SMU) Mathematical Dependence "Lynch, Chris D. SD" writes to shlaer-mellor-users: -------------------------------------------------------------------- H.S. Lahman wrote: >If the >problem space demands that the values used be consistent, then the >analyst is going to have to be picky about exactly when the calculation >is performed and this can only be done explicitly in the OOA. So far, I haven't heard the customer's perspective. Here's my version: 1. Usually, customers expect everything to be consistent, "always". Frequently this, can be accomplished. 2. If perfect consistency is impractical, the customer's expression of the error allowed fits perfectly in the __attribute description__, which can be written a few minutes after the (M) attribute is identified on the initial IM. Only with great reluctance will I tell my customer to wade through process models, accessors, and/or monitors. Whatever can be said via such means can usually be better said in 100 well-chosen words of English (preferably the customer's own.) For what it's worth, I'd like to see the formula and accuracy requirements captured as early in the analysis as possible, and for me that means in the object and attribute descriptions rather than in the other work products, which have the disadvantages of a) coming later and b) being "over the head" of the non-OOA'er perspective of the customer. Also, as far as simulateability, a transform process which recomputes the result on each read is sufficient; the issue of early/late/periodic evaluation cannot apply in an OOA, as this would imply that the (M) attribute is stored __at the model level__ and thus break the rules for third normal form. ------------------------------------------------------------------------ ---- --------- Chris Lynch Abbott Ambulatory Infusion Systems San Diego, CA LYNCHCD@HPD.ABBOTT.COM ------------------------------------------------------------------------ ---- --------- Subject: (SMU) Responding to Dave Whipp Dana Simonson writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Dave Whipp > Whilst there is not enough detail to make definite conclusions, > it is reasonable to suggest that an architecture would not be > expected to maintain the reverse dependency unless the > inverse equation or algorithm was explicitly defined. Exactly! I think it is entirely reasonable that attributes marked as (M) should be thought of as read only to the analysis. The architecture is the only thing that needs to write to a (M) attribute and does so at its discretion or it can calculate the value on an as needed basis and not have any storage for the (M) attribute at all. Subject: Re: (SMU) Mathematical Dependence Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- lahman wrote: > > However, perhaps you can argue that only one read accessor is > > needed. Consider the following accessors: > > > > read X(id).a > > Find-any X where X.a == 7 > > Find-all X where oddp(X.a) > > read X(id).[a,b,c] -- vector read > > read [X.(id_list}].a -- another vector read > > > > You could argue, from an implementation point of view, > > that all the reads of a in these cases are part of the > > same accessor. I'm not so sure. > > I agree that in ADFD land the three reads would be three > different accessors. I overlooked that case. But I think I > could argue that the different accessors actually represented > different locking constraints, etc. but at the lower > implementation levels one still gets to the same point of > grabbing a particular field in a table row for ".a". Then one > could argue that is the place for the calculation trigger -- > as in your spreadsheet metaphor. Time for a counter example. Consider the objects: X(id_x, ref_y(r), a(m), b) and Y(id_y, c) where, forall X: X.a = X.b + Y(X.ref_y).c Consider the relationship navigation accessor chain from Y: Find-any X where X.ref_y = Y.id_y AND X.a = 7 (in action language, this might read: Find-any Y->X where X.a==7) An implemenation could put the calculation of X.a outside the loop because Y.c is constant within the loop. Thus, if Y.c == 4 then an implementation can look for Y->X where X.b == 3. Thus, in the seach accessor, calculation of X.a may not need to be triggered. Now, you could object that the analyst could have made this optimisation; but I would counter that by reminding you that, by definition, mathematical dependence within a model indroduces redundancy; thus the analyst could not reasonably be expected to do the optimisation. Dave Not speaking for GPS. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com Subject: Re: (SMU) Mathematical Dependence Leslie Munday writes to shlaer-mellor-users: -------------------------------------------------------------------- Dave Whipp wrote: > Dave Whipp writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Dean S. Anderson wrote: > > 2) I would add a process type to the ADFD (call it "Calculate" > > or "Update") that would be invoked in a process model when the > > analyst determined it was time to update the attribute. I feel > > that it is the anaylst's job to say "when" the attribute is > > updated since he/she is the only one who can be certain when > > the dependencies for update are met. > > It feels like we're going round in circles. By definition, > the mathematical dependence always has a value: if a=b*c > then, whenever 'a' is read, it will have the value b*c. I may not be fully understanding this thread of discussion, but since it's been going on for so long, I've decided to add my piece of confusion. Comment on the above paragraph: a = b * c ; also a = sigma(1..b) of c ; also a = sigma(1..c) of b ; also a = sqrt( a*b*a*b) ; also a = d + (a * b) - d, etc, etc,... Does this make sense in the context of this thread? Leslie. Subject: Re: (SMU) Mathematical Dependence David Yoakley writes to shlaer-mellor-users: -------------------------------------------------------------------- lahman wrote: > This means that one cannot simply update A.velocity or A.elapsed time > as the events are processed. ERRRRH. Thanks for playing. One can update the depended on attributes any time one pleases. The issue is when does the (M) attribute *need* to be consistent in the context of the OOA (e.g. when is it accessed)? > Moreover, A.distance cannot be correctly calculated until > both events have been processed. Yea so what's your point. No one cares as long as it gets calculated *with* consistent attrs prior to when it is accessed. Actually I think we are both saying very close to the same thing. I hear you argue for giving the OOA control over the calculation because it must be synchronized. I agree there must be synchronization but the synchronization is nothing new and requires no new process or semantic. The OOA always has been responsible for ensuring that attributes are consistent before accessed. So lets not say the calculation must be synchronized with the dependent attrs. Lets say the read access must be synchronized with them and then we have no new rules. Besides the fact that we wont have to invent new rules, is this really any different? Yes. Now the architecture decides when to do the calculation, not the OOA. This is bound to simplify the OOA. What does this cost? In most cases nothing depending on how capable your architecture is. For instance, the calculation can be optimized to match the performance needs of the OOA. If the dependent on attributes rarely change then maybe the calculation is performed early. If they change frequently then maybe it is performed on the fly. Better yet, maybe the calculation is only done late but only if any depended on attributes have changed. Yes it will be more of a challenge to get the same performance as when the OOA is in direct control. But I am sure some folks would argue that modeling productivity is just as important as CPU performance. (Back to your examle which you admit is probably an exception to the general case) So what if the depended on attributes are not consistent when the attribute *needs* to be accessed in the OOA? Well fix the model. It is not modeling the entire problem. The depended on attributes must be buffered somehow and all be updated at one time just as you note. Does this change the rules for how or when the (M) is calculated. No. ________________________________________________________________________ David Yoakley Objective Innovations Inc. Phone: 512.288.5954 14606 Friendswood Lane Fax: 512.288.6381 Austin, TX 78737 Replies: yoakley@oiinc.com ________________________________________________________________________ Did you ever notice when you blow in a dog's face he gets mad at you? But when you take him in a car he sticks his head out the window! Steve Bluestone Subject: Re: (SMU) > Responding to lahman tmp_velocity = (A.velocity + lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Simonson... > > Responding to lahman tmp_velocity = (A.velocity + E_velocity) / 2 > > A.distance = A.distance + tmp_velocity * (E_elapsed time - > > A.elaspsed_time) > > I think the above implies an additional element not included. The > attributes A.velocity, E_velocity, A.elapsed_time, and E_elapsed_time > have an attribute domain of some range of values and UNDEFINED. In > the calculation of tmp_velocity and A.distance, if any of the > attributes are UNDEFINED the the result is also UNDEFINED. The > architecture can calculate these values at any time it chooses. If > the analysis needs to identify the UNDEFINED case and do something > special, like wait for a valid value, then that action should be > analyzed not the calculation of the dependent attribute. First, E_velocity and E_elapsed_time are event data, not attributes. The analyst may make them attributes for convenience, but there are other alternatives. Now, suppose A is created at initialization with all three attributes set to zero. From this point on UNDEFINED is not a valid value for A.distance because some other entity may be interested in the current distance traveled at any time. Therefore, the architecture cannot calculate A.distance anytime it wants because one of the events with E_velocity or E_elapsed_time may not have arrived yet (i.e., the data value is UNDEFINED). So I argue that your last sentence _always_ applies for this example. Basically this means that the analyst has to control when the calculation is done. I think the calculation has to be analyzed by the OOA analyst to determine whether the timing of the calculation is important to the problem at hand. Subject: Re: (SMU) Mathematical Dependence lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Whipp... > Yes, but transforms within an ADFD or SDFD are only activated when > well defined conditions are met. Thus if you had auto-calculation > turned on then all the transforms would do their stuff at the wrong > times unless you added some boolean cells to mark when things should > happen. If you did this, then a speadsheet would almost be an OOA > simulator - not just a data holder. > > My point of using the spreadsheet was partly to show that > the mathematical dependence does not require any special > triggers. Auto-calculation is an adequate update mechanism. > This is not true of transforms. I guess triggers are in the eye of the beholder. In the spreadsheet metaphor the auto-calculation is triggered by writing to a particular cell. So if one could use the write accessor to trigger the dependent calculation, I don't see any difference. The problem is that the spreadsheet doesn't worry about someone publishing the results with an incorrect dependent value because the independent cell values are inconsistent. Thus the spreadsheet user is like an OOA analyst who makes sure all the independent values are updated before printing the spreadsheet. However, in an OOA activities are not so discrete; tasks are continuously being executed so the analyst needs other ways to trigger than simply writing an independent value. Thus it might be much more useful to trigger the calculation on the read of the dependent cell (which spreadsheets don't do) or with a transform that does nothing but trigger. > Yes, an algorithm is associated with a transform. However, I do > not see that this association must be a 1:1 unconditional > relationship. An algorithm is an algorithm and a transform is > a transform. This doesn't prove an algorithm is a transform nor > that a transform is an algorithm. > > If you consider an OIM for OOA-of-OOA then a transform would be > a subtype of a process and would he a relationship: > > TRANSFORM implements (Mc:1) ALGORITHM > ALGORITHM is implemented in (1:Mc) TRANSFORM > > ALGORITHM may take part in other relationships: > > ALGORITHM defines (1:Mc) MATHEMATICAL_DEPENDENCY > > I'm not sure that this would be a correct model - I only > present it as a posibility. If you were to associate a > DFD with a mathematical dependency then you could use a > transform within that DFD for the algorithm. Yeah, we could pick this one to death and suck up a lot of bandwidth in Nonsequitor City. However, I am not convinced about the kernel assumption that transforms and algorithms are different critters. What characteristics does a transform have that would not be consistent with execution of an algorithm? In my mind a transform is the execution of an algorithm. Put another way, if the transform were an active object, it seems to me that its states would represent states in the progress of the algorithm. Subject: Re: (SMU) Mathematical Dependence lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Yoakley... > > I feel that it is the anaylst's job to > > say > > "when" the attribute is updated since he/she is the only one who can > be > > certain when the dependencies for update are met. > > And the analyst of course must not access the (M) attribute before > it has been calculated. So why not just make execution of the > calculation implicit? Again all I think that is needed is a rule > that states the calculation must be done sometime after any updates > to depended on attribute but before any read access. I am missing > something here? No, I don't think you are missing anything. Part of the problem is that this thread is going in several directions at once. One issue is whether the (M) can be made implicit in a manner that allows the architecture to handle all the consistency issues. This subthread started (I think) over the proposition that the architecture can handle only some of the consistency issues and that the analyst has to pick up the rest. Another subthread is addressing the idea of how the (M) calculation is triggered (read accessor, write accessor, special transforms, etc.). So, given this subthread and the fact that one is using the read accessor as a trigger, the analyst would have to make sure the read only occurred when the independent values were consistent. Subject: Re: (SMU) Mathematical Dependence Dana Simonson writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to lahman > First, E_velocity and E_elapsed_time are > event data, not attributes. Red Flag! Mathematically dependent attributes are defined only in terms of attributes. See definition page 8 OOA96. The event data must be written to an attribute in order for the dependency to be valid. > So I argue that your last sentence > _always_ applies for this example. > Basically this means that the analyst has > to control when the calculation is done. > I think the calculation has to be analyzed > by the OOA analyst to determine whether > the timing of the calculation is important > to the problem at hand. I counter that the timing and the calculation are independent issues. Given tmp_velocity = (A.velocity + E_velocity) / 2 A.distance = A.distance + tmp_velocity * (E_elapsed time - A.elaspsed_time) Lets say that A.velocity, A.distance and A.elaspsed_time come from domain A. E_velocity and E_elapsed time come from domain E. And, as you say all values are initialized. If the analyst wants the above calculation to be performed on a 'snapshot' basis where only attributes sampled at the same time are used to calculate the result, then he should buffer these values when received and write the full set after receipt of all pieces in the same accessor. If he merely wants the most recent values available, regardless of when they were received then the dependency alone satisfies the requirement. The analyst should not care when the calculation is performed, he only cares about the consistency of the data used. When I read a value it reflects the current state of the attributes it is dependent on. There is no need for a extra process or for specially colored accessors. PS: Sorry about the strange subject lines, one of my mail systems views discards the subject and replaces it with the fist line of the message body. Subject: (SMU) Action Language Steve Mellor writes to shlaer-mellor-users: -------------------------------------------------------------------- Everyone: To translate a model completely, as per RD, there has to be a statement of all the processing required in an action. This statement must both: * adhere to the spirit, if not the letter, of the process partitioning rules (ie transformation, accessors etc.) * be at a high level of abstraction, suitable for translation (ie the 'wiring' that connects the processes should be made explicit, and treated as first class concept in the language) Today's action languages do a good job of the former, and a less than wonderful job of the latter. However, Shlaer and Mellor have said nothing significant on the subject so far. Please take a look at a draft Chapter 6 from the RD book, which describes a Shlaer-Mellor Action Language (SMALL-- one L is gratuitous). You'll find the chapter at our web site by going through the "what's new" link. Note that we regard an action language as an equal partner to the ADFD, and that the language does not (yet) specify how to go about defining a transformation or test process. We're looking forward to your comments. -- steve mellor http://www.projtech.com Subject: Re: (SMU) Mathematical Dependence lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Simonson... > Given an dependent attribute x where > x = f(y,z) > > If y or z change, by the next time x is > read, it must have been updated. Simple > enough. > > But, can x be written to? If so, do y and z > need to be marked as dependent on x or does > x have an inverse function associated with > it? I would think that within the context of an OOA the intent is that x cannot be written except as a result of the calculation -- if for no other reason than to establish some guidelines for controlling consistency. However, you have an interesting point. I can easily envision a system whose purpose is to allow analysis of the interactions of x, y, and z by varying any one of them. This might be true in a non-linear simulation system. The nature of the system would eliminate the worries expressed elsewhere about consistency in the independent attributes. Now you would have x = f(y,z) y = f'(x,z) z = f''(x,y) that might all represent (M) relationships. I would think that x could only be written through f, y through f' and z through f''. However, since all of them could be written, this would leave something of a notational dilemma. Subject: Re: (SMU) Mathematical Dependence lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Whipp... > Incidently, In re-reading the section in OOA96, I note that the > last bullet point at the bottom of page 8 does associate the > formula/algorithm with the attribute description. Hmmm, I missed that. Obviously they should change that since they admittedly did not think about letting the architecture handle the update. Subject: Re: (SMU) Mathematical Dependence lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Lynch... > So far, I haven't heard the customer's perspective. Here's my > version: > > 1. Usually, customers expect everything to be consistent, "always". > Frequently this, can be accomplished. > 2. If perfect consistency is impractical, the customer's expression > of the error allowed fits perfectly in the __attribute > description__, which > can be written a few minutes after the (M) attribute is identified > > on the > initial IM. > Only with great reluctance will I tell my customer to wade through > > process models, accessors, and/or monitors. Whatever can be said > via such means can usually be better said in 100 well-chosen words > > of > English (preferably the customer's own.) The debate here is whether the architecture can handle all consistency issues in a (M) update. If it can't, I think everyone is agreed that the analyst must account for that consistency. Whether the analyst has to take precautions in the model is a function of the problem space. In any case the model must be consistent when one accesses x or it isn't done yet. The customer should not need to verify this -- the customer rightly expects it. > For what it's worth, I'd like to see the formula and accuracy > requirements > captured as early in the analysis as possible, and for me that means > in the object and attribute descriptions rather than in the other work > > products, > which have the disadvantages of a) coming later and b) being "over the > > head" of the non-OOA'er perspective of the customer. I would think that the formula and accuracy requirements were exactly that -- requirements -- and would be defined before they are placed in the models. If not in the Requirements Specification, then in the Functional Specification. But you don't make guesses about formulas and accuracy in the models. > Also, as far as simulateability, a transform process which recomputes > the > result on each read is sufficient; the issue of early/late/periodic > evaluation > cannot apply in an OOA, as this would imply > that the (M) attribute is stored __at the model level__ and thus break > > the > rules for third normal form. This is an interesting point. I hadn't thought about this, but now that you bring it up, it seems to me that it resolves a few issues of this thread. Since it can't actually exist as an attribute in a data store, it _has_ to be computed in the read accessor. I knew there had to be some reason why I didn't like write accessors doing the update! This makes the consistency issues for the analyst clearer as well. The analyst can count on the read accessor producing a value that accurately reflects the immediate state of the independent variables. If the architecture shortcuts recalculation for performance reasons, the architecture has to make sure that shortcut does not break consistency. The analyst does not have to worry about that; it is a problem for the Architect. Now the only issue for the analyst is: are the independent variables consistent relative to the needs of the problem space at the time the read accessor is invoked? Subject: Re: (SMU) Mathematical Dependence lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Whipp... > > I agree that in ADFD land the three reads would be three > > different accessors. I overlooked that case. But I think I > > could argue that the different accessors actually represented > > different locking constraints, etc. but at the lower > > implementation levels one still gets to the same point of > > grabbing a particular field in a table row for ".a". Then one > > could argue that is the place for the calculation trigger -- > > as in your spreadsheet metaphor. > > Time for a counter example. > > Consider the objects: > > X(id_x, ref_y(r), a(m), b) > and Y(id_y, c) > > where, forall X: X.a = X.b + Y(X.ref_y).c > > Consider the relationship navigation accessor chain from Y: > > Find-any X where X.ref_y = Y.id_y AND X.a = 7 > > (in action language, this might read: Find-any Y->X where X.a==7) > > An implemenation could put the calculation of X.a outside > the loop because Y.c is constant within the loop. Thus, if > Y.c == 4 then an implementation can look for Y->X where X.b == 3. > > Thus, in the seach accessor, calculation of X.a may not need to > be triggered. > > Now, you could object that the analyst could have made this > optimisation; but I would counter that by reminding you that, > by definition, mathematical dependence within a model indroduces > redundancy; thus the analyst could not reasonably be expected to > do the optimisation. I agree with all this, but I am confused about what the point is. I thought I was supporting your spreadsheet metaphor but you seem to be trying to shoot me down. Jeesh! I think I could argue both sides of whether the analyst should do the optimization and if the trigger were in the lowest level get_a function it would be irrelevant to the argument. The optimization relies on the fact that deterministic redundancy exists, regardless of who initiates the optimization. Subject: Re: (SMU) Action Language "Ken Cook" writes to shlaer-mellor-users: -------------------------------------------------------------------- Looks good at first glance. Can I offer an alternative to SMALL (Shlaer-Mellor Action Language - one L is gratuitous) Possibly: SMALL (Shlaer-Mellor Action Language - one L of a Language) :-) Ken Subject: Re: (SMU) Mathematical Dependence lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Simonson... If you are in a rush, just skip to the last paragraph -- for reasons unrelated to your arguments I have switched horses. But if you are looking to fill the all those idle hours... > > First, E_velocity and E_elapsed_time are > > event data, not attributes. > > Red Flag! Mathematically dependent > attributes are defined only in terms of > attributes. See definition page 8 OOA96. > The event data must be written to an > attribute in order for the dependency to be > valid. Actually, my statement was misleading. They are event data at the time of the calculation, but they really are the attribute values that are to be assigned to A.velocity and A.elapsed_time. What I meant to say was that they are not necessarily _different_ attributes -- that would be only one mechanism of implementing the calculation in a consistent manner. Nonetheless, your point is a good one and I now understand what you were driving at originally. I agree that technically the entire calculation as cited in the example could not qualify as an (M) dependency calculation. However, when faced with the task of implementing the example I could make them attributes so that the sequence was: update A.E_velocity update A.E_elapsed_time compute new A.distance = f(A.distance, A.velocity, A.elapsed_time, A.E_elapsed_time, A.E_velocity) update A.velocity <= A.E_velocity update A.elapsed_time <= A.E_elapsed_time In this case I could then designate the calculation of new distance as an (M) dependency. It could only be safely calculated when one has both A.E_xxx updates in hand. Similarly the updates of A.velocity and A.elapsed_time are now (M) dependencies on A.E_xxx (due to Lynch's point that one should preserve 3rd Normal Form). But they cannot be done arbitrarily either. At this point we are nesting (M) dependencies and that starts to hurt my brain. > I counter that the timing and the > calculation are independent issues. > > Given > tmp_velocity = (A.velocity + E_velocity) / 2 > A.distance = A.distance + tmp_velocity * > (E_elapsed time - A.elaspsed_time) > > Lets say that A.velocity, A.distance and > A.elaspsed_time come from domain A. > E_velocity and E_elapsed time come from > domain E. And, as you say all values are > initialized. > > If the analyst wants the above calculation > to be performed on a 'snapshot' basis where > only attributes sampled at the same time are > used to calculate the result, then he should > buffer these values when received and write > the full set after receipt of all pieces in > the same accessor. If he merely wants the > most recent values available, regardless of > when they were received then the dependency > alone satisfies the requirement. > > The analyst should not care when the > calculation is performed, he only cares > about the consistency of the data used. > When I read a value it reflects the current > state of the attributes it is dependent on. > There is no need for a extra process or for > specially colored accessors. I agree there is no need for special processes or specially colored accessors. So long as the independent attributes are consistent at the time of the calculation, it can be bound to existing constructs. I am not arguing that the analyst must tell the architecture when to do the calculation. Though I agree they are quite different issues, I do not agree that the calculation and the timing of it are independent issues (provided one is not on a Unix system where correctness is a percentage). The calculation may be incorrect if the independent attribute values are not consistent. Whether the independent attribute values are consistent is a matter of timing in the OOA. Therefore the _correctness_ of the calculation is dependent upon its timing when triggered in the OOA. Since the analyst controls timing of updates to the independent attributes in the OOA the the analyst must make sure that the independent attributes are in a consistent state prior to the calculation. This is usually trivial but I do not think the analyst can do this in all cases without knowing when the calculation is bound. That is, the analyst may be indifferent to _which_ choice of calculation binding is made, but the analyst must know what choice was actually made. Put another way, though the analyst does not tell the architecture when to do the calculation, the analyst must arrange the OOA so that the inputs to the calculation are always consistent. To do this I think the analyst must know which binding is used. Because of the normal form issue, I have come around to believing that there really isn't a choice of when the calculation is bound -- it has to be at the read accessor for the dependent attribute. Now the analyst just has to make sure that the independent attributes are consistent prior to the invocation of the read accessor. It also means that my distance calculation example is not implement able as an (M) dependency because there is no way it could properly be done within a pure read acccessor without external help from the analyst in the OOA -- I think one would have to do it in a write accessor for three attributes simultaneously. That is, the (M) dependency is more constrained than simply being x = f(a,b,..) where a, b, ... are attributes, as described in OOA96. Subject: Re: (SMU) Mathematical Dependence "Dean S. Anderson" writes to shlaer-mellor-users: -------------------------------------------------------------------- lahman wrote: > > lahman writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Responding to Lynch... > [...] > > Also, as far as simulateability, a transform process which recomputes > > the > > result on each read is sufficient; the issue of early/late/periodic > > evaluation > > cannot apply in an OOA, as this would imply > > that the (M) attribute is stored __at the model level__ and thus break > > > > the > > rules for third normal form. > > This is an interesting point. I hadn't thought about this, but now that > you bring it up, it seems to me that it resolves a few issues of this > thread. Since it can't actually exist as an attribute in a data store, > it _has_ to be computed in the read accessor. I knew there had to be > some reason why I didn't like write accessors doing the update! > > This makes the consistency issues for the analyst clearer as well. The > analyst can count on the read accessor producing a value that accurately > reflects the immediate state of the independent variables. If the > architecture shortcuts recalculation for performance reasons, the > architecture has to make sure that shortcut does not break consistency. > The analyst does not have to worry about that; it is a problem for the > Architect. Now the only issue for the analyst is: are the independent > variables consistent relative to the needs of the problem space at the > time the read accessor is invoked? I am retracting my earlier e-mail that stated I would implement a special "update" or "calculate" process and instead agree with the statements above. I actually realized my suggested implementation was not very good about ten minutes after I sent the e-mail. My only excuse is that is was very early in the morning. Dean S. Anderson Transcrypt International / EF Johnson Radio Systems (ka0mcm@winternet.com) Subject: (SMU) SMALL: Abandonment of relational model? Steve Mellor writes to shlaer-mellor-users: -------------------------------------------------------------------- At 10:21 PM 12/7/97 GMT, you wrote: >David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: >-------------------------------------------------------------------- >I've had a fairly brief read through the document. I have >plenty of comments to make, which I'll get to over a period >of time. Putting everything in one email would take a long >time and be very big. It seems better to start several >distinct threads. I agree. I propose a convention such as that used in the header to this message, i.e. SMALL: . >So, in summary, it appears that Shlaer-Mellor has abandoned >the relational data model in favour of a graph based formalism. >We can neither write to, nor read referential attributes. >Without them, it is still possible to build OOA models, but on >very different principles to those which [I] have been used to. > >I hope someone from PT would like to comment. Fear not. But I'd like to wait a little to see what the community has to say. -- steve Subject: (SMU) (SMALL) Dataflows are Dataflows David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: -------------------------------------------------------------------- SMALL appears to be a rather complex langauge. There does not appear to be any underlying architecture, so the result is a non-orthogonal language, with different data constructs used depending on the process type. In a DFD, all data flows along dataflows. There is no concept of a reference. The concept of references has had unfortunate consequences and is completely unneccesary for a perfectly readable action language. It could easily be replaced with an RD concept of properties on dataflows (i.e. if a dataflow originates from an identifier then a reference is attached to the flow). If the flow is used in a context where the reference makes sense then the reference is used. The same mechanism can be used for referential attributes. What are the unfortunate consequences I refered to? Leaving aside the abandonment of the relational data model, a multitude of quirks is introduced into the language. Sometimes you pipe dataflows into a process; other times you pipe in references. Sometimes you put dataflows as parameters; other times you use references. These type of effects do make a language less easy to use and give it the appearance of having been cobbled together. What is the alternative. A beefed up model of dataflows would allow all data to be piped into processes. This would be more in line with the DFD model. The main addition I would make is to enhance the concept of composed dataflows. If I use a prefix, say "%" to indicate composition then I could write: (~x, ~y) > %coords // %coords contains x and y (~a, ~b) > %coords(a => x, b => y) // ditto (~a, ~b) > %coords(x, y) // ditto. coordinate(all).(x,y) > %coords // has named fields from object coordinate(all) > %coords // has all fields from the object In this last example, the dataflows within the bundle would inherit properties so that the identifiers are propogated. Referential attributes would be tagged with a reference to their defining object. Bundling dataflows should have no semantic consequences. Bundles should be expanded by a parser. Other aspects of composition and decomposition would work in the same way as SMALL. A consequence of making dataflows universal would be to allow dataflows of type arbitary to be used. I see no problem in this. Just treat them as private data types (as in ADA - you can move them round but nothing else). I would be interested to know why this approach is rejected in SMALL. The effect of eliminating references; and doing everything with dataflows; is a simplification of the reset of the language. Generates, Creates, Transforms, etc. would all simply except a set of incoming flows; if necessary aliasing flow names onto their input/output interface. There would be no need for link or unlink processes because referential attributes would be written directly; if the written value is tagged as an identifier (or compound identifier) then the translator has an easy optimisation. I look forward to hearing a justification from PT for their more complex approach. Dave. Not Speaking for GPS. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com Subject: (SMU) Re: spreadsheet analogy lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Whipp... > > I agree with all this, but I am confused about what the point is. I > > > thought I was supporting your spreadsheet metaphor but you seem to > be > > trying to shoot me down. Jeesh! > > I think the sequence went like this: > This actually got a bit off the point. You believe that the > calculation > of the dependent attribute belongs in the read accessor. Whether or > not I agree with this point of view, I still come back to the point > that you shouldn't specify the calculation in the accessor because > there are many different accessors that would require the calculation > to be specified. There must be an independent definiton of the > calculation that the accessors could all refer to. Ah, but you left off the point where I argued that regardless of how many ADFD accessors might need the value, it could be calculated in the lowest level table/field extractor in the implementation -- which corresponds to a cell access in your spreadsheet analogy. > I believe that this definition should be associated with the attribute > > itself, not with a process that calculates it. I don't really care all that much. I think the placement is more of an aesthetic issue than a theoretical requirement. It just bothers me that the description of a calculation is put in different models depending upon context. There is another aspect of one-fact-one-place that I think needs honoring: all of the information of a certain type (read: level of abstraction) should be in one model (appropriate to that level of abstraction). When I look for information about object data structures, I go to the IM and I would not expect to find some objects described in ADFDs. Similarly, when I want to see descriptions of realized code, I expect to go to ADFD process descriptions, not the IM. Subject: Re: (SMU) Mathematical Dependence lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Anderson... > I actually realized my suggested implementation was not very good > about > ten minutes after I sent the e-mail. My only excuse is that is was > very > early in the morning. Just an early morning? As others have gleefully pointed out, I have had Bad Hair Months on this forum. Since this thread has been too serious, a true story apropos of nothing... (The attention span is the second thing to go at my age.) Many years ago I was playing in a duplicate bridge tournament. Just before the tournament my partner and I decided to play the Forcing Stayman convention. (For non-bridge players, the convention is that one partner's bid of two diamonds over an opposing one no-trump bid forces the other partner to keep the bidding open for at least one round.) Several tables into the tournament, the bidding went: E: "one NT" S (partner): "two diamonds" W: "Pass" N (me): "Pass" At this point one of the opponents looked at our convention card and then asked my partner what my bid meant. My partner deadpanned, "It's the Alzheimer's Convention." Subject: Re: (SMU) (SMALL) Dataflows are Dataflows Kenneth Cook writes to shlaer-mellor-users: -------------------------------------------------------------------- At 01:58 PM 12/8/97 GMT, Dave Whipp wrote: >David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: >-------------------------------------------------------------------- >In a DFD, all data flows along dataflows. There is no concept >of a reference. The concept of references has had unfortunate >consequences and is completely unneccesary for a perfectly >readable action language. It could easily be replaced with an >RD concept of properties on dataflows (i.e. if a dataflow >originates from an identifier then a reference is attached to >the flow). If the flow is used in a context where the reference >makes sense then the reference is used. The same mechanism can >be used for referential attributes. > I'm interested in this idea of simplifying SMALL by having it follow the dataflow paradigm more closely. But... In defense of references: You say above that ""if a dataflow originates from an identifier then a reference is attached to the flow". While identifying attributes can be accessed in SMALL, there is no concept in SMALL of the whole identifier (in the case where many attributes comprised the identifier), so it seems you would just replace an Object Reference with a special type of composite called "Identifier". Where is the simplification? The primary benefit of references is they allow modelers to say, "I've already found this thing - so don't waste time finding it again." When back-end stores are involved, or when objects are distributed across several nodes, this is very useful. Even using Identifiers would hamper performance in such systems: one could not assume that an identifier identified an in-memory instance: some kind of hash of the in-memory instances would need to be kept, thus the analysis method would build-in at least that kind of performance hit. I know references have been in debate in OOA circles for years. They have also been used in several implementations of Action Language with causing any Shlaer-Mellor canaries to die in the Ion Chamber caves ;) -Ken Subject: Re: (SMU) SMALL: Pre-created events Kenneth Cook writes to shlaer-mellor-users: -------------------------------------------------------------------- At 01:58 PM 12/8/97 GMT, you wrote: SMALL does not appear to support pre-created events. Might these be added? If not, how might models using this concept be ported to SMALL? -Ken Subject: Re: (SMU) SMALL: Pre-created events David Yoakley writes to shlaer-mellor-users: -------------------------------------------------------------------- Kenneth Cook wrote: > > Kenneth Cook writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > At 01:58 PM 12/8/97 GMT, you wrote: > > SMALL does not appear to support pre-created events. > Might these be added? > If not, how might models using this concept be ported to SMALL? > > -Ken What exactly are these? ________________________________________________________________________ David Yoakley Objective Innovations Inc. Phone: 512.288.5954 14606 Friendswood Lane Fax: 512.288.6381 Austin, TX 78737 Replies: yoakley@oiinc.com ________________________________________________________________________ Did you ever notice when you blow in a dog's face he gets mad at you? But when you take him in a car he sticks his head out the window! Steve Bluestone Subject: Re: (SMU) SMALL: Pre-created events "Ken Cook" writes to shlaer-mellor-users: -------------------------------------------------------------------- > David Yoakley writes to shlaer-mellor-users: > -------------------------------------------------------------------- > What exactly are [pre-created events] Create an instance of an event, complete with target instance and supplemental data values filled in and ready to go. Then store it, pass it around, and, later, execute it. We often use them as callbacks - they are somewhat analogous to function pointers. -Ken Subject: (SMU) SMALL: Coercion Rules David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: -------------------------------------------------------------------- Some simple rules for coercion are given in section 6.5. However, IMHO, it is necessary to have user defined coersion rules. Most domains tend to have notations specific to that domain. At the simplest level, there are constants - for example: PI is a number in some domains. This type of coersion could be dealt with by introducing the concept of constants. But for more advanced datatypes, possibly involving user defined typed, this may not be enough. A domain may understand "4j + 2" as a complex number. Where an application domain treats a string as something atomic; a service domain (which provides the type) would understand the constituents. "-rwxr-xr-x" may be atomic in one domain but meaningful in another. If coercion is to exist as an OOA concept (i.e. not an RD concept) then it mustn't be resticted to just a few obvious examples. It would be wrong to say "That will be mapped by the bridge" for some types but not for others. A time string is coercable into a time value; so any string must be coercable. I would also expect to be able to redefine coercion rules if necessary if the built in rules become inappropriate. Not all nations use the western concept of time; and it is meaningless to use a 12 month year if we go back in time a few centuries. Dave. Not Speaking for GPS. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com Subject: (SMU) SMALL: Case Statements David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: -------------------------------------------------------------------- In SMALL, a Test process can act as a CASE statement simply by defining a guard for each case. However, there is a possible weakness in the language when many guards are produced: the mapping between the Tests and the Guards is by position, not by name. I feel that, for consistency and usability, SMALL should allow anything to be mapped by name. e.g. IsNone? false => !isOne, true => !isNone Dave. Not Speaking for GPS. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com Subject: (SMU) SMALL: Filtering and Sorting David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: -------------------------------------------------------------------- SMALL contains two places where the values of attributes can be tested: Test processes and accessors. What is the difference between: Sample(all, (value > 5) ^ (value < 10)) > ~sample; and: Sample(all) | inRange? !inRange, !outOfRange; !inRange: Sample() > ~sample !outOfRange: ; The basic difference appears to be that the latter is a considerably more powerful construct. Any test is possible; not just simple equality and inequality tests. If I want select just prime number; or filter strings based on search criteria, then the second method must be used. Another difference is the level of precision. In the first version, the constraints are directly specified. In the latter, they are specified indirectly in the process description. What criteria (other than common sense) should be used to determine which style to use. Especially close to the borderline of test complexity. Criteria are needed, otherwise different analysts will produce different solutions. Similar issues arise when sorting dataflows. though the issue is perhaps less confused. Simple sorts based on simple order within types can be expressed in the accessor. more complex sorting (for example, based on frequency) require a transform. There does not appear to be any reason not to use a transform for even fairly simple sorts. Having noted that there is an overlap between the processing of accessors and transforms, I find myself wondering why. Why am I not allowed to select prime numbers within an accessor? Why is the criteria of a test process placed in a separate process description whilst the selection criteria of an accessor are made explicit? It is actually quite easy to work around the restrictions. If I use the auto-calculation interpretation of mathematically dependent attributes, then I can simply define a predicate attribute (isPrime) and select based on that. Similarly, if I wanted to do frequency dependent sorting, I could define an attribute to hold the number of instances with the same value as the attribute upon which I want to sort. These work-arounds feel like kludges. I should not have to use kludges to express simple analysis level thoughts. Dave. Not Speaking for GPS. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com Subject: Re: (SMU) SMALL: Dataflows are Dataflows Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- Kenneth Cook wrote: > In defense of references: > > You say above that ""if a dataflow originates from an identifier then > a reference is attached to the flow". While identifying attributes > can be accessed in SMALL, there is no concept in SMALL of the > whole identifier (in the case where many attributes comprised the > identifier), so it seems you would just replace an Object Reference > with a special type of composite called "Identifier". Where is > the simplification? There are two environments to consider. When considering dataflows from an OOA perspective; then, as I said, dataflows are dataflows. There is no requirement for any concept of a flow being an identifier -- compound or otherwise. >From an RD perspective, a process does know that some input flows are used as identifiers. If you use tagged flows, then the translator can check to see if a flow that is used as an identifer has been tagged with a reference. If the identifier is compound then it must check that all the flows that consitute the identifier are tagged with the same reference. If there is no reference; or the reference is inconsistant, then a search/lookup is needed. One possible confusion here is that I am talking about an RD concept - not an implementation concept. In RD, the actual reference is probably unknown. The tag on the flow says that the flow references a set of instances of a specific object. To put it another way: an early step of the RD translates a dataflow based action language into a reference based action langauge. Tagging is one (easy) way of doing it. In fact, it is neccessary to translate the whole model into a reference based model; not just the action language. When I read the SMALL document, it appeared that PT has moved OOA from a relational data model to a reference based model -- thus eliminating the initial translation step. > The primary benefit of references is they allow modelers to say, > "I've already found this thing - so don't waste time finding > it again." It is wrong to put this information in the OOA (SMALL is part of the OOA). If the translator technology needed to work out that a reference is already known was complex; then I might accept that some pollution of the OOA is justified on pragmatic grounds. But the required techniques are not difficult. > Even using Identifiers would hamper performance in such systems: > one could not assume that an identifier identified an in-memory > instance: some kind of hash of the in-memory instances would need > to be kept, thus the analysis method would build-in at least that > kind of performance hit. You seem to be assuming that it is necessary to propogate identifiers into the implementation. It is not. Dave. Not speaking for GPS. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com Subject: Re: (SMU) SMALL: Pre-created events David Yoakley writes to shlaer-mellor-users: -------------------------------------------------------------------- Ken Cook wrote: > > "Ken Cook" writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > > David Yoakley writes to shlaer-mellor-users: > > -------------------------------------------------------------------- > > What exactly are [pre-created events] > > Create an instance of an event, complete with target instance and > supplemental data values filled in and ready to go. Then store it, > pass it around, and, later, execute it. > > We often use them as callbacks - they are somewhat analogous to function > pointers. > > -Ken Do you use them exclusively for inter-domain callbacks or are they used more generally? I can envision where these would have been useful for the now archaic timer objects since this provides a way to get supplemental data on the timer event however the 00A96/SMALL delayed event abstraction looks more elegant in this regard. dy ________________________________________________________________________ David Yoakley Objective Innovations Inc. Phone: 512.288.5954 14606 Friendswood Lane Fax: 512.288.6381 Austin, TX 78737 Replies: yoakley@oiinc.com ________________________________________________________________________ Did you ever notice when you blow in a dog's face he gets mad at you? But when you take him in a car he sticks his head out the window! Steve Bluestone Subject: Re: (SMU) SMALL: Dataflows are Dataflows Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- Kenneth Cook wrote: > I'm interested in this idea of simplifying SMALL by having it > follow the dataflow paradigm more closely. But... > > In defense of references: > > You say above that ""if a dataflow originates from an > identifier then a reference is attached to the flow". > While identifying attributes can be accessed in SMALL, > there is no concept in SMALL of the whole identifier > (in the case where many attributes comprised the > identifier), so it seems you would just replace an > Object Reference with a special type of composite > called "Identifier". Where is the simplification? I've looked at my previous reply and noticed I omited one important aspect of the answer to this question. I agree that if you have compound identifiers then you do need more dataflows to carry this information (though you can bundle them together). This is a consequence of the analysis and a don't think of it as complexity - just added bulk. The introduction of references does reduce this overhead. But it adds complexity to the language. A consequence of the addition of references is the introduction of the rule that says that you can't read/write referential attributes. A consequence of this restriction is the introduction of compensating link/unlink constructs; and this introduces additional complexity for worrying about referential identifiers. There may be a bit more work for a translator; and there may be a few extra dataflows to be specified; but the language is simplified by sticking with the purist dataflow approach. As an example, I have translated diagram 6.19.1 into SMALL with no references. (In the process of doing this, I noticed that process TR.7 is both an Accessor and a Test - an error?) ([~rampId | TR.EndTime], CurrentTime) | DetermineIfRampComplete? !Complete, !NotComplete ; !Complete: ~rampId | Gen TR12 ; !NotComplete: [ ~rampId | Gen TR13 ; (CurrentTime, [~rampId | TR.(StartTime, EndTime, StartTemperature, EndTempaerature)]) | ComputeDesiredTemperature > ~DesitedTemperature ; ~rampId | TR.batchId | Batch.tankId | CT. > %CT ; (%CT.actualTemperature, ~DesitedTemperature) | DetermineIfHotEnough? !HotEnough, !NotHotEnough ; !HotEnough: %CT.heaterId | Gen H20 ; !NotHotEnough: %CT.heaterId | Gen H21 ; ] Its pretty similar to the original. Although not strictly necessary, I decided not to use explicit relationship navigation; instead I piped referential identifiers through accessors. This was so simple that I would consider dropping relationship navigation from SMALL as well as references and linking. Dave. Not speaking for GPS. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com Subject: Re: (SMU) SMALL:bye bye Relational data model? David Yoakley writes to shlaer-mellor-users: -------------------------------------------------------------------- > It is wrong to put this information in the OOA (SMALL is part > of the OOA). If the translator technology needed to work out > that a reference is already known was complex; then I might > accept that some pollution of the OOA is justified on pragmatic > grounds. But the required techniques are not difficult. > I guess difficult is a very relative term. I know from experience that mapping relational key values to optimized references is not nearly as straight forward as you imply. Any given implementation must choose trade-offs for performance of instance creation, deletion, access, search and also code size. These assumptions are also frequently built on top of additional assumptions about instance populations. There is no question that OOA objects reference each other so I ask what is so great about the relational model reference technique which uses duplicate key values? Does this not infringe on the "one-fact-one-place" notion which you frequently espouse? And of course there is nothing more fun than maintaining relational integrity when the key values change (this problem goes away when the reference is abstract unless of course the change in the key values reflect a change in the relationship). I also could not follow your prior argument regarding limitations when dealing with multiple formalizations. Maybe you can elaborate on this. dy ________________________________________________________________________ David Yoakley Objective Innovations Inc. Phone: 512.288.5954 14606 Friendswood Lane Fax: 512.288.6381 Austin, TX 78737 Replies: yoakley@oiinc.com ________________________________________________________________________ Did you ever notice when you blow in a dog's face he gets mad at you? But when you take him in a car he sticks his head out the window! Steve Bluestone Subject: (SMU) SMALL: Abandonment of relational model "Lynch, Chris D. SD" writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Whipp: ---------- > When >I read the SMALL document, it appeared that PT has moved OOA >from a relational data model to a reference based model -- I think of OOA as being relational primarily in its information modeling and that relational theory is not important to process modeling. Can you enlighten me here? For one thing, I don't know what it would mean for the model to be "reference _based_". Thanks, -Chris ------------------------------------------------------------------------ ---- --------- Chris Lynch Abbott Ambulatory Infusion Systems San Diego, CA LYNCHCD@HPD.ABBOTT.COM ------------------------------------------------------------------------ ---- --------- Subject: Re: (SMU) SMALL: Pre-created events Kenneth Cook writes to shlaer-mellor-users: -------------------------------------------------------------------- At 09:28 AM 12/9/97 -0500, you wrote: >David Yoakley writes to shlaer-mellor-users: >> We often use [pre-created events] as callbacks...[snip] >Do you use them exclusively for inter-domain callbacks or are >they used more generally? Yes, we use them for inter-domain callbacks, including a scheme to register exception handlers to pick up exception generated in the implementation, and pass them "up into the analysis". However, we don't restrict modelers for using them for other purposes. Can't think of any good examples, though. -Ken Subject: Re: (SMU) SMALL: Dataflows are Dataflows David Yoakley writes to shlaer-mellor-users: -------------------------------------------------------------------- Dave Whipp wrote: This was so simple that I would consider > dropping relationship navigation from SMALL as well as > references and linking. > One thing I like about relationship navigation is that you cannot navigate a relationship that does not exist. Using relationship navigation to support access thus compliments the information modeling process, enforcing the importance of capturing relationships correctly. This way Relationships become something tangeable to the analyst instead of just documentation (and input to the RD). They are needed to support access. Interestingly enough, a significant number of performance problems that I have seen, I attributed to either relationships that were not modeled or modeled relationships that were not used. These situiations are always tough for the architect because analyst's frequently (and incorrectly) attribute all performance issues to the architecture. I think relationship navigations tend to reduce these OOA induced performance errors. dy ________________________________________________________________________ David Yoakley Objective Innovations Inc. Phone: 512.288.5954 14606 Friendswood Lane Fax: 512.288.6381 Austin, TX 78737 Replies: yoakley@oiinc.com ________________________________________________________________________ Did you ever notice when you blow in a dog's face he gets mad at you? But when you take him in a car he sticks his head out the window! Steve Bluestone Subject: Re: (SMU) Mathematical Dependence Neil Lang writes to shlaer-mellor-users: -------------------------------------------------------------------- The discussion on mathematical dependence seems to have quieted down for a while, and I thought I would make a few observations about the discussions in the hope that we can reach some common understanding and then head off for more fertile fields. The discussion has focussed almost entirely on process oriented issues: where and how the formula is to be incorporated into either the process model or the architecture. There have also been questions about the semantics implied by mathematically dependent attributes. I found Mike Frankel's classification of processing into aysynchronous, synchronous, and (architecture-resident) forced updating very intriguing (and emminently borrowable ). But the fact of the matter is that our work and decisions about mathematically dependent attributes was driven by data considerations and not processing issues. Tagging an attribute with (M) indicates that the attribute violates the SMOOA rules of attribution (which state in part that an attribute is correctly placed if it depends upon the value of the identifier of an instance and only the identifier.) When an analyst chooses to abstract an attribute and then recognizes that it is computable from the values of other non-identifying attributes (and we won't worry at this time if they are in the same or different objects), the analyst needs to record this additional knowledge in the model. We felt the right way to do this was to tag the attribute to show that it violates the strict rules of attribution, AND to document the mathematical dependence as understood by the analyst. We did not make any statement about the way in which the "formula" would ultimately be captured in the remainder of the model because that's a decision to be made later by the state/process modelers. Remember that a Shlaer-Mellor OOA model is built sequentially -- the OIM is constructed and reviewed before the State/Process modelers do their thing. Only after the dynamics of the domain are understood can decisions be made about how to appropriately develop processing that implements the dependency. And I'm going to claim that depending upon the nature of the domain and its dynamics, the analysts may choose any of the three semantics that Mike Frankel mentioned. I would expect in a significant proportion of models, the builders of the state/process models will directly incorporate the "formula" into a transformation process in one or more state actions. But I can also see other cases where the modelers would choose to build it into a synchronous read. And in some cases I can see the modelers crafting the processing so there's no need for the dependent attribute (so ultimately it disappears from the OIM). And there will be some problems that are so dominated by these types of calculations (a spreadsheet is a good example of this) that a decision may be made to build a formula or computation engine as an architectural service. Sally developed such an architecture in the early 80's to handle periodic recomputation of diagnostic data collected at the end of every beam pulse in a irradiation facility. Sally's "timepoint" architecture does have formula, parameter, and chore abstractions in it, but they arise from the nature of the problem domain. They are not required to support the OOA formalism itself and we do not see such abstractions in the meta-model of the methodology. So I'm asserting that the tagging of an attribute as mathematically dependent does NOT imply any one of the semantics suggested by Mike. Any of them can be used. I think we need to understand exactly what the (M) notation implies in the methodology. It says the following * the tagged attribute violates the rules of attribution * a dependency among attributes has been recognized and documented. It says nothing about how and when such dependency will be computed (that's the responsibility of the analyst) and it certainly makes no requirement on the architecture to maintain the dependency. I see a lot of similarity with unconditional relationships. Specifying a unconditional relationship in the OIM says nothing about how/when to create the participating instances and in particular the association between them. That is done explicitly and separately in the state and process models. In both cases it will take processing over some finite period of time to re-establish consistancy, and there is no requirement that this be done within a single process, or even action. And in both cases it's the analyst who is responsible for specifying the processing. That's the ground rules, folks. I suspect that some of you might have chosen a different set of ground rules but before we can try to discuss that, we first need to agree on what the OOA ground rules are. Neil ---------------------------------------------------------------------- Neil Lang nlang@projtech.com Project Technology, Inc. 510-567-0255 x623 10940 Bigge Street San Leandro, CA 94577 http://www.projtech.com ---------------------------------------------------------------------- Subject: Re: (SMU) SMALL: Dataflows are Dataflows David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: -------------------------------------------------------------------- There's a lot of comments been made. I'll be as brief as I can. Please let me know if I'm too brief David Yoakley wrote > I guess difficult is a very relative term. I know from > experience that mapping relational key values to optimized > references is not nearly as straight forward as you imply I do most of my code generation manully, so perhaps I have a slightly unusual perspective. But I'll stand by my point of view. Give me any dataflow diagram and I'll mark up the dataflows that are changed to references in SMALL. This task doesn't require any creativity or complex pattern matching, so it should be simple for a computer to do. The difficulties you refer to are the problems of building an architecture (execution formalism) that uses references effectively. That's why architectures are difficult; and why so many people use OOA-of-OOA as their architecture. > Any given implementation must choose trade-offs for performance > of instance creation, deletion, access, search and also code > size. These assumptions are also frequently built on top of > additional assumptions about instance populations. Thats irrelevent to this discussion. Its truth is independent of the source notation. > There is no question that OOA objects reference each other so I > ask what is so great about the relational model reference > technique which uses duplicate key values? Does this not > infringe on the "one-fact-one-place" notion which you frequently > espouse? What's so great about the relational model? Nothing, except for the fact that SM is based on it. (There are some other points about its strong theoretical basis, with minimised redundency through normalisation; but I'm sure these benefits could be derived with other methods) But as Chris Lynch wrote: CL: Can you enlighten me here? For one thing, I don't know what CL: it would mean for the model to be "reference _based_". This underscores the fact that other data modelling formalisms are not as well understood as the relational data model. A reference based model would presumably be based on the concept of objects linked by pointers, not referential attributes. In such a model, all identifiers would become arbitary. This is a very different model, and may make a good architecture. But the fact that its an architecture, and therefore is presumably a sound basis for the production of efficient code, doesn't mean that its a good analysis model. The job of translating onto the architecture is the responsibility of Recursive Design, not analysis. Continuing with my reply to DY: I'm not sure I know what you mean by "duplicate key values". I'm going to assume that you are talking about the fact that two facts in two places take on the same value. But that is two facts. If my name is David, and my Passport says David on it, this is not one fact in two places. Both bits of information represent different facts. > And of course there is nothing more fun than maintaining > relational integrity when the key values change (this problem > goes away when the reference is abstract unless of course the > change in the key values reflect a change in the relationship). Whatever data model you use, some operations are easier than others within that model. In the case of SM, if you have identifiers that change then perhaps they aren't identifiers. If the names of two objects can potentially swap round then obviously the name doesn't identify the object. Use an arbitary identifier instead; and make the name descriptive. > I also could not follow your prior argument regarding > limitations when dealing with multiple formalizations. Maybe > you can elaborate on this. I'll try. My argument wil show that SMALL does work; and that most of problems are "solved" by increased complexity. If you have an attribute that formalises more than one relationship then, from a data modelling point of view, writing to that attribute will effect both relatinships. This is obvious because relationships are defined by their data. If you use link/unlink and referential attributes (perhaps make them read only) then when you link one of the relationships then the data is changed; and thus the other relationship is also changed. Delete one, and the other goes. Either that or the referential attribute has two simultaneous values. I must see Mr Shrodinger about his cat sometime. An attribute with two values is pretty meaningless. The way that SMALL get around the problem is that it eliminates both read and write accesses to ref. attributes; and also says that their value has no meaning. This makes the process model work, but what about the IM? In the IM the domain of a referential attribute is the same as the thing(s) it refers to (possibly plus "none"). So we are left with an inconsistency between the process models and the information model. An attribute as two different domains. Here I'll bring Chris Lynch back in. He wrote: CL: I think of OOA as being relational primarily in its CL: information modeling and that relational theory is not CL: important to process modeling. In otherwords he feels that the inconsistency between the PM and IM does not matter. This is probably the cornerstone to my oposition to references. An object model should bring together both the data and control aspects into one seamless model. By attempting to use two different formalism within one objtect model you get increased complexity and a mismatch where the two formalisms meet. And I see very few benefits in compensation. So I'll repeat: It isn't references per-say that I don't like. Its the use of two different formalisms and the mismatch between them. Dave. Not speaking for GPS. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com Subject: Re: (SMU) SMALL: Dataflows are Dataflows Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- David Yoakley wrote: > One thing I like about relationship navigation is that you > cannot navigate a relationship that does not exist. Using > relationship navigation to support access thus compliments > the information modeling process, enforcing the importance > of capturing relationships correctly. This way Relationships > become something tangeable to the analyst instead of just > documentation (and input to the RD). They are needed to > support access. Relationships are tangible. They are made tangible through their formalisation. I don't see how explicit relationship navigation effects the issue of relationship consistency. Reading a referential attribute and then using it in an identifier context is equivalent to a navigation. > Interestingly enough, a significant number of performance > problems that I have seen, I attributed to either relationships > that were not modeled or modeled relationships that were not > used. These situiations are always tough for the architect > because analyst's frequently (and incorrectly) attribute all > performance issues to the architecture. I think relationship > navigations tend to reduce these OOA induced performance errors. I will not argue with the need for producing good analysis models; nor with the proposition that analysis can have a greater impact on performance than the architecture. However, I disagree with your examples. If you use the object access model then you know which relationships are used. Part of the translation process can use this information to drop relationships from the architectural model. An unmodelled relationship will cause problems when navigated, but thats an analysis issue, not a notation issue. I can't help feeling you're confusing analysis with design. The fact that SM uses "recursive design" does not make the design step any less important. Building an architecture is difficult. Tranlating a model onto it can be just as difficult. But separating these stages is a lot easier than an attempt to generate efficient code from the OOA. Many of your comments suggest that you are attempting to use OOA-of-OOA as your architecture (with a few minor tweaks). If you want to use pointers, references, shortcut navigations, Mealy state machines, etc. then put them in the architecture, not the OOA-of-OOA. An aside here: I often find myself using architectures without using OOA. OOA-of-OOA is one formalism of many possible ones. I tend to use a formalism that is appropriate to a design space and populate that model directly. It enables me to do efficient code generations without using RD. But as soon as models have more than a few objects; or have interesting behaviour, then I go back to OOA. The knowledge of how a small number very different architectures work, helps me appreciate the minimalism of OOA. I'd like to keep it that way. I like the SMALL language for its dataflow concepts; and there's not a lot wrong with its syntax. But I think its too big and complex when compared to DFDs. And it breaks the OIM. Dave. Not speaking for GPS. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com Subject: Re: (SMU) SMALL: Dataflows are Dataflows Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- I wrote: > However, I disagree with your examples. If you use the object > access model then you know which relationships are used. My appologies. I didn't mean OAM for this optimisation - that's a slightly different issue. Here is a fairly simple algorithm (probably incomplete in some details) that works out which relationships to drop (or rather, which not to map into the architecture). For each relationship, find its referential attributes. Now search all accessors to see if these attribtes are ever read. If they are not, then drop them and their relationships. If only some are ever read then drop the relationship and the attributes that are never read (presumably the ones that are read are used for a different reason - possibly for other relationships) So we now have all the places where the referential attributes for a relationship are used as a group within a single action or SDFD. Now we need to work out if they are used in an identifier context (where the identifier relates the the defining object). If not, then drop the relationship. There are several possible contexts to test for: Are they compared against an identifier in a search accessor? (this tests for navigation in either direction - you can worry about directionality later). Are they used as an identifier for either a create or a delete accessor? Are they piped into an event generator or wormhole as an identifier? Are they written to referential attributes in another object? You will also need to check any non-standard facilities that your architecture supports. For example, if (M) attributes are maintained by the achitecture then relationships may be used in the calculation (indeed, a referential attribute may be the target of the calculation!) Dave. Not speaking for GPS. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com Subject: Re: (SMU) Mathematical Dependence lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Lang... > So I'm asserting that the tagging of an attribute as mathematically > dependent does NOT imply any one of the semantics suggested by Mike. > Any > of them can be used. > > I think we need to understand exactly what the (M) notation > implies in the methodology. It says the following > * the tagged attribute violates the rules of attribution > * a dependency among attributes has been recognized and documented. I would prefer a more rigorous specification, but I have no particular problem with this sort of abdication of responsibility to a negotiation between the analyst and the architect. > I see a lot of similarity with unconditional > relationships. Specifying a unconditional relationship in the OIM > says nothing about how/when to create the participating instances > and in particular the association between them. That is done > explicitly > and separately in the state and process models. In both cases > it will take processing over some finite period of time to > re-establish > consistancy, and there is no requirement that this be done > within a single process, or even action. And in both cases it's the > analyst > who is responsible for specifying the processing. > That's the ground rules, folks. I do have a big problem with this particular example, however. I believe there are different levels of consistency. One of them is illustrated by this thread in that in certain cases an (M) dependency can only be correctly calculated when two or more independent attributes are consistent. In general the analyst has to ensure that consistency somehow in the OOA explicitly. My problem, though, is that I see unconditional relationships as a different level of consistency. I believe the analyst must be able to count upon relationships being instantiated at least at the action level. [I think one could argue that they must be in place when the create accessor or relational attribute write accessor returns -- after all these are synchronous processes so one should reasonably expect that their activities are complete when they return.] However, if the analyst cannot count on relationships being intact when the action instantiating them is complete, then we have anarchy. Let's say action A1 creates some instance, B, and establishes an unconditional relationship with it. Suppose also, that an externally generated event can transition from A1 to A2. The architecture can hold up the event until A1 finishes, but then A2 executes immediately. If A2 needs to navigate to B, how does the analyst ensure that this will work if one can't count on the fact that the relationship is intact? At best the analyst will have to litter the state models with processing that has nothing to do with the problem at hand. At worst, that processing will be implementation-specific (e.g., closing database transactions, setting semaphores, waking threads, etc.). In fact, I can't think of an example where it would not require at least an implementation-specific assumption about the architecture (e.g., that the value written to the DB store is cached for immediate local access by the DBMS while the transaction is open). At this level of consistency I think the analyst has to be able to count on the certain things when an action completes. Among them are: any instances created are accessible; any relationships instantiated are navigable; and any attributes read will yield the values written in that action. I don't see any way for the analyst to develop a clean and focused OOA at a given level of abstraction without being able to count upon these things. Subject: Re: (SMU) Mathematical Dependence Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- > And there will be some problems that are so dominated by these > types of calculations (a spreadsheet is a good example of this) > that a decision may be made to build a formula or computation > engine as an architectural service. Sally developed such an > architecture in the early 80's to handle periodic recomputation > of diagnostic data collected at the end of every beam pulse in a > irradiation facility. Sally's "timepoint" architecture does > have formula, parameter, and chore abstractions in it, but they > arise from the nature of the problem domain. They are not > required to support the OOA formalism itself and we do not see > such abstractions in the meta-model of the methodology. Developing new architectural services is an interesting issue. Whilst it is easy to add the service to the architecture; and not too dificult to add it into the translator; there is a problem when adding the feature into the model. You end up putting functional information as colorations or parsing descriptions. The real problem here is that it prevents you simulating the model in any existing simulator. This is generally felt to be a very good reason for not adding architectural features (at least, it is where I work). So whilst I will happily to this sort of thing in mini-projects, I can't use them in any big projects. I wrote about this problem of CASE tools stifling creativity a couple of years back on ESMUG. The issue isn't going away. Perhaps there should be a chapter in the RD book on how to go about adding functionally significant architectural services. Then, perhaps, some simulators may let you add them. Dave. Not speaking for GPS. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com Subject: Re: (SMU) SMALL: Dataflows are Dataflows David Yoakley writes to shlaer-mellor-users: -------------------------------------------------------------------- I don't have much time to respond so I will try to get to the point quickly. Dave Whipp wrote: > > Any given implementation must choose trade-offs for performance > > of instance creation, deletion, access, search and also code > > size. These assumptions are also frequently built on top of > > additional assumptions about instance populations. > > Thats irrelevent to this discussion. Its truth is independent > of the source notation. > This was only meant to counter you statement that the translation techniques were not difficult. I think it is very relevent because a significant amount of the difficulty is due to the fact that OOA referential attributes are identifying attributes and not simply references. Try converting a Social Security number to a reference at runtime. I don't see nearly as many trade-offs when dealing with arbitray references. If I can count on the fact the a reference actually identifies an instance and I know that the architecture is in control of implementing the reference then I don't expect to be deciding where to take the performance hit to search an instance population. > > There is no question that OOA objects reference each other so I > > ask what is so great about the relational model reference > > technique which uses duplicate key values? Does this not > > infringe on the "one-fact-one-place" notion which you frequently > > espouse? > > What's so great about the relational model? Nothing, except for > the fact that SM is based on it. (There are some other points > about its strong theoretical basis, with minimised redundency > through normalisation; but I'm sure these benefits could be > derived with other methods) I don't think you read my post carefully. I was not calling into question the relational model, only the applicability of its reference technique (duplicated ids). My point is that the purpose of a referential attribute is only to refer to an instance (maybe this is where we disagree?). So if you buy the S-M notion that referential attributes are used to refer to another instance then I ask why would an analyst would insist that a reference not only REFERS but that it is also the instances OOA identifying attributes? > > But as Chris Lynch wrote: > CL: Can you enlighten me here? For one thing, I don't know what > CL: it would mean for the model to be "reference _based_". > > This underscores the fact that other data modelling formalisms > are not as well understood as the relational data model. > A reference based model would presumably be based on the > concept of objects linked by pointers, not referential > attributes. In such a model, all identifiers would become > arbitary. What? OOA identifiers would not have to be arbitray. Just the referential attributes. And certainly the referential attributes could be implemented by pointers. They could also be implemented as references (C++ or Java) or even the OOA identifying attributes. > I'm not sure I know what you mean by "duplicate key values". > I'm going to assume that you are talking about the fact that > two facts in two places take on the same value. But that is > two facts. If my name is David, and my Passport says David > on it, this is not one fact in two places. Both bits of > information represent different facts. And what about my address? It is also already captured in Person. Does the fact that it is printed on a passport mean that you must capture it again in Passport as a separate fact? The fact that you are using name as a referential attribute says that the name on the passport will not vary from the name of the Person object. So why not just capture a reference and go to Person for name (and any other facts related to person that are needed on a passport)? dy Subject: Re: (SMU) SMALL: Dataflows are Dataflows David Yoakley writes to shlaer-mellor-users: -------------------------------------------------------------------- Dave Whipp wrote: > > Dave Whipp writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > David Yoakley wrote: > > One thing I like about relationship navigation is that you > > cannot navigate a relationship that does not exist. Using > > relationship navigation to support access thus compliments > > the information modeling process, enforcing the importance > > of capturing relationships correctly. This way Relationships > > become something tangeable to the analyst instead of just > > documentation (and input to the RD). They are needed to > > support access. > > Relationships are tangible. They are made tangible through > their formalisation. I don't see how explicit relationship > navigation effects the issue of relationship consistency. > Reading a referential attribute and then using it in an > identifier context is equivalent to a navigation. I agree that using the referential attribute is equavilent. Thats really not my argument. The problem is that it takes a while to learn how to do good modeling. A relationship traversal seems to me to be a better/simpler way to think about accessing a related object than performing an access using a referential attribute. The IM notation states a relationship exists. The AL notation says to traverse the relationship. The IM and the AL seem to be playing together better. I think this will be apparent to newbys to the formalism. I think that folks that have been doing this for a while (and doing it right) will not care so much because the two methods are equavilent. Unfortunately there are a significant number of people that have been doing this for a while that are still not doing it right. I am always looking for ways that the formalism can entice them into the correct mode of thinking. I think relationship chaining does this. There is something else that I mentioned earlier. It is just too easy to be sloppy when using the direct access technique. Take the case where a relationship was put in place early (as PT recommends) Later on, after the process modeling started, it was noticed that it was not formalized quite right and thus the needed access could not be made. Since the access methods are general purpose, the analyst does not have to fix the problem on the IM. Hey, just add some more qualifiers to the access. The altered access can easily lead to a performance problem since it is using attributes in addition to or in place of the referential attributes. Now the analyst is going to say "oh that's an architecture problem" when it is clearly not. This problem will not occur when the analyst is required to use relationship chaining to refer to related instances. Save the ad-hoc access techniques for cases when the relationship has not been established yet. I recognize that I am mostly arguing my intuition and probably not going a good job at it. So maybe its time to hear from some other folks in the "community". I also must confess that I find it easier to translate relationship chaining to an efficient implementation because I don't have to filter out the cases where the access does not strictly use the referential attributes an equality but I am trying to not let that cloud my opinion. dy ________________________________________________________________________ David Yoakley Objective Innovations Inc. Phone: 512.288.5954 14606 Friendswood Lane Fax: 512.288.6381 Austin, TX 78737 Replies: yoakley@oiinc.com ________________________________________________________________________ Did you ever notice when you blow in a dog's face he gets mad at you? But when you take him in a car he sticks his head out the window! Steve Bluestone Subject: Re: (SMU) SMALL: Dataflows are Dataflows Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- David Yoakley wrote: > a significant amount of the difficulty is due to the fact that > OOA referential attributes are identifying attributes and not > simply references. Try converting a Social Security number to a > reference at runtime. I don't see nearly as many trade-offs when > dealing with arbitray references. Why would you want to convert a Social Security number to a reference at run time? You may want to do so in a bridge or a wormhole (i.e. when it is entered by a user) but once its in the system it is highly unlikely to be stored as a string of digits. That would be inefficient. Most (though not all) implementations will not store referential attributes. They will just store the relationship (as references/pointers). That is not the issue. > If I can count on the fact > the a reference actually identifies an instance and I know that > the architecture is in control of implementing the reference then > I don't expect to be deciding where to take the performance hit > to search an instance population. I am sure that your implementation will be able to count on that fact. It depends on your architecture. It has nothing whatsoever to do with anlysis. > I don't think you read my post carefully. I was not calling into > question the relational model, only the applicability of its > reference technique (duplicated ids). My point is that the purpose > of a referential attribute is only to refer to an instance (maybe > this is where we disagree?). So if you buy the S-M notion that > referential attributes are used to refer to another instance then > I ask why would an analyst would insist that a reference not > only REFERS but that it is also the instances OOA identifying > attributes? The analyst produces an information model. It contains referential attributes to relate objects. Why shouldn't the analyst expect to use these referential attributes to reference related objects? I understand completely the reasons why the architect/designer doesn't want to use them, But that's not the point. When the analyst talks to a customer, it is often useful to draw a simple table to demonstrate what's going on. Look at the bottom of page 18 of the SMALL document. The right hand table has a column for "cave". This is obviously referential, and contains a meaningful value. An implementation will probably implement a pointer between the two instances and then implement a read accessor (if its needed) as a navigation. The implementation will not store anything to do with referential attributes. It will probably optimise out most read accesses to referential attributes and pass pointers round. If the referential attribute is only ever read for navigation purposes then the accessor probably won't be implemented. Its quite nice to have it when debugging though. I can just edit the code and add a print statement to see what's going on. > > This underscores the fact that other data modelling formalisms > > are not as well understood as the relational data model. > > A reference based model would presumably be based on the > > concept of objects linked by pointers, not referential > > attributes. In such a model, all identifiers would become > > arbitary. > What? OOA identifiers would not have to be arbitray. Just > the referential attributes. And certainly the referential > attributes could be implemented by pointers. They could > also be implemented as references (C++ or Java) or even > the OOA identifying attributes. Sorry, my lack of clarity probably caused you to misread my statement. There would be no OOA identifiers in the model (not as identifiers, anyway) because it is not an OOA model. Its something else! If you construct a model based on references then identity is based on the principle of references. These are arbitary from the point of view of the analyst. That's almost a definition of a reference. A common implementation of a reference is a pointer (memory location) but it really doesn't matter. It depends on the code generator. This model is no longer based on the relational data model. To use identifiers that are meaningful to the analyst in such a model would be wrong. It would be equivelent to hard coding the value of a pointer in a (portable) C program. There would be no referential attributes. Relationships would be modelled as [lists of] references. I keep returning to the basic principle of RD: analysis is not design. If you structure you code around OOA-of-OOA then it makes the translation simple but gives awful performance. That is not a problem. If you want to get reasonable performance then you need a design step. And in design, you can convert identifiers and referential attributes into references (pointers). Dave. Not speaking for GPS. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com Subject: Re: (SMU) SMALL: Dataflows are Dataflows David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: -------------------------------------------------------------------- David Yoakley wrote: > I agree that using the referential attribute is equavilent. > Thats really not my argument. As soon as I read this, I realised that we have no argument. Shlaer-Mellor has always taken the view that any notation can be used. What matters is the underlying formalism. If two notations are provably equivelent (as they are in this case) then either can be used. My remark about not needing chained relationship navigation was a throw-away remark for which I appologise. It diverted us from the important issue. My real concern is the use of references: link/unlink and the rules about unreadable attributes. The use of references is demonstrably not equivalent to the relational data model. The most striking evidence of this is the dual attribute-domain of referential attributes. The information model defines it one way, the process model defines it as meaningless. > So maybe its time to hear from some other folks in the > "community". I wholeheartedly support that sentiment. Dave. Not speaking for GPS. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com Subject: (SMU) SMALL: Dataflows are Dataflows Dana Simonson writes to shlaer-mellor-users: -------------------------------------------------------------------- > So maybe its time to hear from some other folks in the > "community". I haven't found time to finish reading the SMALL paper yet, so I'll limit my comments to simply stating that whatever the final form yields, I would hope that the DFD and SMALL approches would be one-for-one equivilent. If you link in one than you should link in the other. Subject: Re: (SMU) SMALL: Dataflows are Dataflows David Yoakley writes to shlaer-mellor-users: -------------------------------------------------------------------- Dave Whipp wrote: > I am sure that your implementation will be able to count on that > fact. It depends on your architecture. It has nothing whatsoever > to do with anlysis. Yeah you are right. I was stretching for a quick example. The cases I had actually experienced were more issues with building a good automatic translator with minimal OOA constraints on its use (I don't want to skip the design step, I just want to be able to re-use it a whole lot ;-). I have taken us too far from your central point which was that the use of SMALL references is inconsistent with the IM formalism. Let me just say that I do like the references. I see them as a short-hand notation to simplify a given action. Much like saving a mathmetical computation to a variable even you are not concerned about CPU overhead. And if they happen to also make building a translator easier ... dy ________________________________________________________________________ David Yoakley Objective Innovations Inc. Phone: 512.288.5954 14606 Friendswood Lane Fax: 512.288.6381 Austin, TX 78737 Replies: yoakley@oiinc.com ________________________________________________________________________ Did you ever notice when you blow in a dog's face he gets mad at you? But when you take him in a car he sticks his head out the window! Steve Bluestone Subject: Re: (SMU) SMALL: Dataflows are Dataflows Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- David Yoakley wrote: > I have taken us too far from your central point which was > that the use of SMALL references is inconsistent with the > IM formalism. Let me just say that I do like the references. > I see them as a short-hand notation to simplify a given > action. Much like saving a mathmetical computation to a > variable even you are not concerned about CPU overhead. And > if they happen to also make building a translator easier ... To you identify two percieved advantages of references (and their other baggage): They provide a shorthand notation for simplifying actions and they make the translator simpler. If I accept these advantages then the question to be asked is: what is the cost? and then is there an alternative that provides the same advantages at a lower cost? I will also argue that the translator is not, in fact, simplified. In calculating the costs, I will include the link and unlink statements. It is these that incur the big costs. I could probably compromise, and accept references, if Link and Unlink were removed. The basic cost is increased complexity. There's a new type of dataflow (the reference). There are two new process types: link and unlink. There is a concept of attributes that are meaningless to the analyst - and the restrictions that these cause on read/write accessors. And, of course, the inconsistency with the IM. These are the analysys level complexities. If none of these things were present, then SMALL would be no less powerful. It would still be able to fully manipulate the IM. (This isn't a turing equivelence type argument. I do not beleive that SMALL without references is any less expressive than SMALL with references). These complexities in the anaysis actually increase the complexity the the translation engine. Each concept must be supported by the translator. The parser has more keywords; the parse tree has more note types; the sematic processors have more rules and restrictions to obey. If you believe that references are necessary for a given architecture then, of course, you will need the concept in the translator. So you will need the complexity. I remain to be convinced that the complexity of deriving references from dataflows is any greater than the complexity of supporting references in the source language. Let us suppose that references, etc. were removed from SMALL. Would this make an action description more bulky? Well, It could, unless there is some other concept that can provide the saving. At the end of Section 6.5, SMALL is given the concept of dataflow composition. In section 6.6, references are introduced which we can think of as "a set of identifying attributes". Is it resonable to equate "a set of identifying attributes" with a composed dataflow containing the identifying attributes of an object? There is probably a bit of tweaking to be done to make SMALL work without references. One possibiity is to add a special keyword to read accessors: a ".key" or ".all" attribute that returns a composed dataflow. It could be made implicit. This would provide the same simplifying effect whilst maintaining a pure dataflow foundation. Secondly, we would have to modify all the other statements to accept dataflows rather than references. This is complexity substitution, not addition. I would also beef up the concept of dataflow composition to make it analagous to the Perl "hash" instead of the current "array" concept. The main difference is that in hashes identify consituents by name whilst arrays identify them by position. So, in summary, there are costs involved in supporting references (specifically link and unlink) that I do not beleive are justified for the limited (and debatable) benefits for translator technology and notational simplicity. The costs span both language complexity (the analyst must learn rules and restrictions) and the translator (it must support the concepts). Dave. Not speaking for GPS. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com Subject: (SMU) SMALL: Sequence vs. Data Flows lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- I finally had a chance to look at SMALL over the weekend. On the upside I had very few problems with it and most of those were mostly nits. I will deal with those separately. In this section I will address may greatest misgiving, which is the clumsiness of embedding guards and blocks in the code to express control. In the examples this all worked quite nicely, but I think that the code will start to become very ugly when things get complicated (e.g., 30+ processes) with nested conditions and several control paths. However, my biggest misgiving is the ugliness that will be created in the vanilla cases where there really is a straight forward, as-written sequence -- at least at the conceptual level. The reality is that those classic building blocks for programs -- sequence, iteration, and branching -- are not limited to computer machine code. They also represent a very general approach to describing algorithms in particular and any sort of process in general. Therefore, I would like to see a language that uses those constructs in an uncluttered and natural way. I believe that this will not be the case if a complex process description is cluttered with the guards and blocks. Another reality is that the _control_ being captured by the guards and blocks that is not expressed by the three Turing components is only relevant to multi-processor architectures and often not even then because the language of choice will still be unable to express the dependencies. While I agree that the information the architecture _might_ need to truly allocate multiprocessor resources needs to be expressed in the language, I don't think it should clutter the more common case of basic Turing processing for a single processor environment or language. [One could argue that this information is not necessary at all since most optimizing compilers create this same DFD graph on the fly and figure out the dependencies in the most efficient way for that particular processor even on single processors, because of ALU pipelines. But that's another story...] Thus I would have preferred a notation that allowed the basic process to be expressed in Turing components and then supplement it with the precedence information. This could have been easily done unobtrusively by introducing labels (line numbers) for each statement of the Turing description and providing a separate preamble that expressed the precedence dependencies of the individual statements (i.e., the guards and blocks) with a clean syntax in terms of those labels. At most one might want to add a simple block delimiter within the description itself, such as the proposed []. My last, lesser, overall problem with the syntax is the elegance. The action program on pg. 25 is quite elegant and terse. However, years of using C has demonstrated that elegance and terseness are not necessarily virtues when it comes time to maintain the system. I had some difficulty relating the example code the DFD. Maybe this was due to unfamiliarity with the syntax. But I suspect I would have had more difficulty if some of the statements involved chains of a dozen processes and several embedded branches, even if I were used to the syntax. When we have ADFDs with 50+ processes, it is true that maybe 40% of these are navigation boilerplate that rightfully should be done is a compact notation like [R1->R2->R3] and another 20% are simple read/write accessors that merit terseness. But that still leaves a lot of tests and transforms where I would prefer verboseness to elegance. I don't want any niggling doubts that I missed some subtlety when one statement has six pipelines. -- H. S. Lahman There is nothing wrong with me that Teradyne/ATB could not be cured by a capful of Drano 321 Harrison Av. L51 Boston, MA 02118-2238 (Tel) (617)-422-3842 (Fax) (617)-422-3100 lahman@atb.teradyne.com Subject: (SMU) SMALL: lack of iteration lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- I have always had a problem with S-M's lack of depth-first iteration constructs. OOA96 was forced to add a notational artifact to support operations on ordered sets and binning, but this was done kicking-and-screaming. While the breadth-first iteration represented by successive set operations may be aesthetically appealing on a theoretical basis, it is generally not the way that people think about iteration when attempting to solve problems. This is especially true in the real world problem space involving people who are not mathematicians or software developers. I cannot recall ever seeing a process description outside of software or a course on set theory that used a breadth-first iteration; iterations in processes are _always_ described by a sequence of steps in a "for each" in the real problem space. I find it rather silly to translate the real problem space description to a set-based description in the OOA, just to have the RD translate it back to a depth-first iteration. Having gotten that flame over, let me go to the specific issue. The action language has eliminated the depth-first iteration, apparently because an elegant way was found to solve the binning problem. However, the breadth-first approach still does not work for all problems, particularly ordered set operations. For example, in the binning example on pg. 23, what if there were more steps and one of them created or deleted members of the set? In this case you don't want to always use the original set; instead you want to be sure every member of the new set is properly binned. On pg. 5 some arguments are used for not including For constructs. The first argument is that somehow the reusability of a process in a For construct is less evident than the reusability of the same process outside a For. I am definitely missing something in this argument since I don't see how the apparent reusability of the process is affected at all by either context. Another argument, in the preceding paragraph, seems to argue that the For somehow over specifies the problem. I do not see how this occurs. I do not see any fundamental difference in the level of specification between the depth-first and the breadth-first iterations -- they are both a sequence of repeated steps and they are exactly equivalent in all respects (except in the few cases where a breadth-first iteration would be incorrect). If anything the depth-first iteration is the more general construct because it works in all cases -- as demonstrated by the Turing components where iteration is always depth-first. Another argument is that the For construct allows one to place different "analysis ideas" in the body of the loop. I can't buy this because those "analysis ideas" will still be different if they are two successive set operations. Why is it bad to have different ideas in a sequence bounded by an iteration but it is not bad to have different ideas in a sequence bounded by a block bounded by a guard? Finally, I do not agree that a For structure makes it "more difficult to translate into the action into other organization[s]". If anything, the opposite is true. Every optimizing compiler on the market can routinely optimize things like invariants out of depth-first loops. This is not at all true for set operations. Any such optimizations have to be done by hand in the translation rules. In fact the set operations are generally eliminated entirely as part of RD -- nobody would seriously entertain the idea of using pure set operations if they want their program to execute in less time that it takes to have children. I assume the "other organizations" in this context were the control dependencies. However, the whole point of guards and blocks is to express these control flows, so the mechanism is already in place to do this and would not be affected by a For construct (which is nothing for than a [] block in this case). -- H. S. Lahman There is nothing wrong with me that Teradyne/ATB could not be cured by a capful of Drano 321 Harrison Av. L51 Boston, MA 02118-2238 (Tel) (617)-422-3842 (Fax) (617)-422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) (SMALL) Dataflows are Dataflows lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Since this particular thread has gone on so long, I feel morally obligated to contribute. The current issue seems to be whether one agrees with the reference/link/unlink usage or not. The quick summary is that I agree with both Whipp and Yoakley, but probably more with Yoakley, and my guess is that the paper was unclear about the concept. First, Let's do references. I think the first paragraph of 6.6 is, at best, very misleading when it includes "handle" in the list because "handle" is loaded with preconceptions that are in the mind of the contemplator. I agree with Whipp that things like "identifying attributes", "table names", etc. are very different critters from "handles" and "references". My interpretation of the intent is that a reference is simply a local shorthand (abstraction) for referring to an instance that was _previously_ found by conventional navigation using the relational data model identifier abstractions. Note that this does not necessarily mean relationship navigation; it would apply to pure set manipulations (e.g., Find). Thus I think it is a separate issue from link/unlink. The paper seems to be quite clear that it is not to be used on events; only locally in actions and synchronous processes. This is Good; otherwise Whipp would be correct in asserting that the relational model had been replaced. I do not view it as having any of the connotations of a "handle" or "reference" as those terms might be used in the RD. Thus I think I am closer to Yoakley's view in that I do not think it implies anything about a reference-based model; it is just a notational artifact to cut down on typing. Now let's do links. Offline I debated Lang over the value of link/unlink from Whipp's side and Lang has offered some persuasive arguments for why they are useful. Basically the argument is that link/unlink represents a higher level of abstraction than attribute assignment. It allows the process models to be independent of the choice of relational attributes (compound, unique, etc.) and their placement (e.g., in which object they go on a 1:1 in the IM). These are really issues for the translation based upon the IM information that is at a separate level of abstraction. The main reason that I have come to Love the Link, though, is that it repairs a serious problem: NOT PARTICIPATING. The use of NOT PARTICIPATING is plain broken if one has multiple conditional relationships that are constrained to have the same identifier value. This can happen with two relationships between the same instances or when one uses compound identifiers. One cannot have one conditional relationship active while the other is inactive if one uses attribute assignment AND one wants to capture the fact that the identifiers have to be the same if both relationships are active. The link/unlink solves this problem because NOT PARTICIPATING is not assigned to the relational attribute. The IM still captures the equality-of-value constraint by sharing the relational attribute among relationships, but the link/unlink allows the architecture to decide what mechanism to use for determining whether individual conditional relationships are active. The caveat that I have about link/unlink is really a different issue. I think they should only be used in two situations: for dealing with conditional relationships where both instances live beyond the temporal scope of the relationship and for swapping unconditional relationships (e.g., {A1<-->B1}, {A2<-->B2} => {A1<-->B2}, {A2<-->B1} where An and Bn are instances of A and B). I believe that all other relationships should be handled in the synchronous create and delete accessors. In particular, I think wherever possible the delete accessor should unlink relationships. Clearly when an instance is deleted, none of its relationships can remain. The architecture can handle this much more efficiently than it can be done in the OOA. We use an action language and in most domains about 20-30% of the action language code lies in synchronous services that delete instances. Worse, there is horrendous overhead because one does not necessarily know the order of deletion when multiple instances are being killed, so one has to check if unconditional relationships are actually there and this involves a very expensive Find. BTW, there is a problem with doing the unconditional links in the create accessor that is mitigated by using references. Passing the correct relational identifiers can get clumsy if one has several relationships with some shared compound identifiers. If one can simply pass the instance references, the invocation is a lot cleaner in the action code. I am somewhat ambivalent about this because it starts to impugn things to the reference that are more in line with Whipp's objections. It is one thing to use a reference as a notational shorthand within an action or synchronous service; it may be quite another to pass it as an argument to other services that will have to interpret it. I can argue that the create accessor is a special context because the argument is no different than the reference argument for a link, but I don't like exceptions. -- H. S. Lahman There is nothing wrong with me that Teradyne/ATB could not be cured by a capful of Drano 321 Harrison Av. L51 Boston, MA 02118-2238 (Tel) (617)-422-3842 (Fax) (617)-422-3100 lahman@atb.teradyne.com Subject: (SMU) SMALL: nits lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- The following are the nits that I thought of when reading the paper. Pg 2, Executability. The problem I have with the statement is that it is not true in general. Any time that you have a transform that modifies data and the modified data is tested subsequently to determine flow of control, you cannot execute the models without knowing the nature of that transformation. No set of execution rules can substitute for that knowledge (unless the rule is to emulate the transform). Pg 3, 1st bullet at the bottom. Bad example. As I read it, one always wants to test the remaining food _after_ the dogs eat at the current feeding. This allows the food to be ordered and received before the next feeding when it will be needed. If the test went before the loop one would not know one needed food until it was too late to avoid one or more dogs starving at the current feeding. Pg 4, 4th bullet. How separately are processing details within processes from the body of the action? My real question is: is there an assumption that processes will be written in native languages as realized code rather than in the same action language as the action body? If so, then I think we need a bit better definition of what a "synchronous service" is. If synchronous services are limited to wormhole support, then I think there is a problem. We tend to use synchronous services for any complex processing that does not affect state model flow of control. For example, when an action has to delete several related instances, we will call synchronous services to delete each instance. These services also take care of the boilerplate for unlinking the relationships in addition to invoking the delete accessor. Naturally, these synchronous services use the same action language as the action; we regard them as extensions of the state action. Without this use of synchronous services, our actions would be humongous and getting a handle on the flow of control by looking at a one page state model would be impossible. Pg 5, naming convention example. You say that 'In Service Ion Chamber' and 'Inser Vice Ionch Amber' are not the same. However, you say above that both are the same as InServiceIonChamber. So if you have an InServiceIonChamber, how do you tell which of the first two it is? Pg 6, 1st bullet in middle. A duration is interpreted to be in seconds?!?!? This is either an implementation-specific assumption for a particular case tool or it is seriously over-constraining the definition of a duration. Pg. 6, 3rd bullet in middle. At best you need more coercion rules for dates. At worst you are assuming a particular implementation of the Date data type. Given the notorious problems with dates, I think you would be better off leaving the string-to-date coercion for a transform. Pg 6,7 Data variables. There are a couple of reasons why programs written in Basic are notoriously difficult to maintain. One of them is this sort of on-the-fly typing. We have had several decades of programming experience to beat the lesson into us that Strong Typing is Good. Please don't regress to the Bad Old Days where the type of a variable depends on who did or did not write to it last. Pg 10, tuples. The example in the middle of the page for writing temperature and pressure to all caves will not always be correct. The output is in tuples but, as written, there is no guarantee that the input is. What I am getting at here is that there is an ambiguity in the notation. Given (xxx, yyy) where xxx and yyy happen to be sets, when are tuples assumed and when are they not assumed? (They can't always be assumed to be tuples because transforms may not care about the order of externally provided, independent data sets.) Pg 12, 2nd bullet. I thought it was considered Bad Form to have attributes with UNDEFINED values. Also, the last bullet contradicts this statement. Pg 12, 3rd bullet. I do not understand why it is illegal to initialize an attribute of type arbitrary in the create accessor. Also, how could the architecture provide an appropriate initialization when it may not know what it is? [The most common use of arbitrary types is to pass around data that the domain does not understand (i.e., in one bridge and out another).] Pg 13, example code for ADFD. It is not clear to me that the action code corresponds to the actual DFD. I think the problem is that the DFD is pre-OOA96 so that a transform is accessing a data store. Pg 15, illegal data flow to event generator. I do not understand why this is illegal. A Process is a Process is a Process; you can flow data to it or not but you shouldn't flow to some and not others. Pg 15, Delayed Events. Basically, I don't like these at all. This sort of thing is better done in a wormhole or with a timer. To me a delayed event is equivalent to saying one is going to model threads in the OOA. Also, in the 2nd paragraph you assume the time units to be seconds, which is an implementation issue. It is a particularly bad assumption because it is probably far too grainy for hardware initializations. Very minor nit: myDog | ... I assume myDog is always the receiver? Pg 17, upper middle. I assume "...R2 to the (one)..." should read "...R2 to a (one)..." Pg 17, middle. The examples keep referring to reading a value but they don't indicate where it is being read to. Pg 19, relationship specification. I assume that the only reason for including the relationship specification (as opposed to the relationship identifier) is to provide a tad more documentation of the justification of the link. Otherwise it seems to provide no additional information than Rn wouldn't. Pg 19, associative objects. How are multiple associative objects (obj--->>relation) identified? Pg 21, combining guards. What about OR? When you have alternative paths, different guards may be set in the different paths, but when they close together you need to see if either path set the guard. (Assume the guards are context dependent on the path, as far as naming convention is concerned.) Pg 21, blocks. What is the convention for nested blocks? How do you exit the outer block from within a nested block? I think I know the answer to these questions, but my point is that I won't know for sure until you clarify these issues in the document. Pg 22 bullets 1 & 2. These imply, as written, that if a test has only one guard, the test must always set it. Pg 22, bottom. I don't like the example, which seems to violate 3rd normal form. But this is the subject of another thread. -- H. S. Lahman There is nothing wrong with me that Teradyne/ATB could not be cured by a capful of Drano 321 Harrison Av. L51 Boston, MA 02118-2238 (Tel) (617)-422-3842 (Fax) (617)-422-3100 lahman@atb.teradyne.com Subject: (SMU) SMALL: arithmetic and other operators lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- On page 9 a number of operators are mentioned, but the arithmetic operators are limited to forming comparisons. I think this limitation is overly constraining and will lead to stilted action code. This constraint says I am going to have to make a bunch of Mickey Mouse transforms like add_two_integers to do anything useful. An arithmetic operator is simply a transform. It has a suite of inputs that it transforms into a suite of outputs. The comparison constraint vicariously limits to transform to having a single output (the value of the expression). The arithmetic operators should be regarded as built-in transforms where the translation rules will substitute the properly overloaded functionality depending upon the data types involved. I see no reason why (A.x, 5) | + > ~incremented_A_x should not be legal. Moreover, I would argue that the analyst should be able to supply other operators; to support them all one needs is a translation rule and an association with the relevant data types (already proposed). -- H. S. Lahman There is nothing wrong with me that Teradyne/ATB could not be cured by a capful of Drano 321 Harrison Av. L51 Boston, MA 02118-2238 (Tel) (617)-422-3842 (Fax) (617)-422-3100 lahman@atb.teradyne.com Subject: (SMU) SMALL: on navigating sets lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Pg 18 has the example Cave (all, Temperature > 21) -> [R1] Bench (one) .BenchUse I am ambivalent about this sort of construct. On the one hand, it is a nice, compact, set-based construct to do a complex action across multiple instances. Very elegant. OTOH, I would be tempted to break the thumbs of anyone who did this in a real model because it usually guarantees that the architect is going to have to do handstands to get this to run in any reasonable time. In the particular case of the example it probably would not be a big problem, regardless of the implementation, because you get to exit the Bench search with the first Bench entry found. However, as soon as the selection criteria for Bench changes slightly, this could be a major performance pig. The architect is going to have to introduce new data structures and I would not be surprised if the action winds up being hand written to be able to incorporate the search with the subsequent processing that actually uses the set elements extracted. Though the architect can Do the Right Thing by performance without any changes to the OOA, I still have three problems with this. The first is: why should the architect have to go to a lot of trouble to do so? The second is that when you are debugging hardware or somesuch in MSVC with a set of STDs in you lap, you want the code that you see in the debugger to look pretty much like the models in your lap. But if the architect has twisted it beyond recognition, you have a problem. Third, there is the risk that the architect may not preserve the functionality, data consistency, and referential integrity of the OOA during the complex transformations necessary to achieve reasonable performance. Having been down the path several times, I can assert that model elegance through the use of complex set manipulations is Not Good. My point here is closely related to my objections to the omission of depth-first iterations in another thread. However, this is a more general objection because it is also related to the pitfalls of collecting sets through "natural" relationship navigation. The bottom line is that when we do an OOA we always consider the performance implications and we formulate the OOA in a manner (added attributes, objects, and relationships in the IM, added states in the STD, etc.) to avoid set operations in the action language. This is a form of implementation dependence, but it is unavoidable given the performance problems with pure set operations and the desire to keep the translation simple and easily mappable to the OOA. -- H. S. Lahman There is nothing wrong with me that Teradyne/ATB could not be cured by a capful of Drano 321 Harrison Av. L51 Boston, MA 02118-2238 (Tel) (617)-422-3842 (Fax) (617)-422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) SMALL: on navigating sets "Ken Cook" writes to shlaer-mellor-users: -------------------------------------------------------------------- > From: lahman > Pg 18 has the example > > Cave (all, Temperature > 21) -> [R1] Bench (one) .BenchUse > > I would be tempted to break > the thumbs of anyone who did this in a real model because it usually > guarantees that the architect is going to have to do handstands to get > this to run in any reasonable time. > > Having been down the path several times, I can assert that model > elegance through the use of complex set manipulations is Not Good Your points are interesting to me because this is the kind of syntax we have been needing to give modelers access to the kinds of handstands our architecture is built to do :-). > > The bottom line is that when we do an OOA we always consider the > performance implications and we formulate the OOA in a manner (added > attributes, objects, and relationships in the IM, added states in the > STD, etc.) to avoid set operations in the action language. This is a > form of implementation dependence, but it is unavoidable given the > performance problems with pure set operations and the desire to keep the > translation simple and easily mappable to the OOA. > I sympathize with this. I think there will often be useages of OOA that modelers need to be encouraged to avoid to get the best performance out of a particular architecture. But I think it would be bad to restrict OOA for a particular type of architecture. Powerful set manipulation is can be explioted by some architectures. Subject: (SMU) Referential attributes and identifiers David Stone 5887 writes to shlaer-mellor-users: -------------------------------------------------------------------- I have a question about how referential attributes may correspond with the other object's identifying attributes. May two referential attributes in the formalizing object be associated with the same attribute of the identifier in the other object? In other words, is something like this permitted? +---------------+ +-------------------------------+ | A_OBJECT A | R1 | B_OBJECT B | | * a_id_attr |<---------->| * b_id_attr | | | C | ref_attr_1 (R1.A a_id_attr) | | | | ref_attr_2 (R1.A a_id_attr) | +---------------+ +-------------------------------+ The effect of this would be to force ref_attr_1 and ref_attr_2 to have the same value in any B_OBJECT instance which participated in the relationship. (This would not violate the rules of proper attribution because they could have different values in non-participating B_OBJECT instances.) The books (both Shlaer & Mellor's and Starr's) seem to be silent on the point, though they have no examples that I can find like the one above. Is this: - plain contrary to the method? - poor style, such that a CASE tool or architecture should ideally warn about this, but permit it? - acceptable and useful in some circumstances? Authoritative references would be most welcome. -- David Stone Sent by courtesy of, but not an official communication from: Simoco Europe, P.O.Box 24, St Andrews Rd, CAMBRIDGE, CB4 1DP, UK Subject: Re: (SMU) SMALL: Dataflows are Dataflows Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- Lahman wrote: > My interpretation of the intent is that a reference is simply > a local shorthand (abstraction) for referring to an instance > that was _previously_ found by conventional [...] If references were simply a shorthand notation, then they would be pretty harmless. Unfortunately, their influence has made a bit of a mess. There are two methods for getting data into a process: piping and direct reference. Normally, one is dataflow and the other is reference flow; but its not really consistant. Reference flow has no counterpart in DFDs. It seems messy and uneccessary. It is a result of trying to shoehorn too many new concepts into one place. Lets try and keep the OOA-of-DFD identical to the OOA-of-SMALL. And if you have to choose between fancy features and simplicity then aim to err on the side of simplicity. The purpose of a state action is to describe the implications of an object entering a state. It does not need to be a complete programming language. The method is data based. If I want fancy features then I'll use OMT or Booch. The addition of _localised_ references doesn't solve any implementation issues but it does increase the complexity of the language (and thus the parsers, data models, etc.). And when combined with Link/Unlink, the effects are multiplied ... (I won't repeat the effects here). There is no advantage in having references in addition to composed dataflows. > The main reason that I have come to Love the Link, though, is > that it repairs a serious problem: NOT PARTICIPATING. The use > of NOT PARTICIPATING is plain broken if one has multiple > conditional relationships that are constrained to have the same > identifier value. Stangely enough, this is the main reason why I dislike Link. It treats two relationships, that are constrained the the same referential attribute, as independent. If your IM is broken, then fix _it_, not the method. > Basically the argument is that link/unlink represents a higher > level of abstraction than attribute assignment. It allows the > process models to be independent of the choice of relational > attributes I think my concern here is that different levels of abstraction are being mixed within one model (I use the word "different" - I am not sure that either abstraction is "higher" than the other). If you want to use link/unlink (and therefore references) then fine, but you need to eliminate referential attributes from the IM. Otherwise you get inconsistancies. > It allows the process models to be independent of the choice > of relational attributes (compound, unique, etc.) and their > placement (e.g., in which object they go on a 1:1 in the IM But which process models are effected? Transforms and Tests aren't because they don't access the IM. The only processes effected are accessors - and they are context-free. If you use a different referential attribute then you use a different process. It might be reusable. Reuse of accessor processes isn't my primary concern when building state models. Now, if you had suggested that DFDs reflect the choice of referential attributes then I would agree; but I would point out that SM is a sequential process - IM before state models. Dave. Not speaking for GPS. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com Subject: (SMU) SMALL: more detail please, especially for architects! David Stone 5887 writes to shlaer-mellor-users: -------------------------------------------------------------------- I think the idea of a non-procedural - dataflow - language as an action language is very interesting, though I have no experience of such languages either in using them or in translating them. Therefore I shall not make detailed comments on SMALL as a dataflow language. Nevertheless, I should still like to make some general points. - It is very important to a have a full and precise definition of the language. Analysts need to know exactly what they may write and what effect it will have: architects need to be able to translate it. The paper recently published is a sketch of a proposal, or a introductory tutorial. I hope that the final book will have a substantial appendix giving a definition of the language at least as good as, say, the C Reference Manual at the back of K&R. - Since dataflow languages are somewhat unusual, and the book is after all to be about Recursive Design, it would be very helpful if it could include references to books or papers on translation techniques for such languages. The standard reference on compilers (the Dragon Book) scarcely considers non-procedural languages; I have seen one book which mentions functional languages, but none on dataflow languages. -- David Stone Sent by courtesy of, but not an official communication from: Simoco Europe, P.O.Box 24, St Andrews Rd, CAMBRIDGE, CB4 1DP, UK Subject: Re: (SMU) Referential attributes and identifiers Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- David Stone 5887 wrote: > May two referential attributes in the formalizing object be associated > with the same attribute of the identifier in the other object? > > In other words, is something like this permitted? > > +---------------+ +-------------------------------+ > | A_OBJECT A | R1 | B_OBJECT B | > | * a_id_attr |<---------->| * b_id_attr | > | | C | ref_attr_1 (R1.A a_id_attr) | > | | | ref_attr_2 (R1.A a_id_attr) | > +---------------+ +-------------------------------+ > > The effect of this would be to force ref_attr_1 and ref_attr_2 to have > the same value in any B_OBJECT instance which participated in the > relationship. (This would not violate the rules of proper attribution > because they could have different values in non-participating B_OBJECT > instances.) For your point to be valid, you would have to have the (c) at the other end of the relationship (In your model, B cannot be non-participating). If you move the (c) then the formalisation would be at the wrong end. So I'll make the assumption that you intended a 1c:1c relationship. Now you have the scenario where there is a B with no A. So the value of both attributes should be "not participating". So we are left with the scenario that you use a different "not participating" value for each attribute. This was discussed a few moths ago. The conclusion was that "not participating" is an architectural value and that there is only one such value (I tend to disagree with this - but I'll accept it). If you accept SMALL then referential attributes have no meaningful value; so there could be no justification for your construct. Personally, I'd say that if you want to use that construct then you want to think deeply to justify it. Perhaps you have an example where it would be useful? My gut reaction is that its wrong; I'm not sure that I accept your argument about the rules of attribution. It would break my OOA-of-OOA because I have an object with identifier equivalent to: (relationship_id, attribute_id). When PT publish an offical OOA-of-OOA then we'll have a definitive answer. Dave. Not speaking for GPS. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com Subject: Re: (SMU) Referential attributes and identifiers Carolyn Duby writes to shlaer-mellor-users: -------------------------------------------------------------------- David Stone 5887 wrote: > > David Stone 5887 writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > <> > In other words, is something like this permitted? > > +---------------+ +-------------------------------+ > | A_OBJECT A | R1 | B_OBJECT B | > | * a_id_attr |<---------->| * b_id_attr | > | | C | ref_attr_1 (R1.A a_id_attr) | > | | | ref_attr_2 (R1.A a_id_attr) | > +---------------+ +-------------------------------+ > > The effect of this would be to force ref_attr_1 and ref_attr_2 to have > the same value in any B_OBJECT instance which participated in the > relationship. (This would not violate the rules of proper attribution > because they could have different values in non-participating B_OBJECT > instances.) > > < > > Is this: > > - plain contrary to the method? The intention of formalization is that a relationship is formalized once. For example "Object Lifecycles" states on page 25 "To formalize a one-to-one relationship, referential attributes may be added to either object (but not both)." I think it would be fair to extend this to duplicate formalizations in the same object. > > - poor style, such that a CASE tool or architecture should ideally > warn about this, but permit it? This type of formalization on an IM raises a red flag to me. The architecture will need special extensions to any supported relationship optimizations to handle this case. I think there is a clearer way to model the relationships. Are there two separate relationships between the two objects and at some period of time the two relationships point to the same instance and at other times they don't? Carolyn -- ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Carolyn Duby voice: +01 508-384-1392| carolynd@pathfindersol.com fax: +01 508-384-7906| ____________________________________________________| Subject: Re: (SMU) Referential attributes and identifiers Neil Lang writes to shlaer-mellor-users: -------------------------------------------------------------------- At 10:02 AM 12/15/97 GMT, >David Stone 5887 writes to shlaer-mellor-users: >-------------------------------------------------------------------- > > >I have a question about how referential attributes may correspond with >the other object's identifying attributes. > >May two referential attributes in the formalizing object be associated >with the same attribute of the identifier in the other object? Only if you have 2 separate and independent relationships between the two objects. The OOA formalism requires that each relationship be formalized with a copy of an identifier of the other object. Just as you wouldn't abstract two attributes that represent the same real-world characteristic, you don't duplicate a referential attribute. > >In other words, is something like this permitted? > > +---------------+ +-------------------------------+ > | A_OBJECT A | R1 | B_OBJECT B | > | * a_id_attr |<---------->| * b_id_attr | > | | C | ref_attr_1 (R1.A a_id_attr) | > | | | ref_attr_2 (R1.A a_id_attr) | > +---------------+ +-------------------------------+ > >The effect of this would be to force ref_attr_1 and ref_attr_2 to have >the same value in any B_OBJECT instance which participated in the >relationship. (This would not violate the rules of proper attribution >because they could have different values in non-participating B_OBJECT >instances.) I don't follow your logic here. In the OOA modeling world the value of a referential attribute when there happens to be no related instance is always "NOT PARTICIPATING". So ref_attr_1 and ref_attr_2 have the same value at all points in B's lifecycle. > >The books (both Shlaer & Mellor's and Starr's) seem to be silent on >the point, though they have no examples that I can find like the one >above. > >Is this: > >- plain contrary to the method? Yes it is. I am intrigued by your desire to use the above construct. Perhaps you might explain what you were trying to accomplish with the proposed construct? > >- poor style, such that a CASE tool or architecture should ideally >warn about this, but permit it? > >- acceptable and useful in some circumstances? > >Authoritative references would be most welcome. > >-- >David Stone >Sent by courtesy of, but not an official communication from: >Simoco Europe, P.O.Box 24, St Andrews Rd, CAMBRIDGE, CB4 1DP, UK > > ---------------------------------------------------------------------- Neil Lang nlang@projtech.com Project Technology, Inc. 510-567-0255 x623 10940 Bigge Street San Leandro, CA 94577 http://www.projtech.com ---------------------------------------------------------------------- Subject: Re: (SMU) SMALL: nits David Yoakley writes to shlaer-mellor-users: -------------------------------------------------------------------- Lahman wrote: >Pg 6, 1st bullet in middle. A duration is interpreted to be in >seconds?!?!? This is either an implementation-specific assumption >for a particular case tool or it is seriously over-constraining >definition of a duration. I hope you are miss-interpreting this. When I read it, I just assumed that fractions of a second would be perfectly legal. dy Subject: Re: (SMU) SMALL: Dataflows are Dataflows lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Whipp... I think that where we differ is in the view of the relationship between the IM and the ADFDs. I regard the IM as the place where referential integrity is defined. In the IM I am very interested in such things as verifying that I get to the same instances in either direction around relational loops. The IM is the place where one deals with the details of the relational model. I also regard the relationships as implicitly representing the specific relational identifiers. In the IM I am very much concerned with these issues but I do not even think about things like functionality and flow of control. In contrast, in the ADFD I am primarily concerned with functionality and flow of control rather than the relational model. To focus on these issues I want to minimize the intrusion of the referential integrity issues from the relational model. Therefore I would prefer a notation in the ADFD that abstracts the details (specific referential identifiers) so that they do not obscure the my real area of interest in the action. Therefore I am very happy to use a compact relationship notation, [here -> R1 -> there], rather than dealing with extracting and manipulating the specific identifiers relevant to that relationship. The IM has already packaged the relational identifiers with the relationship definition so that the translator knows what I am doing and referential integrity of the data model is preserved. I see no substantive difference between extracting identifiers followed by a set Find operation and traversing a relationship defined in the IM; both get me an instance and both preserve referential integrity through the relational model -- the navigation just does it indirectly. I am also very happy to use a set filter to extract a set of instances in the ADFD, but I don't really care much how they are identified. Again, I am quite happy to use an abstraction for the bundle of identifiers that may be associated with each instance. When that filter returns an instance to me I can, if I choose, extract its identifiers and use them in subsequent operations. Or I can say X represents those identifiers and wherever I use X the translator should think of the packet of identifiers. When I am writing an action, going the X route seems to me to be a much less intrusive way of dealing with boilerplate that really has little to do with my primary concerns when writing an action. Again, referential integrity based upon a relational model is still preserved because X is simply a symbol for those identifiers. Thus I see these approaches as equivalent and based upon the relational model. The difference is that the notation for actions has been abstracted so that I do not have to view referential integrity at the same level of detail that I would in the IM. I see this as simply leveraging all the work I went to in the IM to define relationships. > If references were simply a shorthand notation, then they > would be pretty harmless. Unfortunately, their influence has > made a bit of a mess. There are two methods for getting data > into a process: piping and direct reference. Normally, one is > dataflow and the other is reference flow; but its not really > consistant. Reference flow has no counterpart in DFDs. I don't see it as a reference flow. The reference is just a surrogate for the identifiers that would be on an ADFD flow to do that same thing. What is being abstracted is the work needed to extract the identifiers so that they may be placed on the flows > It seems messy and uneccessary. It is a result of trying to > shoehorn too many new concepts into one place. Lets try and > keep the OOA-of-DFD identical to the OOA-of-SMALL. And if you > have to choose between fancy features and simplicity then aim > to err on the side of simplicity. Actually, I see the action language as much cleaner than the ADFD. (In fact, that is one thing I have against it -- it is so elegant and compact that I worry about it being difficult to maintain.) I have always felt that ADFDs were messy precisely because of all those processes that did nothing but extract identifiers of instances that I already had in my hand. This is especially true when one uses compound identifiers routinely as we do -- at least 20% of the bubbles in our ADFDs were devoted to this. > Stangely enough, this is the main reason why I dislike Link. > It treats two relationships, that are constrained the the same > referential attribute, as independent. If your IM is broken, > then fix _it_, not the method. But the IM is _not_ broken! You want to capture the fact that the identifiers must have the same value because this is crucial to referential integrity. But as soon as you do capture this important fact in the IM you can no longer write NOT PARTICIPATING to the attribute when one of two conditional relationships that share that identifier is terminated. OTOH, if you use link that mechanism can deal with the problem properly (e.g., ensure that the identifiers values are the same) in the architecture because it knows about the constraint from the IM. The link allows all the complications to be handled in the translation, which is exactly as it should be. > I think my concern here is that different levels of abstraction > are being mixed within one model (I use the word "different" - > I am not sure that either abstraction is "higher" than the > other). If you want to use link/unlink (and therefore references) > then fine, but you need to eliminate referential attributes from > the IM. Otherwise you get inconsistancies. Exactly my point in the preamble: different levels of abstraction (or interests, if you will). However, I don't think using link obsoletes referential identifiers. Those identifiers define the characteristics of the relationship and the rules that it must follow. Whatever the link or unlink does in the architecture, it must still obey those rules. Moreover, it must also enforce those rules. So when you try to link a second 1:1, the simulator has to squawk when the second link is invoked. Put another way, the link cannot instantiate a relationship in a manner that would allow it to be navigated to reach a data store that was inconsistent with the IM's relational data model. > > It allows the process models to be independent of the choice > > of relational attributes (compound, unique, etc.) and their > > placement (e.g., in which object they go on a 1:1 in the IM > > But which process models are effected? Transforms and Tests aren't > because they don't access the IM. The only processes effected are > accessors - and they are context-free. If you use a different > referential attribute then you use a different process. It might > be reusable. Reuse of accessor processes isn't my primary > concern when building state models. I can't argue with this, but I think the issue is whether the details of extracting the identifiers via attributes is important to the action. I argue that if one has already resolved the referential integrity issues using referential identifiers in the IM when defining relationships, then in the action need not be concerned with this level of detail. > Now, if you had suggested that DFDs reflect the choice of > referential attributes then I would agree; but I would point > out that SM is a sequential process - IM before state models. I thought that _was_ what I was suggesting. And I would counter that one has different concerns at each level of that progression. By the time I get to state actions, all I care about is that I get to the right data stores; I rarely care about the details of how I get to them. So I take it as an Act Of Faith that the IM has resolved the details and I want an unobtrusive abstraction for them, which references or relationship navigation provide. -- H. S. Lahman There is nothing wrong with me that Teradyne/ATB could not be cured by a capful of Drano 321 Harrison Av. L51 Boston, MA 02118-2238 (Tel) (617)-422-3842 (Fax) (617)-422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) SMALL: nits Steve Mellor writes to shlaer-mellor-users: -------------------------------------------------------------------- At 03:32 PM 12/15/97 -0500, you wrote: >David Yoakley writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >Lahman wrote: > >>Pg 6, 1st bullet in middle. A duration is interpreted to be in >>seconds?!?!? This is either an implementation-specific assumption >>for a particular case tool or it is seriously over-constraining >>definition of a duration. > >I hope you are miss-interpreting this. When I read it, I just >assumed that fractions of a second would be perfectly legal. Yes: 3.5 is perfectly fine. The way I read HS's comment, it had to do with how to interpret 3. If the analyst simply says 3, then that is intrepreted as 3 seconds, not 3 years, or 3 microseconds. Frankly, it makes little difference to me--all that's important is that it's unambiguous (there _is_ a definition), and it's convenient for as many people as possible. -- steve Subject: Re: (SMU) SMALL: on navigating sets lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Cook... > But I think it would be bad to restrict OOA for a particular type of > architecture. > Powerful set manipulation is can be explioted by some architectures. I think the problem is more fundamental. If you are going to do a pure, general purpose set implementation you are going to spend a lot of time executing Find. You are also left with the problem of breadth-first iterations that require the overhead of multiple loops; today's stack-based hardware is built for depth-first and that is what the languages provide. No matter what you do to streamline it, it will still be a pig. [The LISP people even tried to build special hardware in addition to compilation, but the overhead of linked lists still left it way back in the pack.] In the end I think you wind up translating the set-based paradigm into conventional data structures and techniques that match the hardware. This isn't all that tough since the modern languages and compilers pay a lot of homage to set theory; they just use the set theory to develop more specialized set structures like arrays that are better suited to the hardware. The trick is to maintain the correctness through the translation. I am a bit leery of the phrase "powerful set manipulation". When they use it people usually really mean the powerful means of expression -- in the same sense that LISP is a powerful language because it is very friendly to application development. But us cycle counters are still using BLISS or C. -- H. S. Lahman There is nothing wrong with me that Teradyne/ATB could not be cured by a capful of Drano 321 Harrison Av. L51 Boston, MA 02118-2238 (Tel) (617)-422-3842 (Fax) (617)-422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Referential attributes and identifiers lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Stone ... > I have a question about how referential attributes may correspond with > > the other object's identifying attributes. > > May two referential attributes in the formalizing object be associated > > with the same attribute of the identifier in the other object? As you drew the diagram, there should only be one referential attribute because there is only one relationship with one identifier in the related object. The issue would arise if you had two relationships to the same object (A) or you were using compound identifiers and had two relationships from B that were part of a relational loop in the IM. In the latter case at least one component attribute of the identifier would likely be common to both relationships. In either case I believe you would need a single identifier that formalized both relationships because the constraint that the referential identifiers have the same value is crucial to maintaining referential integrity. The only way to express this explicitly in the models is through sharing the referential attribute in the IM. Alas, there is a problem. If one of relationships is conditional, then one cannot simply place NOT PARTICIPATING in the referential attribute when that relationship is not active. In my view this is a bug in the methodology. This problem is solved using the proposed action language because the link/unlink can solve the problem in a variety of ways in the architecture while still enforcing the IM requirement that if both relationships are active they must have the same value for the referential attribute. -- H. S. Lahman There is nothing wrong with me that Teradyne/ATB could not be cured by a capful of Drano 321 Harrison Av. L51 Boston, MA 02118-2238 (Tel) (617)-422-3842 (Fax) (617)-422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Mathematical Dependence lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Munday... > I may not be fully understanding this thread of discussion, but since > it's been going on for so long, I've decided to add my piece of > confusion. > > Comment on the above paragraph: > > a = b * c ; also a = sigma(1..b) of c ; also a = sigma(1..c) of b ; > also > a = sqrt( a*b*a*b) ; also a = d + (a * b) - d, etc, etc,... > > Does this make sense in the context of this thread? I am surprised no one else responded to this. I figured I would let someone else deal with it who has taken math courses since the time Alchemy was a major. The quick answer is: yes. The issues represented in the first line are typical mathematical dependencies. When asked for the dependent value, that value read must be equal to the value of the expression. So far, so good. At the algebraic level the computation is completely deterministic; it is stated, therefore it is. The difficulty is that the problem space tends not to be so simplistic. In particular, the state of the system varies over time and there may be some notion of consistency among the independent variables that must be satisfied for the calculation to be meaningful in the problem space. The trick lies in evaluating the expression and making sure that the values used in the expression are consistent with the calculation's intent within the context of the problem space timeframe. That is, one does not want the Weight sampled at one time and the Volume sampled at another time when computing Density if Weight and Volume are supposed to be updated together as tuples. Thus the timing of the calculation may become an issue in the problem space because of the way that the independent variables are modified. This timing issue has nothing to do with the pure mathematical validity of the calculation -- it is related to supplementary problem space issues like whether the result would be meaningful at a particular moment in the life of the processing. In this thread we have been lumping all these supplementary issues into the general idea of consistency of the independent variables. Now the second line of examples opens up a different can of worms. Whipp would argue that these are not valid mathematical dependencies because the dependent variable cannot depend upon itself. In the purely algebraic sense this is quite true. I submit that in an OOA this is not always so clear though because we are dealing with abstractions and time. Thus if the attribute represents the current element of a time series, let's say, one could argue that the last value of the attribute represents a completely different critter because This is Now and That was Then. Thus I argue that in some cases of discrete sampling it would be fair for the formula of the dependence to require use the current value of a dependent attribute in the calculation. However, I am not pushing very hard on this because the ice is quite thin. -- H. S. Lahman There is nothing wrong with me that Teradyne/ATB could not be cured by a capful of Drano 321 Harrison Av. L51 Boston, MA 02118-2238 (Tel) (617)-422-3842 (Fax) (617)-422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) SMALL: on navigating sets Kenneth Cook writes to shlaer-mellor-users: -------------------------------------------------------------------- At 06:02 PM 12/15/97 -0500, lahman wrote: >lahman writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >Responding to Cook... > >> But I think it would be bad to restrict OOA for a particular type of >> architecture. >> Powerful set manipulation is can be explioted by some architectures. > >I think the problem is more fundamental. If you are going to do a pure, >general purpose set implementation you are going to spend a lot of time >executing Find. Our Finds are implemented by back-end stores (databases). So while I'm concerned with performance, in the end it is the database vendors problem, but for them that is not new. Even so, in our architecture, sets are first class objects. Sets are used to hold in-memory cache of retrieved data, as well as relationships. Our clients are finding our good performance a real asset. So it can be done. Darwinian architecture: the data is out there, waiting to be read by the strong. Do you really advocate eliminating the set syntax from the language? -Ken Subject: Re: (SMU) SMALL: nits David Yoakley writes to shlaer-mellor-users: -------------------------------------------------------------------- Steve Mellor wrote: > > Steve Mellor writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > At 03:32 PM 12/15/97 -0500, you wrote: > >David Yoakley writes to shlaer-mellor-users: > >-------------------------------------------------------------------- > > > >Lahman wrote: > > > >>Pg 6, 1st bullet in middle. A duration is interpreted to be in > >>seconds?!?!? This is either an implementation-specific assumption > >>for a particular case tool or it is seriously over-constraining > >>definition of a duration. > > > >I hope you are miss-interpreting this. When I read it, I just > >assumed that fractions of a second would be perfectly legal. > > Yes: 3.5 is perfectly fine. > > The way I read HS's comment, it had to do with how to interpret 3. > > If the analyst simply says 3, then that is intrepreted as 3 seconds, > not 3 years, or 3 microseconds. Frankly, it makes little difference > to me--all that's important is that it's unambiguous (there _is_ a > definition), and it's convenient for as many people as possible. > > -- steve I agree. I was expressing my support of the idea and at the same time countering what I may have wrongly assumed to be lahman's argument for a project by project definition of time. I see only benefits in adopting a standard. On the projects that I have been on in fact we have always adopted seconds even when most of the timed intervals were centiseconds and milliseconds. Of course since there was no OOA standard we "standardized" time by requiring analysts to factor time by a constant (TICKS_PER_SECOND). The standard definition fixes the root problem. Kudos to PT. dy ________________________________________________________________________ David Yoakley Objective Innovations Inc. Phone: 512.288.5954 14606 Friendswood Lane Fax: 512.288.6381 Austin, TX 78737 Replies: yoakley@oiinc.com ________________________________________________________________________ Did you ever notice when you blow in a dog's face he gets mad at you? But when you take him in a car he sticks his head out the window! Steve Bluestone Subject: Re: (SMU) Referential attributes and identifiers David Stone 5887 writes to shlaer-mellor-users: -------------------------------------------------------------------- My thanks to all those who have responded to my posting on this. There seems to be no doubt but that it should be invalid. Perhaps I should have explained that this question arose during testing of the static analysis done by our architecture: we didn't know what severity of diagnostic message was required, if any. Moreover, and more importantly, if we were to have supported it, all sorts of complex and interesting issues arise, which we now know we can forget about. The most authoritative reference that anybody pointed out is that on p18 of "Modeling the World in States": "If the value of a referential attribute changes, it means that different instances are now being associated." I had missed this, and formerly thought that only the converse was true. This sentence implies that referential attributes can only be set when linking instances, and also seems to me the authoritative justification for an implicit "not participating" value. Combined with the rules for proper attribution, this means that the referential attributes as I sketched them were invalid, since they would always have the same value. (Incidentally, although "not participating" seems to have been generally accepted in this mailing list before I started reading it, I cannot find any explicit reference to this value in the books.) -- David Stone Sent by courtesy of, but not an official communication from: Simoco Europe, P.O.Box 24, St Andrews Rd, CAMBRIDGE, CB4 1DP, UK Subject: Re: (SMU) SMALL: Dataflows are Dataflows Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- Lahman wrote: > Responding to Whipp... > > I think that where we differ is in the view of the relationship > between the IM and the ADFDs. I regard the IM as the place where > referential integrity is defined. [...] Agreed. > In contrast, in the ADFD I am primarily concerned with > functionality and flow of control rather than the relational > model. Agreed. But I don't want to re-do the IM because the notation of the process models forces me to. (I will change it if I find a mistake) Let me state, as clearly as I can, the chain of reasoning that causes my objection. Note that I have no objection to shortcut navigaction, etc. It is the construction of the relationships that causes the problems. Using link/unlink causes problems with referential attributes which formalise two relationships. This is recognised; and the PT solution is to say that the value of referential attributes is meaningless (I can't think of any other solutions). This is a statement about the information, not the processing. What is being said is that the attribute domain (type) of referential attributes is arbitary. If you attempt to isolate the effect in the process models then you are saying that you have two different information models. I would like just one model. If the attribute domain of a referential attribute is arbitary then the thing to which it refers must also be arbitary. This inevitably means that all objects must have an arbitary identifier. This severily weakens the information model. (objects can still have other, non-arbitary, identifiers). > Actually, I see the action language as much cleaner than the > ADFD. (In fact, that is one thing I have against it -- it is > so elegant and compact that I worry about it being difficult > to maintain.) This is a matter of syntax, not semantics. I tend to agree that SMALL could be improved with a more verbose syntax. The need for the verbose form was recognised (page 4). > I have always felt that ADFDs were messy precisely because of > all those processes that did nothing but extract identifiers of > instances that I already had in my hand. This is especially true > when one uses compound identifiers routinely as we do -- at least > 20% of the bubbles in our ADFDs were devoted to this. Yes, compound navigation reduces the clutter. But, provided you use compound dataflows, you should never have to read any object-instance more than once (per guard) > > Stangely enough, this is the main reason why I dislike Link. > > It treats two relationships, that are constrained the the same > > referential attribute, as independent. If your IM is broken, > > then fix _it_, not the method. > > But the IM is _not_ broken! You want to capture the fact that > the identifiers must have the same value because this is crucial > to referential integrity. But as soon as you do capture this > important fact in the IM you can no longer write NOT PARTICIPATING > to the attribute when one of two conditional relationships that > share that identifier is terminated. I disagree. The IM _is_ broken because the referential attributes don't reflect (define) the relationships. Perhaps we can get in to an "is" ... "isn't" debate. I agree that NOT PARTICIPATING can also cause a problem, but that is because it, too, is a wart. I know I lost the argument some time back about NOT PARTICIPATING, but I do still feel the (c) should mean that referential integrety is optional; not that an extra value is introduced. If two relationships cannot be correctly formalisd in one attribute, then perhaps two attributes are needed It isn't too suprising that each deviation from a pure relational data model causes a ripple of problems. It is unfortunate that the method attempts to work round problems by adding more hacks; and then adding more hacks to solve the problems that these hack create. > [process models dependent on choice of referential attributes] > I thought that _was_ what I was suggesting. Yes, you were. Processing in eyes-brain-fingers got garbled somewhere. > And I would counter that one has different concerns at each level > of that progression. By the time I get to state actions, all I > care about is that I get to the right data stores; I rarely care > about the details of how I get to them. Although SM is a sequential process, I see its aim as producing a single consistant model (at a consistant level of abstraction). Our different perspectives may be due to the complexity of your process models. You talk in terms of 30-50 processes in a DFD; I normally have less than 10 (often only one or two). Most big state actions have many flaws; generally a result of domain pollution or over-specification. Occasionally a big state action is needed, but its rare. Dave. Not speaking for GPS. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com Subject: Re: (SMU) SMALL: Time Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- David Yoakley wrote: > [Steve Mellor wote:] > > If the analyst simply says 3, then that is intrepreted as 3 seconds, > > not 3 years, or 3 microseconds. Frankly, it makes little difference > > to me--all that's important is that it's unambiguous (there _is_ a > > definition), and it's convenient for as many people as possible. > > > I agree. I was expressing my support of the idea and at the same > time countering what I may have wrongly assumed to be lahman's > argument for a project by project definition of time. I see only > benefits in adopting a standard. I do have one slight quibble with this. When modelling hardware, I often have no concept of time (it must be all those late nights ). Time is resolved in software. I only know about clock cycles (Low levels of abstraction introduce time in terms of gate & track delays, but I'm not worried about that here). If I am modelling a UART then I don't know that its running at 9600 baud. I just know that I have a division select and a baud rate register. These are given values by someone who knows what the clock rate is. When I want to use time I might say: "send me an event in 5 clock cycles". I would like to treat this as a duration (time) but it appears that I cannot. Currently, I use wormholes; not timers nor delayed events. If anyone wants to argue domain pollution (implementation) here, then I'm willing to defend. In reality, all the duration values are stored in attributes and are never interpretted by the domain. Dave. Not speaking ofr GPS. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com Subject: Re: (SMU) Mathematical Dependence Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- lahman wrote: > Now the second line of examples opens up a different can of worms. > Whipp would argue that these are not valid because the dependent > variable cannot depend upon itself. In the purely algebraic sense > this is quite true. I submit that in an OOA this is not always so > clear though because we are dealing with abstractions and time. > Thus if the attribute represents the current element of a time > series, let's say, one could argue that the last value of the > attribute represents a completely different critter because This > is Now and That was Then. If we have agreed that there are at least for possible time rules for dependent attributes (early, late, peridoc, continuus) then the concept of a time series becomes somewhat nebulus. If you have a converging series then you may be alright; but a diverging series could overflow before its ever read! and a fractal series would be a random number generator. Dave. Not speaking for GPS. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com Subject: Re: (SMU) Referential attributes and identifiers lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Stone... > (Incidentally, although "not > participating" seems to have been generally accepted in this mailing > list before I started reading it, I cannot find any explicit reference > > to this value in the books.) It was news to me as well when it came out on a thread about a year ago. I believe it is referenced in PT's course materials. As you may have gathered, I tend to go mildly apoplectic whenever it is mentioned. -- H. S. Lahman There is nothing wrong with me that Teradyne/ATB could not be cured by a capful of Drano 321 Harrison Av. L51 Boston, MA 02118-2238 (Tel) (617)-422-3842 (Fax) (617)-422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) SMALL: nits lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Mellor... Regarding storing seconds: > Yes: 3.5 is perfectly fine. > > The way I read HS's comment, it had to do with how to interpret 3. For a decade I programmed in BLISS, whose _only_ data type is Integer. [BLISS blows the socks off C for low level system programming, but it's not useful for much else.] It would be impossible to store the value unless it were scaled to milliseconds or some such. However, this is only part of the problem. > If the analyst simply says 3, then that is intrepreted as 3 seconds, > not 3 years, or 3 microseconds. Frankly, it makes little difference > to me--all that's important is that it's unambiguous (there _is_ a > definition), and it's convenient for as many people as possible. How the data is stored can make a very large difference in performance. Even the RISC machines don't do floating point calculations in a single clock cycle. But the important issue is that the this is not an isolated data element. It may be routinely used in calculations with other values. The problem space may all require different units on input and output. If values have to be converted every time they are accessed you can have serious performance problems. (I once got an order of magnitude throughput improvement in a PL/I program by simply eliminating the conversions between different numeric data types, so this is not a minor issue.) Therefore any such "standard" cannot be interpreted as a requirement for the data store. However, my real issue is much more general because one could let the architecture store the value with different scaling than that data domain specification (so long as it also maintained consistency in the calculations). A value should be interpreted according to its data domain definition. I believe the units for any any numeric value are an intrinsic part of the data domain definition so they should be described with the attribute. This allows the architecture to do whatever it needs to do to store the data properly. This is also why we introduce user-defined types so that 3.5 means different things if it is a Voltage type or a Current type. It seems to me that the point of describing a data domain is to describe the semantics of the attribute and you can't separate the units from that semantic. More importantly, the units of the data is a problem space issue. If every domain expert thinks of duration in microseconds, what right has the action language specification to vicariously override this and reinterpret the problem space conventions? -- H. S. Lahman There is nothing wrong with me that Teradyne/ATB could not be cured by a capful of Drano 321 Harrison Av. L51 Boston, MA 02118-2238 (Tel) (617)-422-3842 (Fax) (617)-422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) SMALL: nits Dana Simonson writes to shlaer-mellor-users: -------------------------------------------------------------------- Reply to Lahman > More importantly, the units of the data is > a problem space issue. If every domain > expert thinks of duration in microseconds, > what right has the action language > specification to vicariously override this > and reinterpret the problem space > conventions? I agree. If my analysis has a duration such as length of Jurassic period I would much prefer units of millions of years to using seconds. Subject: Re: (SMU) SMALL: on navigating sets lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Cook... > Our Finds are implemented by back-end stores (databases). So while > I'm > concerned with performance, in the end it is the database vendors > problem, > but for them that is not new. > Even so, in our architecture, sets are first class > objects. Sets are used to hold in-memory cache of retrieved data, as > well > as relationships. Our clients are finding our good performance a real > > asset. So it can be done. But imagine how good the performance could be if you used arrays? Seriously, I do not see how you can have reasonable performance if you use pure sets for things like relationships. The searches to find a particular instance are prohibitive unless you use a specialized data structure for the set. > Do you really advocate eliminating the set syntax from the language? No. I just don't like it being the _only_ means of expression. My feeling is that set theory is too abstract to be used directly in the OOA. We need a suite of more specialized abstractions that are more consistent with the way real problems are solved in a software environment. If I were designing a new computer source language, I would have to brush up on my set and graph theory because they are necessary to ensuring consistency in whatever constructs my language would support. Set theory provides very basic rules for the behavior of things like arrays and linked lists. However, to be useful my language would have to lead naturally to efficient run-time machine code on real machines. Since real computers are designed around much narrower paradigms, my language would have to provide something in between that satisfied the set theory rules but used structures and processes that were aligned with the computer paradigms (stacks, procedures, etc.). I think that would be a tough thing to do, mainly because a lot of smart people have tried and we still have no good general purpose computer language. The problem is that every language designer has to solve the same translation of basic theoretical paradigms into a practical engineering solution for a real environment. Ensuring that all those simple but rigorous rules are still correctly served in all cases is a daunting task. By restricting the OOA to pure set representations this daunting task of translating paradigms has to be done in the RD for *every application*. It is as if one has to design a computer language for every application. The reusable portions of a particular architecture mitigate the task a great deal, but it is still a risky proposition. The translation rules still have to be defined in a manner that satisfies the set theory rules even though the end result will look very, very different than the OOA. Someone also has to make sure that all those selected architectural mechanisms play together correctly. This task would be a lot easier if the OOA looked a lot more like the final implementation (i.e., there existed a simplistic mapping from OOA constructs to specific choices of implementation mechanisms, such as object => C++ class or object => COBOL record). Now much of the risk is moved to mapping the underlying set theory to these OOA abstractions and this only needs to be done once. When I use a computer language with aliasing, I have a high degree of confidence it will Just Work because the language designer put a lot of time and effort into making the language constructs consistent with the underlying theory through things like scoping rules. I would like the methodology to devote the same energy to providing a suite of OOA abstractions (and rules for applying them) that would preserve the theoretical constraints while providing a more useful mapping to the mechanisms of real implementations. That's all I ask. Really. -- H. S. Lahman There is nothing wrong with me that Teradyne/ATB could not be cured by a capful of Drano 321 Harrison Av. L51 Boston, MA 02118-2238 (Tel) (617)-422-3842 (Fax) (617)-422-3100 lahman@atb.teradyne.com Subject: (SMU) SMALL: Time Jon Monroe writes to shlaer-mellor-users: -------------------------------------------------------------------- > Dana Simonson writes > Reply to Lahman >> More importantly, the units of the data is >> a problem space issue. If every domain >> expert thinks of duration in microseconds, >> what right has the action language >> specification to vicariously override this >> and reinterpret the problem space >> conventions? > I agree. If my analysis has a duration such > as length of Jurassic period I would much > prefer units of millions of years to using > seconds. I also agree. We have several domains on our project where the natural unit of time is "minutes", and other domains where it is "microseconds". The architecture standardized on microseconds, but dealing with time is always a little awkward in the "minutes" based domains. I have always wished that we could color the domain with the units, and let the architecture handle conversion whenever time data is passed between domains. Jonathan Monroe Abbott Laboratories - Diagnostics Division North Chicago, IL monroej@ema.abbott.com Subject: Re: (SMU) SMALL: nits David Yoakley writes to shlaer-mellor-users: -------------------------------------------------------------------- lahman wrote: > lahman writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Responding to Mellor... > > Regarding storing seconds: > > > Yes: 3.5 is perfectly fine. > > > > The way I read HS's comment, it had to do with how to interpret 3. > > For a decade I programmed in BLISS, whose _only_ data type is Integer. > [BLISS blows the socks off C for low level system programming, but it's > not useful for much else.] It would be impossible to store the value > unless it were scaled to milliseconds or some such. However, this is > only part of the problem. You acknowledge that scaling (the architecture) could solve this problemand certainly it should *if* performance of timed events is a concern. Nothing new here, just more work for the good old software architecture. > > If the analyst simply says 3, then that is intrepreted as 3 seconds, > > not 3 years, or 3 microseconds. Frankly, it makes little difference > > to me--all that's important is that it's unambiguous (there _is_ a > > definition), and it's convenient for as many people as possible. > > Therefore any such "standard" cannot be > interpreted as a requirement for the data store. > No doubt. > > > More importantly, the units of the data is a problem space issue. If > every domain expert thinks of duration in microseconds, what right has > the action language specification to vicariously override this and > reinterpret the problem space conventions? In terms of "rights", I will refer to Steve's post " Frankly, it makes little difference> to me--all that's important is that it's unambiguous (there _is_ a > definition), and it's convenient for as many people as possible." And really how big a deal are we talking about here? The analyst can still think in microseconds but now microseconds will be expressed in a standard way. I am a little shocked there is any debate. dy Subject: Re: (SMU) SMALL: Time David Yoakley writes to shlaer-mellor-users: -------------------------------------------------------------------- Jon Monroe wrote: > Jon Monroe writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > > Dana Simonson writes > > > Reply to Lahman > > >> More importantly, the units of the data is > >> a problem space issue. If every domain > >> expert thinks of duration in microseconds, > >> what right has the action language > >> specification to vicariously override this > >> and reinterpret the problem space > >> conventions? > > > I agree. If my analysis has a duration such > > as length of Jurassic period I would much > > prefer units of millions of years to using > > seconds. I didn't realize an argument was put on the table tothink of all time durations in seconds. Maybe this is just a common OOA assumption that am not aware of. Should all durations have the same attribute domain? If so, then your argument has sold me. If not, I have a hard time imagining how we can build a system that can stay running long enough to delay an event for a million years. > I also agree. We have several domains on our > project where the natural unit of time is "minutes", > and other domains where it is "microseconds". The > architecture standardized on microseconds, but > dealing with time is always a little awkward in > the "minutes" based domains. I have always wished > that we could color the domain with the units, and > let the architecture handle conversion whenever > time data is passed between domains. I think convenience is the primary argument. And the question is convenient for whom? An assumption was made that it is more convenient/beneficial to have a common definition across all projects, models, etc than it is inconvenient to express such things microseconds etc. I admit, I was focused on sub-second times and don't see much hardship there. Longer durations do get less convenient to express. So I want to solve this problem somehow but hope to not have to lose the benefits of having a standard. One idea is to keep with the notion of event durations in seconds but give the analyst some way to factor the durations when convenient. We could do this with an optional domain time factor that is to be applied to every delayed event. The time factor assumes the result will be some factor of a second. dy ________________________________________________________________________ David Yoakley Objective Innovations Inc. Phone: 512.288.5954 14606 Friendswood Lane Fax: 512.288.6381 Austin, TX 78737 Replies: yoakley@oiinc.com ________________________________________________________________________ Did you ever notice when you blow in a dog's face he gets mad at you? But when you take him in a car he sticks his head out the window! Steve Bluestone Subject: Re: (SMU) SMALL: on navigating sets Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- lahman wrote: > By restricting the OOA to pure set representations this > daunting task of translating paradigms has to be done in the > RD for *every application*. OK, I'll bite. I have always thought that RD _should_ be applied individually to each application. Any potential for reuse in architectures, translators and code generators is useful, but not essential. In large, multi-year, applications development, the overhead of developing an architecture is not too great. It may be insignificant if appropriate tools are available to aid the task. Conversely, very small applications can also utilise RD effectively because they can make do with a small subset of OOA. With a simple architecture (and a bit of method pollution :-|) using translation for small projects can be very effective. The problem really lies in the medium scale applications. These require a complete architecture but its development (plus that of the translator and code generator) will be a significant overhead. This type of project can really benefit from generic, but customisable, architectures. Many applications can use a small set of reusable architectures. But others may require quite radical departures from the current norm. > I would like the methodology to devote the same energy to > providing a suite of OOA abstractions (and rules for applying > them) that would preserve the theoretical constraints while > providing a more useful mapping to the mechanisms of real > implementations. That's all I ask. Really. The one thing we don't want is a big language. This requires the translation engine to support a big source language; potentially a many-to-one mapping onto architectural concepts. A good example of the problems caused by a big language is the hardware description language: VHDL; and its synthesis to a logic netlist. If you write VHDL using the full power of the language then it cannot be synthesised. Instead you must write using a subset of the language (often known as RTL). Unfortunately, this subset is tool specific (with a common core). Worse still, the rules used by synthesis tools means that if you use an incorrect style, the synthesis results may differ from the source without any warnings. (Your testbench should pick up the differences, if its well written. But you still have to know why). If you target OOA at a specific implementation, which implementation technology do you choose? And are you excluding other users. In your post, you asserted that arrays will give you best performance for storage and retrival. In highly parallel systems (especially if part of the system is implemented in an FPGA or ASIC) this may not be true. Arrays imply RAM (or other regular memory). Sometimes a knowledge of the implementation environment can suggest other alternatives once you have extracted the data and control paths from the OOA. A library of translation algorithms would be a powerful part of a CASE vendor's offering. You might even get books of algorithms. But they shouldn't be part of the method itself. Most especially, they shouldn't be part of the notation. Dave. Not speaking for GPS. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com Subject: Re: (SMU) SMALL: nits lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Yoakley... > You acknowledge that scaling (the architecture) could solve this > problemand > certainly it should *if* performance of timed events is a concern. > Nothing new here, just more work for the good old software > architecture. The point I was addressing was that as I read the chapter this was a requirement on the architecture that precluded storing a scaled value (i.e., the data store had to be seconds). Steve's response did not clarify that interpretation; in fact it seemed to support it by saying there had to be some standard units for time. If that was the intent, then I am arguing that it should not be -- that the architecture _must_ be free to provide scaling in the data store. > > More importantly, the units of the data is a problem space issue. > If > > every domain expert thinks of duration in microseconds, what right > has > > the action language specification to vicariously override this and > > reinterpret the problem space conventions? > > In terms of "rights", I will refer to Steve's post " Frankly, it makes > > little difference> to me--all that's important is that it's > unambiguous > (there _is_ a > > definition), and it's convenient for as many people as possible." > > And really how big a deal are we talking about here? The analyst > can still think in microseconds but now microseconds will be expressed > > in a standard way. I am a little shocked there is any debate. Maybe I misinterpreted Steve's post, but as I read it he was saying he didn't think it was important _which_ units were used, so long as they were standard (i.e., only one units could be used, regardless of the problem space). I think there are other mechanisms (e.g., specifying units in the attribute's data domain) to make the intent unambiguous than hard-wiring units into the action language. I think it is important because using the action language to remove ambiguity seems to be contradicting a basic theme of the methodology: that the OOA should reflect the problem space accurately. If we let the action language define the units for time, then it may as well define the units for distance to be furlongs, area to be hectares, etc. The action language has no business doing this; the units very clearly will vary from one problem space to another and the OOA should accommodate this. -- H. S. Lahman There is nothing wrong with me that Teradyne/ATB could not be cured by a capful of Drano 321 Harrison Av. L51 Boston, MA 02118-2238 (Tel) (617)-422-3842 (Fax) (617)-422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) SMALL: on navigating sets lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Whipp... > > By restricting the OOA to pure set representations this > > daunting task of translating paradigms has to be done in the > > RD for *every application*. > > OK, I'll bite. > > I have always thought that RD _should_ be applied individually > to each application. Any potential for reuse in architectures, > translators and code generators is useful, but not essential. Indeed it should. The OOA constructs will never map exactly to the architecture mechanisms, otherwise we would be doing UML. My issue is that the RD needs to ensure that when doing the translation the consistency and integrity of the OOA are preserved. This has to be done in every architecture. However, it is a lot easier to do if the OOA constructs match up fairly closely than if they are disparate. This is particularly true when one has to use combinations of architectural mechanisms to map single OOA constructs. If one goes to the effort of providing OOA constructs that map more easily into architectural mechanisms, then this effort is effectively reused in every architecture. But when the OOA uses very high level abstractions like sets exclusively, then every architecture has to be done the hard way. > > I would like the methodology to devote the same energy to > > providing a suite of OOA abstractions (and rules for applying > > them) that would preserve the theoretical constraints while > > providing a more useful mapping to the mechanisms of real > > implementations. That's all I ask. Really. > > The one thing we don't want is a big language. This requires > the translation engine to support a big source language; > potentially a many-to-one mapping onto architectural concepts. > > A good example of the problems caused by a big language is > the hardware description language: VHDL; and its synthesis to > a logic netlist. If you write VHDL using the full power of > the language then it cannot be synthesised. Instead you must > write using a subset of the language (often known as RTL). > Unfortunately, this subset is tool specific (with a common > core). Worse still, the rules used by synthesis tools means > that if you use an incorrect style, the synthesis results may > differ from the source without any warnings. (Your testbench > should pick up the differences, if its well written. But you > still have to know why). I am well aware that the task is daunting. > If you target OOA at a specific implementation, which > implementation technology do you choose? And are you excluding > other users. In your post, you asserted that arrays will give > you best performance for storage and retrival. In highly > parallel systems (especially if part of the system is > implemented in an FPGA or ASIC) this may not be true. Arrays > imply RAM (or other regular memory). Sometimes a knowledge of > the implementation environment can suggest other alternatives > once you have extracted the data and control paths from the OOA. I would still assert that an arrays will always give better performance than an unordered set for random instance access on any of today's hardware, but I think that is a tangential issue. I agree with you that the future may someday bring whole new computing paradigms. My counter is that they will also bring new methodologies; I think it would be a serious long shot to expect anyone to be doing S-M, OMT, or Structured Programming in 50 years. However, for the foreseeable future (in computer half lives) computers -- more importantly the operating systems and languages supporting them -- are going to have some fairly basic data structures and processing mechanisms that can be abstracted to apply to all of them. The action language has already taken a small step along this path by explicitly supporting ordered sets. Unfortunately it is still left to the analyst to keep track of which sets are ordered and which aren't and it didn't supply any operations other than ordering. From the architecture's viewpoint, there is a big difference between an ordered set and an unordered one. I am not looking for things like a Multi Dimensional Floating Point Array. What I have in mind is more like qualifiers for sets such as ordered and indexable with support in the action language for appropriate operations. And, of course, I would like my beloved depth-first iteration. > A library of translation algorithms would be a powerful part > of a CASE vendor's offering. You might even get books of > algorithms. But they shouldn't be part of the method itself. > Most especially, they shouldn't be part of the notation. I agree. But if the OOA explicitly supports ordered sets, for example, I don't think this overly commits the architecture, which can still use B-trees or whatever from the library to implement it. The OOA, though, would support basic operations like Find, First and Get Next that are appropriate for that particular type of set. Those operations would be fundamental to all of the alternative mechanisms for ordered sets in the library. All I am looking for is a middle ground of abstractions that are more specialized than Set but which can still be implemented in a variety of ways. I believe the idea of an Indexable Set with its basic, generic operations is going to be implementable in an efficient manner for the foreseeable future. Moreover, it will map rather directly to the appropriate architectural mechanisms so that the architect's life becomes easier because the suite of operations and the rules for their use will help ensure consistency in the translation. -- H. S. Lahman There is nothing wrong with me that Teradyne/ATB could not be cured by a capful of Drano 321 Harrison Av. L51 Boston, MA 02118-2238 (Tel) (617)-422-3842 (Fax) (617)-422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) SMALL: nits "Stephen R. Tockey" writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to lahman... > Maybe I misinterpreted Steve's post, but as I read it he was saying he > didn't think it was important _which_ units were used, so long as they > were standard (i.e., only one units could be used, regardless of the > problem space). I could be just as guilty of misinterpreting Steve Mellor as anyone, but when I read his post I understood him to say that it didn't matter _which_ units were used ***so long as they were unambiguously specified in the OOA model***. Meaning it was OK to have more than one unit of time in the same spec (milliseconds in one place and fortnights somewhere else, fer instance). The requirement was only that we could unambiguously determine which units were being used in what cases. > I think there are other mechanisms (e.g., specifying > units in the attribute's data domain) to make the intent unambiguous > than hard-wiring units into the action language. Strongly agreed. > I think it is important because using the action language to remove > ambiguity seems to be contradicting a basic theme of the methodology: > that the OOA should reflect the problem space accurately. If we let the > action language define the units for time, then it may as well define > the units for distance to be furlongs, area to be hectares, etc. The > action language has no business doing this; the units very clearly will > vary from one problem space to another and the OOA should accommodate > this. Also agreed. IMHO, I'd like units in the OOA to be treated like the 'Range and 'Precision qualifiers in Ada. You specify upper and lower bounds ('Range) and the required precision and you leave it up to the machine (Ada Compiler in Ada's case, Mapper and architecture in RD's case) to figure out the appropriate machine-level representation. -- steve Subject: Re: (SMU) SMALL: Dataflows are Dataflows lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Whipp... > Using link/unlink causes problems with referential attributes > which formalise two relationships. This is recognised; and the > PT solution is to say that the value of referential attributes > is meaningless (I can't think of any other solutions). > > This is a statement about the information, not the processing. > What is being said is that the attribute domain (type) of > referential attributes is arbitary. If you attempt to isolate > the effect in the process models then you are saying that > you have two different information models. I would like just > one model. > > If the attribute domain of a referential attribute is arbitary > then the thing to which it refers must also be arbitary. This > inevitably means that all objects must have an arbitary > identifier. This severily weakens the information model. (objects > can still have other, non-arbitary, identifiers). I guess I am especially dense today, but I don't follow this. Link/unlink operates on a relationship. The IM defines that relationship, the types of the instances being related, and the attributes that identify those instances. In this sense the link/unlink _depends_ upon the definitions of the relational model as defined in the IM. That is, it cannot do its thing unless the relational model is properly defined in the IM. So I can't see any way that the link/unlink modifies the attribute domains. > > But the IM is _not_ broken! You want to capture the fact that > > the identifiers must have the same value because this is crucial > > to referential integrity. But as soon as you do capture this > > important fact in the IM you can no longer write NOT PARTICIPATING > > to the attribute when one of two conditional relationships that > > share that identifier is terminated. > > I disagree. The IM _is_ broken because the referential attributes > don't reflect (define) the relationships. > > Perhaps we can get in to an "is" ... "isn't" debate. Maybe, but I don't follow your logic here. How would you capture the fact that the values of the identifiers for the instances have to be the same for both relationships if you do not have them share the same referential attribute? And how is it that the referential attributes do not reflect the relationships? I thought that's what referential attributes do for a living (i.e., define the particular instance engaged in the relationship)! > I agree that NOT PARTICIPATING can also cause a problem, but that > is because it, too, is a wart. I know I lost the argument some > time back about NOT PARTICIPATING, but I do still feel the (c) > should mean that referential integrety is optional; not that an > extra value is introduced. If two relationships cannot be > correctly formalisd in one attribute, then perhaps two attributes > are needed I was somewhat on your side in that debate. I agreed NOT PARTICIPATING is a wart, but for different reasons. > > And I would counter that one has different concerns at each level > > of that progression. By the time I get to state actions, all I > > care about is that I get to the right data stores; I rarely care > > about the details of how I get to them. > > Although SM is a sequential process, I see its aim as producing > a single consistant model (at a consistant level of abstraction). > Our different perspectives may be due to the complexity of your > process models. You talk in terms of 30-50 processes in a DFD; I > normally have less than 10 (often only one or two). Most big > state actions have many flaws; generally a result of domain > pollution or over-specification. Occasionally a big state action > is needed, but its rare. I can't resist a challenge. Here is the pseudo code for an action in the first STD I picked up from the pile on my desk. I would be interested if you see anything in that would account for our different perspectives. Find an unprocessed PATS if found if TMGR.Match = TRUE generate DIGINST7:... else generate TEST13:... else mark PATS as processed link PATS to this via R21 if PATS is STIM if INST.Test Result is FAIL generate TEST6:... else unlink PATS from this via R21 generate TEST5:... else generate TEST9:... We did this in an action language, but if we had done an ADFD there would have been 5 event generators, 4 tests, 3 read accessors, 1 write accessor, and 1 Find without even counting the stuff needed to handle the linking and navigating to TMGR and INST -- probably 25 ADFD bubbles in all. Basically all this action is doing is dispatching to the next activity. We could have split out the "if found" and the "if not found" activities into different states, but that would clutter the state model and add superfluous events that had nothing to do with flow of control relative to the STD's level of abstraction. Similar argument for the check on STIM. I don't see a whole lot of domain pollution here, or over-specification. However, at least one state of this level of complexity will tend to show up in each of our state models. I agree that most actions are pretty small, though. In the STD where this action came from there were 12 states, of which the example was the largest, three were about about 1/2 to 2/3 the size, and the rest were trivial. Still, the larger actions are not exactly rare. -- H. S. Lahman There is nothing wrong with me that Teradyne/ATB could not be cured by a capful of Drano 321 Harrison Av. L51 Boston, MA 02118-2238 (Tel) (617)-422-3842 (Fax) (617)-422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) SMALL: Dataflows are Dataflows Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- lahman wrote: > In this sense the link/unlink _depends_ upon the definitions of > the relational model as defined in the IM. That is, it cannot > do its thing unless the relational model is properly defined in > the IM. So I can't see any way that the link/unlink modifies > the attribute domains. > [...] > Maybe, but I don't follow your logic here. How would you > capture the fact that the values of the identifiers for the > instances have to be the same for both relationships if you > do not have them share the same referential attribute? And > how is it that the referential attributes do not reflect the > relationships? I thought that's what referential attributes > do for a living (i.e., define the particular instance engaged > in the relationship)! I think we're getting confused somewhere. I am arguing that current value of a referential attribute defines the current [state] of a relationship. So I am arguing for precisely what you are stating in that paragraph. However, when you use link/unlink, the paper on SMALL defines that "the values of [referential attributes] have no meaning in the OOA models" ( last sentense in section 6.6). Just above the two bullet points here, the paper states that: the values of these attributes are "architecture-dependent". Either there are two attribute domains for referential attributes; or the thing to which the attributes refer must also be "architecture- dependent". Alternatively, the value of a referential attribute does not define the relationship (and we are both arguing that it does). This is a result of the use of references and link/unlink. It is easy to demonstrate that referential attributes are meaningful. Just look at any of the examples of referential attributes where a table representation of a object is used. >> Although SM is a sequential process, I see its aim as producing >> a single consistant model (at a consistant level of abstraction). >> Our different perspectives may be due to the complexity of your >> process models. You talk in terms of 30-50 processes in a DFD; I >> normally have less than 10 (often only one or two). Most big >> state actions have many flaws; generally a result of domain >> pollution or over-specification. Occasionally a big state action >> is needed, but its rare. > > I can't resist a challenge. Here is the pseudo code for an action > in the first STD I picked up from the pile on my desk. I would be > interested if you see anything in that would account for our > different perspectives. > 1> Find an unprocessed PATS 2> if found 3> if TMGR.Match = TRUE 4> generate DIGINST7:... 5> else 6> generate TEST13:... 7> else 8> mark PATS as processed 9> link PATS to this via R21 10> if PATS is STIM 11> if INST.Test Result is FAIL 12> generate TEST6:... 13> else 14> unlink PATS from this via R21 15> generate TEST5:... 16> else 17> generate TEST9:... > > We did this in an action language, but if we had done an ADFD there > would have been 5 event generators, 4 tests, 3 read accessors, 1 write > accessor, and 1 Find without even counting the stuff needed to handle > the linking and navigating to TMGR and INST -- probably 25 ADFD > bubbles in all. I'm not sure that I can find 25 bubbles. Even at 1 bubble per line, you only have 7 bubbles. subtract 4 for the "else"s and add 3 for the combined test/accessor and you get 16 processes. And I can't say that I see anything to account for our different perspectives. I would need to see the IM and STM(s) to properly review it. However: line 8: "mark PATS as processed". This intrigues me because you haven't found any PATS. If I assume that you've just made a type somewhere then, since you have just done a seach for [un]processed PATS, you already know that PATS has been processed. So why do you need to mark it? If this is a wormhole then perhaps it should be invoked from the state that marked PATS for the search. Perhaps I'm just completely misunderstanding your pseudocode. A more obvious mistake is: line 14: you're unlinking something that you linked at line 9. A better use of guards would eliminate this unlink. There may be some slightly more global issues that I can't see from just this single state action. There is a long running OO disbute regarding the use of MANAGER objects (this seems to be an example of these). A bit of deligation would simplify the action. It is also possible that some of your chained tests could be collapsed into single tests processes. I don't know. > I don't see a whole lot of domain pollution here, or > over-specification. However, at least one state of this level > of complexity will tend to show up in each of our state models. > I agree that most actions are pretty small, though. In the STD > where this action came from there were 12 states, of which the > example was the largest, three were about about 1/2 to 2/3 the > size, and the rest were trivial. Still, the larger actions are > not exactly rare. I see 14 processes in that "big" action (without global optimisation) Using the figures you give, this implies that about 8% of state actions have more than 10 processes. This seems broadly in agreement with my heuristic. (My models probably have fewer because I use a more delegated style). It is probably true that most models have at least one big state action In your example, most of the processes were tests, generates and read accessors (of various types). You had one link and zero unlinks. If we assume that chained relationships can be navigated in one process then I don't see that relationship manipulations a large proportion of state actions. So I don't see how the use of link/unlink (instead of writing to referential attributes) will simplify your models. I also can't see how the use of references simplifies your example state action. Dave. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com Subject: (SMU) Referential attribute domains and access Mike Morrin writes to shlaer-mellor-users: -------------------------------------------------------------------- Object Lifecycles, chapter 2 (page 19) says of referential attributes: 'The value that a referential attribute may take on will always be the same as the value for some attribute acting as an identifier for the associated object. Consequently, the domain description is always given by the phrase "Same as ",...' Dave Whipp writes to shlaer-mellor-users: > the paper on SMALL defines that "the values of [referential attributes] > have no meaning in the OOA models" ( last sentense in section 6.6). > Just above the two bullet points here, the paper states that: the values > of these attributes are "architecture-dependent". Either there are two > attribute domains for referential attributes; or the thing to which the > attributes refer must also be "architecture- dependent". Alternatively, > the value of a referential attribute does not define the relationship . I suggest that the SMALL paper is in error here, and that the first bullet point in 6.6 should read something like: * referential attributes where the referred-to identifier is of type arbitrary. If it is really intended that referential attributes can NEVER be read in the formalising object, then I think it is a very bad move. regards, Mike Subject: Re: (SMU) SMALL: Dataflows are Dataflows lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Whipp... > I think we're getting confused somewhere. I am arguing that > current value of a referential attribute defines the current > [state] of a relationship. So I am arguing for precisely what > you are stating in that paragraph. Terrific! > However, when you use link/unlink, the paper on SMALL defines > that "the values of [referential attributes] have no meaning > in the OOA models" ( last sentense in section 6.6). Just above > the two bullet points here, the paper states that: the values > of these attributes are "architecture-dependent". Either there > are two attribute domains for referential attributes; or the > thing to which the attributes refer must also be "architecture- > dependent". Alternatively, the value of a referential attribute > does not define the relationship (and we are both arguing that > it does). I think I finally begin to see where you are coming from. I think I agree with Morrin that this was simply mis-stated. At least the top sentence should read, "...value may be architecture-dependent:" When I first read this I assumed they were referring to the fact that even though the identifier might have meaningful values in the problem space, the architecture is free to implement the relationship using other means. I also read the last sentence in a similar manner -- that the values were not meaningful in the OOA in the sense that you should not test or otherwise use them in any way except to navigate relationships. For example, suppose an identifier was Index with a data domain of integers from 0 to 13. In the identified object instance it would be fair to test for Index > 7. However, it would not be fair to test the referential attribute in another object the same way. The other object could only access the original (identified) instance via the relationship and then test that instance's identifier. (I realize this interpretation is more general than the relational table model, but relational tables don't have the advantage of RD.) However, taken literally, I agree with you that those sentences throw out the relational data model when read literally. I just don't think that was the intent. > I'm not sure that I can find 25 bubbles. Even at 1 bubble per line, > you only have 7 bubbles. subtract 4 for the "else"s and add 3 for > the combined test/accessor and you get 16 processes. And I can't > say that I see anything to account for our different perspectives. My count was:5 event generators: DIGINST7, TEST13, TEST6, TEST5, and TEST9 4 tests: found, TMGR.Match, PATS is STIM, and INST.Test Result 3 read accessors: TMGR.Match, PATS (for STIM) and INST.Test Result 1 write accessor: mark PATS 1 Find: Find an unprocessed PATS ---- 14 With OOA96 tests can no longer access data stores, so these are separate. To navigate to TMGR, PATS, and INST one needs to read the referential attributes. Often, as in this case, this is a relationship chain. (This action's description was not well written by our current standards; we now spell out the relationships because we found can't-get-there-from-here problems when writing the actions that should have shown up in the STD review.) Since we routinely use compound identifiers, this navigation typically requires multiple accessors per instance. > I would need to see the IM and STM(s) to properly review it. > However: > > line 8: "mark PATS as processed". This intrigues me because > you haven't found any PATS. If I assume that you've just made > a type somewhere then, since you have just done a seach for > [un]processed PATS, you already know that PATS has been > processed. So why do you need to mark it? If this is a > wormhole then perhaps it should be invoked from the state that > marked PATS for the search. The first line is "Find an unprocessed PATS". Line 8 is in the else where one has been found. This unprocessed PATS is now being processed (R21 and the TESTn events) so it has to be so marked to prevent it being found again the next time through the state. We actually debated a lot about this because the whole idea of marking implies an implementation (e.g., in the actual implementation there was no Marked attribute; we did a Get Next on an array). > Perhaps I'm just completely misunderstanding your pseudocode. > A more obvious mistake is: > > line 14: you're unlinking something that you linked at line 9. > A better use of guards would eliminate this unlink. The unlink could have been eliminated by moving the link in with TEST6 and TEST9. The problem is we want to process everybody except STIMs that PASSED; the R21 relationship was used in other actions to navigate to the PATS being currently processed. As I look at this it has the feel of a fix made during simulation. It could have been done more elegantly, but it is correct. > There may be some slightly more global issues that I can't see > from just this single state action. There is a long running > OO disbute regarding the use of MANAGER objects (this seems > to be an example of these). A bit of deligation would > simplify the action. It is also possible that some of your > chained tests could be collapsed into single tests processes. > I don't know. The TMGR object doesn't actually do anything; it is passive. The TMGR simply keeps track of what tests are around through relationships, counts, and other housekeeping. It also stores some overall information concerning the test session. Basically all the bridges start at TMGR to figure out where to throw a given event. > In your example, most of the processes were tests, generates > and read accessors (of various types). You had one link and > zero unlinks. If we assume that chained relationships can be > navigated in one process then I don't see that relationship > manipulations a large proportion of state actions. So I > don't see how the use of link/unlink (instead of writing to > referential attributes) will simplify your models. I also > can't see how the use of references simplifies your example > state action. It may be a matter of style but when we were doing ADFDs the relationships were done with individual accessors per relational attribute. Usually this was because we would already have some of the compound identifiers in hand. To avoid a combinatorial suite of accessors we copped out and did 1:1::accessors:attributes. As a result we would have a _lot_ of bubbles doing referential attribute reads. In the example I think we would have easily had 10 such reads if we had done an ADFD. -- H. S. Lahman There is nothing wrong with me that Teradyne/ATB could not be cured by a capful of Drano 321 Harrison Av. L51 Boston, MA 02118-2238 (Tel) (617)-422-3842 (Fax) (617)-422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) SMALL: nits lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Tockey... > I could be just as guilty of misinterpreting Steve Mellor as anyone, > but > when I read his post I understood him to say that it didn't matter > _which_ > units were used ***so long as they were unambiguously specified in the > > OOA model***. Meaning it was OK to have more than one unit of time in > the same spec (milliseconds in one place and fortnights somewhere > else, fer > instance). The requirement was only that we could unambiguously > determine > which units were being used in what cases. Hey, I have the franchise on misinterpretation around here! Obviously this won't be resolved until Steve chimes in again. But I had the impression that timers were in the background somewhere and the desire was to provide a standard for duration that timers would understand, regardless of the application. If duration is always in a standard units it is much easier to get timers to work in simulation. -- H. S. Lahman There is nothing wrong with me that Teradyne/ATB could not be cured by a capful of Drano 321 Harrison Av. L51 Boston, MA 02118-2238 (Tel) (617)-422-3842 (Fax) (617)-422-3100 lahman@atb.teradyne.com Subject: RE: (SMU) Referential attribute domains and access "Lynch, Chris D. SD" writes to shlaer-mellor-users: -------------------------------------------------------------------- Mike Morrin quoth: >Object Lifecycles, chapter 2 (page 19) says of referential attributes: >'The value that a referential attribute may take on will always be the >same as the value for some attribute acting as an identifier for the >associated object. Consequently, the domain description is always given >by the phrase "Same as object>",...' Thanks for supplying the "smoking gun". I had mentioned in a recent post (which disappeared into the ether) that PT's course materials intended us to show attributes of sample objects in tabular form, where we dutifully recorded the ID of the other instance- - a clear indication that such values are not arbitrary. I should mention that "primary keys shall never have meaning" and "all primary keys shall be assigned by the system" are two time-tested 'keys' to success in designing a stable database. Perhaps PT is inching in the direction of making these two ideas part of their information modeling formalism. **A slightly different question about referentials:** are "null" (e.g. NOT PARTICIPATING) values allowed for attributes in "standard relational theory" (e.g., Codd's and Date's book) ? (My recollection is that they aren't.) If so, perhaps this business of the referentials points to something deeper. -Chris Lynch Abbott AIS Subject: Re: (SMU) SMALL: Dataflows are Dataflows David.Whipp@gpsemi.com (Dave Whipp) writes to shlaer-mellor-users: -------------------------------------------------------------------- Lahman wrote: > I thought that's what referential attributes > do for a living (i.e., define the particular instance engaged > in the relationship)! Mike Morrin wrote: > I suggest that the SMALL paper is in error here, and that the first > bullet point in 6.6 should read something like: > > * referential attributes where the referred-to identifier is of > type arbitrary. Lahman wrote: > However, taken literally, I agree with you that those sentences > throw out the relational data model when read literally. I just > don't think that was the intent. We seem to have some agreement here. So now I'll try and restate my initial argument; and show why The sentenses must be taken literally for link/unlink to work. Referential attributes define/reflect relationships. To put it another way: referential attributes _are_ the relationship. From the point of view of the model, there is no other (hidden) data to allow a relationship to be independent of referential attributes. Given this, the semantics of link/unlink, from the point of view of the OOA, must be to fiddle with the values of referential attributes. Any other interpretation is incompatible with the data model. If this is accepted, then it must always be true, even when a single referential attribute formalises two (or more) relationships. When you link/unlink using one relationship, this must, from the point of view of the OOA, set the value of the referential attribute(s). Since the referential attribute also defines another relationship, that relationship must also be effected. The conclusion of this is that link can have have a very unfortunate side effect. You supply two instance-references to link one relationship; and the achitecture must search for a third instance to link a different relationship. I regard this as very undesirable. I can see three courses of action: 1. accept it. 2. get rid of link/unlink. 3. get rid of referential attributes. PT (in SMALL) appear to have gone for option 3, in a reather half-hearted way. They have said that referential attributes are meaningless; but they have left them in the information model. If you assume that the quoted sentenses are not to be taken literally, then they have gone for option 1. I think we could use some clarfication from PT. Dave. Not speaking for GPS. ps. I know I keep on stessing "from the point of view of the OOA." I do this because people regularly confuse the argument from the OOA perspective with the arguement from an implementation perspective. It is very likely that an implementation will not actually store the values of referential attributes. This should not infuence the OOA formalism. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com Subject: Re: (SMU) SMALL: Dataflows are Dataflows lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Whipp... > We seem to have some agreement here. So now I'll try and restate > my initial argument; and show why The sentenses must be taken > literally for link/unlink to work. > > Referential attributes define/reflect relationships. To put it > another way: referential attributes _are_ the relationship. From > the point of view of the model, there is no other (hidden) data > to allow a relationship to be independent of referential > attributes. > > Given this, the semantics of link/unlink, from the point of view > of the OOA, must be to fiddle with the values of referential > attributes. Any other interpretation is incompatible with the > data model. We are in complete agreement up to here. > If this is accepted, then it must always be true, even when a > single referential attribute formalises two (or more) > relationships. When you link/unlink using one relationship, this > must, from the point of view of the OOA, set the value of the > referential attribute(s). Since the referential attribute also > defines another relationship, that relationship must also be > effected. > > The conclusion of this is that link can have have a very > unfortunate side effect. You supply two instance-references to > link one relationship; and the achitecture must search for a > third instance to link a different relationship. This is where we part company. The link/unlink is associated with only the particular relationship defined in the syntax. If a referential attribute is shared in the IM all this means is that the value of the referential attribute must be the same for both relationships if they are both active. Therefore, if a referential identifier is shared then the implementation of the link/unlink must verify the equality. But the sharing of a referential attribute in the IM does not imply that one has to have a single referential attribute in the implementation. Enforcing the fact that the relevant referential identifiers have the same values as an existing relationship (if so defined in the IM) is an architectural issue for implementing link/unlink. The link is responsible for making the appropriate rude but graceful response if it is not true, at least during simulation. But I don't see any requirement that the link instantiate or even navigate any relationship other than the one defined in the invocation syntax. To do the check, the architecture needs to verify the equality of referential identifiers. However, it is free to implement this in any way that it wants, so I would hope that it does not do something silly like a search. I would expect the architecture to keep around whatever data it needed -- flags to indicate which relationships were active and/or the relevant identifier values themselves -- as architectural attributes to do the check efficiently. Thus I do not see much of an OOA issue here; in my view it is primarily an architectural issue since the link/unlink is essentially just a surrogate for assigning or deassigning referential identifiers. The implications in the OOA are almost identical. In either case one has to extract the identifiers of the instance to which one is linking/unlinking; the link/unlink just does this behind the scenes. In either case one has to assign/deassign the relational identifiers in the instance from which one is linking. Again, the link/unlink does this behind the scenes. The first difference is that the check for equality of shared identifiers is done explicitly in simulation using explicit ADFD-style assignment while it is done in the architecture for link. The second difference is that the ambiguity of the assignment of NOT PARTICIPATING when one, but not both, relationships goes away is eliminated in the unlink because the architecture can keep enough information around to keep things straight. (This seems to me to be effectively what you did when you had different flavors of NOT PARTICIPATING to resolve the problem because the architecture had to keep track of those flavors somehow as separate data items.) -- H. S. Lahman There is nothing wrong with me that Teradyne/ATB could not be cured by a capful of Drano 321 Harrison Av. L51 Boston, MA 02118-2238 (Tel) (617)-422-3842 (Fax) (617)-422-3100 lahman@atb.teradyne.com Subject: (SMU) SMALL: Why? "Greg Wiley" writes to shlaer-mellor-users: -------------------------------------------------------------------- While I understand the historical reasons for textual action languages, I fail to see why so much effort is being expended creating a new textual dataflow language. If the result is a textual language with a one-one correspondence to a graphical language, why not put the energy into a rigorous definition of the graphical language? Graphical DFD's are more readable than the dataflow scripts (coinage alert) I've seen so far and processing directed graphs is a well-understood problem. -greg Subject: (SMU) Twelve Tech Days of Christmas Phil Ryals writes to shlaer-mellor-users: -------------------------------------------------------------------- I'm not sure what the orginal source of this is; it has been circulating around the underground humor network. Sally suggested that I send it to ESMUG for your holiday enjoyment. Best wishes for a joyous season, Phil Ryals Technical Services -------------- We present, in the spirit of Christmas, the Solstice and Secular Humanism a new standard to be loved for the ages...... The 12 Days of Technology Before Christmas/Solstice On the first day of Christmas, technology gave to me: A database with a broken b-tree (what the hell is a b-tree anyway?) On the second day of Christmas, technology gave to me: Two transceiver failures (CRC errors? Collisions? What is going on?) And a database with a broken b-tree (Rebuild WHAT? It's a 10GB database!) On the third day of Christmas, technology gave to me: Three French users (who, of course, think they know everything) Two transceiver failures (which are now spewing packets all over the net) And a database with a broken b-tree (Backup? What backup?) On the fourth day of Christmas, technology gave to me: Four calls for support (playing the same Christmas song over and over) Three French users (Why do they like to argue so much over trivial things?) Two transceiver failures (How the hell do I know which ones they are?) And a database with a broken b-tree (Pointer error? What's a pointer error?) On the fifth day of Christmas, technology gave to me: Five golden SCSI contacts (Of course they're better than silver!) Four support calls (Ever notice how time stands still when on hold? Three French users (No, we don't have foot pedals on PC's. Why do you ask?) Two transceiver failures (If I knew which ones were bad, I would know which ones to fix!) And a database with a broken b-tree (Not till next week? Are you nuts?!?!) On the sixth day of Christmas, technology gave to me: Six games a-playing (On the production network, of course!) Five golden SCSI contacts (What do you mean "not terminated!") Four support calls (No, don't transfer me again - do you HEAR? Damn!) Three French users (No, you cannot scan in by putting the page to the screen...) Two transceiver failures (I can't look at the LEDs - they're in the ceiling!) And a database with a broken b-tree (Norway? That's where this was written?) On the seventh day of Christmas, technology gave to me: Seven license failures (Expired? When?) Six games a-playing (Please stop tying up the PBX to talk to each other!) Five golden SCSI contacts (What do you mean I need "wide" SCSI?) Four support calls (At least the Muzak is different this time...) Three French Users (Well, monsieur, there really isn't an "any" key, but...) Two transceiver failures (SQE? What is that? If I knew I would set it myself!) And a database with a broken b-tree (No, I really need to talk to Lars - NOW!) On the eighth day of Christmas, technology gave to me: Eight MODEMs dialing (Who bought these? They're a security violation!) Seven license failures (How many WEEKS to get a license?) Six games a-playing (What do you mean one pixel per packet on updates?!?) Five golden SCSI contacts (Fast SCSI? It's supposed to be fast, isn't it?) Four support calls (I already told them that! Don't transfer me back - DAMN!) Three French users (No, CTL-ALT-DEL is not the proper way to end a program) Two transceiver failures (What do you mean "babbling transceiver"?) And a database with a broken b-tree (Does anyone speak English in Oslo?) On the ninth day of Christmas, technology gave to me: Nine lady executives with attitude (She said do WHAT with the servers?) Eight MODEMs dialing (You've been downloading WHAT?) Seven license failures (We sent the P.O. two months ago!) Six games a-playing (HOW many people are doing this to the network?) Five golden SCSI contacts (What do you mean two have the same ID?) Four support calls (No, I am not at the console - I tried that already.) Three French users (No, only one floppy fits at a time? Why do you ask?) Two transceiver failures (Spare? What spare?) And a database with a broken b-tree (No, I am trying to find Lars! L-A-R-S!) On the tenth day of Christmas, technology gave to me: Ten SNMP alerts flashing (What is that Godawful beeping?) Nine lady executives with attitude (No, it used to be a mens room? Why?) Eight MODEMs dialing (What Internet provider? We don't allow Internet here!) Seven license failures (SPA? Why are they calling us?) Six games a-playing (No, you don't need a graphics accelerator for Lotus! ) Five golden SCSI contacts (You mean I need ANOTHER cable?) Four support calls (No, I never needed an account number before...) Three French users (When the PC sounds like a cat, it's a head crash!) Two transceiver failures (Power connection? What power connection?) And a database with a broken b-tree (Restore what index pointers?) On the eleventh day of Christmas, technology gave to me: Eleven boards a-frying (What is that terrible smell?) Ten SNMP alerts flashing (What's a MIB, anyway? What's an extension?) Nine lady executives with attitude (Mauve? Our computer room tiles in mauve?) Eight MODEMs dialing (What do you mean you let your roommate dial-in?) Seven license failures (How many other illegal copies do we have?!?!) Six games a-playing (I told you - AFTER HOURS!) Five golden SCSI contacts (If I knew what was wrong, I wouldn't be calling!) Four support calls (Put me on hold again and I will slash your credit rating!) Three French users (Don't hang your floppies with a magnet again!) Two transceiver failures (How should I know if the connector is bad?) And a database with a broken b-tree (I already did all of that!) On the twelfth day of Christmas, technology gave to me: Twelve virtual pipe connections (There's only supposed to be two!) Eleven boards a-frying (What a surge suppressor supposed to do, anyway?) Ten SNMP alerts flashing (From a distance, it does kinda look like XMas lights.) Nine lady executives with attitude (What do you mean aerobics before backups?) Eight MODEMs dialing (No, we never use them to connect during business hours.) Seven license failures (We're all going to jail, I just know it.) Six games a-playing (No, no - my turn, my turn!) Five golden SCSI contacts (Great, just great! Now it won't even boot!) Four support calls (I don't have that package! How did I end up with you!) Three French users (I don't care if it is sexy, no more nude screen backgrounds!) Two transceiver failures (Maybe we should switch to token ring...) And a database with a broken b-tree (No, operator - Oslo, Norway. We were just talking and were cut off...) ______________________________________________________________________ . + . . . . + . . * + . . . * . /*\ . * . . * , . . /***\ . . . * . . . . + <*******> + . . . . + . /*****\ . . * + + . . * /*********\ * + . , . . . <*************> . + . . + . . # . . * . ____________________________#_________________________________________ Merry Christmas and Happy New Year! Subject: Re: (SMU) SMALL: Why? lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Wiley... > While I understand the historical reasons for > textual action languages, I fail to see why > so much effort is being expended creating a > new textual dataflow language. > > If the result is a textual language with a one-one > correspondence to a graphical language, why not > put the energy into a rigorous definition of the > graphical language? > > Graphical DFD's are more readable than the > dataflow scripts (coinage alert) I've seen so far > and processing directed graphs is a well-understood > problem. We have debated this internally without clear resolution, so the following is primarily personal opinion. The quick answer is that it is easier for the vendors to implement -- at least it was a decade ago when the first tools were developed. This is less true now that GUIs and the tools to build them have become more sophisticated. There is at least one vendor who does generate code directly from ADFDs. One the other side of the coin, we found that ADFDs were an excellent tool for an initial development. I agree that they can be clearer than a text language. But to achieve that clarity you have to be careful about the layout and it takes significantly longer to do this in a GUI than it does to write action language in an editor, especially if it an LSE. Once we were in maintenance mode with a manual translation, we rarely looked at the ADFDs. We did all our debugging and analysis from the state models and went directly to the code. This meant that the maintenance of the ADFDs became a rather thankless task. Also, changing ADFDs is typically a major pain because invariably you have to stick bubbles into the middle of an existing cluster, which means moving all the existing bubbles around. This is very tedious compared to making a small change in an action language. The downside of action languages is that it is very easy for the vendor to sneak in features that the ADFD does not support. One tool vendor actually uses C++ as the action language. However, if the action language is a true data flow language, then I don't see a technical difference between it and an ADFD. They should be equivalent and the action language will then be easier to maintain. -- H. S. Lahman There is nothing wrong with me that Teradyne/ATB could not be cured by a capful of Drano 321 Harrison Av. L51 Boston, MA 02118-2238 (Tel) (617)-422-3842 (Fax) (617)-422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) Mathematical Dependence "Leslie Munday" writes to shlaer-mellor-users: -------------------------------------------------------------------- Thanks for responding, it's nice to know that someone took an interest. Just briefly want to finish this by stating that what I meant by my comment is that, if a is mathematically dependent upon b & c, should it not be written as: a=f(b,c) and not a=b*c? Leslie. -----Original Message----- From: lahman To: shlaer-mellor-users@projtech.com Date: Tuesday, December 16, 1997 2:18 AM Subject: Re: (SMU) Mathematical Dependence >lahman writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >Responding to Munday... > >> I may not be fully understanding this thread of discussion, but since >> it's been going on for so long, I've decided to add my piece of >> confusion. >> >> Comment on the above paragraph: >> >> a = b * c ; also a = sigma(1..b) of c ; also a = sigma(1..c) of b ; >> also >> a = sqrt( a*b*a*b) ; also a = d + (a * b) - d, etc, etc,... >> >> Does this make sense in the context of this thread? > >I am surprised no one else responded to this. I figured I would let >someone else deal with it who has taken math courses since the time >Alchemy was a major. > >The quick answer is: yes. The issues represented in the first line are >typical mathematical dependencies. When asked for the dependent value, >that value read must be equal to the value of the expression. So far, >so good. At the algebraic level the computation is completely >deterministic; it is stated, therefore it is. The difficulty is that >the problem space tends not to be so simplistic. In particular, the >state of the system varies over time and there may be some notion of >consistency among the independent variables that must be satisfied for >the calculation to be meaningful in the problem space. > [SNIP] >-- >H. S. Lahman There is nothing wrong with me that >Teradyne/ATB could not be cured by a capful of Drano >321 Harrison Av. L51 >Boston, MA 02118-2238 >(Tel) (617)-422-3842 >(Fax) (617)-422-3100 >lahman@atb.teradyne.com > > > Subject: (SMU) SMALL Stuff "Leslie Munday" writes to shlaer-mellor-users: -------------------------------------------------------------------- This is a multi-part message in MIME format. ------=_NextPart_000_049C_01BD0FAF.9D208710 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I've had a copy of the SMALL definition (Chapter 6) in my possession for = a few weeks now, and although I haven't read it in detail, I just wanted = to make a few comments for discussion. Firstly, I'd like to say thankyou to all involved for publishing = something which tries to reflect the functionality of ADFDs, and admits = that current Action Specification Languages are not sufficient to = reflect the processing concepts that are shown within the average ADFD. If ADFDs have been sufficient to reflect data manipulation, in the past, = why is it necessary for a textual representation to introduce additional = constructs? [Link/Unlink for example] (Yes, I know there are threads = about this subject, I just wanted to agree with the question, and = broaden the issue). SMALL is very terse. With the power of current text based editors, why = is it necessary to make the notation so difficult to read? (For example, = instead of using the symbol '>' for write, and '>>' for create, which = overloads two already overloaded symbols, just say 'write' and = 'create'). While on the above subject, it took me many years to persuade my = customers (non-software oriented people, many times people with = backgrounds in hardware or electrical engineering) to understand the = notation in an ADFD. After all, ADFDs represent requirements, and = requirements need to be understood by the customer. With the notation of = SMALL, I do not envision persuading my customers to try and understand = the language, in my engineering life-time. There are cases where the same SMALL expression may be written using = more than one notation. Top of page 12, for example. Why? It just makes = the language more difficult to understand, and, I might argue, fails the = 'ham sandwich test'. I would agree to having a terse and an obtuse = version. One which is written for customers to understand, the other for = designers to translate into code. In this case the two notations should = not be intermixed, but an automated conversion process may be made = available. In summary, this paper, to me, is the best thing to come out of S/M = since the definition of ADFDs. If it can express all concepts that are = expressable in ADFDs, then it is sufficient. If it does more then don't = use those extra capabilities, if you don't want to (notice, at this = point the 'ham sandwich test' fails again). Personally, I would like to = see it using more English, because that's the language that my customers = read and write specs in. A non-English biased language also has good = arguments for it. So let's have the option of both. Leslie. Subject: Re: (SMU) Mathematical Dependence Andrew McKinley writes to shlaer-mellor-users: -------------------------------------------------------------------- Leslie Munday wrote: > "Leslie Munday" writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Just briefly want to finish this by stating that what I meant by my comment > is that, if a is mathematically dependent upon b & c, should it not be > written as: > > a=f(b,c) and not a=b*c? I like the format of f(b, c), which indicates that a is dependant on b and c. It is the generic form which, perhaps, could find a place in the IM. The fact that a = (b * c), as opposed to a = sqrt((b * b) + (c * c)), must be documented somewhere, probably attached to the attribute. enjoy, andy > Leslie. Subject: Re: (SMU) SMALL Stuff lahman writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Munday... > SMALL is very terse. With the power of current text based editors, > why is it necessary to make the notation so difficult to read? (For > example, instead of using the symbol '>' for write, and '>>' for > create, which overloads two already overloaded symbols, just say > 'write' and 'create'). I agree. Terseness and elegance are usually not virtues for maintenance -- especially when the symbols have different accepted meanings in otehr contexts. If they use '>>' for create, then what will they use for bitwise right shift when that is added to the available operators? OTOH, I suspect the reason was to preserve the precious real estate on STDs. It is important to be able to get an STD to be easily readable on a single 11x17 hardcopy for reviews and debugging. If the action language is used to describe the states, this might be difficult. However, I think the traditional free-form action description is sufficient for the STD; being able to access the acton language in a separate dialog or printout is sufficient. [For some reason Netscape hung each time I tried to insert a reply after your next paragraph, so I have to prepend...] I am less worried about end users looking at the action language. While it can be regarded as requirements for the translation, it is really an intermediate rework of the requirements by the analyst. Therefore this is more of an issue of requirements traceability, which is usually not the end user's direct problem (i.e., whoever is designated to do this level of requirements tracing has to be familiar with the notation). I believe the end user should be verifying requirements in a different form -- such as the black-box description usually seen in a Functional Specification. If I did get to this level with the end user, I would probably still use the traditional free-form action descriptions in the STD. I also agree that if one has a simple language like this it seems curious that there are different ways of expressing the same thing. I think that the second form, "21 >> ..." is particularly obtuse. > While on the above subject, it took me many years to persuade my > customers (non-software oriented people, many times people with > backgrounds in hardware or electrical engineering) to understand the > notation in an ADFD. After all, ADFDs represent requirements, and > requirements need to be understood by the customer. With the notation > of SMALL, I do not envision persuading my customers to try and > understand the language, in my engineering life-time. There are cases > where the same SMALL expression may be written using more than one > notation. Top of page 12, for example. Why? It just makes the language > more difficult to understand, and, I might argue, fails the 'ham > sandwich test'. I would agree to having a terse and an obtuse version. > One which is written for customers to understand, the other for > designers to translate into code. In this case the two notations > should not be intermixed, but an automated conversion process may be > made available. In summary, this paper, to me, is the best thing to > come out of S/M since the definition of ADFDs. If it can express all > concepts that are expressable in ADFDs, then it is sufficient. If it > does more then don't use those extra capabilities, if you don't want > to (notice, at this point the 'ham sandwich test' fails again). > Personally, I would like to see it using more English, because that's > the language that my customers read and write specs in. A non-English > biased language also has good arguments for it. So let's have the > option of both. Leslie. -- H. S. Lahman There is nothing wrong with me that Teradyne/ATB could not be cured by a capful of Drano 321 Harrison Av. L51 Boston, MA 02118-2238 (Tel) (617)-422-3842 (Fax) (617)-422-3100 lahman@atb.teradyne.com Subject: Re: (SMU) SMALL: Dataflows are Dataflows Dave Whipp writes to shlaer-mellor-users: -------------------------------------------------------------------- Lahman wrote: > > Referential attributes define/reflect relationships. To put it > > another way: referential attributes _are_ the relationship. From > > the point of view of the model, there is no other (hidden) data > > to allow a relationship to be independent of referential > > attributes. > > > > Given this, the semantics of link/unlink, from the point of view > > of the OOA, must be to fiddle with the values of referential > > attributes. Any other interpretation is incompatible with the > > data model. > > We are in complete agreement up to here. > [CUT] > > > > The conclusion of this is that link can have a very > > unfortunate side effect. You supply two instance-references to > > link one relationship; and the architecture must search for a > > third instance to link a different relationship. > > This is where we part company. The link/unlink is associated with > only the particular relationship defined in the syntax. If a > referential attribute is shared in the IM all this means is that > the value of the referential attribute must be the same for both > relationships if they are both active. Therefore, if a referential > identifier is shared then the implementation of the link/unlink must > verify the equality. But the sharing of a referential attribute in > the IM does not imply that one has to have a single referential > attribute in the implementation.> I don't think that we do part company where you suggest. I think that I failed to may be argument with sufficient clarity. Please allow me to restate that my concerns about link/unlink (etc) have nothing whatsoever (ABSOLUTELY NOTHING), to do with architectures or implementations. link/unlink is an OOA construct, so its effects should be considered purely from this perspective. All my comments have nothing whatsoever to do with implementations. (I'm sorry for the repetition, but for some reason this thread repeatedly gets implementation pollution) Right: You have agreed that relationships are completely defined by the values of referential attributes. If you know the value of the referential attribute(s) then you know the relationship. Furthermore, I think you also agreed that, from the perspective of the OOA (i.e. in a simulation) the only information that is available to define the relationship is its formalising attributes. Consider a model with 3 objects (A, B and C), with relationships r1 and r2 between A/B and B/C respectively. For this demonstration, I will define a referential attribute in B to formalise both relationships (for simplicity, there are no compound identifiers). Suppose there are two instances of A; two instances of C; and one instance of B. Let the identifiers of the instances of both A and C be "1" and "2". The value of the referential attribute in B will before be either "1" or "2". (You may want to draw an instance table for each object) Hopefully you agree that, if I was able to change the value of the referential attribute in B from "1" to "2" then both relationships would be effected. However: in SMALL, I cannot do that. I must use two link processes to link the two relationships. (Actually, I might need to use 4 processes - it isn't clear whether or not I need to unlink the relationship before I relink it. For now I'll assume that I don't need to; though it may need a new thread to discuss the implications). Now, suppose I run a simulation where I single step the DFD. One of the processes will be executed before the other (if there are no sequential constraints then there are no restrictions on the order). Initially, the value of the referential attribute is "1": my B is linked to instance "1" of A and instance "1" of C. I will use accessor processes to get references to instances "2" of A and C. I now execute the "(refB, refA2) | link R1" statement. In your post, you agreed that relationships are defined by the value of referential attributes; and that the link statement will, from the perspective of OOA (not the implementation), set the value of the referential attribute. So the value of the referential attribute is now "2". Given that relationships are defined by their formalising attributes; then, if the value of the referential attribute is "2", which instance of C is currently related to B via R2? Does the subsequent "(refB, refC2) | link R2" do anything? Would I get different simulation results if I omitted it? You either break the referential attributes (if the relationship is not defined by the value); or you are requiring the "link R1" process to link R2 as a side effect (if the relationship is defined by the value). Personally, I do not link either of these alternatives. Dave. Not speaking for GPS. -- Dave Whipp, Embedded Systems Group GEC Plessey Semiconductors, Plymouth, United Kingdom. PL6 7BQ. tel. +44 (0)1752 693277 mailto:david.whipp@gpsemi.com fax. +44 (0)1752 693306 http://www.gpsemi.com Subject: (SMU) SMALL: link/unlink "Greg Wiley" writes to shlaer-mellor-users: -------------------------------------------------------------------- The method does not preclude us from defining new accessor forms in addition to those listed in OOA96. What if we think of link and unlink as accessor forms? Does that change the discussion? Am I just stating the obvious? -greg Subject: Re: (SMU) SMALL: link/unlink peterf@pathfindersol.com (Peter J. Fontana) writes to shlaer-mellor-users: -------------------------------------------------------------------- At 08:58 AM 12/30/97 -0800, shlaer-mellor-users@projtech.com wrote: >"Greg Wiley" writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >The method does not preclude us from defining >new accessor forms in addition to those listed >in OOA96. What if we think of link and unlink >as accessor forms? Does that change the >discussion? Am I just stating the obvious? True, the method does not explicitly preculde extensions. HOWEVER as a practical matter, extensions without editor, translator, and architecture support are just handwaving, so typically extensions usually lead to non-trivial investments. An extension to the "analysis concept space" of the method should capture information not already captured throug existing abstractions. I believe link and unlink are redundant with the "regular" write accessor for referential attributes. To the extent you wish to protest that link and unlink have some greater significance than Write (perhaps an architectural significance - ?), then I will counter that you just left the realm of "Analysis" - welcome to "Implementation". A second issue with link&unlink/vs/Write is analysis consistency: in the absence of the link brothers, Write is a very straightforward operation, with no opportunity to shoot yourself in the foot (regarding formalization). However, when link and unlink are separated out, the use of Write requires care - the analyst must manually ensure the appropriate links and unlinks are called. Of course having link and unlink can make the architecture somwhat simpler, but there are many things that fall into that category, like banning non-arbitrary identifiers. ____________________________________________________ Pathfinder Solutions Inc. www.pathfindersol.com | 888-OOA-PATH | | effective solutions for OOA/RD challenges | | Peter Fontana voice: +01 508-384-1392 | peterf@pathfindersol.com fax: +01 508-384-7906 | ____________________________________________________|