<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Развитие метода адаптивной кластеризации путем формирования концептуальной модели объекта информатизации</article-title>
      </title-group>
      <fpage>238</fpage>
      <lpage>246</lpage>
      <abstract>
        <p>The Method of Adaptive Clustering (MAC) determines the order of formation of functional requirements and functional appearance of the projected information system. The article deals with the evolution of the MAC producing a conceptual data model from the functional model. Based on the data model, the order of building the software components of the information system is defined, which are methods encapsulated in data model objects. Аннотация. Метод адаптивной кластеризации (МАК) определяет порядок формирования функциональных требований и функционального облика проектируемой информационной системы. В статье рассматривается развитие МАК в части продуцирования концептуальной модели данных, выводимой из функциональной модели. На основе модели данных определяется порядок построения программных компонент информационной системы, представляющих собой методы, инкапсулированные в объекты модели данных. Ключевые слова: информационная система, метод адаптивной кластеризации, концептуальная информационная модель, сеть Петри, методы классов, МАК, UML Метод адаптивной кластеризации информационных систем (МАК) - это нисходящий функциональный сервис-ориентированный метод визуального проектирования ИС, предназначенный для формирования облика создаваемой ИС как на уровне ее использования (бизнес-уровень), так и в части специфицирования ее программных компонент (кластеров). [1] Используя метод декомпозиции бизнес-процесса, МАК определяет множество операций, которые представляют собой комплекс необходимых действий конкретного сотрудника на своем рабочем месте с целью получения полезного для бизнес-процесса промежуточного продукта. Ключевым свойством метода является установление связей между операциями бизнес-процессов и системными сервисами (архитектурными компонента-</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>ми системы). Это позволяет говорить об адаптивности метода, рассматриваемой
как реализация необходимой и достаточной функциональности системы,
отвечающей требованиям автоматизации бизнес-процессов заказчика.</p>
      <p>МАК определяет функциональную структуру ИС до уровня диалогов.
Требуется расширить представление функциональной структуры до методов
объектов, описывающих информационную структуру предметной области ИС. Для
этого необходимо включить в МАК возможности определения
информационной структуры ИС.</p>
      <p>Целью работы является определение алгоритма автоматизированной
идентификации объектов и связей между ними, определяющих информационную
структуру предметной области бизнес-процесса с возможностью перехода к
уровню концептуальной информационной модели. Объектом исследования
является модель бизнес-процесса и связи функциональных объектов
бизнеспроцесса с объектами предметной области.</p>
      <p>Для этого необходимо решить следующие задачи:
• Определить типы связей функциональных компонент бизнес-процесса с
информационными объектами.
• Сформулировать правила вывода информационной структуры предметной
области ИС из функциональной структуры бизнес-процесса.
• Описать переход от модели информационной структуры к концептуальной
информационной модели предметной области.
2
Существующие методы идентификации
информационных объектов
Методы идентификации объектов можно разделить на 2 группы [2]: анализ
текстов и анализ задачи.</p>
      <p>Метод анализа текстов основан на выделении существительных и глаголов в
тексте описания предметной области и интерпретации их в качестве классов,
атрибутов и методов. Алгоритмы, приводящие к идентификации объектов
методом анализа текстов, как правило, не дают хорошие результаты. Описание
метода приведено в [3], а варианты его автоматизации описаны в [4].</p>
      <p>Метод анализа задач предполагает декомпозицию общей задачи
автоматизации на иерархию задач следующих уровней. Информационные объекты
возникают, как атрибуты определяемых методов (подзадач). Метод анализа задач
слабо формализуем и только случайно может выявить какие-либо
концептуальные информационные объекты. Методу посвящена работа [5].
3</p>
      <p>Связи функциональных и информационных объектов
Классическое определение бизнес-процесса [6]: комплекс действий, в котором
на основе одного или более видов исходных данных создается ценный для
клиента результат.</p>
      <p>Будем называть исходным ресурсом (ИР) все виды исходных данных,
поступающие на вход некоторого функционального объекта (комплекса действий),
результатом которого является целевой продукт (ЦП).</p>
      <p>Будем говорить, что ЦП выводим из ИР комплексом действий и отношение
между ИР и ЦП будем обозначать именованной направленной ассоциацией
(Рис. 1. , вариант a)1.</p>
      <p>Стереотип «Тип активности» в обозначении действия может принимать
значения «Бизнес-функция», «Бизнес-операция», «Диалог».</p>
      <p>Другой тип связи между ИР и ЦП соответствуют случаю, когда ЦП
относится к действию, предшествующему действию, на вход которого поступает ИР
(Рис. 1. , вариант b). В этом случае ИР не обязательно должен совпадать с ЦП,
но однозначно им определяться. В модели отношение ЦП→ИР обозначается не
именованной направленной ассоциацией от ЦП к ИР с именованием ролей
источника и приемника.</p>
      <p>Будем говорить, что информационные объекты предопределены в системе
