Program comprehension during Software maintenance and evolution Armeliese von Mayrhauser , A. Marie Vans Colorado State University Summary By- Fardina.

Slides:



Advertisements
Similar presentations
Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Advertisements

Lecture # 2 : Process Models
Program Comprehension1 Program Comprehension During Software Maintenance and Evolution IEEE Computer, August 1995 Von Mayrhauser, A. and Vans, A. M.
Design Concepts and Principles
Chapter 4 Enterprise Modeling.
SSP Re-hosting System Development: CLBM Overview and Module Recognition SSP Team Department of ECE Stevens Institute of Technology Presented by Hongbing.
July 11 th, 2005 Software Engineering with Reusable Components RiSE’s Seminars Sametinger’s book :: Chapters 16, 17 and 18 Fred Durão.
Chapter 6: Design of Expert Systems
Seminar /workshop on cognitive attainment ppt Dr Charles C. Chan 28 Sept 2001 Dr Charles C. Chan 28 Sept 2001 Assessing APSS Students Learning.
© 2005 Prentice Hall8-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
Analysis Concepts and Principles
9 1 Chapter 9 Database Design Database Systems: Design, Implementation, and Management, Seventh Edition, Rob and Coronel.
Introduction to Software Design Chapter 1. Chapter 1: Introduction to Software Design2 Chapter Objectives To become familiar with the software challenge.
Chapter 2 The process Process, Methods, and Tools
Software Evolution and Maintenance (Chapter 8: Program Comprehension) © Tripathy & Naik 1 Software Evolution and Maintenance A Practitioner’s Approach.
Business Process Management. Key Definitions Process model A formal way of representing how a business operates Illustrates the activities that are performed.
Phase 2: Systems Analysis
SLB /04/07 Thinking and Communicating “The Spiritual Life is Thinking!” (R.B. Thieme, Jr.)
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
ITEC 3220M Using and Designing Database Systems
Top-Down Design and Modular Development
1 Chapter 9 Database Design. 2 2 In this chapter, you will learn: That successful database design must reflect the information system of which the database.
RUP Design RUP Artifacts and Deliverables
Lecture 7 Declarative Knowledge English Study Program FKIP – UNSRI July
Illustrations and Answers for TDT4252 exam, June
Chapter 10 Analysis and Design Discipline. 2 Purpose The purpose is to translate the requirements into a specification that describes how to implement.
Chapter 8 Object Design Reuse and Patterns. Object Design Object design is the process of adding details to the requirements analysis and making implementation.
1 Asking and Answering Questions during a Programming Change Task, By Jonathan Sillito, Member, IEEE, Gail C. Murphy, Member, IEEE, and Kris De Volder.
Presented by: Ashgan Fararooy Referenced Papers and Related Work on:
Learning Targets January 21, 2008 Londa Richter & Jo Hartmann TIE.
Introduction The design, development and maintenance of concurrent software are difficult tasks. Truly effective support methodologies have yet to be developed.
1 The Software Development Process ► Systems analysis ► Systems design ► Implementation ► Testing ► Documentation ► Evaluation ► Maintenance.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
Application Domain Knowledge and Programmers’ Mental Representations Teresa M. Shaft University of Oklahoma Iris Vessey Indiana University.
Software Design. Introduction Designing engineering encompasses the set of principles concepts and practices that lead to the development of a high quality.
Program Comprehension Program Understanding Behavior During Debugging Of Large Scale Software Anneliese von Mayrhauser (Andrews) and A. Marie Vans Rizal.
Chapter 6 Selecting a Design. Research Design The overall approach to the study that details all the major components describing how the research will.
5 Chapter 5: Modeling Systems Requirements: Events and Things Systems Analysis and Design in a Changing World.
Chapter 10 Structuring System Requirements: Conceptual Data Modeling
ICS 3UI - Introduction to Computer Science
7. Modular and structured design
Algorithms and Problem Solving
ITEC 3220A Using and Designing Database Systems
Profiling based unstructured process logs
Fundamentals of Information Systems, Sixth Edition
Object-Oriented Software Engineering Using UML, Patterns, and Java,
Software Life Cycle “What happens in the ‘life’ of software”
Complexity Time: 2 Hours.
Lecture 9- Design Concepts and Principles
Chapter 6: Design of Expert Systems
Software Process Models
Chapter 6 Database Design
Software Life Cycle Models
The Open Group Architecture Framework (TOGAF)
Investigating a Phase Approach to Using Technology as a Teaching Tool
Self-Critical Writing:
Engineering Processes
SWE-795 Presentation 01 11/16/2018 Asking and Answering Questions during a Programming Change Task Jonathan Sillito, Member, IEEE Computer Society, Gail.
Unit# 9: Computer Program Development
Introduction to Computer Programming
Chapter 5 Designing the Architecture Shari L. Pfleeger Joanne M. Atlee
Algorithm An algorithm is a finite set of steps required to solve a problem. An algorithm must have following properties: Input: An algorithm must have.
Chapter 10 Structuring System Requirements: Conceptual Data Modeling
Chapter 13: Systems Analysis and Design
Systems Analysis and Design
Lecture 9- Design Concepts and Principles
Chapter 10 Structuring System Requirements: Conceptual Data Modeling
Top-Down Design & JSP Skill Area Part D
Basic concepts curriculum Curriculum development Curriculum analysis Curriculum evaluation Elements of curriculum Educational objectives content.
Lecture 10 Structuring System Requirements: Conceptual Data Modeling
Presentation transcript:

