Central Heuristics of Software Development


The cognitive complexity of software development is widely acknowledged , and the discipline of computer science (and later also the discipline of software engineering) developed heuristics to overcome this complexity. These heuristics became part of the discipline and are discussed explicitly in computer science and software engineering literature. In this chapter, we mention structured programming, successive refinement, and abstraction.

Structured Programming

The idea of structured programming was introduced by Dijkstra [Dijkstra72]. It was one of the first program design methods targeted at coping with the increasing cognitive complexity of developing software systems. It guides developers to break down big computer programs into routines that have clear roles in the whole computer program. Structured programming is accepted today as one of the fundamental principles of software development.

Structured programming is reflected in related heuristics employed in software development, such as top-down design and bottom-up programming. All these methods aim to keep the program within one s intellectual grasp. In practice, they all direct one to deal with ideas instead of details. Top-down design, for example, guides developers to start by breaking the problem into a set of subproblems and then to divide each subproblem into subproblems. The process continues in this manner until each subproblem is defined at a basic enough level and further decomposition is unnecessary.

Task  

Look at software engineering books for the principle of bottom-up design/programming. Explain its connections to top-down design/programming and in what ways it supports software development processes.

Successive Refinement

The idea of successive refinement is similar to the principle that guides the process of book writing. For example, in the case of this book, we started with a list of topics related to software engineering, that we found relevant from the human perspective. Here are three examples: teamwork, the Code of Ethics of Software Engineering, and learning processes in software engineering. Then we started elaborating each of these topics. This elaboration is was expressed first by the headings we added to each chapter. The content was added only in the next stages.

During that process, we sometimes changed the location of different topics and organized sections differently. However, at each moment, the full picture remained complete and only the details were added, changed, or removed. Adding details is carried out in different ways. Sometimes, all we have to do is to add the content to a section that was determined in early stages; sometimes a new section is added to complete the picture; in yet other cases, sections are broken into subsections. However, according to the idea of successive refinement, no matter what kind of elaboration is conducted throughout this process, the entire picture of the book, as we conceive of it at each stage, is completed.

A similar process occurs during software development. One starts by describing a solution to the problem. This description uses terms that capture the essence of the solution, but these terms are not necessarily provided by the programming language the software is developed in. Then, details are added to the solution in steps similar in nature to the stages mentioned in the previous paragraph. For example, sometimes only the description of a term is added; sometimes a term is broken down to several subterms. Dijkstra [Dijkstra72] describes the main idea of this process by saying that independent of the final decisions that are taken, the coding of the earlier levels remains valid. He concludes that in view of the requirement of program manageability, this continuity is veryencouraging (p. 39). Note that Dijkstra addressed explicitly the importance of program manageability, which aims to support the cognitive complexity of software engineering.

It is important to be aware of the idea of successive refinement when learning programming or when reading computer programs that someone else has written (as happens in many cases in software development). In both situations, computer programs are sometimes presented as finished products. Their aims and syntactic details are explained, but the process by which they were developed is not always discussed [Wirth71]. However, this style of presenting computer programs shows what computers can do, but does not reflect the actual process of software development. As a result, novices may get the incorrect impression that programming is based on syntactic skills only, and that writing a computer program is a simple process in which the developer s intuition is simply translated into the programming language.

One way to help novice software engineers grasp the actual process of software development is to explain the process through which the software was developed (see the process-oriented perspective of software development presented in Chapter 7, Different Perspectives of Software Engineering ). It is more and more accepted that this type of documentation is required for program comprehension . Furthermore, it is more and more accepted that the specific ways by which the computer program achieves its goals should be transparent merely from the code itself.

In educational environments, Pattis [Pattis81] suggests presenting the students with the process through which computer programs are developed. This presentation, Pattis explains, may help students discover that one should not get carried away by the I ve got to get it perfect the first time syndrome (p. 83). This syndrome, Pattis says, simply leads programmers to a situation in which they are unable to develop computer programs.

Tasks  
  1. Imagine you are asked to teach the idea of successive refinement. How would you teach it? What guidelines will you follow?

  2. Discuss connections between successive refinement and structured programming.

Abstraction

Simply put, abstraction is a cognitive means according to which we concentrate on the essential features of our topic of thought, and ignore details that are not relevant at a specific stage of problem-solving situations. Abstraction is especially essential in solving complex problems, as it enables the problem solver to think in terms of conceptual ideas, rather than in terms of their details.

The concept of abstraction is an integral part of the professions of computer science and software engineering. Abstraction can be expressed in different ways, all guiding us to ignore irrelevant details at specific stages in order to overcome complexity. The next three paragraphs describe three ways by which abstraction can be expressed.

One way is by observing what a group of objects has in common and capturing this essence by one abstract concept. In such cases, abstraction leads us to preserve what is common to a set of objects and to ignore irrelevant differences among them. The common characteristics are captured in one concept (which can be a mathematical concept, a class in the paradigm of object-oriented development, a procedure that deals with different kinds of inputs, etc.). In this sense, abstraction is mapping from many to one. For example, the hierarchy of mammals reflects abstraction; at its higher levels we ignore differences between the mammals, at its lower levels, we distinguish between different characteristics of mammals. Another example is mathematical definitions. Think about a square, for example. The definition of square ignores the specific side s size and location. However, in lower levels of abstraction, when we discuss a specific square, we do care about these details. In general, any mathematical definition describes a concept by capturing their shared properties and ignoring irrelevant differences between them.

Abstraction is also applied by choosing appropriate language for describing a solution for a given problem. This language is not necessarily based on the tools provided by the programming language that we use. However, abstraction in this case helps developers think about the problem with appropriate conceptual terms, without being guided to think in terms of any particular programming language. In this case, without using abstraction, computer languages would have forced software developers to delve into irrelevant details at too early stages, and would, in fact, take control of the programming process. In this sense, abstraction bridges natural language and programming language. This idea is reflected by the evolution of programming languages. The first programming languages were significantly different from our language, but today s programming languages enable software developers to express ideas in a way that becomes more and more similar to natural language.

The third expression of abstraction is applied by describing objects by their characteristics rather than by the way they are constructed or how they work. Accordingly, Hoare [Hoare86] explains that an abstract command is a command that specifies the properties of the computer s desired behavior without prescribing in detail how that behavior will be achieved. This idea is expressed, for example, by writing one set of instructions for the manipulation of different types of objects. In lower levels of abstraction, the different ways in which these instructions work on different types of objects are specified. This idea is illustrated by Abelson and Sussman [Abelson and Sussman86] by the process of setting abstraction barriers (p. 73).

Tasks  
  1. Suggest specific situations in software development in which each of the aforementioned implementations of abstraction is useful. Explain what benefits one gains from each expression of abstraction.

  2. Can these uses of abstraction be applied to other situations in our lives?

  3. How is abstraction applied in object-oriented design?




Human Aspects of Software Engineering
Human Aspects of Software Engineering (Charles River Media Computer Engineering)
ISBN: 1584503130
EAN: 2147483647
Year: 2004
Pages: 242

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net