Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "1 The Architectural Design of FRUIT: A Family of Retargetable User Interface Tools Yi Liu, H. Conrad Cunningham and Hui Xiong Computer & Information Science."— Presentation transcript:

1 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 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 User Interface 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 3 1. Introduction Client Application Forms-based UI Component User Figure 1. An architectural design of an application 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. Client Application User FRUIT Configuration info Figure 2. An application with FRUIT Submission response Form description

4 4 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). XForms Model XForms User Interface XML Instance Data XForms Submit Protocol Figure 3. Three parts of XForms Figure 4. An example form <submission action = "http://cs.olemiss.edu/submit" method ="post" id = "submit"/> Figure 5. XForms model and instance data Your Name submit Figure 6. User interface section Figure 7. Filled form yi liu Figure 8. Submitted instance data

5 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 6 Client Application FRUIT UI Figure 9. FRUIT architecture – step 1 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). Client Application FRUIT UI Configuration info Form description Submission response Form Collected data Figure 10. FRUIT architecture – step 2

7 7 Step 3: Refine the main components. We divide FRUIT into two stages: (1)parsing the XForms document and generating the user interface (2)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). Configuration info Form description Submission response Form Collected data FRUIT XForms Parsing Figure 11. FRUIT architecture – step 3.1 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). Configuration info Form description Submission response Form Collected data FRUIT XForms Parsing Form Generation Figure 12. FRUIT architecture – step 3.1

8 8 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). FRUIT Response Assembly instance data action Configuration info Form description Submission response XForms Parsing Form Generation Form Collected data Figure 13. FRUIT architecture – step 3.2 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 9 Commonality h: We divide Response Assembly into two subcomponents: Data Extraction for unifying the incoming data into the same format for all family members and Data Assembly for assembling the unified data into submitted data (Figure 13). Submission response Form Collected data FRUIT Data Assembly Layout Policy Data Extraction XForms Parsing Form description Configuration info Control Construction Figure 15. FRUIT architecture – step 4 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 10 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). Figure 16. FRUIT Java Swing application Client App. UIUI Form Proc. Call FRUIT XForms Parsing Control Construc- tion Layout Policy Data Assembly Data Extraction Proc. Call Figure 17. FRUIT Java Servlet application Client App. UIUI Form Proc. Call FRUIT XForms Parsing Control Construc- tion Layout Policy Data Assembly Data Extraction C1 C2 Invoke URL FRUIT-in FRUIT -out

11 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.


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

Similar presentations


Ads by Google