(Рис. 1. , вариант c), если они
• определены в моделируемом экземпляре бизнес-процесса ранее;
• возникли в рамках иных бизнес-процессов (например, справочники).
Предопределенные объекты играют роль дополнительных к основному ИР.
Целевой продукт также выводим из предопределённого информационного
объекта и так же в модели связь обозначается именованной направленной
ассоциацией от ИР к ЦП.
4
Правила построения сети Петри, изоморфной модели
бизнес-процесса
Представим функциональную модель маркированной сетью Петри с двумя
типами переходов</p>
      <p>= (, , , , ),
где P – множество позиций, T – множество переходов, I, O – входная и
выходная функции, отображающие переходы в комплекты позиций, – маркировка
сети Петри.</p>
      <p>Множество позиций сети Петри функциональной модели</p>
      <p>= ( , , … , ), ≥ 0
делится на четыре непересекающихся подмножества</p>
      <p>= (, , , ), ⋂(, , , ) = ∅.
1 Модели, представленные в данной работе, выполнены в приложении Enterprise
Architect компании Sparx Systems [7].
Рис. 1. Типы информационных связей ИР и ЦП
Здесь N – множество новых, еще не определенных позиций</p>
      <p>= ( , , … , ), ≥ 0.</p>
      <p>K – множество предопределенных (определенных в иных функциональных
моделях), позиций:</p>
      <p>= ( , , … , ), ≥ 0.</p>
      <p>D – множество уже определенных при выполнении сети Петри позиций
=</p>
      <p>1, 2, … , , ≥ 0,
∀ ∈ : = ( ) ∨ = ( ) ∈ .</p>
      <p>C – позиции, управляющие запуском переходов второго типа</p>
      <p>
        = ( 1, 2, … , ), ≥ 0.
При этом, если () множество переходов второго типа, то | | =
Типы переходов:
() .
(
        <xref ref-type="bibr" rid="ref1">1</xref>
        ) =
(2) =
(
        <xref ref-type="bibr" rid="ref1">1</xref>
        ) (
        <xref ref-type="bibr" rid="ref1">1</xref>
        )
1 , 2 , … ,
      </p>
      <p>
        Пара = ( (
        <xref ref-type="bibr" rid="ref1">1</xref>
        ), (2)) определяет порядок следования переходов в модели.
Тогда множество переходов сети Петри определяется как
      </p>
      <p>= ( , , … , , ), ≥ 0.</p>
      <p>Входная позиция для любого типа перехода определяется как ∈ (∗) , а
выходная – ∈ (∗) .</p>
      <p>Начальная маркировка определяется как
∃ ∈ : ( ) = ∞ ; ∀ ∈ , ≠ : = 0:</p>
      <p>∀ ∈ : ( ) = ∞;
∃ ∈ : ( ) = 1, ∀ ≠ : = 0.</p>
      <p>Начальные позиции и являются входными для переходов,
принадлежащих одной и той же упорядоченной паре :</p>
      <p>( ) = , ( ) = , где ( ), ( ) ∈ .
Перед выполнением сети Петри = ∅ . Если в ходе выполнения</p>
      <p>∀ ∈ , ∈ : ( ) = или ( ) =
то = − , а = + ( → ).</p>
      <p>Условие завершения выполнения сети Петри: = ∅ и все переходы
запрещены.</p>
      <p>
        Правила построения сети Петри функциональной модели для всех позиций:
1. Входные и выходные позиции сети представляют собой подмножества (не
комплекты) позиций:
∀ ,
∈ , ∈ : #
, ( ) = (
        <xref ref-type="bibr" rid="ref1">0,1</xref>
        ) и #
, ( ) = (
        <xref ref-type="bibr" rid="ref1">0,1</xref>
        ).
2. На вход перехода первого типа могут поступать не более одной не
определенной позиции и неограниченное число других типов позиций, т.е. ∀ ∈
() , ∈ , ∈ , ∈ :
      </p>
      <p>
        #, ( ) = (
        <xref ref-type="bibr" rid="ref1">0,1</xref>
        ); #, ( ) ≥ 0; #, ( ) ≥ 0.
3. На вход перехода второго типа поступает одна определенная и одна
управляющая позиция, т.е. ∀ ∈ ( ), ∃ ∈ , ∈ :
      </p>
      <p>#, ( ) = 1; #, ( ) = 1.
4. Для всех типов переходов количество выходных позиций равно 1:
∀ ∈ : | ( )| = 1.
5. В качестве выходной позиции для перехода любого типа не может быть
предопределенная позиция, т.е. ∀ ∈ , ∈ :</p>
      <p>#, ( ) = 0.
6. Переход второго типа может сработать только один раз, так как в его
входной управляющей позиции только одна фишка.</p>
      <p>Правила именования позиций сети Петри:
