Софтуерни технологии
Фнг. 2.1. Схема на моделиране
Изтегляне 3.19 Mb.
|
- Навигация на страницата:
- 13. СЪВРЕМЕННИ ТЕХНИКИ ЗА ПРОГРАМИРАНЕ И РАЗРАБОТВАНЕ НА СОФТУЕР
- 13.1. Програмиране, осигуряващо надеждно функциониране на програмните системи
- 13.3. Повторно използване в софтуерното производство ("Re-use")
- 13.4. Разработване на софтуер с участието на потребителя
Фнг. 2.1. Схема на моделиране Изследването на адекватността между модела и реалната система определя приложността на модела. Изследването на вътрешните характеристики на мо- дела и способността му да дава адекватна информация определят валидността на модела. Що се отнася до потребителя, той оценява модела от гледна точка на неговата полезност. 2.1.3. Какви могат ga бъдат следствията от един успешен модел Ако изграждането на модела е успешно, това има немалко положителни следствия:
19  13. СЪВРЕМЕННИ ТЕХНИКИ ЗА ПРОГРАМИРАНЕ
И РАЗРАБОТВАНЕ НА СОФТУЕР В зависимост от приложната област и конкретните изисквания към създа- вания програмен продукт могат да се избират различни програмистки техники или подходи на разработване. Ще разгледаме някои от тях. 13.1. Програмиране, осигуряващо надеждно функциониране на програмните системи Надеждността на функциониране е динамична характеристика, която е свързана с честотата на сривове в системата. Под срив на системата се разбира ситуация по време на работа на соф- туера, при която той започва да се държи по необичаен и неочакван начин. Дефект е наличие в програмата на една или няколко грешки, водещи до срив при изпълнение на програмата с определени входни данни и попадане в определен програмен сегмент. 13.1.1. Разработване на софтуер с минимизиране на дефектите в него Създаването на програмни системи без грешки (fault-free software) e свър- зано с големи разходи и може да се приложи само за системи, функциониране- то на които е свързано с животоопасни или изключително скъпо струващи дей- ности (управление на вредни производства и атомни електроцентрали, косми- чески изследвания и др.). Затова обичайната практика е след тестване до опре- делено ниво системата да се разпространява и да се отстраняват грешките, отк- ривани по време на използването и. Избягване на дефекти (fault avoidance) e подход на разработване, целта на който е да се намали възможността за внасяне на грешки в програмите. Избягването на дефекти и разработването на софтуер с минимален брой грешки се основава на следните принципи: а) създаване на прецизни, по възможност формални спецификации; 162 б) използване на проектиране, което позволява капсулация (скриване) на информацията; в) използване на механизмите за осигуряване на качеството със система- тична верификация и валидация на системата (вж. глава 8.) в определени конт- ролни точки; г) планиране и осъществяване на тестването на системата така, че да се откриват и грешките, останали след верифицирането и валидирането. Обобщавайки натрупания практически опит, в [1] са формулирани следни- те препоръки:
13.1.2. Разработване на софтуер с приемливо ниво на грешни Софтуер с приемливо ниво на дефекти (fault tolerance) e софтуер, кой- то е проектиран и програмиран така, че продължава работата си и при наличие на дефекти. Софтуерните системи, следвайки този подход на разработване, трябва да реализират следните основни функции: а) прогнозиране или откриване на дефекти, по възможност преди да са довели до срив на системата; б) оценка на пораженията след срив на системата (т. е. определяне кои нейни части са засегнати); в) възстановяване след срив. Това може да се постигне чрез отстраняване на повредите или чрез връщане към някое предишно устойчиво състояние на системата. г) локализиране и отстраняване на дефектите, предизвикали срива на системата. Осигуряването на надеждно функциониране може да се осъществи чрез прин-
163
При софтуерните системи този принцип се реализира чрез N-версийно прог-
рамиране. Избира се критична за функционирането на системата компонента. Тя се възлага за проектиране и програмиране на различни групи и всички версии се включват в системата. Когато е необходимо, те се извикват (паралелно или после- дователно) и изпълнението продължава с най-често срещания резултат. Понякога в програмните системи се вграждат т. нар. възстановяващи бло- кове — програмни единици, проверяващи за срив на системата и включващи алтернативен код, позволяващ повторение на процедурата, ако има съмнение за наличие на дефект. Използването им може да се илюстрира със следния при- мер. За решаването на един и същ проблем са създадени три компоненти, реа- лизиращи три различни алгоритъма. Разработена е и тестваща компонента, ко- ято проверява правилността на получаваните резултати. За определени входни данни се изпълнява компонентата, реализираща алгоритъм 1, и резултатите от изпълнението се анализират от тестващата компонента. Ако те са правилни, изпълнението продължава. Ако има съмнения за грешки, същите входни данни се подават на компонентата, реализираща алгоритъм 2, и резултатите отново се насочват към тестващия модул. При неуспех аналогична процедура се повтаря с третата компонента. При неуспех и след нейното изпълнение се включва спе- циална програмна част. В някои софтуерни системи се създават отделни компоненти за обра- ботване на изключенията (exception handlers). Изключение е всяко необи- чайно събитие, което е откриваемо хардуерно или софтуерно и което може да изисква специална обработка. Така могат да се управляват реакциите на систе- мата при настъпване на аварийни ситуации. Най-простата реакция е извеждане на съобщение и преустановяване на изпълнението. Но са възможни и по-слож- ни последователности от действия. Например при системите за управление в реално време, като се установи, че времето за отговор на системата ще бъде по- голямо от допустимото, компонентата за обработка на изключения трябва да включва автоматично съответните защитни и аварийни механизми. В [2] са разгледани някои вградени в езиците за програмиране възможнос- ти за реализация на обработване на изключенията. 13.1.3. Защитно програмиране Този подход на разработване се основава на предположението, че в прог- рамите има неоткрити грешки. Затова още при програмирането се вграждат механизми за откриване на грешката, оценка на засегнатите програмни части и отстраняване на последствията. Една възможна техника е определяне на кри- тични за състоянието на системата променливи и текущо проверяване на стой- ностите им чрез твърдения, описващи условия или пресмятане на контролни суми.
Например в СУБД този принцип се реализира, като промените в базите от данни се съхраняват междинно в някакъв буфер и се внасят в съответната база само след успешно завършване на поредната транзакция. Друг пример на защитно програмиране е използването на контролни точ- ки. Този принцип се прилага най-често при сложни изчислителни задачи. Из- численията се извършват поетапно. Всеки етап завършва с контролна точка, в 164
която се запомнят междинните резултати. Във всяка контролна точка изпълне- нието може да бъде прекъснато и да продължи след време от достигнатото в момента състояние. При срив на системата се осъществява връщане към пос- ледното запомнено състояние. 13.2. Разработване с прототипиране Смисълът на понятието прототип е първи от даден тип". Създаването на прототипи е обичайна практика в материалното производство, когато се разра- ботва опитен образец и след успешни приемни изпитания започва серийното му производство. Прототипният модел на жизнения цикъл е представен в частта 2.3.7. на учебника и показва последователността на извършваните дейности. Тук ще раз- гледаме начина на осъществяване на прототипирането с отчитане на особенос- тите на софтуерното производство, като се придържаме към приетата в [3] тер- минология. В началото на софтуерен проект потребителят понякога не може да фор- мулира какво точно иска и от какво се нуждае. Разработчиците невинаги могат да преценят дали изискванията са изчерпателни, реалистични и дали някои проб- леми имат приемливо решение. Създаването на прототип зависи от много фактори, например от прилож- ната област, от сложността на приложението, от характеристиките на потреби- телите и на проекта. Прототипирането е съвкупност от дейности, осигуряващи ранно демон- стриране на някои свойства на софтуера, който трябва да бъде създаден. Основна цел на прототипирането е да се определят изискванията към раз- работваната софтуерна система. Прототипирането се осъществява в четири последователни стъпки: а) проектиране на прототипа, т. е. избор на функциите и свойствата,
Прототипирането може да бъде вертикално, като се реализират само ня- кои функции, но в техния предполагаем окончателен вид. При хоризонтално- то прототипиране всички функции присъстват, но не са са реализирани с пъл- ните си възможности. б) създаване на прототипа Обикновено усилията за създаване на прототип са по-малки от тези за съз- даване на целевата система. Това се постига с избора на функции и на подходя- щи техники и средства за разработване. Някои характеристики на качеството могат да се игнорират, като в прототипа се изберат само свойства, важни за конкретното приложение — например време на отговор в системи за управле- ние на процеси в реално време, надеждно функциониране и защита на данните в банкови системи и др. в) оценяване на прототипа Тази стъпка е важна, защото осигурява обратна връзка. Оценяването се
165
боти със системата, или от групи потребители с регламентирани комуникации
между тях. г) използване Прототипът или се отхвърля, или се използва като база за разработването
Одобреният прототип може да се използва като учебна среда за евентуал- ни потребители на реалната система. Демонстрираното от прототипа и одобре- но при оценяването трябва задължително да се възпроизведе в крайния про- дукт.
Обикновено прототипът не се вгражда директно в целевата система поради следните причини:
В зависимост от поставените цели разграничаваме три вида прототипиране. Целта на изследователското прототипиране е да се изяснят изисквания- та към целевата система чрез представяне на няколко алтернативни решения. То е подходящо за ранните фази от жизнения цикъл — изследване и анализ на осъществимостта. Препоръчва се само ако има техники и инструментални сред- ства, позволяващи бързо създаване на прототипа, и то с минимални усилия. Целта на експерименталното прототипиране е да провери дали избрано решение на даден проблем е подходящо. Експерименталният прототип се разг- лежда като междинна стъпка между специфицирането и реализацията. Еволюционното прототипиране е с най-големи възможности, но е най- отдалечено от оригиналното разбиране за прототипиране. Основната му идея е, че разработването се осъществява в динамична среда и непрекъснато проме- нящи се изисквания. Затова крайният продукт се създава като последовател- ност от инкременти, всеки от които е прототип за следващия. Инкременталното (постепенно разрастващо се) разработване се осъществява чрез многократно повтаряне на цикъла проектиране — реализация — оценяване. За да бъде прототипирането ефективно, прототипът трябва да се разработ- ва бързо, за да може потребителят да оцени резултатите и да препоръча измене- ния. Най-често използваните методи и средства могат да се разделят в три гру- пи: — езици от четвърто поколение Езиците от четвърто поколение са например езици на заявките и генерира-
— използване на готови софтуерни компоненти В този случай някои от частите на прототипа могат да се изберат от същес-
166
— среди за формално специфициране и прототипиране Съществуват среди [4], които дават възможност след определяне на изиск- ванията, да се създават формални спецификации за системата и чрез инстру- ментално средство те да се превръщат в изпълним код. Потребителят може да използва така създадения прототип за подобряване на формалните изисквания и чрез повтаряне на гореописаната последователност прототипът да еволюира до исканата целева система. Основно предимство на прототипирането е, че позволява изясняване и уточ- няване на функционалните и нефункционални изисквания към целевата систе- ма достатъчно рано. Недостатък е, че прототипирането изисква допълнително време и средства. В някои случаи може да се окаже, че икономически е по- изгодно да се променя завършената система, вместо да се създават прототипи за нея. 13.3. Повторно използване в софтуерното производство ("Re-use") Подходът за повторно използване (ПИ) е съвкупност от планирани и сис- тематични дейности, насочени към максимално използване на съществуващи софтуерни елементи в процеса на създаване на нов софтуер. Този подход е заимстван от материалното производство и се оказва приемли- во решение за намаляване на сроковете и стойността на софтуерните разработки. Софтуерните елементи, които се използват повторно, могат да се класифи- цират по различни критерии. а) класификация по същността им:
— процедури или умения, свързани с процесите на създаване на софтуер. В тази група е know-how информация, която може да бъде под формата на наблюдения, препоръки, експертно знание и др. б) класификация по обхват В зависимост от формата и докъде се простира повторното използване, то
При вертикално повторно използване в избрана приложна област се съз- дават основни модели, които се прилагат във всички разработвани за тази об- ласт софтуерни системи. 167
При хоризонталното повторно използване се създават универсални ком-
поненти, които могат да се вграждат в програмни системи за различни прилож- ни области — например средства за управление на бази от данни, за разпреде- лени среди, за изграждане на графичен потребителски интерфейс и др. в) класификация по начина на осъществяване
г) класификация по използвана техника: — сглобяващо ПИ. Съществуващи софтуерни компоненти се вграждат ка- то основни блокове в софтуерните системи. — генериращо ПИ. Използват се идеи или концепции само на специфика- ционно ниво, след което чрез специално разработени генератори на програми автоматично се създават съответните програмни части. д) класификация по начина на използване: — без промяна. Съществуващи софтуерни елементи се прилагат без изме-
— с модифициране. В този случай се изисква допълнително специфици- ране и реализация на измененията и тестване, за да се провери коректността на получения вариант. е) класификация по вида на използвания софтуерен продукт. Могат да
Ще се спрем накратко на проблемите, свързани с осъществяване на подхо- да за повторно използване в конкретна софтуерна организация. Създаването на софтуер в една и съща приложна област или в една и съща среда дава възможност за натрупване на знания и опит, които могат да се използват и в следващи проекти. Преди всичко необходимостта от въвеждане на подхода трябва да бъде осъзната от ръководството на фирмата, което да планира, финансира и управлява конкретна програма. Мотивите за ПИ могат да бъдат подобряване на качеството на създавания софтуер, доколкото се използват елементи с проверени вече свойства, и по-бързо излизане на пазара с нови продукти, тъй като се намаля- ва времето за разработка. Препоръчва се следната постъпкова процедура:
Например след решение да се приложи повторно използване в Nec Software Engineering Lab e била съставена библиотека от 32 групи програми, реализира- щи 130 алгоритъма с универсално предназначение. 168
Друга софтуерна организация анализира 5 000 програми на Кобол, разра- ботени в нея, и ги класифицира в три групи: редактиращи, обработващи и със- тавящи справки. След целенасочено повторно използване на съществуващи прог- рамни фрагменти са постигнати 50% увеличение на производителността на прог- рамисткия труд, като повторно използваните елементи са съставлявали 60% от новоразработвания софтуер [5]. Съществени за успеха на подхода са техниките за съхраняване и извли- чане на компонентите. За да се опише какво се търси, се използват някои класификационни схеми, познати от библиотечните системи. Механизмите за търсене могат да се основават на ключови думи, на текстови описания на ес- тествен език, фасетна техника чрез съставяне на описания от различни гледни точки и т. н. Препоръчва се сформиране на специална група от високо квалифицирани специалисти, която да осъществява подхода за ПИ в софтуерната организация. Основна дейност на групата е разработване и съпровождане на компоненти за ПИ. Проектирането и създаването на такива компоненти изисква от 5 до 10 пъти повече усилия, отколкото за обикновените компоненти. От програмистка гледна точка трябва да се вземат предвид следните особености: а) програмните компоненти трябва да се проектират и програмират така, че да са лесно настройваеми и да решават клас сходни задачи; б) да се обмисли и реализира систематично процесът на „клониране", т. е. копиране на избран програмен фрагмент на съответно място в новата програм- на система; в) да се регламентира механизъм за съставяне на имена на променливи за предотвратяването на програмни грешки от дублиране на използваните имена; г) програмните компоненти да са преносими, т. е. да могат да работят в различни операционни и хардуерни среди. Формулирани са някои принципи, следването на които би осигурило висока преносимост на разработвания соф- туер. Основен принцип е всички зависещи от средата програмни части да се оформят като самостоятелни модули. При това трябва да се отчитат различната дължина на машинната дума, различното представяне на числовата и символна информация, различните съвкупности от системни прекъсвания и др. Същата група от специалисти поддържа и библиотеката за ПИ — контро- лира съдържанието и качеството на съхраняваната информация, създава опи- сания за нови елементи, изтрива неизползвани елементи, консултира потреби- телите, натрупва статистика за използването й и др. В началото на всеки нов проект се изследва възможността да се използват някои компоненти от библиотеката със или без допълнително модифициране. Прилагането на подхода за повторно използване е все още ограничено поради следните причини:
169  В [5] са анализирани резултатите от прилагане на ПИ в редица индустри-
ални софтуерни организации. Основни тенденции в изследванията са:
елементи за ПИ; — създаване на модели за процеса на ПИ и на съответни инструментални средства, поддържащи разработването за и с повторно използване. 13.4. Разработване на софтуер с участието на потребителя Този подход започва да се използва в началото на 90-те години и е вклю- чен в списъка на единадесетте най-перспективни решения на софтуерната кри- за, съставен от Йордън. Въпреки сравнително краткия период на реалното му използване вече има публикации за положителни резултати от прилагането му [6].
Ще представим накратко същността и особеностите на реализацията му. В зависимост от инициализацията си софтуерните проекти могат да се разделят на две групи. Автономни са проектите без конкретен възложител. Обикновено до идея- та за създаването им се достига след маркетингово проучване на състоянието и тенденциите на софтуерния пазар. Тези проекти се самофинансират от фирми- те разработчици, като функционалните им възможности и изискванията, които трябва да удовлетворяват, се определят чрез изследване на съществуващи ана- лози (действащи или описани в литературата) и обобщаване мнението на по- тенциалните потребители. Поръчани (възложени) са проектите с конкретен възложител, който фи- нансира разработката и след завършването й става неин собственик. Класичес- ките подходи на разработване в този случай предвиждат участие на възложите- ля в началните фази (изследване, анализ на осъществяване) до дефиниране на изискванията и отново чак след окончателното му завършване — за оценка и приемане на готовия програмен продукт. Основна идея на подхода на разработване с участието на потребителя е да се повиши активността и съответно отговорността на потребителя за качество- то на програмния продукт, като той се включи активно и в някои междинни фази. Ще дадем следната дефиниция: Разработване с участието на потребителя е съвкупност от методи, техники и целенасочени действия, осигуряващи активното участие на потребителя в проектирането и създаването на софтуерната система, която той ще използва. Под потребител се разбира лице или лица, които ще използват софтуерна- та система за решаване на проблеми в ежедневната си работа. Идеята за разра- ботване може да бъде на мениджъра или на друг представител в управленската йерархия, но партньор в обсъжданията и съвместната работа трябва да бъде непосредствен потребител. Каталог: fmi -> fmi-ftp-upload-folder -> 4%20Semestur%202005 -> Predmeti -> AMP AMP -> Спецификация на софтуерен проект fmi-ftp-upload-folder -> Oracle e-business Suite Модул Financials, подмодул Fixed Assets fmi-ftp-upload-folder -> Бази от данни Упражнение 9 fmi-ftp-upload-folder -> Basic structures напишете pl/sql блок, който въвежда номера в таблицата messages AMP -> Спецификация на изискванията AMP -> 10. Управление на документацията Документация предназначена за разработчиците AMP -> 1. Анализ на риска Изтегляне 3.19 Mb. Сподели с приятели:
|