TOOLS FOR DESIGN AND DEVELOPMENT ENVIRONMENTS. Case study - ECLIPSE Lecture notes 7

Refactoring the code Refactoring = making system-wide code changes without affecting the behavior of a program. Eclipse provides an extensive list of commands that automate Java code refactoring. Ex. of refactoring operations: Moving and renaming Java elements requires changes in dependent files. Extract Interface help generalize a design in preparation for the next iteration of development.

Refactoring the code Is done in small bursts (not scheduled) when changes are needed: to make the software easier to understand and cheaper to modify; Ex. When encountered: duplicated code / large classes / long methods / tightly coupled components, etc. to add a new feature to a software; Ex. As the code grows, it may be easier to understand and extend if a package is divided into two logical units. to expose previously defined methods as part of the public API. It may be necessary to extract new interfaces from concrete class implementations. Martin Fowler describes a Rule of Three for deciding when to refactor: "The first time you do something, you just do it. The second time you do something similar, you wince at the duplication, but you do the duplicate thing anyway. The third time you do something similar, you refactor.“

Refactoring the code Refactoring -makes software easier to understand and cheaper to modify -prepares a design for the next development iteration -does not change the current behavior. Several different refactoring operations are often applied in a sequence to accomplish a complex task. For example, extracting a group of interfaces is accompanied by renaming a package, moving types, and introducing factory methods. Refactoring operations can update references to changed elements and save a large amount of time compared to performing the same changes manually. Recommendations: Run a complete JUnit test suite both before and after refactoring to determine if program's behavior is unchanged by refactoring. Commit all code to a repository before and after refactoring to establish known states for rolling back changes. Preview the results of refactoring operations to omit individual changes or cancel an entire operation that does not accomplish what you expected.

Refactoring the code Catalog of all refactoring operations available in Eclipse - categorized by common tasks during refactoring activities. Common refactoring tasks: –Composing Methods –Moving Features Between Objects –Organizing Data –Making Method Calls Simpler –Dealing with Generalization –Organizing Classes and Packages

Refactoring the code Catalog (continued) Composing Methods Aim: Composing methods to package code properly. Sugestive names to describe their separate purposes. Eclipse operations: Extract Method. 1.Turn a code selection into a new method whose name explains the purpose of the method. 2.Replace the selection with a reference to the new method. Is useful for cleaning up lengthy, cluttered, or overly complicated methods. Get a valid selection range by using the menu command Edit > Expand Selection To > Enclosing Method (or shortcut keys: Alt+Shift+Up-Arrow ). Inline Method. 1.Put the method's body into the body of its callers 2.Remove the method. When method's body is as clear as its name, or it may perform unnecessary simple delegation.

Refactoring the code Catalog (continued) Moving Features Between Objects Aim: To correct design mistakes or to reassign responsibilities when an evolving code base would be simpler with different class responsibilities. Move methods when: -classes have too much behavior, -classes are collaborating too much and are too tightly coupled, -after moving a field, if needed. Eclipse operations: Move Field. Move a field declaration from one type to another. Additional refactoring is usually required to resolve broken references to a private field. Move Method. 1.Create a new method with a similar body in the class it uses most. 2.Either turn the old method into a simple delegation or remove it altogether. Extract Class. 1.Create a new class 2.Move the relevant fields and methods from the old class into the new class. This refactoring is not included in any Eclipse menus, but it can be accomplished via a series of Move Field and Move Method refactorings.

Refactoring the code Catalog (continued) Organizing Data Aim: Organize fields, local variables, and constants in a class to make working with its data easier. Eclipse operations: Encapsulate Field. Make a field private and provide getter and setter methods. This operation includes an option that changes current field access to use the getter and setter methods. Extract Local Variable. 1.Create a new variable assigned to the selected expression 2.Replace it with a reference to the new variable. Valid selection range by using the menu command Edit > Expand Selection To > Enclosing Method. Extract Constant. 1.Create a static final field from the selected expression 2.Substitute a field reference; optionally rewrite other places where the same expression occurs. Convert Local Variable to Field. 1.Turn a local variable into a field. 2.If the variable is initialized on creation, then the operation moves the initialization to the new field's declaration or to the class's constructors. Inline Local Variable or Constant. Replace references to a local variable or static constant with the expression that is assigned to that variable or constant. Optionally remove the variable or constant declaration.

