И. Соммервилл - Инженерия программного обеспечения (1133538), страница 16
Текст из файла (страница 16)
3. Процесс создания программного обеспечения 59 3.1.3. Формальная разработка систем Этот подход к созданию ПО имеет много черт, скодных с каскадной модслью, но по. строен на основе формальных математических преобразований системной спецификации в исполняемую программу. Процесс создания программного обеспечения в соответствии с этим подходом показан на рис. З.З. Здесь для упрощсния ие указаны обратпыс связи между этапами процесса. Рис. ЗЗ. Модгла фсфмплъной рпзрпбоожи ПО Между данным подходом и каскадной моделью существуют следующие кардинальныс отличия. 1. Здесь спецификация системных требований имеет вид дстализироынной формалыюй спецификации, записанной с помощью специальной матсиатичсской нотации. 2.
Процессы проектирования, написания программного кода и тсстнрования системных модулей заменяются процессом, в котором формальная спецификация путем последовательных форлгальных преобразований трансформируется в исполняемую программу. Этот процесс показан на рис. 3.4. Фврмэлыаю преобразования Т1 Т2 ТЗ Рис. 3.4. Туроцггг форипгаиа|х п1мобрпзоопний В процессе прсобразовапия форм иьпос математическое прсдставлсцис системы последовательно и математически корректно трансформируется в программный код, постепенно все более детализированный. Эти прсобрззования вьпюлняютсл до тех пор, пока все позиции формальной спецификации ис будут трансформированы в эквнвалсптную программу. Преобразования выполняются математически корректно — здесь нс существует проблемы проверки соответствия спецификации и программы.
Преимущество мстода формалыгых преобразований, которос заключается в точном соответствии коисчиой программы спецификации, обеспечивается том, что дгктапцил между последовательными преобразованиями значительно лгсиьию дистанции мсжлу спсцификацисй и программой. Доказательство корректности программного кода для боль. шик масштабируемых систем обычно очень длительно, а часто просто пс выполнимо. В этом отношении метод формальных преобразований, состошций иэ последовательности небольших формальных шагов, весьма привлекателен. Однако выбор длл применения соответствующих формальных преобразований сложен и псочсвидсп. 60 Часть 1.
Инженерия программного обеспечения: обзор Наиболсс известным примером метода формальных прсобразований является ккстод "чистой комнаты" (С!сапгоопк), разработанный компанисй 1ВМ [239, 310, 219, 284). Этот метод прслполагаст пошаговую разработку ПО, когда на каждом шаге применяется фор. мальпыс преобразования. Это позволяет отказаться от тестирования отдельных про.
граммных модулей, а тестирование всей системы происходит после сс сборки. Этот подход болсс палробно рассмотрен в главе 19. Кэк метод "чистой комнаты", так и другие методы формальных прсобразований основываются на В-мстодс )348). Все эти методы имеют несколько "врожденных" недостатков, а стоимость разработки ПО с помощью этих методов нс намного отличается от стоимости разработок другими методами. Методы формальных преобразований обычно примсплют для разработки систем, которые должны удовлетворять строгим трсбовапиям надежности, безотказности и безопасности, так как онн гарантируют соответствие создаш<ых систем их спецификациям.
Кроко разработки уютзанпого типа систем, методы формальных преобразований нс нашли широкого при мснспия, поскольку требуют специальных знаний и опыта использовапил. Кроме того, лля Гкклылипства систем этн мстодкя пс дают существенного выигрыша в стоимости «ши качестве по сравнению с другими методами разработки ПО. Основная причина заключается в том, что функционирование большинства систем с трудом поддается описанию методом фор. мальных специфшащий, — при создании болылинства программных систем болывая часгь усилий разработчиков уходит именно на создание спсшкфн наций. 3.1.4. Разработка ПО на основе ранее созданных компонентов В большинстве программных проектов применяется повторное использование некоторых программных модулей.
Это обычно случастся там, где разработчики проекта знают и раисе созданных программных продуктах, в составс которых есть компоненты, приблизитсльшк удовлетворяющие требованиям разрабатываемых компонентов. Этн компоненты модифицируются в соответствии с новыми требованиями и затсм включается в состав новой системы. В эволюционной модсли разработки, описанной в разделе 3.1.2. для уско.
рсння процесса создания ПО повторнос использование рамос созданных компонентов применяется достаточно часто. Нсфорккальнос решение о повторном использовании ранее созда|гпых программных компонентов обычно приниккастся независимо от общего процссса создания ПО. Вместе с тем на протяжении нескольких последних лет все более широко применяется подход к созданию ПО, основанный иккенно на повторном использовании ранее созданных про. граммпых модулей.
Этот подход основан на наличии большой бэлы существующих программных компонентов, которые можно интегрировать в создаваемую новую систему. Часто такими компонентами являются свободно продаваеккыс на рынке программные продукты, которые можно нсиолк зевать для выполнсния определенных специальных функций, таких как форматирование гскста, числовые вычисления и т.п. Общал модель процесса разработки ПО с повторным использованием ранее созданных компонентов показана на рис. 3тгб, В этом подходе начальный этап специфицирования требований и агап аттестации такие же, как и в других моделях процссса создания ПО.
Л этапы, расположснныс мсжду ними, имеют следующий смысл. 1. Лнлалз кокщонентов. Имел спецификацию требований, па этом этапе осуществляется поиск компонентов, которые могли бы удовлетворить сформулированным трсбова- 3. Процесс создания программного обеспечения б1 пням. Обычно невозможно точно сопоставить ф)ч<кции, рсализусмыс готовыми компонентами, и функции, определенные спецификацией трсбований.
2. Модификация э<у<в<ювлни<ъ На этой стадии анализируются требования с учетом информации о компонентах, полученной на предыдущем этапе. Требования модифицируются таким образом, чтобы максимально использовать возможности отобран. ных компонентов. Если изменение требований невозможно, повторно выполняется анализ компонентов для того. чтобы найти какое-либо альтернативное решение. 3.
ПР<мккшрввпнке еиевмнм. На данном этапе проскгируетсл структура системы либо модифицируется существующая структура повторно используемой системы, Проектирование должно учитывать отобранные программные компоненты и строить струк. туру в соответствии с их функциональными возможностями.
Если некоторые гатовыс программпыс компоненты нсдоступны, проскгирустся новое ПО. 4. Рпевпбоэ<кп и сборка скеюемъс Это этап непосредственного создания системы. В рамках рассматриваемого подхода сборка системы является скорее частью разработки системы, чем отдельным этапом. Ркс. 15. Рпзрлбвтка ПО е яввэю)я<ык иелааъэввлниел<)юнее еоедлкнык каяявнеиэюв Основные достоинства описываемой модели процесса разработки ПО с повторным использованием ранее созданных компонентов заключаются в том, что сокращасгся количество непосредствснно разрабатываемых компонентов и уменьшается общая стон. моста создавасмой системы. Вместе с тем прн использовании этого подхода нсизбсжпы компромиссы при опрсдслспии трсбовании; это может привести к тому, что закопчсппзл система це будст удовлетворлть вссм трсбованиям заказчика. Кроме того, при провсдснин модерниэации системы (т.е.
при создании сс новой версии) отсугствуст возможность влиять на появление новых всрсий компонентов, используемых в системе, что значительно затрудняет сам процесс модернизации. 3.2. Итерационные модели разработки ПО Описанные модели процесса создания ПО имеют свои достоинства и нсдостатки. При создании больших систем, как правило, приходится использовать различные подходы к разработке разных частей системы, т.с.
в целом к разработке системы применяются п<бр<шныс (смешанныс) модели. Поэтому вюкную роль играет возможность выполнять отдельные процессы разработки подсистем и весь процесс создания ПО итсрационио, когда в ответ на изменения трсбовапий повторно выполняются определенные этапы создания системы (чащс всего этапы просктирования и кодирования).
В этом разлслс я представлю двс гибридпыс итерационные молслн, сочстающис нс" сколько различных подходов к разработке ПО и разработанные специально для поддержки итерационного способа создания ПО. 62 'Часть 1. Инженерия программного обеснеченнгн обзор Б Модель аааагавай )кгз)квуатки, где процессы спсцифицирования требований, проектирования и написания кода разбиваются на последовательность небольших шагов, которые ведут к созданию ПО. 2. Слк/лыькая модель раз)ьабаажи, в которой весь процесс создания ПО, от начального эскиза системы до сс конечной реализации, разворачивается по спирали. Сущсствспиыьг отличием итерационных моделей является то, что здесь процесс разработки спецификации протекает параллельно с разработкой самой программной системы. Более того, в ьюдсли пошаговой разработки полную системную спецификацию можно получить только после завсршсния самого последнего шаш процесса создания ПО.
Очевидно, что такой подход входит в противоречие с моделью приобретения ПО, когда полная снстсмнал спецификация является составной частью контракта на разработку системы. Поэтому, чтобы применять итерационные модели для разработки больших систем, которые заказываются "ссрьсзными" организациями, например государственными агентствами, необходимо менять форму контракта, на что такие организации идут с болылим трудом. 3.2.1. Модель пошаговой разработки В касюдной модели созвания ПО определение требований осуществляется совместно с заказчиком до начала проектирования системы, точно также системная архитсктурадолжна быть создана по начала непосредственной реализации (колирования) системы.
Изменения в требованиях, сдсланныс на этапе написания кода, ведут к необходимости выполнения по. вторных работ по проектированию и кодированию системы. Вмсстс с тем к достоинствам каскадной модели можно отнести простоту управления процессом создания ПО (в рамках данной модели), а также наличие отдельных этапов проектирования и реализации, что при. водит к созданию вполне работоспособных систем, в которых учтены все изьгснсния в спе. цифнкации, сделанные ужс во время самого процесса разработки ПО. В отличие от кзскадной, в эволюционной модели можно отложить принятие окончательных решений о спецификации и структуре системы, однако это может привести к созданию плохо структурированной системы, которая будет также трудна в сопровождении.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
