Menu
▾
▴
Re: [Mged-mage2] RE: [Fuge-devel] FuGE Protocols
|
From: Junmin L. <ju...@pc...> - 2006-02-27 22:28:38
|
Hi, Joe, I can answer some of your concerns. > This is a good compromise on Parameter/Parameterizable. The abstract > association to Protocol will be useful. > Regarding the second diagram, GenericProtocol..., you mentioned that it would > not be legal to associate EquipmentApplication with Software. In the diagram > it looks like this is possible because of the association between the parent > classes of these 2 classes. If this is not possible, how should we associate no, by non-abstract, means the genericApp will always associate with certain type of parameterizableApp, e.g. equipmentApp, which references the equipment, not software. So basically the diagram enforces the type of parameterizableApplication which the genericProtocolApp contains to. > equipment with the software that operates it, e.g. the GCOS software for > Affymetrix array processing stations? It is done by the association between protocol and parameterizable named "protocolComponents". It is saying that one protocol will have different types of parameterizables: software, hardware and action. In your case, there will be one "Affy" protocol which contains software: "GCOS software", hardware: "Affymetrix array processing stations". Protocol/ProtocolApp are the two central piece of the diagram, many things are connected to them. ---junmin > > Andy Jones wrote: > >> Hi all, >> I've been through all the alternatives that have been suggested on the list >> and I've come up with a model that I think covers all the use cases and >> greatly simplifies the abstract Protocol package. >> The figure Protocol-27-2-06.jpg shows the abstract Protocol package. >> Protocol has an abstract association to its components (Parameterizable), >> which can be Actions, Software or Equipment. This means that it is legal >> for >> an extension developer to create associations from a subclass of Protocol >> to >> objects of this type. >> Each Parameterizable has an abstract association to Parameter. This means >> that a subclass of any of these classes is allowed to have parameters. >> >> Protocol also has an abstract association to Parameter, so an extension >> developer can give parameters that correspond to the entire Protocol. >> >> On the ProtocolApplication side, there is an exact mirror of this >> structure. >> The association from ProtocolApplication to ParameterizableApplication is >> abstract. This means that an extension developer must create specific >> associations for their subclass of ProtocolApplication, if it is allowed to >> have SoftwareApp, EquipmentApp or ActionApp. I think this is sensible >> anyway, because there is an important use case for creating subclasses of >> ParameterizableApp that do a specific job, such as referencing specific >> subclasses of ProtocolApplication. >> >> The other diagram (GenericProtocol-27-2-06.jpg) shows the GenericProtocol >> class. This is much the same as before, except that GenericAction has >> parameters but GenericProtocol does not. I realise this may not be useful >> for MAGE-simple, but I think MAGE-simple should define their own subclass >> of >> Protocol anyway, cut down to just the required associations. >> >> GenericProtocolApplication is very simple, in that it has a non-abstract >> association to ParameterizableApplication. This means that the user has to >> reference the correct Parameterizable from ParameterizableApp (i.e. it >> would >> not be illegal for an EquipmentApplication to reference a Software), but I >> think the benefit of the simpler model outweighs this downside. >> >> I think if we make these changes for FuGE milestone 3 it would be >> advantageous for the following reasons: >> >> i) The UML for Protocol is simpler to understand than before. >> ii) I think there are use cases for parameters on Actions and Protocols >> depending on the type of Protocol. >> iii) GenericProtocol does not have to cover every use case. >> iv) Allowing parameters on Actions will mean they are used more and we can >> rely less on creating sub-Protocols, which will always be difficult to use. >> v) I don't want to make major changes to this package, as we now have >> several models built on FuGE milestone 1 or 2 and it will be a lot of work >> to migrate them to a new structure. I think the proposed changes can be >> accommodated very easily in the existing models. >> >> Comments? >> >> Cheers, >> Andy >> >> >> >> >> >> >> >> >> >>> -----Original Message----- >>> From: mge...@li... [mailto:mged-mage2- >>> ad...@li...] On Behalf Of Joe White >>> Sent: 21 February 2006 15:58 >>> To: Angel Pizarro >>> Cc: mged-mage2; 'fug...@li...' >>> Subject: Re: [Mged-mage2] RE: [Fuge-devel] FuGE Protocols >>> >>> Hi Angel, >>> >>> In an alternative view of Protocol/Action, we could think of Action as >>> equivalent to a Protocol with one step. If we think of them this way, >>> then an ordered association between Protocol and itself (as you suggest) >>> means that we don't need Action at all. It also means that we might be >>> able to derive Action from Protocol; in that case, you could make a >>> single association to Parameterizable from Protocl and leave it. This >>> way if you need detailed steps, Action will do it for you, but if you >>> only need a Protocol blob, then Protocol works. In either case you >>> still use parameters because Action would inherit the association to >>> Parameterizable. >>> >>> I realize that for experiments involving HPLC or Mass Spec, etc, you >>> really do need detailed protocols with Action and Parameter objects. >>> However, many times one merely references someone else's protocol and >>> indicates an alteration. The 'proof is in the pudding' here, as Alvis >>> has pointed out; few people want to use Action and get that detailed. >>> The real question in my mind is whether detailed protocols, hence Action >>> objects, should be required or not? >>> >>> Cheers, >>> >>> Joe >>> >>> >>> >>> Angel Pizarro wrote: >>> >>> >>>> Joe White wrote: >>>> >>>> >>>>> Hi Everyone, >>>>> >>>>> I agree with Ugis. There are use cases for having parameter in both >>>>> places. In some contexts, a detailed set of actions with parameters >>>>> makes sense, but in other contexts a simple protocol with parameters >>>>> makes more sense. So why not make associations to both? >>>>> >>>> Here is a mythical case illustrating why I am hesitant (although I am >>>> ready to concede the point by now). >>>> >>>> Suppose you want to measure a dose-response curve for substance X by >>>> administering doses of 1, 10 and 100 mL to a single biosource. The >>>> encoding of a protocol could be done by using two protocols, one for >>>> the dosing procedure, and a parent for defining that you do this >>>> procedure three times at different concentrations of X. >>>> >>>> Now where does the parameter for dosage of X go? Do you put it at the >>>> Action or the child Protocol or both? In any of these cases, how do >>>> you convey the fact that the parameter and it's value are in fact >>>> related between the entities if Parameters are composite associations? >>>> >>>> The most correct (not best) solution I can think of is to make an >>>> ActionParameter class that references sub Protocol's Parameters and an >>>> overriding default value(s), but this potentially adds more verbosity >>>> to an already verbose spec. >>>> >>>> The other point that was made by Alvis & Co. is that that Action is >>>> not really used now, and may never be used, so let's just ditch it in >>>> favor of an ordered self-association for Protocols. There are plenty >>>> of other business world specs that can take care of properly defining >>>> workflows for us, such as BPEL, XPDL, etc., if there is a need for >>>> this functionality. >>>> >>>> -angel >>>> >>>> >>>>> Joe >>>>> >>>> >>>> >>>> >>>> ------------------------------------------------------- >>>> This SF.net email is sponsored by: Splunk Inc. Do you grep through log >>>> files >>>> for problems? Stop! Download the new AJAX search engine that makes >>>> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >>>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 >>>> _______________________________________________ >>>> Mged-MAGE2 mailing list >>>> Mge...@li... >>>> https://lists.sourceforge.net/lists/listinfo/mged-mage2 >>>> >>> >>> >>> ------------------------------------------------------- >>> This SF.net email is sponsored by: Splunk Inc. Do you grep through log >>> files >>> for problems? Stop! Download the new AJAX search engine that makes >>> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 >>> _______________________________________________ >>> Mged-MAGE2 mailing list >>> Mge...@li... >>> https://lists.sourceforge.net/lists/listinfo/mged-mage2 >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> ------------------------------------------------------------------------ >>> > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Mged-MAGE2 mailing list > Mge...@li... > https://lists.sourceforge.net/lists/listinfo/mged-mage2 > |