Гибкие технологии и экстремальное программирование

Гибкие технологии

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

Ключевыми постулатами гибкой разработки являются

● Люди и их взаимодействие

● Создание работающего программного обеспечения

● Сотрудничество с заказчиком

● Реакция на изменение.

Ключевые правила поведения сводятся к следующему.

● Уважение мнения каждого участника команды

● Правдивость при любом общении

● Прозрачность всех данных, действий и решений

● Уверенность, что каждый участник поддержит команду

● Приверженность команде и её целям

Принципы гибкой методологии

1) Высшим приоритетом следует считать удовлетворение пожеланий заказчика

2) Не игнорировать изменения требований

3) Частое создание новых работающих версий ПО

4) Заказчики и разработчики должны работать совместно

5) Проекты должны воплощать в жизнь целеустремленные люди

6) Эффективный метод передачи информации – разговор лицом к лицу

7) Работающая программа – основной показатель прогресса в проекте

8) Гибкие процессы способствуют долгосрочной разработке

9) Непрестанное внимание к качественному проектированию

10) Простота

11) Самые лучшие решения выдают самоорганизующиеся команды

12) Команда должна регулярно задумываться над тем, как стать ещё более эффективной

Примеры реализации гибких методологий

Одним из прогрессивных направлений в гибких технологиях считается экстремальное программирование – e X treme P rogramming). Его основные особенности перечислены в следующих таблицах.

Базис XP

1)Игра планирования (Planning game)

2)Частая смена версий (Small releases)

3)Метафора (Metaphor)

4)Простое проектирование

5)Тестирование (TDD - Test Driven Development)

6)Реорганизация (Refactoring)

7)Парное программирование

8)Коллективное владение кодом

9)Непрерывная интеграция.

10)40-часовая неделя.

11)Локальный заказчик.

12)Стандарты кодирования

Рис. 7

Scrum

Scrum — методология управления разработкой информационных систем для гибкой разработки программного обеспечения. Scrum делает упор на качественный контроль процесса разработки. Кроме управления проектами по разработке ПО Scrum может также использоваться в работе команд поддержки программного обеспечения (software support teams), или как подход управления разработкой и сопровождением программ: Scrum of Scrums. Особенности рассматриваемой методологии иллюстрируют рис. 7 и 8.

Рис.8

Спринт — итерация в скрам, в ходе которой создаётся функциональный рост программного обеспечения. Она жестко фиксирована по времени. Длительность одного спринта от 2 до 4 недель.

Резерв проекта — это список требований к функциональности, упорядоченный по степени их важности, подлежащих реализации. Элементы этого списка называются «пожеланиями пользователя» (user story) или элементами резерва (backlog items). Резерв проекта открыт для редактирования для всех участников скрам процесса.

Пример характеристик СКРАМ приведен на рис. 9.

Scrum (роли)

По методике Scrum в производственном процессе есть определенные роли, разбитые на 2 группы «свиней» и «кур».

Свиньи:

● Скрам-мастер (ScrumMaster)

● Владелец проекта (Product Owner)

● Скрам-команда (Scrum Team).

Куры:

● Пользователи (Users)

● Клиенты, Продавцы (Stakeholders)

● Управляющие (Managers)

● Эксперты-консультанты (Consulting Experts).

План работы по методологии Scrum состоит из трех позиций:

1) Нужно сделать;

2) Делается;

3) Сделано.

Пример плана приведен на рис. 10

Нужно сделать Делается Сделано

Рис. 10

Документирование

Это – важный этап разработки программного обеспечения.

Организации, занимающиеся разработкой требований к документам

● ГОСТ – российские государственные стандарты

● IEEE – Институт инженеров по электротехнике и радиоэлектронике (www.ieee.org)

● ISO – международная организация по стандартизации

● SEI – Институт технологий разработки программного обеспечения

● OMG – консорциум по технологии манипулирования объектами (www.omg.org)

Документация по IEEE предполагает разработку на каждом этапе следующих документов.

План управления программным проектом Software Project Management Plan

План включает в себя следующие процессы.

1)Постановка задачи;

2)Организация проекта;

3)Управляющий процесс;

4)Технический процесс;

5)Распределение работ;

6)Дополнение.

Спецификация требований к программному обеспечению Software Requirements Specifications содержит следующие разделы.

