Program ų priežiūra ir tobulinimas Pakartotinės panaudos technologija

ProgramProgramų priežiūra ir tobulinimasų priežiūra ir tobulinimas

Pakartotinės panaudos technologijaPakartotinės panaudos technologija

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

Prof. Vytautas Štuikys

Kaunas University of Technology

Priežiūra ir pakartotinė panauda 2

TurinysTurinys

• Tikslas ir motyvacija• Pakartotinė panauda (reuse) ir priežiūra• Srities inžinerija ir taikymų inžinerija:

– Dvynių (twin) modelis• Srities analizė ir modeliavimas

– FODA (Feature-Oriented Domain analysis)


Intuityvus suvokimasIntuityvus suvokimas

• Bendras pakartotinės panaudos principas - ne iš naujo kurti programinius išteklius (artifaktus), o panaudoti jau kitų sukurtus– Surasti (dažniausiai komponentus)– Suprasti– Modifikuoti (adaptuoti)– Pritaikyti (naujame kontekste)


Motyvacija (1)

• Programų inžinerijos problemos– Žemas našumas, prasta kokybė

• Spręsti galima naudojant jau anksčiau sukurtą kodą (pakartotinė panauda), o ne “išradinėti dviratį”

• 60-85% realizuojamo kodo jau kažkada buvo realizuota• Sutaupomos lėšos ir laikas, nes nereikia iš naujo

specifikuoti, projektuoti, realizuoti ir testuoti produktą• Kokybė geresnė, nes komponentai jau buvo ištestuoti• Tačiau: blogai suprojektuotų ir neištestuotų komponentų

atkartojimas neduos jokios naudos


Panaudos objektai

• Turi būti projektuojami taip, kad galėtų būti lengvai panaudojami

• Jei nebuvo projektuojami panaudai, turi būti adaptuojami• Gali būti panaudojamos tiek žinios, tiek programos

išeities tekstai• Žinios:

– Proceso, pvz., objektinių projektavimo šablonų panauda– Personalo, pvz., ekspertinės srities žinios, paprastai

nepastovios, linkusios migruoti (į kitą projektą, organizaciją)– Produkto, pvz., duomenys, specifikacijos, kodas, testai


Pakartotinės panaudos nauda (1)

• Pagerinti darbo našumą• Pagerinti produkto kokybę• Pagerinti kodo pernešamumą į kitą aplinką ar

platformą• Sumažinti priežiūros pastangas ir laiką (kaštus)• Pagerinti sistemos prižiūrimumo charakteristikas


Pakartotinės panaudos nauda (2)

• Didžiausia panaudos nauda pasiekiama atliekant tobulinamąją (perfective) priežiūrą– Naudojami nauji komponentai, kuriuos galima paimti iš bibliotekų– Apima apie 50% priežiūros kaštų

• Schach [Grubb & Takang] atliktas tyimas parodė, kad jei > 51% projekto biudžeto skiriama priežiūrai, pakartotinė panauda leidžia žymiai sumažinti priežiūros kaštus


Panaudos įtaka prižiūrimumui

• Pakartotinai panaudojamų komponentų charakteristikos:– Bendrumas, vidinis rišlumas (cohesion), stiliaus

vienodumas, gera struktūra, standartų laikymasis

• Tokios pačios charakteristikos būdingos ir gero prižiūrimumo programoms

• Todėl, panaudojamumo pagerinimas teigiamai įtakoja ir prižiūrimumą


Panaudos tipai

• Komponentinė panauda: komponentai yra sistemos blokeliai, iš kurių surenkama sistema (kaip LEGO)

• Komponentų ‘suklijavimui’ naudojami gerai apibrėžti mechanizmai (pvz., scenarijų kalba arba konvejerinis (‘pipe’) modelis)

• Komponentai gali būti kuriami projektuojant panaudai (design for reuse) arba naudojant apgrąžos inžineriją (reverse engineering)

• Geratyvinė panauda: generatorius generuoja panaudojamą kodą

• Tinka tik gerai pažintoms ir specifikuotoms sritimis, pvz., kompiliatorių generatoriai


Panaudos dimensijos

• Horizontali panauda: komponentus galima panaudoti įvairiose srityse

• Vertikali panauda: komponentas gali būti panaudojamas tik tam tikroje konkrečioje srityje (domain-specific)


Panaudą neigiamai įtakojantys faktoriai

• Kelių skirtingų programavimo kalbų naudojimas organizacijoje

• Duomenų saugojimo formato ir vieningos duomenų bazės nebuvimas

• Nenoras kurti panaudojamų komponentų biblioteką

• Panaudojamų komponentų bibliotekos valdymo ir priežiūros problemos