Refactoring the code Catalog (continued) Making Method Calls Simpler Aim: Help make object interfaces easier to understand and use. Rename methods with more descriptive names. Keep method's signature (name, parameters, return type, and visibility) as simple as possible without sacrificing relevant information. Eclipse operations: Rename Method. Change the name of a method. Optionally update all references to this method. Change Method Signature. 1.Change parameter names, parameter types, parameter order, or thrown exceptions 2.Update all references to the corresponding method. Parameters also can be removed or added, and the method return type or visibility can be changed. Introduce Parameter. Add a new parameter to a method signature. 1.Select an expression in the method body before starting this refactoring. 2.The containing method is given a new parameter 3.The selected expression is copied into the argument list of all the callers. Introduce Factory. 1.Replace the selected constructor with a factory method. 2.Create a new static factory method in the specified class 3. Replace all uses of the constructor with the new method.

Refactoring the code Catalog (continued) Dealing with Generalization Aim: Help to manage the inheritance hierarchy of classes and interfaces. Move methods and fields up or down the hierarchy. Create new interfaces to represent relevant subsets of behavior. Generalize type references to more abstract types. Eclipse operations: Push Down. When behavior on a superclass is relevant only for some of its subclasses. Move a set of methods and fields from a class to its subclasses. This refactoring can be applied to one or more methods and fields declared in the same type. Often used when you are extracting a new subclass. Pull Up. Eliminate duplicate behavior in two or more subclasses. -Move a field or method to a superclass of its declaring class. -Declare the method as abstract in the superclass. ( in the case of methods ) This refactoring can be applied to one or more methods, fields, and member types declared in the same type.

Refactoring the code Catalog (continued) Dealing with Generalization (continued) Eclipse operations:(continued) Extract Interface. 1.Create a new interface with a set of methods selected from a class 2.Make the selected class implement the new interface. 3.Optionally change references to the class to use the new interface wherever possible. Generalize Type. Replace a type with one of its supertypes. 1.Select a declaration of a variable, parameter, field, or method return type in the Java editor 2.The refactoring wizard shows the supertype hierarchy for the original type and updates the declaration with the selected supertype. Use Supertype Where Possible. Replace occurrences of a type with one of its supertypes after identifying all places where this replacement is possible.

Refactoring the code Catalog (continued) Organizing Classes and Packages Aim: Design for reuse and extensibility of Java libraries. Help reorganize Java packages and types and update their references. Eclipse operations: Rename Type or Package. 1.Rename a type or package. 2.Optionally modify all references to the changed element. Move Package. 1.Move one or more packages (and all of the types they contain) to a new source folder. 2.Move the underlying operating system folders and files to the new location. Move Type. -Move one or more types to a new destination package. -Move inner classes into a different class.

Refactoring the code Catalog (continued) Organizing Classes and Packages (continued) Eclipse operations: (continued) Rename Source Folder or Project. 1.Rename a source folder or project. (Does not affect Java elements directly) 2.Update project configuration properties with the new name. Move Member Type to New File. 1.Create a new Java compilation unit (file with.java extension) for the selected member type; 2.Update all references as needed. For non-static member types, a field is added to allow access to the former enclosing instance. Convert Anonymous Class to Nested. Convert an anonymous inner class to a named member class.

Continous integration Successful agile development requires that you deliver complete, tested applications at the end of an iteration. An iteration is completed in a specific time interval and often integrates the results of several small teams. Integrating one set of changes at a time makes it easy to identify problems and prevents a surprise at the end. The developers and customers working on a team keep a view of the iteration's progress. It is important to have tools that support a fast, automated build and test cycle. It is also needed a reasonably complete test suite that verifies successful integration of each new or modified component.