1)Введение;

2)Общее описание;

3)Детальные требования;

4)Дополнительная информация.

Отечественный подход

Регламентирует следующие исходные данные и документацию на жизненный цикл (ЖЦ) программных систем (ПС).

● Стандарты и нормативные документы на ЖЦ ПС

● Стратегия и план документирования процессов и объектов ЖЦ ПС

● Ресурсы для документирования программ и данных

● Инструментальные средства и процессы для автоматизации документирования

Технологическая документация включает в себя.

● Документацию этапов и результатов проектирования ПС

● Документацию тестирования и испытаний ПС

● Документацию конфигурационного управления и совершенствования версий ПС

● Документацию управления и оценивания качества ПС

● Документацию гарантирования сохранности продуктов и документов ПС

● Комплект руководств и инструкций поддержки технологии ЖЦ ПС.

Эксплуатационная документация

● Документация администрирования при применении ПС

● Документация операторов-пользователей при применении ПС

● Документация обучения специалистов применению ПС.

Основным является ГОСТ 19 / ЕСПД. Его структура приведена в таблице.

ГОСТ 19.001-77 ЕСПД. Общие положения.

ГОСТ 19.101-77 ЕСПД. Виды программ и программных документов.

ГОСТ 19.102-77 ЕСПД. Стадии разработки.

ГОСТ 19.103-77 ЕСПД. Обозначение программ и программных документов.

ГОСТ 19.104-78 ЕСПД. Основные надписи.

ГОСТ 19.105-78 ЕСПД. Общие требования к программным документам.

ГОСТ 19.106-78 ЕСПД. Требования к программным документам, выполненным печатным способом.

ГОСТ 19.201-78 ЕСПД. Техническое задание. Требования к содержанию и оформлению.

ГОСТ 19.202-78 ЕСПД. Спецификация. Требования к содержанию и оформлению.

ГОСТ 19.301-79 ЕСПД. Порядок и методика испытаний.

ГОСТ 19.401-78 ЕСПД. Текст программы. Требования к содержанию и оформлению.

ГОСТ 19.402-78 ЕСПД. Описание программы.

ГОСТ 19.404-79 ЕСПД. Пояснительная записка. Требования к содержанию

ГОСТ 19 / ЕСПД и оформлению.

ГОСТ 19.501-78 ЕСПД. Формуляр. Требования к содержанию и оформлению.

ГОСТ 19.502-78 ЕСПД. Описание применения. Требования к содержанию и оформлению.

ГОСТ 19.503-79 ЕСПД. Руководство системного программиста. Требования к содержанию и оформлению.

ГОСТ 19.504-79 ЕСПД. Руководство программиста.

ГОСТ 19.505-79 ЕСПД. Руководство оператора.

ГОСТ 19.506-79 ЕСПД. Описание языка.

ГОСТ 19.508-79 ЕСПД. Руководство по техническому обслуживанию. Требования к содержанию и оформлению.

ГОСТ 19.604-78 ЕСПД. Правила внесения изменений в программные документы, выполняемые печатным способом.

ГОСТ 19.701-90 ЕСПД. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения.

ГОСТ 19.781-90. Обеспечение систем обработки информации программное.

Структура технического задания (ТЗ)

● введение;

● основания для разработки;

● назначение разработки;

● требования к программе или программному изделию;

● требования к программной документации;

● технико-экономические показатели;

● стадии и этапы разработки;

● порядок контроля и приемки;

● в техническое задание допускается включать приложения.

ГОСТ 34

Наиболее популярными можно считать стандарты:

● ГОСТ 34.601-90 (Стадии создания АС);

● ГОСТ 34.602-89 (ТЗ на создание АС);

● РД 50-34.698-90 (Требования к содержанию документов).

ISO/IEC 12207:1995-08-01 предусматривает 5 основных процессов ЖЦ ПО:

● Процесс приобретения;

● Процесс поставки;

● Процесс разработки;

● Процесс функционирования;

● Процесс сопровождения.

8 вспомогательных процессов, которые поддерживают реализацию другого процесса, будучи неотъемлемой частью всего ЖЦ программного изделия, и обеспечивают должное качество проекта ПО:

● решения проблем;

● документирования;

● управления конфигурацией;

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

1.Процесс верификации;

