WWW/Internet - Portal do Software Público Brasileiro

ISBN: 978-972-8939-25-0 © 2010 IADISpublic @interface SystemService {String[] implementedUseCases();String[] actors();String description();String[] preConditions();String[] postConditions();}public @interface Episode {String name();boolean primitive() default true;}Both SystemService and Episode annotations are to be placed on methods. With those annotations we areable to reconstruct our Use Case model by recursively inspecting all methods that are called in a SystemService method we are able to find those annotated as Episodes. If the episode is primitive, the search on thatbranch may stop. Episodes composed of other Episodes can be found by search further in the method callstack.Use Case can be recovered by finding all SystemService methods that have that Use Case name in theirimplementedUseCases attribute array. The context will be the union of all contexts and so does thedescription. The actors, on the other hand, will be defined the intersection of all actors attribute array in allSystemService methods that implemented the given Use Case.5. USING THE TECHNIQUE IN A WEB-SERVICE ARCHITECTUREWeb-Services architectures are quite suitable for wrapping-up legacy systems where mosts of the problemsof missing requirements documentation happen. Each Web-Service is a strong candidate for theSystemService annotation, mapping other elements of the architecture must be done. This should occur afterthe architecture is determined by recovering legacy documentation or reverse engineering it. Whenprogramming new functionalities, changing existing functionalities or reading the code to understand it,developers should identify the architectural elements that should be annotated and place annotations on themwith information as accurate as possible. After finishing a annotation, a documentation generation tool can becalled to recover the use case model following the procedures described in the previous section.This technique was applied in a hosting managing system for an internet service provider. The systemwas developed using the JAVA language and used the whole JEE technology stack and other open-sourcetools and frameworks including: EJB, JMS, Servlets, JSP, Hibernate, Spring, Velocity, Maven, JUnit, RMIand WebServices. The use of such technologies was clearly inadequate and the system was over-engineered.Such over-engineering made the system very hard to maintain. Lack of knowledge of basic object-orientedconcepts made developers create classes with thousands lines of code and representing no entity orabstraction.The development process was mostly based on SCRUM mixed with some other concepts from other agilemethodologies. No formal requirements were kept. Unit tests were not developed as preached by suchmethodologies.As the system evolved the architecture which was not good from the beginning deteriorated very fast,making even small changes in the requirements an humongous programming task. Such problems made thissystem a perfect candidate for validating this technique. Annotations were developed and a tool to generatedocumentation from the code was implemented. The tool recovered not only the use case model, but was alsoable to tell where each service and episode could be found.At the same time, a big effort on understanding the architecture and identifying who were thearchitectural elements that should be annotated as SystemService and Episode was done. After several hoursreading lines of codes, it was easy to determine all the candidates for the SystemService annotation, but wewere unable to define a rule for annotating Episodes. Annotating Episodes had to rely on a good290