Program comprehension during Software maintenance and evolution Armeliese von Mayrhauser , A. Marie Vans Colorado State University Summary By- Fardina Fathmiul Alam G#01031111

General Idea Programming Understanding is a key factor in Software maintenance and evolution. Code cognition models examine how programmers understand program code. This paper has survey the current knowledge in this area by comparing six program comprehension models: the Letovsky (1986) model; the Shneiderman and Mayer (1979) model; the Brooks (1983) model; Soloway, Adelson and Ehrlich's (1988) top-down model; Pennington's (1987) bottom-up model; and the integrated metamodel of von Mayrhauser and Vans (1994) based on their scope and experimental support. All models use existing knowledge to build new knowledge about the mental model of the software that is under consideration. This paper identifies open questions, particularly considering maintenance and evolution of large-scale code. These questions relate to scalability of existing experimental results with small programs validity and credibility of results based on experimental procedure and challenges of data availability 2

Table 1 Table 1: Tasks and activities requiring code understanding. Maintenance Tasks Activities Adaptive Understand system Define adaptation requirements Develop preliminary and detailed adaptation design Code changes Debug Regression tests Perfective Understand system Diagnosis and requirements definition for improvements Develop preliminary and detailed perfective design Code changes/additions Corrective Understand system Generate/evaluate hypotheses concerning problem Repair code Reuse Understand problem Find solution based on close fit with reusable components Locate components Integrate components Code leverage Understand problem Find solution based on predefined components Reconfigure solution to increase likelihood of using predefined components Obtain and modify predefined components Integrate modified components Table 1: Tasks and activities requiring code understanding. 3

Table 2: Code cognition models. To analyze the cognitive processes behind these tasks, researchers have developed several models Model Maintenance activity Authors Control-flow Understand Pennington Functional Top-down Soloway, Adelson, and Ehrlich Integrated Understand, Corrective, Adaptive, And Perfective Von Mayrhauser and Vans Other Enhancement Letovsky Brooks Shneiderman and Mayer Table 2: Code cognition models. 4

Cognition Models for Program Understanding Letovsky model Shneiderman and Mayer model Brooks model Soloway, Adelson, and Ehrlich model (top-down model) Pennington model (bottom-up model) Integrated metamodel 5

Letovsky model Figure: Letovsky’s program comprehension model. 6 Letovsky’s high-level comprehension model has three main components. The knowledge base contains programming expertise, problem-domain knowledge, rules of discourse, plans, and goals. The mental model has three layers: The specification layer: characterizes the program goals. The implementation layer contains the lowest level abstraction. with data structures and functions as entities. The annotation layer : links each goal in the specification layer to its realization in the implementation layer. The dangling-purpose unit : links such unresolved ,incomplete links. The assimilation process : combine their knowledge base and the external representations to create their mental models. Produce the highest return in knowledge gain Figure: Letovsky’s program comprehension model. 6