2.Процесс аттестации;

3.Процесс совместной оценки;

4.Процесс аудита.

Четыре организационных процесса:

● Процесс управления;

● Процесс создания инфраструктуры;

● Процесс усовершенствования;

● Процесс обучения.

Документирование кода.
Автоматизация документирования

Руководство пользователя

Типичное руководство пользователя содержит:

● Аннотацию, в которой приводится краткое изложение содержимого документа и его назначение

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

● Страницу содержания

● Главы, описывающие, как использовать, по крайней мере, наиболее важные функции системы

● Глава, описывающая возможные проблемы и пути их решения

● Часто задаваемые вопросы и ответы на них

● Где ещё найти информацию по предмету, контактная информация

● Глоссарий и, в больших документах, предметный указатель.

Общая структура руководства пользователя приведена в следующей таблице, а титульный лис – на рис. 11.

Рис. 11

Содержание Руководства пользователя

• Титульная страница

• Предисловие

• Содержание

• Введение

• Требования к системе

• Подготовка к запуску

• Знакомство с системой

• Основные бизнес-процессы

• Печать документов

• Экспорт / Импорт данных

• Системные сообщения

• Справочники

• Глоссарий

• Предметный указатель

· Форма сообщения об ошибке, отзыве.

Руководство администратора включает в себя слуедующие разделы.

• Титульная страница

• Предисловие

• Содержание

• Введение

• Требования к системе

• Автоматическая установка системы

• Ручная установка системы

• Подготовка к запуску

• Знакомство с системой ADMIN GUIDE

• Конфигурирование системы

• Разграничение прав доступа к системе

• Обслуживание системы / регламентные работы / аудит

• Архивирование системы

• Восстановление после сбоев

• Системные сообщения

• Экспорт / импорт данных

• Справочники

• Глоссарий

• Предметный указатель

• Форма для сообщения об ошибке, отзыве

Документирование кода предполагает использование следующих составляющих.

1. Схем алгоритмов

2. Псевдокода

3. Самодокументирования

Самодокументирование – это комментарии в тексте программы.

Стандартизация и самодокументирование кода имеет следующие положительные моменты:

● Программисты могут прочитать код и легко в нем разобраться;

● Новые программисты быстрее вписываются в проект;

● Новые люди избавлены от необходимости разрабатывать свой стиль и отстаивать его;

● Позволяет избегать типичных ошибок «новичков».

Отрицательные моменты:

● Стандарты – никому не нужный мусор;

● Стандарт – это не то, что я хочу;

● Стандарты понижают творчество;

● Все равно люди не следуют стандартам.

Верификация кода

Под верифика́цией (от лат. verus — «истинный» и facere — «делать») могут подразумеваться разные понятия, например:

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

· подтверждение соответствия конечного продукта предопределённым эталонным требованиям

Мы будем ориентироваться на первое определение.

Методики и мероприятия верификации программного кода:

● статический анализ;

● метрики.

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

Инструменты анализа

Класс инструментов, предназначенный для вычисления метрик программного обеспечения, называют Software Estimation. Наиболее рапсространенными пакетами являются следующие.

«Locmetrics» – очень простой бесплатный продукт с минималистским интерфейсом. В числе поддерживаемых языков – C/C++, C#, Java, SQL – возможно вычисление не только метрики SLOC и ее разновидностей, но и цикломатической сложности.

«USC Codecount» – бесплатный продукт с открытыми исходными кодами на языке ANSI C, разработанный Университетом Южной Калифорнии (University of Southern California, USC) – той же организацией, в которой были созданы COCOMO/COCOMO II. Является официальным инструментом для подсчета метрики SLOC при использовании указанных моделей. В число поддерживаемых языков входят C/C++, C#, Java, JavaScript, SQL, Perl, XML. Методика расчета соответствует принятой SEI для моделей CMM/CMMI. Вычисляет количество логических и физических SLOC, пустых строк, комментариев, директив компилятора, описаний данных, исполняемых инструкций по файлам проекта по отдельности и суммарно.

