model pf 10.002 HEART

Digital Photo Frame
Users Guide Benutzerhandbuch Mode demploi Handleiding Guida dellutente Gui del usuario Moldura

www.compositor.com

Design and specifications subject to change without further notice.

1. Description of Parts

1. LCD Screen 2. Power/Auto Play/Enter 3. Next/Delete All 4. Previous/Delete One 5. USB Port
2. Technical Specifications
Formats supported: BMP (RGB 24 bit), JPG, PNG, GIF and TIFF Display: 1.0 inch LCD screen Storage capacity: 56 photos Port: Standard USB 1.1 interface Power supply: Built-in 3.7V lithium battery or 5V power supply via USB port
3. Description of Buttons Power/Auto Play/Enter
Manual Power On/Off: In standby state, press and hold Power button to start the device. When it is on, press and hold Power button for 3 seconds to power off the device. Auto Power Off: In on state (instead of auto play mode), if no operation is conducted within 2 minutes, the system will power off automatically. Auto Play: After the digital photo frame is powered on, when there are two more (more than two) photos in the device, press Auto Play button to enter the auto play mode. When performing auto play, press Auto Play again to stop.

Previous/Delete One

Backward by hand: After the digital photo frame is started, if there are more than two photos in the device, each time you press Previous button, the previous photo will be displayed. Delete One: If Auto Play button is not pressed, press and hold Previous button for 2 seconds, Delete? will be shown on the screen. And a red dustbin icon will be displayed. Press Enter button to conform and press Next button to cancel.

Next/Delete All

Forward by hand: After the digital photo frame is started, if there are more than two photos in the device, each time you press Next button, the next photo will be displayed. Delete All: If the Auto Play button is not pressed, press and hold Previous button for 2 seconds, the Delete all? will be shown on the screen. And a red dustbin icon will be displayed. Press Enter button to cancel all photos and press Next button to cancel.
4. Install Driver and Photo Viewer
Note: Before using the driver, please first install the Photo Viewer and connect the digital photo frame to your computer. Otherwise, the driver of the digital photo frame will not be installed normally. The CD driver can support Windows 98SE/Windows 2000/Windows Me/Windows XP, unless the digital photo frame is not connected to the computer. A. Insert CD into the CD driver of the computer. B. Enter the CD and select the installation program to install. C. After installation, a shortcut icon will be shown on the screen.
5. Software Interface and Photo View
After the software is installed correctly and the digital photo frame is connected to the computer through USB cable, the system will then automatically inspect and install the Driver. Double click the button to enter the software main interface as shown in Figure 1.

Figure 1

The Photo Viewer window is divided into five parts: Photos on Device window, Address bar, Browse for Images window, Preview window and New Collection Panel window. Note: The internal images of the Driver will be displayed in the New Collection Panel window. When removing or adding photos, the number under the vacancy will correspondingly increase or decrease.

5.1 Add Photos

In the Browse for Images window, select the storage directory and the target folder for storage, and then the photos will be shown on the Browse for Images window. Select the desired photo, and a blue box will be shown around the photo. In addition, the selected photo will be displayed on the Preview window; select button to add the photo to the New Collection Panel window. Note (1) Before adding photos, the Photos on Device window displays items for selection. When no selection is made, the added photo will be automatically cut into the size fitting for digital photo frames screen. When selecting the option of Whole Photo, the added photo will be completely displayed in all images, and the unoccupied place will be in black. (2) Press CTRL button, and left click the mouse to choose more than one photos.

5.2 Crop Photos

Click button to open the Crop Photo window (Figure 2) where you can crop the selected photos.

Figure 2

Click the clockwise button and anticlockwise button to rotate the photos; Drag the brightness sliding block to adjust the photos brightness, drag the contrast sliding block to adjust the photos contrast, and click button to resume the original brightness and contrast of the photos. In the Photo Viewer, the rectangle selection box will be shown in the Crop Photo window.

Press and hold the left mouse button, the needle will change into finger shape, and press and hold the left mouse button to move the selection box and select your desired part of the photo, and then release the mouse to complete the selection. Move the needle at the left upper corner or the right lower corner of the selection box, and then the needle will change into two arrows. Then left click the mouse simultaneously to zoom the setting ratio of the selected photo. Click button to complete cropping photos, and add the cropped photos to the New Collection Panel window. Then press button to exist.
5.3 Management of New Collection Panel Window
The added photos are managed via the New Collection Panel window, where the new added photos will be wrapped by yellow boxes. The photos are selected by clicking the mouse, and the selected photos will be wrapped by blue boxes. (Figure 3)
Figure 3 5.3.1 Photo Sequence
In the New Collection Panel window, select photos and click button to adjust the position of the selected photos. button or
5.3.2 Remove the Selected Photos
In the New Collection Panel window, select photos that you want to remove and click button to remove the selected photos from the window.

5.3.3 Remove All Photos

button to remove all photos from the Collection window. button and the following window will

5.3.4 Save Collections

Before downloading photos, click be displayed (Figure 4);

