Навигация
2.2. Выбор инструментария
Для решения поставленной выше задачи целесообразно использовать модификацию языка JAVA для реализации сложных приложений распределенных предприятий J2EE (JAVA 2 Enterprise Edition). Следует сказать, что язык J2EE делает упор не на библиотеки, а на набор связанных спецификаций и рекомендаций, которые собраны вместе для построения многоуровневых кроссплатформенных приложений. В данном контексте под спецификациями понимаются стандартизованные данные и методы их обработки, которые включены в платформу. При этом рекомендации представляют собой примеры реализаций по определенным предметным областям в соответствии со спецификой и особенностями применения.
Выбор языка J2EE в качестве исходной базы связан с тем, что именно он и его платформа рассматривается разработчиками JAVA, как наиболее перспективная среда проектирования и разработки распределенных JAVA приложений. Данная среда была специально модернизирована для поддержки современных требований для распределенных приложений.
3. Описание системы
Как уже отмечалось, язык GJE сделан в виде расширения к существующему и широко используемому языку JAVA. Автором предполагается, что сделанные на этом языке приложения можно будет использовать во всех трех существующих реализациях конечных приложений на JAVA, а именно – локальных приложений Application, удаленно исполняемых приложениях Applet и серверно- тиражируемых приложениях Servlet.
Технически язык GJE представляет собой внешнее расширение пакетов JAVA для решения задач документооборота и описан как package javax.workflow. Это дает возможность разработчиками подключать пакет и использовать его для решения задач документооборота.
Язык GJE позволяет строить модели документооборота, которые основаны на аппарате теории графов. Автором настоящей статьи в работе [3] введена графовая модель документооборота. Поэтому, при описании классов будет даваться не только общее назначение методов и данных с точки зрения графа как математического понятия, но и применения содержания классов, введенное в модели документооборота.
3.1. Описание интерфейсов языка GJE
Ниже приведено описание интерфейсов классов, являющихся основой языка GJE. Эти классы имеют тип “public”, поэтому они составляют основу построения конструкций документооборота на языке JAVA. Выбранная открытость реализации внешнего пакета обеспечивает возможность внесения модификаций в язык с учетом особенностей конкретных реализаций документооборота.
3.1.1. Класс Node
Класс Node представляет описание единицы нижнего уровня графа – вершины графа. Вершина графа является начальным элементом построения структуры, поэтому она не содержит методов, а содержит только значение, свойственное именно данной конкретной вершине. Как известно, совокупность вершин и их связи определяют граф.
В документообороте, множеству вершин графа соответствует множество состояний документов, используемых в моделируемом документообороте. Каждая отдельная вершина соответствует отдельному состоянию документа, выделение которого считается целесообразным при дискретизации процессов документооборота. Семантическими данными этого класса является содержательная часть документа. Такими данными могут быть текст, звук, видео и другие данные, которые могут быть задействованы в рамках используемых операционных систем и средств разработки.
При реализации документооборота, исходя из свойств языка JAVA, класс может быть расширен дополнительными методами обработки или данными. Такими данными может быть информация, которая не была известна на момент проектирования системы, а актуализировалась во время ее внедрения. Это дает возможность наращивать систему, при этом не нарушая основных правил.
Ниже приведен текст интерфейса класса Node.
package javax.workflow;
public interface Node
{
Object getValue();
void setValue(Object value) throws InvalidOperation;
}
3.1.2. Класс Edge
Класс Edge используется для описывания ребер графа. Ребро графа является базовым элементом аппарата теории графов и характеризуется тем, что соединяет одну или более вершин. Ребро может быть ненаправленным, то есть просто выступать элементом связности, упорядочивающим отношения между вершинами. Направленное ребро, кроме установления факта связности, еще и определяет последовательность в иерархии, то есть указывает на причинно- следственную связь между вершинами.
В применении к графовой модели документооборота, введенной автором в работе [3], вершина графа ассоциируется с действием, которое производит участник документооборота над документом. Если говорить более строго в терминах введенной модели, то ребро графа, описывающего модель документооборота является действием, произведение которого вызывает смену состояния документа с начального на промежуточное либо конечное. Соответственно, входящей вершиной графа является входящее для действия состояния документа. После произведения действия, установленного на ребре графа, документ принимает состояние, соответствующие исходящей вершине графовой модели.
Класс Edge содержит методы getInPoint и getOutPoint, которые используются для получения входящих и исходящих вершин соответственно. Метод getDirection получает данные, которые соотвествуют направленности ребра. Метод getDirection имеет тип Object , поскольку направленности ребра могут соответствовать не только собственно значение указания направленности, а и различные весовые характеристики ребра. Метод setDirection используется для принудительного установления свойств направленности.
Методы getValue и setValue предназначены для получения и установления дополнительных свойств ребра. В применении к задачами документооборота, это означает возможность введение дополнительной информации, свойственной действию. В частности, такой информацией является информация об исполнителях документооборота, которые могут либо должны производить это действие.
Ниже приведен текст интерфейса класса Edge.
package javax.workflow;
public interface Edge
{
Node getInPoint();
Node getOutPoint();
Object getDirection();
void setDirection(Object direction) throws InvalidOperation;
Object getValue();
void setValue(Object value) throws InvalidOperation;
}
Похожие работы
... , а иногда и невозможным. Недостатки MOLAP-модели: · Многомерные СУБД не позволяют работать с большими базами данных. · Многомерные СУБД по сравнению с реляционными очень неэффективно используют внешнюю память. В подавляющем большинстве случаев информационный гиперкуб является сильно разреженным, а поскольку данные хранятся в упорядоченном виде, неопределенные значения ...
... , "базовые" алгоритмы: поиск путей, определение компонент связности графа и т.д. 8. Ввод/вывод графов Одной из проблем при создании средств работы с помеченными графами является выбор внешнего файлового формата для хранения графов. До недавнего времени каждая программная система использовала свой собственный, уникальный формат, что приводило к сложностям при организации обмена данными. ...
... , которые соответствуют определённым процедурам преобразования информации. Эффективная реализация таких процедур обеспечивается оформлением их в виде специальных макрокоманд и включением последних в язык программирования, доступный программисту. Макрокоманды переводятся в машинные команды двумя пу-тями – расстановкой и генерированием. Развитые автокоды получили название Ассемблеры. 3.1.4 Макрос ...
... и в то же время мощного математического аппарата, опирающегося главным образом на теорию множеств и математическую логику и обеспечивающего теоретический базис реляционного подхода к организации баз данных; 3. возможность ненавигационного манипулирования данными без необходимости знания конкретной физической организации баз данных во внешней памяти. Однако реляционные системы далеко не ...
0 комментариев