«Code Counter Pro» – коммерческий продукт ($25 за одну лицензию). В отличие от предыдущих имеет развитый графический интерфейс. Поддерживаются следующие языки программирования: Java, JSP, C/C++, VB, PHP, HTML, Delphi/Pascal, ASM, XML, COBOL. Несмотря на то, что программа хорошо справляется со своей задачей и даже позволяет строить детальные отчеты, чего не может предложить, скажем, Locmetrics, она уступает рассмотренным открытым аналогам по количеству вычисляемых показателей (только число физических строк кода, комментариев, пустых строк, а также суммарные значения).

«Verisoft Complexity Measures Tool» – коммерческий продукт (1200 евро). Поддерживаются только языки C/C++ и Java. Рассчитывает следующие метрики: SLOC, цикломатическую сложность, метрики Холстеда, индекс сопровождаемости (вычисляется на основе предыдущих). Имеет графический интерфейс (с возможностью работы в режиме командной строки), позволяет формировать отчеты в текстовой форме или HTML.

«Eclipse Metrics Plugin» – представляет собой подключаемый модуль для популярной IDE Eclipse. Eclipse – свободно распространяемая среда программирования для языка Java, разработанная компанией IBM. Вычисляет SLOC, количественные метрики классов, цикломатическую сложность, метрики сложности классов (LOCOM1, LOCOM2, LOCOM3, WMPC, NORM, индекс специализации), метрики связности, уровень абстракции и некоторые другие. Достаточно функциональный продукт, который вполне может дать фору многим коммерческим аналогам.

Из рассматриваемых инструментов наиболее универсальным средством является «SLOCCount» – бесплатный продукт, разработанный Дэвидом Вилером (David A. Wheeler), поставляется в виде исходных кодов на языке C по лицензии GNU GPL. В число поддерживаемых языков входят Ada, Assembler, awk, Bourne shell (включая производные: bash, ksh, zsh, pdksh), C, C++, C#, C shell (включая tcsh), COBOL, Expect, Fortran (включая Fortran 90), Haskell, Java, lex (включая flex), LISP (включая Scheme), make-файлы.

Существуют инструменты улучшения прогаммного кода, например.

Beautifier — инструмент для создания «красивого» кода. Приводят исходный код к определенному оформлению. При этом логика кода не меняется.

CASE средства для UML

●IBM Rational Rose (рис. 12)

●Microsoft Visio 2003 и выше

●Umbrello, Dia (рис. 13)

●Visual Paradigm for UML (рис. 14)

●StarUML (рис. 15),

· ArgoUML (рис. 16).

Рис. 12

Рис. 13

Рис. 14

Рис. 15

Рис. 16

Организация работы

Важную роль играет организация рабочего места программиста (Рис. 17) и профилактика заболеваний.

Рис. 17

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

Среды конструирования программных систем

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

Среда проектирования

● Текстовые редакторы;

● Среды визуального моделирования;

● Системы генерации документации;

● Системы сбора и учета требований.

Среда разработки

● Инструменты для написания кода;

● Инструменты для проверки корректности кода;

● Инструменты для компиляции кода;

● Механизмы сборки кода;

● Механизмы выполнения кода;

● Механизмы генерации кода;

● VCS.

Среда тестирования

● Системы для модульного тестирования;

● Системы для интеграционного тестирования;

● Системы для системного тестирования.

Среда выполнения

● Системы резервирования данных;

● Виртуальные среды;

● Облачные среды.

Среда сопровождения

● Информационные системы;

● Базы знаний;

● Часто задаваемые вопросы (FAQ);

● Механизмы обновления;

● Системы учета ошибок;

● Системы сбора запросов на сопровождение;

● CRM.

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

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

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

● SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;

● DFD (Data Flow Diagrams) диаграммы потоков данных;

● ERD (Entity-Relationship Diagrams) диаграммы "сущность- связь".

SADT

Методология SADT разработана Дугласом Россом. На ее основе разработана, в частности, известная методология IDEF0 (Icam DEFinition), которая является основной частью программы ICAM (Интеграция компьютерных и промышленных технологий), проводимой по инициативе ВВС США. Основным элементом диаграммы является функция, общий вид которой приведен не рис. 18.

Рис. 18

DFD

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

При разработке DFD-диаграмм может выполняться постепенное уточнение функций, как при структурном программировании (см. уровни ПДД0 и ПДД1 на рисунке 19).

Рис. 19

Связи и переходы изображаются стрелками, как показано в следующей таблице и на рисунке 20.