• Nenoras viešinti panaudojamus komponentus, kad jų nepanaudotų komercinės naudos siekiantys konkurentai

• Nesugebėjimas įžvelgti ekonominę ir vadybinę panaudos naudą

• Koordinavimo tarp vykdomų projektų organizacijoje nebuvimas


Sisteminis suvokimasSisteminis suvokimas

• Srities analizė• Srities modeliavimas• Bendrų artefaktų išgavimas ir atvaizdavimas iš

srities tam, kad būtų galima efektyviai kurti giminingų komponentų (sistemų) šeimyną

• Apibendrinant: naudojamas dvynių (dviejų lygmenų) modelis apimantis srities inžineriją ir taikymo inžineriją


Dvynių (Dvynių (twintwin) gyvavimo ciklas) gyvavimo ciklas

• Atkartojimų kontekste yra taikomas sudvejintas gyvavimo ciklas – Srities inžinerija (design for reuse)– Taikymų inžinerija (design with reuse)


Kas yra Kas yra srities inžinerija (SI)srities inžinerija (SI)

• Srities inžinerija (SI) - tai sistemiškas procesas, kurio tikslas sukurti bendrinę (šerdinę/core) sistemos architektūrą ir komponentus/generatorius taikymų šeimynai

• SI gali būti taikoma esamiems arba naujiems taikymams. Ji apima analizę arba esamų taikymų arba probleminės srities koncepcijas.

• Sritis gali būti apibrėžta per uždavinių /funkcijų, kuriuos taikymai srityje gali išspręsti, aibę.


Apibrėžimų tąsaApibrėžimų tąsa

• Terminas ”sritis” (domain) vartojamas : – veiklos (business domain), – uždavinių rinkinio (problem domain), – taikymų rinkinio (application domain) bei – žinių ir metodų (solution domain), susietų bendra

terminologija, kontekstuose.

• Terminų hierarchija =>: sritis-taikymas-sistema• Raktas srities apibrėžimui yra nustatymas:

– 1) kas yra viduje srities, – 2) kokios yra srities ribos, – 3) kas yra srities išorėje.


Sąryšis tarp sričių ir taikymųSąryšis tarp sričių ir taikymų

• Taikymai gali priklausyti kelioms sritims• Taikymai ne būtinai perdengia visą sritį arba kelias sritis • Kelios sritys gali būti išsibarsčiusios dalimis viename

taikyme


Sąryšio tąsaSąryšio tąsa

• Kai srities funkcionalumą perdengia vienintelė posistemė vienoje sistemoje, sritis vadinama inkapsuliuota

• Kai srities funkcionalumas yra paskleistas per vienos sistemos keletą posistemių, tai sritis vadinama paskirstyta (distributed), arba prasiskverbusia (diffused)


Sričių tipaiSričių tipai

• Vertikalios sritys• PĮ sistemos yra klasifikuojamos pagal veiklos sritį (lėktuvų

bilietų rezervavimo, užsakymų apdorojimo)– Vertikalios sritys yra sričių sistemos

– Srities inžinerijos taikymo rezultatas vertikaliai sričiai gali būti atsikartojanti struktūra (framework, šablonas, bendrinė architektūra) arba atkartojami komponentai

• Horizontalios sritys• Horizontalios sritys (HS) yra tik sistemų dalys (bibliotekos,

DB dažniausiai nesudaro savarankiškos sistemos)– Srities inžinerijos taikymo rezultatas horizontaliai sričiai yra

atkartojami komponentai (HS gali būti vadinama komponentų sritimi)


Srities inžinerija ir taikymų Srities inžinerija ir taikymų inžinerijainžinerija

• Programų inžinerijos gamybos procesą galima dalinti į du procesus:– Srities inžineriją (SI)– Taikymų inžineriją (TI)

• Procesai gali vykti vienu metu• SI dar vadinama inžinerija (projektavimas) dėl

atkartojimo (engineering-for-reuse)• TI dar vadinama inžinerija (projektavimas) su

atkartojimu (engineering-with-reuse)


Taikymų klasifikacija Taikymų klasifikacija

• Kriterijus: sistemos kokybės užtikrinimo lygmuo• Kritiniai taikymai

– Susiję su saugumu, žmonių sveikata, sunkiu prieinamumu

• Nekritiniai taikymai (sistemos)– Eksperimentinės, mokymo, pasilinksminimo sistemos– Siejami su meta projektavimu (atskira tema)


Srities inžinerijos ir taikymo Srities inžinerijos ir taikymo

inžinerijos priklausomybėinžinerijos priklausomybė


Srities inžinerija ir paveldėtųjų Srities inžinerija ir paveldėtųjų sistemų ir tobulsistemų ir tobuliinimasnimas


Srities analizės problemos ir Srities analizės problemos ir sunkumaisunkumai