Figure 4

In the Save As dialog box input the file name for saving the photos, and click Save button to save all photos and click Cancel button to cancel saving.

5.3.5 Load Saved Photos

button to load the saved photos.
5.4 Download Photos to the Digital Photo Frame
Click button to download photos to the digital photo frame. The Download Program window will display the download progress. As shown in Figure 5, after downloading, the window will disappear.

Figure 5

5.5 Photos on Device Window
Use the Photos on Device window to manage photos in the digital photo frame.
5.5.1 Download Photos from the Digital photo frame
If the digital photo frame has photos, after the digital photo frame is connected to the computer, open the Photo Viewer, then the Photos on Device window will show the photos in the digital photo frame (Figure 6.). Click button, and the photos in the digital photo frame will be completely played (Figure 8) after the photos are updated (Figure 7).

Figure 6

Click Click

Figure 7

Figure 8
5.5.2 Delete Photos from the Digital photo frame

button to delete the selected photos in the digital photo frame. button to delete all photos in the digital photo frame.
5.6 Exist the System 6. Battery Charge
In the Photo Viewer window, click Viewer. And then pull out USB cable.
button on the right upper corner to exit the Photo
Connect the digital photo frame to the computer by inserting the USB cable to the USB port for charging. When the battery icon on the screen of the digital photo frame flashes, it indicates that the battery is being charged. When the battery icon stops flashing, it indicates that the battery is fully charged.
7. Contents in the Packaging
Digital Photo Frame 1 USB Cable 1 CD 1 Bag 1 The User Guide is supplied with the CD.
Precautions & Maintenance
Before using your Compositor Digital Photo Frame, please read this manual carefully This Compositor Digital Photo Frame is for indoor use only. Only use the AC adapter as delivered with your Digital Photo Frame. To avoid risk of fire or electric shock, do not expose this product to moisture. Do not use the Digital Photo Frame in conditions of humidity. Do not block the ventilation holes at the back at any time. Keep your Digital Photo Frame out of direct sunlight. Do not dismantle the Digital Photo Frame. There is a risk of electric shock and there are no user-serviceable parts inside. Dismantling will void the warrantee. Turn off the power before inserting or removing memory cards. LCD screen is fragile, please keep away from any impact, moisture and heat. Only use a soft dry cotton to clean the screen. Guarantee This Compositor Digital Photo Frame is guaranteed against defects in materials and workmanship for a period of two years from the date of purchase. This guarantee is only valid if the appliance has been used in accordance with the instructions in this manual, and provided that it has not been modified, repaired or interfered with by any unauthorized person, or damaged through misuse. Disposal Do not dispose of old or defective appliances in domestic garbage; this should only be done through public collection points. This Compositor product meets all essential requirements and other relevant conditions of the applicable EU directives (WEEE / RoHS). Copyright Reproduction of this manual or any part of it is prohibited without permission from Compositor BV.

Towards a new code-based software development concept enabling code patterns
Klaus Meffert1, Ilka Philippow1
1 TU Ilmenau PF Ilmenau, Germany Meffert@rz.tu-ilmenau.de Ilka.Philippow@tu-ilmenau.de
Abstract. Modern software development is driven by many critical forces. Among them are fast deployment requirements, a code base adaptable to new technologies, easy-to-maintain code, and low development costs. These forces are contradicted by the rising complexity of the technological landscape, harder to understand code due to its complexity, missing documentations and quickly hacked in program logic. We introduce a concept aiding in lowering these negative aspects for code-based software development. Protagonists of our work are explicit semantics in source code and newly introduced code pattern templates, which enable code transformations and whose definition and application will be explained in this paper. Throughout this paper, the term code pattern includes architectural patterns, design patterns, and refactoring operations. Enabling automated transformations stands for providing means of executing possibly premature transformations that might lead to results requiring manual finishing.

1 Introduction

