Software Reengineering Assignment Decomposing ArgoUML

Transcription

1 Software Reengineering Assignment Decomposing ArgoUML Steven Aerts Bart Braem th June 00 The Assignment The assignment consists of transforming ArgoUML into a nearly decomposable system : A nearly decomposable system is a system consisting of subsystems for which the interactions among subsystems is of a different order of magnitude from that of the interactions within subsystems. The analogy with a classification is obvious if one looks upon classes as subsystems. The relevant properties are: the short-run behaviour of each of the component subsystems is approximately independent of the short-run behaviour of the other components; the long-run behaviour of each of the component subsystems depends in only an aggregate way on the behaviour of the other components. Feasibility A number of observations on ArgoUML made us decide that the proposed reengineering of ArgoUML seemed feasible: ArgoUML has numerous tests. The overall test coverage, according to Clover, is rather high:.%. The fact that ArgoUML has a GUI makes this result even better. The project structure was already fairly modular, as shown in figure. ArgoUML is well documented. The developer documentation is large and also describes architectural decisions. The ArgoUML design is clean. It uses facades, singletons,... Initial preparations for this restructuring were already in place. The directory src had been made and i8n was already extracted as a premature subsystem. Heikki Hytyniemi (ed.): Complex Systems Science on the Edge of Chaos. Helsinki University of Technology, Control Engineering Laboratory, Report, October 00.

2 Figure : Initial situation as shown in Creole.. Risk analysis Of course this project also has risks: The developer documentation reflects that the ArgoUML developers have a good understanding of software engineering in general. This implies that we had to do better, we had to improve the design. The assignment was not entirely clear to us, we had to do some research to make sure we understood it completely. The ArgoUML Ant build process is not really transparent. In fact it consists of lots of targets that seem to give the right result. We did not have any experience with Ant so this was a large risk as it is an important part of the assignment. We tried to resolve those risks: We had to deal with the fact that the maintainers already had a strong design. On the other hand: the developers wanted this redesign so it is most probably possible. As part of Chat With The Maintainers we mailed with the main developer, Linus Tolke, in order to understand the assignment and its main objectives.

3 We spent one day thoroughly studying Ant and its possibilities. As a result of this analysis we decided to go on with the project and start the restructuring of ArgoUML. Project Path. Project Plan We have not written a project plan. This is a mistake we made but we did have some reasons at the starting of the project. This is a rather small project when compared to the amount of time needed for our Master s Thesis. This meant we did not have a lot of time for it. We did however try and succeed at working on it one day every week. This is of course no guarantee for a good project result but it helps. We did know which steps we were going to follow but we did not know how far we could go. We immediately knew this project could not be finished entirely due to the limited amount of time and the large codebase (almost NCLOC). In the end we know this was not a wise decision but the project did not suffer from it. We would however make a project plan if we had to do this again.. Tests ArgoUML has a lot of UnitTests and has a nice code coverage. We also noticed the existence of GUI UnitTests, which is very nice because that s traditionally a weak point. The tests can be run fully automated from the Ant script and there even was a continuous testing facility online at Unfortunately that system stopped working at the beginning of May. There were two failing testcases in TestAgainstUmlModel in our CVS checkout. In cooperation with the ArgoUML developers we have searched for a possible fix. The fixed test case ensured that our refactorings caused absolutely no regressions.. Tools We have used the following tools to support our project... Subversion Every good software engineering project needs a good version control system. For this project we chose Subversion (svn) instead of traditional CVS for the following reasons: svn supports file moves and copies while keeping the file history, this was very important as we moved a lot of files.

4 svn increments the revision number of all files when committing, so no version management is necessary to find out which revision of one file was used in combination with a particular revision of another file. We made a lot of changes and sometimes we had to go back in history. Then the versioned repository turned out very useful, manually managing version numbers for around 00 sourcefiles is impossible... Eclipse We used Eclipse as our Java editor. ArgoUML has a proper section on how to setup Eclipse to develop ArgoUML. The built-in support for refactoring turned out to be very useful. Combined with the Subversion plug-in Subclipse moving classes to another package, updating all references and moving the files in Subversion went very fast. Again, we have moved a lot of files so this was necessary... Creole We used the Creole system to do initial analysis of possible subsystems. This is a nice tool to visually inspect Java code for high level analysis. We have some nice diagrams from the initial situation but later on the system crashed on our refactored code... Headway review While making this report we wanted to have more data on our reengineering. We discovered Headway review. This software does statical code analysis on Java code. The measurements and graphs in this document have been produced by Headway review... A weblog During a project a lot of information is gathered. We set up a blog to put all information in one place and to allow project supervisors to follow our activities. Some random thoughts but also important things to remember can be found there. The blog is still available at Elaboration. Applied patterns We have applied a number of patterns from the book Object-Oriented Reengineering Patterns. If It Ain t Broke, Don t Fix It We noticed lots of smaller problems in ArgoUML. These include: code duplication