• Srities analizė pirmą kartą paminėta Neighbors 1980 m. tikslu nagrinėti taikymų šeimynas probleminėje srityje (atitinkamas terminas vienai sistemai yra sistemos analizė)

• Sritys tobulėja, sritys yra pasiskirsčiusios ir persidengiančios, taikymai migruoja, terminija nevienareikšmiškai apibrėžta--- iš čia kyla problemos ir sunkumai


Srities analizės kontekstas (SAK)Srities analizės kontekstas (SAK)

Pagal Sametinger (1997) srities analizės kontekstas aprašomas: Informacijos šaltiniais, Gautu rezultatu, t.y., išėjimo duomenimis Valdymu (žmonių veikla) Srities analizės metodais ir mechanizmais


Informacijos šaltiniai srities analizei Informacijos šaltiniai srities analizei

• Techninė ir mokslinė literatūra• Egzistuojantys taikymai (PĮ sistemos)• Klientų apžvalgos (atsiliepimai)• Ekspertų patarimai ir rekomendacijos• Reikalavimai sričiai


Srities analizės rezultatasSrities analizės rezultatas

Srities apibrėžimas Srities modelis, srities reikalavimų modelis Architektūros modelis Srities taksonomija (terminų, esybių, savybių

klasifikavimo sistema) Bendrumų ir variantiškumo aprašas Srities kalba kaip bendrasis modelis Srities standartai• Atsikartojantys komponentai


Srities inžinerijos charakteristikaSrities inžinerijos charakteristika

• Srities analizės procesas• nepertraukiamas ir iteratyvus• gali būti papildytas naujais reikalavimais• srities ribos gali keistis• naujos siauresnės sritys gali būti apibrėžtos


Srities analizės suvestinėSrities analizės suvestinė

Srities apibrėžimas ir pradinė stadija (nustatymas srities ribų ir dalinių sričių)

• Duomenų surinkimas (literatūros apžvalga, interviu su ekspertais, taikymų analizė)

• Bendrumų dokumentas: apžvalga, apibrėžimai, bendrumai, skirtingumai, parametrų variacijos, svarbiausi rezultatai, scenarijai (pavyzdžiai)

• Bendrinė architektūra ir modelio (-ių) įvairiuose lygmenyse sukūrimas


Srities analizės metodai: FODA Srities analizės metodai: FODA ((Feature-oriented Domain Analysis) Feature-oriented Domain Analysis)

• FODA struktūra: Konteksto analizė (context analysis) Srities modeliavimas (domain modeling) Architektūros modeliavimas (architecture modeling)

Konteksto analizės (kas yra už duotos srities ribų) rezultatas yra konteksto modelis


Srities konteksto modelisSrities konteksto modelis

• Konteksto modelis yra konteksto analizės rezultatas

• Modelis nustato:• Srities apimtį ir ribas (the scope of the domain) • Srities sąryšius (giminystę) su kitomis sritimis (its

relationship to other domains)• Konteksto modelis dokumentuojamas (A context

model documents the results)


Konteksto modelio struktūra Konteksto modelio struktūra

• Struktūrinės diagramos (structure diagrams):• rodo tikslinės srities sąryšius su kitomis sritimis• apibrėžia aukščiau esančias (bendresnes), to

paties rango ir siauresnes žemiau esančias sritis

• Duomenų srauto diagramos (data flow diagrams)• rodo duomenų srautus tarp visų tų sričių

• Visa paskesnė analizės veikla vyksta konteksto modelio rėmuose:


Srities modeliavimas (SM)Srities modeliavimas (SM)

• Tikslas - uždavinių bendrumų ir skirtingumų, kuriuos nagrinėja srities taikymai, analizė.

• Tai nenutrūkstamas žingsninis (inkrementinis) mokymosi procesas

• Srities modeliavimas susideda iš:• Požymių analizės (feature analysis), • Esybių sąryšių modeliavimo (entity relationship

modeling) • Funkcinės analizės (functional analysis).

• Rezultatas - įvairūs modeliai skirtingiems problemų aspektams aprašyti


Požymių analizės išdava Požymių analizės išdava

• Galinių vartotojų suvokimas apie taikymų bendrąsias galimybes duotoje srityje - taikymų servisas.

• Gali būti ir kiti aspektai: • kaip našumas,• taikymui numatyta aparatūros platforma


Esybių sąryšio modeliavimasEsybių sąryšio modeliavimas

• Esybių sąryšių modeliavimas išgauna (captures) ir apibrėžia faktus ir žinias taikymų (programų) realizacijai duotoje srityje

• Esybės gali būti aprašytos klasių arba požymių diagramomis– Bendrinimas (generalisation) naudoja sąryšį ‘is-a’– Agregavimas (aggregation) naudoja sąryšį ‘consists-of’– Šiais sąryšiais detalizuojama: bendrumai, skirtingumai ir

