Design Strategies and Knowledge in Object-Oriented Programming: Effects of Experience

Abstract

running head title: Design Strategies and knowledge in OOP * Françoise Détienne is a cognitive psychologist with an interest in software design; she is a researcher in the Ergonomic Psychology group of INRIA. Human-Computer Interaction, 1995, 10 (2 & 3), 129-170. http://hci-journal.com/ Published in ABSTRACTAn empirical study was conducted to analyse design strategies and knowledge used in object-oriented software design. Eight professional programmers experienced with procedural programming languages and either experienced or not experienced in objectoriented programming participated in this experiment. They were asked to design a program for a procedural problem and a declarative problem.We have concentrated our analysis on the design strategies related to two central aspects of the object-oriented paradigm: (1) associating actions, i.e., execution steps, of a complex plan to different objects and revising a complex plan, and (2) defining simple plans at different levels in the class hierarchy.As regards the development of complex plans elements attached to different objects, our results show that, for beginners in OOP, the description of objects and the description of actions are not always integrated in an early design phase, particularly for the declarative problem whereas, for the programmers experienced in OOP, the description of objects and the description of actions tend to be integrated in their first drafts of solutions whichever the problem type.Most of the first drafts of solutions were structured around the objects, whatever the experience of subjects in OOP. However, by analysing the order in which actions are generated, we found that, for the programmers experienced in OOP, methods were grouped together mainly by membership to the same class whereas, for beginners in OOP, methods were grouped together mainly by functional similarity and execution order. Furthermore, with only a little experience in OOP complex plans are revised more often.Published in Human-Computer Interaction, 1995, 10 (2 & 3), 129-170. http://hci-journal.com/ As concerns the development of simple plans at different levels in the class hierarchy, our results indicate that with a little OOP experience, simple plans are developed either in a top-down manner or in a bottom-up manner. With more OOP experience, our results show that a simple plan is developed in a strictly top-down manner.The analysis of design strategies reveal the use of different knowledge according to subjects' language experience: (1) schemas related to procedural languages; actions are organized in an execution order, or (2) schemas related to object-oriented languages; actions and objects are integrated, and actions are organised around objects.

Assessing the cognitive consequences of the object-oriented approach: A survey of empirical research on object-oriented design by individuals and teams

“…Our results (Détienne, 1995) tend to show that the definition of the structure of classes is more error prone for a declarative problem. This suggests that when a strong data structure known from procedural languages is transferred, the resulting representation includes unnecessary classes and/or objects structured in a way more appropriate to procedural programming.…”

“…It seems that the use of these strategies may be a function of the expertise and of the type of problems. Concerning the effect of expertise, Détienne (1995) observed that novice OO designers more often used a procedural plan, i.e., a procedure-centred strategy, than experienced OO designers. Experienced OO designers tended to use mostly a declarative plan based on the objects, i.e., an object-centred strategy.…”

“…Détienne (1995) suggests that different schemas, depending on subjects' language experience, are used for planning activities. Schemas related to procedural languages group actions in execution order.…”

“…For example, it is clear that the CO2 environment and language (Détienne, 1995) have order constraints (an object cannot be used in a method body if it has not been completely specifed before) which force a top down development of the solution. This causes premature commitments and entail many revision afterward.…”

“…We have been particularly interested in comparing the errors made in declarative problems and procedural problems (Détienne, 1995). In declarative problems, the program structure is strongly constrained by the data structure: the representation of this structure guides problem development.…”