Eliezer Kantorowitz's Home Page


Contact Information
Office: Taub 624 
Email: kantor@cs.technion.ac.il
Phone: (+972-4-829) 4321
Home: (+972-4) 8255981 
Mobile: (+972-544)825597 
fax: (+972-4) 8293900 
E. Kantorowitz
Computer Science Department
32000 Haifa
Table of Contents

      Table Of Contenets (TOC)

Research Topics

Research areas where I instruct students Toward Automatic User Interface Generation Component Oriented Programming (COP)Specificaion Oriented Programming (SOP)

Table of Contents

Toward Automatic User Interface Generation

Construction 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)

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

Table of Contents

Specification Oriented Programming (SOP)

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 Contents

Estimation of the number of defects that remains in inspected software documents.

User 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 Contents

Easy-to-Learn User Interfaces

Computer 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 Contents

Implementation and Extension Complexity

Difficult-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

Selected Publications

[1989]   E. Kantorowitz and O. Sudars ky, " The Adaptable User Interface ",
Communication of the ACM, 32, (Nov 1989),1352-1352
[1993]   E.Kantorowitz and Y. Schechner " Managing the Shape of Planar Splines by their Control Polygons ",
Computer Aided Design,(25),1993,355-364a
[1997-1]   E.Kantorowitz, " Algorithm Simplification through Object Orientation ",
"Software Practice and Experience", 27(2),1997,173-183
[1997-2]   E. Kantorowitz, L. Arzi, A. Gutmann "The Performance of the N-fold Requirements Inspection Method",
Requirement Engineering Journal, 2, (1997), 152-164
[1998]   E. Kantorowitz, "Is Extension Complexity a Fundamental Software metric?",
European Conference on Object Oriented Programming Workshop on Object Oriented Software Metrics, Brussels, 1998
[2000-1]   E. Kantorowitz, L. Arzi and A. Harel, "A Method for Evaluation of the Performance of Requirements Inspection", Proceedings of the 11th ESCOM (European Software Control and Metrics Conference) , Munich 2000
[2000-2]   E. Kantorowitz, R. Drabkin, A. Krits, "Fitting Correctly Shaped Splines to Ship Lines Given by Inaccurate Points",
Ship Technology Research, (47), 2000 , heft 2, 63-66
[2002]   E. Kantorowitz and S. Tadmor,
"A Specification-Oriented Framework for Information System User Interfaces",
8th International Conference on Object-Oriented Information Systems 2002
Workshop on Reuse in Object-Oriented Information Systems Design, LNCS 2426, Springer
[2005-1]   E. Kantorowitz and A. Lyakas, " Use-Case Components for Interactive Information Systems ",
Science of Computer programming,56(2005),5-21
[2005-2]   A.Harel end E. kantorowitz "Estimating the Number of Faults Remaining in Software Code Documents Inspected with Iterative Code Reviews" IEEE International Conference on Software - Science , Technology and Engineering
(SwSTE 2005), IEEE Computer Society 2005
Table of Contents

Biographical Data

1957 - M.Sc. Mechanical Engineering (Naval Architecture) Danmarks Tekniske Universitet (Technical University of Denmark)
1967 - Dr. Tech. Danmarks Tekniske Universitet (Technical University of Denmark)
1967 - Computer Science Dept., Technion - Israel Institute of Technology
Table of Contents

Valid XHTML 1.0 Transitional