5 obsolete classes/code aged code documentation We did not correct any of these problems as they were out of the scope of the project. Read All the Code in One Hour Our first contact with ArgoUML consisted of Read All the Code in One Hour. That did not give perfect results but it gave a nice impression. Skim the Documentation We skimmed the documentation in minutes which gave us a very well overview of the code. The high level documentation proved to be good later on. Do a Mock Installation Using a fresh CVS checkout we tried a mock installation. This failed on two missing ArgoUML modules/extensions which were then removed from the build path. We also discovered the first existing subsystem model, which did not compile. This was a good contact with the existing build files after our Ant study. Always Have a Running Version On one of our last scheduled days we decided to try applying the techniques we had developed to extract a final subsystem: cognitive. We made the move too abrupt and the resulting system broke completely. We had to revert to the older version and redo the entire extraction progressively while keeping everything running (including all tests). The previous subsystems were extracted while keeping everything running, which went a lot better of course. Regression Test after Every Change The ArgoUML testing systems is very good and helped us do regression testing after every reengineering action. Make a Bridge to the New Town We adapted the ArgoUML build scripts to have the old script use the new subsystem jars. That way all old tests kept running while testing all old and new code.. Subsystem extraction steps Most of the other reengineering patterns were not applicable. The assignment focuses on high-level reengineering, a subject that s not covered in the book nor in literature we consulted. The following is a list of techniques we have applied to get to a subsystem. Every time we try to extract a subsystem that is only dependent on the previous

6 subsystems or external libraries. The resulting directed dependency graph works perfectly for the required results. Subsystem discovery by visualization How do you know what might be a subsystem that can be extracted? Use visualization software (Creole, review,... ) to show dependencies between packages. Packages with a lot of incoming arrows and little outgoing arrows are good candidates. Candidates do not always work as their external dependencies might be difficult to resolve, e.g. the kernel package. Dependency tracking How do you know wether a candidate is viable? There are two techniques possible. First we used a nice grep command to find any imports of other ArgoUML packages: grep -Rh "import org.argo". sort -u If the resulting packages are already subsystems that is no problem for the dependencies, otherwise they have to be resolved (see below). After resolving any possible dependencies from the previous step we use refactoring in Eclipse to discover any left over dependencies. There might be dependencies left in case you are trying to move a part of a package, any dependencies on the same package are not visible in the imports. The trick we used is to move the selected classes using refactoring in Eclipse and preview the results. When looking at the files to be moved they will contain any possible necessary imports from unnoticed dependencies. Those can be resolved again. Dependency resolving using moving What if the external dependency is trivial? Sometimes the external dependency is one class with only dependencies on the current and previous subsystems or only external dependencies. In that case the dependency can be moved to the current or previous subsystems, or in case of an external dependency to external packages. In the first case the external class belongs in the subsystem, in the latter the class does not belong in the subsystem. Resolving cascading dependencies using moving What if the external dependencies are cascading? Sometimes the external dependency has other dependencies but in the end those dependencies are independent or only dependent of each other. In that case the previous technique can be applied recursively. Resolving type dependencies using type hierarchies What if the type is the only dependency? A class can be dependent of a specific type, because in that special case an action is necessary. In that case we force inheritance by replacing the dependent type by a more general type, perhaps by introducing an interface. E.g. checking wether a return value is null can happen on an Object in Java.

7 Figure : Overview of the binder construction. Resolving singleton dependencies using Binder What if the dependency is a singleton class? If everything else failed but the only dependencies left are not large and singleton classes we used our Binder construction, as shown in figure. This uses Java class loading, a technique commonly used in ArgoUML. However there it is used in all kinds of packages which blurs the overall view on the system and makes automatic refactoring hard as it would require inspecting every string that might specify a class for loading. We decided to put the class loading in one abstract class: Bindable. The main idea is that those singleton classes can be replaced by a static API that contains the singleton. The business logic can be implemented in a different package. In order to resolve their singleton instance the API extends Bindable. The API initializes the singleton by calling Bindable.getBinding with its class as argument. Bindable looks up Binder using runtime class loading and returns the result of Binder.getBinding. (To avoid having to use classloading twice, once to get the Binder class and once to get the getbinding method, Bindable calls getbinding on the BinderInterface which is implemented by Binder). Binder is on top of the dependency hierarchy and thus it can freely import all necessary classes and return the results. Iterate for next subsystem How to continue? Every time a new subsystem is created there are more classes that are moved in the right subsystem. That way after each iteration the extraction of subsystems gets easier.. Build system We have redefined the ArgoUML build system as follows. In the root there is one build.xml file which contains directives to run the tests, to compile the subsystems,... The src directory contains all subsystems and also contains 7

