22
значительно усложняет разработку и повышает риск возникновения
ошибок [1, c. 61-92].
Модульность, как и другие качественные характеристики, имеющие
измеряемые свойства, такие как метрики, также имеет измеряемые
свойства, которые показывают, в какой степени архитектура является
модульной.
Например, существует множество метрик, измеряющих различные
виды свойств на различных уровнях и этапах разработки системы.
Некоторые метрики измеряют свойства реализации, такие, как количество
строк в коде. Другие метрики измеряют свойства архитектуры. Отметим,
что при оценке степени модульности системы необходимы метрики,
которые измеряют связность, зацепление и детализацию. Кратко
рассмотрим некоторые метрики модульности.
Зацепление между узлами. Данная метрика измеряет, в какой
степени каждый физический узел зависит от других физических узлов.
Данная метрика относится к системному уровню и рассчитывается на
основе диаграммы развертывания (UML).
Степень зацепления компонентов. Данная метрика измеряет для
каждого компонента, в какой степени предоставляются и потребляются его
зависимости. Каждой зависимости назначается вес – 1, если потребляется
и 2, если предоставляется, после чего складываются для расчета значения
метрики. Данная метрика относится к уровню компонентов и
рассчитывается на основе диаграммы компонентов.
Зацепление между компонентами. Эта метрика подсчитывает все
зависимости, которые один компонент имеет для других. Метрика
относится к уровню компонентов и рассчитывается на основе диаграммы
компонентов.
23
Количество классов на компонент. Данная метрика рассматривает
размер и детализацию каждого компонента через подсчет классов к
компоненте. Метрика относится к уровню компонентов и рассчитывается
на основе диаграммы компонентов и диаграммы классов.
Количество вариантов использования на компонент. Эта метрика
основывается на подсчете вариантов использования на каждый компонент,
что позволяет оценить объем ответственности компонента. Метрика
относится к уровню компонентов и рассчитывается на основе диаграммы
компонентов и диаграммы вариантов использования.
Количество компонентов на вариант использования. Данная метрика
измеряет, сколько компонентов разделяют одну и ту же ответственность.
Метрика относится к уровню компонентов и рассчитывается на основе
диаграммы компонентов, диаграммы вариантов использования и
диаграммы последовательности [47, с. 11-13].
В заключение, приведем основные преимущества модульности.
Во-первых, когда программа создается с использованием модульного
подхода, тогда процесс поиска и исправления ошибки (процесс отладки)
значительно упрощается. Это объясняется тем, что разработчик, понимая,
в какой функции/компоненте существует ошибка, может быстро
определить модуль, который отвечает за данную функцию/компоненту.
Кроме того, любой модуль содержит меньший по объему код, чем вся
программа, что также способствует скорейшему исправлению ошибки.
Во-вторых, модульность позволяет значительно упростить повторное
использование кода. Данное утверждение следует из того, что модуль
содержит весь перечень элементов (классы, интерфейсы, перечисления,
пакеты и т.п.), которые объедены для решения определенных задач и
которые на физическом уровне отделены от других элементов программы.
24
Вследствие этого, упрощается создание зависимостей с данным модулем и
его повторное использование в другом контексте.
В-третьих, модульной подход к проектированию программной
системы значительно повышает читабельность кода. Причина этого
заключается в том, что модульный код в высшей степени структурирован и
каждый модуль выполняет определенный перечень задач. В результате,
разработчик может легко сопоставлять читаемый код с соответствующей
задачей, что упрощает понимание кода.
В-четвертых, модульность позволяет обеспечить высокий уровень
надежности разрабатываемой системы. Это объясняется тем, что код,
который легче читать, легче отлаживать, легче поддерживать всегда будет
содержать в себе меньше ошибок. Данное преимущество особенно важно,
когда разрабатывается очень большой проект [55].
В-пятых, модульный подход к программной системе значительно
упрощает и повышает эффективность совместной работы над проектом
большого количества людей. Данное преимущество достигается за счет
того, что каждая команда или отдельные специалисты занимаются
разработкой только своих модулей, интерфейсы которых отрыты для всех
разработчиков, но реализация которых скрыта. В результате, создаются
благоприятные условия для одновременной работы над всем проектом, что
позволяет значительно снизить общую продолжительность разработки.
В-шестых, модульность дает возможность упростить процесс
разработки. Причина этого заключается в том, что отдельный модуль легче
проектировать, разрабатывать и тестировать [54].
В-седьмых, модульность позволяет улучшить управляемость проекта
по разработке программной системы. Например, понимая в каком модуле
существует ошибка руководитель сразу понимает кого из разработчиков
нужно назначить ответственным за исправление данной ошибки.
25
***
Сегодня на рынке представлено большое количество языков
программирования. Каждый язык занимает свою нишу, что объясняется
его характеристиками. Отметим основные характеристики языка Java. Во-
первых, язык Java и компиляторы Java являются бесплатными для
пользования (кроме Java ME). Во-вторых, программа на Java
кроссплатформенна. В-третьих, язык Java обладает богатыми
возможностями, а его стандартные библиотеки объемным API. В-
четвертых, данная технология является лидером в сегменте языков
программирования, что свидетельствует о ее надежности и зрелости. В-
пятых, время разработки программы на Java сравнительно ниже, чем на
С++, хотя они работают немного медленнее, чем программы на С++.
Модульность (англ. modularity) это такой подход к созданию
системы, при котором создаваемая система делится на небольшие части,
называемые модулями (англ. module), которые могут создаваться и
использоваться независимо друг от друга.
Модульный метод проектирования соответствует определенным
критериям, определенным правилам, которым должны следовать
разработчики и определенным принципам, которые должны соблюдаться.
Критериями модульного метода являются: декомпозиция,
композиция, понятность, непрерывность, защищенность. Из указанных
критериев следуют пять правил: прямое отображение, минимум
интерфейсов, слабая связность интерфейсов, явные интерфейсы, скрытие
информации. Из критериев и правил модульно метода формируются пять
принципов: лингвистические модульные единицы, самодокументирование,
унифицированный доступ, открыт – закрыт, единственный выбор.
В тоже время модульность предоставляет целый ряд преимуществ –
упрощает разработку и тестирование, повышает надежность системы и др.
26
ГЛАВА 2. СУЩЕСТВУЮЩИЕ ТЕХНОЛОГИИ ДЛЯ
СОЗДАНИЯ МОДУЛЬНОГО ПО НА ЯЗЫКЕ JAVA
2.1. Технология OSGi (Open Services Gateway Initiative)
Инициатива шлюза открытых сервисов (англ. Open Service Gateway
initiative (OSGi)) была создана в марте 1999 года консорциумом ведущих
технологических компаний с целью определения универсальной
интеграционной платформы для совместимости приложений и сервисов.
Данная платформа должна была решить три фундаментальные проблемы.
Первая проблема заключалась в переносимости (англ. portability).
Консорциум нуждался в единой программной платформе, которая бы
абстрагировала приложение от операционной системы и аппаратной
среды. Другими словами необходима была виртуальная машина.
Очевидно, что выбор пал на технологию Java.
Вторая проблема заключалась в том, что устройства, на которых
платформа должна функционировать, сильно отличались по своим
техническим характеристикам. В особенности это относится к мобильным
устройствам. В результате этого, было решено, что разрабатываемая
универсальная платформа должна обеспечить простое разделение
интерфейса (API, SPI) от их реализации. В тоже время, стандартная версия
платформы Java (Java Standard Edition (Java SE)) не имела реестр сервисов
или платформу для управления сервисами. Следовательно, данная
функциональность должна была быть разработана с нуля.
Третья проблема – поддержка динамических изменений. Согласно
требованиям платформа должна позволять динамическую загрузку (англ.
deployment) и выгрузку (англ. undeployment) приложений в безопасной
форме. Данная функциональность также не поддерживается в Java SE. [2,
с.5-6]
27
Схематичное представление использования платформы OSGi
приведено на рис. 3.
Рисунок 3. Схематичное представление использования технологии OSGi.
Кратко отметим этапы развития спецификации OSGi:
OSGi релиз 1 (R1): май 2000
OSGi релиз 2 (R2): октябрь 2001
OSGi релиз 3 (R3): март 2003
OSGi релиз 4 (R4): октябрь 2005 / сентябрь 2006
o Основная спецификация (R4 Core): октябрь 2005
o Спецификация для мобильных устройств (R4 Mobile / JSR-232):
сентябрь 2006
OSGi релиз 4.1 (R4.1): май 2007 (AKA JSR-291)
OSGi релиз 4.2 (R4.2): сентябрь 2009
o Спецификация для предприятий (R4.2): март 2010
OSGi релиз 4.3 (R4.3): апрель 2011
o Основная спецификация: апрель 2011
o Дополнительная спецификация: май 2012
Аппаратное обеспечение
Драйвер
Драйвер
Драйвер
Операционная система
Среда выполнения Java
Платформа OSGi
Модуль
приложения
Модуль
приложения
Модуль
приложения
28
OSGi релиз 5 (R5): июнь 2012
o Основная спецификация и спецификация для предприятий: июнь
2012
OSGi релиз 6 (R6): июнь 2015
o Основная спецификация: июнь 2015 [49]
За более чем пятнадцатилетний срок данная технология, будучи даже
не включенной в Java SE, стала де-факто стандартом для разработки
модульных программ на языке Java, что свидетельствует о ее зрелости,
надежности, стабильности и эффективности. Кроме того, технология OSGi
достигла такого признания благодаря и преимуществам, которые она
предоставляет. Важнейшие преимущества технологии описаны далее.
Уменьшение сложности. Разработка с технологией OSGi
подразумевает разработку модулей (компонентов OSGi), которые
называются бандлами. Они скрывают свою внутреннюю структуру от
других бандлов и взаимодействуют через сервисы. Такое сокрытие дает
большую свободу при их дальнейшем изменении. Это позволяет не только
уменьшить количество ошибок в коде, но и делает разработку более
простой, так как грамотно разработанный бандл содержит часть
функциональности через четко определенный интерфейс.
Повторное использование. Компонентная модель OSGi позволяет
легко использовать многие компоненты от сторонних разработчиков в
приложении. Увеличивающее количество проектов с открытым кодом
предоставляют их JAR библиотеки готовыми для использования с OSGi. В
тоже время, значительное количество и коммерческих библиотек
поставляются в виде OSGi бандлов. Здесь необходимо отметить, что
исходя из нашего опыта, сегодня не OSGi библиотеки являются
исключением, чем правилом.
29
Соответствие реалиям использование. Платформа OSGi динамична.
Она может изменить бандлы на лету и сервисы могут динамически
создаваться и удаляться. Очевидно, что такие требования очень
распространены, особенно для приложений, разрабатываемых для
предприятий. Платформы OSGi легко решает такие задачи, что позволяет
серьезно экономить на разработке.
Легкость развертывания. Технология OSGi это не только стандарт
для компонентов. Она также определяет, как компоненты устанавливаются
и управляются.
Динамические изменения. Компонентная модель OSGi это
динамическая модель. Бандлы могут быть установлены, запущены,
остановлены, изменены и удалены без необходимости остановки всей
системы. Многие Java разработчики не верят, что это можно быть
осуществлено надежно и намеренно не используют такие возможности в
разрабатываемых проектах. Однако, после некоторого опыта
использования, многие начинают осознавать, что это на самом деле
работает и значительно снижает время развертывания рабочей системы.
Адаптивность. Компонентная модель OSGi разработана с таким
расчетом, чтобы позволять объединять и соединять компоненты. Это
требует, чтобы зависимости компонентов должны быть специальным
образом обозначены. Кроме того, необходимо, чтобы компоненты
функционировали в среде, где их необязательные зависимости не всегда
доступны. Реестр сервисов OSGi – динамические реестр, где бандлы могут
регистрировать, получать и отслеживать сервисы. Динамическая модель
сервисов позволяет бандлам получать информацию о системе и
подстраивать функциональность, которую они обеспечивают.
Прозрачность. Бандлы и сервисы это первоочередные элементы в
среде OSGi. Программный интерфейс (API) управления обеспечивает
30
доступ к внутреннему состоянию бандла и позволяет управлять его
связями с другими бандлами. Например, большинство платформ
обеспечивают командную оболочку (англ. shell), которая дает информацию
о внутреннем состоянии. Части приложений могут быть остановлены или
подвергнуты отладке. Вместо того, чтобы просматривать миллионы строк
лог файлов OSGi приложения могут часто быть отлажены через
командную оболочку в режиме реального времени.
Контроль версий. Технология OSGi решает проблему зависимостей
JAR (англ. JAR hell). Например, библиотека А работает с библиотекой B
версии 2, но библиотека C может работать только с библиотекой B версии
3. Данная проблема не может быть разрешена только средствами Java. В
среде OSGi все бандлы проходят строгий контроль версии и все бандлы
соединяются с друг другом только по нужным версиям. В
рассматриваемом примере оба бандла A и C могут одновременно работать
в одной среде и каждый будет соединен со своей версии бандла B.
Проста в использовании. Платформа OSGi на удивление проста в
использовании, несмотря на мощное управление зависимостями,
конфигурации и динамизм. Код OSGi выглядит почти идентичным
классическому Java коду. Ряд легко используемых аннотации дает
информацию среде как определенный класс хочет использовать динамизм,
конфигурацию и зависимости других сервисов. Настройки по умолчанию
полностью скрывают динамизм. Эта очень простая модель дает в тоже
время очень мощные возможности.
Не занимает много места. Платформа OSGi версии 4 может быть
реализована JAR файлом размером 300KB. Благодаря такому небольшому
размеру, платформа может быть использована на большом количестве
устройств – от очень малых и малых до мейнфреймов. Она требует только
минимальную виртуальную машину Java для своей работы.
31
Высокая производительность. Одна из главных обязанностей
платформы OSGi заключается в загрузке классов из бандлов. В обычной
Java JAR файлы полностью сканируются и классы добавляются в
линейный список. Для поиска класса необходимо просмотреть весь этот
список (обычно очень большой). OSGi платформа использует другой
подход, который не требует такого поиска, что дает значительную
скорость при загрузке.
Широко используется. Спецификации OSGi первично
разрабатывались для встроенных домашних систем, но с 1998 они широко
использовались в различных отраслях: автомобильных, мобильных
телефонах, промышленной автоматизации, шлюзах и роутерах, офисных
АТС, фиксированных телефонных линиях и многих других. С 2003 года
очень популярная среда разработки Eclipse работает на технологии OSGi и
обеспечивает широкую поддержку для разработки бандлов.
Поддерживается ведущими компаниями. Технология OSGi
поддерживается такими компаниями, как Oracle, IBM, Samsung, Nokia,
Progress, Motorola, NTT, Siemens, Hitachi, Deutsche Telekom, Redhat,
Ericsson и многими другими [28].
На сегодняшний день на рынке существует несколько независимых
друг от друга реализаций платформы OSGi, в том числе и с открытым
исходным кодом. Приведем обзор самых распространенных реализаций с
открытым исходным кодом.
Equinox – реализация OSGi платформы, которая используется как
эталонная реализация (англ. reference implementation) и в этой роле она
реализует весь необходимый функционал самых последних спецификаций
платформы OSGi. Цель проекта – быть первоклассной OSGi средой и
способствовать тому, чтобы Eclipse воспринимался как совокупность
бандлов. В результате этого, проект отвечает за то, чтобы создать и