Разработка приложения, реализующего метод Флойда

быстродействие (драйверы);

размер кода (загрузочные сектора, программное обеспечение для микроконтроллеров и процессоров с ограниченными ресурсами, вирусы, программные защиты);

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

Связывание ассемблерного кода с другими языками.

Поскольку на ассемблере чаще всего пишут лишь фрагменты программы, их необходимо связывать с остальными частями на других языках. Это достигается 2 основными способами:

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

На этапе компоновки, или раздельная компиляция. Для взаимодействия скомпонованных модулей достаточно, чтобы связующие функции[3] поддерживали нужные соглашения о вызовах (англ. calling conventions) и типы данных. Написаны же отдельные модули могут быть на любых языках, в том числе и на ассемблере.

Синтаксис.

Общепринятого стандарта для синтаксиса языков ассемблера не существует. Однако, существуют стандарты, которых придерживаются большинство разработчиков языков ассемблера. Основными такими стандартами являются Intel-синтаксис и AT&T-синтаксис.

Инструкции.

Общий формат записи инструкций одинаков для обоих стандартов: [метка:] опкод [операнды] [;комментарий], где опкод - непосредственно мнемоника инструкции процессору. К ней могут быть добавлены префиксы (повторения, изменения типа адресации и пр.).

В качестве операндов могут выступать константы, названия регистров, адреса в оперативной памяти и пр. Различия между стандартами Intel и AT&T касаются, в основном, порядка перечисления операндов и их синтаксиса при различных методах адресации.

Используемые мнемоники обычно одинаковы для всех процессоров одной архитектуры или семейства архитектур (среди широко известных - мнемоники процессоров и контроллеров Motorola, ARM, x86). Они описываются в спецификации процессоров. Возможные исключения:

Если ассемблер использует кроссплатформенный AT&T-синтаксис (оригинальные мнемоники приводятся к синтаксису AT&T)

Если изначально существовало два стандарта записи мнемоник (система команд была наследована от процессора другого производителя).

Например, процессор Zilog Z80 наследовал систему команд Intel i8080, расширил ее и поменял мнемоники (и обозначения регистров) на свой лад. Например сменил интеловские mov[4] на ld. Процессоры Motorola Fireball наследовали систему команд Z80, несколько её урезав. Вместе с тем, Motorola официально вернулась к мнемоникам Intel. И в данный момент половина ассемблеров для Fireball работает с интеловскими мнемониками, а половина с мнемониками Zilog.

Директивы.

Кроме инструкций, программа может содержать директивы: команды, не переводящиеся непосредственно в машинные инструкции, а управляющие работой компилятора. Набор и синтаксис их значительно разнятся и зависят не от аппаратной платформы, а от используемого компилятора (порождая диалекты языков в пределах одного семейства архитектур). В качестве "джентельменского набора" директив можно выделить:

определение данных (констант и переменных);

управление организацией программы в памяти и параметрами выходного файла;

задание режима работы компилятора;

всевозможные абстракции (т.е. элементы языков высокого уровня) - от оформления процедур и функций (для упрощения реализации парадигмы процедурного программирования) до условных конструкций и циклов (для парадигмы структурного программирования);

макросы.

Пример программы.

Пример программы Hello world для MS-DOS для архитертуры x86 на диалекте TASM:

MODEL TINY

CODE SEGMENT

ASSUME CS:CODE, DS:CODE

ORG 100h

START:

mov ah,9

mov dx,OFFSET Msg

int 21h

int 20h

Msg DB 'Hello World',13,10,'$'

CODE ENDS

END START

Происхождение и критика термина "язык ассемблера".

Данный тип языков получил свое название от названия транслятора (компилятора) с этих языков - ассемблера (англ. assembler - сборщик). Название последнего обусловлено тем, что на первых компьютерах не существовало языков более высокого уровня, и единственной альтернативой созданию программ с помощью ассемблера было программирование непосредственно в кодах.

Язык ассемблера в русском языке часто называют "ассемблером" (а что-то связанное с ним - "ассемблерный"), что, согласно английскому переводу слова, неправильно, но вписывается в правила русского языка. Однако, сам ассемблер (программу) тоже называют просто "ассемблером", а не "компилятором языка ассемблера" и т. п.

Использование термина "язык ассемблера" также может вызвать ошибочное мнение о существовании единого языка низкого уровня, или хотя бы стандарта на такие языки. При именовании языка, на котором написана конкретная программа, желательно уточнять, для какой архитектуры она предназначена и на каком диалекте языка написана.