kompozicijų struktūros


FunkcinėsFunkcinės analizės išdava analizės išdava

Funkcinė (srities) analizė nustato:• funkcinius bendrumus ir skirtumus srities taikymuose• nagrinėja struktūrinius ir elgsenos aspektus• nagrinėja komponentų projektavimą funkcinės analizės

metu• požymiai ir sprendimai yra inkorporuojami į modelį

suprojektuojant atskirus komponentus alternatyvoms, juos parametrizuojant ir bendrinant su atskirų komponentų konkretizavimu alternatyvoms


Architektūros modeliavimo Architektūros modeliavimo išdavaišdava

• Tikslas - pateikti sprendimus tiems PĮ uždaviniams, kurie buvo nustatyti modeliuojant sritį

• Architektūros modelis - bazė detaliam projektavimui ir komponentų kūrimui

• FODA architektūros modelis yra aukštesnio lygmens taikymų projektavimas toje srityje

• Identifikuojami bendri komponentai ir susiejami su požymiais, funkcijomis ir duomenimis

• Architektūros modelis pateikiamas skirtinguose abstraktumo lygmenyse (sluoksniuose) su komponentais kiekviename sluoksnyje.


Aukšto abstraktumo laipsnio Aukšto abstraktumo laipsnio komponento aprašaskomponento aprašas

• Komponentas – susietų savybių (požymių) rinkinys

• Išskirti savybes. Savybė – išorėje matoma srities charakteristika

• Suklasifikuoti savybes. Bendros savybių klasės: privalomosios, nebūtinos, pasirenkamosios

• Apjungti savybes ir• Atvaizduoti (aprašyti) savybių rinkinį kaip

komponentą


3.42. FODA 3.42. FODA santraukasantraukaPhase Input Process Output

Context analysis Operatingrequirements, standards

context analysis context model

features, context model features analysis feature modelapplication domainknowledge

entityrelationshipmodeling

entityrelationshipmodel

Domain modelingdomain technology,context model , featuremodel , functional

data flow model

entity relationshipmodel, requirements

analysisfinite statemachine model

Architecture

implementationtechnology, contextmodel, feature model

architectureprocessinteraction model

Modeling entity relationshipmodel, designinformation

modeling module structurecharts


Atkartojimo brandos Atkartojimo brandos lygmenyslygmenys

• Pradinis (trumparegis mąstymas, bijomasi atsikartojimo kainų, pasipriešinimas, atsikartojimas individualus, nekoordinuotas ir neplanuotas)

• Stebimas (vadybinis aspektas, mažas aktyvumo skatinimas, kaina yra žinoma, yra individualūs pasiekimai)

• Koordinuojamas (organizacijos atsakomybė, srities analizės sujungimas su architektūriniais dalykais gamybai, panaudos taktika, panaudos atsipirkimas yra žinomas, komponentų standartizacija)

• Suplanuotas (dvynių gyvavimo ciklas, ataskaitos apie panaudos išlaidas ir pajamas, panaudos yra skatinamas, atsikartojimas per visas funkcines f. sritis)

• Įsišaknijęs (panaudos yra kasdienis reikalas, SA per visas architektūras, korporacijos apibrėžimai, nurodymai, instrukcijos, standartai)


Analizės metodų palyginimas ir Analizės metodų palyginimas ir įvertinimasįvertinimas

• Yra daug SA metodų, (1994 m. Arango (94) pateikė, palygino ir įvertino SA 8 metodus, šiandien jų daugiau, kai kurie

nauji, kiti-žinomų išplėtimai )• Arango parodė, kad metodai turi labai daug bendrumų;

jis taip pat suformulavo jų skirtingumus• Kaip įprasta, naujoje šakoje yra daug terminų nevienodo

traktavimo• Pagrindinis metodas yra FODA, pasiūlytas 1990 m.

Programinės įrangos instituto iš Carnegie Mellon University (USA)


Srities inžinerijos (SI) pagrindinės Srities inžinerijos (SI) pagrindinės problemos ir sunkumaiproblemos ir sunkumai

• Nėra pakankamai gerai apibrėžta terminija dėl tyrimų nepakankamos brandos

• SI neišbaigtumas. Tai reiškia, kad srities modeliavimas niekada nėra pilnas, modelis visada gali būti patikslintas

• Paskirstytos ir persidengiančios sritys• Nėra pakankamai gero palaikymo


Šaltiniai

• P. Grubb and A. A. Takang. Software maintenance: Concepts and Practice. World Scientific.

Documents

Program ų priežiūra ir tobulinimas Pakartotinės panaudos technologija