Object View and Interaction Design

Journal of Information Science and Engineering, 1999

The ultimate goal of a programming environment is to help simplify the software development process. For an object-oriented language, a visual (object-oriented) programming environment (VOOPE) must at least satisfy four essential requirements to meet this goal: interactivity, integration, incrementality, and intelligence. In this study, object-oriented techniques were systematically applied to construct such a VOOPE. On the other hand, some characteristics of object-oriented languages, such as inheritance and polymorphism, may themselves be barriers to understanding, maintaining, and even constructing object-oriented programs. To solve, or at least alleviate, this problem, a languagebased editing process has been designed and incorporated into our VOOPE. This process contains two key elements: syntax-directed editing facilities and an in-place editing assistant, which facilitate object-oriented program development by providing useful programming guidance and by reducing the number of potential programming errors. We have so far developed a window-based environment prototype using Visual C++ and the Microsoft Foundation Classes library.

Lecture Notes in Computer Science, 1999

This paper reports the activities of the ECOOP'99 Workshop on Interactive System Design with Object Models (WISDOM'99). The paper presents the workshop rational, format, the discussion framework and its four identified issues: architecture, process, notation and traceability. The results of the workshop are proposals for a meta-architecture to develop interactive systems, an user-centered software development process framework, some comments on notation issues and finally a traceability model of user interface design. Furthermore this paper contains abstracts of all position papers presented at the workshop.

Journal of Visual Languages & Computing, 1999

The construction of interactive software is known to be a difficult task. As far as the non-interactive part of the application is concerned, designers can find support in the field of software engineering, using object-oriented design methods for example. With regard to the user interface per se, a number of interactive tools (interface builders) are available, that allows creating interactively the look and feel of the interface. However, relating an object-oriented design with a proper user-interface design is still a matter of craft and experience, and few techniques permit the seamless integration of the two.

Proceedings of the twenty-seventh SIGCSE technical symposium on Computer science education - SIGCSE '96, 1996

With Pascal waning in popularity as the CS1 language of choice, many colleges and universities are considering the adoption of C++ (an imperative and object-oriented hybrid language) as its replacement. An important issue that must be addressed in making such a change is the question of what software design methodology should be taught to CS1 students. Two common answers are (i) continue teaching structured design in CS1 and switch to object-oriented design in CS2; or (ii) teach object-oriented design from the outset in CS1. We believe that both of these approaches have significant drawbacks. To avoid these drawbacks, this paper describes a graduated approach to object-oriented design that we call object-centered design. The approach introduces students to object-oriented design by the end of CS2 without an abrupt paradigm shift, and without requiring an early introduction of inheritance.

Technology of Object-Oriented Languages and Systems, 1993

Let's summarize the rules of thumb for good object-oriented design. The programmer is concerned with writing class definitions, while at run time, it is appropriate to talk of objects and their interactions: 1. Each class should be self-contained, providing a complete service of some kind. 2. Each should have a simple and small interface couched in the language of the application domain. If this is so, users of the class are able to ignore the details of its internal structure and implementation and concentrate on the interface. We call this abstraction. See Fig. 3. 3. Classes should hide their data, we call this encapsulation, only providing a small number of controlled methods or functions in the interface for accessing that data. These factors taken together enable separation of interface from implementation. The actual designs of the algorithms employed inside the classes can be changed as better, more efficient algorithms are found. After a design is complete, changes in a class implementation must not affect its interface. The effect on current and future users is then only in terms of efficiency: their applications need not be recoded to take advantage of the new class implementation. The advantages of separation of interface from implementation include rapid prototyping and graceful refinement. See Fig. 3. 4. The majority of the work at run time should be within objects, not in between objects. 5. The complexity of the system should be evenly spread amongst the objects. 6. Classes should be written with reuse in mind. This requirement impacts the interfaces, and may cause us to spend more time on design that we otherwise would. 7. Systems of classes should be written to solve a wide range of problems from the domain of the actual task at hand. We do not set out to write a program to solve a single problem, but a system of classes that solves a wide range of problems of similar type. The code that tailors the system to solve the specific problem at hand should be localized to a small number of classes. 8. Our designs should be easy to extend. We should ask how easy it is to add new data types and functionality. For example, in a 3D graphics program that deals with a small set of graphical objects, how easy is it to add graphical objects? If the program doesn't implement shadows, how easy will it be to add them (assuming the math is not too complex)? 9. We should try to minimize the number of classes in a design. This requirement may be subordinate to those of keeping the class interfaces small and simple, and of minimizing the inter-object communication.

Later this year, the Open University (OU) will offer the first presentation of a new course in object-oriented software technology. This course covers a wide range of issues from programming in Smalltalk to object-oriented analysis and design, to management of object-oriented projects. It is part of the Masters degree programme which is aimed at individuals who are involved in software development professionally. As with all OU courses, the course is to be taught using distance teaching techniques, so course materials are presented through a combination of media including written text, computer software and video. Each course is expected to have a lifetime of about six years-a long time in a field which is moving as rapidly as object-orientation. This paper discusses our experiences of designing the object-oriented analysis and design element of the course: the approach chosen, the difficulties encountered, and the solutions devised.

Journal of Object Technology, 2004

Nowadays, computers play a very important role, that is to say, as a communication tool between people. This introduces the interface between human and machines as a key player, therefore the importance of these interfaces. The existing software development processes recognize this importance but do not establish precise guidelines for the construction of the user interface as an activity within the system life cycle. This article describes a method for constructing user interfaces based upon interaction patterns. This method can be incorporated to an object-oriented software development process which fulfills certain characteristics. Interaction patterns describe interface design solutions favoring the development of a user interface prototype.

2008 15th Working Conference on Reverse Engineering, 2008

The Design Navigator is a tool for reverseengineering object-oriented programs into formal charts of any level of abstraction. We show how the Design Navigator discovers abstract building-blocks in the design of programs and how it visualises them in terms of LePUS3, a formal Design Description Language. We demonstrate why reverse engineering programs into a formal modelling and specification language is not only possible in principle but also of practical benefit.

Chemometrics and Intelligent Laboratory Systems, 1991

Mankind, under the grace of God, hungers for spiritual peace, esthetic achievements, family security, justice, and liberty, none directly satisfied by industrial productivity. But productivity allows the sharing of the plentiful rather than fighting over scarcity; it provides time for spiritual, esthetic, and family matters. It allows society to delegate special skills to institutions of religion, justice, and the preservation of liberty.