· Python.

Python - это один из наиболее популярных современных языков программирования. Он пригоден для решения разнообразных задач и предлагает те же возможности, что и другие языки программирования: динамичность, поддержку ООП и кросс-платформенность. Разработку Python начал Гвидо Ван Россум (Guido Van Rossum) еще в середине 1990-х годов, поэтому к настоящему времени удалось избавиться от стандартных "детских" болезней, существенно развить лучшие стороны языка и привлечь множество программистов, использующих Python для реализации своих проектов.

Многие программисты считают, что необходимо изучать только "классические" языки программирования, такие как Java или C++, так как другие языки все равно не смогут обеспечить таких же возможностей. Однако в последнее время возникло убеждение, что программисту желательно знать более одного языка, так как это расширяет его кругозор, позволяя более творчески решать поставленные задачи и повышая его конкурентоспособность на рынке труда.

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

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

Поэтому кем бы ни являлся читатель данной статьи - опытным программистом или новичком в области разработки ПО, ответом на вопрос, который является и названием этого раздела, должно стать убедительное "да".

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

Архитектура Python.

Любой язык, неважно - для программирования или общения, состоит как минимум из двух частей - словаря и синтаксиса. Язык Python организован точно так же, предоставляя синтаксис для формирования выражений, образующих исполняемые программы, и словарь - набор функциональности в виде стандартной библиотеки и подключаемых модулей.

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

К Python это не относится, так как это язык простой, но упрощенный. Дело в том, что Python является языком с более высоким уровнем абстракции, выше, например, чем у Java и C++, и позволяет передать такое же количество информации в меньшем объеме исходного кода.

Также Python является языком общего назначения, поэтому может применяться практически в любой области разработки ПО (standalone, клиент-сервер, Web-приложения) и в любой предметной области. Кроме того, Python легко интегрируется с уже существующими компонентами, что позволяет внедрять Python в уже написанные приложения.

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

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

Среда исполнения Python.

Как известно, все кросс-платформенные языки программирования построены по одной модели: это действительно переносимый исходный код и среда исполнения (runtime environment), которая не является переносимой и специфична для каждой конкретной платформы. В эту среду исполнения обычно входит интерпретатор, который исполняет исходный код, и различные утилиты, необходимые для сопровождения приложения - отладчик, обратный ассемблер и т.д.

В среду исполнения Java дополнительно входит компилятор, так как исходный код необходимо скомпилировать в байт-код для виртуальной Java-машины. В среду исполнения Python входит только интерпретатор, который одновременно является и компилятором, однако компилирует исходный код Python непосредственно в машинный код целевой платформы.

На данный момент существуют три известных реализации среды исполнения для Python: CPython, Jython и Python.NET. Как можно догадаться из названия, первая среда реализована на языке C, вторая на языке Java, а последняя - на платформе.NET.

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

Среда исполнения Jython - это реализация Python для работы с виртуальной Java-машиной (JVM). Поддерживается любая версия JVM, начиная с версии 1.2.2 (текущая версия Java - 1.6). Для работы с Jython требуется установленная Java-машина (среда исполнения Java) и определенное знание языка программирования Java. Уметь писать исходный код на языке Java не обязательно, однако придется иметь дело c JAR-файлами и Java-апплетами, а также документацией в формате JavaDOC.

Какую версию среды выбрать - зависит исключительно от предпочтений программиста, вообще же рекомендуется держать на компьютере и CPython, и Jython, так как они не конфликтуют между собой, а взаимно дополняют друг друга. Среда CPython работает быстрее, так как нет промежуточного уровня в виде JVM; кроме того, обновленные версии Python сначала выпускают именно в виде среды CPython. Однако Jython может использовать любой класс Java в качестве модуля расширения и работать на любой платформе, для которой существует реализация JVM.

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

· Ruby.

Среда исполнения Python.

Как известно, все кросс-платформенные языки программирования построены по одной модели: это действительно переносимый исходный код и среда исполнения (runtime environment), которая не является переносимой и специфична для каждой конкретной платформы. В эту среду исполнения обычно входит интерпретатор, который исполняет исходный код, и различные утилиты, необходимые для сопровождения приложения - отладчик, обратный ассемблер и т.д.

