Collected Concepts Flashcards

1
Q

Types of Maintenance

A
  • Corrective change
  • Adaptive change
  • Perfective change
  • Preventive change
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Corrective Change

A
  • Deals with the repair of faults or defects found in day-today system functions
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Adaptive Change

A
  • Implementing changes in a part of the system, which has been affected by a change that occurred in some other part of the system.
  • Business or Environment causes
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Perfective Change

A
  • implementing new or changed user requirements
  • involves making functional enhancements to the system
  • Increase the system’s performance
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Preventive Change

A
  • Involves performing activities to prevent the occurrence of errors
  • Tends to reduce the software complexity
    • Improves program understandability
    • Increases software maintainability
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Top-Down Code Reading

A
  • Use context and prior assumptions to gain overall understanding from selected details
  • Examining high-level structuring of system
  • Create hypotheses from these
  • Go progressively deeper into the code, looking for evidence for or against
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Top-Down Strategy Aim

A
  • Squeeze maximum useful information out of each examination of the system
  • At each examination of the system, just look for the smallest useful unit of information
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Top-Down Exploit Beacons

A
  • Cues that suggest instant hypotheses
  • Should stand out (be visible at a glance)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Top-Down Exploit System Diagrams

A
  • Give an overview of the program
  • Hide unimportant and distracting details
  • Only useful for code reading if can be automatically generated (or if very small)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Top-Down Strategy Key Features

A
  • Importance of context and prior understanding
  • Confirms domain assumptions through verification reading
  • Don’t need to understand every word to understand overall meaning
  • Meaning is brought to print, not extracted from print
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Bottom-Up Code Reading

A
  • Start with individual statements and build up picture incrementally
  • Applies when class/method/etc to be examined already identified
  • Skim over code, looking for recognisable idioms
  • Form abstract view of the task of the idiom
  • Combine recognised units to make conjectures about ever larger sections of code
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Bottom-Up Code Reading Cons/Pros

A
  • Pros
    • Gives detailed understanding of fragments of code
  • Cons
    • Can be difficult to understand full meaning of fragments without knowing their context
    • Difficult to know where to start, if program is big or unfamiliar
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Opportunistic/Hybrid Code Reading

A
  • A hybrid of top-down and bottom-up
  • Begin with top-down, to gain the overview
  • Then selectively apply bottom-up, when nearing ‘code-level’
  • Presence of beacons can indicate opportunity for change in strategy
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Program Slicing

A
  • Understand how particular variable got its value, at particular point in the program
  • Remove all program statements that don’t affect the value at this point
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Data Dependency Graphs

A
  • Create graph from code
  • 1 node for each program statement
  • Directed edges between nodes indicate patterns of variable usable and dependency
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Control Flow Graphs

A
  • Create graph from code,
  • 1 node for each program statement and directed edges between nodes
  • Indicate patterns of control flow between consecutive statements
17
Q

Code idiom

A
  • Language-independent way of expressing a construct that is frequently used.
  • Idioms are helpful in bottom-up code reading
  • Recognisable
  • Can be used as a starting point for knowledge about program behaviour, which can be built up.
18
Q

Coding Conventions

A
  • Language-specific best-practice guidelines
  • Code that conforms to conventions is easier to comprehend
19
Q

Swap idiom

A
  • Two variables need to swap values
  • Will most likely look something like this: t = a; a = m;
20
Q

Process Every Item in Collection Idiom

A
  • Language-independent statement of idiom:
    • curr := first item in collection
    • while not at end of collection do
      • process curr
      • curr := next item after curr end while
    • end while
21
Q

Search Collection Idiom

A
  • Search a collection for the first item that has satisfies the given property:
    • curr := first item in collection
    • found := false
    • while not at end of collection and not found do
      • if curr has required property
        • found := true
        • item := curr
      • curr := next item after curr
    • end while
22
Q

Control Dependency Graphs

A
  • 1 node for each program statement
  • Directed edges between nodes indicate dominant control relationships between statements (not only consecutive statements as in CFG)
23
Q

Evolutional Design

A
  • Comes from agile but has wider applicability
  • At the local code level, evolutionary design involves refactoring
  • At the system code level, test-driven design can be used, following a red-green-refactor process.
  • These sorts of evolutionary design techniques help us address the failings of BUFD, as they correspond to a just-enough, just-in-time approach.
    • I.e. they don’t assume that we will get everything right the first time
24
Q

Code Smell

A
  • A code smell is evidence present in a piece of code that suggests it could be improved.
  • With regards to evolutionary design, in which we continually aim to move towards a better design, code smells can be used to identify places where refactoring should be done.
25
Q

Open Source Dangers

A
  • Open source code can disappear or have breaking changes made without warning.
  • There is likely to be no official company behind it who can send a representative to either implement the part of the system where the open source code is needed, or teach your employees how to use it.
  • Do not have 24/7 technical support if something goes wrong, no one is responsible for it, other than yourself.
26
Q

Forward migration

A
  • Initial migration of the entire database, followed by installation of a forward gateway
  • Migrates unchanged legacy apps forward onto a modern DBMS and then migrates the legacy apps to new target apps.
  • One initial Cold Turkey step
  • Involves forward DB gateway
27
Q

Reverse Migration

A
  • Database migration is done at the end of the process. Target apps are created and installed on a reverse gateway that permits access to the legacy DB
  • Target app calls must be migrated in reverse direction, back onto the legacy database, until the legacy database is subsequently migrated
  • Permits more time to prepare database migration compared to forward
    • Determine minimal amount of legacy data to migrate
    • Gateway capabilities may be added “just in time”
28
Q

General Migration

A
  • Combination of forward and reverse migrations.
  • Gateway is more complex, contains functions of forward, reverse, mappable table and coordinator.
  • Permits DB migration step to be incremental and parallel with the other steps
29
Q

Legacy Information System (IS)

A

Any information system that significantly resists modification and evolution to meet new and constantly changing business requirements

30
Q

Cold Turkey Migration Strategy

A

Rewriting legacy IS from scratch to produce target IS, using modern techniques and hardware

  • Problems:
    • A better system must be promised
    • Business conditions never stand still
    • Specifications rarely exist
    • Undocumented dependencies frequently exist
    • Legacy ISs can be too big to cut over data
    • Management of large projects is hard
    • Lateness is seldom tolerated
    • Large project tend to bloat
    • Homeostasis is prevalent
    • Analysis paralysis sets in.
31
Q

Chicken Little Migration Strategy

A

Migration Legacy IS by small incremental steps until the desired long-term objective is reached

  • Each step requires small resource allocation.
    • Produces small result toward the desired goal - an increment
  • Incremental migration methodology
  • Pros
    • Less Risky
    • If something fails, its only one step at a time
    • Outlook is optimistic, not unpredictable until deadline like in Cold Turke)
32
Q

Decomposable Architecture

A

Interfaces, applications and database services can be considered distinct components with well-defined interfaces.

  • Applications modules must be independent of each other (have not hierarchal structure, and interact only with the DB)
  • Gateways can be placed between application modules and legacy database service.
    • Called database gatewat
33
Q

Semidecomposable Architecture

A
  • Only user and system interfaces are separate modules
  • Applications and DB are not separate from each other
  • Analysis and migration are more complex and error-prone
  • Gateway placed between interfaces and the rest of the legacy IS
    • Called Application Gateway
34
Q

Nondecomposable Architecture

A
  • No functional components are separateble
  • Worst architecture for migration
  • End users and ISs interact directly with one, unstructured, component or module
  • Gateway encapsulates the entire legacy IS.
    • Called IS gateway.
    • Most complex.
    • Primary means for dealing with the user interface.
35
Q

Hybrid architecture

A
  • During software evolution, Legacy IS might had parts that fell into different architecture categories
36
Q

Gateways

A

Software module between operational software components to mediate between them.

  • Insulate certain components from changes being made to other components
  • Translate requests and data between the mediated components
  • Coordinate between mediated components for update consistency.
37
Q

Forward Gateway

A
  • Enables legacy applications to access DB environment on the target side of the migration process
  • Translate legacy calls forward to target calls.
38
Q

Reverse Gateway

A
  • Enables target applications to access legacy data management environment.
  • Translate target calls in the reverse direction back into legacy calls.
39
Q
A