3. Общие принципы моделирования жизненного цикла программных средств…

Общие принципы моделирования ЖЦ ПС. Модель ЖЦ ПС – совокупность определенным образом взаимосвязанных процессов послед-ого изменения его сост-я, начиная от возникновения потребности в этом средстве, через формир-ние исходных требований к нему, его проектирование и т.д., заканчивая изъятием его из экспл-ции и послед-ей утилизацией. В ГОСТ Р ИСО/МЭК 12207 подробно описаны только структура и содержание процессов ЖЦ ПС, но не сказано о том, как эти пр-сы взаимноувязывать м/ду собой во времени и простр-ве в ходе конкр проекта, т.е. не приведены модели ЖЦ ПС. На настоящий момент никаких международных ст-тов или соглашений на использование м-лей ЖЦ ПС не сущ-т Осн фазами (этапами) разр-ки ПС будут след-щие: 1.анализ требований и составление спецификаций (ТЗ); 2. Проектирование (2.1.предварительное, 2.2.детальное); 3. программирование; 4. интеграция (сборка системы) и тестирование (4.1. тестир отдел-х модулей; 4.2. интеграция и тестир ПС; 4.3. системное тестир); 5. инсталляция и аттестационное тестирование.

М одель «сделал-исправил». Это сам прост и распростр модель ЖЦ ПС. Иногда не считают за модель. Т.о., обычно, минуя фазы подробного анализа требований польз-ля, составления формальных и докум-ных спецификаций, а также проектирования, сразу приступают к прогр-ю и создают 1 версию ПС, кот затем модифицир, пока она не удовлетворит польз-ля. Эта схема хорошо раб-ет при изгот-нии оч маленьк и простых ПС (Лабы).

К лассическая каскадная или «водопадная» модель. создана по образу и подоб методик, наработанных в др инж-х областях, где сущ-т стандартная практика поэтапного создания продукта, начиная с составления ТЗ и зак поставкой заказчику. Модель реализует принцип однократного вып-ния кажд вида деят-сти в виде заранее ограниченных и однозначно упорядоченных во времени стадий, этапов или фаз проекта, осущ-мых как бы в их естественных границах.

При такой модели ЖЦ ПС работы и задачи,например, процесса разр-ки вып-ся четко послед-но: каких-л перекрытий, параллелизма или возвратов назад не допуск-ся. Это оч жесткое огранич-е, кот делает такую м-ль практич нереализуемой, т.к. недопустимы никакие ошибки на уже законченных этапах. Нужноя идеальное кач-во спец-ций, разраб-мых на самом первом этапе при явном дефиците информации, что также практически невозможно осуществить.

Модифицированная каскадная или модель «водоворота». Анализ требований, проектирование, программирование, тестирование. Данная модель допускает параллельное выполнение отдел работ (их перекрытие), а также возвраты назад, в т.ч. и на неск фаз назад, в случ обнаружения ошибок. Т.о., в данных м-лях есть место проверкам и аттестации. Процессы сопровождения и экспл-ции обычно реализуют после процесса разр-ки. Процессы же заказа, поставки, а также вспом-ые и организац-ые процессы выполняют параллельно с процессом разр-ки. Многочисленные и тщательные проверки, а также документир-сть кажд шага пр-ния позволяют достичь высоких показателей кач-ва и надеж-сти.

Недостатки проявляются особенно ярко при разработке ПС в условиях неопределенности исходных требований, что часто имеет место при проектировании информ. сис-м.

П рототипирование. Решает многие проблемы при неопр-сти исх тр-ний. Снач разраб-ся некот сильно упрощенный прототип с-мы, кот затем тест-ся польз-лем и согласно его пожеланиям циклически усоверш-ся и услож-ся, пока не стан-ся очевидными все осн тр-ния к данному ПС. После чего сост-ся подробн спец-ция на реальную с-му, и ее пр-ние ведется послед-но, например, в соотв с каскадной м-лью ЖЦ. Технически реализ-ть идею протот-я можно только, исп-я языки оч высок ур-ня или спец CASE-ср-ва, т.к. токо с их пом м быстро и отн-но дешево построить необходимое кол-во прототипов с-мы. Само ПС затем м б запрограммировано с пом совсем др ср-в и языков. 2 осн метода прототип-я и соотв м-ли ЖЦ ПС: инкрементную (м-ль запланир-го усоверш-ния продукта) и эволюционную м-ль.

• И нкрементная модель ЖЦ, нач-ся с выдачи некот набора требований и реализует разр-ку послед-сти прототипов, все более приближ-ся к итоговой сис-ме. 1й прототип реализует наиб понятную часть требований, в последующую констр-цию доб-ют доп требования и так далее до тех пор, пока не будет закончено создание системы. Для кажд прототипа вып-ют необх процессы, работы и задачи.