В среду исполнения Java дополнительно входит компилятор, так как исходный код необходимо скомпилировать в байт-код для виртуальной Java-машины. В среду исполнения Python входит только интерпретатор, который одновременно является и компилятором, однако компилирует исходный код Python непосредственно в машинный код целевой платформы.

На данный момент существуют три известных реализации среды исполнения для Python: CPython, Jython и Python.NET. Как можно догадаться из названия, первая среда реализована на языке C, вторая на языке Java, а последняя - на платформе.NET.

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

Среда исполнения Jython - это реализация Python для работы с виртуальной Java-машиной (JVM). Поддерживается любая версия JVM, начиная с версии 1.2.2 (текущая версия Java - 1.6). Для работы с Jython требуется установленная Java-машина (среда исполнения Java) и определенное знание языка программирования Java. Уметь писать исходный код на языке Java не обязательно, однако придется иметь дело c JAR-файлами и Java-апплетами, а также документацией в формате JavaDOC.

Какую версию среды выбрать - зависит исключительно от предпочтений программиста, вообще же рекомендуется держать на компьютере и CPython, и Jython, так как они не конфликтуют между собой, а взаимно дополняют друг друга. Среда CPython работает быстрее, так как нет промежуточного уровня в виде JVM; кроме того, обновленные версии Python сначала выпускают именно в виде среды CPython. Однако Jython может использовать любой класс Java в качестве модуля расширения и работать на любой платформе, для которой существует реализация JVM.

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

Сервисные программы.

Сервисные программы расширяют возможности ОС. Их обычно называют утилитами. Утилиты позволяют, например, проверять информацию в шестнадцатиричных кодах, которая сохраняется в отдельных секторах магнитных дисков; организовывать вывод на принтер текстовых файлов в заданном формате, выполнять архивацию и разархивацию файлов.

Часто утилиты объединяют в комплексы наиболее популярные комплексы Norton Utilities, PC Tools Deluxe и Mace Utilities.

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

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

Типы драйверов.

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

· драйверы пользовательского уровня - исполняются в пользовательском режиме и предоставляют интерфейс между приложениями и драйверами уровня ядра. К ним относятся драйверы принтеров и драйверы виртуальных устройств;

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

С точки зрения документации MSDN драйверы уровня ядра делятся на следующие слои, опишем их на примере драйверов файловых систем.

1) Драйверы высокого уровня. К ним относятся драйверы файловых систем, которые поддерживают файловые системы, например FAT, NTFS, CDFS. Драйверы высокого уровня всегда зависят от драйверов нижних уровней.

2) Драйверы промежуточного уровня. К ним относятся драйверы, обеспечивающие поддержку виртуальных дисков и зеркалирования. Драйверы промежуточного уровня зависят от драйверов нижнего уровня. Кроме того, они подразделяются на следующие подклассы:

· функциональные драйверы - управляют конкретным типом устройств. Драйверы шин предоставляют устройства функциональным драйверам через диспетчер PnP;

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

· драйверы нижнего уровня. Контролируют ввод/вывод шины, к которой подключено периферийное устройство. Здесь также существуют разные виды драйверов;

· драйверы шин - управляют логическими или физическими шинами, такими как PCI, USB. Драйверы шин отвечают за распознавание устройств, подключенных напрямую к этим шинам, оповещение диспетчера PnP об этих устройствах и управление параметрами электропитания шины;

· драйверы, не поддерживающие WDM.

Таким образом, системное ПО - это совокупность программных и языковых средств.

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

1.2 Жизненный цикл прикладной программы

Жизненным циклом программы (ЖЦП) на отрезок времени от принятия решения о необходимости разработки программы до снятия программы с эксплуатации. ЖЦП делится на фазы разработки и использования. Первой фазе соответствует разработка документации, а второй сопровождение. Под сопровождением понимают два вида работ:

1. Модификация программы за счет изменения модели предметной области.

2. Нахождение и исправление ошибок, которые есть в программе. В свою очередь фаза разработки делится на 4 под фазы:

1. Анализ задачи.

2. Проектирование.

3. Кодирование.

4. Тестирование.

Каждый период заканчивается своей документацией.

1. Техническое задание.

2. Эскизный, технический проекты, пояснительная записка.

3. Распечатка программы и статическое тестирование.

4. Сборка программы, программа тестирования, результаты

5. Тестирования.

Разработка ПО может вестись с использованием лавинообразной (Схема 2) или итеративной (Схема 3) моделей разработки. Лавинообразная модель (модель "водопада") может быть использована для разработки ПО небольшого размера с хорошо определенной алгоритмической базой.



