<map version="0.8.1">
<!-- To view this file, download free mind mapping software FreeMind from http://freemind.sourceforge.net -->
<node CREATED="1265207333742" ID="Freemind_Link_1857286280" MODIFIED="1266252636234" TEXT="Aspect Context Assumption">
<node CREATED="1265207396801" ID="_" MODIFIED="1266251883774" POSITION="left" TEXT="Sources" VSHIFT="1">
<node COLOR="#ff0000" CREATED="1265207402660" ID="Freemind_Link_369631007" MODIFIED="1265207555480" TEXT="HW Data Collection, version of 2010.02.03"/>
<node COLOR="#00b000" CREATED="1265207416300" ID="Freemind_Link_57661579" MODIFIED="1265207615226" TEXT="MobileMedia Data Collection, version of 2010.01.18"/>
<node COLOR="#0000ff" CREATED="1268055162767" ID="Freemind_Link_1997153748" MODIFIED="1268055229352" TEXT="Glassbox Data Collection, version of 2010.03.04"/>
</node>
<node CREATED="1266938858264" ID="Freemind_Link_1047869480" MODIFIED="1266938885042" POSITION="right" TEXT="Aspect-Aspect Coordination">
<node CREATED="1266233036083" FOLDED="true" ID="Freemind_Link_1954892058" MODIFIED="1266233042191" TEXT="Inter-Aspect Assumptions">
<node CREATED="1265211984847" FOLDED="true" ID="Freemind_Link_1392248305" MODIFIED="1265211992048" TEXT="Assumptions on Aspect Deployment">
<node CREATED="1266250126161" FOLDED="true" ID="Freemind_Link_1378329638" MODIFIED="1266250139669" TEXT="Inclusion requirement between aspect (one aspect needs another one)">
<node CREATED="1268061469676" FOLDED="true" ID="Freemind_Link_678345129" MODIFIED="1268061621525" TEXT="General">
<node COLOR="#00b000" CREATED="1266244179913" ID="Freemind_Link_500378683" MODIFIED="1266246362699" TEXT="&lt;html&gt;&lt;h4&gt;l.m.alternative.video.VideoNotPhotoNotMusic.aj; 20--23&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes that some instance of AbstractVideoAspect has also been deployed.&lt;p&gt;Otherwise, it would need to extend that aspect.&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266243640176" ID="Freemind_Link_199747736" MODIFIED="1266244131883" TEXT="&lt;html&gt;&lt;h4&gt;l.m.alternative.photoMusic.PhotoAndMusicAspect.aj; 38--64&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes that MusicSelector and PhotoSelector have also been deployed, but VideoSelector apparently has not.&lt;p&gt;Otherwise, I would assume this code should also invoke stuff from VideoSelector.  Really, of course, the&lt;br&gt;assumption is not on a particular aspect deployment, but on the presence of particular methods.&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266246248608" ID="Freemind_Link_694467145" MODIFIED="1266246362746" TEXT="&lt;html&gt;&lt;h4&gt;l.m.optional.copy.CopyMultiMediaAspect.aj; 46--48&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes CopyAspect to also be deployed.&lt;p&gt;Not so exciting here, as the two aspects at least reside in the same package.&lt;/html&gt;"/>
</node>
<node CREATED="1268061477769" FOLDED="true" ID="Freemind_Link_695754564" MODIFIED="1268061501358" TEXT="Use of external marker interfaces">
<node COLOR="#0000ff" CREATED="1268055464901" ID="Freemind_Link_114897716" MODIFIED="1268058433155" TEXT="&lt;html&gt;&lt;h4&gt;g.monitor.resource.BerkeleyDbMonitor.aj; 14--16; 18--20; 22--24&lt;br&gt;g.monitor.resource.BerkeleyXmlDbMonitor.aj; 32--34; 36--38; 40--41&lt;br&gt;g.monitor.resource.CommonsHttpMonitor.aj; 18--24&lt;br&gt;g.monitor.resource.JdbcMonitor.aj; 35--52&lt;br&gt;g.monitor.ui.ServletRequestMonitor.aj; 70&lt;/h4&gt;Interpretation of Code&lt;p&gt;Assumes implementing MonitoredType will ensure Glassbox is started when an instance of this type is created.&lt;p&gt;This assumes bootstrap/glassbox.config.AutoInitialization.aj to be deployed&lt;/html&gt;"/>
</node>
<node CREATED="1266233638907" ID="Freemind_Link_942659219" MODIFIED="1276683755947" TEXT="Feature Interaction Resolution">
<node CREATED="1268061573768" FOLDED="true" ID="Freemind_Link_459783554" MODIFIED="1268061617510" TEXT="General">
<node COLOR="#ff0000" CREATED="1265208256203" ID="Freemind_Link_829270319" MODIFIED="1265209144618" TEXT="&lt;html&gt;&lt;h4&gt;hw.a.concurrency.HWTimeStamp.aj; 159--163&lt;/h4&gt;Comment&lt;p&gt;This advice is needed because of distribution.&lt;br&gt;When the client side makes an update, the server side complaint is updated, but the client side is not.&lt;br&gt;Thus, we need also to update the client side object (hence the cflow) and increment it.&lt;br&gt;Note that this was not needed before the Observer pattern, because we would update the object just once per request.&lt;br&gt;Now we update it more than once and this synchronization is needed.&lt;p&gt;This really shows that the advice above was making additional assumptions about its usage context, namely that each&lt;br&gt;complaint record&apos;s timestamp would only be incremented once per request regardless of how many individual updates&lt;br&gt;to the record this request entailed.&lt;br&gt;This issue was caught manually and a fix was implemented for a special situation.&lt;br&gt;The new assumption is now that each complaint record&apos;s timestamp is only modified once per request, except&lt;br&gt;where the record is involved in an observer pattern (where the timestamp will be incremented once per update of the record).&lt;/html&gt;"/>
</node>
<node CREATED="1268061579282" FOLDED="true" ID="Freemind_Link_1569487297" MODIFIED="1268061584360" TEXT="Shared marker interfaces">
<node COLOR="#0000ff" CREATED="1268055507598" ID="Freemind_Link_1293026043" MODIFIED="1268058405568" TEXT="&lt;html&gt;&lt;h4&gt;g.monitor.resource.BerkeleyDbMonitor.aj; 14--16; 18--20; 22--24&lt;br&gt;g.monitor.resource.BerkeleyXmlDbMonitor.aj; 32--34; 36--38; 40--41&lt;br&gt;g.monitor.resource.CommonsHttpMonitor.aj; 18--24&lt;br&gt;g.monitor.resource.JdbcMonitor.aj; 35--52&lt;br&gt;g.monitor.ui.ServletRequestMonitor.aj; 70&lt;/h4&gt;Comment; Interpretation of Code&lt;p&gt;Assumes MonitoredType will be used as a marker interface by LogManagement.aj to switch off logging, if logging is deployed.&lt;p&gt;This is an interesting assumption, because a marker interface that has been defined explicitly for one aspect is implicitly used&lt;br&gt;by another aspect. However, given the specific comment &apos;/*don&apos;t manage logging for this*/&apos; in BerkeleyDbMonitor, this is an&lt;br&gt;assumption explicitly made rather than something that happens and that the base code (i.e., this aspect) can be oblivious of.&lt;/html&gt;"/>
</node>
<node CREATED="1266234142552" FOLDED="true" ID="Freemind_Link_478688548" MODIFIED="1269619771720" TEXT="Assumptions about where other aspects are woven">
<node COLOR="#ff0000" CREATED="1265210196360" ID="Freemind_Link_31538073" MODIFIED="1265210580495" TEXT="&lt;html&gt;&lt;h4&gt;hw.a.exceptionHandling.HWUpdateObserverExceptionHandler.aj; 60--72&lt;/h4&gt;Comment&lt;p&gt;Note that this aspect needs a lot of knowledge about how the observer pattern affects the application and how the application should deal with its exceptions.&lt;p&gt;Comments Phil:&lt;ul&gt;&lt;li&gt;Pointcut only addresses updates. This is so, because the observer pattern is only applied to update calls, too.&lt;/li&gt;&lt;li&gt;Assumes requests are handled in HTML (returning error messages wrapped in an HTTP die()). This has been created against the command pattern,&lt;br&gt;but still makes strong assumptions about this being implemented based on servlets. See above for problems with this.&lt;/li&gt;&lt;/ul&gt;&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266246162897" ID="Freemind_Link_1460289485" MODIFIED="1266246362746" TEXT="&lt;html&gt;&lt;h4&gt;l.m.optional.copy.CopyAspect.aj; 36--41&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes that PhotoViewController is an appropriate controller for implementing&lt;br&gt;copying and will not be advised by other aspects to change this behaviour.&lt;/html&gt;"/>
</node>
</node>
</node>
<node CREATED="1265212396975" FOLDED="true" ID="Freemind_Link_1347328038" MODIFIED="1265212418720" TEXT="Mutual Exclusion between aspects">
<node CREATED="1265212419595" FOLDED="true" ID="Freemind_Link_201332044" MODIFIED="1265212433591" TEXT="Exactly one of the aspects has to be deployed">
<node COLOR="#ff0000" CREATED="1265208032739" ID="Freemind_Link_1282563255" MODIFIED="1265209144633" TEXT="&lt;html&gt;&lt;h4&gt;hw.a.concurrency.HWLocalSynchronzation.aj, hw.a.concurrency.HWManagedSynchronization.aj&lt;/h4&gt;Interview Phil Greenwood&lt;p&gt;The system assumes either one of these two aspects to be deployed.&lt;br&gt;HWLocalSynchronisation is related to the in-memory implementation of data storage&lt;br&gt;whereas HWManagedSynchronisation is related to the database-based implementation of data storage. &lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266243640176" ID="Freemind_Link_1762762188" MODIFIED="1266244131883" TEXT="&lt;html&gt;&lt;h4&gt;l.m.alternative.photoMusic.PhotoAndMusicAspect.aj; 38--64&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes that MusicSelector and PhotoSelector have also been deployed, but VideoSelector apparently has not.&lt;p&gt;Otherwise, I would assume this code should also invoke stuff from VideoSelector.  Really, of course, the&lt;br&gt;assumption is not on a particular aspect deployment, but on the presence of particular methods.&lt;/html&gt;"/>
</node>
<node CREATED="1265212556985" ID="Freemind_Link_941717460" MODIFIED="1265212566951" TEXT="At most one aspect has to be deployed">
<node CREATED="1268061626134" FOLDED="true" ID="Freemind_Link_1184501681" MODIFIED="1268061628540" TEXT="General">
<node COLOR="#ff0000" CREATED="1265210997846" ID="Freemind_Link_1352617548" MODIFIED="1265212690395" TEXT="&lt;html&gt;&lt;h4&gt;hw.a.patterns.UpdateStateObserver.aj; 24--28&lt;/h4&gt;Interpretation of the code&lt;p&gt;Together with the way the subjectChange pointcut is phrased (namely that it mentions&lt;br&gt;Subject+.set* instead of referring to the classes directly) this makes an assumption&lt;br&gt;that no other code in the system uses the ObserverProtocol aspect and makes other classes implement Subject.&lt;p&gt;This may be a lesser problem, as the advise on Lines 30--32 probably ensures that the subject--observer bindings&lt;br&gt;are still set up reasonably, but there may be circumstances where this leads to problems. In any case, the&lt;br&gt;assumption is not made explicit.   Really, I would probably classify this as a programming error or bad smell at least,&lt;br&gt;as the proper thing to do would probably be to create a protected sub-interface of Subject and use this in the declare&lt;br&gt;parents code.&lt;br&gt; Comment Phil: There is an assumption here, but it is very much implicit.&lt;/html&gt;" VSHIFT="-1"/>
</node>
<node CREATED="1265212660558" FOLDED="true" ID="Freemind_Link_1068481461" MODIFIED="1265212681819" TEXT="Mutual exclusion of subaspects of a common abstract aspect">
<node COLOR="#ff0000" CREATED="1265208693536" ID="Freemind_Link_610436118" MODIFIED="1265209144586" TEXT="&lt;html&gt;&lt;h4&gt;hw.a.distribution.RMIClientDistribution.aj; 20&lt;/h4&gt;Comment; Interpretation of the code&lt;p&gt;From the comment, this seems to assume that RMIClientDistribution is the only specialisation of HWClientDistribution&lt;br&gt;(otherwise it should be within(RMIClientDistribution+) rather than within(HWClientDistribution+).&lt;p&gt;Comments Phil:&lt;ul&gt;&lt;li&gt;RMIException is RMI specific, so would probably not occur in other subaspects anyway&lt;/li&gt;&lt;li&gt;Even though this has been structured in super- and sub-aspects, there always was an assumption that only RMI would actually be implemented&lt;/li&gt;&lt;li&gt;Even if more than one sub-aspect were to be implemented, the assumption always was that only one of them would be deployed at the same time.&lt;/ul&gt;&lt;/html&gt;"/>
</node>
</node>
</node>
<node CREATED="1265212447526" FOLDED="true" ID="Freemind_Link_1586016162" MODIFIED="1276612553450" TEXT="Mandatory Aspect Assumption">
<node COLOR="#ff0000" CREATED="1265210277337" ID="Freemind_Link_383746164" MODIFIED="1265210580511" TEXT="&lt;html&gt;&lt;h4&gt;hw.a.logging.HWLogging.aj; 49--52&lt;/h4&gt;Interpretation of the code&lt;p&gt;Assumes that in any run of the system, either a new HealthWatcherFacade instance is created or a servlet class is initialised.&lt;br&gt;These are cross-assumptions on the existence and weaving of other aspects (e.g., HWServerDistribution).&lt;p&gt;Really, this seems to be a stupid aspect that would much better be implemented by modifying LogMechanism and setting the default value for logFile to Constants.LOG_PATH.&lt;br&gt;Not sure why this wasn&apos;t done in this manner.&lt;/html&gt;"/>
</node>
</node>
<node CREATED="1265212287453" ID="Freemind_Link_283950887" MODIFIED="1276612676448" TEXT="Assumptions on ITDs">
<node CREATED="1266249371581" FOLDED="true" ID="Freemind_Link_725768711" MODIFIED="1276693078997" TEXT="Assumptions on ITD provision">
<node COLOR="#00b000" CREATED="1266235320142" ID="Freemind_Link_891815977" MODIFIED="1266235754385" TEXT="&lt;html&gt;&lt;h4&gt;l.m.alternative.PhotoSelector.aj; 25--38&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes presence of imageController declaration and that it has been set appropriately before this advice is invoked.&lt;p&gt;This is an inter-aspect dependency: It assumes that l.m.alternative.TwoAlternativeFeatures and&lt;br&gt;l.m.alternative.PhotoAndMusicAndVideo or PhotoAndMusicAspect have been deployed. &lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266235004703" ID="Freemind_Link_1930741580" MODIFIED="1266235126208" TEXT="&lt;html&gt;&lt;h4&gt;l.m.alternative.PhotoAndMusicAndVideo.aj; 26--57&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes intertype declarations from a number of other aspects.&lt;p&gt;MusicSelector, PhotoSelector, VideoSelector, but also some others yet to be determined.&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266235497127" ID="Freemind_Link_1278798007" MODIFIED="1266235754401" TEXT="&lt;html&gt;&lt;h4&gt;l.m.alternative.PhotoSelector.aj; 25--38&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes imageAlbumData has been declared and set appropriately.&lt;p&gt;This is an inter-aspect dependency: It assumes that l.m.alternative.TwoAlternativeFeatures&lt;br&gt;and either l.m.alternative.PhotoAndMusicAndVideo or l.m.alternative.photoMusic.PhotoAndMusicAspect&lt;br&gt;have been deployed, as they are setting the value in after advice for the startApp pointcut.&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266246901671" ID="Freemind_Link_1843565357" MODIFIED="1266247286926" TEXT="&lt;html&gt;&lt;h4&gt;l.m.optional.sms.SMSAspect.aj; 23--25&lt;/h4&gt;Interpretation of the Code&lt;p&gt;SmSOrCapturePhoto assumes this method is there.&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266246959120" ID="Freemind_Link_1938893987" MODIFIED="1266247286926" TEXT="&lt;html&gt;&lt;h4&gt;l.m.optional.sms.SMSAspect.aj; 27--29&lt;/h4&gt;Interpretation of the Code&lt;p&gt;SMSReceiverController assumes this method is there.&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266247076797" ID="Freemind_Link_160852949" MODIFIED="1266247286926" TEXT="&lt;html&gt;&lt;h4&gt;l.m.optional.sms.SMSAspect.aj; 47--49&lt;/h4&gt;Interpretation of the Code&lt;p&gt;SMSReceiverController assumes this method is there.&lt;/html&gt;"/>
</node>
<node CREATED="1266249347948" FOLDED="true" ID="Freemind_Link_1951951326" MODIFIED="1276693132259" TEXT="Assumptions on ITD use">
<node COLOR="#ff0000" CREATED="1265210350252" ID="Freemind_Link_595153511" MODIFIED="1265212265209" TEXT="&lt;html&gt;&lt;h4&gt;hw.a.patterns.RepositoryFactory.aj; 26--35&lt;/h4&gt;Interpretation of the code&lt;p&gt;Assumes that all code will use the getRepositoryFactory() method of AbstractRepositoryFactory to access specific repository factories.&lt;br&gt;This seems to imply that all relevant code is aware of the presence of this aspect, as the method isn&apos;t actually in the interface of AbstractRepositoryFactory.&lt;p&gt;The key thing seems to be the implication this has for code using the abstract factories, namely that such code is aware of the presence of this aspect&lt;br&gt;and the opportunity of (and need for) calling getRepositoryFactory.&lt;br&gt;At the very least, there is an assumption about layering here that should be documented in the code.&lt;br&gt;Comment Phil: This seems to be a general problem with ITDs. Maybe the solution here is really to provide better tooling,&lt;br&gt;that can check for the presence of such methods etc. dynamically during development.&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266234647719" ID="Freemind_Link_1620292626" MODIFIED="1266235126224" TEXT="&lt;html&gt;&lt;h4&gt;l.m.alternative.MusicSelector.aj; 49--62&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes setMusicController/setMusicAlbumData have been invoked on controller from outside this aspect.&lt;p&gt;This is an inter-aspect dependency: It assumes that either&lt;br&gt;l.m.alternative.PhotoAndMusicAndVideo or l.m.alternative.photoMusic.PhotoAndMusicAspect&lt;br&gt;have been deployed, as they are setting the value in after advice for the startApp pointcut.&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266243053979" ID="Freemind_Link_1457918283" MODIFIED="1266244131712" TEXT="&lt;html&gt;&lt;h4&gt;l.m.alternative.musicvideo.MusicOrVideo.aj; 17--32&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes that some other code will know of these introductions and use them appropriately.&lt;p&gt;Such dependencies between aspects will of course be checked by seeing that if some code&lt;br&gt;calls these methods this aspect must be deployed. However, this particular aspect doesn&apos;t add&lt;br&gt;anything to the system&apos;s behaviour unless its introductions are invoked somewhere else, as it&lt;br&gt;doesn&apos;t actually use them in any way anywhere else. So, assuming that developers do not&lt;br&gt;intentionally produce dead code, this makes an assumption on other code. In this case, this&lt;br&gt;seems to assume that the aspect is deployed together with MusicMediaAccessor. An error in the&lt;br&gt;implementation of MusicMediaAccessor seems to be that it doesn&apos;t actually use the constants&lt;br&gt;defined in the aspect, but instead adds the strings directly.&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266246225869" ID="Freemind_Link_1710625844" MODIFIED="1266246362746" TEXT="&lt;html&gt;&lt;h4&gt;l.m.optional.copy.CopyAspect.aj; 53--74&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Again, an inverse assumption: Code that invokes this method (which is not&lt;br&gt;invoked from CopyAspect!) assumes CopyAspect has been deployed.&lt;/html&gt;"/>
<node COLOR="#0000ff" CREATED="1268058781848" ID="Freemind_Link_1682563993" MODIFIED="1268058811499" TEXT="&lt;html&gt;&lt;h4&gt;g.util.logging.api.LogManagement.aj; 65--136&lt;/h4&gt;Interpretation of Code&lt;p&gt;Expects base code to be aware of this aspect so that it knows it can call these ITDs.&lt;/html&gt;"/>
</node>
</node>
<node CREATED="1265212770973" ID="Freemind_Link_967849173" MODIFIED="1265212778315" TEXT="Assumptions on Super-Aspect Structure">
<node COLOR="#000000" CREATED="1268059119147" FOLDED="true" ID="Freemind_Link_15699949" MODIFIED="1276613055753" TEXT="Assumptions on the semantics of abstract pointcuts introduced in the super-aspect ">
<node CREATED="1268059651209" FOLDED="true" ID="Freemind_Link_1980515781" MODIFIED="1268059663832" TEXT="Semantics of individual pointcut">
<node COLOR="#ff0000" CREATED="1265210629038" ID="Freemind_Link_115913217" MODIFIED="1265211431370" TEXT="&lt;html&gt;&lt;h4&gt;hw.a.patterns.ServletCommanding.aj; 182&lt;/h4&gt;Interpretation of the code&lt;p&gt;Assumes the presence of the (apparently unrelated) pointcut on lines 159--162 and advice&lt;br&gt;in the super aspect CommandProtocol dealing with this pointcut and executing a particular&lt;br&gt;command. Furthermore, assumes that the advise in CommandProtocol will be executed after&lt;br&gt;commandTrigger, because the information about which command to invoke will only be available&lt;br&gt;after the call to setCommand.&lt;p&gt;This seems a very roundabout way of doing things. It would have been easier not to refer&lt;br&gt;back to the abstract aspect for CommandProtocol and to implement command invocation on&lt;br&gt;Line 182 directly rather than using this indirect call.&lt;br&gt;Comment Phil: This is an interesting assumption. However, all the assumptions are essentially true by construction.&lt;br&gt;Still, it may help to have explicit documentation of these assumptions.&lt;/html&gt;"/>
<node COLOR="#0000ff" CREATED="1268059061782" ID="Freemind_Link_990401481" MODIFIED="1268059079982" TEXT="toplevelPoint()">
<node COLOR="#0000ff" CREATED="1268056601305" ID="Freemind_Link_106903355" MODIFIED="1268059106852" TEXT="&lt;html&gt;&lt;h4&gt;g.monitor.resource.EjbOperationMonitor.aj; 24&lt;/h4&gt;Interpretation of Code&lt;p&gt;Assumes request enabling is required at this level.&lt;p&gt;This is both an assumption on the behaviour of topLevelPoint in the super aspect&lt;br&gt;and on the control flow in the base that implies that this is the right point to do this.&lt;/html&gt;" VSHIFT="1"/>
<node COLOR="#0000ff" CREATED="1268058463945" ID="Freemind_Link_1467230442" MODIFIED="1268058817576" TEXT="&lt;html&gt;&lt;h4&gt;g.monitor.ui.ServletRequestMonitor.aj; 76&lt;/h4&gt;Interpretation of Code&lt;p&gt;Assumes all points measured also are top-level entry points&lt;/html&gt;"/>
</node>
<node COLOR="#0000ff" CREATED="1268056698976" ID="Freemind_Link_1256440022" MODIFIED="1268059046051" TEXT="&lt;html&gt;&lt;h4&gt;g.monitor.resource.EmailMonitor.aj; 16--17&lt;br&gt;g.monitor.resource.JaxmMonitor.aj; 19&lt;br&gt;g.monitor.resource.JndiMonitor.aj; 30--31&lt;br&gt;g.monitor.resource.JxtaSocketMonitor.aj; 22--23&lt;br&gt;g.monitor.resource.AbstractFtpMonitor.aj; 19--20&lt;/h4&gt;Interpretation of Code&lt;p&gt;Assumes that monitorPoint() defines points to be monitored using a response structure.&lt;p&gt;An assumption on the super aspect.&lt;/html&gt;"/>
<node COLOR="#0000ff" CREATED="1268056743188" ID="Freemind_Link_1798481489" MODIFIED="1268057927138" TEXT="&lt;html&gt;&lt;h4&gt;g.monitor.resource.JakartaFtpMonitor.aj; 13--18&lt;/h4&gt;Interpretation of Code&lt;p&gt;Assumes defining this pointcut will define a monitor point&lt;p&gt;An assumption on the super aspect.&lt;/html&gt;"/>
<node COLOR="#0000ff" CREATED="1268057817503" ID="Freemind_Link_1834634727" MODIFIED="1268057927123" TEXT="&lt;html&gt;&lt;h4&gt;g.monitor.resource.JxtaOperationMonitor.aj; 11--12&lt;/h4&gt;Interpretation of Code&lt;p&gt;Assumes super aspect will use classControllerExecTarget&lt;/html&gt;"/>
<node COLOR="#0000ff" CREATED="1268058091860" ID="Freemind_Link_1226777265" MODIFIED="1268058811468" TEXT="&lt;html&gt;&lt;h4&gt;g.monitor.resource.LogMonitor.aj; 18&lt;/h4&gt;Interpretation of Code&lt;p&gt;Assumes that monitoredPublicMethods() defines methods to be monitored.&lt;/html&gt;"/>
<node COLOR="#0000ff" CREATED="1268058529805" ID="Freemind_Link_464176415" MODIFIED="1268058811468" TEXT="&lt;html&gt;&lt;h4&gt;g.monitor.ui.SpringMvcRequestMonitor.aj; 32--33; 41--42&lt;br&gt;g.monitor.ui.StrutsRequestMonitor.aj; 45--49&lt;br&gt;g.monitor.ui.TemplateOperationMonitor.aj; 23--24; 28--29&lt;/h4&gt;Interpretation of Code&lt;p&gt;Assumes setting these pointcuts will lead to desirable logging&lt;p&gt;An assumption on the super aspect. &lt;/html&gt;"/>
</node>
<node CREATED="1268059664207" FOLDED="true" ID="Freemind_Link_722919770" MODIFIED="1268059672581" TEXT="Semantics of relations between pointcuts">
<node COLOR="#0000ff" CREATED="1268055964504" ID="Freemind_Link_850283330" MODIFIED="1268056506883" TEXT="Correctly closing monitor responses">
<node COLOR="#0000ff" CREATED="1268055606870" ID="Freemind_Link_61360069" MODIFIED="1268056506915" TEXT="&lt;html&gt;&lt;h4&gt;g.monitor.resource.BerkeleyDbMonitor.aj; 51--53; 55--59; 61--63; with 46--47&lt;/h4&gt;Interpretation of Code&lt;p&gt;Assumes that monitorEnd() is advised to endNormally/endException for the current response created via createResponse&lt;p&gt;This doesn&apos;t use the monitorStart()/monitorPoint() abstract pointcuts defined in the super aspect, because they have bundled all handling of BerkeleyDB stuff into one aspect.&lt;/html&gt;"/>
<node COLOR="#0000ff" CREATED="1268055804591" ID="Freemind_Link_1502950686" MODIFIED="1268056506915" TEXT="&lt;html&gt;&lt;h4&gt;g.monitor.resource.BerkeleyXmlDbMonitor.aj; 94--100; 108--114; 122--134; 150--154; 156--172&lt;/h4&gt;Interpretation of Code&lt;p&gt;Assumes that monitorEnd() is advised to endNormally/endException for the current response created via createResponse&lt;p&gt;This doesn&apos;t use the monitorStart()/monitorPoint() abstract pointcuts defined in the super aspect, because they have&lt;br&gt;bundled all handling of BerkeleyXmlDB stuff into one aspect.  Particularly interesting for the advice on lines 156--172, as this&lt;br&gt;actually doesn&apos;t create a response for every join point. Some interesting use of if-pointcut in the definition of monitorEnd here!&lt;/html&gt;"/>
<node COLOR="#0000ff" CREATED="1268055938543" ID="Freemind_Link_1835907188" MODIFIED="1268056506899" TEXT="&lt;html&gt;&lt;h4&gt;g.monitor.resource.BufferFlushMonitor.aj; 23--25&lt;/h4&gt;Interpretation of Code&lt;p&gt;Assumes super aspect to endNormally/endException after monitorEnd&lt;p&gt;This might be a bit nitpicky. However, it still is an assumption on how the super-aspect works.&lt;/html&gt;"/>
<node COLOR="#0000ff" CREATED="1268056143031" ID="Freemind_Link_1480941173" MODIFIED="1268056506883" TEXT="&lt;html&gt;&lt;h4&gt;g.monitor.resource.CommonsHttpMonitor.aj; 44--56&lt;/h4&gt;Interpretation of Code&lt;p&gt;Assumes all responses thus opened will be closed correctly by the advice for monitorEnd.&lt;br&gt;In particular, here this seems to assume that executeOnMethod1 and executeOnMethod2 are a&lt;br&gt;complete decomposition of executeOnMethod.&lt;p&gt;Interesting: This could have been made safe by simply removing the explicit advice and renaming&lt;br&gt;monitorEnd into monitorPoint (providing the parameters and using executeOnMethod1 and&lt;br&gt;executeOnMethod2 explicitly). Has this not been done because the implementor of&lt;br&gt;CommonsHttpMonitor didn&apos;t know this was an option? Or is there another reason?&lt;/html&gt;"/>
<node COLOR="#0000ff" CREATED="1268056434146" ID="Freemind_Link_934232319" MODIFIED="1268056506883" TEXT="&lt;html&gt;&lt;h4&gt;g.monitor.resource.EjbCallMonitor.aj; 36--50&lt;/h4&gt;Interpretation of Code&lt;p&gt;Assumes all responses thus opened will be closed correctly by the advice for monitorEnd.&lt;p&gt;This is essentially the case. monitorEnd() adds &apos;&amp;&amp; this(Object)&apos;, which excludes static&lt;br&gt;calls, similarly, the two before advices include this(ejb) which excludes static calls.&lt;/html&gt;"/>
<node COLOR="#0000ff" CREATED="1268056548439" ID="Freemind_Link_1367358967" MODIFIED="1268057927169" TEXT="&lt;html&gt;&lt;h4&gt;g.monitor.resource.EjbOperationMonitor.aj; 32--38&lt;/h4&gt;Interpretation of Code&lt;p&gt;Assumes all responses thus opened will be closed correctly by the advice for monitorEnd.&lt;/html&gt;"/>
<node COLOR="#0000ff" CREATED="1268056780901" ID="Freemind_Link_458255385" MODIFIED="1268057927169" TEXT="&lt;html&gt;&lt;h4&gt;g.monitor.resource.JakartaFtpMonitor.aj; 24--26&lt;/h4&gt;Interpretation of Code&lt;p&gt;Assumes openConnection will appropriately be used to close responses as well.&lt;/html&gt;"/>
<node COLOR="#0000ff" CREATED="1268057738448" ID="Freemind_Link_1919054162" MODIFIED="1268058516042" TEXT="&lt;html&gt;&lt;h4&gt;g.monitor.resource.JdbcMonitor.aj; 153--215&lt;br&gt;g.monitor.resource.SftpMonitor.aj; 17--19&lt;br&gt;g.monitor.ui.DwrMonitor.aj; 41--47&lt;br&gt;g.monitor.ui.MvcFrameworkMonitor.aj; 53--63&lt;br&gt;g.monitor.ui.PortletMonitor.aj; 24--34&lt;br&gt;g.monitor.ui.ServletRequestMonitor.aj; 78--85; 107--139&lt;/h4&gt;Interpretation of Code&lt;p&gt;Assumes all responses thus opened will also be closed by the super aspect again.&lt;/html&gt;"/>
<node COLOR="#0000ff" CREATED="1268058139500" ID="Freemind_Link_1668655685" MODIFIED="1268058824809" TEXT="&lt;html&gt;&lt;h4&gt;g.monitor.resource.RemoteCallMonitor.aj; 37--41&lt;br&gt;g.monitor.ui.GwtMonitor.aj; 28--34&lt;/h4&gt;Interpretation of Code&lt;p&gt;Assumes all responses thus opened will also be closed by the super aspect again.&lt;p&gt;Interesting case, because monitorEnd potentially matches more joinpoints as it also includes static calls.&lt;/html&gt;"/>
</node>
</node>
<node CREATED="1268059573004" FOLDED="true" ID="Freemind_Link_712443601" MODIFIED="1268059611107" TEXT="Handling of parameters from abstract pointcuts">
<node COLOR="#0000ff" CREATED="1268055419469" ID="Freemind_Link_1444902813" MODIFIED="1268058080177" TEXT="&lt;html&gt;&lt;h4&gt;g.monitor.resource.AbstractFtpMonitor.aj; 22--24&lt;br&gt;g.monitor.resource.JaxmMonitor.aj; 21--23&lt;br&gt;g.monitor.resource.JxtaSocketMonitor.aj; 37--43&lt;/h4&gt;Interpretation of Code&lt;p&gt;Assumes the argument of monitorPoint() will be passed on to getKey()&lt;/html&gt;"/>
</node>
</node>
<node CREATED="1268061636101" FOLDED="true" ID="Freemind_Link_433359143" MODIFIED="1268233338407" TEXT="Assumptions on concretisation of pointcuts by super-aspect">
<node COLOR="#0000ff" CREATED="1268056816880" ID="Freemind_Link_1644612053" MODIFIED="1268058289893" TEXT="&lt;html&gt;&lt;h4&gt;g.monitor.resource.JakartaFtpMonitor.aj; 28&lt;br&gt;g.monitor.resource.SftpMonitor.aj; 17--21&lt;/h4&gt;Interpretation of Code&lt;p&gt;Assumes the super aspect uses monitorPoint rather than monitorStart/monitorEnd to define points to be monitored.&lt;/html&gt;"/>
</node>
</node>
<node CREATED="1266249742078" FOLDED="true" ID="Freemind_Link_1699336637" MODIFIED="1276613311106" TEXT="Assumptions on Sub-Aspect Structure (Pointcut contracts)">
<node CREATED="1266249754776" ID="Freemind_Link_1478141335" MODIFIED="1268059431576" TEXT="Semantics of pointcut parameters" VSHIFT="2">
<node COLOR="#00b000" CREATED="1266236376997" ID="Freemind_Link_1487239615" MODIFIED="1266236453688" TEXT="&lt;html&gt;&lt;h4&gt;l.m.alternative.music.optional.CopyAndMusic.aj; 21--22&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Not an assumption here, but one for CopyMultiMediaAspect: This pointcut refines&lt;br&gt;the pointcut there, so we should be able to express some more assumptions about&lt;br&gt;the pointcut in CopyMultiMediaAspect already (e.g., the assumption about the meaning of the return value).&lt;/html&gt;"/>
</node>
<node CREATED="1268059434153" ID="Freemind_Link_860888011" MODIFIED="1268059446261" TEXT="Match-up and Nesting properties">
<node COLOR="#0000ff" CREATED="1268058670324" ID="Freemind_Link_583473962" MODIFIED="1268058811483" TEXT="&lt;html&gt;&lt;h4&gt;g.monitor.AbstractMonitor.aj; 33--35; 44--50&lt;/h4&gt;Interpretation of Code&lt;p&gt;Assumes monitorBegin() and monitorEnd() are matched up so that as many Resources&lt;br&gt;are created as are removed within one control flow. Also assumes that this match up leads to correct nesting.&lt;p&gt;There&apos;s some rudimentary checking takes place in AbstractMonitorClass.getValidResponse,&lt;br&gt;but it doesn&apos;t actually enforce proper nesting completely.&lt;/html&gt;"/>
</node>
</node>
<node CREATED="1266233150005" FOLDED="true" ID="Freemind_Link_650862195" MODIFIED="1269858345018" TEXT="Precedence Assumptions">
<node COLOR="#ff0000" CREATED="1265209303149" ID="Freemind_Link_1852071805" MODIFIED="1265210580448" TEXT="&lt;html&gt;&lt;h4&gt;hw.a.exceptionHandling.ExceptionHandlingPrecedence.aj; 44&lt;/h4&gt;Interpretation of the code&lt;p&gt;Assumes that there are no precedence conflicts other than with ServletCommanding.&lt;p&gt;I guess, this probably doesn&apos;t need any additional code, just checking that indeed there are none.&lt;/html&gt;"/>
<node COLOR="#0000ff" CREATED="1268057871622" ID="Freemind_Link_280977345" MODIFIED="1268057927123" TEXT="&lt;html&gt;&lt;h4&gt;g.monitor.resource.JxtaSocketMonitor.aj; 25--31&lt;/h4&gt;Interpretation of Code&lt;p&gt;Assumes JxtaSocketMonitor has precedence over AbstractMonitor (otherwise the implementation of getKey would not work)&lt;p&gt;Note that this is standard AspectJ semantics, so the real assumption here is that this precedence relations is not changed&lt;br&gt;by any other aspect through an explicit declare precedence.&lt;/html&gt;"/>
</node>
</node>
<node CREATED="1266249608061" FOLDED="true" ID="Freemind_Link_872021237" MODIFIED="1266249613700" TEXT="Inter-Advice Assumptions">
<node CREATED="1266249615090" FOLDED="true" ID="Freemind_Link_701520418" MODIFIED="1276613505414" TEXT="&quot;Wormhole&quot; assumptions">
<node COLOR="#00b000" CREATED="1266236084580" ID="Freemind_Link_1257175785" MODIFIED="1266236453703" TEXT="&lt;html&gt;&lt;h4&gt;l.m.alternative.music.MusicAspect.aj; 116&lt;/h4&gt;Comment&lt;p&gt;The comment states &quot;This should be the return value from method handleCommandAction.&quot; indicating&lt;br&gt;that the developers didn&apos;t quite see how they could express this in their aspect. They could have used&lt;br&gt;two coordinated advices that hand the return value over appropriately based on the assumption&lt;br&gt;that the value is not changed in between. This assumption is what I find interesting about this example.&lt;p&gt;Note, there is another issue about the duplication of exception handlers here. I believe, they&lt;br&gt;could have avoided that by listing these exceptions as to be thrown by the advice, thus&lt;br&gt;effectively placing an assumption on the weaving context that the exception would be handled there.&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266246281718" ID="Freemind_Link_977841828" MODIFIED="1266246362746" TEXT="&lt;html&gt;&lt;h4&gt;l.m.optional.copy.CopyMultiMediaAspect.aj; 55-57&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes that mediaName is not changed between invocation of this advice and of the advice on lines 61--116.&lt;p&gt;Not a problem for a single-threaded phone application, but will become problematic in a multi-threaded environment.&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266246652963" ID="Freemind_Link_505748834" MODIFIED="1266246836195" TEXT="&lt;html&gt;&lt;h4&gt;l.m.optional.favourites.FavouritesAspect.aj; 40--76&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes (on line 69) that favorite will be maintained appropriately per controller instance.&lt;p&gt;This works for single-threaded phone applications, but may become problematic with&lt;br&gt;multi-threaded contexts.  Actually, there seem to also be a few typos in the ITDs dealing with favorite.&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266247311683" ID="Freemind_Link_17524114" MODIFIED="1266247442216" TEXT="&lt;html&gt;&lt;h4&gt;l.m.optional.sorting.SortingAspect.aj; 65--83&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes (on line 76) that sort will be maintained appropriately per controller instance.&lt;p&gt;A potential for issues in synchronisation.&lt;/html&gt;"/>
</node>
<node CREATED="1266249817989" FOLDED="true" ID="Freemind_Link_1662619117" MODIFIED="1276613521116" TEXT="Assumptions on sequential execution of advice">
<node COLOR="#00b000" CREATED="1266235159322" ID="Freemind_Link_1938343551" MODIFIED="1266235296619" TEXT="&lt;html&gt;&lt;h4&gt;l.m.alternative.PhotoAndMusicAndVideo.aj; 65--76&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes that the advice after startApp is always executed before this advice in any run of the application.&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266243787791" ID="Freemind_Link_1441980930" MODIFIED="1266244131883" TEXT="&lt;html&gt;&lt;h4&gt;l.m.alternative.photoMusic.PhotoAndMusicAspect.aj; 72--83&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes setMainMenu has been invoked from somewhere before.&lt;p&gt;This is satisfied because setMainMenu is invoked from within this aspect.&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266245720872" FOLDED="true" ID="Freemind_Link_93407587" MODIFIED="1266250824844" TEXT="Command Presence">
<node COLOR="#00b000" CREATED="1266243325854" ID="Freemind_Link_606730298" MODIFIED="1266244131727" TEXT="&lt;html&gt;&lt;h4&gt;l.m.alternative.photo.PhotoAspect.aj; 56--72&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes a command labeled &apos;View&apos; has been added to the list of available commands.&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266235857492" ID="Freemind_Link_110967057" MODIFIED="1266236453719" TEXT="&lt;html&gt;&lt;h4&gt;l.m.alternative.music.MusicAspect.aj; 64--78&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes that the &apos;Play&apos; command has been added to the menu; that is that the advise at lines 156--161 and 167--171 has been run.&lt;p&gt;This seems an interesting form of cross-dependency. Formally expressing this as an LTL formula requiring that we have passed that&lt;br&gt;other advice before entering this advice doesn&apos;t make sense (it would be almost vacously true as there is no other way this advice&lt;br&gt;could ever be entered). Instead, it requires that for at least one object that has been associated with this advice, we have&lt;br&gt;previously registered the play command.  NEEDS MORE THOUGHT&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266243939617" ID="Freemind_Link_910459088" MODIFIED="1266244131883" TEXT="&lt;html&gt;&lt;h4&gt;l.m.alternative.video.VideoAspect.aj; 56--71&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes that the &apos;Play Video&apos; command has been added to the menu;&lt;br&gt;that is that the advise at lines 110--115 and 120--124 has been run.&lt;p&gt;This seems an interesting form of cross-dependency. Formally expressing&lt;br&gt;this as an LTL formula requiring that we have passed that other advice&lt;br&gt;before entering this advice doesn&apos;t make sense (it would be almost vacously&lt;br&gt;true as there is no other way this advice could ever be entered). Instead, it&lt;br&gt;requires that for at least one object that has been associated with this advice,&lt;br&gt;we have previously registered the play command.  NEEDS MORE THOUGHT&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266245473907" ID="Freemind_Link_1604341374" MODIFIED="1266246384394" TEXT="&lt;html&gt;&lt;h4&gt;l.m.optional.capturephoto.CapturePhotoAspect.aj; 23--42&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes that the &apos;Capture Photo&apos; command has been added to the menu, that is that the advise at lines 134--139 has been run.&lt;p&gt;This seems an interesting form of cross-dependency. Formally expressing this as an LTL formula requiring that we have passed&lt;br&gt;that other advice before entering this advice doesn&apos;t make sense (it would be almost vacously true as there is no other way this&lt;br&gt;advice could ever be entered). Instead, it requires that for at least one object that has been associated with this advice, we have&lt;br&gt;previously registered the play command.  NEEDS MORE THOUGHT&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266245620093" ID="Freemind_Link_1709343111" MODIFIED="1266246384394" TEXT="&lt;html&gt;&lt;h4&gt;l.m.optional.capturephoto.CapturePhotoAspect.aj; 59--73&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes that the &apos;Take Photo&apos; command has been added to the menu; that is that the advise at lines 84--90 has been run.&lt;p&gt;This seems an interesting form of cross-dependency. Formally expressing this as an LTL formula requiring that we have passed&lt;br&gt;that other advice before entering this advice doesn&apos;t make sense (it would be almost vacously true as there is no other way this&lt;br&gt;advice could ever be entered). Instead, it requires that for at least one object that has been associated with this advice, we have&lt;br&gt;previously registered the play command.  NEEDS MORE THOUGHT&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266246064551" ID="Freemind_Link_1049035263" MODIFIED="1266246384394" TEXT="&lt;html&gt;&lt;h4&gt;l.m.optional.capturevideo.CaptureVideoAspect.aj; 87--101&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes that the &apos;Capture Video&apos; command has been added to the menu, that is that the advise at lines 74--79 has been run.&lt;p&gt;This seems an interesting form of cross-dependency. Formally expressing this as an LTL formula requiring that we have passed&lt;br&gt;that other advice before entering this advice doesn&apos;t make sense (it would be almost vacously true as there is no other way this&lt;br&gt;advice could ever be entered). Instead, it requires that for at least one object that has been associated with this advice, we have&lt;br&gt;previously registered the play command.  NEEDS MORE THOUGHT&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266246560936" ID="Freemind_Link_13298914" MODIFIED="1266247261763" TEXT="&lt;html&gt;&lt;h4&gt;l.m.optional.favourites.FavouritesAspect.aj; 40--76&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes that the &apos;Set Favorite&apos; and &apos;View Favorites&apos; commands have been added to the menu; that is that the advice on lines 144--148 hs been run.&lt;p&gt;This seems an interesting form of cross-dependency. Formally expressing this as an LTL formula requiring that we have passed&lt;br&gt;that other advice before entering this advice doesn&apos;t make sense (it would be almost vacously true as there is no other way this&lt;br&gt;advice could ever be entered). Instead, it requires that for at least one object that has been associated with this advice, we have&lt;br&gt;previously registered the play command.  NEEDS MORE THOUGHT&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266247171654" ID="Freemind_Link_292869862" MODIFIED="1266247261763" TEXT="&lt;html&gt;&lt;h4&gt;l.m.optional.sorting.SortingAspect.aj; 65--83&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes that the &apos;Sort by View&apos; command has been added to the menu; that is that the advice on lines 171--174 has been run.&lt;p&gt;This seems an interesting form of cross-dependency. Formally expressing this as an LTL formula requiring that we have passed&lt;br&gt;that other advice before entering this advice doesn&apos;t make sense (it would be almost vacously true as there is no other way this&lt;br&gt;advice could ever be entered). Instead, it requires that for at least one object that has been associated with this advice, we have&lt;br&gt;previously registered the play command.  NEEDS MORE THOUGHT&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266246460631" ID="Freemind_Link_1567879080" MODIFIED="1266246836195" TEXT="&lt;html&gt;&lt;h4&gt;l.m.optional.copy.CopyMultiMediaAspect.aj; 61--116&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes that the &apos;Copy&apos; and &apos;Save Item&apos; commands have been added to the menu.&lt;p&gt;This is an interesting variant of the theme: The two commands are not introduced within this aspect, but otherwise. &lt;/html&gt;"/>
</node>
</node>
</node>
<node CREATED="1266233591129" FOLDED="true" ID="Freemind_Link_690235531" MODIFIED="1268218966993" TEXT="Interprocessual Aspect Interaction Assumptions">
<node CREATED="1266249119636" ID="Freemind_Link_1028041059" MODIFIED="1266249132210" TEXT="Interprocessual Deployment Assumptions">
<node CREATED="1266233748926" FOLDED="true" ID="Freemind_Link_1858288676" MODIFIED="1266233751831" TEXT="Distribution">
<node COLOR="#ff0000" CREATED="1265209058485" ID="Freemind_Link_533374917" MODIFIED="1265209144571" TEXT="&lt;html&gt;&lt;h4&gt;hw.a.distribution.RMIClientDistribution.aj; 30--51&lt;/h4&gt;Interpretation of the code&lt;p&gt;This assumes a remote server to be bound to &quot;//&quot; + healthwatcher.Constants.SERVER_NAME + &quot;/&quot; + healthwatcher.Constants.SYSTEM_NAME&lt;p&gt;This implies an assumption that a corresponding aspect (RMIServerDistribution) will be woven into the system on the server side that&lt;br&gt;appropriately binds the name to a server instance before this lookup is evaluated.&lt;br&gt;So, in a way this is a constraint about the collaboration of two aspects (or rather, two separate pieces of advice) in a system.&lt;/html&gt;"/>
<node COLOR="#ff0000" CREATED="1265208560033" ID="Freemind_Link_1840974220" MODIFIED="1265209144602" TEXT="&lt;html&gt;&lt;h4&gt;hw.a.distribution.HWServerDistribution.aj; 21&lt;/h4&gt;Comment; Interpretation of the code&lt;p&gt;Also, seems to assume that these only need to be made serialisable on the server side.&lt;br&gt;However, this could also be an error in my interpretation: From the comment: &quot;makes model classes serializable (actually this is also needed in the client)&quot;.&lt;br&gt;Hence, it seems that this aspect is actually also meant to be woven into the client code, even though this is not strictly necessary.&lt;br&gt;The assumptions about which part of the code this is to be woven into are not made explicit.&lt;p&gt;This assumption assumes that this aspect will only be woven for the server code.&lt;br&gt;Looking at build.xml (and the comment above) I&apos;m not sure this is actually the case.&lt;br&gt;Need to check with developers. If it isn&apos;t the case it is somewhat unclean in the separation of concerns as the server aspect also contains client concerns.&lt;br&gt;Comment Phil: This aspect is deployed both on the client and the server. This is a bit unclean. It implies an assumption about deployment of aspects.&lt;/html&gt;"/>
</node>
<node CREATED="1266249138239" FOLDED="true" ID="Freemind_Link_112439273" MODIFIED="1266249148127" TEXT="Serial Invocations of the Same Application">
<node COLOR="#00b000" CREATED="1266246747976" ID="Freemind_Link_1032404535" MODIFIED="1266246845020" TEXT="&lt;html&gt;&lt;h4&gt;l.m.optional.favourites.FavouritesAspect.aj; 144--148&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes l.m.optional.favourites.PersisteFavoritesAspect.aj has been deployed&lt;br&gt;also and has been used for serialising the media data read.&lt;p&gt;An interesting assumption as it may span a number of runs of the application.&lt;/html&gt;">
<edge WIDTH="thin"/>
</node>
</node>
</node>
<node CREATED="1266249004348" ID="Freemind_Link_345556488" MODIFIED="1268238841598" TEXT="Interprocessual Precedence Assumptions">
<node COLOR="#00b000" CREATED="1266247386845" ID="Freemind_Link_144794337" MODIFIED="1266247442216" TEXT="&lt;html&gt;&lt;h4&gt;l.m.optional.sorting.SortingAspect.aj&#x9;; 183--201;  209--215&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Makes an assumption about correct relative ordering of serialising and deserialising aspects.&lt;p&gt;An interesting assumption as it may span a number of runs of the application. Different from the case above,&lt;br&gt;however, here the code for serialising and deserialising is in the same aspect, which may make ordering quite difficult.&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266246854813" ID="Freemind_Link_1979685383" MODIFIED="1266247286942" TEXT="&lt;html&gt;&lt;h4&gt;l.m.optional.favourites.PersisteFavoritesAspect.aj; 22--32&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Relies on consistent aspect ordering between aspects serialising and deserialising media data.&lt;p&gt;Otherwise, fields added by other aspects might be mistaken for fields added by this aspect, as&lt;br&gt;they are only referenced by their relative order.&lt;/html&gt;"/>
</node>
</node>
</node>
<node CREATED="1266938886495" ID="Freemind_Link_505416848" MODIFIED="1266938891854" POSITION="right" TEXT="Aspect-Base Coordination">
<node CREATED="1265211449940" FOLDED="true" ID="Freemind_Link_449069500" MODIFIED="1265211457399" TEXT="Synchronisation Assumptions">
<node CREATED="1265211660978" ID="Freemind_Link_1303518917" MODIFIED="1276769310856" TEXT="Weaving Context Ensures Synchronisation">
<node CREATED="1265211697183" FOLDED="true" ID="Freemind_Link_1683274175" MODIFIED="1265211713877" TEXT="Advice only called once in an application">
<node COLOR="#ff0000" CREATED="1265211246144" ID="Freemind_Link_1344440970" MODIFIED="1265211431402" TEXT="&lt;html&gt;&lt;h4&gt;hw.a.persistence.HWPersistence.aj; 61--62&lt;/h4&gt;Interpretation of the code&lt;p&gt;This seems to make the assumption that HealthWatcherFacade.new is invoked only once&lt;br&gt;&#xa;in an application or if not it is at least invoked in separate critical sections appropriately mutexed.&lt;p&gt;&#xa;If this is not true, there is a danger of creating a connection in the persistence mechanism that is never actually used due to a race condition.&lt;br&gt;Comment Phil: This seems to be an explicit assumption, as HWFacade 47--52 is synchronised and HWFacade is a singleton.&lt;/html&gt;"/>
<node COLOR="#ff0000" CREATED="1265210466038" ID="Freemind_Link_1858234125" MODIFIED="1265210580527" TEXT="&lt;html&gt;&lt;h4&gt;hw.a.patterns.ServletCommanding.aj; 105--140&lt;/h4&gt;Interpretation of the code&lt;p&gt;Assumes HWServlet is only initialised once (as this is a singleton aspect and commandTable is a member of the aspect).&lt;p&gt;Note that the servlet specification doesn&apos;t actually state that this is the case. Servlet engines are free to maintain pools of&lt;br&gt;servlets or even instantiate a new servlet for every connection. This implies the servlet engine would invoke init() multiple times.&lt;br&gt;Of course, this is not a big problem, all that happens is that unneeded objects are instantiated, but it is still a potential waste of resources. &lt;/html&gt;"/>
</node>
<node CREATED="1265211726604" FOLDED="true" ID="Freemind_Link_640052176" MODIFIED="1265211758507" TEXT="Advice invoked only by one thread at a time">
<node COLOR="#ff0000" CREATED="1265210828596" ID="Freemind_Link_1081158481" MODIFIED="1265211431386" TEXT="&lt;html&gt;&lt;h4&gt;hw.a.patterns.ServletCommanding.aj; 172--183&lt;/h4&gt;Interpretation of the code&lt;p&gt;This code is a critical section (threads potentially share and co-modify the command object).&lt;br&gt;It is not appropriately guarded here, so it makes strong assumptions about the weaving context to be appropriately synchronised.&lt;p&gt;In fact, if I understand the servlet specification correctly, there is no such guarantee, so this could actually lead to a race condition&lt;br&gt;when two clients send the same command to the server at the same time. With a bit of bad luck in code interleaving, in such a&lt;br&gt;situation the response to one of the clients could be based (completely or partially) on the request data from the other client.&lt;br&gt;If the command servlets themselves are programmed badly, this may even lead to data corruption.&lt;/html&gt;"/>
</node>
<node CREATED="1265211775122" FOLDED="true" ID="Freemind_Link_1768248294" MODIFIED="1265211843520" TEXT="Advice only invoked only once in a thread until some &#xa;other advice has been invoked in the same thread&#xa;(lock/unlock pairing)">
<node COLOR="#ff0000" CREATED="1265207913500" ID="Freemind_Link_1725283783" MODIFIED="1265209179317" TEXT="&lt;html&gt;&lt;h4&gt;hw.a.concurrency.HWManagedSynchronization.aj; 25--30, 32--37&lt;/h4&gt; Interpretation of the code&lt;p&gt;ConcurrencyManager does not perform any analysis of why a certain key is in the keys database.&lt;br&gt;As a consequence, there is an assumption in this advice combination that there is never an attempt to lock the&lt;br&gt;same key twice within the same cflow (as in lock(k), lock(k), unlock(k), unlock(k)).&lt;br&gt;Doing so would lead to deadlock on the second lock(k).&lt;p&gt;This is not a problem for the aspect in its current context as it only applies to three &apos;insert&apos; operations and we can,&lt;br&gt;thus, make sure through inspection of these three operations that this will never be invoked in a nested fashion.&lt;br&gt;However, as soon as the implementation of these functions is touched, we would need to establish this again.&lt;br&gt;Comment Phil: This was not an explicit assumption, but should have been.&lt;br&gt;The developers could have used cflowbelow constructs to avoid this causing any trouble.&lt;html&gt;"/>
</node>
<node COLOR="#ff0000" CREATED="1265207655223" ID="Freemind_Link_1980750486" MODIFIED="1265207890705" TEXT="&lt;html&gt;&#xa;  &lt;h4&gt;hw.a.concurrency.HWLocalSynchronzation.aj; 18--22&lt;/h4&gt;&#xa;  Interpretation of the code&#xa;  &lt;p&gt;&#xa;  The advise assumes all methods (including non-public) in all classes implementing the SynchronizedClasses tagger need to be synchronized.&#xa;  &lt;p&gt;&#xa;Comment Phil: This uses a slight underspecification, assuming it is not going to do any harm.&#xa;&lt;/html&gt;"/>
</node>
<node CREATED="1265211906249" ID="Freemind_Link_1355684909" MODIFIED="1265211919476" TEXT="Assumptions about what needs to be synchronised"/>
<node CREATED="1265211931297" ID="Freemind_Link_14163711" MODIFIED="1265211939495" TEXT="Assumptions about who could share monitors">
<node COLOR="#ff0000" CREATED="1265207762496" ID="Freemind_Link_1528145117" MODIFIED="1265207890720" TEXT="&lt;html&gt;&lt;h4&gt;hw.a.concurrency.HWLocalSynchronzation.aj; 18--22&lt;/h4&gt; Interpretation of the code&lt;p&gt;The advise assumes that synchronisation has to happen on the target object of the call itself rather than on a separate monitor.&lt;br&gt;This implies that other threads may also synchronise on the same monitor introducing additional mutexes or potentially even deadlocks.&lt;p&gt;Check if this has ever been discussed. Phil: Not sure if it has. However, it is likely. In any case, it is an assumption made by the system. &lt;/html&gt;"/>
</node>
</node>
<node CREATED="1266233213316" FOLDED="true" ID="Freemind_Link_1910012998" MODIFIED="1266233220236" TEXT="Architectural Assumptions on the Base">
<node CREATED="1266233523078" ID="Freemind_Link_695688167" MODIFIED="1266233529294" TEXT="Well encapsulated communication">
<node CREATED="1266233333659" FOLDED="true" ID="Freemind_Link_1533505863" MODIFIED="1266233346077" TEXT="Layered Base with Pivotal Communication Point">
<node COLOR="#ff0000" CREATED="1265208443966" ID="Freemind_Link_1809904587" MODIFIED="1265209144618" TEXT="&lt;html&gt;&lt;h4&gt;hw.a.distribution.HWClientDistribution.aj; 21&lt;/h4&gt;Interpretation of the code&lt;p&gt;Assumes that all communication between client and server always happens through an IFacade instance.&lt;br&gt;This is an architectural rule that is not made explicit in the code.&lt;/html&gt; "/>
<node COLOR="#ff0000" CREATED="1265209353488" ID="Freemind_Link_1859076356" MODIFIED="1265210580464" TEXT="&lt;html&gt;&lt;h4&gt;hw.a.exceptionHandling.HWDistributionExceptionHandler.aj; 25--48&lt;br&gt;hw.a.exceptionHandling.HWPersistenceExceptionHandler.aj; 40--58&lt;br&gt;hw.a.exceptionHandling.HWTransactionExceptionHandler.aj; 24--41&lt;/h4&gt;Interpretation of the code&lt;p&gt;Assumes that all HW servlets are subclasses of HWServlet; that is, no user interaction happens through any other channel.&lt;p&gt;Comment Phil: This is a very dangerous assumption!&lt;br&gt;Actually, one of the first changes introduced into HW was the command pattern.&lt;br&gt;The purpose of this was to decouple HW from its UI, so that it could be used with something other than servlets.&lt;br&gt;No other UI has ever actually been implemented, but if it had been, this assumption here would have broken immediately. &lt;/html&gt;"/>
<node COLOR="#ff0000" CREATED="1265210196360" ID="Freemind_Link_647651208" MODIFIED="1265210580495" TEXT="&lt;html&gt;&lt;h4&gt;hw.a.exceptionHandling.HWUpdateObserverExceptionHandler.aj; 60--72&lt;/h4&gt;Comment&lt;p&gt;Note that this aspect needs a lot of knowledge about how the observer pattern affects the application and how the application should deal with its exceptions.&lt;p&gt;Comments Phil:&lt;ul&gt;&lt;li&gt;Pointcut only addresses updates. This is so, because the observer pattern is only applied to update calls, too.&lt;/li&gt;&lt;li&gt;Assumes requests are handled in HTML (returning error messages wrapped in an HTTP die()). This has been created against the command pattern,&lt;br&gt;but still makes strong assumptions about this being implemented based on servlets. See above for problems with this.&lt;/li&gt;&lt;/ul&gt;&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266234470032" ID="Freemind_Link_321494081" MODIFIED="1266247141446" TEXT="&lt;html&gt;&lt;h4&gt;l.m.alternative.MusicSelector.aj; 49--62&lt;br&gt;l.m.alternative.PhotoSelector.aj; 25--38&lt;br&gt;l.m.alternative.music.MusicAspect.aj; 64--78&lt;br&gt;l.m.alternative.photo.PhotoAspect.aj; 56--72&lt;br&gt;l.m.alternative.video.VideoAspect.aj; 56--71&lt;br&gt;l.m.optional.capturephoto.CapturePhotoAspect.aj; 23--42&lt;br&gt;l.m.optional.capturephoto.CapturePhotoAspect.aj; 59--73&lt;br&gt;l.m.optional.capturevideo.CaptureVideoAspect.aj; 87--101&lt;br&gt;l.m.optional.copy.CopyMultiMediaAspect.aj; 61--116&lt;br&gt;l.m.optional.favourites.FavouritesAspect.aj; 40--76&lt;br&gt;l.m.optional.sorting.SortingAspect.aj; 65--83&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes all user interaction is treated by handleCommandAction.&lt;p&gt;This may be encoded in the architecture, but is certainly not clarified as a dependency for this advice. &lt;/html&gt;"/>
</node>
<node CREATED="1266233533605" FOLDED="true" ID="Freemind_Link_1446478082" MODIFIED="1276614670587" TEXT="Responsibility Encapsulation">
<node COLOR="#ff0000" CREATED="1265208126402" ID="Freemind_Link_234129535" MODIFIED="1265209144633" TEXT="&lt;html&gt;&lt;h4&gt;hw.a.concurrency.HWTimeStamp.aj; 41--43, 46--49, 52--93&lt;/h4&gt;Interpretation of the code&lt;p&gt;These pieces of advice assume that insert, update, and search are the only places where a complaint record is modified.&lt;br&gt;Interestingly, they do not take into consideration removal of a complaint record.&lt;br&gt;ComplaintRepositoryRDB.remove is currently implemented as an empty method, but if it were to do anything, this would probably cause a problem.&lt;p&gt;The HW Application does not allow removing complaints once registered.&lt;br&gt;Thus, there is an assumption that removal will never happen.&lt;br&gt;This is probably an unimplemented requirement, not having support for it in the aspect is part of the experimental (rather than productive) setup of the system. &lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266243576465" ID="Freemind_Link_872403254" MODIFIED="1266244131743" TEXT="&lt;html&gt;&lt;h4&gt;l.m.alternative.photo.optional.CopyAndPhoto.aj; 26--27&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes that there are no other constructors in PhotoViewScreen.&lt;/html&gt;"/>
</node>
<node COLOR="#ff0000" CREATED="1265210120414" ID="Freemind_Link_227830782" MODIFIED="1265210580495" TEXT="&lt;html&gt;&lt;h4&gt;hw.a.exceptionHandling.HWPersistenceExceptionHandler.aj; 1--173&lt;/h4&gt;Interpretation of the code&lt;p&gt;Assumes that these explicitly listed pointcuts cover all places where persistence-related exceptions are thrown in the system.&lt;/html&gt;"/>
</node>
<node CREATED="1266233364259" ID="Freemind_Link_956274692" MODIFIED="1266233401045" TEXT="Well encapsulated data">
<node COLOR="#ff0000" CREATED="1265208494086" ID="Freemind_Link_677203062" MODIFIED="1265209144602" TEXT="&lt;html&gt;&lt;h4&gt;hw.a.distribution.HWServerDistribution.aj; 21&lt;/h4&gt;Interpretation of the code&lt;p&gt;Assumes that all data that is ever exchanged between server and client is implemented in classes in hw.model.*.&lt;p&gt;Comment Phil: This has been ensured by an initial refactoring of the code-base that was used to develop HW. &lt;/html&gt;"/>
</node>
</node>
<node CREATED="1266233789537" ID="Freemind_Link_65683487" MODIFIED="1276614287409" TEXT="Assumptions on particular coding patterns">
<node CREATED="1266233877427" FOLDED="true" ID="Freemind_Link_687540291" MODIFIED="1285858391667" TEXT="Assumptions on Semantic Patterns in the Base">
<node CREATED="1266233979734" FOLDED="true" ID="Freemind_Link_1868010531" MODIFIED="1266233983936" TEXT="On control flow">
<node COLOR="#ff0000" CREATED="1265209194863" ID="Freemind_Link_1003024514" MODIFIED="1265210580448" TEXT="&lt;html&gt;&lt;h4&gt;hw.a.distribution.RMIServerDistribution.aj; 20--34&lt;/h4&gt;Interpretation of the code&lt;p&gt;Assumes that serverStart matches exactly HealthWatcherFacade.getInstance() (line 23 should really be &apos;proceed()&apos;).&lt;p&gt;This may really be a bit over-exacting for this particular example, but this assumption does have the potential of breaking the encapsulation&lt;br&gt;provided by the explicit pointcut. So, as a consequence, we should be able to document what we assume about pointcuts inherited from&lt;br&gt;super-aspects or expected to be defined in sub-aspects.&lt;/html&gt;"/>
<node COLOR="#ff0000" CREATED="1265209665052" ID="Freemind_Link_1522530253" MODIFIED="1265210580480" TEXT="&lt;html&gt;&lt;h4&gt;hw.a.exceptionHandling.HWPersistenceExceptionHandler.aj; 81--102&lt;br&gt;hw.a.exceptionHandling.HWPersistenceExceptionHandler.aj; 106--124 (in analogy)&lt;/h4&gt;Interpretation of the code&lt;p&gt;Assumes&lt;ol&gt;&lt;li&gt;that ComplaintRepositoryRDB.update invokes internal_update&lt;/li&gt;&lt;li&gt;that internal_update invokes at most once Statement.executeUpdate&lt;/li&gt;&lt;li&gt;that executeUpdate does not modify the SQL query passed to it, and&lt;/li&gt;&lt;li&gt;that maintaining this query in an exception will actually have an impact on error handling.&lt;/li&gt;&lt;/ol&gt;&lt;p&gt;The final assumption is violated by the first advice in the series, as it simply replaces any such exception with a standard RepositoryException.&lt;br&gt;Comment Phil: Interestingly, Phil seemed to recall that internal_update was explicitly introduced as scaffolding for this to enable picking up some parameter values.&lt;br&gt;Further analysis of the code didn&apos;t support this, though. It remains unclear why internal_update exists at all.&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266235987591" ID="Freemind_Link_1126073542" MODIFIED="1266236453719" TEXT="&lt;html&gt;&lt;h4&gt;l.m.alternative.music.MusicAspect.aj; 85--118&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes that the Save command is indeed handled within handleCommand already and will be invoked also for musical media.&lt;p&gt;The first part can be checked by inspecting the joinpoint shadows: If there are none, then this assumption is invalid. The second&lt;br&gt;part seems more difficult. It seems again to be an assumption on the overall setup. LTL or similar can be useful here again, but&lt;br&gt;what would the appropriate state predicates be?&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266243458275" ID="Freemind_Link_1780397845" MODIFIED="1266244131727" TEXT="&lt;html&gt;&lt;h4&gt;l.m.alternative.photo.exceptionblocks.ScreensAspectEH.aj; 16--17&lt;/h4&gt;Interpretation of the Code&lt;p&gt;The fact that this doesn&apos;t select calls to loadImage, but rather selects calls&lt;br&gt;to the constructor directly encodes an assumption that loadImage is only&lt;br&gt;ever invoked from within this constructor.&lt;p&gt;I&apos;m really not quite sure why this is a useful aspect in the first place. It seems&lt;br&gt;to introduce more dependencies than it resolves.   Anyway, the only other relevant&lt;br&gt;assumption that I can identify is somewhat reversed to the other ones:&lt;br&gt;PhotoViewScreen.new makes an assumption that this aspect will be deployed&lt;br&gt;and will soften the two exceptions for this particular constructor.&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266244324041" ID="Freemind_Link_566643403" MODIFIED="1266246362715" TEXT="&lt;html&gt;&lt;h4&gt;l.m.aspects.exceptionblocks.ControllerAspectEH.aj; 27--34&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes AlbumData.deleteAlbum is only ever invoked from AlbumController.handleCommand.&lt;p&gt;Note that this could be fixed by changing the pointcut to a general call(AlbumData.deleteAlbum)&lt;br&gt;without the explicitly added withincode. Not sure I fully understand why the exception handling&lt;br&gt;performed needs to add this specific constraint. In the current code base, deleteAlbum is only ever&lt;br&gt;called from that handleCommand method anyway.  CLARIFY WITH EDUARDO (above is another similar case)&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266244401274" ID="Freemind_Link_1380260763" MODIFIED="1266246362715" TEXT="&lt;html&gt;&lt;h4&gt;l.m.aspects.exceptionblocks.DataModelAspectEH.aj; 108--116&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes MediaAccessor.loadAlbums is only ever invoked from AlbumData.getAlbumNames.&lt;p&gt;Similar to above.  Here, though it would have made sense to have a negative withincode to&lt;br&gt;exclude the case where loadAlbums is recursively invoked.  CLARIFY WITH EDUARDO&lt;p&gt;"/>
<node COLOR="#00b000" CREATED="1266244537321" ID="Freemind_Link_422940233" MODIFIED="1266246362731" TEXT="&lt;html&gt;&lt;h4&gt;l.m.aspects.exceptionblocks.UtilAspectEH.aj; 29--37&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes that internalReadMediaAsByteArray is only invoked from readMediaAsByteArray&lt;p&gt;This is probably true, as it is a private operation, but then why is the withincode clause needed in the first place?&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266244460323" ID="Freemind_Link_1228674260" MODIFIED="1266246362731" TEXT="&lt;html&gt;&lt;h4&gt;l.m.aspects.exceptionblocks.UtilAspectEH.aj; 19--21&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes that MediaUtil.readMediaAsByteArray is only used to read in images; that is, that the class is not reused for videos or music.&lt;p&gt;In fact, though, it is at least also used for music, which may lead to slightly misleading error messages.  On the other hand, the pointcut&lt;br&gt;here is a good example of where it does make sense to use withincode for an exception handling aspect: The advise handles&lt;br&gt;exceptions from Class.getResourceAsStream and, thus, does need the context to determine how to correctly interpret them.&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266246992795" ID="Freemind_Link_1774262667" MODIFIED="1266247294174" TEXT="&lt;html&gt;&lt;h4&gt;l.m.optional.sms.SMSAspect.aj; 27--29&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes the image will additionally be passed to the constructor of PhotoViewScreen in the usual manner so that it will be displayed.&lt;p&gt;An alternative would seem to be to only maintain an appropriate flag or to use loadImage to ensure the image was copied/referenced appropriately.&lt;/html&gt;"/>
<node COLOR="#ff0000" CREATED="1265209581310" ID="Freemind_Link_1053759828" MODIFIED="1265210580464" TEXT="&lt;html&gt;&lt;h4&gt;hw.a.exceptionHandling.HWPersistenceExceptionHandler.aj; 75--77&lt;/h4&gt;Interpretation of the code&lt;p&gt;Assumes that all exceptions from AddressRepositoryRDB.search are wrapped into PersistenceMechanismExceptions.&lt;p&gt;This advice seems to violate an implicit assumption of the two pieces of advice above that the message of&lt;br&gt;PersistenceMechanismExceptions will actually be maintained. Instead, they are thrown away.&lt;/html&gt;"/>
</node>
<node CREATED="1266233985154" FOLDED="true" ID="Freemind_Link_818468381" MODIFIED="1266233993292" TEXT="On data values">
<node CREATED="1268061686483" FOLDED="true" ID="Freemind_Link_766663807" MODIFIED="1268324030395" TEXT="Existence of parameter values">
<node COLOR="#ff0000" CREATED="1265210958397" ID="Freemind_Link_247329797" MODIFIED="1265211431386" TEXT="&lt;html&gt;&lt;h4&gt;hw.a.patterns.ServletCommanding.aj; 172--183&lt;/h4&gt;Interview Phil Greenwood&lt;p&gt;Also, there is an assumption about the existence of the &apos;operation&apos; parameter in the URL and that it is correct and refers to an existing command.&lt;/html&gt;"/>
</node>
<node CREATED="1266247834378" FOLDED="true" ID="Freemind_Link_1246608225" MODIFIED="1266251161588" TEXT="Control-Flow Semantics of return values">
<node COLOR="#00b000" CREATED="1266234860300" ID="Freemind_Link_692368109" MODIFIED="1266247153176" TEXT="&lt;html&gt;&lt;h4&gt;l.m.alternative.MusicSelector.aj; 49--62&lt;br&gt;l.m.alternative.PhotoSelector.aj; 25--38&lt;br&gt;l.m.alternative.music.MusicAspect.aj; 64--78&lt;br&gt;l.m.alternative.photo.PhotoAspect.aj; 56--72&lt;br&gt;l.m.alternative.video.VideoAspect.aj; 56--71&lt;br&gt;l.m.optional.capturephoto.CapturePhotoAspect.aj; 23--42&lt;br&gt;l.m.optional.capturephoto.CapturePhotoAspect.aj; 59--73&lt;br&gt;l.m.optional.capturevideo.CaptureVideoAspect.aj; 87--101&lt;br&gt;l.m.optional.copy.CopyMultiMediaAspect.aj; 61--116&lt;br&gt;l.m.optional.favourites.FavouritesAspect.aj; 40--76&lt;br&gt;l.m.optional.sorting.SortingAspect.aj; 65--83&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes that returning true will stop other potential aspects handling command.&lt;br&gt;Also assumes that other command handlers will return true when they have eaten an command.&lt;p&gt;This is a bit nitpicky. It seems a pretty standard protocol, but it is currently not&lt;br&gt;documented (only informally in l.m.core.ui.controller.ControllerInterface, but not as an assumption&lt;br&gt;of the aspect). Sometimes this sort of protocol is implemented one way (true for &apos;yes I&apos;m done&apos;),&lt;br&gt;sometimes the opposite way (true for &apos;command still up for grabs&apos;), so making this assumption&lt;br&gt;explicit should certainly help with reuse or base-code evolution.&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266235652663" ID="Freemind_Link_65504245" MODIFIED="1266235747592" TEXT="&lt;html&gt;&lt;h4&gt;l.m.alternative.VideoSelector.aj; 49--56&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes that the return value of handleCommandAction&lt;br&gt;is not important and that video selection should always take priority.&lt;p&gt;Apart from this, also makes a lot of assumptions similar to the other&lt;br&gt;XYSelector aspects above. However, this one is interesting as it is&lt;br&gt;different from the assumptions up there and it is not immediately clear why this would be so.&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266243766437" ID="Freemind_Link_1233325853" MODIFIED="1266244131883" TEXT="&lt;html&gt;&lt;h4&gt;l.m.alternative.photoMusic.PhotoAndMusicAspect.aj; 72--83&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes that returning true will stop other potential aspects handling goToPreviousScreen.&lt;br&gt;Also assumes that other handlers will return true when they have handled goToPreviousScreen.&lt;/html&gt;"/>
</node>
<node CREATED="1266251189625" FOLDED="true" ID="Freemind_Link_1730896513" MODIFIED="1266251199871" TEXT="No internal modification of parameters">
<node COLOR="#ff0000" CREATED="1265209525144" ID="Freemind_Link_1608955556" MODIFIED="1266250975066" TEXT="&lt;html&gt;&lt;h4&gt;hw.a.exceptionHandling.HWPersistenceExceptionHandler.aj; 62--73&lt;/h4&gt;Interpretation of the code&lt;p&gt;Assumes that Statement.executeQuery does not internally modify the SQL code.&lt;/html&gt;"/>
</node>
<node CREATED="1266251208961" FOLDED="true" ID="Freemind_Link_246259272" MODIFIED="1266251328151" TEXT="State of the application when advice is called">
<node CREATED="1266251329150" FOLDED="true" ID="Freemind_Link_1520378170" MODIFIED="1266251421178" TEXT="Type assumptions" VSHIFT="2">
<node COLOR="#00b000" CREATED="1266234532432" ID="Freemind_Link_970062863" MODIFIED="1266235126224" TEXT="&lt;html&gt;&lt;h4&gt;l.m.alternative.MusicSelector.aj; 49--62&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes Display.getDisplay (controller.midlet).getCurrent() returns a list,&lt;br&gt;and in particular a list that shows a selection of different media that are marked up as &apos;Music&apos; or sth else.&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266235228111" ID="Freemind_Link_1052912338" MODIFIED="1266235288075" TEXT="&lt;html&gt;&lt;h4&gt;l.m.alternative.PhotoSelector.aj; 25--38&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes Display.getDisplay (controller.midlet).getCurrent() returns a list,&lt;br&gt;and in particular a list that shows a selection of different media that are marked up as &apos;Photos&apos; or sth else.&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266243836831" ID="Freemind_Link_655711985" MODIFIED="1266244131883" TEXT="&lt;html&gt;&lt;h4&gt;l.m.alternative.video.VideoAspect.aj; 44--48&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes that if this aspect is deployed, AlbumData mediaAccessors will always be VideoMediaAccessors.&lt;p&gt;Otherwise, there should be more defensive programming that also covers other cases.&lt;/html&gt;"/>
</node>
<node CREATED="1266251579354" FOLDED="true" ID="Freemind_Link_385923461" MODIFIED="1268061889385" TEXT="LTL-like assumptions about legal operations before and after the advice has been invoked???">
<icon BUILTIN="help"/>
<node COLOR="#00b000" CREATED="1266245931052" FOLDED="true" ID="Freemind_Link_239234256" MODIFIED="1266250772037" TEXT="Screen Types">
<node COLOR="#00b000" CREATED="1266236279067" ID="Freemind_Link_737882093" MODIFIED="1266236453703" TEXT="&lt;html&gt;&lt;h4&gt;l.m.alternative.music.MusicAspect.aj; 167--171&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes that no other code introduces a screen type that has the integer value 2.&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266243397344" ID="Freemind_Link_1889876560" MODIFIED="1266244131727" TEXT="&lt;html&gt;&lt;h4&gt;l.m.alternative.photo.PhotoAspect.aj; 101--106; 112--116&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes no other code defines a screen type valued 1.&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266244142946" ID="Freemind_Link_1687965966" MODIFIED="1266246362699" TEXT="&lt;html&gt;&lt;h4&gt;l.m.alternative.video.VideoAspect.aj; 120--124&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes that no other code introduces a screen type that has the integer value 3.&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266245852322" ID="Freemind_Link_451646587" MODIFIED="1266246384238" TEXT="&lt;html&gt;&lt;h4&gt;l.m.optional.capturephoto.CapturePhotoAspect.aj; 84--90&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes no other code introduces a screen type with ordinal value 1 for CaptureVideoScreen.&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266245937798" ID="Freemind_Link_1573483732" MODIFIED="1266246384238" TEXT="&lt;html&gt;&lt;h4&gt;l.m.optional.capturevideo.CaptureVideoAspect.aj; 26--32&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes no other code introduces a screen type with ordinal value 2 for CaptureVideoScreen.&lt;/html&gt;"/>
</node>
<node COLOR="#00b000" CREATED="1266245910003" FOLDED="true" ID="Freemind_Link_641358990" MODIFIED="1266250787375" TEXT="Unique Commands">
<node COLOR="#00b000" CREATED="1266234965717" ID="Freemind_Link_792101210" MODIFIED="1266235126208" TEXT="&lt;html&gt;&lt;h4&gt;l.m.alternative.OneAlternativeFeature.aj; 18--20&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes that no other code adds an &apos;Exit&apos; command to the menu.&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266235604269" ID="Freemind_Link_308932778" MODIFIED="1266235754401" TEXT="&lt;html&gt;&lt;h4&gt;l.m.alternative.TwoAlternativeFeaturs.aj; 32--34&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes that no other code adds a &apos;Back&apos; command to the menu.&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266236250437" ID="Freemind_Link_1476771477" MODIFIED="1266236453703" TEXT="&lt;html&gt;&lt;h4&gt;l.m.alternative.music.MusicAspect.aj; 156--161&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes that no other code adds a command labelled &apos;Play&apos;.&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266243002354" ID="Freemind_Link_1358638084" MODIFIED="1266244131712" TEXT="&lt;html&gt;&lt;h4&gt;l.m.alternative.music.optional.CopyAndMusic.aj; 33--36&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes that no other code will add a &quot;Copy&quot; command.&lt;p&gt;Strangely enough, this is not inherited from CopyMultiMediaAspect, which assumes this label to be there... &lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266243359357" ID="Freemind_Link_192668371" MODIFIED="1266244131727" TEXT="&lt;html&gt;&lt;h4&gt;l.m.alternative.photo.PhotoAspect.aj; 101--106&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes no other code adds a command labelled &apos;View&apos;.&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266243608438" ID="Freemind_Link_1646148270" MODIFIED="1266244131868" TEXT="&lt;html&gt;&lt;h4&gt;l.m.alternative.photo.optional.CopyAndPhoto.aj; 29--31&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes that the constructor doesn&apos;t itself add a command named &apos;Copy&apos;.&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266244072354" ID="Freemind_Link_1521607944" MODIFIED="1266244131883" TEXT="&lt;html&gt;&lt;h4&gt;l.m.alternative.video.VideoAspect.aj; 110--115&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes that no other code adds a command labelled &apos;Play Video&apos;.&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266244240130" ID="Freemind_Link_893198506" MODIFIED="1266246362715" TEXT="&lt;html&gt;&lt;h4&gt;l.m.alternative.video.optional.CopyAndVideo.aj; 31--34&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes that no other code adds a command labelled &apos;Copy&apos;.&lt;p&gt;Implicitly assumes that l.m.alternative.photo.optional.CopyAndPhoto is not deployed.&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266245819733" ID="Freemind_Link_821975019" MODIFIED="1266246384254" TEXT="&lt;html&gt;&lt;h4&gt;l.m.optional.capturephoto.CapturePhotoAspect.aj; 84--90&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes no other code introduces a command labelled &apos;Take photo&apos;.&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266245882427" ID="Freemind_Link_1788906413" MODIFIED="1266246384254" TEXT="&lt;html&gt;&lt;h4&gt;l.m.optional.capturephoto.CapturePhotoAspect.aj; 134--139&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes no other code introduces a command labelled &apos;Capture photo&apos;.&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266245967638" ID="Freemind_Link_668248164" MODIFIED="1266246384238" TEXT="&lt;html&gt;&lt;h4&gt;l.m.optional.capturevideo.CaptureVideoAspect.aj; 74--79&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes no other code introduces a command labelled &apos;Capture Video&apos;.&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266246711942" ID="Freemind_Link_1079963938" MODIFIED="1266247271775" TEXT="&lt;html&gt;&lt;h4&gt;l.m.optional.favourites.FavouritesAspect.aj; 144--148&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes no other code introduces commands labelled &apos;Set Favorite&apos; and &apos;View Favorites&apos;.&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266247037904" ID="Freemind_Link_1647333914" MODIFIED="1266247271775" TEXT="&lt;html&gt;&lt;h4&gt;l.m.optional.sms.SMSAspect.aj; 37--39&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes no other code introduces a command labelled &apos;Send Photo by SMS&apos;.&lt;/html&gt;"/>
<node COLOR="#00b000" CREATED="1266247355215" ID="Freemind_Link_1381061749" MODIFIED="1266247450026" TEXT="&lt;html&gt;&lt;h4&gt;l.m.optional.sorting.SortingAspect.aj; 171--174&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assumes no other code introduces a command labelled &apos;Sort by Views&apos;.&lt;/html&gt;"/>
</node>
<node COLOR="#00b000" CREATED="1266236311585" ID="Freemind_Link_1843428812" MODIFIED="1266236453688" TEXT="&lt;html&gt;&lt;h4&gt;l.m.alternative.music.MusicAspect.aj; 181--184&lt;/h4&gt;Interpretation of the Code&lt;p&gt;Assunes that no other code will add a &quot;Type of media&quot; input field.&lt;p&gt;It would seem a bit odd for this to be in MusicAspect, as it certainly&lt;br&gt;also is relevant for something like video. So, conversely, there is&lt;br&gt;probably an assumption here that Video will never be used without Music?&lt;/html&gt;"/>
</node>
</node>
</node>
</node>
<node CREATED="1268061765797" FOLDED="true" ID="Freemind_Link_974643938" MODIFIED="1268061781997" TEXT="On Advice structure">
<node COLOR="#0000ff" CREATED="1268055258521" ID="Freemind_Link_262975724" MODIFIED="1268055596439" TEXT="&lt;html&gt;&lt;h4&gt;g.agent.ErrorContainment.aj; 39--48&lt;/h4&gt;AOP@Work article; Interpretation of Code&lt;p&gt;Assumes any around advice will be suitably enclosed in subaspects named &apos;*..*Around&apos; so that it will&lt;br&gt;not be matched by this pointcut.&lt;p&gt;See AOP@Work article for an explanation why we do not want to contain exceptions in around advice.&lt;/html&gt;"/>
</node>
</node>
<node CREATED="1266233905307" FOLDED="true" ID="Freemind_Link_923628315" MODIFIED="1276868056735" TEXT="Assumptions on the code called from advice">
<node COLOR="#ff0000" CREATED="1265211377129" ID="Freemind_Link_1808379710" MODIFIED="1265211431417" TEXT="&lt;html&gt;&lt;h4&gt;lib.patterns.ObserverProtocol.aj; 152--157&lt;/h4&gt;Interpretation of the code&lt;p&gt;Assumes that calls to updateObserver do not lead to calls to add/removeObserver&lt;p&gt;If they do, a ConcurrentModificationException will be thrown, so the error will be spotted at runtime.&lt;/html&gt;"/>
</node>
</node>
</node>
</map>
