Showing papers on "Applied science published in 1997"

Design issues in computer science education

Abstract: classes should emphasize uniformity and parsimony by encapsulating information that needs to be hidden and by providing information that needs to be communicated. The decision about what needs to be hidden or communicated must be made in the context of the particular software that is being designed. Hiding hedges a designer's bets about what implementation details are likely to change. As [2] points out, it is impossible to have infinite design flexibility and allow for all possible changes. Therefore, abstract classes need to be tuned to a particular programming situation and the design areas most likely to undergo change. This insight has important pedagogical implications. For one thing, it explains why if you examine a dozen textbooks on data structures you will find a dozen variants of an abstract list class. Each author has envisioned the use of the list class within the context of the software in the book and chosen a set of abstractions to communicate and a collection of details to hide. Since each book has a different teaching philosophy, it is no wonder that these list abstractions turn out to be different. As teachers, we should not attempt to present the list class but should rather discuss the variety of ways in which a list might be abstracted to meet specific design flexibility goals. More generally, abstract classes are not the basic unit of reusable software. What is reusable are concrete classes that are complete and relatively open to access and extension. Pedagogically, this means that we must give careful consideration to the design of concrete classes as well as to the building of abstract layers on top of such classes. The implications of the need to tune abstract classes to the design flexibility goals of a particular piece of software is that abstract classes had better be easy to build. To accomplish this, the member functions in an abstract class must have simple implementations. Ideally, each member function in an abstract class should be implemented by at most three lines of code that refers to some underlying concrete object: setup, make-concrete-call, cleanup. Degrees of Abstraction and Practical Issues Of course, in a practical world (both in industry and in the classroom), we do not always do what is ideal. There is a great temptation to design an abstract interface and then I December 1997 5 Vol. 29 No. 4 inroads SIGCSE Bulletin code substantial algorithmic details into the implementation. However, to the degree that an abstract class does concrete algorithmic work, it ceases to be abstract. If an abstract class does concrete algorithmic work then it will not be easy to change these implementation details and the benefits of abstraction will be lost. At the same time, the algorithmic work will be hidden by an interface which fails to deliver its full potential to the caller. Hence, when the algorithm is needed again in a different context, the class wrapper may have to be redesigned anyway. Let's name this phenomenon. We will call a class quasi-abstract if it has an abstract interface but has an implementation which directly codes substantial algorithmic details. Many examples used in texts for abstract classes are really more precisely quasi-abstract classes. This means that the data representation is hidden properly, but that the algorithmic work has been done inline rather than being similarly encapsulated. To some degree, such a class is a design compromise and should be recognized as such in a teaching setting. Recognition of this compromise is crucial to dealing with it from a design perspective. As educators, the reason that we tend to drift into quasi-abstract classes is twofold. On one hand, we do not have a robust enough set of concrete classes to build upon. On the other hand, to create a truly abstract class, we may need to add another level of abstraction and the pain of additional names and class definitions is too much to bear. Certainly, in the context of busy courses, there is sometimes not enough time to do everything in the best possible way. Nevertheless, we should try to set design standards and, when we need to compromise, we should be explicit about what we are doing and why. Teaching is about being aware. Toolkits and Environments If we wish to teach design then we must work in an environment that is rich in tools. As Eric Roberts states [10]: Students need exposure to modem software development practices. It is no longer acceptable to teach programming by having students write small, self-contained programs from scratch. Even though we cannot predict exactly what toolkits and programming environments students will use when they graduate, it is essential that they learn to work with some modem programming environment that forces them to add small amounts of special-purpose code on top of a large existing infrastructure. Moreover, this experience should come early in the curriculum so that students can apply these techniques in summer internships and their more advanced courses. In addition to reflecting current practice, there are important pedagogical reasons for students to work within a framework of existing code, tools, and class structures. The most important reason for asking students to extend or modify existing code is to permit them to see and explore a large base of well designed code. If we provide a partial solution to an assignment, we have the opportunity to model the kind of software design principles we preach. If we provide a set of tools to be used in a number of assignments, we have a chance to show what we mean by quality reusable software. The code we deliver to students is our stake in the ground about what quality design means in practice. As students progress in the curriculum, they must be exposed to large scale commercial development environments. Although source code is usually not available in such environments, students can still learn by studying the pros and cons of the class libraries provided in the environment. A large scale class library may be used as a set of examples against which the design methodologies in textbooks can be examined. Students can learn about the strengths and weaknesses of both the libraries and the methodologies. It must be recognized that it will not be easy to have faculty everywhere use framework code, toolkits, and advanced environments. Few faculty have the support structure necessary to build large quantities of code. Those of us who have designed and built such pedagogical code must make every effort to distribute this work to faculty at other institutions. However, due to portability issues, this distribution task is not easy. Therefore, it will take time for good code and lab depositories to be put into place. The main obstacle to the faculty use of large scale commercial development environments is the time it takes to grasp the class libraries. With documents that are several inches thick, it must be considered a non-trivial task for faculty to learn an environment well enough to use it in teaching. Hopefully, CS units will begin to allow time for their faculty to pursue this learning process. Design and the Software Project Course In most institutions, students take a junior/senior project course in which they learn about software design and development in a team setting. Ideally, this course should provide a situation in which the design principles learned in earlier courses are put into practice and new design principles applicable to large scale projects are taught. Unfortunately, it is often the case that the project course is a negative design experience. The course is often treated as a rite-of-passage in which students are expected to work ridiculously long hours in order to finish a project on time. SIGCSE Bulletin i n r o a d s Vol. 29 No. 4 6 December 1997 Under these circumstances, there is no incentive for students to ponder a design, explore alternatives, and backtrack to make improvements. Just as in the freshman courses, solving the problem is enough however ugly the code or the design. Of course, students know that there is some penalty for poor design but they also know that the biggest penalty is for not having a running program that roughly meets the specs. We believe that the project course must cease to be a rite-of-passage and instead must become a serious investigation of design issues. Using an incremental approach to building software, students should be encouraged to add class structures and then build working partial solutions every 2-3 days ifpossible. If students "fall behind" in terms of meeting the most ambitious project goals, they should be permitted to "make up the grade" by explaining in writing what design pathways they explored and why their design is of higher quality because of this exploration. The grades will then depend not only on how much the students did but also on what they learned along the way. Design is ultimately a human process and, beyond a reasonable level, stress is counter-productive for the creative work that design requires. If we believe that it is possible to have both rapid development and well designed software [3], then we must use the project course to teach students how this can be accomplished. We must be models of best practice and we must not encourage the mistakes so often committed in industry. We need to make the project course a calm, humane, creative, and rational design experience. Our students will then be able to bring to their future work both good methodologies and good attitudes.