Схема 1-Лавинообразная

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

· планирование;

· реализация;

· проверка;

· оценка.



Схема 2- Итеративная

Преимущества итеративного подхода:

· снижение воздействия серьёзных рисков на ранних стадиях проекта, что ведет к минимизации затрат на их устранение;

· организация эффективной обратной связи проектной команды с потребителем (а также заказчиками, стейкхолдерами) и создание продукта, реально отвечающего его потребностям;

· акцент усилий на наиболее важные и критичные направления проекта;

· непрерывное итеративное тестирование, позволяющее оценить успешность всего проекта в целом;

· раннее обнаружение конфликтов между требованиями, моделями и реализацией проекта;

· более равномерная загрузка участников проекта;

· эффективное использование накопленного опыта;

· реальная оценка текущего состояния проекта и, как следствие, большая уверенность заказчиков и непосредственных участников в его успешном завершении.

1.3 Методология и технология разработки ПП

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

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

Применительно к программированию технологию можно определить, как совокупность процессов создания, сопровождения и применения программного продукта. Любая технология программирования базируется на некоторой методологии разработки программ.

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

Методология - совокупность методов, применяемых в какой-либо области человеческой деятельности.

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

Методология науки дает характеристику компонентов научного исследования - его объекта, предмета анализа, задачи исследования, совокупности исследовательских средств, необходимых для решения задачи данного типа, а также формирует представление о последовательности движения исследователя в процессе решения задачи. Методология создания информационных систем заключается в организации процесса построения информационной системы и обеспечении управления этим процессом для того, чтобы гарантировать выполнение требований как к самой системе, так и к характеристикам процесса разработки. При разработке или приобретении программных продуктов встает проблема формулирования бизнес-требований, предъявляемых к программному продукту или услуге. В значительной степени ошибки проектирования обусловлены неточным выражением этих требований. Разработка программного обеспечения - Software Development Process рассматривается как проектная деятельность, предполагающая дискретность выполнения отдельных шагов (итераций), использование различного вида ресурсов (трудовых, материальных, финансовых, информационных). Проект по созданию программного продукта обладает рядом характеристик, которые влияют на выбор методологии и инструментальных средств разработки.

Сформировалось три стратегии разработки программных продуктов:

1) линейная последовательность этапов разработки, предполагающая однократный проход этапов процесса разработки; поддерживается "водопадной" моделью жизненного цикла программного продукта;

2) инкрементная стратегия, когда определенные в полном объеме бизнес-требования к программному продукту реализуются постепенно, в виде последовательности версий, расширяющих функциональность программного продукта;

3) эволюционная стратегия, когда в начале требования определяются в неполном объеме, но уточняются в ходе разработки версий программного продукта. Линейная последовательность этапов разработки имеет несколько вариантов. Модель водопада (Waterfall Model) - наиболее "старая" модель процесса разработки программного обеспечения. Процесс разработки представляется как последовательность (поток) этапов, фаз (анализа требований, проектирования, реализации, тестирования, интеграции и поддержки). Разработчик переходит от одной стадии к другой строго последовательно, после полного и успешного завершения предыдущей фазы; переходов назад либо вперед или перекрытия фаз не происходит. Системный анализ определяет роль каждого элемента в компьютерной системе, взаимодействие элементов друг с другом. Анализ начинается с определения требований и назначения подмножества этих требований программному элементу. Среди основных решаемых задач планирования проекта программного обеспечения выделяют: объем, сроки и трудозатраты проектных работ, бюджет проекта, состав исполнителей, план-график работ. В процессе анализа требований уточняются функции и характеристики программного средства, требования к пользовательскому и программному интерфейсам. Проектирование программного продукта включает в себя разработку архитектуры построения, состава и назначения модулей, алгоритмов и структуры данных, интерфейсов. Кодирование обеспечивает реализацию проектных решений в выбранной среде программирования. Тестирование - обязательный этап для выявления дефектов программного продукта. Сопровождение - поддержка работоспособности программного продукта у заказчика, внесение изменений в эксплуатируемый программный продукт. Каждая стадия (этап) завершается выпуском полного комплекта документации. Эта модель обладает как достоинствами, так и недостатками. Основная проблема - нарастание риска проекта из-за накапливания ошибок ранних стадий проекта, что не позволяет эффективно выявлять и нивелировать последствия подобных рисков.