Рис. 20

Пример Диаграммы потоков данных приведен на рис. 21.

Рис. 21

Метод структурного проектирования

Метод может быть проиллюстрирован диаграммой рис. 22 и 23.

Рис. 22

Рис. 23

Результат преобразования диаграммы рис. 23 показан на рис. 24.

Рис. 24

Компонентный подход. Модульность
Сложность системы

Компонентно-ориентированная модель реализуется по принципу, представленному на рисунке 25. Она широко использует программные модули.

Рис. 25

Зависимость стоимости системы от количества модулей может быть представлена диаграммой рис. 26.

Рис. 26

При реализации модульных систем применяется принцип информационной закрытости. Содержание (процедуры, данные) модулей должно быть скрыто друг от друга. Это означает следующее: все модули независимы, обмениваются только той информацией, которая необходима для работы. Доступ к операциям и структурам модуля ограничен. Достоинства такого подхода - возможность работы разных команд и простая модификация системы. Идеальный модуль – «черный ящик».

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

Существует 7 типов связности:

1. По совпадению (CC=0)

2.Логическая (CC=1)

3.Временная (CC=3)

4.Процедурная (CC=5) – рис. 27

5.Коммуникативная (Информационная) (CC=7) – рис. 28

6.Последовательная (CC=9) – рис. 29

7.Функциональная связность (CC=10) – рис. 30.

Рис. 27

Рис. 28

Рис. 2

Рис. 30

Характеристики мер связности модулей приведены в таблице.

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

Сцепление может быть следующих типов:

1) По данным (рис. 31);

2) По образцу (рис. 32);

3) По управлению (рис. 33);

4) По общей области (рис. 34);

5) По содержимому (рис. 35).

Рис. 31

Рис. 32

Рис. 33

Рис. 34

Рис. 3

Характеристики иерархической структуры программы – высота и ширина. Высота равна количеству уровней иерархии (на рис. 36 их 3), а ширина определяется по формуле, приведенной ниже.

Рис. 36

Сложность программной системы

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

1) Отображает управляющую структуру;

2) Узлы (вершины) графа = линейным участка;

3) Дуги = поток управления;

4) Узлы могут быть операторные и предикатные;

5) Предикатный узел = простое условие;

6) Регионы – отдельные подграфы;

7) Окружающая среда.

Условный оператор на графе отображается как показано на рис. 37.

Рис. 37

Условие с операцией Or представляется графом рис. 38.

Рис. 38

Наиболее часто используется понятие цикломатической сложности, которая определяет:

● Количество независимых путей в базовом множестве алгоритма;

● Верхнюю оценку количества тестов, которая гарантирует однократное выполнение всех операторов.

Все независимые пути образуют базовое множество. Для графа рис. 38 таких путей 3 (см. рис. 39)..

Рис. 39

Способы расчета:

1. Количество регионов потокового графа;

2. V(G)=E-N+2, где E — кол-во дуг, N — кол-во узлов;

3. V(G)=p+1, где p — кол-во предикатных узлов.

Автоматизация сборки

Работа с проектом состоит из следующих этапов.

● Создать каталог / структуру каталогов

● Создать файл / множество файлов

● Написать код

● Проверить его

● Откомпилировать код

● Запустить и проверить модуль / систему

● Собрать модули в исполняемые файлы

● Создать дистрибутив.

Для сборки используются скрипты

● В Windows

– BAT (Batch, DOS)

– CMD (Command, Windows NT)

– PowerShell (Windows 2003)

● В Linux / Unix

– sh

– bash и т.п.

Пример BAT файла приведен на рис. 40.

Рис. 40

PowerShell исполбзует Командлеты (англ. cmdlets) — это специализированные команды, которые реализуют различную функциональность. Они именуются по правилу Глагол-Существительное, например Get-ChildItem, благодаря чему их назначение понятно из названия. Командлеты выводят результаты в виде объектов или их коллекций. Дополнительно они могут получать входные данные в такой же форме и, соответственно, использоваться как получатели в конвейере. Хотя PowerShell позволяет передавать по конвейеру массивы и другие коллекции, командлеты всегда обрабатывают объекты поочередно. Для коллекции объектов обработчик командлета вызывается для каждого объекта в коллекции по очереди.