При так подходе к созданию кажд прототипа работы и задачи процесса разр-ки вып-ют послед-но или частично параллельно с перекрытием. Все эти работы и задачи вып-ся неоднократно в одинаковой послед-сти для всех прототипов, а при частично одновременном создании послед-ных прототипов они могут быть выполнены параллельно для ряда прототипов.

• П ри эволюционной модели ЖЦ с-ма также разр-ся в виде послед-сти прототипов, но, в отлич от инкрементной м-ли, требования не м б полностью осознаны и сформул-ны предварит-но, поэт они устан-ся частично и в дальнейшем уточн-ся в кажд последующей конструкции. Начинают такое прототипирование, как правило, с наиболее сложных и непонятных требований, чтобы затем информацию, получ в ходе реализации более ранних версий, исп-вать для уточнения и расширения требований, кот будут использованы в послед версиях.

Процессы экспл-ции и сопр-ния для всех типов моделей, исп-щих прототипир-е, обычно реализ-ся после оконч пороцесса разр-ки иногда║ для разных версий (прототипов). Процессы же заказа и поставки, а также вспом и организац пр-сы чаще всего вып-ют ║ с пр-сом разр-ки.

В целом проекты, исп-щие прототип-е, как правило, заверш-ся на 40% раньше аналогичных проектов с каскадными моделями ЖЦ, а получающийся при этом код оказ-ся на 45% более коротким. Однако, такой код обычно оказ-ся более запутанным и сложным для сопровождения, а докум-ция на ПС не столь полной и качественной.

П ри разработке сложных компьютерных систем иногда используют, так называемую V-модель, которая, в общем, является разновидностью каскадной модели ЖЦ ПС. 1. Системн требования. 2. Требования к прогр средствам. 3. Предварит проектирование. 4. Детальное проектирование. 5. Кодирование. 6. Тестир-е модулей. 7. Тестир-е компонентов. 8. Интеграция. 9. Аттестационное тестир-е. 10. Интеграция системы.

4. Методы проектирования программ. Классические методы восходящей и нисходящей разработки. Конструктивный и архитектурный подходы к разработке программ. Методы конструктивной и целенаправленной конструктивной реализации.

В кач-е модульной структуры исп-ют древовидную структуру, вкл-я деревья со сросшимися ветвями. Узлы такого графа дерева – программ-е модули, а направление дуги показывает статическую подчиненность мод-й, каждая дуга показывает что в тексте м-ля из кот-о она исходит имеется ссылка в кот-й она входит. Т.о. каждый м-ль может обращаться к подчиненному ему модулю. Кроме модульной структуры проги д/б также совокупность спецификаций на все модули. Специф-я на каждый модуль д содержать: 1. синтаксическую спецификацию его входов, на основании которой можно построить синтаксически правильное обращение к любому входу этого модуля. 2. функц-ю специф-ю м-ля, т.е. описание семантики фун-й выпол-х этим м-лем по каждому из его входов.

В процессе разр-ки проги ее модульная структура может формир-ься различ-ми сп-бами с определением разл порядка программ-я и отладки модулей указанной структуры.

В связи с этим говорят о различных методах разработки модульной структуры проги. Обычно выделяют два класса метода разработки структуры прог: 1. м-д восходящей разработки. 2. м-д нисходящей разработки. Существует несколько производных от них методов.

Метод восходящей разработки. Сначала строится модульная стр-ра в виде дерева, возможно со сросшимися ветвями. Затем поочередно программ-ся модули проги, начиная с самого нижнего уровня (с листьев). Порядок написания модулей таков, что для каждого вновь программ-го м-ля уже д/б запрограм-ны все модули, к кот-м он обращ-ся. После того как все мо-ли написаны произв-ся их поочередное тестир-е и отладка точно в таком же пор-ке как велось программ-е.

Такой пор-к кажется естеств-м. Ведь кажд м-ль при его программ-и выражается через уже запрограм-е непосредственно подчиненные ему м-ли. А при тестир-и испо-ет уже отлаженные до этого м-ли. Но соврем технология такую разр-ку не реком-ет. Во-1, на программ-е какого-либо м-ля совсем не треб-ся тексты использ-ых им м-лей, а дост-но всего лишь спецификации обращения к ним. Для тестир-я разраб-емого м-ля полезно вызываемые им модули заменить имитаторами (заглушками). Во-2, каж прога в какой-то степени подч-ся некот-м внутр-м для нее, но глобаль для ее м-лей соображениям (принципам реализации, структурам данных и т.д.) Это опр-ет ее концептуальную целостность и как пр они формируются в пр-се ее разр-ки. В-3, при восх-м тестир-и для каждого м-ля кроме головного приходиться создавать ведущую прогу. Такая прога д подготовить для тест-го м-ля необходимое состояние инф-ной среды и произвести его вызов. Разр-ка ведущих программ приводит к гораздо большему объему отладочного программ-ния, чем разработка заглушек.

