И.А. Волкова, И.Г. Головин, Л.Е. Карпов - Системы программирования (1119414), страница 2
Текст из файла (страница 2)
На этапе проектирования осуществляетсяпроцесс, который называют управлением сложностью.Как и все сложные системы, сложные программы имеют иерархическуюструктуру, а уровни их иерархии отражают различные уровни абстракции, следующиедруг из друга, но не тождественные друг другу. Эти уровни соответствуютвзаимозависимым подсистемам, которые сами могут иметь сложную, иерархическуюструктуру. На этапе проектирования широко применяется метод “разделяй и властвуй”.При проектировании сложных программных комплексов их обычно стараютсяразложить на некоторое число относительно небольших подсистем, каждую из которыхможно отладить независимо от других (“автономно”).
Основная сложностьпроектирования – определить основания для разделения общей системы насоставляющие ее подсистемы. Выбор подсистем часто зависит от разработчика исущественно влияет как на сложность процесса проектирования, так и на конечноекачество программного продукта. Такое разложение называется декомпозициейпрограммы.Декомпозицию одной и той же системы можно проводить, основываясь наразных ее свойствах.
Алгоритмическая декомпозиция разделяет программную системупо алгоритмам, в ней используемым. Такой метод декомпозиции ассоциируется соструктурным программированием и методом проектирования “сверху-вниз”. Каждыйотдельный полученный в результате модуль системы выполняет какой-либо одинэтапов работы общего системного процесса. Данные в таком подходе играютпассивную роль.Объектно-ориентированная декомпозиция связана с выделением отдельныхобъектов, которые способны воспринимать направляемые им сообщения и отвечатьвыполнением тех или иных ответных действий. Алгоритмы в такой модели теряютсвою независимость, они превращаются в операции над выделенными объектами.Активную роль в таком подходе приобретают данные программ, то есть объекты.
Этиобъекты обладают не только информационной составляющей (значениями), но идействиями.Если алгоритмическая декомпозиция концентрируется на последовательностипроисходящих событий, то декомпозиция по объектам фиксируется на этих объектах ина событиях, происходящих в системе и вызывающих действия. Сам процесс,выполняемый в программе, описывается в терминах посылки сообщений от объектадругим объектам. В последнее время объектно-ориентированный подходрассматривается, как более предпочтительный. Объектно-ориентированные системыболее открыты и легче поддаются модернизации. На основе объектно-ориентированнойдекомпозиции сложные программные системы удается строить путем эволюционногоразвития небольших подсистем.Результатом работы второго этапа являются8••••схема иерархии подсистем (или модулей, для алгоритмическойдекомпозиции),функциональность и интерфейсы каждой подсистемы, то есть их внешниеспецификации (первые два результата возникают от проектирования “вбольшом”),внутреннее представление (структура) данных для каждого отдельногомодуля программы,алгоритмы, обрабатывающие данные в каждом отдельном модулепрограммы (последние два результата – от проектирования “в малом”).Написание текста чаще называется программированием или кодированием,этот этап заканчивается, когда в наличии оказывается текст программы на некоторомязыке программирования.
Для написания текста программ чаще всего выбирается язык,соответствующий методам, выбиравшимся при анализе и формировании требований кпрограммному продукту и проведении декомпозиции строящейся системы. Вчастности, объектно-ориентированная декомпозиция особенно полезна припоследующем программировании на объектно-ориентированном языке.Верификацией программы называется процесс ее проверки на правильность.Существуют специальные теоретические методы верификации программ, примеромтаких методов может служить валидация – доказательство правильности программ сиспользованием логических методов.
Наиболее широко применяются эвристическиеметоды верификации, основанные на тестировании. Тестирование программы естьпроцесс обнаружения дефектов в созданных программах. Во время тестированиявыявляется несоответствие программы исходным требованиям и спецификациям потестам, то есть программам с заранее известными ответами. Среди методов наиболееизвестны методы “черного” и “белого” ящиков. Отладка программ – это выявлениепричин дефектов, а также их устранение. Отладка начинается после обнаружениядефектов.
Иногда на этапе отладки приходится устранять не только причины дефектов,но и дефекты в данных, возникшие при работе неверных программ.Результатом тестирования и отладки является доказательство, что всевыявленные на данном комплекте тестов ошибки исправлены, а других ошибок необнаружено.Этапкомпоновкипредставляетсобойинтеграционныйпроцесскомплексирования (комбинирования), то есть связывания отдельных частей программыв одну большую систему программного обеспечения. Обычно после компоновкипроводится этап комплексного тестирования программных систем, на которомпроверяется правильность взаимодействия всех автономно разработанных составныхчастей между собой.
Правильная организация процессов верификации, тестирования идокументирования имеет особое значение для последующего внедрения,тиражирования и сопровождения создаваемых программ.Внедрением называется работа по привлечению заказчика к использованиюсозданного программного продукта. На этом этапе возникает множествоорганизационныхпроблемпообучениюпользователей,тестированиюработоспособности и устойчивости программы при работе в конкретной организации иконкретной операционной среде. Если организация заказчика представляет собойразветвленную сеть рабочих мест, проводится тиражирование продукта.9Во время сопровождения программного продукта можно наблюдатьпродолжение контактов пользователей и разработчиков.
Сопровождение являетсязеркальным отражением разработки и внутри себя содержит все этапы фазы разработки(от определения требований до документирования, внедрения и тиражирования).В идеальном случае процесс разработки может иметь вид последовательновыполняемых слабо связанных между собой этапов. Такая схема разработки называетсянисходящей, и она редко встречается на практике. Чаще встречается каскадная схема, вкоторой можно наблюдать замыкание процесса и проведение повторного анализатребований после проведения его тестирования. Каскадная схема является одним извариантов итеративных схем разработки программного обеспечения.Буквальное следование каскадной схеме разработки приводит к существенномузапаздыванию получения результатов.
Согласование результатов с пользователямипроизводится только в точках, планируемых после завершения каждого этапа работ,требования к программному обеспечению зафиксированы в техническом задании навсе время разработки. Это приводит к тому, что пользователи могут вносить замечанияи пожелания по совершенствованию системы только после того, как работа над нейбудет полностью завершена. Каскадная схема хорошо пригодна для моделированияпроцессов разработки такого программного обеспечения, для которого с самого началаудается достаточно точно и полно сформулировать все требования, с тем, чтобы затемпредоставить разработчикам свободу выбора наиболее подходящих техническихметодов реализации.
Реально процесс разработки программного обеспечения никогдане бывает простым, чаще применяется каскадно-возвратный метод:ОпределениетребованийПроектированиееПрограммированиеКомпоновка(интеграция)Только для каскадной схемы,в нисходящей схеме –обратная связь отсутствуетОпределениетребованийПроектированиеПрограммированиеКомпоновка(интеграция)ТестированиеТестированиеДокументированиеРеальный ходразработкипрограммногообеспечения(каскадновозвратная схема)Идеальный случайразработкипрограммногообеспечения (нисходящаяи каскадная схемы)10ДокументированиеДля преодоления проблем каскадно-возвратного метода используетсяспиральная модель жизненного цикла, упор в которой делается на начальные этапы:определение требований, их анализ и проектирование. На этих этапах реализуемостьтехнических решений проверяется путем создания прототипов.
Каждый виток спиралисоответствует созданию фрагмента или версии программ, на нем уточняются цели ихарактеристики проекта, определяется качество проектирования, планируютсяследующие работы. Основная проблема спирального цикла – определение моментаперехода на следующий этап. Для ее решения вводят временные ограничения накаждый из этапов жизненного цикла.Написание текстаПроектированиеАнализ(определениетребований)КомпоновкаВерсия 1Версия 2Версия 3Верификация,тестирование,отладкаДокументированиеТиражированиеВнедрениеТехнологические процессы, составляющие жизненный цикл любогопрограммного продукта, стандартизованы. Международной организаций по стандартамISO, институтом IEEE и другими организациями, в том числе структурамиПравительства России, утверждены стандарты, описывающие процессы, видыдеятельности и задачи жизненного цикла программ и программно-аппаратных систем, атакже результаты, достигаемые с помощью различных видов деятельности.
С помощьюстандартов удается проводить оценку качества проводимых процессов и выискиватьвозможности для их улучшения. Например, международный стандарт ISO/IEC 15504(SPICE) Standard for Information Technology — Software Process Assessment (оценкапроцессов разработки и поддержки программного обеспечения) определяет правилаоценки процессов жизненного цикла. Этот стандарт определяет 5 категорий процессов,включающих 35 процессов и 201 вид деятельности.