Observing current software development projects leads to the conclusion that for a huge number of these projects working with source code is the main driver. Modeldriven development and other techniques seen as sophisticated may be established to a certain part but code-related work is the most relevant procedure for many projects, including work with legacy artifacts. By observing and accompanying a lot of source code-based projects, we noticed the difficulties with state-of-the-art programming techniques. This paper is a contribution to make software development more productive in that segment. Our technique is especially suited for architectural elements to be interwoven with existing source code. To accomplish a raise in software development productivity, we suggest using what is described as code pattern template throughout this paper. Such a template is suited for supporting and hopefully easing the usage of (code-related) architectural patterns (compare Buschmann [12]), design patterns (compare Gamma [1]), and refactoring operations (see Fowler [11]). To enable such templates, we introduce explicit semantics to source code, assigning a deeper meaning, or sense, to a piece of code.
Before digging into detail, we make the following assumptions to build our paper on: A lot of software projects exist for which source code is the main entity developers work with. We also know that there are other established techniques as well, such as model-driven development, and that the perception of the modus operandi depends on the type of project (embedded systems, commercial vs. academic etc.). However, we assume that the majority of software projects is code-driven. We think that it is at least difficult (if not impossible) replacing code-based development with higher-level concepts, such as visual programming, to a satisfying extent in general-domain programming. Code patterns are an important means of building maintainable software. Only using them correctly leads to a benefit, applying them differently makes a loss in product quality very likely. The number of documented design and other code patterns is way too large to be known by a single person or a small group of developers. In our opinion, many design and architectural patterns exist of which each single is too complex to be understood well enough by the majority of software developers. Here, better tool support is needed. It seems impossible identifying the sense (i.e. the semantic meaning or intention) of an arbitrary piece of code within a given context by a machine. In our eyes, it is not possible to perfectly execute automated transformations for unknown pieces of code. The reason is the missing awareness of the transforming entity about source code, target code and transformations. The next section describes our perception of current code-based software development practices as a common scenario in software development projects. 1.1 A common software development scenario A typical scenario for software projects may look like this: After organizational and other management activities are finished, a person or a group sets up the requirements for the development department. Often, the requirements are compiled in an ordinary document, maybe supported by charts, cross links etc. Nevertheless, this important document frequently is informal and not machine understandable in a satisfying way. The developers read the requirements, communicate their understanding of them and questions arising to the creator of the document or to a different, but competent person in this field. After the developers think that they know what the program to be created should do, they begin by extending the existing code base. For that they use an integrated development environment (IDE) available with their project and write plain source code. Often this activity includes searching the right program modules or packages to modify or extend. To finally implement a given requirement, the developers have to dig down into the code and do the adaptations they think fulfill the requirement. Normally, the software development department tries to develop maintainable code that is easy to understand, efficiently adaptable to future requirements and with

problem of program understanding is removed while being unable to process and understand statements generically at the same time. This paper suggests implementing annotations for Java as specific comments. Other approaches such as JSR 175 propose annotations as first-class program elements in Java. But one major problem with JSR 175 as the main concept for annotations in Java is the limited scope an annotation has (single statements are outside the scope of a JSR 175 annotation). To distinguish annotations from ordinary comments, a unique prefix is added to them after the comment prefix (for Java the two characters /*). This paper suggests the double at-sign @@. Meffert [10] describes an implementation for annotations and recommends using a composite annotation that embodies both a machine-interpretable part and a human-readable part. Besides, hash codes can be attached to annotations to recognize changes in annotated code fragments with high probability, and thus be able to ask for revalidating the annotations in question. 2.3 Transformation A transformation in the context of this paper is the process of getting to a target code from a given source code by applying defined rules. A rule always produces the same result when applied onto the same source code (with no rule changed in the meantime). At first, transformations are introduced to obtain a code pattern template (see next section). At second, they are helpful to support the developers in applying a code pattern by trying to apply the pattern as far as possible. It can only be a try because when automatically transforming code the machine executing the transformations misses what a human would call awareness of the meaning of source code, the transformations and the result. That in turn makes it impossible, in our opinion, to get a machine to transforming arbitrary pieces of code in any context. That is why we suggest a workaround for this problem currently unsolvable in our eyes. Our suggestion leads to an extended support when transforming code that reduces manual work but cannot make it superfluous. 2.4 Code pattern template A code pattern template contains any information about a pattern necessary for a specific process (selection, application, recognition). This includes static and dynamic parts, and source code as well as semantic information (compare Krahn and Rumpe [8] for a template without explicit semantic information). To use a template effectively it must be connected with a given source code, the context. Connecting the template with code means finding anchors in the context that justify the applicability of the template for the context. Semantic anchors in source code are provided by annotating the code during software development, as this paper proposes. The semantic counterpart in the code template is equivalent to annotations. Also the scope an applied annotation has is relevant. When comparing the name and the scope

of an annotation in source code and code pattern template a match can be determined. The next figure illustrates this matching process.

Source code

class Example{ class Example{.. void doWork(){ void doWork(){.. /**@@intent.*/ /**@@intent.*/ for(int i=.) for(int i=.).. } }

Pattern template

Pattern: X Pattern: X role: <name> role: <name> <semant.elem.> <semant.elem.> <scope> <scope> <constraints> <constraints>
Fig. 1. Matching a pattern template with source code via annotations
As displayed, the template can also contain constraints that can perform extensive validations, like evaluating preconditions. Additional logic included in the template is used for Abstract Syntax Tree (AST) analysis (such as finding a variable declaration of a specific type in a given scope) as well as for handling information gained by matching code and template. Routines implemented such logic are called handlers here. A handler as well as a constraint checker is implemented in pure Java code. It can utilize a library that provides often required logic. This library is supposed to grow during the creation of new code templates. The reason why handlers and checkers are implemented programmatically and not supplied via a simpler scripting language is the capability and flexibility such logic must have. The information that led to an explicit code pattern template definition, are stored along with it (see section 4).
3 Towards a new software development concept
The presented approach suggests extending common code-based development scenarios (as described in section 1.1) by a semantic layer. For adding semantics, two perspectives are proposed. The first one is the perspective of code. By adding explicit semantic information to code, analysis tools have much more possibilities of extracting information from the code. The second perspective concerns code pattern templates which are supposed to be enriched by semantic information, too. The vehicle for manifesting explicit semantics in code is the quite popular concept of annotations. Future tools should support developers in adding annotations to the code they want to enrich semantically. Our vision is that modern IDEs will suggest annotations to the developers which will be added automatically to their code. Besides, an IDE should verify applied annotations and ease their definition (compare Meffert [9]). Adding semantics to code pattern templates can occur in any satisfying way, because templates need not be compilable necessarily (in contrast to Krahn and Rumpe [8] who describe a different approach).