Рисунок 1. Этапы разработки ПО для водопадной модели

Модифицированные модели водопада - Agile Software Development, гибкая или "живая" методология разработки, нацелена на минимизацию рисков путем сведения разработки к серии коротких циклов, называемых итерациями, длительностью не более двух недель. Каждая итерация обеспечивает прохождение всех фаз проекта, обеспечивая инкремент (прирост) функциональности. Однако итерация, как правило, недостаточна для выпуска новой версии продукта. По окончании итерации команда разработчиков оценивает и выбирает приоритеты разработки. Основной метрикой данной методологии становится рабочий продукт, а не система письменной документации. Далее была создана модель RAD - Rapid Application Development (быстрая разработка приложений), которая стала основой технологий создания и развертывания программных продуктов. Эта модель предусматривает:

· инструментальную поддержку процесса разработки, минимизацию времени и трудозатрат;

· использование прототипа для уточнения требований заказчика;

· цикличность разработки - каждая новая версия продукта основывается на оценке результата работы предыдущей версии заказчиком;

· постепенное расширение функциональности;

· распределение ролей в команде разработчика, возможность их совмещения;

· управление проектом создания программного продукта.

Модель RAD может принимать одну из трех форм: макет (в виде чертежа формы документа, схемы диалога), работающий макет для ограниченного набора функций или типовой программный продукт, подлежащий настройке. Макетирование основывается на многократном повторении итераций, в которых участвуют заказчик и разработчик, и начинается со сбора и уточнения требований к создаваемому программному продукту.

Инкрементная модель объединяет элементы последовательной водопадной модели с итерационной основой макетирования.

Рисунок 2. Схема выполнения проектных работ по модели RAD

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

Эволюционная стратегия получила свое воплощение в ряде моделей: спиральной, компонентно-ориентированной. Автором спиральной модели является американский ученый Б. Боэм (1988).

Спиральная модель объединила свойства классического жизненного цикла и макетирования, но дополнила их анализом риска. Эта модель включает в себя четыре обязательные фазы:

1) планирование - определение целей, вариантов, ограничений;

2) анализ риска - анализ вариантов и распознавание (выбор) риска;

3) конструирование - разработка продукта следующего уровня;

4) оценивание - оценка заказчиком текущих результатов разработки.

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

Спиральная модель ориентирована на большие, дорогостоящие и сложные проекты. При этом требуется:

1. Постоянное взаимодействие с потенциальными пользователями, выяснение изменяющихся требований к программной системе.

2. Разработка архитектуры системы, определяющей концепцию построения программного продукта, открытой для изменений.

3. Наличие разработчиков высокой квалификации, инструментария разработки, соответствующего масштабу и сложности программного продукта.



Рисунок 3. Схема выполнения проектных работ по спиральной модели: 1 - планирование проекта и жизненного цикла; 2 - концепция эксплуатации; 3 - спецификация требований; 4 - проверка требований; 5 - детальный дизайн; 6 - кодирование; 7 - модульное тестирование; 8 - интеграция и тестирование; 9 - приемочное тестирование; 10 - развертывание.

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

1.4 Тестирование программных средств

История развития тестирования программного обеспечения.

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

В начале 1970-х тестирование ПО обозначалось как "процесс, направленный на демонстрацию корректности продукта" или как "деятельность по подтверждению правильности работы ПО". В зарождавшейся программной инженерии верификация ПО значилась как "доказательство правильности". Хотя концепция была теоретически перспективной, на практике она требовала много времени и была недостаточно всеобъемлющей. Было решено, что доказательство правильности - неэффективный метод тестирования ПО. Однако, в некоторых случаях демонстрация правильной работы используется и в наши дни, например, приемо-сдаточные испытания. Во второй половине 1970-х тестирование представлялось как выполнение программы с намерением найти ошибки, а не доказать, что она работает. Успешный тест - это тест, который обнаруживает ранее неизвестные проблемы. Данный подход прямо противоположен предыдущему. Указанные два определения представляют собой "парадокс тестирования", в основе которого лежат два убедиться, что продукт работает хорошо, а с другой - выявляет ошибки в ПО, показывая, что продукт не работает. Вторая цель тестирования является более продуктивной с точки зрения улучшения качества, так как не позволяет игнорировать недостатки ПО.

В 1980-х тестирование расширилось таким понятием, как предупреждение дефектов. Проектирование тестов - наиболее эффективный из известных методов предупреждения ошибок. В это же время стали высказываться мысли, что необходима методология тестирования, в частности, что тестирование должно включать проверки на всем протяжении цикла разработки, и это должен быть управляемый процесс. В ходе тестирования надо проверить не только собранную программу, но и требования, код, архитектуру, сами тесты. "Традиционное" тестирование, существовавшее до начала 1980-х, относилось только к скомпилированной, готовой системе (сейчас это обычно называется системное тестирование), но в дальнейшем тестировщики стали вовлекаться во все аспекты жизненного цикла разработки. Это позволяло раньше находить проблемы в требованиях и архитектуре и тем самым сокращать сроки и бюджет разработки. В середине 1980-х появились первые инструменты для автоматизированного тестирования. Предполагалось, что компьютер сможет выполнить больше тестов, чем человек, и сделает это более надежно. Поначалу эти инструменты были крайне простыми и не имели возможности написания сценариев на скриптовых языках.

В начале 1990-х в понятие "тестирование" стали включать планирование, проектирование, создание, поддержку и выполнение тестов и тестовых окружений, и это означало переход от тестирования к обеспечению качества, охватывающего весь цикл разработки ПО. В это время начинают появляться различные программные инструменты для поддержки процесса тестирования: более продвинутые среды для автоматизации с возможностью создания скриптов и генерации отчетов, системы управления тестами, ПО для проведения нагрузочного тестирования. В середине 1990-х с развитием Интернета и разработкой большого количества веб-приложений особую популярность стало получать "гибкое тестирование" (по аналогии с гибкими методологиями программирования).

В 2000-х появилось еще более широкое определение тестирования, когда в него было добавлено понятие "оптимизация бизнес-технологий" (en:business technology optimization, BTO). BTO направляет развитие информационных технологий в соответствии с целями бизнеса. Основной подход заключается в оценке и максимизации значимости всех этапов жизненного цикла разработки ПО для достижения необходимого уровня качества, производительности, доступности.

Тестирование программного обеспечения - процесс исследования программного обеспечения (ПО) с целью получения информации о качестве продукта. алгоритм интерфейс delphi

Существует несколько признаков, по которым принято производить классификацию видов тестирования. Обычно выделяют следующие:

· по объекту тестирования;

· по знанию системы;

· по знанию системы;

· по степени автоматизированности;

· по степени изолированности компонентов;

· по времени проведения тестирования;

· по признаку позитивности сценариев;

· по степени подготовленности к тестированию.

Уровни тестирования.

Модульное тестирование (юнит-тестирование) - тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция. Часто модульное тестирование осуществляется разработчиками ПО.

Интеграционное тестирование - тестируются интерфейсы между компонентами, подсистемами. При наличии резерва времени на данной стадии тестирование ведётся итерационно, с постепенным подключением последующих подсистем.

Системное тестирование - тестируется интегрированная система на её соответствие требованиям.

Бета-тестирование - интенсивное использование почти готовой версии продукта (как правило, программного или аппаратного обеспечения) с целью выявления максимального числа ошибок в его работе для их последующего устранения перед окончательным выходом (Релизом) продукта на рынок, к массовому потребителю.

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

Альфа-тестирование - имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком. Чаще всего альфа-тестирование проводится на ранней стадии разработки продукта, но в некоторых случаях может применяться для законченного продукта в качестве внутреннего приёмочного тестирования. Иногда альфа-тестирование выполняется под отладчиком или с использованием окружения, которое помогает быстро выявлять найденные ошибки.

Обнаруженные ошибки могут быть переданы тестировщикам для дополнительного исследования в окружении, подобном тому, в котором будет использоваться ПО.

Тестирование "белого ящика" и "чёрного ящика".

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

При тестировании белого ящика (англ. white-box testing, также говорят - прозрачного ящика), разработчик теста имеет доступ к исходному коду программ и может писать код, который связан с библиотеками тестируемого ПО. Это типично для юнит-тестирования (англ. unit testing), при котором тестируются только отдельные части системы. Оно обеспечивает то, что компоненты конструкции - работоспособны и устойчивы, до определённой степени. При тестировании белого ящика используются метрики покрытия кода.

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

Тестирование программного обеспечения.

Существует несколько признаков, по которым принято производить классификацию видов тестирования. Обычно выделяют следующие:

По объекту тестирования:

1. Функциональное тестирование (functional testing)-- это тестирование ПО в целях проверки реализуемости функциональных требований, то есть способности ПО в определённых условиях решать задачи, нужные пользователям. Функциональные требования определяют, что именно делает ПО, какие задачи оно решает.

функциональные требования включают в себя:

· функциональная пригодность (англ. suitability);

· точность (англ. accuracy);

· способность к взаимодействию (англ. interoperability);

· соответствие стандартам и правилам (англ. compliance);

· защищённость (англ. security).

2. Тестирование производительности (performance testing). Тестирование производительности в инженерии программного обеспечения - тестирование, которое проводится с целью определения, как быстро работает вычислительная система или её часть под определённой нагрузкой. Также может служить для проверки и подтверждения других атрибутов качества системы, таких как масштабируемость, надёжность и потребление ресурсов.

Тестирование производительности - это одна из сфер деятельности развивающейся в области информатики инженерии производительности, которая стремится учитывать производительность на стадии моделирования и проектирования системы, перед началом основной стадии кодирования.

Направления тестирования производительности.

В тестировании производительности различают следующие направления:

· нагрузочное (load);

· стресс (stress);

· тестирование стабильности (endurance or soak or stability);

· конфигурационное (configuration);

Возможны два подхода к тестированию производительности программного обеспечения:

· в терминах рабочей нагрузки: программное обеспечение подвергается тестированию в ситуациях, соответствующих различным сценариям использования;

· в рамках бета-тестирования, когда система испытывается реальными конечными пользователями.

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

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

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

6. Конфигурационное тестирование - ещё один из видов традиционного тестирования производительности. В этом случае вместо того, чтобы тестировать производительность системы с точки зрения подаваемой нагрузки, тестируется эффект влияния на производительность изменений в конфигурации. Хорошим примером такого тестирования могут быть эксперименты с различными методами балансировки нагрузки. Конфигурационное тестирование также может быть совмещено с нагрузочным, стресс или тестированием стабильности.

Определение целей тестирования производительности.

В общих случаях тестирование производительности может служить разным целям:

· c целью демонстрации того, что система удовлетворяет критериям производительности;

· с целью определения производительность какой из двух или нескольких систем лучше;

· c целью определения, какой элемент нагрузки или часть системы приводит к снижению производительности.

Многие тесты на производительность делаются без попытки осмыслить их реальные цели. Перед началом тестирования всегда должен быть задан бизнес-вопрос: "Какую цель мы преследуем, тестируя производительность?". Ответы на этот вопрос являются частью технико-экономического обоснования (или business case) тестирования. Цели могут различаться в зависимости от технологий, используемых приложением, или его назначения, однако, они всегда включают что-то из нижеследующего:

· параллелизм;

· пропускная способность.

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

Если концепция приложения не заключается в работе с конкретными конечными пользователями, то преследуемая цель для производительности будет основана на максимальной пропускной способности или числе транзакций в единицу времени. Хорошим примером в данном случае будет являться просмотр веб-страниц, например, на портале Wikipedia.

Время ответа сервера.

Эта концепция строится вокруг времени ответа одного узла приложения на запрос, посланный другим. Простым примером является HTTP 'GET' запрос из браузера рабочей станции на веб-сервер. Практически все приложения, разработанные для нагрузочного тестирования работают именно по этой схеме измерений. Иногда целесообразно ставить задачи по достижению производительности времени ответа сервера среди всех узлов приложения.

Время отображения.

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

Требования к производительности.

Очень важно детализировать требования к производительности и документировать их в каком-либо плане тестирования производительности. В идеальном случае это делается на стадии разработки требований при разработке системы, до проработки деталей её дизайна. Однако тестирование производительности часто не проводится согласно спецификации, так как нет зафиксированного понимания о максимальном времени ответа для заданного числа пользователей. Тестирование производительности часто используется как часть процесса профайлинга производительности. Его идея заключается в том, чтобы найти "слабое звено" - такую часть системы, соптимизировав время реакции которой, можно улучшить общую производительность системы. Определение конкретной части системы, стоящей на этом критическом пути, иногда очень непростая задача, поэтому некоторые приложения для тестирования включают в себя (или могут быть добавлены с помощью add-on'ов) инструменты, запущенные на сервере (агенты) и наблюдающие за временем выполнения транзакций, временем доступа к базе данных, оверхедами сети и другими показателями серверной части системы, которые могут быть проанализированы вместе с остальной статистикой по производительности.