Л.Е. Карпов - Системы программирования (1114903), страница 2
Текст из файла (страница 2)
С этим мо жно былобы примириться, если бы разрывы между разработкой и сопровождением не приводилик разрыву между разработкой и использованием:Фаза использованияФаза разработкиФаза сопровождения(продолжающейся разработки)6Приведенные схемы соответствуют, так называемым, одноразовым разработкам.Гораздо интереснее и продуктивнее такие отступления от классической моделижизненного цикла, в которых фаза сопровождения становится непосредственнымпродолжением разработки, при этом разработчик сам сопровождает свои программы:Фаза использованияФаза сопровожденияФаза разработки(продолжающейся разработки)Процессы разработки и сопровождения включают в себя этапы:•••••••••Анализ (определение) требованийПроектированиеНаписание текста программ (программирование, “кодирование”)Компоновка или интеграция программного комплексаВерификация, тестирование и отладкаДокументированиеВнедрениеТиражированиеСопровождение, повторяющее все предыдущие этапыЭтап постановки задачи и определения и анализа требований во многом неформализован, но он влияет на всю разработку и качество конечного продукта.
На этомэтапе необходимо выяснить потребности конечного пользователя. Часто для этогоприходится создавать общий с заказчиком словарь терминов – систему понятий,посредством которой можно будет общаться с пользователями. Выработанная системапонятий должна использоваться для описания объектов автоматизации, их сходства сдругими объектами и их своеобразия, то есть отличий от объектов, остающихся зарамками осуществляемого проекта разработки программного обеспечения.На первом этапе создаются материалы различных видов: от простого текста дочастично формализованных описаний требований.
Чтобы добиться хотя бы частичнойформализации, разрабатываются специальные программные средства, в частности,языки описания требований. Эти языки могут быть разными:•••Таблицы решений, отображающие связь входных данных с выходными.Фактически таблицы содержат условия, налагаемые на возможные входныеданные, и эффекты, которые эти данные оказывают на поведение программыи выходные данные. Для их построения входные данные разбиваются нагруппы, представители которых обрабатываются программным продуктомпрактически одинаково.Функциональные диаграммы, представляющие собой графы с узлами,соответствующими входным данным и накладываемым на них (или ихсочетания) условиями и/или ограничениями.
В диаграммах такжеописывается эффект обработки соответствующих данных.Языки спецификаций, применяемые для формулирования требований (языкCLU – один из первых таких языков, к этим же языкам относится языкдиаграмм взаимодействия MSC, язык SDL и другие).7Результатом первого этапа являются сформулированные требования, то естьвнешняя спецификация, описание системы с точки зрения пользователя.Проектирование есть сложный процесс проектирования всей системы в целом.Часто этот этап разбивается на два подэтапа: проектирование структуры системы(проектирование “в большом”), и проектирование совокупности взаимосвязанныхподсистем (проектирование “в малом”).
На этапе проектирования осуществляетсяпроцесс, который называют управлением сложностью.Как и все сложные системы, сложные программы имеют иерархическуюструктуру, а уровни их иерархии отражают различные уровни абстракции, следующиедруг из друга, но не тождественные др гу другу.
Эти ур вони со товетствуютвзаимозависимым подсистемам, которые сами могут иметь сложную, иерархическуюструктуру. На этапе проектирования широко применяется метод “разделяй и властвуй”.При проектировании сложных программных комплексов их обычно стараютсяразложить на некоторое число относительно небольших подсистем, каждую из которыхможно отладить независимо от других (“автономно”). Основная сложностьпроектирования – определить основания для разделения общей системы насоставляющие ее подсистемы. Выбор подсистем часто зависит от разработчика исущественно влияет как на сложность процесса проектирования, так и на конечноекачество программного продукта.
Такое разложение называется декомпозициейпрограммы.Декомпозицию одной и той же системы можно проводить, основываясь наразных ее свойствах. Алгоритмическая декомпозиция разделяет программную системупо алгоритмам, в ней используемым. Такой метод декомпозиции ассоциируется соструктурным программированием и методом проектирования “сверху-вниз”. Каждыйотдельный полученный в результате модуль системы выполняет какой-либо одинэтапов работы общего системного процесса.
Данные в таком подходе играютпассивную роль.Объектно-ориентированная декомпозиция связана с выделением отдельныхобъектов, которые способны воспринимать направляемые им сообщения и отвечатьвыполнением тех или иных ответных действий. Алгоритмы в такой модели теряютсвою независимость, они превращаются в операции над выделенными объектами.Активную роль в таком подходе приобретают данные программ, то есть объекты. Этиобъекты обладают не только информационной составляющей (значениями), но идействиями.Если алгоритмическая декомпозиция концентрируется на последовательностипроисходящих событий, то декомпозиция по объектам фиксируется на этих объектах ина событиях, происходящих в системе и вызывающих действия. Сам процесс,выполняемый в программе, описывается в терминах посылки сообщений от объектадругим объектам.
В последнее время объектно-ориентированный подходрассматривается, как более предпочтительный. Объектно-ориентированные системыболее открыты и легче поддаются модернизации. На основе объектно-ориентированнойдекомпозиции сложные программные системы удается строить путем эволюционногоразвития небольших подсистем.Результатом работы второго этапа являются•схема иерархиидекомпозиции),подсистем(или8модулей,дляалгоритмической•••функциональность и интерфейсы каждой подсистемы (первые два результатавозникают от проектирования “в большом”), то есть их внешниеспецификации,внутреннее представление (структура) данных для каждого отдельногомодуля программы,алгоритмы, обрабатывающие данные (последние два результата – отпроектирования “в малом”) в каждом отдельном модуле программы.Написание текста чаще называется программированием или кодированием,этот этап заканчивается, когда в наличии оказывается текст программы на некоторомязыке программирования.
Для написания текста программ чаще всего выбирается язык,соответствующий методам, выбиравшимся при анализе и формировании требований кпрограммному продукту и проведении декомпозиции строящейся системы. Вчастности, объектно-ориентированная декомпозиция особенно полезна припоследующем программировании на объектно-ориентированном языке.Верификацией программы называется процесс ее проверки на правильность.Существуют специальные теоретические методы верификации программ, но наиболеешироко применяются эвристические методы верификации, основанные натестировании.
Тестирование программы есть процесс обнаружения дефектов всозданных программах, а отладка программ есть выявление причин дефектов, а такжеих устранение. Во время тестирования выявляется несоответствие программыисходным требованиям и спецификациям по тестам, то есть программам с заранееизвестными ответами. Среди методов наиболее известны методы “черного” и “белого”ящиков. Отладка начинается после обнаружения дефектов. Иногда на этапе отладкиприходится устранять не только причины дефектов, но и дефекты в данных, возникшиепри работе неверных программ.Результатом тестирования и отладки является доказательство, что всевыявленные на данном комплекте тестов ошибки исправлены, а других ошибок необнаружено.Этапкомпоновкипредставляетсобойинтеграционныйпроцесскомплексирования (комбинирования), то есть связывания отдельных частей программыв одну большую систему программного обеспечения. Обычно после компоновкипроводится этап комплексного тестирования программных систем, на которомпроверяется правильность взаимодействия всех автономно разработанных составныхчастей между собой.
Правильная организация процессов верификации, тестирования идокументирования имеет особое значение для последующего внедрения,тиражирования и сопровождения создаваемых программ.Внедрением называется работа по привлечению заказчика к использованиюсозданного программного продукта. На этом этапе возникает множествоорганизационныхпроблемпообучениюпользователей,тестированиюработоспособности и устойчивости программы при работе в конкретной организации иконкретной операционной среде.
Если организация заказчика представляет собойразветвленную сеть рабочих мест, проводится тиражирование продукта.Во время сопровождения программного продукта можно наблюдатьпродолжение контактов пользователей и разработчиков. Сопровождение являетсязеркальным отражением разработки и внутри себя содержит все этапы фазы разработки(от определения требований до документирования).9В идеальном случае процесс разработки может иметь вид последовательновыполняемых слабо связанных между собой этапов. Такая схема разработки называетсянисходящей, и она редко встречается на практике. Чаще встречается каскадная схема, вкоторой можно наблюдать замыкание процесса и проведение повторного анализатребований после проведения его тестирования.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