The Educational Use of Computer Based Science Simulations: Some Lessons from the Philosophy of Science

Abstract: The recent proliferation of science simulation software presents philosophy of science instructors with a viable means to reaching greater numbers of students in both science and non-science majors. The software, when combined with an interrogative approach which construes science as a pragmatically constructivist process, provides the opportunity to explore myriad practical and conceptual problems. This paper examines some of the potential, and some of the problems, inherent in using computerized simulations in science and science studies classes by applying lessons from the epistemology of science. It concludes that, while computer simulations are extremely useful pedagogical tools, they are not experiments, and are thus of only limited utility as a substitutes for actual laboratories.

Teamwork: computational science and applied mathematics

Abstract: Computational science and engineering, or CSE, is a relatively new and rapidly evolving field of study. It draws heavily on other fields, often using interdisciplinary teams of mathematicians and computer scientists working with scientists and engineers to solve problems requiring multiple areas of expertise. In this paper four examples of computational science in action illustrate the relation between CSE and the distinct but complementary disciplines it draws upon, focusing in particular on mathematics. Each example illustrates the need for interdisciplinary work. The training necessary for success in computational science, not surprisingly, is somewhat different from that traditionally prescribed by single academic disciplines. The use of the term applied mathematics is a little arbitrary. Some, applied mathematicians working in areas such as fluid dynamics are unconnected with applications, while the work of some core mathematicians in areas such as string theory and number theory makes fundamental contributions in applied areas such as mathematical physics and cryptography. We take applied mathematics to be that part of mathematics used in science and engineering.

A taxonomy for computer science

Abstract: We try to capture the essence of information technology and computer science, arguing that information technologists have the same principal goal as all technologists: to create machines with certain properties. To achieve this, they formalize the problem, i.e. abstract the properties into a specification and invent or develop a schema, i.e. an abstraction of the machine’s structure. Subsequently, it is their principal task to prove that the schema satisfies the specification. Computer scientists develop mathematical and physical means to support or even enable that task. From this, the principal research questions of computer science may be derived. From this viewpoint, we try to propose a consistent set of notions together with a consistent terminology, which may clarify the relation of information technology and computer science to other scientific disciplines and also give rise to new ideas about computer science education.

