Технология программирования (ТП). Основные понятия и подходы. Основные этапы развития ТП. Стихийное программирование.
Технология программирования - совокупность методов, приемов и средств для сокращения стоимости и повышения качества разработки программных систем.
Технологией программирования называют совокупность методов и средств, используемых в процессе разработки программного обеспечения. Как любая другая технология, технология программирования представляет собой набор технологических инструкций, включающих: 1/Указание последовательности выполнения технологических операций;2/Перечисление условий, при которых выполняется та или иная операция;3/Описание самих операций, где для каждой операции определены исходные данные, результаты, а также инструкции, нормативы, стандарты, критерии и методы оценки и т.п.
Кроме набора операций и их последовательности, технология также определяет способ описания проектируемой системы, точнее модели, используемой на конкретном этапе разработки.
Основные этапы развития программирования как науки:
Первый этап – “ стихийное программирование ”. Этот этап охватывает период с момента появления первых вычислительных машин до середины 60-х годов 20 века. В этот период практически отсутствовали сформулированные технологии, и программирование фактически было искусством. Первые программы имели простейшую структуру. Они состояли из собственно программы на машинном языке и обрабатываемых ею данных. Сложность программ в машинных кодах ограничивалась способностью программиста одновременно мысленно отслеживать последовательность выполняемых операций и местонахождение данных при программировании.
Второй этап – структурный подход к программированию (60-70-е годы 20 века.) Структурный подход к программированию представляет собой совокупность рекомендуемых технологических приемов, охватывающих выполнение всех этапов разработки программного обеспечения. В основе структурного подхода лежит декомпозиция сложных систем с целью последующей реализации в виде отдельных небольших подпрограмм. С появлением других принципов декомпозиции данный способ получил название процедурной декомпозиции.
Третий этап – объектный подход к программированию (с середины 80-х до конца 90-х годов 20 века). Объектно-ориентированное программирование определяется как технология создания сложного программного обеспечения, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного типа, а классы образуют иерархию с наследованием свойств. Взаимодействие программных объектов в такой системе осуществляется путем передачи сообщений.
Четвертый этап – компонентный подход и CASE – технологии (с середины 90-х годов 20 века до нашего времени). Компонентный подход предполагает построение программного обеспечения из отдельных компонентов – физически отдельно существующих частей программного обеспечения, которые взаимодействуют между собой через стандартизованные двоичные интерфейсы. В отличие от обычных объектов объекты-компоненты можно собрать в динамически вызываемые библиотеки или исполняемые файлы, распространять в двоичном виде и использовать в любом языке программирования, поддерживающем соответствующую технологию.
Жизненный цикл и этапы разработки ПО
Жизненным циклом программного обеспечения называют период от момента появления идеи создания некоторого программного обеспечения до момента завершения его поддержки фирмой – разработчиком или фирмой, выполнявшей сопровождение.
Процесс разработки в соответствии со стандартом предусматривает действия и задачи, выполняемые разработчиком, и охватывает работы по созданию программного обеспечения и его компонентов в соответствии с заданными требованиями, включая оформление проектной и эксплуатационной документации, а также подготовку материалов, необходимых для проверки работоспособности и соответствия качества программных продуктов, материалов, необходимых для обучения персонала, и т.д.
Постановка задачи. В процессе постановки задачи четко формулируют назначение программного обеспечения и определяют основные требования к нему. Каждое требование представляет собой описание необходимого или желаемого свойства программного обеспечения. Различают функциональные требования, определяющие функции, которые должно выполнять разрабатываемое программное обеспечение, и эксплуатационные требования, определяющие особенности его функционирования.
Анализ требований и определение спецификаций. Спецификациями называют точное формализованное описание функций и ограничений разрабатываемого программного обеспечения. Соответственно различают функциональные и эксплуатационные спецификации. Совокупность спецификаций представляют собой логическую модель проектируемого программного обеспечения. Для получения спецификаций выполняют анализ требований технического задания, формулируют содержательную постановку задачи, выбирают аппарат формализации, строят модель предметной области, определяют подзадачи и выбирают или разрабатывают методы их решения. На этом этапе также целесообразно сформировать тесты для поиска ошибок в проектируемом программном обеспечении, обязательно указав ожидаемые результаты.
Проектирование. Основной задачей этого этапа является определение подробных спецификаций разрабатываемого программного обеспечения. Процесс проектирования сложного программного обеспечения обычно включает:
1/Проектирование общей структуры – определение основных компонентов и их взаимосвязей;2/Декомпозицию компонентов и построение структурных иерархий в соответствии с рекомендациями блочно – иерархического подхода;/3/Проектирование компонентов.
Результатом проектирования является детальная модель разрабатываемого программного обеспечения вместе со спецификациями его компонентов всех уровней.
Реализация. Реализация представляет собой процесс поэтапного написания кодов программы на выбранном языке программирования (кодирование), их тестирование и отладку.
Сопровождение. Сопровождение – это процесс создания и внедрения новых версий программного продукта. Причинами выпуска новых версий могут служить:
1/Необходимость исправления ошибок, выявленных в процессе эксплуатации предыдущих версий;2/Необходимость совершенствования предыдущих версий, например, улучшения интерфейса, расширения состава выполняемых функций или повышения его производительности;3/Изменение среды функционирования, например, появление новых технических средств и / или программных продуктов, с которыми взаимодействует сопровождаемое программное обеспечение.
На этом этапе в программный продукт вносят необходимые изменения, которые могут потребовать пересмотра проектных решений, принятых на любом предыдущем этапе.
3. Модули, их свойства. Сцепление модулей. Связность модулей.
Модульное программирование - метод разработки программ, предполагающий разбиение программы на независимые модули. Считается, что:
- оптимальный по размерам модуль целиком помещается на экране дисплея;
- разделение большой программы на модули облегчает ее разработку, отладку и сопровождение.
Размер модуля измеряется числом содержащихся в нем операторов (строк). Модуль не должен быть слишком маленьким или слишком большим.
Прочность модуля (связность) — это мера его внутренних связей. Чем выше прочность модуля, тем больше связей он может спрятать от внешней по отношению к нему части программы и, следовательно, тем больший вклад в упрощение программы он может внести. Для оценки степени прочности модуля Майерс [5] предлагает упорядоченный по степени прочности набор из семи классов модулей. Самой слабой степенью прочности обладает модуль, прочный по совпадению. Это такой модуль, между элементами которого нет осмысленных связей. Такой модуль может быть выделен, например, при обнаружении в разных местах программы повторения одной и той же последовательности операторов, которая и оформляется в отдельный модуль. Необходимость изменения этой последовательности в одном из контекстов может привести к изменению этого модуля, что может сделать его использование в других контекстах ошибочным. Такой класс программных модулей не рекомендуется для использования. Вообще говоря, предложенная Майерсом упорядоченность по степени прочности классов модулей не бесспорна. Однако, это не очень существенно, так как только два высших по прочности класса модулей рекомендуются для использования. Эти классы мы и рассмотрим подробнее.
Функционально прочный модуль — это модуль, выполняющий (реализующий) одну какую-либо определенную функцию. Информационно прочный модуль — это модуль, выполняющий (реализующий) несколько операций (функций) над одной и той же структурой данных (информационным объектом), которая считается неизвестной вне этого модуля. Сцепление модуля — это мера его зависимости по данным от других модулей. Характеризуется способом передачи данных. Чем слабее сцепление модуля с другими модулями, тем сильнее его независимость от других модулей.
Для оценки степени сцепления Майерс предлагает [5] упорядоченный набор из шести видов сцепления модулей. Худшим видом сцепления модулей является сцепление по содержимому. Таким является сцепление двух модулей, когда один из них имеет прямые ссылки на содержимое другого модуля (например, на константу, содержащуюся в другом модуле). Такое сцепление модулей недопустимо. Не рекомендуется использовать также сцепление по общей области — это такое сцепление модулей, когда несколько модулей используют одну и ту же область памяти. Такой вид сцепления модулей реализуется, например, при программировании на языке ФОРТРАН с использованием блоков COMMON. Единственным видом сцепления модулей, который рекомендуется для использования современной технологией программирования, является параметрическое сцепление (сцепление по данным по Майерсу [5]) — это случай, когда данные передаются модулю либо при обращении к нему как значения его параметров, либо как результат его обращения к другому модулю для вычисления некоторой функции. Такой вид сцепления модулей реализуется на языках программирования при использовании обращений к процедурам (функциям).
Рутинность модуля — это его независимость от предыстории обращений к нему. Модуль будем называть рутинным, если результат (эффект) обращения к нему зависит только от значений его параметров (и не зависит от предыстории обращений к нему). Модуль будем называть зависящим от предыстории, если результат (эффект) обращения к нему зависит от внутреннего состояния этого модуля, хранящего следы предыдущих обращений к нему.
4. Классификация моделей проектируемого ПО.
Методологии структурного анализа и проектирования, основанные на моделировании потоков данных, обычно используют комплексное представление проектируемого программного обеспечения в виде совокупности моделей:
• диаграмм потоков данных (DFD), описывающих взаимодействие источников и потребителей информации через процессы, которые должны быть реализованы в системе
• диаграмм «сущность-связь» (ERD), описывающих базы данных разрабатываемой системы;
• диаграмм переходов состояний (STD), характеризующих поведение системы во времени
• спецификаций процессов;
• словаря терминов.
Спецификации процессов. Спецификации процессов обычно представляют в виде краткого текстового описания, схем алгоритмов, псевдокодов, Flow-форм или диаграмм НассиШнейдермана. Поскольку описание процесса должно быть кратким и понятным как разработчику, так и заказчику, для их спецификации чаще всего используют псевдокоды.
Словарь терминов. Словарь терминов представляет собой краткое описание основных понятий, используемых при составлении спецификаций. Он должен включать определение основных понятий предметной области, описание структур элементов данных, их типов и форматов, а также всех сокращений и условных обозначений. Он предназначен для повышения степени понимания предметной области и исключения риска возникновения разногласий при обсуждении моделей между заказчиками и разработчиками.
5. Диаграммы переходов состояний (STD).
Моделируют поведение системы во времени в зависимости от прошедших событий. Такие диаграммы позволяют осуществить декомпозицию управляющих процессов, происходящих в системе и описать отношение между управляющими потоками. С помощью ДПС можно моделировать дальнейшее функционирование системы, исходя из предыдущих и текущего состояния.
Существует два способа построения STD:
- первый заключается в идентификации всех возможных состояний и анализе всех имеющих смысл переходов между ними;
- по второму способу сначала определяется начальное состояние, затем следующее за ним и т. д.
Если программная система в процессе функционирования активно не взаимодействует с окружающей средой (пользователем или датчиками), то диаграмма переходов состояний обычно интереса не представляет. В этом случае она демонстрирует только последовательно выполняемые переходы: из исходного состояния в состояние ввода данных, затем после выполнения вычислений - в состояние вывода и, наконец, в состояние завершения работы.
Для интерактивного программного обеспечения с развитым пользовательским интерфейсом основные управляющие воздействия - команды пользователя, для программного обеспечения реального времени — сигналы от датчиков и/или оператора производственного процесса. Общим для этих типов программного обеспечения является наличие состояния ожидания, когда программное обеспечение приостанавливает работу до получения очередного управляющего воздействия. Для интерактивного программного обеспечения наиболее характерно получение команд различных типов.
6. Функциональные диаграммы. Метод функционального моделирования SADT.
Методология SADT разработана Дугласом Россом. На ее основе разработана, в частности, известная методология IDEF0 (Icam DEFinition). Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Основные элементы этой методологии основываются на следующих концепциях:
· графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описываются посредством интерфейсных дуг, выражающих "ограничения", которые в свою очередь определяют, когда и каким образом функции выполняются и управляются;
· строгость и точность. Выполнение правил SADT требует достаточной строгости и точности, не накладывая в то же время чрезмерных ограничений на действия аналитика. Правила SADT включают:
· ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);
· связность диаграмм (номера блоков);
· уникальность меток и наименований (отсутствие повторяющихся имен);
· синтаксические правила для графики (блоков и дуг);
· разделение входов и управлений (правило определения роли данных).
· отделение организации от функции, т.е. исключение влияния организационной структуры на функциональную модель.
Методология SADT может использоваться для моделирования широкого круга систем и определения требований и функций, а затем для разработки системы, которая удовлетворяет этим требованиям и реализует эти функции. Для уже существующих систем SADT может быть использована для анализа функций, выполняемых системой, а также для указания механизмов, посредством которых они осуществляются.
Состав функциональной модели
Результатом применения методологии SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы - главные компоненты модели, все функции ИС и интерфейсы на них представлены как блоки и дуги. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как информация, которая подвергается обработке, показана с левой стороны блока, а результаты выхода показаны с правой стороны. Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу(рис.1.).
Одной из наиболее важных особенностей методологии SADT является постепенное введение все больших уровней детализации по мере создания диаграмм, отображающих модель.
Тестирование – это процесс выполнения программы, целью которого является выявление ошибок. Никакое тестирование не может доказать отсутствие ошибок в хоть сколько–нибудь сложном программном обеспечении. Однако соблюдение основных правил тестирования и научно обоснованный подбор тестов может уменьшить их количество.
Процесс разработки программного обеспечения, в том виде, как он определяется в современной модели жизненного цикла программного обеспечения, предполагает три стадии тестирования:
· Автономное тестирование компонентов программного обеспечения;
· Комплексное тестирование разрабатываемого программного обеспечения;
· Системное или оценочное тестирование на соответствие основным критериям качества.
Для повышения качества тестирования рекомендуется соблюдать следующие основные принципы:
· Предполагаемые результаты должны быть известны до тестирования;
· Следует избегать тестирования программы автором;
· Необходимо досконально изучать результаты каждого теста;
· Необходимо проверять действия программы на неверных данных;
· Необходимо проверять программу на неожиданные побочные эффекты на неверных данных.
Следует также иметь в виду, что вероятность наличия необнаруженных ошибок в части программы пропорциональны количеству ошибок уже найденных в этой части.
Существуют два принципиально различных подхода к формированию тестовых наборов: структурный и функциональный.
Структурный подход базируется на том, что известна структура тестируемого программного обеспечения, в том числе его алгоритмы (“стеклянный ящик”). В этом случае тесты строят так, чтобы проверить правильность реализации заданной логики в коде программы.
Функциональный подход основывается на том, что структура программного обеспечения неизвестна (“черный ящик”). В этом случае тесты строят, опираясь на функциональные спецификации. Этот подход называют так же подходом, управляемым данными, так как при его использовании тесты строят на базе различных способов декомпозиции множества данных
7. Структурное тестирование.
Структурный подход базируется на том, что известна структура тестируемого программного обеспечения, в том числе его алгоритмы (“стеклянный ящик”). В этом случае тесты строят так, чтобы проверить правильность реализации заданной логики в коде программы.
Структурное тестирование называют также тестированием по «маршрутам», так как в этом случае тестовые наборы формируют путем анализа маршрутов, предусмотренных алгоритмом. Под маршрутами при этом понимают последовательности операторов программы, которые выполняются при конкретном варианте исходных данных. В основе структурного тестирования лежит концепция максимально полного тестирования всех маршрутов программы. Так, если алгоритм программы включает ветвление, то при одном наборе исходных данных может быть выполнена последовательность операторов, реализующая действия, которые предусматривает одна ветвь, а при втором - другая. Соответственно, для программы будут существовать маршруты, различающиеся выбранным при ветвлении вариантом. Считают, что программа проверена полностью, если с помощью тестов удается осуществить выполнение программы по всем возможным маршрутам передач управления. Однако нетрудно видеть, что даже в программе среднего уровня сложности число неповторяющихся маршрутов может быть очень велико, и, следовательно, полное или исчерпывающее тестирование маршрутов, как правило, невозможно. Структурный подход к тестированию имеет ряд недостатков. Так тестовые наборы, построенные по данной стратегии: • не обнаруживают пропущенных маршрутов; • не обнаруживают ошибок, зависящих от обрабатываемых данных, например, в операторе if (a - b) < eps - пропуск функции абсолютного значения abs проявится только, если а < Ь; • не дают гарантии, что программа правильна, например, если вместо сортировки по убыванию реализована сортировка по возрастанию.