8 a generic build script common.xml. That contains the common instructions required to build a subsystem. Each subsystem has its own build.xml which specializes common.xml with its own dependencies such as the libraries and other subsystems required for compiling and testing the subsystem. Each subsystem makes its own jar file. By overriding the jar target it is possible for a developer to compile all jars and then work at one subsystem while using the other subsystems as jars which do not need to be recompiled. It does not even require the source code from the other subsystems. Open problems Some targets are not yet defined for the subsystems, e.g. generating Javadoc documentation and creating a signed jar do not work yet. The Ant build files in the subsystems might need more property files but it is hard to figure out where that property file belongs. Not everything is a subsystem yet... Suggestions The uml package is very large. It seems reasonable to make a few subsubsystems here, to make this more manageable. The new build process spends a lot of time checking subsystem dependencies. This could go faster when using Ant timestamps: unchanged subsystems do not have to start their compilation. There seems to be a lot of unused code, it would be good to check that (using test coverage tools) before proceeding with the restructuring. 7 Results The resulting design can be seen in figure. Note the position of Binder on top of the dependency graph and the subsystems at the bottom. 7. Subsystems We have created the following subsystems: configuration and cognitive. util, ui, ocl, model, i8n, data, 7. Metrics We have studied the following metrics of our result : Afferent Coupling (CA) is the number of other packages that depend upon classes within this package, and is an indicator of the package s responsibility. metric definitions as in the Headway review documentation 8

9 Efferent Coupling (CE) is the number of other packages that the classes in this package depend upon, and is an indicator of the package s independence. Instability (I) is defined as the ratio of efferent coupling to total coupling. This metric is an indicator of the package s resilience to change. The range for this metric is 0 to, with I=0 indicating a completely stable package and I= indicating a completely instable package. The following table shows the metrics for the final version and the difference from the initial CVS checkout, as measured by Headway review. As a reference the new subsystems are marked with a *. Package name CA CA CE CE I I org.argouml.util* org.argouml.uml org.argouml.ui* org.argouml.persistence org.argouml.ocl* org.argouml.moduleloader org.argouml.model* org.argouml.kernel org.argouml.i8n* org.argouml.configuration* org.argouml.cognitive* org.argouml.binder 0 0 org.argouml.application The Afferent Coupling of our subsystems increases slightly. Only the configuration package has a large increase because configuration is necessary in many other packages. The Efferent Coupling is of course an important metric and overall it decreases. However there are some exceptions. Binder did not exist before and now it resolves quite some dependencies. Model uses some classes which moved to the util package and Cognitive had a large dependency on ListSet, as can be seen in figure. It has been moved to the util package. It belongs there because it is only an implementation of a List and it is not really related to cognitive. Overall the instability decreases with only model and cognitive as exceptions, for reasons stated above. 8 Conclusion We have turned a system consisting of several packages into a system with packages and subsystems. The dependency graph is becoming a directed graph. Based on metrics we have shown that the restructuring worked out fine and does not affect the overall structure. We have presented techniques to continue the restructuring of ArgoUML and to transform a general Java system into a nearly decomposable system.

10 b in d e r la n g u a g e a p p lica tion p e rs is te n ce ocl 7 ke rn e l p a tte rn 7 8 cog n itive m od u le loa d e r , 0 u i 8 0, u m l 7, 7 7 con fig u ra tion m od e l 8 u til i 8 n Figure : Overview of the restructuring result at package level. Gray means unchanged, green added, red deleted and blue changed. 0

11 UMLToDoIte m De s ig n e r 7 Offe n d e r Pos te r 8 ToDoIte m 0 ToDoLis t Re s olve d Critic critics Ite m UID u i 8 8 De cis ion Mod e l Goa lmod e l Lis tse t ToDoLis tlis te n e r Un re s olva b le Exce p tion ch e cklis t De cis ion Goa l ToDoLis teve n t Tra n s la tor Ab s tra ctcog n itive Tra n s la tor Figure : Overview of the cognitive package. Gray means unchanged, green added, red deleted and blue changed.