| Affiliations: | |
|
|
|
|||||
|
|
Research areas where I instruct students Toward Automatic User Interface Generation Component Oriented Programming (COP)Specificaion Oriented Programming (SOP)
Table of ContentsConstruction of Graphical User Interfaces (GUI) can involve as much as 25% of the total system development costs. A considerable amount of research is therefore done world wide for reducing these high GUI development costs. Our contribution to this research is a new combination of component technology and abstract semantic interfaces. [2002] [2005] In our approach a program is composed of two major components. The application logic (AL) component contains the code that implements the business logic of the application. The second component is the interaction style (IS) component that implements and manages the GUI. The interface of the IS component is abstract, i.e. the developer specifies only the needed action, but not how to do it. If, for example, a developer wishes to select one of a set of choices, she will employ the Select.one() interface method. Different IS components may implement this method differently. One IS component may implement this method by generating a menu, where the user can do her choice. Another IS component may produce a set of radio buttons, where the user makes her choice. The important point is that the programmer of AL component does not write GUI at all. Instead the programmer call such abstract methods as Select.one(). The AL programmer can, therefore, better focus on the correct implementation of the business logic. This complete separation of Gui code and the application logic code in two separate components is possibly one of the most useful results of our research. One of the consequences of this separation is that if the programmer is unhappy with the appearance of the produced GUI, she can simply exchange the IS component with one that produce a more satisfying GUI. Changing the appearance of the GUI requires thus no changes in the code of the AL component. Porting the system to another platform is done solely by exchanging the IS component with an IS component designed for the new platform. Again, the code of the AL is not changed when porting to a new platform. A major weakness of our technology is that the appearance of the GUI produced automatically by the IS components may not be satisfactory in some real life applications. An in depth investigation of this issue is required.
Table of Contents
Component Oriented Programming (COP) is considered to be a
programming paradigm by its own right. The goal of COP is to facilitate
the construction of systems from ready made of the shelf components.
To achieve this each COP component is compiled separately and stored .
A system is put together by combining a number of such stored compiled components.
A component framework specifies an interface that all its components must have.
This interface is used to connect the different components of a system.
No compilation is therefore required in order to connect the components into a system.
Constructing a system from components is therefore a fast process.
An example of the usefulness of the COP paradigm
is found in the previous section (Toward Automatic User Interface
Generation), where a GUI component called IS is
combined with an application logic component called AL through
an abstract interface.
[2005]
The advantage is that it is easy and
fast to change an unsatisfactory GUI of an application by exchanging its IS component
with an IS component that produces a more satisfactory GUI..
I have some
ideas on further applications of the COP programming paradigm, that
may be good research topics
Verifying that the code of a system implements its specifications correctly involves usually high costs. A considerable amount of research is therefore done world wide in order to improve both testing techniques and formal verification methods. Our contribution in this area is the development of a specification oriented programming (SOP) approach. [2002] [2005] The basic idea is to develop tools enabling a direct translation of the specifications into code. The resulting code should be " similar " to the specifications. The similarity between the code and the specification should be of a nature that facilitates the verification. There is place for investigations on what similarities are useful and on how to use the similarities in the verification process. Such investigations may utilize some existing results on practical and formal construction of use case specifications. Our practical experiments with the SOP approach suggest its usefulness. I believe therefore that this research has a good potential.
Table of ContentsUser requirements documents (URDs) are usually inspected by human inspectors for faults. The detected faults are removed from the URD. The number of defects that remains in the URD after this process is estimated. If the number is high, a new inspection is required. In this research we developed a new estimator for estimating the number of faults that remains after an inspection. [1997-2] [2000-1] [2006] Experiments suggest that the estimator is sufficient accurate. The developed probabilistic model provides metrics for the performance of the inspectors. The metric enable comparing the performance of different kinds of inspectors with different kinds of URD.
Table of ContentsComputer users invest a considerable amount of time in learning how to use their applications. This learning effort limits the number of applications, which a user can learn and use. It has been observed that many users avoid applications that requires considerable learning. Ease-of-learning is therefore important for the marketability of computer applications. The purpose of a research done together with Dr. Yoram Hazan was to get some insight on what makes an application easy-to-learn. The study employed the IRIT solid modeler for construction of images of geometrical shapes. We developed two different Graphical User Interfaces (GUIs) for IRIT. The first GUI was designed in the style that is typical for applications developed for the WINDOWS environment. This GUI was called the WINDOWS GUI. The second " easy-to-learn GUI " was designed to minimize the learning effort. The design of this GUI employed known pedagogical principles. The usability of these two different GUI ' s was tested in carefully designed behavioral experiments with users who employ computers 1-2 hours per week. The learning time for the easy-to-learn GUI was about 30% less than the learning time for the " typical WINDOWS GUI ". An interesting observation was that users were more comfortable with the easy-to-learn system (less afraid) and did on their own initiative some experiments exploring the capabilities of the system. The users exploited the capabilities of the easy-to-learn system more efficiently than those of the WINDOWS system, which indicates that they got a better understanding of the easy-to-learn system. These observations suggest that the benefit of systems that are easy-to-learn is not only in the saving in learning time, but also in providing a comfortable user experience and in enabling a more efficient exploitation of the capabilities of the system.
Table of ContentsDifficult-to-extend legacy software is a major problem in the industry. The extension complexity concept was developed during the extension of a legacy Computer Assisted Design software of a shipyard [1997-1] and [1998]. The extension complexity of a given piece of software expresses the class of costs involved in extending the software with new functionalities. The concept is analogous to time and space complexities of algorithms, but is concerned with software manufacturing costs. Extension complexity is usually quite easy to estimate. There are both practical and theoretical indicators that extension complexity captures some fundamental software quality characteristics. The subject deserves further investigation.
Table of Contents