The result of having explicit semantics in source code as well as in code pattern templates allows finding an appropriate template for a given context (i.e. a source code) in order to transform the context according to what the template defines. Matching code and template is easier with help of explicit semantic information than by any ordinary AST-based comparison (see Meffert [10]). The reason is that it is nowadays simply not possible for a machine reasoning about the sense of an arbitrary piece of code. There are exceptions (such as speaking names), but to put them onto a commonly understood basis for code analysis, these exceptions would have to become standards which sounds contradictory. By introducing annotations, a more practicable mechanism is suggested. When working with code patterns, tool-support is possible for the processes definition of code pattern templates, recognition of applied patterns in a given source code, selection of an applicable pattern for a given source code, and application of a selected pattern onto a given source code. Each process can profit from explicit semantics that would otherwise not be reasonable by a machine. The next paragraph describes the idea of introducing explicit semantics to code and code template in detail. After that, an extended example of creating a code template is given. 3.1 Working with explicit semantics As said, there are two sides of the medal, for which explicit semantic information is relevant, namely source code and code templates. Code templates are a newly introduced entity (other papers did this in a different way already) not significant for a programmer. However, enriching source code with annotations is significant for developers following our approach. As it is not possible reasoning about the sense of any piece of code and as it is not possible knowing about the design intentions of developers, annotations have to be added to source code manually at least to a certain extent. A tool could assist that process by suggesting annotations for a given code: Either by comparing the code with already known cases or by evaluating speaking names or other coding conventions seen as common. Only presenting valid annotations for a given scope further narrows down the number of annotations to consider. The introduction of semantic information into non-compilable code templates is different than for source code. As only experienced developers are able to define templates (see the next section), more competence and engagement in proceeding with this process and understanding it is assumed. Code templates also need to be described once for a set of similar contexts, whereas annotating code depends on the individual motivations for doing do. Different motivations for annotation source code are plausible. Each one results from a specific aim the developer has. The alternatives are that the developer knows a pattern to apply but wants support in applying it, knows a pattern that might apply and wants to get an acknowledgement or a better proposal,

