SOMA Flashcards

1
Q

Program understanding - System Knowledge

A

problem domain

execution effects

cause and effect relation

product environment

decision support

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Tasks during Maintenance

A

1 change (changes are necessary)
2 Understanding the system
3 execute changes
4 Test and deploy

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Cause effect relation

A

1 Identify program parts

2 Establish relation between parts

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Process model for program understanding

A

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)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Strategy for program understanding

A

Strategy for program understanding

top-down: top levels of programs to the low-level details
bottom-up: From lower-level patterns to higher-level

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Top-Down Model

A

First, make hypotheses about coarse structure
Refine knowledge

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Procedure knowledge acquisition:

A

1 To raise basic knowledge

2 Create hypotheses about program behavior

3 Check hypotheses (correct, mental model correct, otherwise hypothesis must be
revised)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Composition VS Comprehension

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Influence factors on program understanding

A

1 Expertise (Domain, Programming)
2 Implementation issues (Naming, Comments, Nesting, Coding standards)
3 Doumentation

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Characteristics of good software

A

Functionality
Flexibility
Availability
Correctness

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Test Pyramid

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Reuse

A

of: code, test data, architecture, algos
→ of knowledge: process, lessions learned, product

benefits: increase productivity, quality, portable code, less maintenance, better maintainability

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Approaches to Reuse

A

Composition-Based: Atomic building blocks (modules, functions, classes)

Generation-Based: Program that generates target systems (High-Level specification, e.g. compiler-generator)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Problems with Reuse Libraries

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Factors influencing Reuse

A

Technical factors: programming languages, information presentation, availability of libs

Non-technical factors: money spent, not invented here, legal framework

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Software Lifecycle

A

Analysis

Design

Implementation

Test

Software Use

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Software Maintenance Framework

A

Organisational
vs User (requirements, additional functionality, non-programming support)
vs Operational (policies, market)
Environment (hardware, software)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Software Changes

A

Corrective changes (Design, logic, coding errors)

Adaptive changes (changed environment, new laws …)

Perfective changes (user requests, extending functionality, performance)

Preventive Changes (ease further maintenance)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Changes to a software often cannot be
realized because

A

Limitations of resources

poor quality of the existing system

Organizational strategy

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Solutions to Maintenance Problems

A

Budget and effort reallocation

replacement of existing system

Improve the existing system by preventive
maintenance.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

How to reduce maintenance costs?

A

Budget reallocations

replacing old software

Improving the existing software

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

knowledge is implicitly stored

A

Experiences

Management knowledge

Operational and functional information

Business rules and prozesse

23
Q

Waterfall model

A

Emphasis on phases (analysis, design, coding, testing, usage)
Disad: errors found in later stages are hard to correct

Assumption: All results of one phase are correct and
complete

24
Q

Spiral model

A

based on 4 tasks:

1 Analyis of goals, requirements, and alternatives
2 Evaluating alternatives considering risks
3 Start next iteration of program development and testing
4 Start planing the next iteration (phase)

25
Q

Code-And-Fix

A

Coding phase:
- Programming
Fix phase:
- Corrections
- Extensions

AD HOC
Code remains faulty and maintainability decreases

26
Q

Maintenance tasks

A

Operation
Validation
Software Maintenance
Processes
Idea
Unterstand the
system
Implementation
Testing
Define
objectives
Analysis
Specification
Documentation
Release new
version
Training

27
Q

Quick-Fix Model

A

First responder approach

  1. Find fault
  2. Correct it

Problems:

  • No detailed analyses
  • No documentation
28
Q

Boehm‘s model

A

Cyclic model
Based on economic models and principles
Management decision is driver of the process

29
Q

Osborne‘s model

A

Considers the real requirements of software maintenance

Iterative loops to implement maintenance activities

30
Q

Reverse Engineering - abstraction

A

From product/system to idea
abstraction: extraction of knowledge at an appropriate level of understanding

3 types of abstraction:
1 Function abstraction (knowl. about how a procedure works)
2 Data abstraction (knowl. about data models without impl. details)
3 process abstraction (program flow without exact behav.)

31
Q

Objectives of Reverse Engineering

