Motivation and Goal of This Thesis

The conventional approach to develop Man Machine Interfaces for storage system has limited flexibility while the MMI requirement is changed. During development phase, programmers have to change their handcrafted MMI application code again once the MMI requirement is changed. This change may occur repeatedly until the MMI requirement under consideration is satisfied.

For instance, we can study the cases in figure 3. The case on the left side is the MMI development for serial products, and the case on the right side is the MMI maintenance for different customers.

Figure 3 Various MMIs for Serial Products and Different Customers

1) For the case on the left side of figure 3: The MMI requirement for product version 1.1 (with 4 ports to connect hard disk drives) only requires basic functions of the storage system, while the MMI requirement for product version 1.2 (with 8 ports to connect hard disk drives) requires additional advanced functions. MMI designers have to change the menu size to support more ports for more hard disk drives, and more advanced functions for the new serial products. Consequently, MMI programmer must modify their MMI programs to meet these changes.

2) For the case on the right side of figure 3: Different customers bought the same kind of product. Customer A wants to change the layout of MMI into layout A, while customer B wants his layout of MMI in layout B. Since layout A and B are different, the MMI designers and programmers must maintain various MMI programs for these different customers eventually.

Unfortunately, the time to market is usually very short and the human resource to develop and maintain products is very tight, how to shorten the MMI development time and reduce maintenance effort become a major issue for the market competition.

In this thesis study, we attempt to conquer above problems by using Visual-Based UI Construction Methodology to design the Visual MMI Development for Storage Systems. After the construction of this system, we also demonstrate the feasibility and applicability of the Visual-Based UI Construction Methodology.

Chapter 2 Related Work

In this chapter, we describe the related work of conventional MMI development, the Visual-Based UI Construction Methodology, and the conventional software framework for MMIs of storage systems.

2.1 Conventional MMI Development

In a general software process, we follow the principles and models of Software Engineering [3], e.g. Waterfall Model in figure 4. During a general software life cycle [4], we compose requirement documents and specifications, plan and design architecture of system and software framework, implement modules on target platforms, do many tests on units and system for verification and validation, and maintain software for upgrade and optimization.

Figure 4. The Waterfall Model for Software Process Requirements

definition

System and software design

Implementation and unit testing

Integration and system testing

Operation and maintenance

Figure 5. The Concept of Conventional MMI Development

In the brief illustration of figure 5, the concept of conventional MMI development [5], MMI designers have to compose MMI requirement documents with screen layouts or menu tree, etc, and system designers compose functional and other requirement documents.

According to these requirement documents, programmers implement MMI, functional and other programs, and compile them together and produce applications. However, these applications are implemented for specific environments, e.g. Booting Utility in BIOS / EFI environment, Pre-OS Utility in EFI Shell or Win-PE environments. It is hard to design reusable programs for all MMI utilities of storage systems. Usually their MMI programs mix with functional programs and others. Therefore, programmers have to take long time to modify, or develop new programs when MMI requirements were changed. Also, we need much effort to maintain these utilities for serial products and various customers.

2.2 Visual-Based UI Construction Methodology

The Software Engineering Laboratory of NCTU had developed Visual-Based User Interface Construction Methodology [6]. We illustrate the concept of this methodology in figure 6 briefly.

Figure 6. The Concept of Visual-Based UI Construction Methodology

In this methodology, MMI designers use visual authoring tool to compose MMI prototype according to MMI requirements. The visual authoring tool can generate MMI programs. Programmers implement functional and other programs as API library for MMI programs. We can bind the related functions to MMI components, and then produce application utilities very efficiently.

Figure 7 illustrates the detail framework of Visual-Based User Interface Construction Methodology. This methodology supports the UI Visual Requirement Authoring System for UI designers to produce GUI-based requirement scenario and specifications. It also supports the Program Generator to generate the target application system as specified in the visual requirement representation. The programmer can produce the target application system, base on the function binding features provided in the program generator to bind each GUI component with the associated application function.

Figure 7. The Framework of Visual-Based UI Construction Methodology

The main components of this system are described as follows:

1) UI Visual Requirement Authoring System: It is a visual-based authoring tool. The UI designers use the UI Visual Requirement Authoring System to create a prototype of user look and feel. Then one can edit this prototype by adding more text or buttons. The UI designers can preview the prototype and modify it. Once the authoring process is completed, the UI designer has generated a target UI system.

2) MRCs Manager: MRC (Multimedia Reusable Components) is the basic component in visual requirement presentation, contains multimedia data by the object-oriented method. It has its own attributes, and accepts external signal to trigger actions. The UI designer uses the existing MRCs to produce the visual UI prototype via visual UI authoring tool. If there are no existing MRCs, the UI designer uses the component constructor to produce new MRCs and then adds it to the MRCs Manager for further use in the visual UI authoring tool.

3) Template Manager: It is a database management system for managing UI templates, e.g. structure template, layout template, and style template. It provides an interface for adding or deleting UI templates as well as for retrieving an existing UI template. Template constructor can make new UI templates and then stores them into UI template database through the Template Manager.

4) Program Generator: It is a function binding system that generates the program for target system based on the binding of a UI icon to an API function for the underlying device.

When the design of user look and feel is satisfied, the UI designers use the program generator to produce the source code of application. The program generator produces the source code target application system. The Program Generator applies the software framework to generate the source code. A software framework is a platform for representing the visual representation that is generated by the authoring system. Programmers can instantiate a software framework from the generic software framework.

6) Function Library Component: It is a set of pre-defined library. Programmers develop associated functions based on API (Application Program Interface) library functions, and implement them according to the hardware specification. The Program Generator applies this function library to produce source code for target UI system.

This UI Visual Requirement Authoring System is especially suitable for the UI designer. The visual-based authoring system helps the UI designers to create a prototype of MMI in an efficiency way. The UI designers can edit and preview this prototype and verify its functionality on PC. After the design of MMI is frozen, the UI designer can apply this authoring system to produce the target UI program without writing any textual code. The authoring system uses the code generator to translate the visual representation to source code.

The code generator resolves the relationship between the MMI and the application functions of device drivers. It applies the designed framework and function library in code generation phase.

The Visual-Based User Interface Construction Methodology can improve the productivity, quality, and maintainability of MMI software efficiently [7]. This methodology claims for the following benefits:

1) Replace voluminous textual documentations

2) Support rich multimedia UI components such video, audio, image, and animation for UI designer to easily and quickly authoring visual UI prototype.

3) Generate visual MMI prototype without writing textual based program 4) Independent work between MMI designer and programmer

5) Provide more natural means of communication to reduce misunderstanding between MMI designer and programmer

6) Based on the experiment results, it depicts that using this methodology can reduce the development and maintenance time during the construction of MMI system [7]

7) Elicit an early feedback from user, more expressive in describing user’s demands 8) Based on the experiment results, it depicts that using the proposed methodology can

reduce the development and maintenance time during the construction of UI system

In figure 8, some experimental data in the dissertation, “Generating User Interface for Mobile Devices Using Visual-Based User Interface Construction Methodology” [7], are recalled here.

Figure 8. Comparisons between Conventional and Visual-based UI Construction [7]

In the left chart of figure 8, the experiment results compare the development time between the Conventional MMI Development and Visual-Based User Interface Construction Methodology. Based on the collected data, the upper line with circle dots represents the development time that students use the Conventional MMI Development, and the average time spent is 420 minutes. The lower line with square dots represents the development time that

students use Visual-Based User Interface Construction Methodology, and the average time spent is 376 minutes.

In the right chart of figure 8, the experiment results compare the maintenance time between the Conventional MMI Development and Visual-Based User Interface Construction Methodology. The upper line with circle dots represents the maintenance time that students use the Conventional MMI Development, and the average time spent is about 154 minutes.

The lower line with square dots represents the maintenance time that students use Visual-Based User Interface Construction Methodology, and the average time spent is about 140 minutes.

Both charts in figure 8 reveal the development and maintenance time of Visual-Based User Interface Construction Methodology are less than the Conventional MMI Development.

2.3 Conventional Software Framework for MMIs of Storage Systems