• управляющие позиции не именуются
• остальные позиции получают имена соответствующих информационных
объектов функциональной модели.
Переходы первого типа именуются соответствующими наименованиями
действий. Переходы второго типа изображаются двумя параллельными отрезками:
входным и выходным. Входной отрезок получает имя входного действия,
выходной – выходного действия функциональной модели.</p>
      <p>Рис. 2 демонстрирует правила перехода от функциональной модели к
эквивалентной сети Петри.
Рис. 2. Описание функциональной модели сетью Петри с двумя типами переходов
Формирование информационной структуры предметной
области
Будем называть предварительной моделью данных модель, автоматически
продуцируемую из соответствующей сети Петри. Предварительная модель данных
определяет информационную структуру предметной области бизнес-процесса.</p>
      <p>Будем исходить из того, что все программные компоненты инкапсулируются
в действия, то есть программной обработки при переходе второго типа не
происходит. Это означает, что формирование выходных позиций производится на
уровне постусловий действия, а входных – на уровне предусловий.</p>
      <p>С учетом этого применяются следующие правила формирования
предварительной модели:
1. Переход первого типа всегда порождает связи между входной и выходной
позицией.
2. Если на выходе перехода второго типа определённая позиция, то связь с
входной не возникает.
3. Если на выходе перехода второго типа не определенная позиция, то эта
позиция выводится предусловием из входной.
5.6. Переход второго типа. Связать входную и выходную позицию
направленной ассоциацией, присвоив началу имя входного отрезка
перехода, а концу – выходного отрезка.
6. Перейти на шаг 4.
7. Если не пуст список не определенных позиций сообщить о некорректном
построении сети Петри.
8. Конец алгоритма.
6</p>
      <p>Формирование концептуальной информационной модели
В результате автоматического продуцирования предварительная модель данных
обладает избыточным количеством связей между информационными объектами
и определяет только один тип связей между ними (направленную ассоциацию).</p>
      <p>Избыточность появляется в связи с тем, что в модели бизнес-процесса
различные действия могут оперировать одними и теми же парами ИР и ЦП. При
формировании предварительной модели без учета смысла этих связей
невозможно определить ее обоснованность и необходимость: связь может быть
ролевой, а может дублировать уже существующую. Предварительная модель данных
также не может учесть характер связей между сущностями и требования к
нормализации. Поэтому переход к концептуальной модели выполняется вручную.</p>
      <p>Для преобразования предварительной модели данных в концептуальную
информационную модель (Рис. 3. ) необходимо:
• Проанализировать модель и удалить лишние связи.
• Интерпретировать и заменить типы связей на ассоциацию, генерализацию,
композицию или агрегацию.
• Нормализовать концептуальную информационную модель.
Вместе с тем, применение алгоритма продуцирования предварительной модели
данных позволило поднять качество и сократить временные затраты в процессе
анализа сложных информационных систем за счет:
• сфокусированного выделения информационных объектов в процессе
моделирования автоматизируемого бизнес-процесса,
• минимизации затрат на процесс идентификации объектов предметной
области и связей между ними,
• и, как следствие, сокращения проектных итераций.
Рис. 3. Преобразование предварительной модели данных в концептуальную
информационную модель</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1. Г. Н. Циперман, «
          <article-title>Применение метода адаптивной кластеризации для проектиро- вания сложных информационных систем,» в III Научно-практическая конференция «Актуальные проблемы системной и программной инженерии»</article-title>
          .
          <source>Сборник научных трудов, Москва</source>
          ,
          <year>2013</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          3.
          <string-name>
            <surname>Abbot</surname>
            <given-names>R.J.</given-names>
          </string-name>
          , «
          <article-title>Program Design by Informal English Descriptions» Communications of the ACM, т</article-title>
          .
          <volume>26</volume>
          , №
          <volume>11</volume>
          , pp.
          <fpage>882</fpage>
          -
          <lpage>894</lpage>
          ,
          <year>1983</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          4.
          <string-name>
            <surname>Saeki</surname>
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Horai H. и Enomodo</surname>
            <given-names>H.</given-names>
          </string-name>
          ,
          <source>«Process from Natural Language Specification» в Proceedings of the 11th International Conference on Software Engineering Software Development</source>
          , New-York,
          <year>1989</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          5.
          <string-name>
            <surname>Daniels</surname>
            <given-names>P.J.</given-names>
          </string-name>
          , «
          <article-title>The user modelling function jf an intelligent interface for document retrieval systems»</article-title>
          <source>Intelliget Information Systems for the Information Society</source>
          , pp.
          <fpage>162</fpage>
          -
          <lpage>176</lpage>
          ,
          <year>1986</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          7.
          <string-name>
            <given-names>Sparx</given-names>
            <surname>System Pty Ltd</surname>
          </string-name>
          , «Enterprise http://sparxsystems.com/products/ea.
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>