Метод нисходящей разработки. Сначала стр-ся модуль-я стр-ра в виде дерева, возможно со сросш-ся ветвями, а потом програм-ся м-ли и проги , начиная с м-ля верх-о ур-ня, переходя к программ-ю нижнего уровня только если к нему есть обращение модуля верхнего уровня.

Когда м-ли написаны произв-ся их пооч-е тестир-е и отладка и в том же п-ке как они и писались. 1 тестир-ся голов-й модуль. Все вызыв-ые им м-ли заменяются имит-ми – загл-ми. В 1 прибл-и имитатор пред соб простой фрагмент проги, кот сигнал-ет о факте обращ-я к имитир-му м-лю от вызываемого его м-ля и обычно их распечат-ет, возвращает вызвав-му м-лю заранее запасенный подходящий рез-т, чт тот продолжал свою работу.

После заверш тест-я и отладки голов-о или люб-о послед-го м-ля произво-ся переход к тест-ю 1 из м-лей, кот на дан-й м-нт были предст-ны имит-ми. Для этого имитатор замен-ся на настоящий м-ль, а вызываемые им др м-ли замен-ся соотв имит-ми. При эт кажд м-ль будет тест-ся в естест-ом для него сост-ии инф-й среды, кот будет созд-ся всеми вышестоящими м-лями к мом-ту обращ-я к данному тест-му м-лю.

Т.о. дост-но большой объем программ-я (отлад-го) при восх-м программ-и замен-ся программ-ем отн-но простых имит-ров заглушек. Имит-ры удобно исп-ть чт подыгрывать пр-су подбора тестов путем задания нужных рез-тов выдаваемых ими.

При нисх-щей разр-ке вся необх-я глоб-я и-ция формируется своевременно, т.е. ликвидируются неприятные случаи простоев при программ-и модулей нижн ур-ней.

Недост: необ-ть абстраг-ся от базовых возм-тей исп-го ЯП, выдум-я на верхн ур-х некот абстрак-е операции, кот-е позднее н реал-ть в виде конкр-х програм-х м-лей.

Общие недостатки классич методов восх и нисх разработки: Особен-ть м-дов – модульная структура проги была спроек-на до нач программ-я м-лей. Это требование нах в полном соотв-и с водопадной м-лью ЖЦ, т.к. разр-ка м-льной стр-ры проги и ее кодир-е произ-ся на разных этапах. Разр-ка м-льной стр-ры завершает этап конструир-я, открывает этап кодир-я. Треб-е предвар-ной разр-ки м-льной стр-ры вызывает ряд возражений: сомн-но, что до прог-я м-лей м было дост-но точно и детально разр-ть всю стр-ру. Это необяз делать, т.е. м неск модерн-ть каскадную м-ль ЖЦ и разр-ть проги так, чт мод-я стр-ра формир-сь в проц-е программ-я м-лей.На базе эт идеи классич м-ды б модер-ны и появился кон-й и арх-й подход.

Конструктивный подход к разработке программ - модиф-я нисх-й разр-ки при кот мод-я древовидн стр-ра проги форм-ся в пр-се программ-я м-лей. Изнач м-льной стр-ры нет. Разр-ка проги нач-ся с прогр-я голов-о м-ля исходя из специф-ии (ТЗ) на прогу вцелом. В пр-се прогр-я гол-го м-ля выд-ются внут-ие подз-чи в терминах кот и программ-ся гол-й м-ль. Для кажд такой подз-чи созд-ся спец-ция. В дальн-м кажд из спец-ций пред соб ТЗ на разр-ку фрагмента проги или поддерева м-ля. После выдел-я подз-чи в гол-м м-ле стр-ся обращение к этой подз-че в соотв с созданной его спец-цией. На осн получ-х спец-ций пишутся тексты м-лей 2 ур-ня и т.д. Т.о. произв-ся одновр и код-е м-лей и формир-е дерева прог.

Архитектурный подход к разработке программ.- пред собой модиф-ю восх разр-ки при кот мод-я стр-ра проги форм-ся в пр-се программ-я м-лей. При арх-м подх в кач-ве осн цели ставится не цель разр-ть конкр прогу, а повысить ур-нь исп-го ЯП. Т.е. для некот типичных прог данной предм-й обл выдел-ся типичн ф-ции самого низк ур-ня. Далее такие ф-ции специф-ся и программ-ся в виде отд программ м-лей. Т.к. пр-с выделения таких ф-ций связ с накопл-ем и обобщ-ем опыта реш-я з-ч в данной предм обл, то снач реал-ся наиб прост ф-ции, а затем постеп появ-ся м-ли с пом-ю ранее выделенных ф-ций. Такой набор м-лей низш ур-ней созд-ся в расчете на то, что при разр-ке той или ин проги в рамках данной предм обл эти м-ли м оказ-ся пригодным для исп-я. Это позв сократить трудозатраты на разр-ку конкр-ой проги и повысить кач-во прогр модульных стр-р нижнего ур-ня. широко исп-ся в борьбе с дублир-м в програм-и.