Continous integration Continuous integration occurs at two points in the development cycle. 1.Each developer uses Eclipse to keep his or her view of the project's code synchronized with a team repository. The automated project builders within Eclipse assist developers in performing continuous compilation and unit testing of their component. 2. A build machine is used to compile and test the application in a clean environment. Eclipse includes support for writing and running Ant build files that automate the build process. Continuous integration with a team repository

Continous integration Automatic incremental build Workspace and projects configured correctly  continuous integration is automatic and nearly instantaneous. Automatic build includes project dependencies that integrate modules from other teams. The default Java project builder compiles all code from the source folders into the output folders. The builder runs automatically whenever any source file is updated. Automatic build can be disabled  Rebuild manually one or all projects. It is also possible to clean all output from one or all projects and rebuild them from scratch.

Continous integration Automatic incremental build (continued) Supplementary steps in a project's build process: Are performed by Java applications or by running non-Java tools that are executed from the command line. Relevant examples: -generate code from database or XML Schemas; -generate code from models (see the Eclipse EMF and UML2 technology projects); -package JAR archives; -generate Javadoc files; -use FTP to deploy an application to a test server. External Tools menu: -Any external tool can be configured and run from within Eclipse. -It's more common to use Ant build files to run other Java or non-Java tools.

Continous integration Introduction to Ant Ant – used to implement customized build process.  Part of the Apache open source project.  Java-based build tool designed to be cross-platform, easy to use, extensible, and scalable.  Works equally well in small personal projects or in large, multi-team, distributed development efforts. Ant's benefits – enabled by three core concepts: Ant build files use a declarative syntax to represent build targets, tasks, and dependencies. New tasks may be added that support additional tools or operations; The build files are written with an XML format that helps to provide a flexible and extensible structure. This also allows use of standard XML tools for editing and parsing the build files.

Continous integration Introduction to Ant (continued) The primary elements in an Ant build file : Project. Each build file contains one project. It's not necessary for an Ant project to be equivalent to an Eclipse project; an Ant project represents a logical group of related targets. Target. An Ant project contains one or more targets that produce the build output, such as a library archive, or that perform interim steps, such as compiling source code or running tests. Dependencies between targets assure that prerequisites are completed before a target is run. Task. Each target contains tasks that represent its individual operations. Ant includes a long list of built-in tasks for performing operations such as copying files, running the Java compiler, or setting property values. Other tools can contribute new tasks that extend Ant's capabilities. For a more detailed explanation of writing Ant build files for large projects and continuous integration, see the Ant Web site,

Continous integration Introduction to Ant (continued) Build Properties Set of properties used to parameterize aspects of the build file for an Ant project. Build Tasks –Built into the standard Ant library –Added by third-party extensions. Examples: ant— Run Ant on the supplied build file. copy— Copy a file or fileset to a new file or directory jar— Create a JAR file containing the specified set of files. javac— Compile the specified source file(s). junit— Run the JUnit testing framework. junitreport— Merge the individual XML files generated by the junit task and apply a stylesheet to produce an HTML report of the JUnit results. taskdef— Add a task definition to the enclosing project, such that the new task can be used in this project's targets. (see the Ant documentation for a complete list).

Continous integration Introduction to Ant (continued) Building a Project Steps, in project build file, required to prepare a complete build: 1.Generate Java code from XML Schemas that define data types and enumerated code lists. 2.Run all JUnit tests and generate an HTML report of the test results. 3.Generate Javadoc HTML files from the source code. 4.Automate the entire project build and test process so that it can be run either inside or outside of Eclipse.

Eclipse and Ant Ant is a declarative and extensible build tool, and its capabilities are seamlessly integrated with the Eclipse workbench; supplementing the default Java builder with Ant build files allows fulfill non-routine build requirements. Ant build file editor features: -coordinated Outline view -hover text tips -Content Assist -templates -automatic formatting. Workbench preferences for Ant include runtime configuration where additional JAR files may be added to the classpath used to run build files. Individual build files have their own runtime settings that can override or extend the defaults. Ant build files may be configured to run automatically whenever project resources are modified. The build file may be run either within Eclipse or independently on a separate build machine as part of an automated continuous build process.