УДК 004.414.38
ПРИМЕНЕНИЕ ЛИНГВИСТИЧЕСКОГО ИНСТРУМЕНТА ПРИ КОНЦЕПТУАЛЬНОМ МОДЕЛИРОВАНИИ
И. В. Арзамасцева, О. Н. Гаврикова
THE USE OF LINGUISTIC INSTRUMENT IN CONCEPTUAL MODELING
I. V. Arzamastseva, O. N. Gavrikova
Аннотация. Актуальность и цели. Формальное представление знаний позволяет точно и однозначно определить элементы системы и связи между ними. Недостатком данного подхода является сложность синтаксиса и семантики формальных языков. Но формальное представление позволяет значительно сократить процесс перехода от моделирования к разработке самого программного продукта. Осуществить этот переход без четкого определения семантики моделируемых элементов чрезвычайно сложно. В связи с этим необходимо использовать лингвистические знания. Целью работы является анализ возможности использования лингвистического инструмента при концептуальном моделировании в процессе разработки технических требований к проекту, выявление оптимального метода и построение абстрактной концептуальной модели. Материалы и методы. Была построена концептуальная абстрактная модель машины по приготовлению и раздаче напитков с помощью языка UML, для чего использована программа Enterprise Architect 10 (Trial Version). В процессе построения использовалось лингвосемантическое описание, что позволило упростить процедуру моделирования. Результаты. Проведенное исследование позволило определить роль лингвистических знаний при концептуальном моделировании и выявить лингвистический инструмент для него. Доказана целесообразность использования лингвистических знаний в процессе создания концептуальной абстрактной модели. Выводы. Точное и грамотное составление требований позволяет сократить количество ошибок и исправлений на предпроектной стадии разработки.
Ключевые слова: концептуальное моделирование, лингвистический инструмент, UML.
Abstract. Background. Formal knowledge representation can accurately and unambiguously identify the elements of the system and the relationships between them. The disadvantage of this approach is the complexity of the syntax and semantics of formal languages. But formal representation allows to reduce considerably the process of transition from modeling to the development of the software itself. To carry out this transition without a clear definition of the semantics of the modeled elements is extremely difficult. In this connection must be used linguistic knowledge. The purpose of the work are to analyze the possibility of the use of linguistic tools in the conceptual modeling in the development of technical requirements for the project, identifying best practices and build an abstract conceptual model. Materials and methods. It was built conceptually abstract model of a machine for preparing and dispensing beverages with the help of language UML, which has been used to program Enterprise Architect 10 (Trial Version). In the process of building used linguistic and semantic description that will simplify the procedure of modeling. Results. This study has allowed to determine the role of linguistic knowledge in conceptual modeling and to identify linguistic tool for him. It was proved the expediency of the use of
linguistic knowledge in the creation of a conceptual abstract models. Conclusions. Precise and well-written requirement can reduce the number of errors and corrections in the pre-development phase.
Key words: conceptual modeling, linguistic tools, UML.
Введение
Для разработки любого программного продукта необходимо вначале четко определить основные требования к программной системе. В зависимости от сферы применения существует множество способов моделирования как системы в целом, так и ее компонентов. Сюда относятся объектное моделирование, моделирование событий, состояний системы. Среди них есть формальные (языки формального представления), полуформальные (диаграммные нотации) и неформальные (текстовое описание) способы моделирования.
Однако до сих пор не существует какого-то единого способа представления моделируемой системы. Описание с помощью естественного языка дает точное представление о системе и ее элементах, достаточно удобное для восприятия, но часто приводит к многозначности слов.
Формальное представление позволяет достаточно точно и однозначно определить элементы системы и связи между ними. Недостатком данного подхода является сложность синтаксиса и семантики формальных языков, поскольку любой из них требует предварительного изучения. Но формальное представление позволяет значительно сократить процесс перехода от моделирования к разработке самого программного продукта. Осуществить этот переход без четкого определения семантики моделируемых элементов чрезвычайно сложно. В связи с этим необходимо использовать лингвистические знания.
1. Элементы моделируемой системы
К сожалению, часто сложно описать систему, так как нет четких стратегий и правил по определению элементов, которые должны в нее входить. Такая неопределенность вполне объяснима, поскольку для каждого отдельного случая нужно определить и описать конкретные элементы системы. Таким образом, невозможно разработать универсальные способы их определения и описания. Тем не менее существуют рекомендации по поводу того, что следует включить в моделируемую систему [1]. Однако эти рекомендации недостаточно систематизированы для их универсального применения на практике.
Мы предлагаем добавить к UML использование лингвистических знаний, т.е. семантику и структуру входящих в моделируемую систему элементов и отношений между ними. Это позволит упростить процедуру концептуального моделирования рассматриваемой системы и тем самым получить семантически и синтаксически более точные модели. Для этого необходимо определить каждый элемент моделируемой системы (табл. 1). В данной работе мы рассматриваем элементы, необходимые для всех систем в общем (рис. 1).
Таблица 1
Основные элементы моделируемой системы
Объекты Объекты включают в себя предметно-ориентированные понятия системы. В зависисмости от своей природы объекты могут быть представлены как сущности (entities), ассоциации (associations), агенты (agents) или события (events). Объектная модель, таким образом, представляет собой совокупность переменных состояний, с помощью которых описываются остальные элементы системы [1]. Объект в концептуальном моделировании -это дискретное множество управляемых моделируемой системой основных концептов (системы), которые обладают следующими свойствами: • четко различимы; • исчисляемы в любом состоянии системы; • несмотря на отличия, обладают рядом схожих свойств; • могут отличаться друг от друга в индивидуальном состоянии или в переходах состояний. Правило определения типа объекта: концептуальный объект должен быть представлен: • событием, если его экземпляры существуют только в одном состоянии; • агентом, если его экземпляры могут контролировать поведение других объектов; • сущностью, если его экземпляры пассивны и независимы; • ассоциацией, если его экземпляры пассивны и зависимы от других объектов, которых они связывают
Сущности (Entities) Сущность - автономный, пассивный объект. Сущности могут существовать в системе независимо от других объектов (в отличие от ассоциаций). Они не могут контролировать поведение других объектов (в отличие от агентов). Как и другие виды объектов, сущности могут изменяться самостоятельно от состояния к состоянию в зависимости от изменений в значениях переменных состояния
Ассоциации (Associations) Ассоциация - это концептуальный объект, связывающий другие объекты. Каждый связанный объект выполняет определенную роль в ассоциации. Позиция каждого объекта связи очень важна. Изменение расположения этих объектов приведет к изменению связи, так как изменятся их роли в этой связи. Ассоциации могут связывать объекты разных типов -сущности, ассоциации, агенты или события. Они также могут связывать более двух объектов одновременно, поскольку объекты одной и той же ассоциации выполняют разные роли [1, 2]
Продолжение табл. 1
Специализация/ генерализация (Object specialization/ generalization) Множество экземпляров объекта часто делятся на подмножества с общими свойствами объекта-родителя, сохраняя при этом свои собственные отличительные свойства. Специализация устанавливается между объектом-родителем и его экземплярами (или дочерними объектами). Таким образом, дочерний объект выполняет роль специализации, а объект-родитель - генерализации. При этом дочерний объект по умолчанию наследует все свойства объекта-родителя, если в свойствах первого не указано обратное
Агрегация (Aggregation) Этот тип связи используется для моделирования составных объектов. Например, библиотека состоит из нескольких объектов: каталог, полки, защитная система и т.д. Объект-компонент может быть частью только одного составного объекта. Графически обозначается ромбом. Агрегации поддаются все концептуальные объекты: сущности, ассоциации, агенты и события. Объекты-компоненты одного составного объекта могут быть разных типов (например, агенты и сущности)
Атрибуты (Attributes) Атрибут - это внутреннее свойство объекта. У атрибута есть имя и ряд значений, которые он может принимать. Графически атрибут расположен в нижней части прямоугольника, представляющего объект, который он характеризует. Объявление атрибута обозначает соответствующую функциональную область объектов, характеризующихся данным атрибутом. Атрибут может быть объявлен через предопределенный тип (String или Boolean), предметным/специальным именем (например, SpeedLimit: Speed) или открытым перечислением (например, DoorState: {open, closed}). Правило определения атрибута: элемент в концептуальной модели должен быть представлен атрибутом, если а) к нему не требуется добавлять атрибуты/ ассоциации, специализировать или агрегировать; б) в него не входит концептуальный объект, к которому требуется добавлять атрибуты/ ассоциации и специализировать его
Окончание табл. 1
Агенты (Agents) Активный компонент системы, участвующий в достижении цели. Важны не свойства агента, а его роль в системе, которую он играет для достижения цели (цель - это конечная установка системы, которую она должна выполнить посредством взаимодействия ее агентов). С операционной точки зрения агент рассматривается как процессор, который несет ответственность за исполнение определенных операций в строго заданных условиях для достижения цели. Эти условия соответствуют обязательствам (permissions and obligations), которые определяются для каждой операции в операционной модели. Цель для каждого агента назначается в зависимости от его возможностей, которые определяются атрибутами объекта и ассоциациями, которые агент способен отслеживать и контролировать. Поведение агента определяется последовательностью переходов состояний элементов системы, которые данный агент контролирует. Эти элементы обычно представлены переменными состояний. Так, состояние переменой x -это функциональная пара (x,v), где v обозначает определенное значение для x. Глобальное состояние системы определяется совокупностью состояний всех переменных, характеризующих систему. В роли агента может выступать как одушевленное, так и неодушевленное лицо
События (Events) Определяют переход от одного состояния к другому. Выражаются глаголом, отглагольным существительным или предикативной конструкцией
Состояния (States) Состояние определяется множеством всех ситуаций, где некоторые переменные, характеризующие контролируемый элемент, всегда имеют одно значение, несмотря на другие переменные, чьи значения могут отличаться в данном множестве в зависимости от ситуации. Эти переменные могут соответствовать атрибутам и отношениям, контролируемым данным компонентом [1]
Рис. 1. Сущности и их роли в ассоциации [1] 114
Для более подробного семантического описания концептуального объекта создаются специальные аннотации, которые включают следующие характеристики:
- Имя (Name). Уникально для данного объекта, позволяет однозначно определить его в целой системе.
- Тип (Type). Позволяет вербально объявить представление объекта (сущность, агент или событие).
- Определение (Def). Точно определяет концептуальный объект на естественном языке. Такое определение дает необходимое и достаточное условие, для того чтобы отдельный элемент можно было считать экземпляром объекта данной системы. Определения объектов необходимы для построения точной модели. Они должны быть достаточно точными и однозначными, чтобы исключить различные интерпретации разными людьми.
- Синонимы (Synonyms) - необязательная характеристика. Определяют ряд элементов, которые могут быть использованы в качестве синонимов при обращении к данному концептуальному объекту.
- Имеет (Has). Вербально определяет относительно системы значение различных атрибутов объекта. Такое определение должно быть максимально точным и однозначным, чтобы избежать различных интерпретаций и разночтений.
- Инвариант (DomInvar). Перечисляет известные свойства объекта как инварианты, сохраняющие свое значение в любом состоянии объекта. Эти свойства необходимы для построения или проверки модели, содержащей данный объект. Таким образом, они задают необходимые условия для правильного функционирования объекта в системе. Например, для объекта «собрание» инвариантом будет следующее условие: «собрание может быть назначено в том случае, если установлены дата, продолжительность и место его проведения».
- Начальное значение (Init). Определяет начальное значение атрибутов и ассоциаций любого экземпляра объекта, когда он появляется в системе [1].
Таким образом, описание системы позволит изначально создавать более правильные и однородные модели и проверять синтаксическую и семантическую правильность в процессе их создания.
2. Семантическое описание элементов системы
Для демонстрации применения лингвистического инструмента при концептуальном моделировании с использованием унифицированного языка моделирования как языка широкого профиля, хорошо развитого в сфере концептуального моделирования, был разработан пример, в котором демонстрируется применение языка UML с использованием структурно-семантического описания системы для разработки требований к абстрактной машине по приготовлению и раздаче напитков.
В данном примере используются диаграммы классов и диаграммы событий UML, отражающие элементы системы и ее функционирование. Также
добавлено семантическое описание элементов системы данной абстрактной машины, что позволит получить более точную и полную концептуальную модель.
Построим концептуальную абстрактную модель машины по приготовлению и раздаче напитков с помощью языка UML в три этапа. Для этого использована программа Enterprise Architect 10 (Trial Version), основное назначение которой - предоставить возможность моделирования и проектирования приложений при помощи графического языка UML. Эта программа была разработана компанией Sparx Systems, специализирующейся на создании инструментов визуального моделирования для планирования, разработки и создания программных систем [3].
Любая машина по приготовлению и раздаче напитков состоит из следующих базовых элементов: корпус с вращающимся элементом, на котором расположены емкости с компонентами будущего напитка; кнопка включения; кнопки выбора напитков; платформа для стакана с готовым напитком; индикаторы состояния машины.
Функционирование машины включает в себя следующие основные этапы:
1) хозяин бара включает машину;
2) пользователь нажимает на кнопку с изображением выбранного напитка;
3) корпус с вращающимся элементом начинает движение и останавливается, когда достигает необходимого компонента напитка.
4) корпус с вращающимся элементом прекращает движение, загорается индикатор готовности напитка.
3. Построение диаграмм UML
Представим семантическое описание элементов системы и ее функционирования.
Согласно семантическому описанию, представленному в первой главе, мы имеем в рассматриваемой системе следующие объекты.
На рис. 2 изображена диаграмма, где представлены все объекты и атрибуты описываемой системы. Связь между агентами и сущностями представлена ассоциациями с именами, а также агрегацией.
На рис. 3 представлена диаграмма состояний UML. На данной диаграмме представлены события и состояния (положительные и отрицательные) описываемой системы. У каждого события возможно два последующих исхода. Начальное событие изображается с помощью символа ф, а конечное -с помощью символа
®
. События (переходы состояний) изображены стрелками.
Заключение
Как показало исследование, подобное описание системы и входящих в нее элементов эффективно и может быть рекомендовано при составлении технических требований к проекту на этапе концептуального моделирования системы.
В ходе демонстрации применения лингвистического инструмента при концептуальном моделировании с использованием унифицированного языка моделирования UML были выявлены особенности использования лингвистических знаний, а именно содержательная сторона описываемой системы. Благодаря такому описанию мы смогли построить достаточно полную и точную концептуальную модель при помощи программы Enterprise Architect 10 (Trial Version), поскольку все входящие в нее элементы были описаны заранее. В данной модели отражены как статичные (диаграмма классов UML), так и динамические (диаграмма состояний UML) аспекты рассматриваемой системы.
Рис. 2. Диаграмма классов UML
sd Dynamic View
ActivityFinal
Рис. 3. Диаграмма состояний UML
Список литературы
1. Lamsweerde, A. Requirements eigineering: from system goals to UML models to software specifications / A. Lamsweerde. - London : A John Wiley and Sons, Ltd, 2009. -683 p.
2. Буч, Г. Язык UML. Руководство пользователя / Г. Буч, Д. Рамбо, А. Якобсон. -2-е изд. - М. : ДМК, 2006. - 496 с.
3. DOORS (Dynamic Object-Oriented Requirements System). - URL: http://www.rcm2.co.uk
Арзамасцева Иветта Вячеславовна кандидат технических наук, доцент, кафедра прикладной лингвистики, Ульяновский государственный технический университет E-mail: [email protected]
Гаврикова Ольга Николаевна
студентка,
Ульяновский государственный технический университет E-mail: [email protected]
Arzamastseva Ivetta Vyacheslavovna candidate of technical sciences, associate professor, sub-department of applied linguistics, Ulyanovsk State Technical University
Gavrikova Ol'ga Nikolaevna student,
Ulyanovsk State Technical University
УДК 004.414.38 Арзамасцева, И. В.
Применение лингвистического инструмента при концептуальном моделировании / И. В. Арзамасцева, О. Н. Гаврикова // Модели, системы, сети в экономике, технике, природе и обществе. - 2015. - № 3 (15). - С. 110-119.