Shneiderman and Mayer model Recodes the program in short-term memory into an internal semantic representation via a chunking process. In internal semantics the top are high-level concepts are such as program goals, The lowest levels contain details algorithms used to achieve program goals. Long-term memory, a knowledge base with semantic and syntactic knowledge, assists during internal semantics construction. Program understanding is directional: It starts with the program code and continues until the problem statement is reconstructed. Figure: Shneiderman and Mayer program comprehension model. 7

Brooks comprehension model The three key elements of the model are- Mappings from a problem (application) domain to the programming domain through several intermediate domains. Understanding the mappings in terms of hypotheses. Programmers read all available documentations and try to reconstruct the mappings as much as they can. Internal representations reflect knowledge contained in external representations such as code, design documents, or requirements specifications. Figure : An overview of Brooks comprehension model. 8

Soloway, Adelson, and Ehrlich model (top-down manner) This model works in a top-down manner: The understanding process matches external representations to programming plans using rules of discourse to select plans, by setting expectations. Once a match is complete, the internal representation is updated to reflect the newly acquired knowledge. These updated mental representations are subsequently stored as new plans. The process is said to complete when the programmer has associated all the programming plans with the goal hierarchy Knowledge Internal/ External Representation Understanding process Figure : Soloway, Adelson, and Ehrlich comprehension model. 9

Pennington Model (Bottom-up Comprehension) The model applies two concepts: 1.Program model: (high Right of the figure) textbase (A textbase represents information that the reader of a text can recall from memory after reading the text)and 2. situation model: (high Left of the figure) (represents what the text is about) They are important to Pay attention to the loop: {Match – Mental representation – Text structure knowledge} followed by the Text base. Finally, when the programmer stops iterating through the loop, the final mental representation is known as the textbase. The programmer assimilates their understanding of the code, knowledge of the text structure, and the situation model to create a mental model in the form of a textbase. The programmer assimilates the documentations, plan knowledge, and the textbase to create the situation model. The textbase and the situation model are cross-referenced to refine and update the two models. Figure : Pennington model. 10

Integrated Metamodel Figure : Integrated Metamodel 11 The four major components of the model are explained in the following: Top-down model It represents domain knowledge about the program. These include programming plans and rules of discourse. Program model If the programmer understands what the program is doing from the control flow aspect, then he has a program model of the code. These include two kinds of knowledge: text- structure knowledge and plan knowledge. Situation model (See the Pennington’s model) After building a program model, a programmer builds a situation model by using control flow and data flow information in a bottom-up manner. Knowledge base The knowledge base provides a medium for interactions among the above three models. The programmer takes an opportunistic approach and simultaneously builds all the three models by updating the knowledge base with the understanding of one model and applying the knowledge to further build another model. Figure : Integrated Metamodel 11

Model Evaluation Criteria

Program Comprehension Experiments

Some observation from the analysis of model evaluation criteria Many characteristics are shared among different models. For example, Brooks, Letovsky, and Shneiderman and Mayer all focus on hierarchical layers in the mental representations. Brooks and Soloway, Adelson, and Ehrlich use a form of top-down program comprehension, while Pennington uses a bottom-up approach to code understanding. Letovsky and Shneiderman and Mayer use both top-down and bottomup comprehension. All five models use a matching process between knowledge structures and the artifact under study. No one model accounts for all behavior as programmers understand unfamiliar code. The Integrated Metamodel responds to the cognition needs for large software systems.

Conclusion Based on all of these evaluations and analyses, this paper has drawn some conclusion that- Existing experimental results of program understanding work is based of small scale programs and some of the model may or may not scale up successfully .So existing results from related areas need further investigation. Some results generalize or appear as components of to larger results (Ex: Pennington’s and Soloway, Adelson, and Ehrlich’s models in the Integrated Metamodel ). Accurate documentation and Data availability is a challenge. Because of it program comprehension is difficult .Because of these challenges, it become hard even for experts to work on project maintenance and evolution. 

Questions Overall reaction of this paper?. Do you think that comparing this six program comprehension models is giving a whole scenario of understand programming code? Some Limitations of these comprehension models.