Graphics g = new Graphics(); Picture p = new Picture(); /*@@COMPOSITE_ADD_ELEMENT*/ elements.add(p); elements.add(new Text("This is a text")); elements.add(new Line(2, 3, 17, 42)); elements.add(new Line(8, 1, 9, 14); g.create(); } } In the above code, the annotation COMPOSITE_ADD_ELEMENT is just written once. For the other two statements beginning with elements.add( the annotation can be skipped in case there is a handler reasoning that these two statements must be analogue to the annotated statement. Here are the relevant excerpts of the other classes: /*@@COMPOSITE_COMPONENT_CLASS*/ public class Graphics { /*@@COMPOSITE_OPERATION*/ public void create() { for (int i = 0; i < Client.elements.size(); i++) { Object o = Client.elements.get(i); if (o.getClass() == Picture.class) { ( (Picture) o).paint(); } else if (o.getClass() == Text.class) { ( (Text) o).print(); } else if (o.getClass() == Line.class) { ( (Line) o).draw(); } } } } /*@@COMPOSITE_COMPOSITE_CLASS*/ public class Picture { /*@@COMPOSITE_OPERATION*/ public void paint() { // picture is painted here } } To sum up, the aspects that degenerate the above sample code from Composite are: The children of class Graphics are not held in a list attribute in Graphics, but in a static attribute in Client. Each class has an operating method with different name (create, paint, print, draw) instead of a unified name. The hierarchy between elements (containing and contained elements) is represented by the order of the elements in the static attribute elements, not by holding child elements by their parents.
The classes Text and Line are analogous to the above class Picture and do not contain any logic noticeable in our context. Text and Line are annotated in analogy to Picture, but the annotation name at class level is COMPOSITE_LEAF_CLASS. It is remarkable that method create in class Graphics is satisfactorily determined by adding one annotation COMPOSITE_OPERATION above it. The reason is that an assumption is made for any method annotated that way. The idea is that such an annotation equalizes the logic contained in the methods body and reduces it to one statement, namely this method is the analogy to the operation-method in Composites role X (with X being a class identified by another annotation, such as COMPOSITE_COMPOSITE_CLASS). Conclusions from introducing such homogeneity are that code transformation must rely on known cases, which is not necessarily a problem itself. It is just quite time-consuming identifying similar cases and the transformations into one or several analogous target codes. Also, it might be that an annotation above a method might be too coarse-grained for a method implementing multiple relevant aspects. But then the situation is resolved latest when applying the pattern. There it should prove whether the transformed code still does what it should do. The previously mentioned mechanism of comparing known code blocks will nevertheless be able to popup an alert to inform developers annotating a multi-purpose method with an unqualified annotation. 4.2 Target code To demonstrate how a transformation from the source situation above to a defect-free implementation of Composite can be executed, the desired target code is shown. It represents a known Composite implementation that is a priori context-free. Also some annotations were added, finding them is described later. The corresponding classes could look like this (other alternatives are possible): /*@@COMPOSITE_CLIENT_CLASS*/ public class Client { public Client() { Graphics g = new Graphics(); Picture p = new Picture(); g.add(p); g.add(new Text("This is a text")); g.add(new Line(2, 3, 17, 42)); g.add(new Line(8, 1, 9, 14); g.operation(); } } public interface IComponent { void operation(); void add(Component component); }

/*@@COMPOSITE_COMPONENT_CLASS*/ public class Graphics implements IComponent { private List elements = new Vector(); /*@@COMPOSITE_ADD_ELEMENT*/ public void add(IComponent c) { if (c.getClass().isAssignableFrom(Graphics.class)){ throw new RuntimeException( " Graphics must not be added to itself"); } elements.add(c); } /*@@COMPOSITE_OPERATION*/ public void operation() { for (int i = 0; i < elements.size(); i++) { IComponent c = (IComponent) elements.get(i); c.operation(); } } } public interface IComposite extends IComponent { } /*@@COMPOSITE_COMPOSITE_CLASS*/ public class Picture implements IComposite { private List elements = new Vector(); /*@@COMPOSITE_ADD_ELEMENT*/ public void add(IComponent c) { elements.add(c); } /*@@COMPOSITE_OPERATION*/ public void operation() { paint();//picture itself is background for (int i = 0; i < elements.size(); i++) { IComponent c = (IComponent) elements.get(i); c.operation(); } } public void paint() { //paint the picture here } } public interface ILeaf extends IComponent { } /*@@COMPOSITE_LEAF_CLASS*/ public class Text implements ILeaf { private String line; public Text(String a_text) { line = a_text; } /*@@COMPOSITE_ADD_ELEMENT*/ public void add(IComponent c) { throw new RuntimeException("not supported"); }
/*@@COMPOSITE_OPERATION*/ public void operation() { System.out.println(line); } } Class Line is not shown as it is analogous to class Text (Line has just a different implementation of method operation). It should be noted that annotation COMPOSITE_ADD_ELEMENT moved from class Client of the source code from section 4.1 to class Graphics in the target code. That is possible because it does not matter if the caller of a method is assigned the annotation or the method itself. The reason to choose class Graphics for the annotation is that the client class should not become part of the template in general. The client class is cared by the transformations given in the next section. It is not part of the explicit template definition. Dependencies between the client class and the other roles the pattern in question has (also compare [13]) are given by the existence of source and target code. Thus, the definition of a client class in the template would hold no additional information that could be exploited. Annotations were added to source and target code wherever an link between them was required that could otherwise not be reasoned about. Thus, an annotation is required for any part in code for which the intention cannot be evaluated via (static) AST analysis satisfactorily. It depends on the capabilities of a tool which evaluations are possible, but an experienced developer should be able telling for which pieces of code a machine cannot uncover its intention (the so-called program understanding). The annotations in the source code were introduced reversely, i.e. after having the target code. This way, the significant parts of the pattern (manifested in the target code) were known already. Now we proceed with the transformation of the initial code until the target code is manifested.

tagging a class as having role B). We chose to do so to signalize that even a low-level action can be realized by using another action or combining multiple low-level actions. 5.1.2 Introduce method add to class Graphics High-level description: 1. Add method add with the code shown in section to class Graphics. 2. Adapt the logic in the methods body. Low-level actions: 1. Add method A (logic as given in target code, including the annotation) to class B (A = add, B = Graphics). Preconditions: 1. Non-critical: Method add does not exist already 2. Critical: Method add does exist already and has different implementation User confirmation required or variation known in the repository. Remarks: The methods logic in action one will be replaced by a parameterized version in the code template to obtain (see further down). Replace access to method add from attribute elements with sophisticated method add in class Graphics High-level description: 1. Using method add from attribute elements directly is forbidden. 2. Instead, use method add from class Graphics. Low-level actions: 1. Find list variable annotated with COMPOSITE_ADD_ELEMENT. 2. Determine any place where method A for attribute B is called statically (A = add, B = variable from action one). 3. For all found places: a. Determine instance variable of class A that is available at the time method C(D) of attribute B is called (A = Graphics, B = variable from action one, C = add, D = signature of method C). b. Find class with annotation A (A = COMPOSITE_COMPONENT_CLASS). c. Replace A.add(B) with C.add(B) (A = variable from step one, B = *, C = instance variable for class found in previous step). Preconditions: 1. Action 3a) returns non-empty result for any place found. 2. For action 3a): There exists a class with the given annotation. Such a precondition is omitted for the following transformations. Remarks: We assume that there are no dynamic calls to method add from attribute elements. Dynamic calls cannot be discovered reliably. Action 2a is another way of expressing that a specific class is meant. A precondition for using this description is that class Graphics was identified be5.1.3

fore as incorporating role Component of the Composite pattern (compare the first transformation where this already happened). 5.1.4 Adapt method create in class Graphics High-level description: 1. Rename method create in class Graphics to operation, if necessary. 2. Replace code in renamed method with code from method in target code. Low-level actions: 1. Find class with annotation A (A = COMPOSITE_COMPONENT_CLASS). 2. Find method with annotation A in previously found class (A = COMPOSITE_OPERATION). 3. Rename previously found method to A (A = operation). 4. Replace code in previously renamed method with logic from method A of target code class B (A = method name found in action 2, B = Graphics). Preconditions: 1. Examine whether the method to be adapted corresponds in its behavior with the adapted code (i.e. by evaluating possibly existent annotations or by comparing code blocks from a repository with the source code). Display the recognized behavior to the user. If difference detected: Inform user what the method is supposed to do. If no difference detected: Suggest proceeding with transformation. Remarks: In low-level action four, the method A contains code that is contextdependent. The content-dependent parts will later on be parameterized in the code template. For reasons of simplifications, here no parameters are passed to the methods called in method operation. Considering parameters would be possible by introducing a generic data transfer object (DTO) that is a container object holding any parameter of the operation methods from classes Picture, Text and Leaf. The DTO could then also be introduced to method operation and to the callers. 5.1.5 Adapt method paint in class Picture The following is also valid for class Text. High-level description: 1. Add a new method operation that iterates over all children of Picture and also executes the original paint-method. 2. Find all calls to method paint of class Picture and replace them with a call to method operation. Low-level actions: 1. Add method A to class B and adapt so that method C is called (A = operation, B = Picture, C = paint). 2. Determine any place where method A is called and replace it with call to method B (A = paint, B = operation). Preconditions:
Within method operation, any parameter that must be passed to method paint must be known. This is a constraint that cannot be coped with in this paper. It may lead to a transformed code that is not compilable. The main idea behind this is: Better give a developer a nearly perfectly transformed code that needs slight rework than give him no transformed code at all. With annotations it is very probable that the source code to transform conforms at least close to what is expected.
5.1.6 Let class Graphics implement interface IComponent The following is valid for the classes Picture, Text and Line in an analogue way (namely with different interfaces). High-level description: 1. Introduce interface IComponent as shown in the target code. 2. Add a directive to class Graphics that lets it implement interface IComponent. Low-level actions: 1. Add a class for interface A as shown in the target code (A = IComponent). 2. Add the statement implements A to class B (A = IComponent, B = Graphics). The low-level actions described above are a direct start in obtaining reusable actions. With every template definition, the number of actions to be defined from scratch is likely to be reduced. 5.2 Verifying the transformation Because finding transformations as described above is a nontrivial task, errors may occur during this process. To avoid or uncover errors as good as possible, we suggest following the hints: Check that for any annotation added to the source code, a corresponding annotation in the target code must exist. For any difference between source and target code a transformation must exist. For each transformation the necessary preconditions must exist. It seems as if there is no other technique to obtain these preconditions than by thinking about which are obligatory. See section 5.5 for further considerations on preconditions. Test the transformations on a slightly modified piece of code. For example, modify the visibility of attribute, methods, and classes. The modified code needs not be compilable as it is only about verifying transformations in this step. Each annotation must either exist in the repository. Or, if not it has to conform to a defined syntax (see [10]). It is likely to occur that developers defining transformations as described in the previous section forget a transformation or a precondition. To find out such incom-

Method @@COMPOSITE_OPERATION) } } [Interface ILeaf] public interface <role> extends <role:IComponent> { } [Role Leaf] public class <role> implements <role:ILeaf> { private String line; public Text(String a_text) { line = a_text; } public void add(<role:IComponent> c) { throw new RuntimeException("not supported"); } public void operation() { ~INSERT_CODE(@@COMPOSITE_LEAF_CLASS, Method @@COMPOSITE_OPERATION) } } Some explanations to the above code: The sections marked with Interface are special roles names that have to be consistent throughout the template but can be chosen freely, are realized via slots. A slot is defined by an arbitrary name that is unique within the template containing all the roles. To recognize a slot, its name is surrounded by < and >. The special slot <role> gets assigned the value that follows the section identifier role or interface. The slot <role:X> references the section marked by [Role X] or [Interface X] and gets assigned the value of the referenced role. Which concrete name a role and thus a class or interface has depends on what the developer enters when asked about it on the application of the template. The control tag INSERT_CODE has two parameters that identify a method in the source code. The code from within this method is to be copied to the target code during transformation. This may lead to premature transformations which we think is unavoidable in some cases. By looking at the transformations 5.1.2, 5.1.4 and 5.1.5 that contain code to be introduced to the target code, slots can be identified. A slot has to be added for any variable that is context-dependent (see point 1d in the above list and compare method add in the section of role Composite above in this paragraph). A by-product of the process obtaining a code template definition is the definition of annotations. I.e., a concrete (posteriori) definition of annotations introduced a priori during the transformation phase is possible. With the next example the abovementioned steps are demonstrated: Step 3 of the activities necessary to create a code template results in annotation definitions. The annotations existent in the source and target code (sections 5.1 and 5.2) are equivalent with respect to their name, but different concerning their scope. The scope of an applied annotation is the statement the annotation is applied above. This concrete scope must be within a generically defined scope that is manifested with the annotation definition. It follows an overview of the annotations applied to the code
from section 5.1 and 5.2, together with the code in source and target code the annotations were applied to.
Table 1. Overview of annotations applied in section 5.1 and 5.2

