Transcript Title of the presentation

Programų supratimas
Prof. Robertas Damaševičius
[email protected]
Prof. Vytautas Štuikys
Kauno technologijos universitetas
Programų inžinerijos katedra
Program understanding
1
Turinys
•
•
•
•
•
Sąvokų apibrėžimas
Programų suvokimo rolė PĮ priežiūroje
Programų suvokimo iššūkiai
Programų suvokimo (kognityviniai) modeliai
Programų inspekcija
Program understanding
2
Programų suvokimas
• Tyrimų sritis nagrinėjanti, kaip programų kūrėjai
supranta programas
• Programų suvokimas reikalingas:
–
–
–
–
–
–
Derinant ir ieškant klaidų (debugging)
Peržiūrint kodą
Kuriant testavimo atvejus
Tobulinant dokumentaciją
Rekonstruojant architektūrą
Peržiūrint kodą
Programų suvokimas
3
Programų suvokimo procesas
• Ankstesnių žinių naudojimas siekiant įgyti naujų žinių apie
programą
• Esamos žinios:
–
–
–
–
–
–
Programavimo kalbos
Aplinka
Programavimo principai
Architektūros modeliai
Galimi algoritmai ir sprendimai
Srities informacija
• Naujos žinios:
–
–
–
–
–
Kodo funkcionalumas
Architektūra
Algoritmų realizacijos detalės
Duomenų srautai
Valdymo sekos
Programų suvokimas
4
Programų supratimo tikslai
• Pagr. tikslas yra sėkmingai įgyvendinti pageidaujamus PĮ
pakeitimus.
• Siekiant tikslo reikia gauti informaciją apie:
– Probleminę sritį
– Programos vykdymo rezultatus
– Produkto aplinką
Program understanding
5
Programų suvokimas (1)
• Prieš įgyvendinant suvokimus, svarbu suprasti
tiek PĮ kaip visumą, tiek atskiras programų
sistemos dalis, kurios bus keičiamos
• Priežiūros metu tai reiškia:
– Turėti bendrąsias žinias apie tai, ką programų sistema
daro ir kaip ji susijusi su savo aplinka;
– Nustatyti, kur pakeitimai turi būti realizuojami;
– Turėti gilias žinias apie tai, kaip veiks pataisytos
programos dalys
Program understanding
6
Programų suvokimas (2)
• Programų suvokimo kaštai sudaro žymią programų
priežiūros kaštų ir darbo pastangų dalį
• Hewlett Packard vertina, kad programų suvokimo kaštai
yra $200 mln. per metus
• Iki pusės keitimo kaštų sudaro suvokimo kaštai
• Kaštai didėja, jei
– Programuotojas prižiūri ne paties sukurtą programą
– Dokumentacija netiksli, pasenusi arba jos visai nėra
– Programos struktūra degradavo dėl „greitų
pataisymų“
Program understanding
7
Programos suvokimo modelis
Program understanding
8
Suvokimo procesas
• Suvokimas yra transformacija tarp
programavimo srities ir probleminės srities,
kurios metu rekonstruojamos
– Šių sričių (įskaitant tarpines sritis) žinios ir
– Sąryšiai tarp jų
Program understanding
9
Programos suvokimui reikalingos
žinios (1)
• Probleminės srities žinios
– Padeda pasirinkti reikiamus resursus (algoritmus, įrankius,
metodus)
• Vykdymo supratimas
– Sistemos elgsenos supratimas abstrakčiame lygmenyje
– Tikėtinų pakeitimo pasekmių numatymas
Program understanding
10
Programos suvokimui reikalingos
žinios (2)
• Priežastiniai sąryšiai
– Tikslas yra nustatyti planuojamo pakeitimo poveikius kitoms
sistemos dalims („raibuliavimo efektas“)
– Nustatyti sistemos dalių tarpusavio priklausomybių pobūdį, nes
priklausomybės atliekant keitimą gali sukelti problemų
• Produkto-aplinkos sąryšiai
– Tikslas yra nustatyti visus išorinius faktorius (veiklos taisykles,
vyriausybės nustatytas taisykles ir kt.), kurios gali turėti įtaką
sistemai
• Sprendimus įtakojantys požymiai
– Požymiai (sudėtingumas, prižiūrimumas), padedantys priimti
resursų ir finansų paskirstymo sprendimus
Program understanding
11
Programos suvokimo strategijos
• Iš viršaus (top-down)
– Probleminės srities analizė ir atitikmenų kode
identifikavimas
• Iš apačios (bottom-up)
– Tam tikrų kodo pasikartojančių šablonų atpažinimas ir
semantinės prasmės suteikimas
• Oportunistinė
– Abu metodai naudojami kai to prireikia
Program understanding
12
Suvokimas iš viršaus į apačią
Program understanding
13
Suvokimas iš apačios į viršų
Program understanding
14
Suvokimas iš apačios į viršų
• Programuotojas atpažįsta, išskiria ir grupuoja
tam tikrus kodo šablonus programoje
• Šablonai yra apjungiami į semantinę prasmę
turinčias struktūras
• Procesas kartojamas tol, kol apima visą
programos kodą ir programa yra suprantama
Program understanding
15
Dviejų suvokimo modelių
įvertinimas
• Pagrindiniai abejų suvokimo strategijų trūkumai:
– Neatsižvelgiama į išorės faktorių (pvz., priežiūros
įrankių) indėlį
– Praktikoje suvokimo procesas nėra toks tvarkingas ir
gerai apibrėžtas, kaip modeliuose
• Praktikoje programuotoji abu modelius taiko
oportunistiškai
Program understanding
16
Oportunistinis modelis
• Suvokimas priklauso nuo trijų pagrindinių vienas
kitą papildančių dedamųjų:
– Žinių bazė: priežiūros specialisto ekspertinės žinios ir
patirtis
– Mentalinis modelis: programuotojo dabartinės žinios
apie analizuojamą programą
– Asimiliacijos procesas: žinių išgavimo iš PĮ artefaktų
procesas
Program understanding
17
Programos suvokimo faktorių
taksonomija
Program understanding
18
PĮ priežiūra ir suvokimas
• Programų suvokimas yra svarbi ir brangiai
kainuojanti PĮ priežiūros dalis
• “There is no high-quality substitute for experience
when it comes to understanding and maintaining
a system, as existing methods and tools are not
effective enough and documentation tends to be
unreliable”*
* Survey: C. Tjortjis and P.J. Layzell, "Expert Maintainers’ Strategies and
Needs when Understanding Software: A Qualitative Empirical Study",
Proc. IEEE 8th Asia-Pacific Software Engineering Conf. (APSEC 2001),
IEEE Comp. Soc. Press, 2001, pp. 281-287.
Program understanding
19
Priežiūros praktikos ir reikalavimai
susiję su suvokimu
• Siekient palengvinti suvokimą, sistemos atvaizdai (peržiūros,
abstrakcijos, diagramos, modulių sąryšiai) turi būti išgauti pusiau
automatiškai
• Posistemių aukšto lygmens abstrakcijos su susijusiomis funkcijomis
ir sąryšiais turi būti vizualizuojamos, ir dokumentuojamos ateičiai
• Grupės narių bendravimo informacija susijusi su nagrinėjama
sistema turi būti fiksuojama ir saugoma
• Žinios apie atliktus pakeitimus ir iš komentarų išgauta informacija
yra labai svarbi
• Turi būti įvertinta dalinio programų suvokimo rizika
Program understanding
20
Priežiūros užduotys ir veiklos, kurios
reikalauja programų suvokimo
Source: Program Understanding: A Survey,
A. von
Mayrhauser and A. M. Vans
Program
understanding
Technical Report CS-94-120, 1994.
21
Programų suvokimo komponentų
taksonomija
Source: Software Comprehension – Integrating Program Analysis and Software
Program understanding
22
Visualization, Welf L¨owe Morgan Ericsson Jonas Lundberg Thomas Panas
Suvokimo iššūkiai (1)
• Netinkamas intelekto naudojimas (painus kodas)
– Sunku suvokti kitiems programuotojams
• Skirtingi programavimo stiliai
– Didelė programų sistema, kurią kūrė skirtingus programavimo
įgudžius ir patirtį turinčių programuotojų komanda
– Tokias programas sunku suvokti
Program understanding
23
Suvokimo iššūkiai (2)
• Netinkami vardai
– Naudojami beprasmiai vardai arba nenuosekli vardų sudarymo
strategija
– Vardas turi aiškiai apibrėžti įvardijamą objektą
• Žodyne nenaudojami srities terminai
– Tinkamų srities terminų naudojimas yra laikomas gerąja praktika
– Tinkami vardai ir komentarai, nesant pakankamos dokumentacijos, labai
palengvina suvokimą
• Prieštaringas terminų žodynas
– Programos identifikatorių suvokimas priklauso nuo jų gebėjimo tiksai
aprašyti srities sąvoką
– Netinkamo vardo naudojimas apsunkina suvokimą
Program understanding
24
Suvokimo iššūkiai (3)
• Programų atvaizdavimas
• Panašių sakinių ir modulių grupavimas palengvina suvokimą
• Geras kodo išdėstymas daro kodą suprantamesniu
• Nepakankamas komentavimas
• Komentarų trūkumas yra pagrindinė priežiūros kaštų augimo
priežastis
• Gilios paveldėjimo hierarchijos
• Mažai žmonių gali tinkamai suprasti hierarchijas, kurių gylis didesnis
nei 3
Program understanding
25
Suvokimo iššūkiai (4)
• Konceptų aptikimas
– Viso kodo skaitymas didelės sistemos atveju yra labai neefektyvu
– Pageidaujamam kodui surasti naudojama paieška
– Skirtumai tarp pakeitimo užklausos aprašo natūralia kalba ir programos
žodyno gali apsunkiti keitimo užklausos įgyvendinimą
• Kodo atsikartojimas (“bad smells in code”)
– Išbandytą kodą naudoti lengviau, tačiau tai apsunkina priežiūrą
• “Negyvas” (niekada nevykdomas) kodas
– Viena iš pagrindinių suvokimo problemų.
Program understanding
26
Suvokimo metodai
• Abstrakcijomis grįstas (by step-wise abstraction)
– Nustatomos kritinės funkcijos ir atsekant jų naudojimą programoje
nustatomos visos programos funkcijos
• Sąrašu grįstas(Checklist-based)
– Skaitytojams duodamas sąrašas dalykų, į kuriuos reikia atkreipti dėmesį
– Skirtingiems skaitytojams duodami skirtingi sąrašai, kad kiekvienas
gilintųsi į atskirą problemos aspektą
• Defektais grįstas (Defect-based)
– Defektai suklasifikuojami (pvz., netinkamas, trūkstamas funcionalumas
– Kiekvienai defektų klasei sukuriamas scenarijus, padedantis surasti tos
klasės defektus
• Perspektyvinis (Perspective-based)
– Panašus į defektais grįstą, tačiau kodo skaitytojai turi skirtingas roles
(testuotojas, projektuotojas, vartotojas)
Programų suvokimas
27
Suprantamumą palengvinantys
faktoriai (1)
• Ekspertinės žinios
– Gilios probleminės srities, problemų sprendimo ir programavimo
kalbų žinios palengvina programos suvokimą
• Sintaksės paryškinimas
– Gali būti naudojamas kartu su kitais metodais, palengvinančiais
konceptų aptikimą programų išeities tekste
• Kryžminis indeksavimas
– Tarp kodo dalių parašytų skirtingomis programavimo kalbomis gali
palengvinti kodo suprantamumą
Program understanding
28
Suprantamumą palengvinantys
faktoriai (2)
• Iškvietimų grafai
– Atvaizduoja sąryšius tarp skirtingų programos modulių (funkcijų,
procedūrų)
– Statiniai grafai rodo galimus iškvietimus
– Dinaminiai grafai rodo iškvietimus programos vykdymo metu
• Komentarai ir anotacijos
– Virtualūs komentarai, kurių nebuvo originaliame išvesties tekste
– Anotacijos padeda lengvai suprasti programos kodą
Program understanding
29
Suprantamumą palengvinantys
faktoriai (3)
• Programų sluoksninė analizė („slicing“)
– Efektyvūs metodas leidžiantis sumažinti reikalingo perskaityti kodo apimtį
– Naudojamas priežastiniams-pasekmių sąryšiams aptikti
– Palengvina klaidos aptikimą
• Poveikio analizė
– Skirta aptikti kodo dalis, kurias gali paveikti atliekami pakeitimai
– Padeda aptikti priklausomybes tarp skirtingų kodo dalių
• Programos dekompozicija
– Didelės programos suskaidymas į mažesnius lengviau suprantamus modulius
Program understanding
30
Suvokimo efektyvumas
• Įtakoja daugelis faktorių:
– Programų priežiūros charakteristikos
– Programos charakteristikos
– Užduoties charakteristikos
Programų suvokimas
31
Reikalavimai programų
prižiūrėtojui
•
•
•
•
•
•
Programų bazės žinojimas
Taikomosios srities žinios
Programavimo kalbos žinios
Programavimo ekspertinės žinios
Įrankių žinojimas
Individualūs sugebėjimai
Programų suvokimas
32
Programos charakteristikos
•
•
•
•
Taikymo srities charakteristikos
Programavimo srities charakteristikos
Programos dydis ir sudėtingumas
Dokumentacijos tikslumas ir prieinamumas
Programų suvokimas
33
Užduočių charakteristikos
• Užduoties tipas
– Tobulinimas, taisymas, adaptavimas, išplėtimas ...
• Užduoties dydis ir sudėtingumas
• Laiko apribojimai
• Aplinkos faktoriai
Programų suvokimas
34
Modeliai
• Mentaliniai modeliai
– Vidinis programos darbo vaizdas programuotojo
galvoje
• Pažinimo modeliai
– Teoriniai procesų modeliai, padedantys
programuotojams susidaryti programos darbo vaizdą
(mentalinį modelį)
Programa
Programų suvokimas
Pažinimo
Modelis
35
Mentalinis
Modelis
Mentaliniai modeliai
• Programų suvokimas yra procesas, kurio metu
esamos žinios yra naudojamos naujoms žinioms
įgyti tikslu suprasti programą
• Tiek esamos, tiek naujai įgytos žinios
naudojamos programos darbo mentaliniam
modeliui sudaryti
Program understanding
36
Mentaliniai modeliai
• Statiniai elementai
– Teksto struktūros žinios
– Mikrostruktūra
– „Kodo gabalai“(makrostruktūra)
• Dinaminiai elementai
– Skaidymas į dalis (chunking )
– Kryžminis indeksavimas (cross-referencing)
• Pagalbiniai elementai
– „Švyturiai“
Programų suvokimas
37
Statiniai mentalinio modelio
elementai
• Struktūros žinios apie programos tekstą ir jo struktūrą
– Formuojamos iš patirties ir saugomos ilgalaikėje atmintyje
• „Gabalai“ (chunks) – įvairaus abstrakcijos lygmens teksto
struktūros
– Atitinka programos struktūrinės diagramos elementus.
• Planai yra žinių elementai, kurie leidžia patikrinti lūkesčius,
hipotezes ir palaikyti dėmesį
– Įeina žinios apie sąryšius tarp programos dalių ir priežastinius ryšius.
• Programavimo planai gali būti aukšto lygmens, žemo lygmens arba
vidutinio lygmens programavimo sąvokas.
– Objektų, operacijų, testų rolės, kiti planai ir apribojimai
• Srities planai apima visas žinias apie probleminę sritį, išskyrus kodą ir
žemo lygmens algoritmus.
Program understanding
38
Teksto struktūra
• Programos tekstas ir jos struktūra
– Valdymo struktūra: iteracijos, sekos, sąlyginiai
sakiniai
– Kintamųjų paskelbimai
– Iškvietimo hierarchijos
– Parametrų apibrėžtys
• Mikrostruktūra – programos sakiniai ir jų
sąryšiai.
Programų suvokimas
39
„Gabalai“ (fragmentai)
• Makrostruktūra
• Įvairaus lygmens abstrakcijos
• Galima apjungti į didesnius „gabalus“
Programų suvokimas
40
Planai (objektai)
• Žinių elementai skirti interpretacijoms, teiginiams ir
lūkesčiams validuoti
• Apjungia priežastinių ryšių žinias apie informacijos
strautus ir sąryšius tarp programos dalių
• Programavimo planai
– Pagrįsti programavimo konceptais
– Žemo lygmens: ciklai ir sąlyginio kodo segmentai
– Vidutinio lygmens: paieška, rūšiavimas, sumavimas ir t.t Aukšto
lygmens
• Srities planai
– Visos žinios apie probleminę sritį
– Pavyzdžiai: probleminės srities objektai, sistemos aplinka,
domain-specific solutions and architectures.
Programų suvokimas
41
Dinaminiai mentalinių elementų
modeliai
• Strategija, kuri aprašo veiksmų, reikalingų tam tikram tikslui pasiekti,
seką
– Kodo eilučių skaitymas ir supratimas kuriant mentalinį modelį
• Žinias kuriančių mechanizmų supratimas
– Fragmentavimas (Chunking) kuria naujas aukštesnio abstrakcijos lygmens
struktūras iš žemesnio lygmens abstrakcijų
– Kryžminis indeksavimas susiej skirtingus abstrakcijos lygmenis
• Komponentai yra procesai, epizodai, veiksmai
– Procesai yra epizodų sekos
– Epizodai yra veiksmų sekos
– Veiksmai yra elementarios programuotojo veiklos priežiūros metu
Program understanding
42
Kryžminis indeksavimas
• Programos dalių atvaizdavimas į funkcinius
aprašus
temp = a;
a = b;
b = temp;
swap
for (i=0; i<size; i++)
if (array[i]==target)
return true;
Programų suvokimas
sequential search
43
Pagalbiniai elementai
• Švyturiai
– Atpažįstami informacijos blokai.
• Pvz., reikšmių sukeitimo blokas rikiavimo
procedūroje
– Patyrę programotojai atpažįsta greičiau
– Parastai naudojama atliekant supratimą iš viršaus į
apačią
• Diskursas
– „Programuotojų susitarimų visuma“
• Pavyzdžiai: kodavimo standartai, geroji praktika,
tikėtinas duomenų struktūrų naudojimas, šablonai
Programų suvokimas
44
Kognityviniai modeliai
•
•
•
•
•
•
Letovsky
Shneiderman and Mayer
Brooks
Soloway, Adelson and Ehrlich
Pennington
Mayrhauser and Vans (integruotas metamodelis)
Programų suvokimas
45
Letovsky modelis
Programų suvokimas
46
Letovsky modelis
• Three main components: knowledge base, mental model
(internal representation), and assimilation process.
• Maintainer produces a mental representation by
combining existing knowledge through a assimilation
process of external representation of the software
• The knowledge base contains programming expertise,
problem-domain knowledge, rules of discourse, plans,
and goals.
• The mental model has three layers: a specification, an
implementation, and an annotation layer.
Program understanding
47
Letovsky modelis
• Specification layer - highest abstraction level
completely characterizes the program goals.
• Implementation layer contains lowest level
abstraction, with data structures and functions
• Annotation layer link each goal in the specification
layer to its realization in the implementation layer.
• The assimilation process occurs either top-down or
bottom-up in the way they think yields the highest
return in knowledge gain.
48
Shneiderman modelis
Programų suvokimas
49
Shneiderman modelis
• Proposed in 1979
• Based on two forms of programming knowledge
– syntactic and semantic (general and task
related semantic knowledge)
• Describes the comprehension process that
transform the program in short-term memory
into internal semantic knowledge via a
chunking process
Program understanding
50
Shneiderman modelis
• Comprehension model recodes the program in shortterm memory into an internal semantic representation
via a chunking process.
• These internal semantics contain different levels of
program abstraction.
• At the top are high-level concepts such as program
goals. The lowest levels contain details such as the
algorithms used to achieve program goals.
51
Shneiderman modelis
• Long-term memory, a knowledge base with semantic
and syntactic knowledge, assists during internal
semantics construction.
• Syntactic knowledge is programming language
dependent, while semantic knowledge concerns general
programming knowledge independent of any specific
programming language.
• Like working memory, semantic knowledge in long-term
memory is layered and incorporates high-level concepts
and low-level details.
• Program understanding is directional: It starts with the
program code and continues until the problem statement
is reconstructed.
52
Brooks modelis
Programų suvokimas
53
Brooks modelis
• Describes program comprehension as developer’s
reconstruction of domain knowledge
• Program comprehension is complete when a complete set of
mappings can be made from the top level domain (problem
domain) to the bottom level domain (programming domain).
• Domain knowledge emphasizes the function of information
contained in the software
• Developers comprehend the program by recreating
mappings from the problem domain or real-world problems,
to the programming domain through several intermediate
knowledge domains.
• Intermediate domains are used to decrease the gap
between problem and programming domain.
Program understanding
54
Brooks modelis
• Four different knowledge domains to reach the
programming
domain:
inventories,
accounting,
mathematics, and programming languages.
• Knowledge within each domain includes details about
domain objects, the operations allowed on them, and the
order in which operations are allowed
• Inter-domain knowledge describes the relationships
between objects in different but closely related domains
55
Brooks modelis
• The mental model is built through a top-down
process that successively refines hypotheses
• A cognitive process verifies that internal
representations reflect knowledge contained in
external representations such as code, design
documents, or requirements specifications.
• Beacons are the main vehicle for this
verification, which is also hypothesis driven.
56
Programų švyturiai („beacons“)
• The information required for hypothesis
generation and refinement is manifested in key
features:
• Internal features and
• External features
• to the program –
– known as beacons which serve as typical indicators
of the presence of a particular structure or operation
Program understanding
57
Programų švyturiai („beacons“)
(1)
• Internal to the program text
• 1. Prologue comments, including data and variable
dictionaries
• 2. Variable, structure, procedure and label names
• 3. Declarations or data divisions
• 4. Interline comments
• 5. Indentation or pretty-printing
• 6. Subroutine or module structure
• 7. I/O formats, headers, and device or channel
assignments
Program understanding
58
Programų švyturiai („beacons“)
(2)
•
•
•
•
•
•
External to the program
1. Users' manuals
2. Program logic manuals
3. Flowcharts
4. Cross-reference listings
5. Published descriptions of algorithms or
techniques
Program understanding
59
Soloway modelis
Programų suvokimas
60
Soloway modelis
• Developer constructs a hierarchy of goals and
plans top-down based on rules
• The model suggests decomposing the code into
familiar elements that will be the foundation for
the internal representation of the system
 Uses three types of plans: strategic, tactical, and
implementation.
 Strategic plans describe a global strategy used in
a program or algorithm and specify language
independent actions.
Program understanding
61
Soloway modelis
 Tactical plans are local strategies for solving a
problem; these plans contain language-independent
specifications of algorithms.
 Implementation plans are language dependent and
are used to implement tactical plans; they contain
actual code fragments.
 A mental model is constructed top-down.
 It contains a hierarchy of goals and plans.
 Rules of discourse and beacons help decompose
goals into plans and plans into lower level plans.
62
Soloway modelis
 The triangles represent knowledge (programming
plans or rules of discourse). For example, a subset
of the rules of discourse might include the following:
 variables updated same way as initialized,
 no dead code,
 a test for a condition means that the condition must be
potentially true,
 don't do double duty with code in a non-obvious way, and
 an If is used when a statement body is guaranteed to
execute only once; a While is used when the statement may
need to be executed repeatedly.
63
Soloway modelis
 The diamond represents the understanding process.
 The rectangles illustrate internal or external program
representations.
 External representations include documents such as
requirements or design documents; code; user,
reference, or maintenance manuals; and other
miscellaneous related documents.
 Internal representations include plans and schemas.
 The understanding process matches external
representations to programming plans using rules of
discourse to select plans, by setting expectations.
64
Pennington modelis
Programų suvokimas
65
Pennington modelis
• Developers build a program and situation model
bottom-up from the elementary blocks source
code
• Program model represents a control-flow
abstraction of the code that identifies the
elementary blocks of code control in the code.
• Situation model represents the problem domain
or real world
• The program model is usually developed before
the situation model.
Program understanding
66
Pennington modelis
• The program model is created buttom-up via the
chunking of microstructures into macrostructures and
via cross-referencing.
• Programming plan knowledge, consisting of
programming concepts, exploits existing knowledge
during the understanding task and infers new plans
for storage in long-term memory.
• A situation model is built by cross-referencing and
chunking.
• Beacons can invoke a particular schema (for
example, a swap operation causes the programmer
to recall sorting functions). Code statements and their
interrelationships form the microstructure.
67
Pennington modelis
• The model requires knowledge of real-world domains,
such as generic operating system structure and
functionality for the operating system domain.
• Domain plan knowledge is used to mentally represent
the code in terms of real-world objects, organized as a
functional hierarchy.
• Lower order plan knowledge can be chunked into
higher order plan knowledge.
68
von Mayrhauser and Vans
modelis
Programų suvokimas
69
von Mayrhauser and Vans
modelis
• Meta model consisting of four main
• components:
– top-down model,
– situation model, program model, and
– knowledge base
• Knowledge base is the foundation to build the
three former models through comprehension
process
Program understanding
70
von Mayrhauser and Vans
modelis
• The integrated code comprehension model has four
major components: the top-down, situation, and program
models and the knowledge base.
• The first three reflect comprehension processes. The
fourth is needed to successfully build the other three.
• Each component is involved in the internal
representation of the program (or short-term memory)
and a strategy to build this internal representation.
• The knowledge base furnishes the process with
information related to the comprehension task and stores
any new and inferred knowledge.
71
von Mayrhauser and Vans
modelis
• For large systems, a combination of approaches to
under standing becomes necessary.
• Therefore, the integrated model combines the top-down
understanding of Soloway, Adelson, and Ehrlich with the
bottom-up understanding of Pennington.
• Nevertheless, experiments show that programmers
switch between all three comprehension model
• Any of the three sub models may become active at any
time during the comprehension process.
• For example, during program model construction, a
programmer might recognize a beacon indicating a
common task such as sorting.
72
von Mayrhauser and Vans
modelis
• This leads to the hypothesis that the code sorts
something, causing a jump to the top-down model.
• The programmer then generates sub goals and searches
the code for clues to support these sub goals.
• If the programmer finds a section of unrecognized code
during this search, he may return to program model
building.
• Structures built by any one model component are
accessible by the other two, but each model component
has its own preferred knowledge types.
73
Programos kodo peržiūra
(Software Inspection)
Program understanding
74
Software inspection
• One of most effective quality assurance
techniques in software engineering.
• The primary goal of an inspection is to detect
defects before the testing phase begins
• Contributes to improve the overall quality of
software with the corollary budget and time
benefits
Program understanding
75
Software inspection taxonomy
Program understanding
76
Dimensions of inspection (1)
• The goal of technical dimension is to
characterize different inspection methods to
identify similarities and differences among them.
• Each inspection approach needs to be
characterized in more detail according to the
– activities performed (process),
– the inspected software product (product),
– the different team roles as well as overall optimal size
and selection (team roles, size, and selection),
– and the technique applied to detect defects in the
software product (reading technique).
Program understanding
77
Technical dimension
Program understanding
78
Technical dimension - Activities
•
•
•
•
•
•
Planning,
Overview,
Defect Detection,
Defect Collection,
Defect Correction, and
Follow-up.
Program understanding
79
Technical dimension - Planning
• The objective of planning phase is to organize a
particular inspection when materials to be
inspected pass entry criteria, e.g. when source
code successfully compiles without syntax errors
• The overview phase consists of a first meeting in
which the author explains the inspected product
to other inspection participants. The main goal of
the overview phase is to make the inspected
product more lucid and, therefore, easier to
understand and inspect for participants.
Program understanding
80
Technical dimension – Defect
• Defect detection phase - core of an inspection.
• The main goal of the defect detection phase is to
scrutinize a software artifact to elicit defects.
• Defect collection
– Defects detected by each inspection participant must
be collected and documented.
– Decision must be made whether a defect is really a
defect.
Program understanding
81
Technical dimension – correction
• Throughout the defect correction phase,
– the author reworks and resolves defects found or
– rationalizes their existence
• The objective of the follow-up phase is to check
whether the author has resolved all defects.
– one of the inspection participants verifies the defect
resolution
Program understanding
82
Dimensions of inspection (2)
• The managerial dimension provides information
on the effects inspections have on a project
• Managers are most often interested in the way
inspections influence
– project effort (effort),
– project duration (duration), and
– product quality (quality).
• May have other effects a manager might be
interested in, such as their contribution to team
building or education in a particular project
Program understanding
83
Dimensions of inspection (3)
• The organizational dimension characterizes the
effects inspections have on the whole
organization and vice versa.
• Subdimensions:
– project structure
– team
– environment
• These subdimensions provide important
information on the context in which inspections
take place.
Program understanding
84
Dimensions of inspection (4)
• The assessment dimension includes
– qualitative (qualitative assessment) and
– quantitative assessment (quantitative assessment) of
inspections.
• This dimension allows one to make a
comparison of cost/benefit ratios in a given
situation to determine the economics for a
software inspection implementation.
Program understanding
85
Dimensions of inspection (5)
• Finally, the tool dimension describes how
inspections can be supported with tools.
– purpose of the various tools (purpose)
– how they support a given inspection approach
(supported inspection approach).
Program understanding
86
Inspection roles
• Organizer: plans all inspection activities within a project
• Moderator: ensures that
– inspection procedures are followed
– team members perform their responsibilities for each phase
– moderates the inspection meeting
• Inspector: responsible for detecting defects in the target
software product
Program understanding
87
Inspection roles
• Reader/Presenter: in inspection meeting, leads the team
through the material in a complete and logical fashion.
• Author: develops the inspected product and is
responsible for the correction of defects during rework.
• Recorder: responsible for logging all defects in an
inspection defect list during the inspection meeting.
• Collector: consolidates the defects found by the
inspectors if there is no inspection meeting.
Program understanding
88
Generic model of inspection
Program understanding
89
Inspection quality model
Program understanding
90
Inspection quality factors
• Increasing the number of inspectors is expected to increase the
number of defects detected in an inspection. However, there will be
a ceiling effect after which adding an additional inspector does not
necessarily pay off in more detected defects.
• Using very experienced inspectors is expected to increase the
number of detected defects in an inspection.
• Spending more effort for defect detection is expected to increase the
number of defects detected in an inspection.
• The difficulty of a product is related to the defect-proneness. This
means that a more difficult software product contains more defects. •
• The larger the size of an inspected product, the more defects are
detected in an inspection
• The higher the initial quality of the inspected document, the lower
the number of detected defects.
Program understanding
91
Inspection effort
Program understanding
92
Inspection effort
• Increasing the number of people increases
inspection effort.
• The more experienced the inspectors, the less
effort they consume for defect detection and,
thus, for the overall inspection.
• The more difficult (e.g., complex) a product, the
more effort is required for inspecting it.
• The larger the size of the inspected product, the
more effort is required for its inspection.
Program understanding
93
Įgytos žinios
• Programų suvokimas ir programų priežiūra
• Programų suvokimo modeliai
• Programų inspekcija
Program understanding
94
Literatūra
• Penny Grubb, Armstrong A. Takang. Software
Maintenance: Concepts and Practice. World Scientific
Publishing Company; 2 ed., 2003.
• Diomidis Spinellis. Code Quality: The Open Source
Perspective. Addison Wesley Professional, 2006.
• Bill Blunden. Software Exorcism: A Handbook for
Debugging and Optimizing Legacy Code. Apress, 2003.
• Stan Jarzabek, Effective software maintenance and
evolution : a reuse-based approach. Taylor & Francis
Group, 2007.
• Oliver Laitenberger, Jean-Marc DeBaud, An
encompassing life cycle centric survey of software
inspection, Journal of Systems and Software, 50(1),
2000, 5-31.
Program understanding
95
Papildomi šaltiniai
• Von Mayrhauser, A. and Vans, A. M. Programų
suvokimas During Software Maintenance and Evolution,
IEEE Computer,1995. (lecture notes)
• Susan Elliott Sim. Research in Program
Comprehension (UC Irvine lecture notes).
• Jonathan Maletic. Programų Comprehension & The
Psychology of Programming (Kent State University
lecture notes).
• Richard Upchurch. Program Comprehension. From
Software Process Resource Collection. UMass –
Dartmouth, 1996.
Programų suvokimas
96