Differences

This shows you the differences between two versions of the page.

--- mdd:modeling [2014/06/01 14:29] – [Это пример оформления статьи] golovanov_sergey
+++ mdd:modeling [2026/08/29 07:59] (current) – external edit 127.0.0.1
@@ Line 1: / Line 1: @@
+====== Моделирование Моделирования Моделирования ======
+Pierre-Alain Muller, Frédéric Fondement, Benoît Baudry, and Benoît Combemale. 2012. Modeling modeling modeling. //Softw. Syst. Model.// 11, 3 (July 2012), 347-359. DOI=10.1007/s10270-010-0172-x
+[[http://dx.doi.org/10.1007/s10270-010-0172-x|http://dx.doi.org/10.1007/s10270-010-0172-x]]
+==== Введение ====
+Подходы к проектированию на основе моделей проникли во все сферы разработки программного обеспечения до такой
+степени, что кажется, мы уже используем модели сродни мольеровскому мсье Журдену, который использовал для речи
+прозу, но не знал об этом. В основе моделирования лежат отношения, которые мы создаём ,чтобы
+представить что-то одно, через нечто другое. В данной статье рассмотрены определения различных моделей и
+отношений между ними. Определены стандартные отношения между моделями, которые могут быть использованы для
+выражения различных видов представления отношений. Кроме того будет предложен графический синтаксис для
+представления этих отношений. Так же приводится структурное определение для предлагаемого языка в форме
+метамодели и формальной интерпретации (используется язык Prolog.)
+==== 1. Обзор литературы ====
+Приводимая ниже таблица, содержит определение понятия модель, которое разные авторы приводят в своих работах.
+^ Таблица 1. Сводная таблица определения понятия “модель” ^
+^ Безивин (Bézivin) | Модель - это упрощение системы, созданное с определённой целью или замыслом. Модель должна быть способна отвечать на необходимые вопросы вместо самой системы.[2] ^
+^ Браун (Brown) | Модель позволяет абстрагироваться от физической системы, что позволяет инженеру сосредоточиться на существенных деталях, игнорируя при этом посторонние.[3] ^
+^ Джексон (Jackson) | Слово “Модель” здесь означает область дискового пространства  или базы данных, которая в большей или меньшей степени соответствия хранит часть Предметной Области. В последствии модель может действовать в как заменитель Предметной Области, предоставляя информацию ЭВМ, которая не может быть легко получена непосредственно из Предметной Области когда это необходимо. [4] ^
+^ Кюне (Kuehne) | Модель - это абстракция  системы (действительной или описанной через язык), которая позволяет делать прогнозы или выводы. [5] ^
+^ Людвиг (Ludewig) | Модель помогает создать отображения, предоставляя сведения о последствиях создания этих отображений ещё до того как они действительно созданы. [1] ^
+^ OMG (Object Modeling Group) | Модель системы  - это описание или же спецификация этой системы или её среды в некоторых определённых целях. [6] ^
+^ Сейдевиц (Seidewitz) | Модель - это ряд состояний некоторой исследуемой системы. (ИС) [7] ^
+^ Селик (Selic) | Функция инженерной модели - снижение риска, через облегчение нашего понимания сложной задачи и потенциальных способов её решения, до принятия на себя расходов и усилий по её полному решению. [8] ^
+^ Штейнмюллер (Steinmüller) | Модель - это информация: о чем-либо (содержание, значение) созданная кем-либо (отправителем) для кого-либо (получателя) с некоей целью (контекст применения). [9] ^
+=== Особенности моделей ===
+По Брэну Селику [8] инженерная модель должна обладать следующими пятью особенностями:
+- **Абстракция.** Модель - это всегда сокращенная интерпретация представляемой системы.
+- **Понятность.** Модель должна сохранять интуитивную форму.
+- **Точность.** Модель должна предоставлять объективное отражение необходимых особенностей системы.
+- **Предикативность.** Модель должна корректно предугадывать важные, но не очевидные свойства системы.
+- **Доступность.** Модель должна быть значительно дешевле для реализации и анализа, чем моделируемая система.
+=== Определение отношений между моделями ===
+С точки зрения подхода, которого придерживается Жан-Мари Фавр (подход называется мега-модель) [11] все MDE-инструменты могут быть описаны через 4 (+1 производное) основных отношений:
+**Представление** (RepresentationOf),
+**Элемент** (ElementOf),
+**РаспадаетсяНа** (DecomposedIn),
+**ПреобразуемоВ** (IsTransformedIn)
+**СоответствуетС** (ConformsTo) - производное отношение.
+==== 2. К модели моделирования ====
+Моделью моделирования здесь называется представление, которым необходимо управлять, когда используем технику
+моделирования. В процессе моделирования по сути с определённой целью создаются объекты, которые служат для
+представления других объектов. Следующий ниже подход к моделированию моделирования таким образом служит для
+фиксирования различных отношений между объектами, которыми манипулируем в процессе моделирования.
+При моделировании приходится иметь дело с объектами, которые представляются через другие объекты.
+Как утверждает Бран Селик [8], сначала следует найти компромисс между абстракцией и доступностью для понимания,
+поэтому отойдём от простого видения //Системного класса// Жана-Мари Фавра [12] и проведём грань между исходным
+объектом (который многие авторы называют моделью) и целевым объектом (называемым оригиналом по Стачовику [10])
+Кроме того понимание того является ли данный объект исходным или целевым относительно данной стрелки ничего
+не способно сказать нам о данном объекте. Это представлено на Рисунке 1. Здесь “источник” обозначен X, а “цель”
+Y, отношение **Представления** (RepresentationOf) обозначается μ.
+[[mdd:_detail:mdd:modeling_1.png|]]
+=== Интенция (Intention) ===
+Ни объекты ни их представления не создаются отдельно. Как говорится в [9] Штейнмюллером оба существуют, чтобы
+отвечать заданным целям, проявляют свойства, создаются для тех, кто в этом заинтересован.
+Здесь и далее это воспринимается как назначение объекта или его интенция (от англ. intention).
+Интенсиональное моделирование отвечает на вопросы КТО? и ЗАЧЕМ?, но не отвечает на вопрос ЧТО?
+Таким образом цель объекта состоит в том, чтобы представить причину (ЗАЧЕМ?) кто-то будет использовать данный
+объект, в каком контексте и какие ожидания от его использования. Это должно быть похоже на смешение требований,
+поведения, свойств и ограничений, которым удовлетворяет или следует данный объект.
+^ Таблица 2. Различные μ - отношения и их графические обозначения. ^
+^ Вид ^ Интенции ^ Описание ^ Условное обозначение ^
+| Отличается (different) | [[mdd:_detail:mdd:modeling_t211.png|]] | X и Y служат совершенно разные назначения. Обычно обозначается как разница в точках зрения. | [[mdd:_detail:mdd:modeliing_t212.png|]] |
+| Пересекается (share) | [[mdd:_detail:mdd:modeling_t221.png|]] | X и Y имеют некоторые общие цели. X и Y могут быть частично представлены друг через друга. Представление обоих частично и расширено. | [[mdd:_detail:mdd:modeliing_t222.png|]] |
+| Подмножество (sub) | [[mdd:_detail:mdd:modeling_t231.png|]] | Цели X - подмножество целей Y. Всё, что справедливо для X имеет смысл в контексте Y. Y может быть частично представлен через X. | [[mdd:_detail:mdd:modeliing_t232.png|]] |
+| Тот же (same) | [[mdd:_detail:mdd:modeling_t241.png|]] | X и Y имеют одно и то же назначение. Они могут представлять друг друга. Обычно так бывает из-за лингвистических соответствий или несоответствий. | [[mdd:_detail:mdd:modeliing_t242.png|]] |
+| Надмножество (super) | [[mdd:_detail:mdd:modeling_t251.png|]] | X включает цели Y. X может представить Y, однако, Y имеет дополнительные свойства. Это расширенное представление. | [[mdd:_detail:mdd:modeliing_t252.png|]] |
+Все авторы сходятся на том, что преимущество моделей в том, что они фактически могут быть использованы в том
+месте, где создаются, по крайней мере для некоторых конкретных целей. В этом и заключается то, что Стачовик
+называет прагматической прикладной особенностью модели. На практике оказывается удобно работать с некоторой
+выборкой интенций и договориться, что μ-отношение - это полное представление данной выборки. Отсюда μ/I
+(приведённое ниже) обозначает что X является представлением Y (для ой выборки интенций). Символ I может быть
+затем использован в другом месте схеме, чтобы показать данный образ включает некоторое подмножество интенций.
+Если интенция не меняется во всех схеме, то она может быть упрощена до условного обозначения.
+^ Таблица 3. Условные обозначения. X полностью представляет Y для заданного подмножества интенций (в данном контексте). ^
+| [[mdd:_detail:mdd:modeling_t3.png|]] |
+=== Сравнение аналитической и синтетической сущностей представления ===
+Как было показано ранее, несколько авторов различают модели //аналитические// и //синтетические//
+(соответственно //описательные//  и //специфицирующие// модели в смысле Сейдевица [7] и Фавра [12]).
+//Аналитическое представление// отношений устанавливает, что “цель” как-то выражается через “источник”.
+Аналитическое представление определяется (через μα) следующим образом:
+[[mdd:_detail:mdd:modeling_f1.png|]]
+где Tα отношение, такое что X может быть получен (или абстрагирован) из R(Y), в то время как R
+является одним из представлений X (включая идентичность). На языке моделирования Tα может обозначать
+преобразование модели (model transformation). В терминах истинности (введённых Фавром), в случае μα
+представления истинность содержится в //цели.//
+//Синтетическое// представление отношения подразумевает формирование цели из источника. Синтетическое представление
+(через μγ) определяется как:
+[[mdd:_detail:mdd:modeling_f2.png|]]
+где Tγ отношение, такое что Y может быть получен (или абстрагирован) от R(X), в то время как R
+является одним из представлений X (включая идентичность (Identity)). На языке моделирования Tγ
+может так же обозначать преобразование модели (model transformation). В терминах истинности, в случае
+μγ представления истинность содержится в источнике.
+Рассмотрение количественного вклада X и Tγ в синтез Y находится за пределами данного обзора.
+=== Каузальность ===
+Каузальность относится к вопросу о синхронизации, поднятому Майклом Джексоном (Michael Jackson) [4]; она
+определяет не только //где// устанавливается μ-отношение, но и //как//  оно изменяется во времени (если такое имеет
+место).
+Если вернуться к определениям //корректности// и //достоверности//, предложенным Эдом Сейдвицем (Ed Seidewitz) [7],
+то считается, что каузальность определяет:
+  * В случае //аналитического// представления, когда X //корректна// по отношению к Y.
+  * В случае //синтетического// представления, когда Y //достоверна//  по отношению к X.
+Одним из путей уменьшения этой неопределенности является четкое разделение между природой
+(//аналитический/синтетический//) и каузальностью (//корректность/достоверность//) отношения представления. На
+Рисунке 2 модель является каузальным аналитическим представлением системы. Если система изменяется,
+каузальное μα-отношение определяет последующее обновление модели. В свою очередь, так как модель
+также является каузальным μγ-представлением программы, она также обновляется и остается //аналитическим//
+представлением системы.
+[[mdd:_detail:mdd:modeling_3_копия.png|]]
+=== Транзитивность ===
+Ниже формально правила транзитивности между видами представлений установлены, как операторы языка Prolog.
+Это сделано, чтобы сделать вывод о типе представления между двумя явлениями, отнесенными друг к другу через n
+прямых представлений.
+^ Таблица 4. Правило сочетания представлений ^
+| [[mdd:_detail:mdd:modeling_t4.png|]] |
+Установлены три основных пункта (названные также Prolog-правилами (Prolog rules) для последовательности μ* из
+μ-отношений:
+  - Если все μ-отношения в μ* относятся к одному типу K, тогда сочетаемое μ*-отношение также принадлежит к этому типу. Это правило имеет одно исключение: когда все отношения принадлежат к типу share, сочетаемое μ*-отношение может принадлежать к типам share или different.
+  - Если в μ* встречается μ-отношение типа same (X и Y одинаковы по сути (same intention)), то это отношение не влияет на тип сочетаемого μ*-отношения.
+  - Если в μ* присутствует μ-отношение типа different (X и Y абсолютно различны (no intention)), то тип сочетаемого μ*-отношения также будет different. Правило имеет одно исключение: когда все отношения в μ* относятся к типу different, сочетаемое μ*-отношение может быть любого типа.
+Используя данное объяснение μ-отношений в Предисловии, выявлены правила сочетаемости, приведенные в
+Табл. 4. Следует отметить, что в некоторых случаях существует только один возможный результат сочетания
+отношений. Например, в третьей строке Табл. 4 если X является расширенным представлением Y (тип allInSource)
+и если Y имеет одинаковый смысл с Z (тип same), то X является расширенным представлением Z (тип allInSource).
+В некоторых случаях сочетания отношений могут привести к 2, 3, 4 или 5 возможным результатам. Например,
+Рисунок 3 (соответствует строке 11 в Табл. 4) иллюстрирует две возможных ситуации, когда X является расширенным
+и частичным представлением Y (тип share) и Y является расширенным и частичным представлением Z (тип share).
+В первом случае общий для X и Y смысл не будет пересекаться со смыслом, общим для Y и Z. Во втором случае общий
+для X и Y смысл пересекается со смыслом, общим для Y и Z, что значит, что X является расширенным и частичным
+представлением Z (тип share).
+[[mdd:_detail:mdd:modeling_4.png|]]
+==== 3. Метамодель моделирования ====
+Далее вводится структурное определение моделирования с использованием метамодели (Рисунок 4).
+[[mdd:_detail:mdd:modeling_5.png|]]
+Сам процесс моделирования (Modeling) может быть назван и охарактеризован через набор объектов-имен (Thing) без
+какого бы то ни было учёта их внутренней структуры. Единственная информация, которую хранит объект это
+возможное интенциональное **Представление** (RepresentationOf) другого объекта, соответствующее μ-отношениям
+(содержащихся в исходных объектах).
+Таким образом модель моделирования может быть рассмотрена как конечный ориентированный мультиграф (то есть
+между любыми двумя вершинами возможны кратные рёбра) без циклов (т. е. рефлексивность ребер). Определение
+самопредставления (т. е. циклы) ограничиваются следующим OCL представлением:
+<nowiki>
+context RepresentationOf inv NoLoops : self.src <> self.tgt;
+</nowiki>
+μ-отношение в основном  характеризуется своей интенцией (Intention), которая включает все части интенций
+исходного объекта (src). Считается, что цель определяется без какого-либо интенции, но она представлена через
+другой объект. Другими словами отношение **Представление** (RepresentationOf) содержит интенцию src относительно
+tgt (в метамодели src и tgt - это две роли, которые Объект (Thing) может играть в **Представлении**
+(RepresentationOf)). Это касается так же и метамодели поскольку представление (represent) включает ссылку между
+Объектом (Thing) и отношением **Представление** (RepresentationOf), где дуга representBy не является контейнером,
+т. к. целевой объект не зависит от представления. Кроме того допускается определение одного объекта через
+другой без какого бы то ни было представления этого другого объекта (вопреки интенциональности), но только,
+чтобы воспринимать его внутреннюю структуру как “черный ящик” в используемом здесь формализме.
+В рамках данного формализма предполагается так же определение чёрного ящика как интенции  каждого
+представления объекта (кроме неформального описания, использующего body). Таким образом по содержанию интенции
+и связям между объектами не может быть сделано никаких выводов. Однако, в контексте одного представления
+атрибут вида (kind) позволяет охарактеризовать окружение интенции объекта источника (src) сравнительно с
+объектом-целью (tgt) (см. Таблицу 4).
+μ-отношение Представление (representationOf) так же характеризуется своей сущностью (nature), используемой
+для различения аналитического и синтетического представления. И наконец причинность μ-отношения
+характеризуется булевым атрибутом causality для отношения representationOf. По нашему мнению формализация
+причинностных отношений представляется очень важной (т.ч. для инженерии, метамоделирования и т. д.) но
+рассмотрение этой проблемы вынесено за рамки темы моделирование моделирования.
+На Рисунке 4 построена графическая модель редактора на основе формального структурного определения
+моделирования.
+==== 4. Практическое использование моделирования ====
+Здесь в качестве примера рассматриваются интенциональные ограничения, на вплетение аспектов в репозиторий
+модели. Модель на Рисунке 5 может быть рассмотрена как спецификация ограничения, которое может усилить
+репозиторий модели. Данным ограничением утверждается, что порядок включения аспектов (включение сначала
+аспекта 1, а затем аспекта 2 в Базу, либо наоборот: сначала аспекта 2, а потом аспекта 1) не должно влиять на
+результирующую интенцию. M'1 и M'2 имеют одни и те же интенции, что показано двумя одинаковыми зацикленными
+стрелками.
+M1 и M2 созданы как расширения Базы, путем включения интенций, переносимых соответственно Аспектом 1 и
+Аспектом 2. Интенция M1 (и M2) включает в себя интенцию Базы, что отражено на схеме отношением Надмножества
+(super). Интенция М1 (M2) не полностью включает в себя  интенции Аспекта 1 (Аспекта 2). Необязательно
+требование представления  М1 (M2) аспектом (это, например, не несёт информацию о включениях) - вместо этого
+используется отношение Подмножества (sub). Далее представление M1 (M2) ещё более расширяется до M'1 и M'2. В
+итоге M'1 и M'2 имеют одинаковые интенции, что установлено отношением Тот же (same).
+[[mdd:_detail:mdd:modeling_6_копия.png|]]
+==== 5. Примеры ====
+=== Тестирование на основе модели ===
+Тестирование на основе построения моделей выполняется путем создания тестовых сценариев, которые могут
+использоваться для тестирования программы. На представленном Рисунке 6 с одной стороны разрабатываются модель и
+программа, в то время как тестовые сценарии пишутся отдельно. Затем тестирование состоит в проверке
+соответствия между этими двумя образами системы. При выявлении несоответствия, будет найдена ошибка.
+Тестовая модель является частичным представлением системы с дополнительным назначением - тестированием
+(нахождением ошибок), которое (назначение) в системе не представлено. Также тестовая модель является частичным
+представлением модели, которая разделяет содержание модели (понятия, обрабатываемые этими представлениями
+одинаковы), но опять же тестовая модель обладает этим дополнительным содержанием. В то же время,  модель
+является представлением системы. В дальнейшем модель используется для создания частей программы.
+Когда тестовая модель становится достаточно большой, тестовые сценарии могут быть автоматически синтезированы
+по данной модели согласно критерию адекватности теста. Таким образом, существует связь μα между этими двумя
+объектами. Данная особенная связь также предполагает что μα связь между тестовой моделью и системой
+распространяется на тестовые сценарии, которые, следовательно, также являются представлениями системы.
+Последнее отношение, которое заслуживает внимания, из  отмеченных на рисунке, заключается в том, что тестовые
+сценарии являются представлением программы, так как они могут предоставлять информацию для анализа наличия
+ошибок в программе. Однако, эти два аспекта не разделяют никакого содержания, так как целью тестовых сценариев
+является нахождение ошибок в программа, в то время как целью программы является обеспечение функциональности
+для некоторого пользователя.
+[[mdd:_detail:mdd:modeling_13.png|]]
+=== Моделирование моделирования моделирования ===
+Этот обзор озаглавлен “Моделирование моделирования моделирования”, что отражает тот факт, что  он представляет
+собой работу о формальной модели (на рисунке - F) языка (L), который в свою очередь представляет множество
+моделей систем (M и S на картинке). В качестве примера рассмотрим статью для журнала (модель модели модели),
+которая может быть расширена до трудов конференции (модель модели) через третий уровень моделирования, который
+будет соответственно докладом на основе этой статьи.
+[[mdd:_detail:mdd:modeling_15_копия.png|]]
+===== Заключение =====
+В статье приведён анализ различных определений моделей, основанный на анализе соответствующей литературы и
+предложен язык моделирования, который может быть использован для представления различных отношений между
+моделями, метамоделями и языками.
+===== Ссылки =====
+  - Ludewig, J., Models in software engineering - an introduction. SoSyM, 2003. 2(3): p. 5-14.
+  - [[http://dl.acm.org/ft_gateway.cfm?id=872565&ftid=210826&coll=DL&dl=GUIDE&CFID=469594174&CFTOKEN=38885209|Jean Bézivin and Olivier Gerbé. 2001. Towards a Precise Definition of the OMG/MDA Framework. In Proceedings of the 16th IEEE international conference on Automated software engineering (ASE '01). IEEE Computer Society, Washington, DC, USA, 273-.]]
+  - Brown, A.W., Model driven architecture: Principles and practice. SoSyM, 2004. 3(3): p. 314-327.
+  - Jackson, M., Some Basic Tenets of Description. Software and Systems Modeling, 2002. 1(1): p. 5-9.
+  - Kühne, T., Matters of (meta-) modeling. SoSyM, 2006. 5(4).
+  - [[http://dx.doi.org/10.1109/MS.2003.1231147|Ed Seidewitz. 2003. What Models Mean. IEEE Softw. 20, 5 (September 2003), 26-32. DOI=10.1109/MS.2003.1231147]]
+  - [[http://dx.doi.org/10.1109/MS.2003.1231146|Bran Selic. 2003. The Pragmatics of Model-Driven Development. IEEE Softw. 20, 5 (September 2003), 19-25. DOI=10.1109/MS.2003.1231146]]
+  - Steinmüller, W., Informationstechnologie und Gesellschaft: Einführung in dieAngewandte Informatik. 1993, Darmstadt: Wissenschaftliche Buchgesellschaft.
+  - Stachowiak, H., Allgemeine Modelltheorie. 1973: Springer, Wien.
+  - Favre, J.-M. Towards a Megamodel to Model Software Evolution Through Software Transformation. in Proceedings of Workshop on Software Evolution through Transformation, SETRA 2004. Rome, Italy: p.
+  - Favre, J.-M., Foundations of Model (Driven) (Reverse) Engineering: Models - Episode I: Stories of The Fidus Papyrus and of The Solarus. 2004, Dagstuhl Seminar 04101 on “Language Engineering for Model-Driven Software Development: Dagsthul, Germany.
+  - Muller P. - A., Fondement F., Baudry B., Combemale B. Modeling Modeling Modeling
+  - [[http://dx.doi.org/10.1007/s10270-010-0172-x|Pierre-Alain Muller, Frédéric Fondement, Benoît Baudry, and Benoît Combemale. 2012. Modeling modeling modeling. //Softw. Syst. Model.// 11, 3 (July 2012), 347-359. DOI=10.1007/s10270-010-0172-x]]