We analyze conventional software framework for MMIs of storage systems, and generalize four layers: 1) MMI Program, 2) Management API, 3) Driver Layer, and 4) Embedded Firmware.

Here is a short example to describe the relationship between these layers. The end-users use the MMI Program to display the information or configuration of storage systems.

Before MMI Program displays these data, it calls the functions of Management API to get the particular data, and then it arranges the data into the display screen. Management API is a function library, and its functions can submit management commands to get the information or set the configuration of storage systems. These commands will pass to Driver Layer because this is the software layer to transfer commands to hardware devices. In the internal side of storage systems, Embedded Firmware handles commands from host side and response them with particular results.

Figure 9 illustrates the Conventional Software Framework for MMIs of Storage Systems with these four layers.

Figure 9. Conventional Software Framework for MMIs of Storage Systems

We describe these four layers in the following paragraphs.

1) MMI Program: According to MMI specifications, programmers implement MMI programs for particular utilities. For instance, they implement the MMI program in assembly language for Booting Utility, C language for Pre-OS Utility, Java for Web-based Utility, etc.

These MMI Programs call Management API to get information or change the setting of storage systems. For Embedded Utility and LCD Panel of storage systems, there are related applications embedded in firmware side.

2) Management API: Management API is a library with many functions for utilities to get information, fetch strings, or change the setting of storage systems. For example, function MngApi_GetCtrlInfo( ) can get controller information, and function MngApi_GetPdInfo( ) can get physical drive information. The other functions can set logical driver’s cache policy, etc.

First, the Booting Utility of storage systems includes basic functions only, so it usually uses minimal Management API. Second, the Pre-OS Utility is similar to Booting Utility, but it includes some advanced functions, and needs some additional Management API for these advanced functions. Third, the Web-based Utility includes full functions of storage systems, and of course, it uses full Management API of storage systems.

3) Driver Layer: Driver provides the capability to submit commands to hardware devices. Usually Management API submits a set of management commands, or called IOCTRL (IO Control) commands, to Driver Layer. No matter BIOS / EFI driver, Pre-OS driver or OS driver will pass these commands to the embedded firmware of storage systems.

4) Embedded Firmware: In the internal side of storage systems, there are embedded operating system and firmware core running. Firmware core handles commands from host side, transfer data to the buffer of Management API by DMA (Direct Memory Access), and return the status of commands to host drivers. For Embedded Utility and LCD Panel of storage systems, the related applications are running in embedded OS also.

Before MMI programs display the information of storage systems, they must call the functions of Management API to get the wanted information. Management API provides many functions for MMI programs and submits management commands to firmware by passing through the Driver Layer to get data. Driver passes management commands to firmware and returns the status of commands for Management API. Embedded firmware takes the responsibility to handle management commands and take the actions for them. For example, Embedded Firmware collects information of adapter controller or hard disk drives, or changes the setting of disk array, etc.

Chapter 3

System Design and Implementation

In this chapter, we describe the design and implementation of the Visual MMI Development for Storage Systems, and derive the Generic Software Framework for the MMI Generation of Storage Systems.

3.1 Visual MMI Development for Storage Systems

In this section, we design the model of Visual MMI Development for Storage Systems. This model uses similar concept of Visual-Based User Interface Construction Methodology, MMI designers use visual authoring tool to compose MMIs, and programmers write functional and other programs separately. Figure 10 illustrates this concept.

Figure 10. The Concept of Visual MMI Development for Storage Systems

However, the difference between Visual-Based UI Construction Methodology and Visual MMI Development for Storage Systems is the output of the Visual Authoring Process.

In the previous methodology, Visual Authoring Tool generates MMI program, and programmer binds functions from functional library to MMI program and generate MMI applications.

We change the output of the Visual Authoring Process becomes MMI data, and let Generic MMI Engine to manipulate this MMI data directly. This change is due to the consideration on some limitations for MMI utilities of storage systems. With this change, we can implement the Generic MMI Engine for various environments.

Figure 11 illustrates the framework of Visual MMI Development for Storage Systems.

Figure 11. The Framework of Visual MMI Development for Storage Systems

This framework includes the following major parts:

1) Visual Authoring Tool: MMI designers use the Visual Authoring Tool to compose wanted MMIs according to MMI requirement documents. During implementation, we choose Inkscape as this tool. Please refer to section 3.3.1 Visual Authoring Tool -- Inkscape.

2) SVG Files: These files are the output of Visual Authoring Tool. We use the file format in SVG (Scalable Vector Graphics) that is a standard language to describe two-dimensional graphics and graphical applications in XML (Extensible Markup Language).

Please refer to section 3.3.2 SVG Files.

3) Template SVG Files: These files are the SVG files with templates of MMI elements.

To speed up the development of MMIs, we can create these files for MMI designers first. All SVG files can be previewed in some web browsers, e.g. Firefox.

4) SVG Parser: This parser can parse the SVG structure, and obtain required information from SVG files. It invokes some functions of XML parser. Please refer to section 3.3.3 SVG Parser.

5) MMI Data: The output data of SVG Parser is MMI Data. It is also the results of Visual Authoring Process. Generic MMI Engine can manipulate the MMI Data directly.

Please refer to section 3.3.4 MMI Data.

6) Generic MMI Engine: This is the kernel component of Visual MMI Development for Storage Systems. It needs the Management API and OS Dependent API to accomplish the functionalities of target MMI application. Please refer to section 3.3.5 Generic MMI Engine.

7) Management API: This API (Application Program Interface) is depended on the features of storage systems, and it provides functions to manage underlying storage devices.

MMI programmers have to program these functions according to functional requirement documents, and Generic MMI Engine will invoke these functions.

8) OS Dependent API: Generic MMI Engine requires some functional APIs but they are OS dependent. For instance, it needs Input API to get the input of keyboard or mouse, and Display API to display the MMIs to the monitor screen of computers. We separate the OS dependent code to OS Dependent API, and let the implementation of Generic MMI Engine become more easily for various environments.

9) Target MMI Application: After MMI designers compose MMIs with Visual Authoring Tool, save them as SVG files, and use SVG Parser to transform SVG files to MMI data, we can generate target MMI application with MMI data, Generic MMI Engine, Management API and OS Dependent API.

To use the model of Visual MMI Development for Storage Systems, we describe its flow in the following steps:

Step 1) MMI designers use Visual Authoring Tool to compose wanted MMIs according to MMI requirement documents

Step 2) Save the results of Visula Authoring Tool as SVG Files.

Step 3) To speed up the development of MMIs, we can create Template SVG Files for MMI designers.

Step 4) For developers or customers, they can preview these SVG Files in web browsers.

Step 5) MMI programmers add additional information in SVG Files.

Step 6) Use SVG Parser to transform SVG Files to MMI Data.

Step 7) MMI programmers program related functions in Management API according to functional requirement documents.

Step 8) Generate the target MMI applications with MMI Data, Generic MMI Engine, Management API and OS dependent API.

3.2 Generic Software Framework for the MMI Generation of Storage Systems

The conventional software framework for the MMI generation of storage systems lacks of the support of a visual authoring system. We therefore incorporate a visual authoring system into the software framework for MMIs of storage systems. The incorporated Visual Authoring and MMI Engine are shown in figure 12. We call the new software framework as Generic Software Framework for the MMI Generation of Storage Systems, since it can be used to generate Man Machine Interfaces of many storage systems.

Figure 12. Generic Software Framework for the MMI Generation of Storage Systems

There are also four layers in Generic Software Framework for the MMI Generation of Storage Systems: 1) Visual Authoring Process, 2) Generic MMI Engine, 3) Driver Layer, and 4) Embedded Firmware. We introduce the new layers:

1) Visual Authoring Process: MMI designers use Visual Authoring Tool to compose each MMI according to the MMI requirement specification for particular utility. The authoring tool is visualized and very user-friendly. After save the results in SVG files and use SVG Parser to parse these files, we can get the MMI data for Generic MMI Engine at the end

1) Visual Authoring Process: MMI designers use Visual Authoring Tool to compose each MMI according to the MMI requirement specification for particular utility. The authoring tool is visualized and very user-friendly. After save the results in SVG files and use SVG Parser to parse these files, we can get the MMI data for Generic MMI Engine at the end