WWW/Internet - Portal do Software Público Brasileiro

IADIS International Conference WWW/Internet 2010understanding of the business and the desired granularity for Episodes as they could be found in differentlevels of the architecture.For each new requirement, a Story was created following the SCRUM methodology. When the Story wasto be programmed, developers were instructed to annotate every SystemService and Episode they would findin their way. Finding Episodes and SystemServices was not a problem, but it did not make changing thesystem any easier. On the other hand to describe a SystemService developers had define which use caseswere realized by that service, which actors used that service, and the service preconditions and postconditions, which added more difficult than just understanding and changing the code as it was done before.As more stories were developed, more SystemServices and Episodes were annotated and the fasterdevelopers could find where to change the code to implement a new Story by reading the documentationgenerated by the tool. This was easily detected by seeing how many SCRUM points were implemented ineach Sprint.6. CONCLUSIONAnnotations are a powerful tool to document and instrument code. The technique that we developed showedhow it could effectively help recovering a software requirement and mapping requirements to code. Whencompared to Jermakovics (2008) approach, this technique requires a higher manual effort on one hand, but onthe other hand can be used where no requirement documentation exists. When compared to Liu (2005)approach, this technique is much faster and more accurate however it relies on the source-code where Liuassumes that even the source-code is no longer reliable and it is a top-down black-box approach. Comparingin more generic way to other requirements reengineering techniques, there are two main approaches:• Code-parsing which is faster, but has limited use and requires some documentation, good variablenames in the source-code to be effective. Example: Jermakovics (2008);• Manually inspecting system and source-code which is slower, requires lots of hours, but can be usedin any situation. Example: Liu (2005).This technique uses the manual approach, but as it uses annotations is restricted to JAVA legacy systemsand requires a reliable source-code. As it documents the system directly in the source-code it has anadvantage over the other techniques because it can be used incrementally and simultaneously as the systemevolves.When applying the technique, we found that some modifications are necessary to make it more effective.These modifications are described in the next paragraphs and we are currently working on those issues.Actors and Use Case should be identified before making changes to the code. This may seem obvious tosomeone developing a new software, but when you are maintaining a legacy system, the Use Cases andActors may not be clear and not knowing them make it harder to annotate the SystemService.Annotation syntax as it is now does not allow defining annotation recursive reference, annotationinheritance and others, which could help to have annotations that reflect more closely the original use casemetamodel. Such deficiencies made the use case model generated by the annotated code to have someinaccuracies and inconsistencies.Among the inconsistencies, it was the decision to have the context as the union of preconditions andpostconditions defined in the SystemService. Many times, as the Use Case was realized by calling differentservices, one service postcondition was the next service precondition making both of them incorrect as a UseCase context. Having the Use Case explicitly represented in the source code and referenced by the annotationis the only solution we found so far for this problem. With the current annotation syntax this could beaccomplished by having an abstract class UseCase and implementing the use case as a regular class thatwould never get called by system.An experiment was done creating the UseCase class and it showed also that it would be very beneficial tothis technique using annotations that are processed during run-time. This would also allow to find episodesand services relations by injecting dependencies and logging code during the run-time processing of theannotations. This would also help solving another problem which was dealing with alternative flows, since asthe tool is now it can only identify which episodes are part of a service, but it can not say which ones areinside a loop or an if statement and therefore run different number of times and in different conditions.291