Paradigms for educational research in computer science

Abstract: Computer science education can benefit from the adoption of a multiparadigm perspective. Just as it is essential to have a theoretical framework on which to drape the research experience, it is suggested that the sub-discipline of CS educational research is enriched by recognition of the existence of multiple frames, even where they may not all be open to the full experience of any one researcher. This paper presents some glimpses of the potential value to Computer Science education of three paradigms: positivistic, interpretivistic, and critical. 1. The concept of “Paradigm” The term paradigm was coined by Thomas Kuhn [9] to express an alternative concept of the history of science to that of the dominant beliefs of the time. Convention dictated that advancement in science was a continuous linear process. This view of ongoing progress was challenged in the 1930s by a philosopher, Gaston Bachelard, who presented the history of science in terms of epistemologically disparate episodes [2]. Kuhn rejected the notion that Newtonian physics was an incremental improvement on top of Aristotlean physics, suggesting instead that Newton proposed a revolutionary new world view. Permission to make digital/hard copy of all or part of this work for personal or classroom use is granted without fee provided thet copies are not made or disuibuted for prom or wmmercial atiantage, the copyright notice, the title of the publication and its date appear, and notice is given that copying is by permission of ACM, Inc. To cow otherwise. to reoublish. to o-as3 on servers or to redistribute to Ii&, requires .prior &ecific p&mission and/or a fee. ACSE’97. Melbourne, AMralia Q 1997 ACM O-69791.95b0/97/0007 . . ..$3.50 Such new “paradigms” required the disintegration of existing modes of thought (via a build-up of anomalies) in order to be accepted by the establishment and become regarded as science. That is, there is a period of negotiation and social construction involved in the acceptance of that which constitutes “science” at any one time in history. In computer science, the word “paradigm” is commonly used in the context of programming languages. For example, Ambler et al [I] state that A programming paradigm is a collection of conceptual patterns that together mold the design process and ultimately determine a program’s structure. Such conceptual patterns structure thought in that they determine the form of valid programs. They control how we think about and formulate solutions, and even whether we arrive at solutions at all. The sense in which the adoption of a particular paradigm determines how the problem-space is structured is apparent. As computer scientists we are likely to be swayed by the argument that different programming paradigms are useful for different purposes. Educational research also benefits from being a multiparadigm discipline. In this paper a discussion of the nature of three paradigms in educational research the positivistic, interpretivistic, and critical is followed in each case by a brief account of an example in the area of computer science education. It is intended that this form an argument for a multiparadigm approach to educational research within computer science. 2. Qualities of paradigms in educational research It should not be supposed that there is full consensus on the definition of a paradigm within the educational research community. Even Kuhn has been accused of being highly inconsistent with his use of the word. It therefore pays to define it on each occurrence of its usage. Here, the definition that will be used is one given by Guba and Lincoln [5]: . ..paradigms are basic belief systems; they cannot be proven or disproven, but they represent the most fundamental positions we are willing to take. If we could cite reasons why some particular paradigm should be preferred, then those reasons would form an even more basic set of beliefs. At some level we must stop giving reasons and simply accept wherever we are as our basic belief set our paradigm... This definition highlights the fundamental nature of a paradigm. It may be thought of as a “worldview”, shaping the motivation, meaning and interpretation of a research enterprise. Paradigms are often defined in terms of a number of components which help to locate the world-view from which research is conducted. This includes an ontological component (which states how the paradigm defines what there is to be known) and an epistemological component (which states how the paradigm addresses the relationship between the “knower” and the “known”). A tripartite paradigm model is used in this paper, with a brief introduction to each of three paradigms via some existing research which illustrates it. Sarantakos [12] suggests that this tripartite model is one generally accepted by a majority of social scientists. 3. Positivistic research into the learning of UNIX The positivistic paradigm views the nature of reality as something which exists external to and independent of people, and is taken to be that which is observed through the senses. Research is an instrument which is used to seek universal laws of causality. It tends to favour quantitative research methods. An example of research from a positivistic paradigm is the investigation by Gupta and Siebuhr [6] into undergraduate student learning of computer science. Machine-available data of student processes running on UNIX was collected over two years from filtered accounting information. This information was examined statistically to determine a number of metrics, for example: the frequency of UNIX command use by years; the percentage of students using a command; individual student vocabulary size; the commands used by users over time; the most commonly-used commands as classified by broad functionality editing, compiling, etc.; the system usage versus the vocabulary size;