Диссертация (1137259), страница 17
Текст из файла (страница 17)
Поэтому, задаётся второе требование на гибкость программного комплекса,которое утверждает, что необходимо сделать каждый из этапов максимально гибким, в частности необходимо предоставить пользователю возможность выбора различных алгоритмов конструированиярешётки, различных индексов качества, различных типов узорныхструктур и прочее.Третьим требованием является эффективность программногокомплекса. Для удовлетворения этого требования выбран эффективный язык программирование – C++. Последнее требование – кроссплатформенность, которое может быть удовлетворено при использовании только кроссплатформенных библиотек, таких как Boost.Для удовлетворения первых двух требований предлагается архитектура, представленная на рисунке 4.3.
В рамках этой архитектуры сначала создаётся общая инфраструктура для моделирования наоснове узорных структур, и затем модули данной архитектуры специфицируются для моделирования процессов с состояниями сложной структуры. Выделяются две подсистемы: подсистема по работес узорными структурами и подсистема построителя решёток, которые не должны быть связанными между собой кроме как посредством заранее заданного программного интерфейса. В этом случаедобавление любых алгоритмов и любых узорных структур в данный программный комплекс возможно без исправления уже добав-102ленных, что существенно упрощает использование разрабатываемойсистемы.С технической точки зрения, остаётся ещё вопрос, каким образомможно хранить и обрабатывать всё множество узорных объёмов и содержаний.
На диаграмме они представлены хранилищами объёмов исодержаний. Это будет рассмотрено подробнее позже. На диаграмме также присутствуют подсистемы импорта данных, расчёта меркачества узорных понятий и фильтрации решётки, которые необходимы для полного цикла моделирования с использованием узорныхструктур. Тем не менее ядром данной системы является подсистема построения решёток представленная несколькими подсистемами.Рассмотрим устройство ядра подробнее.Рисунок 4.3: Архитектура комплекса моделирования с использованием узорных структур.Можно выделить следующие блоки архитектуры программногообеспечения, показанные на рисунке 4.4:103Рисунок 4.4: Архитектура предлагаемого программного обеспечениядля работы с узоными структурами.∙ Полурешётка, заданная через операцию сходства (в дальнейшем данную подсистему будем называть менеджером узоров);∙ Подсистемы хранения и обработки объёмов и содержаний;∙ Построитель узорных решёток или просто построитель.Рассмотрим данные подсистемы в отдельности.4.3.3Менеджер узоровМенеджер узоров – это подсистема, которая отвечает за представление полурешётки описаний произвольного типа.
Таблица 4.1104ОперацияID=GetObjectType()ID=GetPatternType()Pttrn=Preprocess(JSON) = ⊓ { , }= ⊑ { , }=( == )Pttrn=LoadPattern()JSON=SavePattern()FreePattern()ОписаниеВозвращает JSON описание типа входных объектовВозвращает JSON описание типа используемых узоровПреобразовавыет JSON описание объектов во внутрений формат узоровВычисляет результат пересечения двухузоров.Проверяет, является ли первый узор подузором второго узора.Проверяет равенство узоров.Преобразовывают между представлением узора в памяти и его JSON представлениемОсвобождает память, занимаемую узором.Таблица 4.1: Основные функции API подсистемы менедежер узора.перечисляет основные операции, которые данная подсистема должна предоставлять.
Помимо обязательной операции расчёта сходствадвух узоров ⊓, от данной подсистемы также требуется реализацияпроверки отношений “=” (равенство), “⊑” (поглощение) на узорах(отношений сравнения). Данная операция введена в подсистему изпрактических соображений. На практике, отношения сравнений вомногих случаях можно реализовать намного эффективнее, чем операцию сходства.Подсистема менеджера узоров должна уметь работать с двумя типами данных.
Первый тип – это описание объектов в базе данных.Данное описание используется только как входные данные. Затемописание объектов должно быть преобразовано во внутренний формат узоров. Этот формат – это представление объекта узора в памяти компьютера. Для целей сериализации, то есть для целей передачи узоров между сессиями необходимо уметь сохранять и загружатьузоры в/из памяти компьютера в долгосрочное хранилище.
Форматвнешнего хранения узоров может отличаться от формата хранения105описаний объектов. Это может быть необходимо как из соображенийэффективности так и из-за необходимости отражение формализмапроекций, каждая из которых может быть выражена как отдельныйменеджер узоров, но который работает с одними и теме же входными данными. Соответственно, каждый узор будет являться узоромв той или иной проекции, который можно эффективнее хранить вспециальном формате.Остальные операции относятся непосредственно к полурешёткеописаний. Они соответствуют операциям сходства и проверки отношения равенства или поглощения между узорами.
Здесь стоит отметить, что на практике операции проверки всех таких отношенийпредставлены одной функцией с целью повышения эффективностиданной операции. В частности, в качестве параметров этой функциипередаются какой именно результат является интересным и априорные знания о возможных результатах. Например, на различныхэтапах алгоритма AddIntent требуется проверять различные условия.
Так иногда требуется проверить только равенство, иногда толькострогое поглощение. На других этапах заранее известно, что два узора сравнимы и нужно только проверить как именно. Добавление подобных параметров позволяет увеличить эффективность получениярезультата сравнения, которое является одной из наиболее частыхопераций при построении рещёток формальных понятий.4.3.4Подсистемы хранения объёмов и содержанийРазмер результирующей решётки может иметь произвольный размер. Где должна храниться вся выделяемая память под новые объёмы и содержания? Подсистемы хранения отвечают именно за это.Введение этих подсистем позволяет отделить логику хранения от логики задания полурешётки описаний, что может быть полезно дляиспользование систем кэширования узоров. Следующая задача систем хранения – это анонимизировать память, по которой хранитсяпредставление узоров.
В частности с внешними потребителями эти106подсистемы работают с помощью уникальных идентификаторов. Таквнешний потребитель им передаёт идентификатор объёма или содержания, а подсистемы хранения их преобразуют в память, по которойхранятся соответствующие объём или содержание, и производит сними необходимые действия.
Обратно он также возвращает идентификаторы объёма или содержания результата. В частности, программный интерфейс подсистемы хранения содержаний совпадет спрограммным интерфейсом подсистемы менеджера узоров и по сутиявляется обёрткой над ним. Основное отличие подсистемы хранениясодержаний от подсистемы менеджера узоров в том, что она работаетс идентификаторами вместо памяти.ОперацияID=Clone(ID)ОписаниеКопирует объём заданный по ID. ПриID==-1 создаётся пустой объём.AddObject(ID, objID)Добавляет объект с номером objID вобъём заданный по IDSize=Size(ID)Возвращает мощность объёма, заданного по IDObjID=LastAddedObject(ID) Возвращает последний добавленныйобъек в заданный объёмID=LoadExtent(JSON)Преобразовывают между представлеJSON=SaveExtent(ID)ниями объёма в памяти в JSONТаблица 4.2: Основные функции подсистемы хранения объёмов.Подсистема хранения объёмов всегда работает с множествамиобъектов и поэтому устроена по другому, чем подсистема хранениясодержаний.
В таблице 4.2 показаны основные функции API подсистемы содержаний. В частности данная подсистема умеет добавлять объекты в объём, проверять его мощность, сохранять/загружатьобъём в/из внешнего представления и клонировать ранее созданноемножество объектов.107ОперацияInitialize(extStorage,intStorage)AddObject(objID,intID)Build()ОписаниеИнициализирует подсистему построителя решёток хранилищамиобъёмов и содержаний.Добавляет очередной объект вузорную структуру.
Соответсвуетфункции узорной структуры.Заканчивает вычисления узорнойструктуры.Таблица 4.3: Основные функции API подсистемы построителя узорных решёток.4.3.5Подсистема построения узорной решёткиПоследней частью предлагаемой архитектуры программныхсредств по работе с узорными структурами является построитель решётки. Это та подсистема, которая по хранилищам объёмов и содержаний, задающие операции по работе с множествами объектови узорами, находит множество узорных понятий и отношения между ними. Сначала данная подсистема должна быть инициализирована соответствующими объектами хранилищ объёмов и содержаний.Далее каждый из объектов должен быть добавлен в построитель решёток методом AddObject. Данный метод передаёт в построительрешёток номер добавляемого объекта и идентификатор содержания,описывающего этот объект, то есть фактически задаёт функцию из узорной структуры (, (, ⊓), ).
Все алгоритмы построения решёток узорных понятий могут быть поделены на поступательные иполные. Первый обновляют решётку формальных понятий при добавлении каждого следующего объекта. Последние же требуют полное описание формального контекста или узорной структуры. Специально для таких подходов введена функция Build, которая должна вызываться после добавления всех объектов в построитель и, таким образом, завершать построение решётки.
Поступательные подходы могут производить вычисления при каждом добавлении объек-108та, в то время как полные методы могут лишь накапливать данные вAddObject и затем производить все вычисления в Build.4.3.6Моделирование процессов с состояниями сложнойструктурыРисунок 4.5: Механизм работы с частичным порядком в рамках предлагаемой архитектуры.Для моделирования процессов требуется реализовать полурешётку описаний для произвольного частичного порядка и частичный порядок для сложных последовательностей.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
