SOMA Flashcards
Program understanding - System Knowledge
problem domain
execution effects
cause and effect relation
product environment
decision support
Tasks during Maintenance
1 change (changes are necessary)
2 Understanding the system
3 execute changes
4 Test and deploy
Cause effect relation
1 Identify program parts
2 Establish relation between parts
Process model for program understanding
Read about the program (Read data flow diagrams)
Read the source code (Read definitions and implementation modules)
Run the program (Get trace data
Dynamic analysis)
Strategy for program understanding
Strategy for program understanding
top-down: top levels of programs to the low-level details
bottom-up: From lower-level patterns to higher-level
Top-Down Model
First, make hypotheses about coarse structure
Refine knowledge
Procedure knowledge acquisition:
1 To raise basic knowledge
2 Create hypotheses about program behavior
3 Check hypotheses (correct, mental model correct, otherwise hypothesis must be
revised)
Composition VS Comprehension
Influence factors on program understanding
1 Expertise (Domain, Programming)
2 Implementation issues (Naming, Comments, Nesting, Coding standards)
3 Doumentation
Characteristics of good software
Functionality
Flexibility
Availability
Correctness
Test Pyramid
Reuse
of: code, test data, architecture, algos
→ of knowledge: process, lessions learned, product
benefits: increase productivity, quality, portable code, less maintenance, better maintainability
Approaches to Reuse
Composition-Based: Atomic building blocks (modules, functions, classes)
Generation-Based: Program that generates target systems (High-Level specification, e.g. compiler-generator)
Problems with Reuse Libraries
Granularity and size
Low granularity: few functions, easy to understand but limiting the reuse § High granularity: many functions, c confusing, bad for reuse
Search problem (find reusable comps)
Search problem
Specification and flexibility problem
Factors influencing Reuse
Technical factors: programming languages, information presentation, availability of libs
Non-technical factors: money spent, not invented here, legal framework
Software Lifecycle
Analysis
Design
Implementation
Test
Software Use
Software Maintenance Framework
Organisational
vs User (requirements, additional functionality, non-programming support)
vs Operational (policies, market)
Environment (hardware, software)
Software Changes
Corrective changes (Design, logic, coding errors)
Adaptive changes (changed environment, new laws …)
Perfective changes (user requests, extending functionality, performance)
Preventive Changes (ease further maintenance)
Changes to a software often cannot be
realized because
Limitations of resources
poor quality of the existing system
Organizational strategy
Solutions to Maintenance Problems
Budget and effort reallocation
replacement of existing system
Improve the existing system by preventive
maintenance.
How to reduce maintenance costs?
Budget reallocations
replacing old software
Improving the existing software