1 / 11

FRUIT: A Family of Retargetable User Interface Tools

Design methodology, architecture, and applications of FRUIT software product line for device-independent user interface controls. Stepwise refinement approach with commonality and variability analysis. XML-based XForms technology adopted for flexibility and reusability.

christophercardenas
Download Presentation

FRUIT: A Family of Retargetable User Interface Tools

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Architectural Design of FRUIT:A Family of Retargetable User Interface Tools Yi Liu, H. Conrad Cunningham and Hui Xiong Computer & Information Science Department University of Mississippi

  2. Abstract Forms-based user interfaces are used widely for human-computer interaction. However, it is difficult to reuse software in such systems because they are often dependent upon particular display technologies. We design the Family of Retargetable UserInterface Tools(FRUIT) to solve the problem. FRUIT adapts the device-independent XForms technology to deliver a family that supports a variety of devices. We study the architecture for the FRUIT product line and illustrate a design methodology based on stepwise refinement and commonality and variability analysis. We also examine two members of FRUIT and show how they are refinements of the family architecture.

  3. Forms-based UI Component Client Application User Figure 1. An architectural design of an application Configuration info Client Application FRUIT Form description User Submission response Figure 2. An application with FRUIT 1. Introduction In Figure 1, the user interacts with the application through a forms-based User Interface (UI). It is difficult to share code or fine-grained architectural design within a forms-based UI. FRUIT is a software product line in which the members share a high-level architectural design, a common interface design, and perhaps components. By using FRUIT, the interactions with user interface controls are represented in a device-independent manner and translated into specific technologies. Figure 2 shows an architectural design of an application with FRUIT. The information exchanges between the Client Application and FRUIT use the XML-based XForms standard.

  4. XForms Model XForms User Interface XForms Submit Protocol XML Instance Data Figure 3. Three parts of XForms 2. XForms XForms is a new device-independent markup language that combines XML and forms. XForms splits traditional HTML forms into the parts: (1) XForms model, (2) XForms user interface, and (3) instance data (Figure 3). <body> <input ref = "name"> <label> Your Name </label> </input> <submit submission = "submit"> <label> submit </label> </submit> </body> Figure 6. User interface section Figure 4. An example form <head> <model> <instance> <example> <name/> </example> </instance> <submission action = "http://cs.olemiss.edu/submit" method ="post" id = "submit"/> </model> </head> Figure 5. XForms model and instance data Figure 7. Filled form <example> <name>yi liu </name> </example> Figure 8.Submitted instance data

  5. 3. Architectural design The general goal is to develop a product line in which user interface controls are represented in a device-independent manner. Commonality analysis is a process for finding the common characteristics among family members. Variability analysis identifies important assumptions that hold for some family members. We generalize the variabilities and wrap them with abstract interfaces so that family members can be built with a common architecture. Stepwise refinement We use a stepwise refinement method that combines domain analysis with commonality and variability analysis. Step 1: Find the main components and specify the top-level architecture. FRUIT takes descriptions from the Client Application, translates them into a form, and delivers it to the device. Then, FRUIT collects data from the device and sends them to the Client Application (Figure 9).

  6. Figure 9. FRUIT architecture – step 1 Form description Form UI FRUIT Client Application Configuration info Client Application UI FRUIT Collected data Submission response Figure 10. FRUIT architecture – step 2 Step 2: Analyze the interfaces. Commonality a: FRUIT is independent from the Client Application. All communication between the Client Application and FRUIT uses the abstract interface between them. The inputs consist of both the form description (an XForms document that describes the elements) and the form configuration information (an XML document that specifies details such layout). Commonality b: The UI varies among devices. Each FRUIT member has an interface with the UI that isolates FRUIT from the specific device characteristics. FRUIT sends a form to the device and then collects the user responses (Figure 10).

  7. Form description Form FRUIT XForms Parsing Configuration info Collected data Submission response Figure 11. FRUIT architecture – step 3.1 Form Generation Form description XForms Parsing Form Configuration info Collected data Submission response FRUIT Figure 12. FRUIT architecture – step 3.1 • Step 3:Refine the main components. • We divide FRUIT into two stages: • parsing the XForms document and generating the user interface • extracting the user response and assembling the data. • Step 3.1: The commonalities for the first stage. • Commonality c: Each family member must parse the XForms documents (Figure 11). Commonality d: FRUIT parses the form description and extracts the elements into displayable controls for the expected device. Form configuration gives the layout information (Figure 12).

  8. Form description Form Form Generation XForms Parsing Configuration info Response Assembly Submission response Collected data instance data action FRUIT Figure 13. FRUIT architecture – step 3.2 Step 3.2: The commonalities for the second stage. Commonality e: All family members must collect data from the UI and send them to the Client Application. The submitted data contains two parts: instance data and action description. When a form returns, it gives the URI for the form to be invoked next in the action description (Figure 13). Step 4: Refine the subcomponents. Consider Form Generation and Response Assembly. Commonality f: Each element corresponding to an XForms control is translated into a control in output form. Commonality g: FRUIT should establish appropriate policies for form layout since the form configuration information might be incomplete or empty.

  9. Form description Layout Policy Control Construction XForms Parsing Form Configuration info Data Extraction Data Assembly Submission response Collected data FRUIT Figure 15. FRUIT architecture – step 4 Commonality h: We divide Response Assembly into two subcomponents: Data Extraction for unifying the incoming data into the same formatfor all family members and Data Assembly for assembling the unified data into submitted data (Figure 13). 4. Examples Consider a Java Swing application and a Java Servlet application. The Java Swing and Java Servlet applications are both implemented using Java. XForms Parsing and Data Assembly are components that can be reused. Variability analysis Variability a: The action types between the FRUIT and the other two components differ.

  10. UI Control Construc-tion Form XForms Parsing Layout Policy Client App. Proc. Call Proc. Call Data Extraction Data Assembly FRUIT Figure 16. FRUIT Java Swing application The interactions among components in the FRUIT Java Swing application are procedure calls. The components in the FRUIT Java Servlet application communicate by invoking servlets. We divide the FRUIT process into two parts: the outgoing process, and the incoming process (Figure 16 and 17). FRUIT -out UI Client App. Control Construc-tion Form Layout Policy XForms Parsing Invoke URL C1 • FRUIT-in Data Extraction Proc. Call Data Assembly Invoke URL C2 FRUIT Figure 17. FRUIT Java Servlet application

  11. Variability b: The implementation of the Control Construction component differs. In the Java Swing application, the XForms controls are converted into Swing controls. In the Java Servlet application, the XForms controls are converted into HTML controls. 5. Conclusion It is difficult to exploit software reuse in forms-based systems because the systems are heavily dependent upon the display technologies. FRUIT uses the new device-independent technology XForms to satisfy the diverse expectations of users. We design FRUIT as a family of programs, or software product line, whose members share the same design architecture but differ in the implementations of some components. In addition to introducing a tool, we illustrate a methodology for designing product line architectures. This method is based on the stepwise refinement approach and commonality and variability analysis. The experience of building the Java Swing and Java Servlet prototypes of FRUIT indicates that this method results in a reliable architecture.

More Related