И.А. Волкова, И.Г. Головин, Л.Е. Карпов - Системы программирования, страница 2

Чтобы добиться хотя бы частичнойформализации, разрабатываются специальные программные средства, в частности,языки описания требований. Эти языки могут быть разными:••Таблицы решений, отображающие связь входных данных с выходными.Фактически таблицы содержат условия, налагаемые на возможные входныеданные, и эффекты, которые эти данные оказывают на поведение программыи выходные данные. Для их построения входные данные разбиваются нагруппы, представители которых обрабатываются программным продуктомпрактически одинаково.Функциональные диаграммы, представляющие собой графы с узлами,соответствующими входным данным и накладываемым на них (или ихсочетания) условиями и/или ограничениями. В диаграммах такжеописывается эффект обработки соответствующих данных.7•Языки спецификаций, применяемые для формулирования требований (языкCLU – один из первых таких языков, к этим же языкам относится языкдиаграмм взаимодействия MSC, язык SDL и другие).Результатом первого этапа являются сформулированные требования, то естьвнешняя спецификация, описание системы с точки зрения пользователя.Проектирование есть сложный процесс проектирования всей системы в целом.Часто этот этап разбивается на два подэтапа: проектирование структуры системы(проектирование “в большом”), и проектирование совокупности взаимосвязанныхподсистем (проектирование “в малом”).

На этапе проектирования осуществляетсяпроцесс, который называют управлением сложностью.Как и все сложные системы, сложные программы имеют иерархическуюструктуру, а уровни их иерархии отражают различные уровни абстракции, следующиедруг из друга, но не тождественные друг другу. Эти уровни соответствуютвзаимозависимым подсистемам, которые сами могут иметь сложную, иерархическуюструктуру. На этапе проектирования широко применяется метод “разделяй и властвуй”.При проектировании сложных программных комплексов их обычно стараютсяразложить на некоторое число относительно небольших подсистем, каждую из которыхможно отладить независимо от других (“автономно”). Основная сложностьпроектирования – определить основания для разделения общей системы насоставляющие ее подсистемы.

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

Данные в таком подходе играютпассивную роль.Объектно-ориентированная декомпозиция связана с выделением отдельныхобъектов, которые способны воспринимать направляемые им сообщения и отвечатьвыполнением тех или иных ответных действий. Алгоритмы в такой модели теряютсвою независимость, они превращаются в операции над выделенными объектами.Активную роль в таком подходе приобретают данные программ, то есть объекты. Этиобъекты обладают не только информационной составляющей (значениями), но идействиями.Если алгоритмическая декомпозиция концентрируется на последовательностипроисходящих событий, то декомпозиция по объектам фиксируется на этих объектах ина событиях, происходящих в системе и вызывающих действия.

Сам процесс,выполняемый в программе, описывается в терминах посылки сообщений от объектадругим объектам. В последнее время объектно-ориентированный подходрассматривается, как более предпочтительный. Объектно-ориентированные системыболее открыты и легче поддаются модернизации. На основе объектно-ориентированнойдекомпозиции сложные программные системы удается строить путем эволюционногоразвития небольших подсистем.Результатом работы второго этапа являются8••••схема иерархии подсистем (или модулей, для алгоритмическойдекомпозиции),функциональность и интерфейсы каждой подсистемы, то есть их внешниеспецификации (первые два результата возникают от проектирования “вбольшом”),внутреннее представление (структура) данных для каждого отдельногомодуля программы,алгоритмы, обрабатывающие данные в каждом отдельном модулепрограммы (последние два результата – от проектирования “в малом”).Написание текста чаще называется программированием или кодированием,этот этап заканчивается, когда в наличии оказывается текст программы на некоторомязыке программирования.

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

Наиболее широко применяются эвристическиеметоды верификации, основанные на тестировании. Тестирование программы естьпроцесс обнаружения дефектов в созданных программах. Во время тестированиявыявляется несоответствие программы исходным требованиям и спецификациям потестам, то есть программам с заранее известными ответами. Среди методов наиболееизвестны методы “черного” и “белого” ящиков. Отладка программ – это выявлениепричин дефектов, а также их устранение. Отладка начинается после обнаружениядефектов. Иногда на этапе отладки приходится устранять не только причины дефектов,но и дефекты в данных, возникшие при работе неверных программ.Результатом тестирования и отладки является доказательство, что всевыявленные на данном комплекте тестов ошибки исправлены, а других ошибок необнаружено.Этапкомпоновкипредставляетсобойинтеграционныйпроцесскомплексирования (комбинирования), то есть связывания отдельных частей программыв одну большую систему программного обеспечения.

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

На этом этапе возникает множествоорганизационныхпроблемпообучениюпользователей,тестированиюработоспособности и устойчивости программы при работе в конкретной организации иконкретной операционной среде. Если организация заказчика представляет собойразветвленную сеть рабочих мест, проводится тиражирование продукта.9Во время сопровождения программного продукта можно наблюдатьпродолжение контактов пользователей и разработчиков. Сопровождение являетсязеркальным отражением разработки и внутри себя содержит все этапы фазы разработки(от определения требований до документирования, внедрения и тиражирования).В идеальном случае процесс разработки может иметь вид последовательновыполняемых слабо связанных между собой этапов. Такая схема разработки называетсянисходящей, и она редко встречается на практике. Чаще встречается каскадная схема, вкоторой можно наблюдать замыкание процесса и проведение повторного анализатребований после проведения его тестирования.

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