Learning Perspectives on software engineering (CH10)

Slide 1

Learning Perspectives on
Software Engineering

 Jim Tomayko     Orit Hazzan 

Slide 2

Learning Perspectives
on Software Engineering

• Reflective practices

• Program comprehension

• Additional important topic: Learning organization in general and learning software organizations in particular.

Slide 3

Software Engineering
as a Reflective Practice

Main Idea

• On-going reflection on what we do in the process of software system developing

• Reflection:

  • reflection-in-action: During the development process

  • reflection-on-action: After the completion of the development

Slide 4

Reflective Practice

Sch n, D. A. (1983). The Reflective Practitioner, BasicBooks.

Sch n, D. (1987). Educating the Reflective Practitioner: Towards a New Design for Teaching and Learning in The Profession, SF: Jossey-Bass.

Sch n wrote about architecture

• Sch n did not talk about SE (though he published his books when the software crisis was known)

• Application to disciplines such as management, psychoanalysis

• Two applications to software engineering:

  • The studio method of teaching

  • On-going reflection

Slide 5

Analogy: Architecture Design and Software Design Processes

Worldwide Institute of Software Architects ( http://www. wwisa .org/wwisamain/role.htm ):

• Phases which define the role of the architect in the software construction process, conceptually following the phases of building construction and architectural services

• Do not fit completely the agile paradigm, yet convey the importance of communication and customer input during software development processes

Slide 6

The Reflective Practitioner Framework and its Relevance to Software Engineering

[Instructors may select several quotes from Sch n s book to illustrate the possible application of a reflective practice perspective to software engineering]

Slide 7

Program Comprehension
Introductory Questions

• How and why is the topic connected to our course?

• What does it mean to understand a computer program?

• What factors influence program comprehension?

• In what cases is it important to understand a computer program?

• Why the topic should be discussed at all? Is code reading different from reading a regular text?

Slide 8

Program Comprehension

What does it mean to understand a computer program?

• Knowing all its variables ?

• Knowing all its procedures? Functions? Objects? Methods? Data structures?

• Knowing how the program behaves?

Formulate your definition for program comprehension

Slide 9

Program Comprehension

Fjeldstad, R. K. and Hamlen, W. T. (1983):

In making an enhancement or maintenance programmers studied the original program:

• About 3.5 times as long as they studied the documentation of the program, and

• Just as long as they spent implementing the enhancement.

Slide 10

Program Comprehension

Oman, P. W. (1990): Four experiments demonstrate the influence of typographic style (source code formatting and commenting) on program comprehension.

• About one half of the maintenance programmer s time is spent studying the source code and related documentation.

Slide 11

Program Comprehension

Factors affecting program readability

• Reader characteristics

• Representational factors: Programming language, the nature and inclusion of comments

• Typographic factors: Upper and lowercase, fonts, white space

• Environmental factors: The medium of the program (monitor, paper), external documentation, software tools.

• Logical complexity

Slide 12

Program Comprehension

Brooks, R. (1983): Four sources of variation in behavior on program comprehension:

• The kind of computation the program performs

• The intrinsic properties of the program text (length, etc)

• The reason for which the task is performed (modification, debugging . . . )

• Differences among the individuals performing the task

Slide 13

Program Comprehension

Littman, Pinto, Letovsky & Soloway (1987):

Two strategies for program understanding:

• As-needed strategy: Focus on local program behavior. Since the programmer does not approach the modification task with a good understanding of the program, it becomes necessary to gather additional information while the program modification is performed.

• The systematic strategy: The programmer learns how the program behaves before attempting to modify it. Such knowledge permits programmers to design modifications that take these interactions into account. This strategy leads to successful program modification.

Slide 14

Program Comprehension

Vans, A. M., von Mayrhauser, A. and Somlo, G. (1999).

von Mayrhauser, A. and Vans, A. M. (1993).

• Three levels of abstraction with respect to program comprehension (Actions during maintenance):

• Program Level (code)

• Situation level (algorithmic)

• Domain level (application)

Full lists of actions for each level can be found in the book

Slide 15

Program Comprehension ”
Findings (Cont)

• Switches during corrective maintenance occur slightly more between program and situation models ”the two lower levels of abstraction

• Programmers with little experience in the domain, work at lower levels of abstraction until enough domain experience allows them to make connections from the code to higher levels of abstraction

Slide 16

Program Comprehension ”
Findings

• Programmers with domain experience but little knowledge about the software, also work at lower levels of abstraction, but use their knowledge of the domain to make direct connections into the program.

• Code size affects the level of abstraction on which maintenance engineers prefer to concentrate while building a mental representation of the program. As the code size increases subjects work less with low level program details than higher level functional descriptions of code.

Slide 17

Program Comprehension ”
Discussion

• How and why is the topic connected to our course?

• Why the topic should be discussed at all? Is code reading different from reading a regular text?