12
Service (JMS) или работу с СУБД, используя Java Persistence API (JPA) [8,
с. 1]. История версии Java SE и Java EE приведена в таблице 2.
Java SE
Java EE
Продукт
Дата
Продукт
Дата
JDK 1.0
23 января 1996
–
–
JDK 1.1
19 февраля 1997
JPE
май 1998
J2SE 1.2
08 декабря 1998
J2EE 1.2
12 декабря 1999
J2SE 1.3
08 мая 2000
J2EE 1.3
24 сентября 2001
J2SE 1.4
06 февраля 2002
J2EE 1.4
11 ноября 2003
J2SE 5.0
30 сентября 2004
Java EE 5
11 мая 2006
Java SE 6
11 декабря 2006
Java EE 6
10 декабря 2009
Java SE 7
07 июля 2011
Java EE 7
12 июня 2013
Java SE 8
18 марта 2014
Java EE 8
21 сентября 2017
Java SE 9
21 сентября 2017
Таблица 2. История версий Java SE и Java EE [40] [37].
Java ME предназначена для таких устройств как сотовые телефоны,
датчики, принтеры и т.п. и менее популярна чем Java SE и Java EE [38].
Основными элементами языка Java являются классы, интерфейсы,
перечисления, аннотации, ошибки, исключения, пакеты и модули. Модули
рассматриваются во второй главе работы, а остальные элементы кратко
рассматриваются далее.
По мере разработки программы количество исходных файлов может
быть очень значительным, что требует механизма для их управления.
Именно этой цели и служат пакеты, которые являются конструкциями
видимости для организации элементов и обеспечения управления
пространством имен. В файловом пространстве пакет это отдельная папка.
Очевидно, что один пакет (одна папка) может включаться в другой пакет
(другую папку). Для того, чтобы обозначить пакет используется ключевое
слово package. Для того, чтобы было удобно использовать элемент (без
указания его полного имени) используется ключевое слово import [7, с. 77-
79].
Интерфейс это элемент, который описывает, что классы должны
делать без описания того, как они должны это делать. Другими словами
13
данные элементы позволяют отделить интерфейс (интерфейс) от
реализации (класс). Класс может реализовать один или несколько
интерфейсов [10, c. 242].
package me.pavel;
public interface Manager{
public void register(Object object);
public void unregister(Object object);
}
Листинг 1. Пример интерфейса Manager.
В листинге 1 приведен пример интерфейса. Данный интерфейс
находится в пакете me.pavel. Интерфейс определяет два метода register и
unregister. Указанные методы имеют модификатор доступа public, который
можно опустить, так как в Java все методы интерфейса могут быть только
public. Один интерфейс может наследовать методы другого интерфейса.
Основа объектно-ориентированного программирования и языка Java
классы и объекты, созданные из классов. Инициализация объектов
осуществляется в конструкторах, в то время, как изменение состояние
объекта осуществляется через методы [16, с. 185].
Поле это объект любого типа с которым можно работать по ссылке
или примитивный тип. Если это ссылка на объект, тогда необходимо
инициализировать эту ссылку и связать ее с существующим объектом
(используя оператор new) [4, с. 47]. Поля могут быть как статическими
(принадлежат классу), так и экземплярными (принадлежат объекту).
В языках С и С++ используется термин функция, чтобы описать
наименованную подпрограмму (англ. subroutine). В Java применяется,
обычно, термин метод. Метод определяет сообщение, которое
объект/класс могут получить. Основными составляющими метода
являются имя, аргументы, возвращаемые тип и тело метода [4, с.48].
14
Методы также могут быть как статическими (принадлежат классу), так и
экземплярными (принадлежат объекту).
В Java один класс может иметь только один прямой родительский
класс, однако, может реализовывать неограниченное количество
интерфейсов. Важно также отметить и поддержку вложенных классов,
которые определяются внутри другого класса: статические, внутренние,
локальные и анонимные. В листинге 2 приведен пример класса, который
реализует интерфейс из листинга 1.
package me.pavel;
import java.util.*;
public class DefaultManager implements Manager{
private final Set<Object> objects;
public DefaultManager(){
objects=new HashSet<>()
}
@Override
public void register(Object object){
objects.add(object);
}
@Override
public void unregister(Object object){
objects.remove(object);
}
}
Листинг 2. Пример класса DefaultManager.
Перечисления это специальный тип данных, который позволяет дать
переменной значение одной из заранее определенных констант.
Перечисления полезны в тех случаях, когда существует ограниченный
набор значений, которым переменная должна быть равна [6, c. 157]. В тоже
время, каждая константа перечисления является объектом, что позволяет
устанавливать для нее поля, методы и конструкторы – см. листинг 3.
15
Следует отметить, что конструктор в этом случае не может содержать
модификатор public.
package me.pavel;
public enum Fruit {
ORANGE(1), APPLE(2);
private int id;
Fruit(int id){
this.id=id;
}
public int getId(){
return this.id;
}
}
Листинг 3. Пример перечисления Fruit.
Аннотации это форма метаданных, которые обеспечивают данные о
программе и которые сами не являются частью программы. Аннотации не
имеют прямого воздействия на код, который они сопровождают.
Аннотации могут быть использованы в следующих случаях:
1. Информация для компилятора. В этом случае аннотации используются
компилятором для обнаружения ошибок и подавления предупреждений.
2. Обработка во время компиляции и во время развертывания.
Программные инструменты могут обрабатывать аннотации для генерации
кода, XML файлов и т.п.
3. Обработка во время выполнения кода. Некоторые аннотации
доступны для обработки во время выполнения кода [44].
Например, в листинге 2 применяется аннотация @Override, цель
которой указать, что обозначаемый метод должен переопределить метод в
супертипе [50].
Ошибки и исключения это классы и объекты, которые используются
для идентификации ненормальной ситуации. Тип ошибки и исключения
16
определяется по классу объекта, который передается виртуальной
машиной. На рисунке 1 представлена иерархия классов.
Рисунок 1. Иерархия классов ошибок и исключений (UML) [34].
Ошибки это, как правила, такие ситуации, после которых программа
прекращает работу, вот почему, ошибки не обрабатываются. Например,
сбой в работе виртуальной машины. RuntimeException это
исключительные ситуации, которые следует обрабатывать. UserException
это исключительные ситуации, которые необходимо обрабатывать.
1.2. Модульность ПО – основные понятия, концепции и преимущества
Модульность (англ. modularity) это такой подход к созданию
системы, при котором создаваемая система делится на небольшие части,
называемые модулями (англ. module), которые могут создаваться и
использоваться независимо друг от друга [46].
Важно отметить существование двух представлений модуля –
логического представления и физического представления. Под логическим
представлением модуль рассматривается как единая небольшая часть
системы с определенной функциональностью. Под физическим
представлением модуль рассматривается как один или несколько файлов.
Модульный метод проектирования соответствует определенным
критериям, определенным правилам, которым должны следовать
разработчики и определенным принципам, которые должны соблюдаться –
17
см. рисунок 2 [1, c. 53-54]. Указанные критерии, правила и принципы
кратко рассматриваются далее.
Рисунок 2. Критерии, правила и принципы модульного подхода [1].
Декомпозиция. Термин декомпозиция имеет два основных значения.
Во-первых, он обозначает разделение целого на части. Во-вторых, данный
термин обозначает научный метод, который позволяет заменить решение
одной сложной и/или большой задачи решением нескольких простых
и/или меньших задач [20].
Таким образом, метод проектирования соответствуют критерию
декомпозиции, если он дает возможность преобразовать сложную задачу в
несколько более простых и независимых задач, чтобы разработчики могли
работать отдельно над каждой из них [1, c. 55].
Композиция. Термин композиция означает составление целого из
частей [21].
Метод проектирования соответствует критерию композиции, если он
позволяет осуществлять разработку таких элементов системы, которые
Модульный подход
Критерии:
1. Декомпозиция.
2. Композиция.
3. Понятность.
4. Непрерывность.
5. Защищенность.
Правила:
1. Прямое отображение.
2. Минимум интерфейсов.
3. Слабая связность интерфейсов.
4. Явные интерфейсы.
5. Скрытие информации.
Принципы:
1. Лингвистические модульные
единицы.
2. Самодокументирование.
3. Унифицированный доступ.
4. Открыт – закрыт.
5. Единственный выбор.
18
возможно свободно объединять друг с другом для создания новой
системы. Важно отметить, что новые системы могут значительно
отличаться от той системы, для которой определенный элемент
предназначался и иметь свой собственный контекст. Данное условие
возможно только в том случае, если каждый элемент системы имеет
высокий уровень автономности [1, c. 57-58].
Понятность. Метод проектирования удовлетворяет критерию
понятности, если в результате применения данного метода получаются
такие модули, содержание которых можно понять без понимания
содержания других модулей, или, по крайней мере, после ознакомления
лишь с некоторыми модулями.
Важность данного критерия объясняется тем, что чем выше
понятность модуля, тем легче разработчикам осуществлять работу над ним
на всех этапах – проектирования, разработки, тестирования, как во время
разработки системы, так и при ее сопровождении [1, c. 59-61].
Непрерывность. Термин непрерывность используется по аналогии с
непрерывностью числовой функции в математике, под которой понимают
такое свойство, при котором малые изменения аргумента функции
приводят к малым изменениям значения функции [22].
Следовательно, метод проектирования соответствует критерию
непрерывности, если небольшие изменения в спецификации программной
системы могут быть реализованы за счет изменения одного или очень
ограниченного количества модулей [1, c. 59-61].
Защищенность. Метод проектирования удовлетворяет условию
защищенности, если исключительная ситуация (ошибка, исключение),
которая возникала во время исполнения программы в одном модуле, не
распространится на другие модули, или, в худшем случае, затронет только
соседние модули.
19
Важность данного критерия объясняется тем, что он позволяет
создавать устойчивые к сбоям программные системы, что особенно
необходимо при разработке долго функционирующих систем, таких, как
банковские системы, космические системы и т.п.
Из описанных выше критериев следуют пять правил, которые кратко
рассматриваются далее.
Прямое отображение. Любая программная система связана с
определенной предметной областью и моделью данной области, которая
является абстрактным представлением области. Хорошо построенная
модель должна иметь четкую структуру.
Согласно правилу прямого отображения модульная структура
программной системы должна соответствовать модульной структуре
модели предметной области.
Минимум интерфейсов. В соответствии с правилом минимума
интерфейсов программная система должна проектироваться таким
образом, чтобы между модулями было минимальное количество связей.
Например, при трех модулях максимально возможное количество
связей между модулями равно трем: модуль 1 – модуль 2, модуль 2 –
модуль 3, модуль 3 – модуль 1. Следуя данному правилу, нужно
спроектировать систему таким образом, чтобы между модулями было
только две связи, например: модуль 1 – модуль 2, модуль 1 – модуль 3.
Слабая связность интерфейсов. В соответствии с этим правилом, два
модуля должны обмениваться минимальным объемом информации. Важно
подчеркнуть, что если правило минимум интерфейсов связано с
количеством связей между модулями, то правило слабой связности
интерфейсов связано с объемом данной связи.
Явные интерфейсы. Правило явных интерфейсов гласит, что если
между двумя модулями существует связь, то данная связь должна
20
основываться на хорошо известном интерфейсе. Нарушение данного
правила значительно усложняет разработку программной системы и может
привести к серьезным ошибкам.
Скрытие информации. Согласно данному правилу для каждого
модуля должна быть выбрана информация, которая необходима для
использования данного модуля и только которая делается общеизвестной.
Данная информация, как правило, указывается в официальной
документации. Информация, которая не является необходимой для
использования модуля, скрывается.
Из приведенных выше критериев и правил следуют пять принципов,
которые приводятся далее.
Лингвистические модульные единицы. Принцип лингвистических
модульных единиц выражается в том, что используемый язык
(проектирования, программирования и т.п.) должен поддерживать
модульные конструкции на всех этапах разработки – анализа,
проектирования, реализации, тестирования. Нарушение данного принципа
(например, когда на этапе проектирования используется язык
поддерживаемый модули, а на этапе реализации используется язык
неподдерживаемый модули) может в такой мере осложнить разработку
проекта, что дальнейшая работа над проектом может быть признана
бесперспективной.
Самодокументирование. Согласно данному принципу, вся
информация о модуле должна содержаться в самом модуле. Этот принцип
объясняется тем, что даже сегодня, когда существуют общепринятые
стандарты разработки и большое количество лучших практик, некоторые
разработчики выносят информацию о модуле в отдельную документацию,
что приводит к тому, что между модулем и документацией быстро
возникают противоречия. Данный принцип, в свою очередь, направлен на
21
то, чтобы информация о модуле была максимально достоверной и
актуальной.
Унифицированный доступ. В соответствии с принципом
унифицированного доступа все службы, которые предоставляются
модулем, должны быть доступны другим модулем через
унифицированную нотацию. Например, если в языке Java объявляется
сервис как объект (Service service = ServiceFactory.getService();), то
использование методов сервиса осуществляется через оператор точки
(service.someMethod();).
Открыт – Закрыт. Данный принцип выражается в том, что каждый
модуль должен находиться в одном из двух состояний – быть открытым
или закрытым.
Открытым называется такой модуль, интерфейсы которого
разработчики могут расширять или модифицировать.
Закрытым называется такой модуль, интерфейсы которого
разработчики не должны расширять или модифицировать, так как такие
изменения приведут к необходимости вносить изменения и в модули-
клиенты. Таким образом, закрытость модуля направлена на
предотвращения такой ситуации, когда небольшое изменение одного
модуля может повлечь множественные изменения других модулей.
Единственный выбор. Согласно данному принципу, если модуль
осуществляет работу над определенным перечнем данных, который может
со временем расширяться, то только этот модуль должен знать полный
перечень этих данных. Принцип единственного выбора объясняется тем,
что если существуют другие модули, которым необходимо знать весь
перечень данных, то при каждом изменении (добавлении или удалении)
данных необходимо осуществлять изменение в многих модулей, что