В PowerShell, как и в оболочках UNIX/Linux, присутствует конвейер. Он служит для передачи выходных данных одного командлета во входные данные другого. PowerShell включает язык сценариев с динамическими типами, на котором можно реализовывать сложные операции с использованием командлетов. Язык сценариев поддерживает переменные, функции, конструкции ветвления (if-then-else) циклы (while, do, for и foreach), структурированную обработку ошибок и множество других возможностей, включая интеграцию с.NET.

Ant

Apache Ant (англ. ant — муравей и акроним — «Another Neat Tool») — утилита для автоматизации процесса сборки программного продукта. Является платформонезависимой аналогом Ant был создан в рамках проекта Jakarta. Это — самостоятельный проект первого уровня Apache Software Foundation. Первая версия была разработана инженером Sun Microsystems Джеймсом Дэвидсоном (James Davidson).

Управление процессом сборки происходит посредством XML- сценария, также называемого Build-файлом. В первую очередь, этот файл содержит определение проекта, состоящего из отдельных целей (Targets). Цели сравнимы с процедурами в языках программирования и содержат вызовы команд-заданий (Tasks). Каждое задание представляет собой неделимую, атомарную команду, выполняющую некоторое элементарное действие. Между целями могут быть определены зависимости — каждая цель выполняется только после того, как выполнены все цели, от которых она зависит (если они уже были выполнены ранее, повторное выполнение не производится). Типичными примерами целей являются clean (удаление промежуточных файлов), compile (компиляция всех классов), deploy (развёртывание приложения на сервере). Конкретный набор целей и их взаимосвязи зависят от специфики проекта.

Краткий список заданий (команд).

Javac компиляция Java-кода

Copy копирование файлов

Delete удаление файлов и директорий

Move перемещение файлов и директорий

Replace замещение фрагментов текста в файлах

JUnit автоматический запуск юнит-тестов

Exec выполнение внешней команды

Zip создание архива в формате Zip

CVS выполнение CVS-команды

Mail отправка электронной почты

Xslt наложение XSLT-преобразования.

Пример простого сценария сборки приведен ниже.

Первая строка содержит общую информацию о собираемом проекте.

Самые важные атрибуты элемента project это default (по умолчанию) и basedir (базовая директория). Атрибут default указывает на target (задание), определенное для выполнения по умолчанию.

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

% ant -buildfile simple.xml init

Запустив такую команду, обработчик Ant'а выполнит только задание (target) с атрибутом name, которого равно init. Итак, в нашем примере заданием по умолчанию является deploy. Следующий пример команды запуска Ant выполнит именно задание указанное по умолчанию, так как нет указания в командной строке на какое-либо конкретное задание:

% ant -buildfile simple.xml

В общем случае элемент target содержит пять атрибутов: name, if, unless, depends и description. Обязательным атрибутом является name, когда как остальные — необязательные.

Указывая значение атрибута depends, вы можете указать Ant'у, что данное задание зависит от других заданий и не может быть выполнено пока не выполнятся все задания из указанных в атрибуте. В приведенном выше примере, задание clean не запустится до тех пор, пока не завершится задание init. Атрибут depends может включать несколько значений имен заданий через запятую, тем самым указывая, что зависит от нескольких заданий. Атрибуты if и unless дают вам возможность указать задания, которые выполнятся если указанное свойство установлено (в случае if) или наоборот, в случае unless не установлено. Вы можете использовать команду available для установки свойств, как показано в следующем примере, либо в командной строке.

<available classname="org.whatever.Myclass"

property="Myclass.present"/>

Задание init из нашего примера содержит установку четырех свойств вида:

Очень часто property (свойствам) присваивают часто используемые директории или файлы. Атрибуты элемента property это пары name(имя) и value(значение). Установка свойств позволит логически подвязать необходимые директории или файлы вместо их прямого использования. Если нужно сослаться на свойство с именем sourceDir где-либо позднее в файле, вы можете использовать следующий синтаксис, указывающий Ant'у подставить соответствующее значение установленное в элементе property ранее: ${sourceDir}. Пример:

<javac srcdir="${src.dir}"

destdir="${build.classes}"

classpath="${classpath}"

debug="on"

deprecation="off"

optimize="on">

<exclude name="**/Script.java"

unless="bsf.present" />

< /javac>

Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями: