Анализа на влијанието на промената на објектите

Одржувањето на софтверот генерално се смета за скап, напорен и долготраен процес. Една од причините за ова е бидејќи е тешко за софтверските инженери задолжени за одржување целосно да го разберат софтверскиот систем кои тие не го проектирале или имплементирале. Дури и самите тие да го развиле системот, лесно е да се заборави на деталите на дизајнирањето или кодот, и уште повеќе доколку има малку или воопшто нема документација за системот. Друга причина е дека мора да се земат предвид меѓусебните односи помеѓу промената што треба да се изврши во софтверот и остатокот од системот. Постојат комплексни меѓусебно зависни односи помеѓу различни компоненти на софтверот.

Постојат различни причини за промени во софтверскиот систем:

1. Перформансите на софтверот мора да бидат одржувани (перфективно одржување);
2. Грешките во наведените податоци (спецификации), дизајнот и имплементацијата мора да бидат исправени (корективно одржување);
3. Конечниот производ мора да функционира во различни средини (адаптивно одржување);
4. Конечниот производ мора, исто така, и да еволуира (еволутивно одржување);

Проблемите со промената на објектите во софтверот можат да бидат разгледувани како:

1. Идентификација на жртвите на промената;
2. Идентификација на типот на промените кои можат да се извршат над секој објект од софтеврот;
3. Оценување на ефектите на промената;
4. Стекнување на знаење за тоа како да се спроведе промената.

Импактната анализа може да се дефинира како активност на идентификација на објектите кои треба да се модифицираат за да се изврши промената, т.е. проценување на потенцијалните последици од извршување на промената. Импактна анализа на некоја промена е неопходна од следниве причини:

1. За да се пресмета трошокот што ќе го предизвика промената. Ако предложената промена ја има способноста да влијае на големи разединети (разделени) секции на софтверот, тогаш промената можеби би требало да биде преиспитана и ако е можно да биде отфрлена со цел да се проектира друга побезбедна промена.

1. За да се разбере значењето и односите помеѓу определениот предмет на промената и структурата на софтверот. Постојат софтверски алатки за импактна анализа кои можат да користат систем за бележење на спроводливоста (управување, спроведување) (notion conductivity), бидејќи постојат релации на зависност кои се подобри спроводници на промени. Овие типови на релации ја дозволуваат идентификацијата на деловите од софтверот кои мораат да бидат изменети и делови кои можат да се модифицираат за даден модел (примерок) на промена (change-type).

1. За да се запишат историјата на информации поврзани со промената и да се процени квалитетот на одредена промена. Истражувањето на повратната реакција од корисниците на променетиот производ помага при одржувањето на квалитетот на софтверот.

1. За да се одредат деловите на софтверот кои можеби треба да бидат тестирани за тоа да се одреди дали се стабилни (непадливи) (regression tested), по извршување на некоја и да се одреди ранливоста на некои критични секции на софтверот со цел да се одреди дали функционалноста на тие делови од софтверот се чувствителни на промените направени на софтверот.

Импактната анализа се врши со помош на одредени модели т.е. методи. Овде ќе биде разгледан генеричкиот модел кој користи база на знаења (познавања) (generic knowledge-based model). Тој е заснован на фази од четири животни циклуси и специфичен делокруг на погледи (domain-specific view).

Моделот What-If

Моделот What-If е генерички модел заснован на знаење. Овој модел е генерички бидејќи не е заснован на каков било тип на програмирање или специфичен програмски јазик или на некаков метод на дизајнирање. Затоа, тој може да биде применет за темелот на проблемот кој треба да се реши. Целта на овој модел е да се процени влијанијата на променетите објекти во софтверскиот систем. Целта на овој модел е да се процени однапред влијанието (импакт) на промената на објектите во софтверскиот систем.

Концептуална рамка

Нека S биде софтверскиот систем претставен од множество на објекти O_s = {o₁,o₂,…,o_n}. Нека T_s = {t₁,t₂,…,t_n} биде множество на видови (типови) на промени кои можат да се извршат над објектите од S, така што за дадена промена {t_i,o_j} можеме да дефинираме

ƒ_impact {t_i,o_j} → {o₁,…,o_i,o_k,…}

на таков начин што некои системски одлики во S остануваат непроменети ако промената е конечно извршена и објектите над кои е извршено влијанието {o₁,…,o_i, o_k,…} се, исто така, усогласено изменети и каде што:

• објектите во O_s се поврзани преку јавни зависности (множество на подредени парови);
• T_s зависи од погледот (view) на софтверскиот систем;
• ƒ_impact е функција на импактна анализа; и
• {o₁,…,o_i,o_k,…} се „директни жртви“ на промената, т.е. тие објекти кои имаат директна врска (однос) со o_j. Способноста да се процени влијанието на промената во однос на објектите на кои би можела да влијае промената и да се изврши ширење (propagation) на промената, зависи од следниве фактори:

1. Погледот на софтверскиот систем;
2. Видови (типови) на промена;
3. Множество на објекти со кои треба да се манипулира;
4. Релации на зависност помеѓу објектите на S; и
5. ƒ_impact и неговите одлики.

Затоа, постои потреба експлицитно да се дефинираат овие фактори што се подсекции кои следат.

Погледи на софтверскиот систем

Погледот врз софтверскиот систем S_view е множество на абстракции кои даваат можни карактеристи на софтверскиот систем. Кога се прави промена, неопходно е да се дефинира „животниот циклус на промената на објектите“ и неговата дефиниција мора да биде заснована на одликите на софтверскиот систем.

Погледот врз софтверскиот систем може да се на неколку категории: поглед преку програмски јазик и структурен поглед, архиктектурски поглед, поглед преку софтверски животен циклус (waterfall, spiral и други погледи на животни циклуси) и делокружен поглед (domain view).

Секоја од овие погледи имаат предности и недостатоци. На пример, програмскиот поглед ја има предноста дека е лесно да се имплементира и во повеќето случаи овој поглед е заснован на структурата на програмскиот јазик. Неговите недостатоци се дека се фокусира само на релациите на зависност во програмскиот јазик и бара од одржувачот да создава еден вид на „ментално сознание“ за релациите меѓу дизајнот или спецификациите и програмерското ниво.

Овој систем на погледи е заснован на т.н. „приод на мешан поглед (mixed view)“.

Во овој приод, имаме четири фази на животни циклуси. Секоја фаза претставува поглед. Значи имаме: поглед на побарувања (requirement view), поглед на спецификации (specification view), поглед на дизајн (design view) и програмерски поглед. За секој поглед имаме domain view, што ги прави јавни фино структурираните зависности меѓу деловите во системот (ова е илустрирано на првата слика). Предноста на овој приод е дека можеме да го објасниме влијанието на промената однос на domain-specific view и погледот на животниот циклус. Исто така, дозволува да се специфицира влијанието на промената во однос на следниве комбинации на погледи: побарувачко-спецификациски поглед; спецификациско-дизајнерски поглед; побарувачко-програмерски поглед; побарувачко-дизајнерски поглед и спецификацско-програмерски поглед.

Модели (примероци) на промени и множество на објекти во What-If

За секој поглед, треба да се дефинираат модели (примероци) на промена кои ќе оперираат над објектите од погледот. Во некои случаи, такви промени можат да бидат тривијални, како промената на податочни типови (променливи, функции и сл.) (type change) во програмскиот поглед, спојување (merging) и бришење во дизајнерско-програмскиот поглед или модификација и елиминација во побарувачко-спецификациски поглед. Ова може да биде сложено во некои случаи, и можеби ќе бара интервенција од специјалисти и корисници на системот пред типот на промената да биде наведен.

Најосновниот објектноориентиран концепт е самиот „објект“. Објектот може да се опише како ентитет што може да се набљудува. Со ова посматрање објектот се разликува од неговата околина. Објект во конвенционален програмски јазик може да биде дефиниран како колекција од рутини, типови на податоци и/или податочни елементи. Рутините ги имплементираат методите асоцирани со објектот; типовите ги структуираат податоците што се обработуваат, а податочните елементи ја претставуваат инстанцата на објектната класа. Објектите кои се манипулираат од What-If се опишани по следнава хиерархија:

1. Објекти на побарувања: глави (chapters), секции, подсекции, итн, во документот за побарувања;
2. Објекти на спецификација: спецификациски функции и операции;
3. Објекти на дизајн: објекти кои ги кодираат дизајнерските одлуки како што се активни и пасивни објекти и операции во HOOD (Hierarchical Object Oriented Design);
4. Објекти на имплементација: модули, процедури, блокови, пакети, задачи (tasks) и променливи.

Врски на зависност помеѓу објектите

Софтвеските објекти се поврзани меѓусебно со сложени зависности и нужности (принудувања) Поради тоа, разбирањето на зависностите во системот е фундаментално за извршување на ефикасна софтверска промена. Овде, ќе ги идентификуваме следниве видови на зависности:

1. Врски на меѓуфазни зависности: овие се врски на објекти од различни погледи, и
2. Врски на внатрефазни зависности: овие врски на зависност, зависат од одредениот поглед на системот. На пример: во програмерскиоjт поглед можеме да ги имаме следниве: S_i го повикува S_j, ако и S_i и S_j се подпрограми; S_i го создава S_j. Задачи во програмскиот јазик Ada: S_i е параметар на S_j, ако S_i е параметар, а S_j е функција; S_i е деклариран во S_j, ако S_i е деклариран внатре во S_j итн.

ƒ_impact и неговите својства

Дефиницијата ƒ_impact {t_i,o_j} → {o₁,…,o_i,o_k,…} не е доволна за импактна анализа и ширење на промената. Она што всушност треба да дефинираме е:

ƒ_impact {t_i,o_j} → {o₁(o₁₁, o₁₂,…,o_1n),…, o_i(o_i1, o_i2,…,o_in), o_k(o_k1, o_k2,…,o_kn),…}

каде

{(o₁₁,o₁₂,…,o_1n),…,(o_k1k, o_k2,…,o_kn),…}

се објекти кои се индиректно засегнати од промената.

Во овој случај можеме да ги пресметаме и директните и индиректните жртви на промената. Постојат два метода на презентација за да се направи ова: површен метод и длабок метод. Генерално, површниот модел е презентација која прикажува помалку инфорамции експлицитно (ги прикажува слично како текстуален документ), па е полесна за имплементација. Но од друга страна, колку помалку експлицитно прикажува инфорамции, толку потешко е за некоја алатка да манипулира со процесот на промена на софтверот. Ако една алатка треба снабди со сестрана поддршка за сложени софтверски задачи, кои бараат длабоко сфаќање на софтверскиот артефакт, тогаш ќе мора да го претставува артефактот на таков начин, да сите релевантни инфорамции се достапни на алатката. Важна придобивка од подлабока презентација е тоа што тие дозволуваат подлабоко ниво на интеграција помеѓу софтверските алатки за анализа. Поради тоа за да се претстави како ƒ_impact извршува импактна анализа и ширење на промената (change propagation), го адаптираме следново:

1. Користење на граф за да се претстави структурата на секој поглед. Јазлите во графикот одговараат на објектите на погледот, додека линиите со стрелки одговараат на зависностите меѓу објектите. Според тоа, за целиот систем имаме мулти-граф кој се состои од графици на: поглед на побарувања, поглед на спецификации, поглед на дизајн и програмерски поглед. Презентација со граф е искористена овде, бидејќи може да се користи како моќна техника за софтверско инженерство.

1. Мулти-графот е претставен од множество на неговите едноставни графиконски компоненти и од нивните зависности.

1. Композитни релации на зависност, ограничувања и сите други информации како пред и пост услови за примената на одреден вид на промена се организирани како правила во базата на знаења на моделот.

1. Компонентите во графот и нивните зависности се организирани и како множество од факти.

1. Информациите кои се специфични за секоја поединечна софтерска компонента се сместени во база на податоци.

What-If прототипот

Прототипот What-If е заснован на две подсистеми на What-If мешани погледи. Тоа се дизајнерскиот поглед и програмерскиот поглед. Овде се користи дизајнерскиот метод HOOD за дизајнерскиот поглед, а програмскиот јазик Ada е избран за погледот на кодирање. Изборот е заснован на фактот што Ada како програмски јазик поседува некои конструкции кои се богати со семантика и можат да бидат дефинирани во два чекора; прво декларацијата, а потоа телото. Овие конструкции се подпрограми, задачи, генерички единици, приватни типови, незавршени типови и потпорни константи (deferred constants). HOOD како метод на дизајнирање е заснован на концептот на објекти и историјата на овој метод е поврзан со Ada. Транслацијата од HOOD во Ada е можна преку ODS (Object Description Skeleton).

Архитектурата на прототипот

Прототипот се состои од три главни подсистеми: подсистемот на (екстракција), базата на знаење и абстракторот. Подсистемот на екстракција ги прима како влезен параметар HOOD ODS и Ada кодот. А како излез ги продуцира директните релации кои подоцна се претвораат во Prolog факти и правила (начела, закони). Исто така, продуцира табели кои ги покажуваат одликите на секој објект во системот. Табелите се сместуваат во база на податоци, а фактите и правилата се сместуваат (респецтивелѕ) во базата за факти и базата за правила. Абстракторот ги прима прашањата за пребарување (queries), го извршува процесот на апстракција на релациите и продуцира одговори до корисникот.