CC BY
47
УДК 004.822
И. И. Бикмуллина, И. А. Барков, А. П. Кирпичников РАЗРАБОТКА МЕТОДИКИ АВТОМАТИЗИРОВАННОГО СИНТЕЗА ИНФОРМАЦИОННЫХ СИСТЕМ НА ОСНОВЕ СЕМАНТИЧЕСКИХ ОТНОШЕНИЙ ПРЕДМЕТНОЙ ОБЛАСТИ
Ключевые слова: UML, синтез диаграммы классов.
Рассмотрена задача автоматизированного структурного синтеза информационных систем на основе семантических отношений предметной области. Предложен искусственно интеллектуальный подход к автоматизированной разработке информационных систем, усовершенствование современной технологии за счет автоматизированного синтеза диаграмм классов UML на основе семантических моделей.
Keywords: UML, synthesis of class diagrams.
The paper considers the problem of automated structural synthesis of information systems based on the semantic relations of subject area. We propose an artificially intelligent approach to automated information systems development, improvement of modern technology at the expense of automated synthesis the UML class diagrams on based on semantic models.
Введение
Задача изготовления программного изде-лия(ПгоИзд) сводится к тому, чтобы получить изделие требуемой спецификации. В объектно-ориентированной технологии создания программных изделий спецификация ПгоИзд задается системой диаграмм. Система диаграмм - это свойства и основа изготовления ПгоИзд. Таким образом, необходимым условием существования ПгоИзд является спецификация ПгоИзд в виде системы диаграмм. В настоящее время технология получения ПгоИзд на основе спецификации ПгоИзд в значительной мере изучена и автоматизирована.
Следующий этап автоматизации проектирования программных изделий в рамках объектно-ориентированной технологии создания программных изделий заключается в автоматизации процесса синтеза диаграмм с использованием заранее созданной спецификации предметной области (ПрО) решаемой задачи. Спецификацию ПрО часто называют онтологией ПрО (ОнЯ). Остановимся на определении ОнЯ применительно к задачам информационного поиска [1]. Таким образом, ОнЯ - это некоторое представление мира относительно интересующей ПрО. У такого представления компонентами являются: термины и правила применения данных терминов, определяющих границы значений данных терминов в рамках рассматриваемой ПрО. Формально ОнЯ - это система понятия, а также утверждений о понятии, на основе которых моделируются классы, определяются отношения между классами. Поэтому компонентами ОнЯ будут: классы из понятий, отношения, функции, аксиомы, шаблоны. В данной работе ОнЯ будет рассматриваться как система на базе математически точных аксиомах и логике предикатов первого порядка, дескриптивной, модальной и т.п. (формальная система).
Рассматривается двухуровневая технология проектирования программных изделий. Верхний уровень технологии ориентирован на получение автоматизированным или автоматическим способом спецификации ПгоИзд с помощью предварительно подготовленной спецификации ПрО и некоторого задания,
целью которого является инициализация процесса получения конкретной спецификации.
Использование ОнЯ для процессов синтеза конкретных объектов и процессов отличается переходом от обработки данных к обработке смыслов. В настоящее время активно формируется научное направление «компьютерная семантика».
Семантические определения
Процесс изготовления ПгоИзд - это придание программным конструкциям желаемых свойств, адекватно отражающих необходимые черты моделируемой ПрО.
Свойство представляет собой категорию, выражающую такую сторону предмета, которая обуславливает его различие или общность с другими предметами и обнаруживается в его отношении к ним [2]. Итак, свойство является чертой, характеризующей данную ПрО и позволяющая точно определить программное изделие при необходимой степени декомпозиции. При отсутствии этой черты программное изделие превращается в другое изделие.
Свойства ПгоИзд описывается в зависимости от особенностей программного изделия, рассматриваемое как техническое средство, инструмент решения поставленных задач. Особенность - это черта, характеризующая объект с точки зрения его связи с другими объектами: возможности превращения в другой объект под давлением другого объекта, возможности влияния на другой объект. Также программное изделие должно иметь комплекс особенностей. Одной из таких особенностей является та операционная среда, благодаря которой программное изделие превращается в инструмент решения задач автоматизации. Особенность ПгоИзд как технического средства - это отношение данного ПгоИзд к другим объектам (естественным и искусственным), с которыми программное изделие взаимодействует. Таким образом, особенность - это характерная черта чего-то по отношению к другим предметам. В этом смысле прикладная программа обладает набором
свойств, которые позволяют решать возложенную на нее прикладную задачу. Вычислительная среда, наоборот представляет собой лишь особенность, так как черта, не зависит от прикладной задачи.
Все сказанное относится в полной мере к автоматизируемой предметной области. Например, в задачах моделирования свойств стали необходимо учитывать как свойства самой стали (например, упругость, пластичность, прочность), так и такую особенность, как коррозия, так как данная черта, зависит не только от свойств самой стали, но и свойств внешней среды.
Природа специфики в понимании свойств ПгоИзд основывается на разнообразии вариантов абстрагирования, использующихся в разных науках. Отличия типов исследуемых свойств, способов моделирования данных типов во многом определяется дифференциацией наук.
Понятие «свойство программного изделия» -это некоторое высказывание, связанное с смысловым понятием: в работе [2] смысл - это содержание высказывания.
Так как задача смыслоотождествления рассматривается в языкознании, то существует возможность применить лингвистические приемы для описания свойств ПгоИзд. В первую очередь это касается науки конструирования диаграмм, науки о языках, информатики.
В дальнейших рассуждениях мы интенсивно будем использовать термин «понятие».
Проведем краткий обзор трактовки понятия из разных научных дисциплин, чтобы разобраться, что же представляет собой понятие. К развитию понятий и терминов стремится каждая научная дисциплина.
Энциклопедия характеризует понятие, как форму мышления, отражающую существенные свойства, связи и отношения предметов и явлений в их противоречии и развитии. Мысль или система мыслей, обобщающая, выделяющая предметы некоторого класса по определенным общим, а также в совокупности специфическим для них признакам [2]. Отсюда, понятие выделяет как общее, так и декомпозирует сами объекты (их свойства, отношения), классифицируя в соответствии с их особенностями. Так, понятие «человек» отражает как базовые свойства (характеризующие всех людей), и отличие любого человека от всех остальных.
Понятием является языковая модель, четко определяющая смысл. Понятие в отличие от термина (зафиксированного понятия, где смысл зафиксирован) не статично во времени, его смысл меняется достаточно динамично, но при этом сохраняя значительную стабильность. Любой научный термин нагружен базовым списком свойств (многие из которых лишь подразумеваются). И когда в математике говорится «множество», то неявно предполагается, что неважна последовательность его элементов и его элементы не повторяются и т.п. В моделировании деталей машин также имеется много примеров: «консоль», «вал», втулка» и т.п. Смысл этих терминов известен.
В автоматизированных системах современная обработка данных в основном работает с терминами. Для создания интеллектуальных автоматизированных
систем, в том числе и систем автоматизации проектирования программных изделий, нужно от терминов перейти к понятиям. Для этого нужно включить в обработку явным образом выписанные смыслы(все), которые обозначены конкретными терминами.
Так ниже приведен состав диаграммы классов UML:
Cl =<ConceptsUML, IdConcept, Syntax_Restriction>, где Cl - это диаграмма класса, которая состоит из массива понятий (ConceptsUM) рассматриваемой предметной области, понятия (Id Concept), представляющего идентификатор в описании класса понятий и описания синтаксических ограничений (SyntaxRestriction). Рассмотрим вышеизложенные компоненты диаграммы класса более подробно:
1.Отсюда, понятия (ConceptsUM) в диаграмме классов формализуются по принципу: ConceptsUML=<Concepts,Relations, Initial_Concept>, где понятия диаграммы классов состоят из множества понятия (Concepts), множества отношений (Relations) различного вида (иерархические, неиерархические) между данными понятиями и начального понятия (InitialConcept) в описании класса понятий. Рассмотрим вышеизложенные компоненты понятия диаграммы класса более подробно:
1.1.Concepts = {Concept conceptscount - конечное непустое множество понятий (включая Initial Concept), при этом Conceptjсостоит из: Concepti=<Conceptvalue,ConceptKind,ConceptrermType>, где ConceptValue- значение понятия; ConceptKind- тип понятия; ConceptTermType- тип терминального понятия.
1.1.1. Значение понятия включает в себя: Concept value=<Concept value_Type,Concept Value_ Value>, где значение понятия описывается своим типом ConceptValue_Type и значением ConceptValue_Value. ConceptValue_Type e {«Строковое», «Целое», «Вещественное», «Логическое», «Бинарные данные»}. Значение понятия есть непустая последовательность символов, которая идентифицирует определенный класс объектов описываемой предметной области, множество значений (сорт) или представляет в ней конкретное (константное) значение: ConceptValue_Value e String u Integer u Real u Boolean.
String - множество строк. Integer -множество целых чисел. Real - множество вещественных чисел. Boolean- множество {«true», «false»}. Значением понятия может быть последовательность символов, интерпретируемых как строковая константа (ConceptValue_Type = «Строковое»), целое число из множества целых чисел (ConceptValue_Type = «Целое»), вещественное число из множества вещественных чисел (Concept Value_Type = «Вещественное»), элемент множества {«true», «false»} (ConceptValue_Type = «Логическое»),
(ConceptValue_Type = «Бинарные данные»).
1.1.2. Тип понятия включает в себя: ConceptKind e {«Терминальное», «Нетерминальное»}. То есть понятие может быть терминальным (ConceptKjnd = «Терминальное») или
нетерминальным (ConceptKind = «Нетерминальное»).
1.1.3. Тип терминального понятия состоит из: ConceptTermType 6 {«Идентификатор», «Константа», «Сорт», «Не определено»}.
Терминальное понятие может быть идентификатором (ConceptТегтТуре=«Идентификатор»), константой (ConceptTermType=«Константа»), или обозначать некоторый сорт (Concept ^^^«Сорт»).
Если понятие Concepti является нетерминальным, то ConceptTermType = «Неопределено».
1.2. Relations = {Relationi=0}count- конечное, возможно пустое, множество отношений. Каждое отношение Relationi является направленным бинарным отношением, имеющим, возможно, спецификатор множественности и связывающим два понятия. Отношение описывается следующим образом: Relationj=<RelationEndSp,Begin_Concept,Enâ_Concepf>, где Relation EndSp - спецификатор множественности; BeginConcept - понятие-начало отношения; EnâConcept - понятие-конец отношения.
1.2.1. Спецификатор множественности (кардинальность) — характеристика отношения, определяющая способ порождения понятия-экземпляра вместе с отношением к нему по понятию-концу данного отношения:
RelationEndSp 6 {«Конкретность», «Единственность», «Множество»}, где
Relation EndSp= «Конкретность» (пустой спецификатор) означает, что может быть порождено только одно понятие-экземпляр и его значение (имя) должно совпадать со значением (именем) его понятия-прототипа
(EnâConcept).
Relation EndSp= «Единственность» означает, что по Enâ Concept может быть порождено только одно понятие- экземпляр, но его значение (имя) обязательно должно быть задано при порождении. Порожденное понятие при этом является сущностью из класса объектов или элементом из множества значений, идентифицируемого понятием-прототипом (EnâConcept) (строка, целое значение, вещественное значение, логическое значение).
RelationEndSp= «Множество» означает, что по Enâ_Concept может быть порождено любое количество (но, по крайней мере, одно) понятий- экземпляров и их значения (имена) обязательно должны быть заданы при порождении. Каждое порожденное понятие при этом является сущностью из класса объектов или элементом из множества значений, идентифицируемого понятием-прототипом (EnâConcept).
1.2.2. Begin Concept - понятие, из которого исходит - понятие-начало отношения.
Begin Concept £ Concepts \ TerminalConcepts, где Terminal Concepts - множество терминальных понятий, Terminal Concepts с Concepts. Понятием-началом отношения может быть любое нетерминальное понятие.
1.2.3. Enâ Concept - понятие, в которое входит - понятие-конец отношения:
Enâ Concept £ Concepts \ {InitialConcept}, где InitialConcept - начальное понятие в описании класса понятий, оно единственно, и через него не может быть выражено ни одно другое понятие из описываемого класса понятий:
Initial Concept е Concepts.
Понятием-концом отношения может быть любое понятие за исключением начального понятия.
2. IdConcept е Concepts.
IdConcept - понятие, представляющее идентификатор в описании класса понятий (Concepts), оно единственно и не может быть выражено через другие понятия, то есть является терминальным понятием типа «Сорт». Понятие выделяется отдельно для того, чтобы в абстрактном синтаксисе отличить идентификатор от строковой константы.
3. Описание синтаксических ограничений: Syntax Restrictions = <Lexica, Syntax>,
где Lexica - лексичнские ограничения; Syntax- синтаксические ограничения.
Оно может отсутствовать, если текстовое представление информации не требуется.
3.1. Lexica= {<Lexem_Typei, Definition,>},=i, где LexemTypei е {«Идентификатор», «Целое число», «Вещественное число», «Строковая константа», «Ограничитель строковой константы»}; Definitioni - строка символов, включающая метасимволы и представляющая конкретное лексическое ограничение для вида лексемы.
3.2. Синтаксические ограничения задаются для нетерминальных понятий:
Syntax = {<Concept,, Definition>}, где Conceptj е Concepts \ Terminal Concepts; Definition - строка символов, включающая метасимволы и представляющая конкретное синтаксическое ограничение для конкретного понятия [3].
Связки, используемые для формулировки сочетаемости понятий:
1) «И», P(x)=P1 (x) Л P2(x)A... Л Pn(x).
Таким образом, например, фраза «БПЛА (беспилотный летательный аппарат) может быстро доставить небольшую посылку в любую точку города, минуя пробки. Кроме того, с его помощью можно доставлять посылки в труднодоступные места» будет записано как «БПЛА(x)= беспилотный летательный аппарат (x) A быстро доставляющий небольшую посылку в любую точку горо-да(x) A минующий пробки(x) A доставляющий посылки в труднодоступные места(x)».
2) «НЕ», P(x)=—I Pn(x).
Отсюда, например, фраза «Беспилотный летательный аппарат — это летательный аппарат без экипажа на борту» будет записано как «беспилотный _летательный аппарат(x) = летатель-ный(x) A аппарат(x) A — экипажа на борту(x)».
3) «ИЛИ» , P(x)=P-|(x) v P2(x)v... v Pn(x).
Например, фраза «Беспилотный летательный аппарат— это любое удаленно управляемое или вовсе самостоятельное (интеллектуальное) средство» будет записано как «беспилотный летательный аппарат (x) = (самостоятельное(x) A интеллектуальное(x) v удаленно управляемое'(x)) A средство(x)»
Также из выше приведенного примера видно, что приоритет у «И» выше чем у «ИЛИ», то есть между ними взоимоотношения такие же, как между умножением и сложением или логическим
& и V.
Правила структурной сочетаемости понятий:
1) «горизонтальное объединение» - объединение подряд идущих понятий в словосочетание.
2) «целое-часть», у : х-| ... хп. Где слева в формуле находится «целое» в виде термина - определяемое понятие, а справа находятся понятия - «части» данного «целого». При этом возможен вариант как строгого включения частей (как неотъемлемые компоненты одного целого), то есть обязательного присутствия и в последствие включения всех частей в целое у : Х1 Л х2 Л ... Л Хп, либо не строгого включения (компоненты достаточно самостоятельны, чтобы существовать отдельно от целого) у : Х1 V х2 Л х3 V ... V хп. Так, например, высказывание «Хвостовое оперение состоит из двух частей: киль и стабилизатор» будет записано как «хвостовое оперение» : «киль» Л «стабилизатор».
Характеристика конструкторского понятия «целое / часть» отражает способность понятия структурно присоединять другие понятия или, наоборот, присоединяться к господствующему компоненту сочетания [4].
В работе части в обоих случаях будут относиться к атрибутам, а целое к названию класса. И применяется данное правило для фиксации структурных свойств объекта, а также его характеристик.
Однако на практике правила образования структур «целое-часть» недостаточно, так как правила структурной сочетаемости имеют более богатый набор средств интересующие нас сочетаемости. Также возможно пересечение соседних фраз, когда окончание одной является уже началом следующей.
3) Установление тождественных понятий. "Поиск в модели экстенсионально тождественных или интенсионально тождественных элементов (например, с целью поиска тех элементов, являющихся в сечении кругом, являющимися телами вращения)"[4].
4) «Зависимость» - характеристика зависимости понятия, обозначает обязательность совместного использования структурных элементов изделия[4]. Данное правило набирает силу при определении наиболее устойчивых словосочетаниях, например, «иску-ственный интеллект» или когда к понятию привязывается его характеристика, доопределяющая рассматриваемое понятие, например, «воздушный шар», «кусок металла». Также когда объекты конкретной предметной области друг без друга являются бесполезными элементами, например словосочетание, «болт, гайка».
5) «Компонентность», обозначает отнесение параметров рассматриваемого понятия, его характери-стик(например, «размер моста», так «размер» становится атрибутом понятия «мост») к его атрибутам, то есть к атрибутным свойством изделия, например, «габаритный размер»[4].
6) «Наследовательность», означает, что у понятий есть что-то общее («воздухоплавательный аппарат» и «аэростат») и между ними есть смысловая ассоциация «целое-часть», например, «машина» и «легковая машина», «грузовая машина».
Для построения интеллектуальных систем необходимо содержание понятия определить как описание его свойств. Для выделения объема понятия
необходимо процедурным путем вычислить свойства рассматриваемых объектов.
Пример спецификации предметной области и задачи проектирования
Рассмотрим класс прикладных задач «Статистические характеристики», в котором используются понятия: «массив экспериментальных данных», «среднее значение», «среднее отклонение». Естественно предположить, что массив экспериментальных данных хранится в файле. Спецификация предметной области «Статистические характеристики»
Понятие запись {
Поле : вещественное;
}
Понятие массив {
М : вектор из запись;
}
Понятие файл {
Имя_файла : строка; Функция Прочитать_запись()
Результат запись }
Понятие массив_экспериментальных_данных {
М : массив;
Функция Прочитать_массив_из_файла(Ф : файл)
Результат пусто }
Понятие среднее_значение {
Значение : вещественное; Функция Вычислить_значение(М : мас-сив_экспериментальных_данных)
Результат Значение }
Понятие среднее_отклонение {
Значение : вещественное; ФункцияВычислить_значение(С : сред-нее_значение, М : мас-сив_экспериментальных_данных)
Результат Значение }
Поясним содержание спецификации. Спецификация представляет собой совокупность связанных понятий. Каждое понятие идентифицируется именем, которое вводится с помощью ключевого слова «Понятие». В фигурных скобках размещается описание свойств понятия. Свойства понятия включают описание данных, описание операций и описание предикатных свойств.
Описание полей и операций имеет традиционный вид для языков программирования. Описание операций дополнительно включает описание используемых в вычислениях операций.
В приведенной спецификации понятие «запись» включает одно поле, в котором может
храниться значение статистического данного. С использованием понятия «запись» строятся описание понятия «массив» и «файл». Понятие «массив» используется в понятии «массив экспериментальных данных» для хранения прочитанных из файла данных. Понятие «массив экспериментальных данных» дополнительно включает функцию «Прочи-тать_массив_из_файла». Понятия «среднее значение» и «среднее отклонение» являются носителями соответствующих статистических характеристик, которые вычисляются с помощью функций «Вычис-лить_значение».
Понятие «понятие» не тождественно понятию «класс». Как видно из спецификации, понятия «запись» и «массив» могут быть реализованы в виде одного класса «массив», в котором при этом понятие «запись» может быть представлено соответствующим полем.
Обсудим теперь процессы синтеза спецификации программного изделия. В настоящей работе изучению подлежит процесс синтеза структурной модели программной системы. Ограничимся рассмотрением особенностей процесса синтеза диаграммы классов. Спецификация предметной области «Статистические характеристики» ориентирована на синтез диаграммы классов.
Синтез диаграммы классов выполняется для некоторой задачи, спецификация задачи задается понятием «прикладная_задача»:
Понятие прикладная_задача {
Ф : файл;
С :среднее_значение;
Д :среднее_отклонение; Функция Вывести_результат('С, Д) Свойство Ухесреднее_значение У у е среднее_отклонение (Угеприкладная_задача(Доступен(г,х) ^ Доступен(г,у))^х=у)
Вывести_результат >0 }
Смысл спецификации задачи в нашем примере заключается в том, чтобы используя спецификацию предметной области подобрать одну или несколько диаграмм классов, в каждой из которых экземпляр класса «прикладная_задача» используя имя файла «Имя_файла» получит доступ к файлу с экспериментальными данными и сможет вычислить среднее знчение «С» и среднее отклонение «Д».
Понятие «прикладная_задача» содержит свойство, формулировка которого начинается ключевым словом «Свойство». Указанное свойство означает единственность экземпляра класса «сред-нее_значение», который может быть доступен (предикат «Доступен») из экземпляра класса «приклад-ная_задача». Предикат вида «аеЬ» означает: а является экземпляром классаЬ. Предикат вида «Досту-пен(а,Ь)» означает: экземпляр класса Ь находится в области видимости экземпляра класса а. Необходимость введения свойства единственности обусловлена тем, что при синтезе диаграммы классов возможен недопустимый случай, когда при единственном экземпляре класса «прикладная_задача» возможно су-
ществование более одного экземпляра класса «среднее_значение». Например, такая ситуация возможна, если мы построим бинарное отношение агрегациивида {(прикладная_задача, сред-нее_значение), (прикладная_задача, сред-нее_отклонение), (среднее_отклонение, сред-нее_значение)}, где каждое выражение в круглых скобках обозначает элемент отношения (целое, часть) с общедоступными областями видимости.
Понятия спецификации предметной области также могут содержать описание свойств. В нашем примере они отсутствуют из-за ограниченности объема статьии простоты самого примера.
Таким образом, необходимо синтезировать одну или несколько альтернативных диаграмм классов, используя спецификацию предметной области «Статистические характеристики».
Нашей задачей является построение системы бинарных отношений: отношение агрегации, отношение композиции, отношение наследования, отношение видимости. Перечисленные отношения составляют основу диаграммы классов.
Кроме того, необходимо назначить для всех входящих в классы полей, свойств и методов области видимости. Каждому структурному элементу понятия при включении его в класс необходимо определить область видимости: закрытая (private), или защищенная (protected), или общедоступная (public).
Если структурный элемент понятия включается в класс в виде поля, то можно утверждать, что его область видимости будет закрытой. Утверждение базируется на тезисе: хороший стиль объектно-ориентированного программирования требует, чтобы в объекте извне были видимы только свойства (property) и методы.
Рассмотрим еще пример. Пусть построены отношение агрегации {(прикладная_задача, сред-нее_отклонение)}с областью видимости «общедоступная» и отношение наследования {(сред-нее_значение, среднее_отклонение)}, последнее бинарное отношение включает пары (предок, потомок).В этом случае экземпляру класса «при-кладная_задача» будет недоступен экземпляр класса «среднее_значение». Возможным выходом из создавшего положения является введение в экземпляр класса «среднее_отклонение» специального метода, осуществляющего чтение среднего значения.
Замечание. Как известно технология объектно-ориентированного программирования создавалась для разработки крупных программ, поэтому приведенный пример не является типичным для указанной технологии. Однако даже такой простой пример вызовет затруднения у начинающего программиста при проектировании диаграммы классов. Более опытный программист, возможно, упустит из рассмотрения какие-то важные особенности примера. Очень квалифицированный специалист потратит на разработку диаграммы классов значительную часть своего драгоценного времени.
Приведенные примеры и рассуждения показывают, что мы имеем дело с очень интересной картиной взаимодействия элементов классов и экземпляров классов, которое проистекает, с одной стороны, из объектно-ориентированной модели программирования, и, с другой стороны, и это очень важно, - из накопленного опыта создания эффективных объектно-ориентированных программ. Поэтому формализация и автоматизация процесса структурного синтеза информационной системы представляют собой в значительной степени сложную научную задачу.
Аксиоматическая система
В настоящей работе принят логико-математический подход к решению задачи синтеза диаграммы классов. Традиционно логико-математический подход характеризуется использованием генератора для получения вариантов решений и анализатора - для выбора подходящих решений. Анализатор строится обычно на аксиоматической системе. В работе сделана попытка сформулировать аксиоматическую систему для анализа вариантов структурных решений, принимаемых в процессе синтеза диаграммы классов. Приведем без формализации, полученные к настоящему моменту структурные аксиомы. Аксиома 1. Между двумя классами существует единственное отношение.
Аксиома 2. Имя поля, свойства, метода является уникальным внутри данного класса. Аксиома 3. В разных классах возможны атрибуты с одинаковыми именами.
Аксиома 4. Если в классе используется один экземпляр другого класса, то необходимо использовать между этими классами отношение наследования. Аксиома 5. Если в классе используется несколько экземпляров другого класса, то существующее отношение между этими классами является агрегацией. Аксиома 6. Если класс-«целое» является стандартным компонентом системы программирования, а класс-«часть» не является стандартным компонентом системы программирования, то отношение («целое-часть») между этими классами является отношением агрегации.
Аксиома 7. Если отношение является агрегацией, то в этом случае проблема создания и ликвидации экземпляров класса «часть» должна решается явным образом.
Аксиома 8. Если «целое» является стандартным компонентом системы программирования и «часть» является тоже стандартным компонентом системы программирования, то отношение «целое-часть» между этими классами является отношением композиции. Аксиома 9. Если между классом-«целое» и классом-«часть» имеется отношение композиции и происходит ликвидация класса-«целое», то удалится и класс «часть».
Аксиома 10. Если между классом-«целое» и классом-«часть» существует отношение агрегации и при удалении класса-«целое» удаляется и класс-«часть», то отношение между этими классами является композицией.
Необходимо синтезировать одну или несколько альтернативных диаграмм классов, используя специфи-
кацию предметной области «Статистические характеристики».
Нашей задачей является построение системы бинарных отношений:
1) виды отношений взаимодействия классов:
1.1) иерархические
а) ассоциация
RaS(04) {C,(O4) x Cj(O4)}: «используется для», «находится в процессе», «быть результатом», «быть полученным при», «служить параметрами», «быть полученным с помощью», «использоваться для» [5].
i) один к одному,
ii) один ко многим,
iii) многие к одному.
б) наследования (обобщения),
Rn(O4)=a,,r\ Acm(O4) —>a,, r,| AcO [5]. Класс и наследование атрибутов и отношений его подклассами:
A(Ci),R(Ci)—>A(Cii),R(CII)!A(CI)!R(CI)—> —>А(С12)ЛС12)А(С0ЛС1)—>А(С13)ЛС13) [5].
1.2)структурные отношения («часть-целое») С1 с С 11 A С12 A С 1з[5].
а) агрегации,
б) композиции.
в) «класс-данные» (класс - атрибуты, класс -функции)- «входит в состав», «является характеристикой»
Rcd(04) = Cj(O4) с D,(04): отношение данного вида реализовано для всех классов данной онтологии С1(04) с D, AC1cAD [5], то есть AcAD, С1с A
1.3) неиерархические
а) реализация,
б) зависимость.
2) виды отношения доступности (разновидности методов доступа):
2.1) без ограничений (public),
2.2) закрытое (private),
2.3) защищенное (protected).
3) для языков с ООП
3.1) конструктор (С++, С#),
3.2) деструктор (для языков С++)
4) виды классов
4.1) абстрактное
4.2) интерфейс
4.3) шаблон
4.4) утилита
Где 04 - онтология; С1 - класс, A-атрибуты, R-отношения, D - вид атрибута, O4 ={C, A, R, D}. Перечисленные отношения составляют основу диаграммы классов.
В рассмотренном в статье примере (о нахождении среднего значения и дисперсии) одним из возможных вариантов выборки видов отношений является:
наследования (от среднего значения к дисперсии), агрегации {(файл, запись), (МЭД, файл), (массив, запись)} или
композиции{( МЭД, массив), (МЭД, файл), (массив, запись)} или
сервер-клиен {(файл, МЭД),(запись, массив)}.
Замечание
Как известно технология объектно-ориентированного программирования создавалась для разработки крупных программ[6-9], поэтому приведенный пример не является типичным для указанной технологии. Однако даже такой простой пример вызовет затруднения у начинающего программиста при проектировании диаграммы классов. Более опытный программист, возможно, упустит из рассмотрения какие-то важные особенности примера. Очень квалифицированный специалист потратит на разработку диаграммы классов значительную часть своего драгоценного времени.
Заключение
На основе анализа технологий создания программных систем сформулирована проблема о необходимости автоматизированного синтеза диаграммы классов иМЬ.
Разработана система аксиом, которая может быть использована в качестве правил принятия решений в автоматизированной системе синтеза диаграмм классов иМЬ.
Использование системы аксиом в задачах синтеза иМЬ диаграммах классов планируется рассмотреть в последующих публикациях.
Литература
1. Б.В.Добров, В.В.Иванов, Н.В.Лукашевич, В.Д.Соловьев, Онтологии и тезаурусы: Учебно-методическое пособие.
Казанский государственный университет, Казань, 2006, С. 198.
2. А.М. Прохоров, Большая советская энциклопедия. Изд. 3-е. - В 30 т. Советская энциклопедия, М., 19701978.
3. В.А. Тимченко, В сб. 0818-2012, Минск, 2012. С. 6369.
4. И.А. Барков, Теория конструкторской семантики. ИжГТУ, Ижевск, 2003, С. 30.
5. Л.С. Глоба, М.Ю. Терновой, Р.Л. Новогрудская, В сб. 0818-2013, Минск, 2013. С. 49-54.
6. М.В. Медведев, А.П. Кирпичников, Трехмерная реконструкция объектов в системе технического зрения мобильного робота. Т. 17, №15. Вестник Казанского технологического университета, Казань, 2014. С. 326 - 330.
7. М.В. Медведев, А.П. Кирпичников, Система управления беспилотным летательным аппаратом на основе вейвлет-методов обнаружения и распознавания объектов на изображениях. Т. 17, №19. Вестник Казанского технологического университета, Казань, 2014. С. 359 -363.
8. А.П. Кирпичников, С.А. Ляшева, М.П. Шлеймович, Обнаружение и сопровождение объектов в бортовых системах обработки изображений. Т. 17. № 13. Вестник Казанского технологического университета, Казань, 2014. С. 331-334.
9. А.П. Кирпичников, С.А. Ляшева, М.П. Шлеймович, И.В. Леонова, Проектирование автоматизированной системы обработки данных успеваемости студентов на основе нечеткой логики. Т. 17. № 22. Вестник Казанского технологического университета, 2014. С. 372376.
© И. И. Бикмуллина - аспирант кафедры автоматизированных систем обработки информации и управления КНИТУ-КАИ им А.Н. Туполева, elsiyar-b@yandex.ru; И. А. Барков - д-р техн. наук, профессор кафедры автоматизированных систем обработки информации и управления КНИТУ-КАИ им А.Н. Туполева, barkov.asoiu@kstu-kai.ru; А. П. Кирпичников - д-р физ.-мат. наук, зав. каф. интеллектуальных систем и управления информационными ресурсами КНИТУ, kirpichnikov@kstu.ru.
© I. I. Bikmullina — postgraduate of the Department of Automated Information Processing Systems & Control, KNRTU named after A.N. Tupolev, elsiyar-b@yandex.ru; I. A. Barkov - Dr. Sci., Professor of the Department of Automated Information Processing Systems & Control, KNRTU named after A.N. Tupolev, barkov.asoiu@kstu-kai.ru; А. P. Kirpichnikov - Dr. Sci, Head of the Department of Intelligent Systems & Information Systems Control, KNRTU, kirpichnikov@kstu.ru.