A

Recovering Lost Information
Support migration between different platforms
Improving or restoring documentation
Providing different perspectives on a program
Extraction of re-usable components
Support in dealing with complexities
Detecting side effects
Reduction of maintenance costs

32
Q

Redocumentation

A

Goal: Creation of semantically equivalent
documentation within the same level of
abstraction.

Creating alternative views
Improving existing documentation
documentation on modified program

Techniques: CFG, Structograms, ERDs, Class diagrams

33
Q

Different Levels of Reverse Engineering

A
34
Q

Reverse Engineering - Design Recovery

A

Goal: Gain higher abstractions directly from
the source code.
Detection of control structures, data types, modules, class hierarchies
Recognition of patterns
Derivation of the architecture

35
Q

Reverse Engineering - Specification Recovery

A

Goal: Obtaining specification knowledge from
system information
if: Design knowledge is often not sufficient OR Paradigm shift in design

36
Q

Reverse Engineering - Specification Recovery

A

Goal: Obtaining specification knowledge from
system information
if: Design knowledge is often not sufficient OR Paradigm shift in design

37
Q

When is reverse engineering necessary?

A
  • Missing or incomplete design/specification
  • Insufficient documentation
  • Poorly structured source code
  • Program transformation
  • Ensuring program compatibility
  • Migration to other HW/SW platforms
  • Rising error rate
38
Q

Restructuring of Source Codes

A

Control-flow-driven
Efficiency-driven
Adaption-driven

39
Q

Software maintenance - definition

A

Software maintenance is the process of modifying a software system or component after delivery to correct faults, improve performances or other attributes, or adapt
to a changed environment.

40
Q

Reasons for the high costs of maintenance

A
  • Insuffcient knowledge of the user domain
  • Insuffcient or obsolete documentation
  • Complexity of programs
  • Programmer = maintenance personnel
  • Employee responsible for the code left the company
  • Knowledge often only implicitly (in the program code) available
41
Q

Maintenance process

A
  1. Analyze the existing system
  2. Analyze the necessary changes of the system
  3. Prediction of potential impacts (ripple effects)
  4. Determination of skills and knowledge required for the changes
  5. Implementation of the changes
42
Q

Restructuring

A

Creating a more maintainable system, changing the abstract representation of the system without changing its functionality.

43
Q

Re-engineering

A

Enhancement of a system by using first reverse engineering to comprehend the system and then forward engineering to produce the new system.

44
Q

Forward engineering

A

The traditional software development approach.

45
Q

The aims of program comprehension

A

Problem domain
Execution effect
Cause-effect relation
Product-environment relation
Decision-support features

46
Q

Principles which impact reusability

A

Generality (wide spectrum)
Cohesion vs coupling (should be high vs low)

Interaction (with user should be min.)
Uniformity and standardization

47
Q

Motivation Backward Slicing

A

Computation of Statements influencing the value of a variable

Identification of faulty statements

48
Q

Motivation Forward Slicing

A

Computation of statements influenced by a statement

Effects of a statement on the rest of the program

Find the variables that are influenced by a statement

49
Q

Internal Factors Software-Maintenance

A

Software: Difficulty of aplication domain, Quality, Complexity

Process: Capturing requirments, undocumented assumptions, variation in programming practice

Personnel: Stuff turnover, Domain expertise

49
Q

External Factors Software-Maintenance

A

Organisational: Change in policies, Competition in market place

Operational: Hardware and software innovation

User environment: User requirements

50
Q

Purpose of software analysis

A

Unfolding of program structures

Which statements influences a variable in a specific line

Which statements have no influence on the result

Is a specific line of code reachable

51
Q

Forward (!) Slicing

A

start with all defs of statement
gen(n) = def : if ref∧in or inSlice(n)

inSlice if ref and out intersect

inSlice if m is in INFL(n) and inSlice(n)

52
Q

In Slice - Backward (!) Slicing

A

S0(n): if n is PRE(m) and Def(n) and R(m) intersect
B(n): if one of INFL(n) in slice
(create new slice for each n of B(n) in slice)
S1: S0(n) + B(n) + slice(B(n) if n in slice)