Annotation name COMPOSITE_ADD_E LEMENT COMPOSITE_CLIEN T_CLASS COMPOSITE_COMP ONENT_CLASS COMPOSITE_OPERA TION COMPOSITE_COMP OSITE_CLASS COMPOSITE_LEAF_ CLASS
Code in source elements.add(p) public class Client public class Graphics
Code in target public void add(IComponent c) none
public class Graphics implements IComponent 1. public void create() public void operation() 2. public void paint() public class Picture public class Picture implements IComposite public void print() 1. public class Text implements ILeaf 2. public class Line implements ILeaf
As can be seen, the annotation COMPOSITE_OPERATION was applied to two different code statements. Thus, the scope to be defined for the annotation must include both scopes that correspond to the applied code statements. Here, the scope is the same for both cases as just the name of a method is different. The scope matching both methods public void create() and public void paint() is public method with empty signature, or to give it a reusable (arbitrary but unique) symbolic name: METHOD_PUBLIC_SIGNATURE_0. Under this symbolic name the scope of other annotations can be expressed concisely. Symbolic names for scopes are stored in a repository that can be accessed by the logic relevant for processing annotations. Defining an annotation means creating an initial definition which can then be improved in iterations. A new iteration is possible if the annotation already defined is applied to another program element. After application, a review of the applied annotations scope is possible followed by a comparison of the annotation definition regarding its conformance to the new application. After a code template definition is created, different source codes can be evaluated with it. When comparing other source codes with the target code of the template, for every applied annotation three cases can be distinguished: 1. Annotation both exists in source and target code, possibly with different names. 2. Annotation only exists in source code. 3. Annotation only exists in target code. Case one means that source and target code match conceptually. Annotations of case two are not necessary in the target code because they can be reasoned by in a different way (e.g. by matching with a different annotation, or by exploiting ASTinformation with help of a handler routine) or because in the target code there is miss-
ing a corresponding (i.e. semantically equivalent) code block. The third case includes source code that does not contain (semantically equivalent) parts of the target code. Case one produces a direct match between source and target code whereas for cases two and three making a match depends on whether a missing annotation is just missing because it was forgotten or it is not adequate applying it (here user input is required). Making a match between source and target code means that the transformations connected with the code template are likely to be possible. Verifying the preconditions stored with the template allows to distinguish the applicability of the pattern expressed by the template better. In case no precondition is violated the applicability is given to a high degree. A violated precondition lowers the applicability. 5.4 Utilizing a code template for varying source code It is likely that a piece of code is different from a source transformed initially to obtain a template (as in section 5.3). This paragraph illustrates with an example how the template can be exploited under different contexts. Further, it is shown how new variations of the template can be achieved. Assume we have a class Client that is different to that shown in section 4.1 and that looks like: /*@@COMPOSITE_CLIENT_CLASS*/ public class Client { public Client() { Graphics g = new Graphics(); /*@@COMPOSITE_ADD_ELEMENT*/ g.addPicture(new Picture()); /*@@COMPOSITE_ADD_ELEMENT*/ g.addText(new Text("This is a text")); /*@@COMPOSITE_ADD_ELEMENT*/ g.addLine(new Line(2, 3, 17, 42)); g.addLine(new Line(8, 1, 9, 14); g.create(); } } In this instance class Graphics is different to the initial example in that it provides methods for adding the child elements Picture, Text, and Line. The above code already contains annotations to avoid printing the code a second time (normally, the annotations are to be added after the code is considered!). As can be seen, each addXXX-method must be annotated the same way to match Composites operationmethod. Taking the transformations from section 5.1, we can recycle some steps, skip others, modify some and introduce new actions. Transformation 5.1.1 is obsolete. The transformations 5.1.2 and 5.1.3 must be modified. About the other transformations, the example above does not allow making any assumptions, for sake of simplicity we assume them to be equivalent. To modify the two mentioned transformations, it could be thought of the addXXX-methods in class Graphics of three methods with different signature but equivalent logic (e.g. elements.add(inputparam)). The only arguable

reason having such a code is that classes Picture, Text, and Line do not share a common interface. This means we would obtain an additional transformation that introduces an interface to each of these three classes (compare the refactoring activity Introduce Interface described by Fowler [11]). Transformations 5.1.2 and 5.1.3 would then include the replacement of all addXXX-methods by one add-Method in class Graphics and for the callers of the methods. Concluding, the template defined previously could remain unchanged for most parts, just some transformations would have to be adapted, deleted or introduced. For these, previously defined actions could be recycled. Besides, in the definition of annotation COMPOSITE_ADD_ELEMENT the scope would have to be extended so that not only calls to a method for a class derived from a collection (such as java.util.Vector) are included but also calls to methods of other classes (such as Graphics). 5.5 Exploiting the code pattern template Recapitulating, the information we have after defining a code template is: the initial source code, the annotated source code, the transformed and annotated target code, the transformations leading from source to target, a code template and annotation definitions. Source and target code as well as the code template contain information about the role relations and the relations of annotated pieces of code. This valuable data can be used to determine if preconditions met before selecting or applying a pattern, or to detect applied patterns within a given source code. By comparing applied annotation within a source code with code pattern templates, partly implemented patterns can be recognized, or, to see it from a different perspective, missing annotations can be detected (in case the pattern in question is applied fully). Having explicit semantics in source code can be an enormous advantage for implementing preconditions because not only can syntactic constraints be validated but also semantic ones. The information of a number of source codes that can be transformed into the same target code allows to reason about the similarity or equality (in the sense of comparable behaviour) of different source codes. This in turn can be exploited when trying to detect if changes in annotated code are significant or not (e.g. x++ is equal to x+1, to give a very basic example). Recognizing synonymous code blocks statistically comes into reach when having large amounts of data accessible (compare the machine translation work by Wang [15]). By gathering information about which pieces of code could be seen as isomorphic (i.e. analogous in their behaviour) it is possible comparing ASTs not for exactly matching with specific elements but for matching with isomorphic elements. This could be seen as a search for synonyms rather than for exact compliance.

report errors when certain pieces of code are not annotated. Code of that category is such that is either not known when compared with other projects stored in a repository. Or it may be code that has an ambiguous meaning, because at least two different annotations for the same piece of code are recorded in the repository. In the latter case, a proposal could be presented, leading to a more transparent type of code considering program understanding.

8 References

1. Gamma, E., Helm, R., Johnson R., Vlissides, J.: Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley (1995) 2. Java Specification Request 175: A Metadata Facility for the JavaTM Programming Language. http://www.jcp.org/en/jsr/detail?id=175 3. Java Specification Request 305: Annotations for Software Defect Detection. http://www.jcp.org/en/jsr/detail?id=305 4. Jackpot. http://jackpot.netbeans.org/index.html 5. Cinnide, M., Nixon, P.: A Methodology for the Automated Introduction of Design Patterns. Proceedings of the International Conference on Software Maintenance, Oxford (1999) 6. Niere, J., Schfer, W., Wadsack, J. P., Wendehals, L., Welsh, J.: Towards Pattern-Based Design Recovery. Proceedings of the 22nd International Conference on Software Engineering 2000, Limerick, Ireland (2000), 241-251 7. Krahn, H., Rumpe, B.: Towards Enabling Architectural Refactorings through Source Code Annotations. In: Mayr, H.C., Breu, R. (eds.): Proceedings der Modellierung 2006, Innsbruck (2006) 8. Krahn, H., Rumpe, B.: Techniques For Lightweight Generator Refactoring. In: Lmmel, R., Saraiva, J., Visser, J.: Proceedings of Summer School on Generative and Transformational Techniques in Software Engineering (LNCS 4143), Springer (2006) 9. Meffert, K.: Supporting Design Patterns with Annotations. 13th Annual IEEE International Symposium and Workshop on Engineering of Computer Based Systems (ECBS '06), Potsdam (2006) 437-445 10. Meffert, K., Philippow, I.: Supporting Program Comprehension for Refactoring Operations with Annotations. In: Fujita, H., Mejri, M. (eds.): New Trends in Software Methodologies, Tools and Techniques - Proceedings of the fifth SoMeT_06, Vol. 147 (2006) 48-67 11. Fowler, M: Refactoring: Improving the Design of Existing Code. Addison-Wesley (1999) 12. Buschmann, F.; Meunier, R.; Rohnert, H.; Sommerlad, P.: A System of Patterns. PatternOriented Software Architecture. John Wiley and Sons (1996) 13. Hedin, G.: Language Support for Design Patterns Using Attribute Extension. In: Bosch and Mitchell (Eds.): Object-Oriented Technology. ECOOP97 Workshop Reader (LNCS 1357), Springer (1997) 137-140 14. Shi, N., Olsson, R.A.: Reverse Engineering of Design Patterns from Java Source Code. In: Proceedings of the 21st IEEE International Conference on Automated Software Engineering (ASE'06) - Volume 00 (2006) 123-134 15. Wang, Y.: Grammar Inference and Statistical Machine Translation. Carnegie Melon University (1998)