Инструментальные средства разработки программных агентов формируют среду, которая оптимизирована для выпуска определенного типа приложений, со специфической архитектурой.
Основным отличаем инструментальных сред от других средств построения программных агентов является то, что среда обеспечивает полный цикл разработки программных агентов, включая этапы анализа предметной области, этапы проектирования, разработки, верификации, а так же этапы развертывания и сопровождения.
Можно выделить наиболее известные и популярные среды разработки агентов:
АВЕ (Agent Building Environment);
Рассмотрим более подробно перечисленные инструментальные среды разработки программных агентов.
1. Инструментальная среда AgentBuilder предоставляет для разработчиков средства разработки и среду выполнения агентного приложения. Технология создания интеллектуального агента в среде AgentBuilder представлен на рисунке 2.1.
Рис. 2.1
Средства разработки и среда выполнения написаны на языке программирования Java, что позволяет им работать на всех платформах, где установлена Java среда. Агент, созданный с помощью инструментария AgentBuilder, может выполняться на любой платформе с виртуальной машиной Java (версии 1.1 и выше).
Средства разработки представляют собой удобный графический интерфейс для анализа предметной области разрабатываемой МАС и спецификации желаемого поведения агентов, разрабатываемых при помощи графических редакторов. В данной инструментальной среде предусмотрены следующие этапы построения многоагентного приложения:
определение состава агентства;
создание агентов, которое предусматривает построение онтологии, используемой для выполнения делегированных агенту полномочий, и ментальной модели (убеждения, способности, обязательства, правила поведения);
создание протоколов для спецификации взаимодействия агентов данного агентства;
генерация специального файла описания агента на языке RADL, который, в конечном итоге, представляет ментальную модель и желаемое поведение агента.
Среда выполнения агентного приложения состоит из агентной программы и процессора выполнения агента. Процессор использует эффективные процедуры логического вывода путём сопоставления правил поведения агента с убеждениями агента, определяемыми текущей ментальной моделью, и входящими сообщениями. На основе проводимых рассуждений процессор выполняет определенные действия, связанные с полномочиями агента. Агентная программа представляет собой определение агента в виде файла на языке RADL вместе с укомплектованной библиотекой классов проекта. Агентная программа совместно с процессором образуют выполняемого агента. При запуске среды выполнения, инициализируется процессор агента, который использует RADL-модель и онтологию агента, представленную в виде библиотеки классов проекта (Project Accessories Library). Для этого необходимы определение агента (файл RADL, который обеспечивает агента способностью рассуждения и начальной ментальной моделью) и библиотека классов проекта (вспомогательные классы проекта PACs из библиотеки классов проекта) - эти объекты используются для отображения предметной области задачи.
2. В среде Bee-gent разработка агентно-ориентированных приложений выполняется по методологии спецификации поведения агентов распределенной системы с использованием МАС - библиотеки, реализованной на языке Java. На основе предлагаемых системой Bee-gent графических средств, возможна чёткая структуризация поведения каждого агента в виде графа состояний и определение протоколов взаимодействий агентов. Графы состояний агентов строятся на основании жизнеспособности ролей, определенных в виде регулярных выражений на этапе агентно-ориентированного анализа (например, по методологии Gaia). Пример фрагмента графа поведения агента Студент обучающей системы показан на рисунке 2.2.
Рис. 2.2
Граф состояний регистрирует все имена состояний, в которых агент может находиться. На следующем шаге разработки определяются классы для каждого состояния. Каждое состояние в графе является экземпляром класса AwrIPState из агентной библиотеки фирмы Toshiba, реализованной на языке Java. В конструкторе класса определяются пред и пост условия, т.е. условия, которые должны быть выполнены агентом в текущем состоянии для того, чтобы выполнить действия, определенные классом состояния, и определить переход в следующее состояние. Затем специфицируются действия, которые должны быть выполнены в каждом состоянии (включая собственные процессы агента и взаимодействия с другими агентами). Для начального и конечного состояний также создаются классы "INIT" и "END". Если агент взаимодействует с другими агентами, то при спецификации отдельных состояний система Bee-gent предусматривает определение протокола взаимодействия. Протокол должен отражать все линии поведения агента в данном состоянии. В каждом состоянии деятельность агента направлена на выполнение протоколов взаимодействия с целью реализации планируемой линии поведения. Деятельность каждого агента в МАС определяется, например, моделью услуг, разработанной на этапе агентно- ориентированного анализа по методологии Gaia.
Каждая линия поведения документируется диаграммой взаимодействия агентов с указанием содержимого сообщений и их очередности. На рисунке 2.3 приведен пример диаграммы взаимодействия для состояния "Изучение дисциплины" агента Студент. Формат сообщений определяется языком XML/ACL, который является развитием языка коммуникации KQML.
Рис. 2.3 Диаграмма взаимодействия агента Студент в состоянии "Изучение дисциплины"
Таким образом, на основе разработанных логических моделей, система Bee-gent автоматически генерирует на языке Java скелет программного кода многоагентной системы, который дополнятся необходимым программным кодом, обеспечивающим заданный "жизненный цикл" агентов. В системе Bee-gent, в отличие от AgentBuilder, при описании поведения агентов не используются правила, определяющие реакцию агента на внешние события и его внутреннее состояние.
3. JACK TM Intelligent Agents (JACK) представляет собой агентно-ориентированную среду разработки, которая построена на основе языка программирования Java. JACK является надстройкой Java в виде расширения синтаксиса Java конструкциями для программной реализации свойств, связанных с понятием интеллектуального агента. Язык программирования агентов JACK предлагает следующие возможности:
определяет новые основные классы, интерфейсы и методы;
расширяет синтаксис Java для поддержки новых агентно-ориентированных классов, определений и операторов;
предоставляет расширения семантики (особенности при выполнении) для поддержки модели выполнения, требуемой агентно-ориентированной программной системой.
Все расширения языка реализованы как plug-in, что делает язык максимально расширяемым и гибким в агентно-ориентированном программировании.
На уровне классов введены 5 главных конструкций:
агент, который в JACK моделирует интеллектуальные сущности;
способность, которая собирает в одно целое функциональные компоненты (события, планы, множество убеждений и др. способности), для использования их агентами;
событие, для моделирования ситуаций и сообщений, на которые агент должен быть способен ответить;
план, который предназначен для моделирования процедурного описания того, как агент управляет данным событием (все предпринимаемые агентом действия заранее предусмотрены и описаны в его планах);
множество убеждений, для моделирования знаний агента в виде убеждений, которые придерживаются семантики закрытого или открытого мира. Данная конструкция представляет убеждения агента в виде реляционных кортежей первого порядка и обеспечивает их логическую непротиворечивость.
Следует отметить, что желаемое поведение агента инкапсулируется в модульных единицах, определяемых этими классами, а классы содержат все требуемые для независимого выполнения структуры и методы, которые программисты на языке JACK могут использовать. Для установления отношений между упомянутыми выше классами существует набор деклараций.
Для установления отношений между упомянутыми выше классами предоставлен набор деклараций. Ниже приведен фрагмент кода для реализации конструкции плана, написанного на JACK (элементы синтаксиса, которые принадлежат JACK, выделены жирным шрифтом):
plan MovementResponse extends Plan {
#handles event RobotMoveEvent moveresponse;
#uses agent implementing RobotInterface robot;
static boolean relevant (RobotMoveEvent ev)
context() { … }
#reasoning method
В этом примере определяемый план действий программного агента наследует свои основные выполняемые функции от класса JACKPlan. Кроме того, с помощью нескольких деклараций для планов языка JACK указывается, каким образом план будет использоваться. Каждая декларации предваряется символом "#" для того, чтобы отличить их от элементов синтаксиса Java. Декларация #handles event определяет цель или событие, на которое этот план отвечает. Декларация #uses agent implementing закрепляет агента(ов), которые могут использовать этот план. План в примере могут выполнять только те агенты, которые реализуют указанный интерфейс (RobotInterface). В фигурных скобках содержится обычный код Java.
Помимо деклараций язык JACK для описания рассуждений и поведения, предпринимаемых агентом при выполнении плана, предоставляет свои операторы методов рассуждения, которые выделяются предшествующим символом "@".
Для поддержки выполнения агентно-ориентированной программной системы JACK предоставляет следующие дополнительные языковые расширения, обеспечивающие следующую семантику:
Многопоточность встроена в ядро и выведена из-под контроля программиста.
Работа агентов осуществляется таким образом, что агенты обрабатывают множество планов и имеют доступ к описаниям убеждений. Агенты выполняют планы в задачах управления событиями, когда они возникают, сравнивая свои убеждения, когда необходимо. Эти планы могут инициировать подзадачи, которые в свою очередь могут инициировать свои подзадачи, если агент требует трудоемкий и сложный ответ.
Введена новая структура данных, названная логический элемент (logical member), значение которого зависит от результата запроса к множеству убеждений агента.
Возможность выполнение запросов к множеству убеждений агента, используя для этого логические элементы, посредством их объединения для получения желаемого результата. Если запрос имеет успех, то логический элемент содержит желаемое значение.
Компонент среды разработки JACK (JACK Development Environment) дает возможность рисования обзорных диаграмм, по которым среда генерирует скелет программного кода и следит за тем, чтобы изменения, произведенные в коде, отображались и на диаграммах.
Агенты, создаваемые в JACK, имеют архитектуру, присущую интеллектуальным агентам. Таким образом, возможно моделирование разумного поведения, в соответствии с теоретической моделью BDI- архитектуры агента , основанной на убеждениях, желаниях и намерениях.
Согласно BDI-архитектуре, интеллектуальные агенты JACK - это автономные программные компоненты, которые могут проявлять разумное поведение на основе проактивности (целенаправленность) и реактивности (направляемое событиями) на входные сигналы. Каждый такой агент имеет:
убеждения (это его набор данных о мире);
желания (набор событий на которые он будет реагировать и набор целей, достижения которых он может желать);
намерения (набор планов, которые описывают как он может управлять возникающими целями и планами).
Если агента рассматривать как аналог личности, то набор планов описывает шаги, которые агент должен выполнить при возникновении определенного события или желании достичь определенного результата. На первый взгляд, поведение агента может показаться похожим на действия экспертных систем, со всеми присущими им ограничениями. Однако, принципиальное отличие агентно-ориентированных систем в том, что агенты можно программировать для выполнения планов точно так же, как действовала бы разумная личность. В частности, с помощью агентов можно реализовать следующие свойства, ассоциирующиеся с разумным поведением:
устойчивую целенаправленность - агенты сосредоточены на целях, а не на выбранных методах для их достижения;
контекстную зависимость в реальном времени - агенты будут следить за вариантами, которые применимы в каждый момент времени и принимать решения относительно последующих действий, на основе имеющихся условий;
утверждение правильности подхода в реальном времени - агент будет гарантировать, что он следует выбранному курсу действий до тех пор, пока определенные условия продолжают быть истинными;
одновременность - агентная система является многопоточной. Если возникают новые цели и события, то агент способен определить приоритеты по требованию многозадачности.
JACK приложение представляет собой исходный код, реализующий характерные для агентно-ориентированного подхода понятия: агентов, способностей, события, планы, убеждения, view (запросы), а также Java класс с функцией main(), которая является точкой входа для виртуальной машины Java, и любые другие Java необходимые файлы. Файлы, которые создаются для этих понятий, должны иметь такое же имя, как и у объекта, определяемого в файле. Они имеют расширение, определяющее тип JACK понятия. Компилятор агентов JACK конвертирует исходные файлы на языке агентов JACK в код на языке Java, который затем компилируется в код виртуальной машины Java для выполнения на целевой системе.
4. Программная среда JADE (Java Agent Development Framework) получила широкое применение для разработки многоагентных систем. Она полностью реализованная на языке Java и поддерживает FIPA - стандарты для создания интеллектуальных агентов. Цель создания среды JADE - упростить процесс разработки посредством стандартизации способов взаимодействия агентов во всеоохватывающей среде системных сервисов.
Для достижения этой цели JADE предлагает програмисту-разработчику агентных систем следующие возможности:
агентную платформу FIPA-compliant Agent Platform, основанную на FIPA и включающую обязательные типы системных агентов для управления, во-первых, агентной платформой (AMS), во- вторых, каналом коммуникации (ACC) и службы каталогов (DF) (эти типы агентов автоматически активируются при запуске платформы);
распределенную агентную платформу Distributed Agent Platform, которая может использовать несколько хостов, при чем на каждом узле запускается только одна Java Virtual Machine. Агенты выполняются как Java- потоки. В зависимости от местонахождения агента, посылающего сообщение, и того, кто его получает, для доставки сообщений используется соответствующий транспортный механизм.
Multiple Domains support - ряд основанных на FIPA DF-агентов могут объединится в федерацию, таким образом реализуя мультидоменную агентную среду.
Multithreaded execution environment with twolevel scheduling. Каждый JADE-агент имеет собственный поток управления, но он также способен работать в многопотоковом режиме. Java Virtual Machinе проводит планирование задач, исполняемых агентами или одним из них.
Object-оriented programming environment. Большинство концепций, свойственных FIPA- спецификации, представляются Java-классами, формирующими интерфейс пользователя.
Library of interaction protocols. Используются стандартные интерактивные протоколы fipa request и fipa-contract-net. Для того, чтобы создать агента, который мог бы действовать согласно таким протоколам, разработчикам прикладных программ нужно только имплементировать специфические доменные действия, в то время как вся независимая от прикладной программы протокольная логика будет осуществляться системой JADE.
Administration GUI. Простые операции управления платформой могут исполняться через графический интерфейс, отображающий активных агентов и контейнеры агентов. Используя GUI, администраторы платформы могут создавать, уничтожать, прерывать и возобновлять действия агентов, создавать иерархии доменов и мультиагентные федерации DF (фасилитаторов).
JADE базируется на технологиях Java RMI, Java CORBA IDL, Java Serialization и Java Reflection API. Разработка МАС в этой среде упрощается благодаря использованию FIPA-спецификаций и ряда инструментов поддержки фазы отладки и развертывания системы. Эта агентная платформа может устанавливаться на компьютерах с разными операционными системами, и ее можно конфигурировать через удаленный GUI-интерфейс. Процесс конфигурирования этой платформы достаточно гибкий: ее можно изменить даже во время исполнения программ, посредством перемещения агентов с одной машины на другую. Единственным требованием для работы системы является установка на машине Java Run Time 1.2.
Каждый запущенный экземпляр среды JADE является контейнером, т.к. может содержать несколько агентов. Группа активных контейнеров образуют платформу. Главный контейнер всегда должен быть активен, а все другие контейнеры должны быть зарегистрированы им при их создании. Поэтому, первый контейнер, запущенный на платформе является основным контейнером, а все остальные - обычными контейнерами и должны получить указания о том, где находится их основной контейнер, на котором они должны быть зарегистрированы. Если в сети запускается еще один основной контейнер, то он представляет собой другую платформу, на которой новые обычные контейнеры имеют возможность зарегистрироваться. На рисунок 2.4 показаны приведенные выше концепции платформы и контейнера и показывает сценарий с двумя JADE платформами, состоящими из трёх и одного контейнера соответственно.
Рис. 2.4 Среда "существования" агентов JADE
JADE агенты должны иметь уникальные имена, знать имена друг друга и, благодаря этому, они могут общаться напрямую, независимо от их фактического местонахождения, т.е. внутри одного контейнера (например, агенты A2 и A3), в различных контейнерах внутри одной платформы (например, A1 и A2) или в различных платформах (например, A4 и A5). Основной контейнер отличается от обычных тем, что содержит систему управления агентами и маршрутизатор, которые автоматически запускаются при запуске основного контейнера. Система управления агентами AMS (Agent Management System), представляет собой "власть" в платформе (создание / удаление агентов в удаленных контейнерах, запрашиваемых через AMS) и обеспечивает службу именования агентов. Маршрутизатор каталогов DF (Directory facilitator), который обеспечивает сервис "Жёлтых страниц", помогает найти агенту других агентов, для получения от них необходимых услуг, необходимых ему для достижения своих целей.
Для осуществления коммуникации архитектура среды предоставляет гибкий и эффективный процесс обмена сообщениями, в котором JADE создает очередь и управляет потоком ACL-сообщений, являющихся приватными для каждого агента. Агенты способны обращаться к очереди с помощью комбинации нескольких режимов своей работы: блокирование, голосование, перерыв в работе и сопоставление с эталоном (если это касается методов поиска). инструментарий платформа мультиагентный
В последних версиях системы используется Java RMI, event-notification и IIOP. Однако, можно легко добавить и другие протоколы. Также предусмотрена возможность интеграции SMTP, HTTP и WAP. Большинство коммуникационных протоколов, которые уже определены международным сообществом разработчиков агентных сред, доступны и могут иллюстрироваться на конкретных примерах после определения поведения системы и ее основных состояний. Вместе с поддержкой определенных пользователем контентных языков, реализованы онтологии управления агентами, а также онтологии, которые могут быть реализованы и зарегистрированы агентами и использованы системой. С целью существенного расширения работоспособности JADE, предусмотрена возможность интеграции с JESS и Java-оболочкой CLIPS.
Сравнительный анализ возможностей рассматриваемых инструментальных сред для разработки программных агентов приводится в таблице 4. А на рисунке 2.5 приведены результаты данного анализа.
Таблица 4
Сравнительный анализ возможностей инструментальных сред для разработки программных агентов
|
Возможности инструментальных сред |
||||
|
Средства построения агентств |
||||
|
Средства управления проектом |
||||
|
Графическая среда для определения спецификаций агентов |
||||
|
Механизм контроля целостности |
||||
|
Средства построения онтологии |
||||
|
Библиотека для разработки МАС |
||||
|
Механизм рассуждений агента о своих способностях и способностях других агентов |
||||
|
Формальный язык коммуникации |
||||
|
Средства отладки взаимодействия агентов |
||||
|
Механизм поиска агентов с заданными способностями |
||||
Рис. 2.5
На основании сравнения характеристик рассмотренных инструментальных сред можно сделать вывод о том, что наиболее мощными и гибкими технологиями реализации понятия "агент", являются подходы, предложенные инструментарием AgentBuilder и средой JACK.
Необходимо обратить внимание на то, что для платформы JADE существует дополнительное BDI расширение - среда Jadex. Эта среда предусматривает гибридную реактивно-делиберативную архитектуру, в которой агент рассматривается как "черный ящик", принимающий и отправляющий сообщения. Основываясь на результатах обработки сообщений, внутренних и внешних событий, делиберативный механизм принимает решения о переходе к новому плану действий или продолжению старого. Действующий план может посылать сообщения другим агентам, изменять базу убеждений, формировать новые цели и вызывать внутренние события. Система использует библиотеку планов, которые обрабатываются как Java-классы.
Одним из главных преимуществ разработки интеллектуальных агентов на платформе Jadex является то, что не требуется изучения новых языков программирования. Вместо этого агенты кодируются на базе объектно-ориентированного программирования в интегрированной среде разработки (IDEs), типа Eclipse и Intellij IDEA.
Еще одним важным аспектом является независимость связующего программного обеспечения, поскольку Jadex независимо с его модулями может использоваться в совершенно других сценариях на верхнем уровне платформы. Ориентированные на агента программы добавляют явные свойства автономных действующих элементов, которые принимают участие в процессе принятия решений, к пассивных объектам. В этом отношении агенты предоставляют активные компоненты с индивидуальными возможностями взаимодействия с компонентами.
Jadex разработан как самостоятельный механизм принятия решений, адаптированные для работы с любыми связующими системами, которые выполняют взаимодействие с агентом относительно его собственного управления и получения сообщений.
Агент может свободно мигрировать между хостами, выполняя операции, как на серверной стороне, так и на стороне пользователя, сохраняя при этом независимость от места выполнения поставленных задач.
Проведенный анализ наиболее известных инструментальных систем позволил выбрать эффективную и доступную среду Jadex.
Настоящая статья посвящена технологиям разработки приложений и тенденциям их развития в условиях перехода большинства отечественных и зарубежных компаний от стихийной автоматизации отдельных областей их деятельности к единым интегрированным решениям.
Разработка приложений в современных ИТ-проектах
Современный период развития средств автоматизации и информатизации отечественных предприятий можно охарактеризовать как время массового перехода от стихийной автоматизации отдельных областей деятельности компаний к единым интегрированным решениям, охватывающим все аспекты их существования. Это не могло не отразиться на составе и объеме наиболее часто выполняющихся ИТ-проектов и на методах их выполнения.
Особенности современных ИТ-проектов
Если еще пять-семь лет назад были широко распространены проекты, связанные с заказной разработкой уникальных приложений (и несколько реже - решений на основе готовых компонентов, предназначенных для конкретной предметной области) и выполняемые силами эрудированных программистов широкого профиля, владеющих и смежными специальностями (например, умеющих администрировать локальные сети и СУБД), то сегодня в первую очередь заказываются проекты внедрения готовых бизнес-приложений и ERP-систем, в рамках которых нередко выполняются проекты по разработке решений на базе все тех же готовых бизнес-приложений. Причиной этого является, с одной стороны, осознание руководителями большинства компаний того факта, что, как бы их компания ни претендовала на уникальность в своей маркетинговой стратегии, по существу и ее производство, и отдельные аспекты ее деятельности являются вполне типовыми, а с другой стороны - осознание производителями бизнес-приложений неуникальности бизнес-процессов большинства компаний и создание ими широкого спектра типовых решений с одновременным предоставлением услуг по их внедрению, сопровождению и обновлению своими силами или силами партнеров.
Переход к разделению труда в проектах по разработке ПО
Подобная ситуация не могла не отразиться на кадровом составе ИТ-компаний, среди которых в последнее время преобладают системные интеграторы (иногда имеющие свой отдел разработки, но специализирующиеся в основном на комплексных проектах, включающих не только разработку приложений), а компаний, специализирующихся исключительно на разработке приложений, немного. В последних полным ходом идет процесс специализации, разделившей группу разработчиков на бизнес-аналитиков, системных аналитиков, программистов, технических писателей и руководителей проектов. При этом нередко системный аналитик не умеет программировать, бизнес-аналитик не руководит проектами, а руководитель проекта занимается только организационной работой и не интересуется ни архитектурой приложения, ни тем более предметной областью. Это отражает факт перехода от малотиражного производства эксклюзивного программного обеспечения к массовому промышленному производству типовых решений, востребованных современными пользователями.
Изменение требований к приложениям
Говоря о проектах по разработке приложений и о связанных с разработкой приложений частях комплексных ИТ-проектов, следует заметить, что сегодня наиболее актуальным становится создание корпоративных решений на основе не только СУБД, но и других продуктов - офисных приложений, GIS- и CAD-систем, средств бизнес-анализа, специализированных серверных продуктов, систем управления предприятием и других бизнес-приложений. Требования к защищенности создаваемых решений также заметно отличаются от тех, что существовали еще три года назад. Наконец, одной из важных тенденций является рост интереса к приложениям для мобильных устройств и приложений, способных работать автономно и при необходимости синхронизироваться с информационной системой предприятия.
Из иных тенденций, проявившихся в последнее время в области разработки корпоративных решений, следует отметить растущую потребность компаний в средствах бизнес-анализа, входящих в состав имеющихся решений или существующих в виде отдельных инструментов. Несмотря на то что создание приложений с применением бизнес-аналитики затруднено из-за того, что сегодня вопросы стандартизации доступа к данным многомерных хранилищ и языка запросов к ним остаются актуальными, в руках разработчиков уже имеется достаточно средств решения подобных задач для наиболее популярных аналитических платформ как от поставщиков самих аналитических платформ (например, Oracle, Microsoft и Hyperion), так и от компаний, специализирующихся на инструментах анализа данных (Cognos, ProClarity и Business Objects). Кроме того, средства бизнес-анализа (Business Intelligence and Report Tools, BIRT) доступны и для платформы Eclipse, занимающей сейчас половину рынка средств разработки Java-приложений.
Вовлечение заказчика в процесс разработки
Оценка вклада разработчиков приложений в успех бизнеса компании-заказчика, равно как и оценка качества самого процесса разработки и его результата всегда являлась спорным вопросом и поводом для непонимания и конфликтов. Однако в последнее время появились методы оценки зрелости процессов разработки и рекомендации, основанные на модели Capability Maturity Model Integration (CMMI), а также ряд методологий разработки приложений, предоставляющий заказчику приложения возможность контролировать ход процесса разработки. Модель CMMI позволяет оценить и усовершенствовать процессы разработки приложений и воспользоваться удачными примерами постановки подобных процессов, и наличие оценки того или уровня зрелости согласно этой модели у компании-разработчика в известной мере является гарантией качества конечного результата процесса разработки продукта в этой компании.
Семейство методологий разработки приложений под общим названием Agile methodologies (включающее, в частности, методологию экстремального программирования, о которой мы писали несколько месяцев назад) предоставляет «рецепты» для ежедневного управления проектной командой, включая, наряду с прочими, принцип разработки, управляемой тестированием (Test-Driven Development, TDD), зарекомендовавший себя в качестве средства получения высококачественного кода. Особенностью данного семейства методологий является вовлеченность заказчика в процесс разработки с тем, чтобы он мог его контролировать на всех этапах.
Самые популярные архитектуры и платформы
Архитектура, ориентированная на сервисы
Одна из современных тенденций развития ИТ-инфраструктуры современных предприятий и архитектур корпоративных приложений - переход к архитектуре, ориентированной на сервисы (Service Oriented Architecture, SOA). Данная архитектура предполагает создание и внедрение распределенных приложений и служб, основанных на применении различных технологий, например веб-служб (так, подобные технологии широко поддерживаются платформой Eclipse и средствами разработки от Borland и Microsoft).
Наиболее популярные платформы
Одна из наиболее заметных тенденций последнего времени проявляется в унификации платформ, для которых создается большинство приложений, и выделении среди них двух лидеров - Windows/Microsoft .NET и Java/J2EE. Это во многом обусловлено способностью указанных платформ обеспечить возможность создания приложений, степень защиты данных в которых, равно как и возможности создания пользовательских интерфейсов и обеспечения доступа к сервисам и данным, отвечают современным требованиям. Впрочем, указанная тенденция уже давно ни для кого не нова.
Отметим также, что ввиду бурного роста интереса корпоративных заказчиков к разработкам для мобильных устройств средства разработки данной категории приложений и сами мобильные платформы становятся все более популярными среди разработчиков.
Рост популярности мобильных платформ
Сегодня мобильные приложения разрабатываются примерно для полутора десятков платформ. Согласно проведенному в конце прошлого года исследовательской компанией Evans Data Corp. опросу нескольких сотен разработчиков мобильных приложений, основными лидерами в этой области являются.NET Compact Framework и Java 2 Mobile Edition (J2ME), а также другие платформы Microsoft для мобильных устройств и Embedded Linux (рис. 1).
Рис. 1. Популярность мобильных платформ среди разработчиков (источник - Developers’ Choice Wireless Platforms. Definitive Rankings of Wireless Platform by Developers Worldwide - Evans Data Corp., September 2005)
Тем не менее, согласно тому же опросу, в плане удовлетворения разработчиков качеством инструментов и уровнем поддержки сообщества разработчиков первое место сейчас занимает платформа Nokia Series 60. По прогнозам той же Evans Data Corp., на рынке мобильных платформ ожидается рост доли Embedded Linux.
Что касается средств разработки приложений, для платформы Windows Mobile инструменты от Microsoft существуют уже в течение нескольких лет. Инструменты компании Borland доступны для платформ.NET Compact Framework, Symbian и J2ME. Кроме того, имеются некоторые инструменты разработки мобильных приложений компании Sybase, а также ряда других производителей.
Инструменты для разработчиков сегодня
Узкая специализация разработчиков привела к активному развитию в течение последних пяти лет так называемых средств поддержки жизненного цикла приложений, предназначенных для больших коллективов разработчиков. К подобным средствам относятся средства управления требованиями, моделирования бизнес-процессов, приложений и данных, тестирования и оптимизации приложений, управления коллективной работой, контроля версий, управления изменениями. Производят такие инструменты многие ведущие поставщики ПО: IBM, Computer Associates, Borland, Microsoft, Oracle и ряд других.
В последнее время пристальное внимание инструментам подобного назначения стали уделять многие компании, ранее специализировавшиеся на создании сред разработки (в частности, IBM, Computer Associates, Borland, Microsoft, Oracle и Sybase). Потребность во взаимной интеграции всех этих «тяжелых» инструментов привела к созданию целых платформ для ролевой разработки программного обеспечения и управления жизненным циклом приложений - такие платформы сейчас производятся компаниями Borland, IBM, Microsoft и рядом других.
Как правило, применение подобных инструментов требует рассмотрения процесса разработки программного обеспечения как производственного процесса и соответственно создания и внедрения методик управления этим процессом, сходных с методиками управления процессами материального производства. Внедрение подобных методик зачастую осуществляется путем реализации отдельных (и не дешевых!) ИТ-проектов по внедрению в компаниях - разработчиках интегрированных платформ разработки приложений с целью автоматизации и оптимизации процессов, сопровождающих разработку, включая постановку задач, управление требованиями, достижение соответствия стандартам качества.
Бесплатные версии коммерческих инструментов
Если вспомнить, что происходило с инструментами для разработки в последние два года, можно заметить, что в последнее время весьма активно проявилась тенденция выпуска ведущими производителям средств разработки их бесплатных версий (причем с неплохими функциональными возможностями) с целью привлечь внимание разработчиков к потенциалу и возможностям полнофункциональных продуктов и платформ, для которых они предназначены. В частности, компания Borland уже примерно три года выпускает бесплатные версии некоторых своих средств разработки. Корпорацией Microsoft недавно было выпущено семейство продуктов Express, включающее несколько инструментов для разработки приложений Windows Forms и ASP .NET. Корпорация Oracle, в свою очередь, также предоставила свободный доступ разработчиков к инструменту Oracle JDeveloper 10g.
Инструменты с открытым кодом
Наблюдается еще одна тенденция, характерная для современного рынка средств разработки, - активный рост популярности платформ и инструментов с открытым исходным кодом, в развитие которых сейчас инвестируется немало средств коммерческими компаниями, в том числе такими известными производителями платформ, как IBM, Novell и Oracle. Среди наиболее ярких примеров следует отметить активное развитие среды Eclipse - универсальной открытой платформы разработки, совместимой с множеством языков, платформ развертывания и технологий, а также проекта Mono реализации части платформы.NET для операционной системы Linux (для последней сейчас активно выпускаются компиляторы и иные инструменты).
Начало проекту Eclipse было положено в 1998 году корпорацией IBM, поставившей перед собой цель создания интегрированной среды Java-разработки нового поколения, расширяемой за счет встраиваемых в нее интегрируемых инструментов, силами нескольких поставщиков Java-инструментов. С этой целью корпорация IBM в конце 2001 года предоставила сообществу Open Source часть исходного кода своего средства разработки Java-приложений WebSphere Studio Workbench и сформировала консорциум Eclipse (включавший представителей компаний Borland, IBM, MERANT, QNX Software Systems, Rational Software, Red Hat, SuSE, TogetherSoft и Webgain) для управления дальнейшим развитием этой среды разработки, преобразованный в дальнейшем в независимую некоммерческую организацию Eclipse Foundation, насчитывающую сегодня 115 членов.
Сегодня, по прошествии пяти лет с момента ее создания, платформа Eclipse стала настолько популярна, что начала вытеснять с рынка широко применявшиеся коммерческие инструменты (например, некоторые средства Java-разработки). Сегодня доля рынка средств разработки Java-приложений, занимаемая Eclipse, составляет примерно 50%. При этом в течение предыдущего года явно наблюдалась тенденция превращения Eclipse из среды Java-разработки в платформу интеграции инструментов для всего жизненного цикла разработки приложений - недавно в рамках консорциума Eclipse были начаты такие проекты, как создание графической среды моделирования, инструментов для архитектуры, ориентированной на сервисы, а также выпущены обновленные версии инструментов тестирования, бизнес-анализа, средств создания web-приложений.
Что касается собственно средств разработки приложений, на основе платформы Eclipse сейчас созданы среды разработки для PHP, Fortran, Macromedia Flex; планируется выпуск ряда инструментов для разработки приложений для встроенных и мобильных платформ. Для платформы Eclipse существуют и коммерческие средства разработки компаний IBM, Borland и SAP.
Самые популярные среды разработки
Согласно опросу 1200 разработчиков, проведенному в июне этого года исследовательской компанией Evans Data Corp., наиболее широко используемой средой разработки оказалась Microsoft Visual Studio .NET (рис. 2).
Рис. 2. Частота использования сред разработки (источник - Developers’ Choice IDE Scorecard - Evans Data Corp., June 2006)
По данным того же опроса, наиболее популярной в плане функциональности средой разработки приложений оказалась IBM Rational Application Developer, признанная участниками опроса лучшей в качестве инструмента моделирования и сборки приложений и обладающей лучшим набором примеров (рис. 3).
Результаты данного опроса отражают уже упомянутые тенденции преобладания двух наиболее популярных платформ (Windows/Microsoft .NET и Java/J2EE - практически все популярные среды разработки предназначены для этих платформ) и роста популярности средств и платформ разработки с открытым кодом (о чем свидетельствует присутствие Eclipse в пятерке самых популярных сред разработки).
Итак, современные тенденции развития технологий разработки приложений включают уменьшение доли разработки приложений в ИТ-проектах, постепенный переход от малотиражного производства эксклюзивного программного обеспечения к массовому промышленному производству типовых решений, все более активное применение средств поддержки жизненного цикла разработки приложений (включая проекты внедрения интегрированных платформ для разработки приложений). В последнее время также усилился интерес к созданию приложений для мобильных платформ. Характерной тенденцией последних лет является также появление высококачественных инструментов с открытым кодом. Не исключено, что названные тенденции сохранятся еще в течение как минимум нескольких лет.
1.3 Выбор средств разработки программного обеспечения
В настоящее время существует огромное количество программных продуктов, позволяющих в сжатые сроки эффективно и качественно разработать программный комплекс для различных предметных областей.
К ним относятся такие программные средства, как Delphi, Visual C++, С Builder, Visual Basic, Java Builder;
Использование средств этого типа оправдано, когда необходимо в сжатые сроки создать приложение с удобным и понятным графическим интерфейсом.
Приняв во внимание вышеперечисленные аргументы, для разрабатываемого программно-методического комплекса целесообразно использовать средства типа RAD.
Для функционирования программного комплекса, необходима также некоторая программная среда, в простейшем случае представленная операционной системой. В более сложных случаях, когда система работает с большим количеством данных, которые необходимо поддерживать в актуальном состоянии, должна присутствовать некоторая СУБД.
Для правильного и обоснованного выбора RAD-средства необходима оценка продуктов по определенным критериям экспертами. Получить оценку продуктов можно из специальных источников. Но эта оценка дается, учитывая специфику разработки приложения. Более или менее рациональный выбор средства разработки приложения можно сделать только в контексте конкретного проекта или конкретной организации, ведущей разработку.
Поэтому для правильной оценки средств разработки приложения нужна оценка экспертов, ознакомленных со спецификой разрабатываемого приложения, с вопросами его дальнейшей модификации и сопровождения. Ввиду невозможности получить такую оценку от признанных экспертов и не достаточной серьезности разрабатываемого приложения, решил в качестве экспертов принять студентов группы и других лиц, занимающихся разработкой программ.
Во внимание принимались различные критерии для оценки качества программного продукта, в частности такие, которые учитывают аспекты разрабатываемого программного продукта:
Доступность программных средств разработки и реализации;
Cоответствие выбираемых программных средств уровню подготовленности программиста;
Возможности программных средств для разработки профессиональных приложений и сложных программных систем;
Оценка качества средств с точки зрения надежности, производительности, удобства работы и трудоемкости их эксплуатации;
Перспективность и жизнеспособность фирм изготовителей программных средств, возможность обновления и наличия новых версий продуктов при модернизации программно-технической среды;
Возможность перехода от однопользовательского варианта (для отладки и локального применения) к сетевому, для средств разработки и средств эксплуатации, а также его сложность;
Стыковка с широким спектром других СУБД и возможности переноса БД для данного программного средства на другие СУБД;
Возможность подключения к корпоративным сетям и Интернет/Интранет, поддержка постоянно развивающихся WEB технологий;
Модульный принцип построения, степень ее универсальности.
Наличие документации на русском языке, справочных систем, документации в печатном и электронном исполнении, возможности консультаций;
Простота языка программирования;
Скорость работы приложения;
Скорость компиляции приложения;
Наличие интегрированного отладчика;
Обработка исключительных ситуаций;
Методика определения подходящего программного продукта заключается в следующем.
Сначала выбирается несколько доступных и известных программных продуктов. Мною для рассмотрения были выбраны Delphi 5.0, Visual C++ 6.0 и Visual Basic. Каждому критерию назначил вес, исходя из целей проектирования таким образом, что сумма весов всех критериев равнялась 1.
Потом по каждому из параметров критерия давалась оценка программному продукту по десятибалльной шкале, и считалась интегральная оценка по каждому программному продукту по формуле 1.1.
В качестве экспертов, который ставили экспертную оценку, выступали студенты пятого курса группы ИТ98-1
Вычисления по формуле (1.1) сведены в таблицу 1.2.
Как видно из таблицы 1.2 наиболее подходящим средством для разработки программного комплекса является Delphi 5.0.
Таблица 1.2 - Сравнение программных продуктов
1.4 Техническое задание 1.4.1 Введение
Программный комплекс предназначен для создания курса обучения дисциплине и для обучения дисциплине.
1.4.2 Основания для разработки
Разработка программного комплекса ведется на основании задания на дипломную работу, утвержденное приказом ректора Донбасской машиностроительной академии по ГОСТ 19.101-77.
Тема дипломной работы – «Программно – методический комплекс для мультимедийного представления учебной информации».
Спецчасть разработки – «Разработка программного обеспечения для интерфейса оболочки комплекса и примера информационного наполнения»
1.4.3 Назначение разработки
Программный комплекс предназначен для создания большого числа обучающих дисков по разным дисциплинам. Включает интерфейс для создания курса обучения и оболочку для обучения.
1.4.4 Требования к программному изделию 1.4.4.1 Требования к функциональным характеристикам
Программный комплекс должен выполнять следующие функции:
Предоставлять возможность ввода лекций и другого учебного материала с рисунками, видео и звуковым сопровождением;
Предоставлять возможность изменения курса;
Предоставлять возможность проходить курс(обучаться);
Предоставлять возможность контролировать полученные знания;
Предоставлять возможность поиска по всему курсу.
1.4.4.2 Требования к надежности
Программный комплекс должен устойчиво функционировать и не приводить к зависанию операционной системы в аварийных ситуациях.
Контроль формируемого учебного материала возложен на пользователя, который создает учебный курс.
1.4.4.3 Условия эксплуатации
Температура окружающего воздуха, влажность и другие параметры микроклимата должны соответствовать требованиям к помещениям, оборудованным персональными ЭВМ.
Для создания учебного курса необходим человек – преподаватель или пользователь, который будет заводить материал. Человек должен обладать навыками работы с персональной ЭВМ, оснащенной операционной системой Windows.
1.4.4.4 Требования к составу и параметрам технических средств
Для нормального функционирования программного комплекса необходима персональная ЭВМ со следующими характеристиками:
Объем оперативной памяти не менее 32 мегабайт;
Процессор не ниже Pentium 166, мышь, клавиатура;
Наличие свободного места на жестком диске в размере не менее 5 мегабайт;
Дисковод на 3,5’’;
Звуковая карта;
Монитор SVGA.
1.5.4.5 Требования к информационной и программной совместимости
Программа должна функционировать под операционной системой Windows. Должна быть установлена программа BDE Administrator для работы с базами. Исходные коды программы должны быть написаны на языке Object Pascal в среде разработки Delphi 5.0. Информация должна вводиться непосредственно через GUI. Результат визуализации информации должен быть представлен в хорошо воспринимаемом виде.
1.4.4.6 Требования к программной документации
Предварительный состав программной документации установлен в соответствии с ГОСТ 19.101-77. Ниже перечислен список программных документов и их содержание.
Текст программы – запись программы с необходимыми пояснениями и комментариями.
Описание программы – сведения о логической структуре и функционировании программы.
Программа и методика испытаний – требования, подлежащие проверке при испытании программы, также порядок и методы контроля.
Техническое задание – настоящий документ.
Пояснительная записка – результаты исследования структур представления информации, общее описание функционирования программы, а также обоснование принятых технических и технико-экономических решений.
1.4.5 Стадии и этапы разработки
Стадии и этапы разработки должны соответствовать ГОСТ 19.101-77 и состоять из следующих пунктов.
1 Техническое задание – черновое определение требований к программному комплексу и программной документации.
2 Эскизный проект – разработка структур представления информации в программном комплексе, разработка структуры классов, необходимых для реализации поставленного алгоритма. Формулировка методов реализации вложенности в программном комплексе, разработка структуры программы.
3 Технический проект – уточнение структуры классов и методов представления информации. Детальное уточнение метода реализации вложенности. Разработка структуры программы.
4 Рабочий проект – разработка программы, разработка программной документации, испытание программы.
1.4.6 Порядок контроля и приемки
Разработанное программное обеспечение должно соответствовать требованиям заказчика и отвечать всем поставленным функциональным требованиям. Программа должна быть протестирована на возможность возникновения исключительных ситуаций и должна быть сделана соответствующая рецензия.
1.5 Разработка математической модели
Очень важным этапом при создании электронного учебника является выбор материалов для обучения и стрктура представления этих материалов.
Предлагаются следующие шаги для составления курса обучения:
Методическая разработка темы обучающей программы.
Анализом результатов специальных модельных экспериментов разработать модель главы для профильного учебника.
Определить требования к программному продукту, с помощью которого можно педагогам образовательных учреждений создавать электронные учебники для профильной школы с учетом уровня подготовки педагогов к использованию компьютера.
Разработать пакет программных средств, предназначенный для разработки электронных средств учебного назначения: информационных и экспертных систем, электронных учебников, специальных средств для изучения учащихся.
Предложить технологию разработки электронных учебников для профильного обучения с помощью пакета.
Разработать ряд учебников и провести эксперименты по их проверке с учащимися и педагогами.
На основе анализа электронных средств, созданных педагогами и специальных исследований разработать новый проект программных средств для создания электронных учебников.
При разработке учебника необходимо учитывать: интересы учащихся, их психологически особенности, отношение к предмету и педагогу, возможности учащихся выполнить творческие задания и ориентация на него, затруднения школьников в изучении предмета и виды помощи, которые они предпочитают.
Этапы разработки электронного учебника можно представить в виде схемы, изображенной на рисунке 1.2.
В учебнике требуется уделить специальное внимание мотивации обучающихся к изучению каждой темы. Общими моментами в данной плоскости являются: возможности применения математики в соответствующей предметной области, необходимость сдачи экзаменов.
Возможность накопить опыт творческой деятельности в разных предметных областях, знакомство с интересными применениями ЭВМ.
Учебник должен обеспечить возможность ученику выбрать не только уровень, на котором будет изучать учебный материал темы, но и разный способ изучения темы (не менее двух способов). При этом ученик должен осознать, что он и только он отвечает за свой выбор уровня изучения темы.
Рисунок 1.2 - Этапы разработки ЭУ
Учебник призван защитить обучаемых от перегрузки. В частности, этому служит раздел домашних заданий по новому материалу (в нем представлены минимальное число задания, которые будут предложены на дом и при выполнении которых студенту вновь предстоит выбирать уровень сложности).
В учебнике должен быть специальный тренажер, обращаясь к которому по своей инициативе ученик может не только отработать алгоритмы решения основных типов задач, но и учиться: отказываться от известного метода решения задач и находить другие методы, составлять задачи, искать и исправлять ошибки в решении задач, проводить анализ ситуаций разными способами и др.
В учебнике должен быть раздел личного мониторинга, предназначенный для учащихся, которые до проведения контрольной работы хотят оценить результаты своей работы над темой и своевременно внести необходимые коррективы, хотят узнать прогноз результата выполнения контрольной и получить указание от компьютера, каким образом можно его улучшить.
Предусмотрены различные виды помощи ученикам. Особенно важным является включение специальной экспертной системы, которая предназначена не только для оказания помощи ученикам в решении конкретных задач на уроке или дома, но и ориентирована на передачу опыта автора учебника с разными элементами учебника.
Раздел творческих заданий, в котором предлагаются возможные проекты для нужд учебного заведения и для участия в конференциях и конкурсах, проводимых как внутри учебного заведения, так и вне его.
Важно, чтобы учебник можно было существенно изменять и дополнять на основе не только разработок автора учебника, учителя, который его использует, но и учащимися вместе с учителем на основе проектов, выполненных учениками и с учетом особенностей образовательного учреждения и профиля класса. Вот одна иллюстрация: учебник по математике для гуманитарных классов может быть переведен учащимися на те иностранные языки, которые изучают учащиеся. В этом случае новые ученики, использующие дополненный вариант электронного учебника, получают новый возможный вариант изучения темы – изучать тему на иностранном языке.
Существенно, чтобы обучающиеся знакомились с опытом выполнения каких-то работ, которые являются важными для профиля класса, которые вызывают известные затруднения учащихся и которые выполнены их сверстниками. Это достигается за счет включения в учебник разделов, в которых представлены разные варианты выполнения одних и тех же заданий учениками, изучавшими материал с помощью электронного учебника (к примеру, на рефлексию или систематизацию, на составление задач и др.) и анализ выполнения, выполненные учениками и автором электронного учебника.
Исходя из вышеперечисленного предлагается структура материалов, приведенная на рисунке 1.3.
1.6 Разработка компонентов программного комплекса 1.6.1 Разработка логической модели программного комплекса
Одним из способов при описании логической модели программного комплекса является структурный анализ.
Сущность структурного подхода заключается в декомпозиции (разбиении) системы на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы "снизу-вверх" от отдельных задач ко всей системе целостность теряется, возникают проблемы при информационной стыковке отдельных компонентов.
Все наиболее распространенные методологии структурного подхода базируются на ряде общих принципов . В качестве двух базовых принципов используются следующие:
Принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения;
Принцип иерархического упорядочивания - принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.
Выделение двух базовых принципов не означает, что остальные принципы являются второстепенными, поскольку игнорирование любого из
них может привести к непредсказуемым последствиям (в том числе и к провалу всего проекта). Основными из этих принципов являются следующие:
Принцип абстрагирования - заключается в выделении существенных аспектов системы и отвлечения от несущественных;
Рискнок 1.3- Структура материалов
Принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы;
Принцип непротиворечивости - заключается в обоснованности и согласованности элементов;
Принцип структурирования данных - заключается в том, что данные должны быть структурированы и иерархически организованы.
В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди которых являются следующие:
SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;
DFD (Data Flow Diagrams) диаграммы потоков данных;
ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь";
На уроках біології. [Електронний ресурс]. Режим доступу: http: // www. nenc.gov.ua / index.php? id=79. – Заголовок з титул. екрана. АНОТАЦІЇ Сліпчук І.Ю. Методика навчання біології учнів 8-9 класів з використанням комп’ютерних технологій. – Рукопис. Дисертація на здобуття наукового ступеня кандидата педагогічних наук за спеціальністю 13.00.02 – теорія та методика навчання (біологія). – Наці ...
Сферы интеллектуальной деятельности, принесло с собой совершенно новые представления о возможностях обработки информации, новые приемы и формы работы, новый уровень информационной обеспеченности общества. В этом смысле есть все основания говорить о наступлении эры компьютерных технологий как о новом витке цивилизации. Кстати, выражение "компьютерная цивилизация" действительно есть, оно реально...
Интегрированная среда разработки (ИСР) – это система программных средств, используемая программистам для разработки программного обеспечения. В английском языке такая среда называется Integrated development environment или сокращённо IDE.
ИСР обычно включает в себя текстовый редактор, компилятор, интерпретатор, средства автоматизации разработки и сборки программного обеспечения и отладчик. Иногда также содержит средства для интеграции с системами управления версиями и разнообразные инструменты для упрощения конструирования графического интерфейса пользователя. Многие современные среды разработки также включают окно просмотра программных классов, инспектор объектов и диаграмму иерархии классов – для использования при объектно-ориентированной разработке ПО. Большинство современных ИСР предназначенны для разработки программ на нескольких языках программирования одновременно.
Один из частных случаев ИСР – среды визуальной разработки, которые включают в себя возможность визуального редактирования интерфейса программы.
Основным окном, является текстовый редактор, который используется для ввода исходного кода в ИСР и ориентирован на работу с последовательностью символов в текстовых файлах. Такие редакторы обеспечивают расширенную функциональность – подсветку синтаксиса, сортировку строк, шаблоны, конвертацию кодировок, показ кодов символов и т. п. Иногда их называют редакторами кода, так как основное их предназначение – написание исходных кодов компьютерных программ.
Подсветка синтаксиса – выделение синтаксических конструкций текста с использованием различных цветов, шрифтов и начертаний. Обычно применяется в текстовых редакторах для облегчения чтения исходного текста, улучшения визуального восприятия. Часто применяется при публикации исходных кодов в Интернет.
Понятие трансляции, компилятора и интерпретатора было дано в предыдущих лекциях.
Одна из наиболее важных частей ИСР – отладчик, который представляет собой модуль среды разработки или отдельное приложение, предназначенное для поиска ошибок в программе. Отладчик позволяет выполнять пошаговую трассировку, отслеживать, устанавливать или изменять значения переменных в процессе выполнения программы, устанавливать и удалять контрольные точки или условия остановки и т. д.
Наиболее распространёнными отладчиками являются:
- GNU Debugger – отладчик программ от проекта GNU;
- IDA – дизассемблер и низкоуровневый отладчик для операционных систем семейства Windows и GNU/Linux;
- Microsoft Visual Studio – среда разработки программного обеспечения, включающая средства отладки от корпорации Microsoft;
- OllyDbg – бесплатный низкоуровневый отладчик для операционных систем семейства Windows;
- SoftICE – низкоуровневый отладчик для операционных систем семейства Windows;
- Dr. Watson – стандартный отладчик Windows, позволяет создавать дампы памяти;
- WinDbg – бесплатный отладчик от корпорации Microsoft.
Основным процессом отладки является трассировка. Трассировка – это процесс пошагового выполнения программы. В режиме трассировки программист видит последовательность выполнения команд и значения переменных на данном шаге выполнения программы, что позволяет легче обнаруживать ошибки. Трассировка может быть начата и окончена в любом месте программы, выполнение программы может останавливаться на каждой команде или на точках останова, трассировка может выполнятся с заходом в процедуры/функции и без заходов.
Наиболее важным модулем ИСР при совместной разработке проектов средней и высокой степени сложности является система управления версиями. Система управления версиями (английская аббревиатура CVS) - программное обеспечение для облегчения работы с изменяющейся информацией. Она позволяет хранить несколько версий одного и того же документа, при необходимости, возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение и многое другое.
Такие системы наиболее широко применяются при разработке программного обеспечения, для хранения исходных кодов разрабатываемой программы. Однако они могут с успехом применяться и в других областях, в которых ведётся работа с большим количеством непрерывно изменяющихся электронных документов, в частности, они всё чаще применяются в САПР, обычно в составе систем управления данными об изделии. Управление версиями используется в инструментах конфигурационного управления различных устройств и систем.
В нашей стране, возможно в связи с малым количеством масштабных проектов, системы управления версиями распространение не получили, несмотря на то, что их использование является залогом успешной реализации крупных проектов. В связи с этим остановимся подробнее на этой возможности ИСР.
Большинство систем управления версиями используют централизованную модель, когда имеется единое хранилище документов, управляемое специальным сервером, который и выполняет большую часть функций по управлению версиями. Пользователь, работающий с документами, должен сначала получить нужную ему версию документа из хранилища; обычно создаётся локальная копия документа, так называемая «рабочая копия». Может быть получена последняя версия или любая из предыдущих, выбранная по номеру версии или дате создания, иногда и по другим признакам. После того, как в документ внесены нужные изменения, новая версия помещается в хранилище. В отличие от простого сохранения файла, предыдущая версия не стирается, а тоже остаётся в хранилище и может быть получена оттуда в любое время. Сервер может использовать дельта-компрессию – способ хранения документов, при котором сохраняются только изменения между последовательными версиями, что позволяет уменьшить объём хранимых данных.
Иногда создание новой версии выполняется незаметно для пользователя (прозрачно) – либо с помощью прикладной программы, имеющей встроенную поддержку такой функции, либо за счёт использования специальной файловой системы. В последнем случае пользователь просто работает с файлом как обычно, и при сохранении файла автоматически создаётся новая версия.
Часто бывает, что над одним проектом одновременно работают несколько человек. Если два человека изменяют один и тот же файл, то один из них может случайно отменить изменения, сделанные другим. Системы управления версиями отслеживают такие конфликты и предлагают средства их решения. Большинство систем может автоматически объединить (слить) изменения, сделанные разными разработчиками. Однако такое автоматическое объединение изменений, возможно обычно только для текстовых файлов и то, только при условии, что изменялись разные (непересекающиеся) части этого файла. Такое ограничение связано с тем, что большинство систем управления версиями ориентированы на поддержку процесса разработки программного обеспечения, а исходные коды программ хранятся в текстовых файлах. Если автоматическое объединение выполнить не удалось, система может предложить решить проблему вручную.
Часто выполнить слияние невозможно ни в автоматическом, ни в ручном режиме, например, в случае, если формат файла слишком сложен или вообще неизвестен. Некоторые системы управления версиями дают возможность заблокировать файл в хранилище. Блокировка не позволяет другим пользователям получить рабочую копию или препятствует изменению рабочей копии файла (например, средствами файловой системы) и обеспечивает таким образом исключительный доступ только тому пользователю, который работает с документом.
Другие возможности системы управления версиями состоят:
В создании разных вариантов одного документа-ветки, с общей историей изменений до точки ветвления и с разными – после неё.
Ведении журнала изменений, куда пользователи могут записывать пояснения о том, что и почему они изменили в данной версии;
Контролирует права доступа пользователей, разрешении или запрете чтения или изменения данных в зависимости от того, кто запрашивает это действие.
Отдельным классом являются распределённые системы управления версиями. Такие системы используют распределённую модель вместо традиционной клиент-серверной. Они, в общем случае, не нуждаются в централизованном хранилище: вся история изменения документов хранится на каждом компьютере, в локальном хранилище, и при необходимости отдельные фрагменты истории локального хранилища синхронизируются с аналогичным хранилищем на другом компьютере. В некоторых таких системах локальное хранилище располагается непосредственно в каталогах рабочей копии.
Когда пользователь такой системы выполняет обычные действия, такие, как извлечение определённой версии документа, создание новой версии и тому подобное, он работает со своей локальной копией хранилища. По мере внесения изменений хранилища, принадлежащие разным разработчикам, начинают различаться, и возникает необходимость в их синхронизации. Такая синхронизация может осуществляться с помощью обмена патчами или так называемыми наборами изменений (англ. change sets) между пользователями.
Основное преимущество распределённых систем заключается в их гибкости. Каждый разработчик может вести работу независимо, так, как ему удобно, сохраняя промежуточные варианты документов и передавая результаты другим участникам, когда посчитает нужным. При этом обмен наборами изменений может осуществляться по различным схемам. В небольших коллективах участники работы могут обмениваться изменениями по принципу «каждый с каждым», за счет чего отпадает необходимость в создании выделенного сервера. Крупное сообщество, наоборот, может использовать централизованный сервер, с которым синхронизируются копии всех его участников. Возможны и более сложные варианты, например, с созданием групп для работы по отдельным направлениям внутри более крупного проекта.
Для использования систем управления версиями необходимо владеть терминологией этих систем. Общепринятой терминологии не существует, в разных системах могут использоваться различные названия для одних и тех же действий.
Ниже приведены некоторые, наиболее часто используемые варианты. В связи с тем, что системы разрабатывались англоязычным сообществом, а русскоязычная терминология ещё на выработана, используются английские термины.
branch (ветвь) – направление разработки, независимое от других. Ветвь представляет собой копию части (как правило, одного каталога) хранилища, в которую можно вносить свои изменения, не влияющие на другие ветви. Документы в разных ветвях имеют одинаковую историю до точки ветвления и разные – после неё.
check-in, commit, submit – создание новой версии, публикация изменений. Распространение изменений, сделанных в рабочей копии, на хранилище документов. При этом в хранилище создаётся новая версия изменённых документов.
C heck-out, clone – извлечение документа из хранилища и создание рабочей копии.
C onflict – конфликтная ситуация, когда несколько пользователей сделали изменения одного и того же участка документа. Конфликт обнаруживается в случае, когда один пользователь уже опубликовал свои изменения, а второй только пытается их опубликовать и система сама не может корректно слить конфликтующие изменения. Поскольку программа может быть недостаточно разумна для того, чтобы определить, какое изменение является «корректным», второму пользователю нужно самому разрешить конфликт (resolve).
M erge, integration (слияние) - объединение независимых изменений в единую версию документа. Осуществляется, когда два человека изменили один и тот же файл или при переносе изменений из одной ветки в другую.
R epository (хранилище документов) - место, где система управления версиями хранит все документы вместе с историей их изменения и другой служебной информацией.
R evision (версия документа). Системы управления версиями различают версии по номерам, которые назначаются автоматически.
T ag, label (метка) – которую можно присвоить определённой версии документа. Метка представляет собой символическое имя для группы документов, причём описывает она не только набор имён файлов, но и ревизию каждого файла. Ревизии включённых в метку документов могут принадлежать разным моментам времени.
T runk, mainline (ствол) – основная ветвь разработки проекта. Политика работы со стволом может отличаться от проекта к проекту, но в целом она такова: большинство изменений вносится в ствол; если требуется серьёзное изменение, способное привести к нестабильности, создаётся ветвь, которая сливается со стволом, когда нововведение будет в достаточной мере испытано; перед выпуском очередной версии создаётся «релизная» ветвь, в которую вносятся только исправления.
U pdate, sync (обновление, синхронизация) – синхронизация рабочей копии до некоторого заданного состояния хранилища. Чаще всего это действие означает обновление рабочей копии до самого свежего состояния хранилища. Однако при необходимости можно синхронизировать рабочую копию и к более старому состоянию, чем текущее.
W orking copy (рабочая копия) – рабочая (локальная) копия документов.
Рассмотрим возможности ИСР на примере наиболее доступных и популярных версий.
Eclipse (от англ. затмение) – свободная интегрированная среда разработки модульных кроссплатформенных приложений (рисунок 69). Развивается и поддерживается некоммерческой организацией Eclipse Foundation (http://www.eclipse.org/).
Первоначально Eclipse разрабатывалась фирмой «IBM» в качестве корпоративного стандарта ИСР для разработки на разных языках под платформы от данной компании. По сведениям «IBM», проектирование и разработка стоили 40 млн. долл. Исходный код был полностью открыт и сделан доступным после того, как Eclipse был передан для дальнейшего развития независимому от «IBM» сообществу.
В основе Эклипс лежат фреймворк OSGi и SWT/JFace, на основе которых разработан следующий слой – RCP (Rich Client Platform, платформа для разработки полноценных клиентских приложений). RCP служит основой не только для Эклипс, но и для других RCP-приложений, например, Azureus и File Arranger. Следующий слой – сам Эклипс, представляющий собой набор расширений RCP: редакторы, панели, перспективы, модуль CVS и модуль Java Development Tools (JDT).
Эклипс – в первую очередь, полноценная Java ИСР, нацеленная на групповую разработку: поддержка CVS входит в поставку Эклипс, активно развиваются несколько вариантов SVN-модулей, существует поддержка VSS и других. В силу бесплатности и высокого качества, Эклипс во многих организациях является корпоративным стандартом для разработки приложений.
Второе назначение Эклипс – служить платформой для разработки новых расширений, чем он и завоевал популярность: любой разработчик может расширить Эклипс своими модулями. Уже существуют C/C++ Development Tools (CDT), разрабатываемые инженерами QNX совместно с «IBM», и средства для языков COBOL, FORTRAN, PHP и прочие от различных разработчиков. Множество расширений дополняет среду Эклипс менеджерами для работы с базами данных, серверами приложений и др.
Рисунок 69 . Интерфейс главного окна Эклипс
Эклипс написана на Java, потому является платформо-независимым продуктом, за исключением библиотеки SWT, которая разрабатывается для всех распространённых платформ. Библиотека SWT используется вместо стандартной для Java библиотеки Swing. Она полностью опирается на нижележащую платформу (операционную систему), что обеспечивает быстроту и натуральный внешний вид пользовательского интерфейса, но иногда вызывает на разных платформах проблемы совместимости и устойчивости приложений.
Основой Eclipse является платформа расширенного клиента (RCP - от англ. rich client platform). Её компоненты:
OSGi (стандартная среда поставки комплектов (англ. bundles));
SWT (портируемый инструментарий виджетов);
JFace (файловые буферы, работа с текстом, текстовые редакторы);
Рабочая среда Эклипс (панели, редакторы, проекции, мастеры).
Другой популярной свободной ИСР является КДевелоп (http://www.kdevelop.org, рис. 70). КДевелоп (англ. KDevelop) - свободная среда разработки программного обеспечения для UNIX-подобных операционных систем. Проект стартовал в 1998 году. КДевелоп распространяется согласно лицензии GNU (General Public License).
Рисунок 70. Интерфейс KDevelop
KDevelop не включает в свой состав компилятор, вместо этого он использует любой компилятор для создания исполняемого кода.
Текущая стабильная версия поддерживает большое количество языков программирования, таких как Ада, Bash, C, C++, Фортран, Java, Pascal, Perl, PHP, Python, Ruby и SQL.
КДевелоп использует встроенный компонент – текстовый редактор – через технологию KParts. Основным редактором является Kate.
Функции КДевелоп:
Подсветка исходного кода с учетом синтаксиса используемого языка программирования, который определяется автоматически;
Менеджер проектов для проектов разного типа, таких как Automake, qmake для проектов базирующихся на технологиях Qt и Ant для проектов, базирующихся на Java;
Навигатор классов (Class Browser);
Front-end для GNU Compiler Collection;
Front-end для GNU Debugger;
Помощников для генерации и обновления определения классов и платформы (framework);
Автоматическая система завершения кода (Си/C++);
Встроенная поддержка системы документирования исходных кодов (Doxygen);
Одна из систем контроля версий: SCM, CVS, Subversion, Perforce и ClearCase;
Функция Quick Open позволяющая быстро перемещаться по файлам.
KDevelop представляет собой «подключаемую» архитектуру. Когда разработчик делает изменения, он должен лишь скомпилировать плагин. Предусмотрена возможность сохранения профилей, указывающих какие плагины должны быть загружены. KDevelop не поставляется со встроенным текстовым редактором, он подключается как плагин. KDevelop не зависит от языка программирования и от платформы, на которой он запускается, поддерживая KDE, GNOME и много других технологий (например, Qt, GTK+ и wxWidgets).
Встроенный отладчик KDevelop позволяет работать графически со всеми средствами отладки, такими как точки останова и трассировки. Он также может работать с динамически подгружаемыми плагинами, в отличие от консольного gdb.
На данный момент существует примерно от 50 до 100 плагинов для данной IDE. Среди наиболее полезных – persistent project-wide code bookmarks, Code abbreviations, позволяющие быстро разворачивать текст, Source formatter, который переформатирует текст для style guide до сохранения, поиск по регулярным выражениям и project-wide поиск/замена.
Последней рассматриваемой ИСР является Microsoft Visual Studio (Microsoft Visual Studio, рис. 71). По сути, Microsoft Visual Studio является линейкой продуктов компании «Майкрософт», включающих интегрированную среду разработки программного обеспечения и ряд других инструментальных средств.
Рисунок 71. Интерфейс Microsoft Visual Studio
Microsoft Visual Studio включает один или несколько компонентов из следующих: Visual Basic.NET, Visual C++, Visual C#, Visual F#, Microsoft SQL Server, Visual InterDev, Visual J++, Visual J#, Visual FoxPro, Visual Source Safe.
Одним из главных преимуществ Майкрософт Визуал Студия является высокое качество документирования процесса разработки и описания возможных проблем в MSDN Library. Однако наиболее интересная для профессионала часть, посвящённая тонкостям разработки, существует только на английском языке.
Также компания «Майкрософт» предлагает бесплатный аналог продукта Visual Studio Express.
Загрузка...
