Program understanding1 Programų supratimas Prof. Robertas Damaševičius...

Program understanding 1

Programų supratimas

Prof. Robertas Damaševičius [email protected]

Prof. Vytautas Štuikys

Kauno technologijos universitetas

Programų inžinerijos katedra


Turinys

• Sąvokų apibrėžimas• Programų suvokimo rolė PĮ priežiūroje• Programų suvokimo iššūkiai• Programų suvokimo (kognityviniai) modeliai• Programų inspekcija

Programų suvokimas 3

ProgramProgramų suvokimasų 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ų suvokimo procesasProgramų 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ų 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ų 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ų 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ų“


Programos suvokimo modelis


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ų


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


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


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


Suvokimas iš viršaus į apačią


Suvokimas iš apačios į viršų


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


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


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


Programos suvokimo faktorių taksonomija


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.


Priežiūros praktikos ir reikalavimai Priežiūros praktikos ir reikalavimai susiję su suvokimususiję 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


Priežiūros užduotys ir veiklos, kurios reikalauja programų suvokimo

Source: Program Understanding: A Survey, A. von Mayrhauser and A. M. VansTechnical Report CS-94-120, 1994.


Programų suvokimo komponentų taksonomija

Source: Software Comprehension – Integrating Program Analysis and SoftwareVisualization, 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



• 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ų 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



• 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ų.


Suvokimo metodaiSuvokimo 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)


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ą



• 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ų 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


Suvokimo efektyvumasSuvokimo efektyvumas

• Įtakoja daugelis faktorių:– Programų priežiūros charakteristikos– Programos charakteristikos– Užduoties charakteristikos


Reikalavimai programų Reikalavimai programų prižiūrėtojuiprižiūrėtojui

• Programų bazės žinojimas• Taikomosios srities žinios • Programavimo kalbos žinios• Programavimo ekspertinės žinios• Įrankių žinojimas• Individualūs sugebėjimai


ProgramProgramosos chara charakkteristiteristikoskos

• Taikymo srities charakteristikos• Programavimo srities charakteristikos• Programos dydis ir sudėtingumas• Dokumentacijos tikslumas ir prieinamumas


Užduočių charakteristikosUžduočių charakteristikos

• Užduoties tipas– Tobulinimas, taisymas, adaptavimas, išplėtimas ...

• Užduoties dydis ir sudėtingumas• Laiko apribojimai• Aplinkos faktoriai


ModelModeliaiiai

• Mentaliniai modeliai– Vidinis programos darbo vaizdas programuotojo

galvoje

• Pažinimo modeliai– Teoriniai procesų modeliai, padedantys

programuotojams susidaryti programos darbo vaizdą (mentalinį modelį)

ProgramaMentalinis Modelis

Pažinimo 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


MentalMentaliniaiiniai model modeliaiiai

• 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“


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.


Teksto struktūraTeksto 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.


„„Gabalai“ (fragmentai)Gabalai“ (fragmentai)

• Makrostruktūra• Įvairaus lygmens abstrakcijos• Galima apjungti į didesnius „gabalus“


PlanPlanaiai ( (objektaiobjektai))

• Ž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.


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


Kryžminis indeksavimasKryžminis indeksavimas

• Programos dalių atvaizdavimas į funkcinius aprašus

temp = a;a = b;b = temp;

for (i=0; i<size; i++) if (array[i]==target) return true;

swap

sequential search


Pagalbiniai elementaiPagalbiniai 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


Kognityviniai modeliaiKognityviniai modeliai

• Letovsky• Shneiderman and Mayer• Brooks• Soloway, Adelson and Ehrlich• Pennington• Mayrhauser and Vans (integruotas meta-

modelis)


Letovsky modelisLetovsky modelis


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.

48

• 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.

Letovsky modelis


Shneiderman modelisShneiderman 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


51

• Comprehension model recodes the program in short-term 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.


52

• 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.


Brooks modelisBrooks modelis


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.

Brooks modelis

55

• 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

Brooks modelis

56

• 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.


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ų š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ų š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


Soloway modelSoloway modelisis


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.


62

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.


63

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, andan 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.


64

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.


Pennington modelPennington modelisis



• 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.


• 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


• 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 von Mayrhauser and Vans modelmodelisis



• 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


• 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


• 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


• 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)



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


Software inspection taxonomy


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).


Technical dimension


Technical dimension - Activities

• Planning, • Overview, • Defect Detection, • Defect Collection, • Defect Correction, and • Follow-up.


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.


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.


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



• 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



• 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.



• 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.



• 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).


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


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.


Generic model of inspection


Inspection quality model


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.


Inspection effort


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.


Įgytos žinios

• Programų suvokimas ir programų priežiūra• Programų suvokimo modeliai• Programų inspekcija


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.


Papildomi šaltiniaiPapildomi š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 understanding1 Programų supratimas Prof. Robertas Damaševičius...

Documents

Transcript of Program understanding1 Programų supratimas Prof. Robertas Damaševičius...