Главная >> Монографии

Pages: |

| 2 | 3 |

«В. И. ГУРЬЯНОВ ИМИТАЦИОННОЕ МОДЕЛИРОВАНИЕ НА UML SP Монография Чебоксары 2014 УДК 004.94 ББК 30в6 Г 95 Гурьянов В. И. Имитационное моделирование на UML SP: монография / В.И. Гурьянов. – Чебоксары : Филиал СПбГЭУ в г. ...»

-- [ Страница 1 ] --

Министерство образования и науки Российской Федерации

Филиал федерального государственного бюджетного образовательного

учреждения высшего профессионального образования

«Санкт-Петербургский государственный экономический

университет» в г. Чебоксары

В. И. ГУРЬЯНОВ

ИМИТАЦИОННОЕ МОДЕЛИРОВАНИЕ НА UML SP

Монография

Чебоксары 2014 УДК 004.94 ББК 30в6 Г 95 Гурьянов В. И. Имитационное моделирование на UML SP: монография / В.И. Гурьянов.

– Чебоксары : Филиал СПбГЭУ в г. Чебоксары, 2014. – 135 с.

ISBN 978-5-4246-0279-5 Печатается по решению редакционно-издательского совета Филиал федерального государственного бюджетного образовательного учреждения высшего профессионального образования «Санкт-Петербургский государственный экономический университет» в г. Чебоксары РЕЦЕНЗЕНТЫ:

доктор физ.-мат. наук, профессор В. Н. Орлов кандидат техн. наук, доцент М. В. Богданов кандидат физ.-мат. наук, доцент В. П. Филиппов В монографии излагаются основы имитационного моделирования с точки зрения объектно-ориентированного подхода. Имитационные модели представлены на разработанном автором специальном языке имитационного моделирования – UML Scientific Profile. Дается определение основных стереотипов профиля. Подробно рассмотрена методология Modeling SP – методология разработки объектных моделей.

Приводятся многочисленные примеры. Реализация имитационных моделей выполнена на C++. Монография рассчитана на научных работников, инженеров и аспирантов, интересующихся проблемами имитационного моделирования.

Станислав Улам в 40-х годах прошлого века, когда понял, что задача о вероятности выкладывания пасьянса может быть решена не только математически, но и экспериментально. Успешное решение задачи о движении нейтрона в изотропной среде, выполненное методом Монте-Карло Дж. фон Нейманом и С. Уламом, по-видимому, и может считаться отправной точкой в развитии имитационного моделирования.

В 50-е и 60-е годы для создания имитационных моделей использовались универсальные языки программирования, такие как FORTRAN и ALGOL, что получило название алгоритмического подхода. В 70-е годы Т. Нейлор попытался применить имитационные модели для изучения реальных экономических процессов. Однако на протяжении как 70-х, так и 80-х годов эти попытки были по большей части безуспешными. С середины 70-х годов появились инструментальные средства, имеющие собственные языковые возможности. Благодаря этому многие проблемы создания имитационных моделей в 80-х годах удалось преодолеть, снизив уровень сложности разработки модели до приемлемого уровня. Это породило то, что сейчас называют инженерным подходом. В последующие два десятилетия имитационные модели стали использоваться в контурах управления экономических субъектов и заняли вполне заслуженное место в практике управления.

Столь успешное развитие технологий специализированных пакетов имитационного моделирования неизбежно оттенило алгоритмический подход на второй план. В настоящее время создано множество замечательных учебных пособий по имитационному моделированию. За редким исключением (например, Труб И.И. «Объектноориентированное моделирование на C++» 2006 года издания), все они за основу берут тот или иной инструментарий (GPSS, Simulink, AnyLogic и др.). В тоже время применение имитационного моделирования в научных исследованиях требует использования всего арсенала информационных технологий, что предполагает построение имитационных моделей на универсальных языках программирования с учетом последних достижений в этой сфере.

В монографии выражена личная точка зрения автора на имитационное моделирование, а материал книги представляет собой некую компиляцию более ранних работ. Большая часть материалов была представлена на конференциях и семинарах, а также в различных публикациях 2010 – 2013 гг. Автор отдает себе отчет в том, что ряд гипотез и утверждений, высказанных в этой книге, носит дискуссионный характер, и ни в коей мере не настаивает на их абсолютной истинности. Большая часть подобных высказываний вынесена в разделы «Примеры и пояснения». Этот материал предполагает существование собственного мнения у читателя.

имитационного моделирования, т.е. некий объект, является имитационной моделью другого объекта, если их компоненты имеют одинаковые протоколы обмена сообщениями. Для описания объектных моделей используется специальный профиль UML (Scientific Profile или UML SP), основная идея которого состоит в том, чтобы каждой программной сущности назначать предметную семантику. Для этого используются стандартные механизмы расширения UML. Язык UML SP подобен языку SysML/UML (Systems Modeling Language), однако в отличие от последнего наделен двойственной семантикой, что и делает его инструментом имитационного моделирования. Кроме того, дано описание адаптированного унифицированного процесса, названного Modeling SP, что позволяет говорить о методологии разработки имитационных моделей.

В первой главе рассмотрены основы имитационного моделирования, в частности, обсуждается «коммуникационная» парадигма и понятие «язык моделирования». В разделе 1.2 приведен пример модели на UML SP. Желающие могут ограничиться прочтением только этого раздела, чтобы получить полное представление о нашем подходе. Во второй главе вводятся основные концепты и стереотипы UML SP; указаны элементы адаптации унифицированного процесса; приводятся примеры объектных моделей. Рассматриваются особенности моделирования экономических процессов, объектные модели организационных систем и бизнес-процессов. Кратко обсуждаются вопросы моделирования развивающихся систем и некоторые аспекты моделирования эволюции. В третьей главе представлены отдельные методы и подходы к изучению программных симуляций. В книге почти не рассматриваются традиционные вопросы имитационного моделирования, такие как метод Монте-Карло, статистическая обработка, системы массового обслуживания. Касаясь подобных вопросов, мы обычно рекомендуем ту или иную литературу.

Два слова о практической значимости предлагаемого подхода. Использование визуального языка как языка имитационного моделирования открывает новые возможности чисто инженерного приложения имитационных моделей. Рассматриваемый в этой книге профиль UML можно использовать как язык проектирования систем различной природы, в том числе экономических, политических и общественных. Причем проект системы будет не менее строгим, чем математическая модель. Мы полагаем, что имитационные модели можно построить даже в таких областях, в которых математическое моделирование пока недостаточно эффективно.

Имитационное моделирование широко применяется в самых разнообразных областях науки и техники. Нельзя ожидать, что все специалисты в конкретной области являются профессиональными программистами. Поэтому монография написана в форме учебного пособия по языку UML SP. Материал представлен так, чтобы не заставлять читателя обращаться к специальной литературе по программной инженерии.

Единственным исключением является необходимость владения навыками объектноориентированного программирования на языке C++. Для разработки приложений использовались системы программирования Borland C++ Builder и Cincom Smalltalk (VisualWorks 7.6).

Книга рассчитана на специалистов различных областей знаний, использующих имитационное моделирование в своих научных исследованиях. Кроме того, мы надеемся, что книга будет интересна также профессиональным программистам, поскольку «компьютерные игры», созданные природой, отличаются нетривиальностью и некоторой характерной эстетикой.

Автор выражает благодарность руководителю семинара «Математическое моделирование и прикладные задачи» доктору физ.-мат. наук В.Н. Орлову, а также всем участникам семинара, за плодотворное обсуждение некоторых тем, затронутых в этой книге.

Глава I. Основы имитационного моделирования 1.1. Унифицированный процесс Программная симуляция создается с помощью компьютерной программы. Поэтому для создания имитационной модели вполне применим процесс разработки программного обеспечения (Software Development Process). В монографии мы ограничимся унифицированным процессом разработки программного обеспечения (Unified Software Development Process, USDP).

Унифицированный процесс есть конечный результат исследований, проводимых в Ericsson (метод Ericsson, 1967), Rational (Rational Objectory Process, 1996–1997) и других ведущих компаниях. Особая роль принадлежит корпорации Rational Software, которая выпустила на рынок структурированную базу знаний под названием Rational Unified Process (RUP). RUP представляет собой набор рекомендаций по созданию практически любых программных продуктов. Обобщая опыт лучших разработок, RUP детально определяет когда, кто и что должен делать в проекте, чтобы в результате получить программную систему в установленные сроки, с определенной функциональностью и в рамках отведенного бюджета. Далее мы будем говорить об унифицированном процессе (UP) и будем придерживаться терминологии (и переводу терминов) книги [4].

Напомним основные термины и принципы унифицированного процесса.

Унифицированный процесс наглядно может быть представлен в виде матрицы Рабочие потоки Фазы (см. рис.1) [4].

Как видно на рис. 1, унифицированный процесс состоит из последовательности четырех фаз, каждая из которых завершается контрольной точкой:

• Inception (Начало) – цели и видение продукта;

• Elaboration (Развитие, Уточнение) – архитектура;

• Construction (Конструирование, Построение) – базовая функциональность;

• Transition (Переход, Внедрение) – выпуск продукта.

По мере прохождения этих фаз UP объем работ, выполняемый в каждом из пяти рабочих потоков, меняется.

К пяти основным рабочим потокам относятся:

• определение требований (построение Use Case Model) – сбор данных о том, что должна делать система, основные артефакты – диаграммы прецедентов и спецификация ПО;

• анализ (создание Analysis Model) – анализ требований и создание эскиза системы, основные артефакты – архитектура и диаграммы классов анализа;

• проектирование (разработка Design Model) – детальная проработка проекта системы, учет особенностей платформы;

• реализация – построение программного обеспечения;

• тестирование – проверяется, отвечает ли реализация предъявляемым требованиям.

Наиболее важными артефактами проекта являются модели: Use Case Model, Analysis Model, Design Model и д.р. Модель – целостный комплекс артефактов, который предоставляет самодостаточный взгляд на разрабатываемую систему. Самодостаточность моделей означает, что разработчик может из конкретной модели почерпнуть всю необходимую ему информацию, не обращаясь к другим источникам. Модели позволяют увидеть ее глазами будущих пользователей снаружи (Use Case Model) и глазами разработчиков изнутри (Analysis Model и Design Model) задолго до первой строки исходного кода. Большинство моделей представляются наборами UML-диаграмм.

В унифицированном процессе обычно используют следующие диаграммы:

диаграмма классов (class diagram), диаграмма состояний (statechart diagram), диаграмма деятельности (activity diagram), диаграмма последовательности (sequence diagram), диаграмма кооперации (collaboration diagram), диаграмма компонентов (component diagram), диаграмма развертывания (deployment diagram). Подробное описание диаграмм смотрите в книге [9].

Унифицированный процесс предполагает итерационную модель жизненного цикла.

Для средних и крупных проектов содержание этих итераций подробно рассмотрено в [35].

Разработка небольших моделей, в т.ч. тех, что рассматриваются в данной книге, может быть выполнена за три итерации. Для таких моделей удобно начинать разработку непосредственно с программы. Приведем следующую последовательность работ. В скобках приведены термины рабочих потоков.

Начало. На этой фазе производится выбор некоторого прототипа, который выражает концепцию проекта, причем этот выбор носит исключительно мыслимый характер. Поэтому мы это действие как итерацию выделять не будем.

Развитие (Уточнение). Итерация 1. Изучается предметная область. Если существует математическая модель моделируемого объекта, то ее следует включить в описание предметной области. Затем формулируются цели исследования, это позволяет определить, какие показатели должны измеряться в имитационных экспериментах (определение требований). Затем создается заготовка имитирующей программы (модель анализа). Можно воспользоваться шаблоном, приведенным в ПРИЛОЖЕНИИ I. Шаблон определяет архитектуру приложения. Затем необходимо внести изменения в шаблон, определив необходимые классы и задав наиболее важные связи между объектами (классы анализа). На этой итерации процедуры методов (модель дизайна) детализировать не стоит.

Конечный артефакт – заготовка программы. Конечно же, программа должна работать.

Развитие (Уточнение). Итерация 2. Методом обратного инжиниринга (reverse engineering) следует построить диаграммы UML, определяющие имитационную модель.

Некоторые CASE-системы поддерживают этот режим. Если такой возможности нет, то это можно сделать «вручную». Следует уточнить требования и построить диаграмму прецедентов; для каждого прецедента составить спецификацию (определение требований). В модели анализа нужны две диаграммы: диаграмма основных классов и архитектура (т.е. разложить классы по пакетам). Обе диаграммы должны показывать, как приложение реализует каждый прецедент. Модель дизайна на этой итерации обычно не уточняется. Конечный артефакт – UML-модель.

Конструирование (Построение). Итерация 3. Цель этой итерации – согласование кода программы и UML-модели. UML-модель, построенная на второй итерации как правило отличается от программы, построенной на первой итерации. Поэтому в программу следует внести изменения. Кроме того, дописываются коды методов, а в UMLмодели создается модель дизайна. Модель дизайна обычно содержит диаграммы деятельности, кооперации, последовательности действий. Эти диаграммы определяют алгоритмы процедур приложения. Конечный артефакт – согласованные UML-модель и программа.

Затем на тестах производится верификация модели. Цель верификации состоит в том, чтобы убедиться в правильности модели и программы. Для этого в качестве тестов используются некоторые частные случаи, точные решения для которых известны.

После третьей итерации собственно и начинается исследование имитационной модели.

Как уже было сказано выше, методология унифицированного процесса – это методология разработки любого программного обеспечения. В следующем разделе рассмотрен вариант унифицированного процесса, адаптированного под задачи имитационного моделирования (далее – Modeling SP).

1.2. Пример имитационной модели Продемонстрируем методологию Modeling SP на простом примере. Этот пример мы будем рассматривать как шаблон для моделирования на UML SP, а данный раздел – как концентрированное изложение языка UML SP. Все последующее изложение можно рассматривать как обсуждение различных вопросов, возникающих на практике.

Итак, допустим, что необходимо построить модель процесса покупки товара.

Описание предметной области. Покупатель встречается с продавцом с целью покупки товара. Продавец предлагает цену, покупатель обдумывает предложение. Если цена покупателя устраивает, то он покупает товар. Мы осознанно утрируем ситуацию, чтобы не отвлекать внимание читателя на детали модели сделки.

Код программы. Как было сказано в предыдущем разделе, для разработки относительно простых имитационных моделей удобно начинать процесс разработки имитационной модели непосредственно с кода. Опишем моделируемый процесс на языке программирования C++. Создадим главную форму (см. рис. 2; далее будем говорить о сцене), посредством которой Исследователь (Researcher) будет управлять имитационным экспериментом и визуализировать результаты моделирования. Сначала систему надо создать и приготовить начальное состояние. Это будет делать метод Button1Click (кнопка с надписью Приготовить). Пусть метод Button2Click (кнопка с надписью Продвинуть время) моделирует процесс сделки; результат эксперимента отображается в полях формы (см.

рис. 2).

Главная форма с элементами управления – это модель экспериментальной установки. Для того чтобы снимать показания, разместим также некоторый код в самой модели изучаемой системы. Совокупность этих операторов, включая сцену и некоторые другие объекты, назовем исследовательской установкой (Research Instruments). Для подобных программных сущностей (Epistemology Entity) далее будем использовать прилагательное «гносеологический». В имитационную модель процесса покупки гносеологические сущности не входят; мы их сознательно отделяем от самой модели (модуль Unit1, см. ПРИЛОЖЕНИИ I. Листинг 1).

Собственно имитационную модель представим классами Market., Buying, Agent и Fabric. Классы, подобные перечисленным, характерны для большинства имитационных моделей. Изучаемая система (Ontology System) моделируется экземплярами класса Buying (модуль Unit3, см. ПРИЛОЖЕНИИ I. Листинг 3). В дальнейшем для описания системы всегда будет создаваться специальный класс, который имеет, по меньшей мере, один метод, помеченный как exist (определяет единицу дискретно – событийного времени или, можно сказать, квант существования системы). Класс позволит инкапсулировать процесс покупки товара в объекте.

Кроме класса, моделирующего систему, необходим также класс, моделирующий окружение системы (Ontology Environment). Этот класс необходим для того, чтобы строго определить системные показатели, характеристики системы как целого, в частности, начальные и граничные условия. В нашем случае покупка осуществляется в контексте рынка (класс Market, модуль Unit2, см. ПРИЛОЖЕНИИ I. Листинг 2). Поэтому класс Buying должен иметь свойство deal, которое принимает значение true, если покупка совершилась и false – в противном случае. Обратите внимание – именно эту информацию мы и выводим на главную форму, т.е. Исследователь наблюдает за системой как бы со стороны, из контекста Market. Класс Market также обладает методом exist (сообщение посылает Исследователь), который в свою очередь посылает сообщение exist к объекту класса Buying. Экземпляр класса Agent – это Атомарный объект (Ontology Atom); нижний уровень объектной (точнее – объектно-темпоральной) декомпозиции системы. Код класса Agent приведен в Листинге 4, и в особом комментарии не нуждается. Единственно стоит обратить внимание на схематичность агента. Это не случайно. Единственное требование состоит в том, чтобы атомарный объект правильно описывал взаимодействие с системой.

Внутреннее строение агента «физического» смысла не имеет. Прилагательное «онтологический» используется для того, чтобы отличать атомарные объекты модели от других атомарных объектов (например, атомов языка программирования).

В классе главной формы определим одно поле pWorld (мир модели) и метод Button1Click запишем следующим образом:

void fastcall TForm1::Button1Click(TObject *Sender) { // Приготовить начальное состояние pWorld = new Market;

int r = StrToInt(Edit1->Text);

pWorld->Prepare(r);

а метод Button2Click:

void fastcall TForm1::Button2Click(TObject *Sender) { // Эксперимент pWorld->Exist(); // квант существования мира модели bool d = pWorld->observe; // Text = "Согласен с ценой"; // Text = "Товар куплен"; // Text = "Не согласен с ценой"; // Text = "Товар не куплен"; // deal и поле observe класса Market, также войдет в «Research Instruments» – это и есть отношение «Measurement».

Ключом к пониманию диаграммы классов является диаграмма кооперации (см.

рис.6). Исследователь инициирует моделируемый процесс, посылая сообщение «Exist»

объекту класса Market, который, в свою очередь, активизирует процедуру метода Buying::Exist(). Код этой процедуры имеет вид int m = pSeller->Offer(); // продавец предлагает цену pBuyer->Listen(m); // покупатель слушает предложение ответ if (d) { pBuyer->Buy(goods); // покупатель покупает товар На диаграмме видно, как агенты обмениваются сообщениями. Последовательность обмена сообщениями составляет коммуникационный протокол в этой системе, а в более сложной – модель системы документооборота. Каналом передачи сообщений будет среда (объекты m и d) класса Buying.

Диаграмма классов и диаграмма кооперации тесно связаны. Каждый объект – это экземпляр класса, каждая связь – экземпляр ассоциации. Поэтому на диаграмме классов должны быть показаны те ассоциации, для которых есть связи на диаграммах кооперации.

Проводя параллель с математикой, можно сравнить диаграмму классов с уравнением, а диаграмму кооперации – с одним из решений этого уравнения (диаграмма последовательности действий – аналог графика функции). Тем самым, диаграммы классов задают модель процесса коммуникации.

«Research Design Model» имеет технический характер и позволяет перейти от модели анализа к коду программы на конкретном языке программирования. Такой переход выражается в определении конкретных алгоритмов методов и обычно является результатом перехода от композиции параллельных процессов к последовательным. В нашем случае такой переход не вызывает трудностей, поскольку процессы (будучи параллельными) выполняются последовательно.

В рассмотренном примере код программы и модель на UML уже являются согласованными. В процессе разработки такая согласованность достигается ценой многочисленных итераций модель-код, причем обычно код программы корректируется по UML-модели.

1.3. О сущности имитационного моделирования Сначала определим наиболее общие понятия, такие как модель и моделирование.

Под моделью будем понимать объект m, который в некотором определенном смысле может замещать объект o. Таким образом, модель – это некий заменитель, т.е. суррогат объекта. Соответственно, моделирование – это процесс подбора объекта m, такого, чтобы он мог использоваться вместо объекта o, относительно некоторого действия. На наш взгляд, «некоторое действие», как правило, связано с познавательной ситуацией. Термин модель имеет два значения – то, которое мы определили выше, и более древнее значение, как объект для подражания. Термин модельная задача, который далее мы часто будем использовать, надо понимать именно в этом, последнем значении.

Есть разные точки зрения на имитационное моделирование. Можно, например, говорить об агентной парадигме или парадигме системной динамики. В данной книге мы будем придерживаться «коммуникационной» парадигмы, которая имеет много общего с дискретно-событийной парадигмой.

Между математической моделью и объектом моделирования общими являются отношения между элементами. Мы предположим, что между имитационной моделью и объектом исследования общим будет протокол обмена сообщениями между компонентами. Т.е. имитационная модель – всякий объект, который воспроизводит процесс коммуникаций исследуемого объекта. Конечно, сообщение – это тоже некоторое отношение между элементами. Поэтому имитационная модель – это математическая модель. Но если математика рассматривает отношения «вне времени», то коммуникативный акт характеризуется дискретностью и событийностью и предполагает дискретно-событийное время (так как сообщение всегда направлено от передатчика к приемнику и, тем самым, делает их не равноценными во времени). В имитационных моделях есть и другие отношения. Однако они вторичны – выбираются так, чтобы обеспечить определенный протокол обмена сообщениями.

Коммуникационная парадигма позволяет довольно четко определить объект исследования в задачах имитационного моделирования. Объектом исследования является коммуникационный процесс, или протоколы обмена сообщениями. Алгоритмический подход [10] мы получим, если выполним редукцию протоколов на процессную модель.

Отсюда следует, что имитационная модель и объект исследования имеют одинаковые алгоритмы поведения. Далее мы покажем, как системная динамика и многоагентные системы связаны с объектно-ориентированным имитационным моделированием.

Обсудим подробнее, что значит язык имитационного моделирования. Мы будем исходить из того, что код программы имитационной модели – это текст, описывающий некоторый кусочек действительности. Нам бы хотелось подчеркнуть это отдельно, потому что большинство авторов рассматривают объектно-ориентированное моделирование как способ написания «хороших» программ для имитационного моделирования. Различие состоит в том, что в нашем понимании код программы должен адекватно отражать описываемый феномен. Критерий адекватности мы уже указали – эквивалентность процессов коммуникации. Например, если мы моделируем лифт, то цикл на массиве – это не адекватное описание, а вот итератор – адекватное.

Текст всегда пишется на некотором языке. Напомним выразительное высказывание Галилея: «Философия написана в величественной книге (я имею в виду Вселенную), которая постоянно открыта нашему взору, но понять ее может лишь тот, который сначала научился постигать ее язык и толковать знаки, которыми она написана. Написана же она на языке математики». Точка зрения на математику как на мир идеальных объектов интересна и полезна (см. [22]), но, нам ближе понимание математики как языка. Мы будем также понимать имитационное моделирование как языковое описание действительности, точно так же как описанием действительности является математическое уравнение. Такая точка зрения конструктивна. Далее мы покажем, как может быть строго построен такой язык моделирования.

Идея языка моделирования появилась в начале 60-х годов. Джеффи Гордон (Geoffrey Gordon) в 1961 г. разработал язык моделирования GPSS (General Purpose Simulating System – моделирующая система общего назначения). Язык GPSS ориентирован на описание систем массового обслуживания и в нем реализован блочноориентированный подход. Язык GPSS стал языком, который и на сегодняшний день определяет технологические решения в дискретном имитационном моделировании. Почти в то же время Кристен Нюгор (Kristen Nygaard) предложил язык моделирования СИМУЛА, концепции которого в дальнейшем легли в основу объектно-ориентированного программирования. Концепции языка СИМУЛА мы рассмотрим подробнее.

В 1962 г. К. Нюгорт (Норвежский компьютерный центр) приступил к реализации проекта Simulation Language (отсюда и SIMUlation LAnguage), предназначенного для программного моделирования методом Монте-Карло. Он привлек к сотрудничеству Уле Джохана Дала (Ole-Johan Dahl). За основу был выбран язык программирования АЛГОЛИдея объединить данные с процедурами, их обрабатывающими, появилась в 1965 г.

Несколько позже появились и другие понятия – класс, объект, наследование, имитация параллельных вычислений. Новый язык вызвал интерес в Дании, Германии и СССР (в СССР в конце 60-х появилась реализация Симулы для УРАЛа-14 и БЭСМ-6).

Окончательная версия языка была закончена в январе 1967-го года и получила название СИМУЛА-67. В настоящее время разработаны и другие языки моделирования, среди которых можно назвать Modelica (пакеты MathModelica и Dymola), SLAM II (развитие FORTRANа), ObjectMath (пакет Mathematica).

Язык СИМУЛА предназначен для моделирования систем с дискретно-событийным временем, т.е. систем, представляющих последовательность сменяемых друг друга мгновенных событий. У. Дал определяет моделирование как «процесс представления динамической системы моделью для получения информации об этой системе путем проведения экспериментов над моделью». Цель разработчиков языка была определена так: «предоставить в распоряжение исследователя, строящего модель системы, концептуальную основу для ясного и четкого мышления; предоставить средства для описания динамических моделей; облегчить процесс программирования».

Появление многочисленных понятий ООАП продиктовано желанием разработчиков языка использовать СИМУЛУ-67 в качестве основы для построения специализированных языков, ориентированных на различные предметные области. У. Дал пишет: «Язык Симула-67 выходит за традиционные рамки языков программирования и может служить основой, на которой строятся различные математические и естественнонаучные теории от геометрии и алгебры до химической технологии и сельского хозяйства, даже в тех случаях, когда речь идет не об имитации или программировании, а лишь о получении количественной информации». Нам эта мысль кажется весьма привлекательной.

Эти идеи, несколько подзабытые в последние годы, нашли свое отражение также и в языке UML SP. С одной стороны UML SP предоставляет разработчику имитационной модели «концептуальную основу для ясного и четкого мышления», с другой – позволяет использовать методологию UP для разработки компьютерных моделей. От существующих языков моделирования наш подход отличается тем, что отделяет саму модель от способа реализации модели (язык программирования, методы аппроксимации, организация вычислений и т.п.), делая имитационную модель объективной и существенно более ясной.

Глава II. Разработка имитационных моделей 2.1. Визуальный язык имитационного моделирования UML SP Визуальный язык UML был разработан для проектирования программного обеспечения. Унифицированный язык моделирования (Unified Modeling Language) появился в конце 80-х в начале 90-х годов в основном благодаря усилиям Гради Буча, Джима Рамбо и Ивара Якобсона [9]. В настоящее время консорциум OMG принял этот язык как стандартный язык моделирования ПО. Мы будем в основном опираться на версию 1.5. UML имеет механизмы расширения, которые позволяют специализировать область применения языка. Такие расширения называются профилями UML. В данном разделе рассматривается профиль UML, далее называемый как научный профиль (Scientific Profile), предназначенный для описания объектных имитационных моделей [15].

2.1.1. Концепция UML SP. Мы определим три положения: (а) стереотипы обозначают концепты, (б) стереотипы имеют двойную семантику и (в) предполагается коммуникационная парадигма.

Профиль UML – это набор стереотипов, помеченных значений и ограничений.

Предполагается, что модель предметной области представлена в эксплицитной форме, например, как тезаурус, семантическая сеть или онтология. Эксплицитная форма – это такая форма представления знаний, которая допускает машинную обработку. Стереотип может определять новые метки и ограничения, которые не являлись частью исходного элемента. В профиль вводится двойственная семантика посредством механизма помеченных значений для стереотипов в виде {Concept = имя концепта}. Для разграничения семантик, будем говорить о вычислительной семантике (см., например, [34]) и о предметной семантике стереотипа. Поскольку профиль – расширение UML, то можно воспользоваться разнообразными методологиями проектирования ПО, такими как Unified Process [4], порождающее программирование и др. Идея профиля состоит в том, чтобы распространить эти методологии на разработку имитирующих программ.

Вследствие двойственной семантики можно будет говорить о методологиях построения имитационных моделей. Как будет показано далее, Scientific Profile предоставляет возможность создания повторяемого, предсказуемого и контролируемого процесса разработки имитационных моделей.

Приведем некоторые пояснения.

В языке UML предусмотрены механизмы расширения, которые применяется для уточнения синтаксиса и семантики. Механизм расширения включает в себя стереотипы, помеченные значения и ограничения.

Стереотипы позволяют создавать новые элементы языка на основе существующих элементов. Для применения стереотипа перед именем элемента необходимо добавить имя стереотипа во французских кавычках («…»). Стереотип обычно определяет ряд помеченных значений и ограничений, которые применяются к элементу, помеченному этим стереотипом.

Помеченные значения используются тогда, когда к элементу необходимо добавить некоторую специальную информацию. Синтаксис помеченных значений следующий:

{метка1 = значение1, …, меткаN = значениеN}. Мы используем помеченное значение Concept.

Ограничения задают условия или правила для элемента модели, которые должны быть истинными. Ограничения отображаются, как строка текста, заключенная в фигурные скобки ({}), расположенная рядом с элементом. Ограничения можно задавать на специальном языке OCL, который входит в стандарт UML. Этот язык подобен языку SQL и отличается от процедурного языка.

То, что каждой программной сущности следует назначать предметную семантику, вовсе не означает, что на диаграммах всегда следует показывать концепты. Напротив, это следует делать только тогда, когда это повышает наглядность диаграмм. Тем не менее, помеченные значения всегда присутствуют на так называемом семантическом заднем плане (semantic backplane) элемента UML, расширяя тем самым его спецификацию [4].

Мы будем придерживаться понимания онтологии в смысле системы Protg.

Protg – это одна из наиболее популярных систем работы с онтологиями, первая версия которой создана в Стэндфордском университете (США) в 1987 г. По мнению разработчиков системы Protg все понятия предметной области делятся на классы, подклассы, экземпляры [68].

Онтологии, если классифицировать их по принципу «общее-частное», подразделяются на следующие виды:

верхнего уровня – система наиболее общих концептов, не зависящих от конкретной предметной области (например, CYC – база знаний понятий окружающего мира);

онтологии предметной области (или онтология домена) – содержат понятия конкретной предметной области;

онтологии задач – описывают понятия, которые определяются конкретными задачами. Назначение такой онтологии в том, чтобы описать концептуальную модель конкретной задачи или изучаемой системы.

Таким образом, каждый элемент модели может иметь, хотя это и не обязательно, несколько концептов. Концепты онтологии верхнего уровня фиксируются в стереотипах.

Концепты онтологии задачи – в специальных именованных значениях {Concept = имя концепта} и ограничениях.

Онтологии предметной области образуют субпрофили (например, Scientific Profile for Active Systems); это позволяет специализировать профиль для конкретных научных областей. Можно подумать, что стереотипы субпрофиля строятся так же, как и стереотипы профиля, но только теперь в качестве метаклассов выступают стереотипы профиля. Это неверно. Стереотипы субпрофиля находятся в отношении обобщения со стереотипами профиля. Стереотипы субпрофиля замещают стереотипы профиля в конкретных моделях.

Продолжая параллель с математикой, заметим, что совершенно правомерно говорить об онтологии математических моделей, например об онтологиях уравнений математической физики. В научных текстах концепты определяются после ключевого слова «где».

Двойственная семантика UML SP предполагает две методологии, которые имеет смысл рассматривать раздельно. Методология, оперирующая с предметной семантикой – это методология моделирования систем. Методология отличается от других системных методологий. По своей форме и используемым методам данная методология подобна унифицированному процессу, но предназначена для моделирования систем произвольной природы. Методология, оперирующая с вычислительной семантикой – это методология ООАП. Методология подобна унифицированному процессу (хотя явно тяготеет к методу Domain-Driven Design), но формально не совпадает с ним, поскольку унифицированный процесс использует свой набор стереотипов и потому пользуется другим UML-языком.

Важно подчеркнуть, что каждая из двух методологий может применяться совершенно автономно: для разработки моделей систем в системном анализе и для проектирования ПО соответственно. Что касается Domain-Driven Design, то применительно к имитационному моделированию интересна работа [28]; см. сайт [40].

Однако если обратится к компьютерному имитационному моделированию, эти методологии следует рассматривать только как единое целое. Это выражается в том, что процесс разработки имитационной модели предполагает итерационную разработку, при которой используется либо один, либо другой аспект UML SP. В этом случае возможно возникновение противоречий между моделью системы и моделью программы. Чтобы гарантированно исключить возникновение противоречий, потребуем, что бы обе модели описывали некий инвариант, хотя и разными понятиями. В качестве такого инварианта мы будем рассматривать коммуникационную парадигму, т.е. и модель системы, и модель ПО должны описывать один и тот же коммуникационный процесс. В данной монографии единую методологию мы будем называть MSP (Modeling SP – моделирование на научном профиле) с тем, чтобы подчеркнуть то, что данная методология – это методология разработки имитационных моделей, а не методология имитационного моделирования.

Сделаем еще одно примечание. Разработка ПО имитационного моделирования выполняется согласно унифицированному процессу и не сводится к разработке имитационной модели. Методология MSP как методология ООАП специально максимально приближена к UP с тем, чтобы можно было встраивать артефакты MSP в UP с минимальными усилиями.

Далее обе методологии рассматриваются параллельно, причем в большинстве случаев, сначала будем рассматривать вычислительную семантику, а затем – предметную.

Тем не менее, не следует забывать, что каждая из методологий может быть определена независимо одна от другой. В первом случае предметом моделирования является реальная, существующая в физическом мире система. Во-втором – программная система.

2.1.2. MSP и основные стереотипы UML SP. Стереотипы UML SP имеют много общего со стереотипами SysML, однако эта тема заслуживает отдельного анализа, и здесь мы этой темы касаться не будем. Строгое определение стереотипов UML SP см. в ПРИЛОЖЕНИИ III. Сейчас мы дадим определение основных стереотипов в контексте их использования в MSP. Как сказано выше, методология разработки имитационных моделей строится по аналогии с UP. Напомним, что UP предполагает следующие рабочие потоки:

Требования (метод прецедентов), Анализ, Проектирование и д.р. Рассмотрим рабочие потоки в этом порядке.

В качестве основы моделирования систем будем использовать концепцию «трех миров» К.Р. Поппера [46]. Структура реальности, согласно К. Попперу, имеет три компонента: мир ментальных состояний и процессов, физический мир и мир продуктов сознания. Именно такой смысл мы будем вкладывать в концепты стереотипов Research Use Case Model, Research Analysis Model, Research Design Model. С точки зрения вычислительной семантики для интерпретации стереотипов полезна точка зрения семиотики. Мир продуктов сознания – это код имитирующей программы, который, в свою очередь, рассматривается как текст, описывающий предметную область. UMLпрофиль будет играть роль метаязыка. Прагматика задается стереотипом Research Use Case Model, семантика – Research Analysis Model, а синтактика – Research Design Model.

Стереотип Research Use Case Model определяет цели и намерения Исследователя (стереотип Researcher "metaClass" Actor), последние обслуживаются прецедентами (случаями использования). Модель прецедентов есть метод определения требований, и предназначена для спецификации имитирующей программы.

В этом рабочем потоке производится сбор информации об объекте моделирования, определяются цели и задачи исследования, строится модель требований, диаграммы прецедентов, составляется спецификация прецедентов. Последнее и есть собственно спецификация имитирующей программы.

Типичные прецеденты: Приготовить начальное состояние, Вычислить новое состояние, Обработать результаты наблюдения, Визуализировать результат. Среди ролей Исследователя отметим роли Наблюдатель контекста и Наблюдатель системы, и будем различать их тем, где расположены датчики измерений (прежде всего детекторы и хронометры). Для примера п. 1.2. диаграмма прецедентов будет иметь вид, показанный на рис. 3.

Спецификация прецедента в простейшем случае должна содержать: предусловие, этапы сценария, постусловие. Более подробно о спецификации прецедентов см. [4].

Спецификации всех прецедентов образуют спецификацию программы (SRS).

«Research Analysis Model» создается в рабочем потоке Анализ и имеет два основных артефакта – архитектуру имитирующей программы и диаграммы классов (см.

рис. 4 и рис. 5). Данная модель фокусируется на том, что должна делать система, чтобы прецеденты были выполнены. Детали того, как система будет это делать, предоставляются потоку Проектирование [4]. В рамках профиля аналитическая модель задает семантику (предметную и вычислительную) имитационной модели, и мы рассмотрим эту модель наиболее подробно.

Модель анализа требований представлена пакетом со стереотипом Универсум («Universe»). Типичная архитектура «Research Analysis Model» определяется четырьмя пакетами, распределенными по двум уровням абстракции (специфическому и общему) и двум разделам (гносеологическому и онтологическому); см. пример на рис. 4. Заметим, что архитектура не входит в определение UML SP и является артефактом рабочего потока анализа. Знание архитектуры значительно облегчает понимание ограничений, накладываемых на стереотипы. Вычислительная семантика архитектуры имитационной модели может быть задана архитектурным паттерном MVC, который сам состоит из трех паттернов – Observer, Strategy и Composite [14]. Паттерны Observer и Strategy моделируют наблюдение за системой и экспериментальное воздействие на систему, а паттерн Composite определяет иерархию классов для Observer и Strategy. Возможны и другие архитектурные паттерны.

На специфическом уровне заданы пакеты со стереотипами Исследовательская установка («Research Instruments») и Мир модели («World»). Стереотип Измерение («Measurement») применяется к отношению зависимости, связывающему данные пакеты.

Мы определяем это отношение как контролируемое нарушение инкапсуляции классов пакета «World». Стереотип Мир модели отражает исследуемую систему и ее окружение и содержит описание имитационной модели в традиционном понимании. Пакеты со стереотипами Epistemology Entity и Ontology Entity общего уровня задают методологии проведения измерений и экспериментов и законы функционирования системы в стереотипах UML. Их вычислительная семантика определяется как повторно используемые компоненты линейки ПО имитационной модели. В пакетах онтологического раздела запрещено использовать какие-либо классы, кроме помеченных меткой Concept (есть два исключения, см. далее). В корневой пакет «Universe» заносится класс Magnitude и все или некоторые из его потомков. Это обеспечивает доступ всех пакетов к данному классу. Предметная семантика этих классов определяется как агент взаимодействия гносеологических и онтологических объектов и предназначена для определения общего типа интерфейса. Выбор этих классов определяет набор доступных измерительных шкал (классификационные, сравнительные и количественные шкалы).

Для определения концептов архитектурных стереотипов будем опираться на концепцию «четырех миров», предложенную К.К. Колиным (доклад на 10-м заседании семинара «Методологические проблемы наук об информации» под названием «Философия информации: Структура реальности и феномен информации»; Москва, ИНИОН РАН, 7 февраля 2013 г., см. [31]). Обсуждая вопрос о сущности информации, К.К.

Колин предложил двухуровневую модель реальности. На верхнем уровне два компонента – физическая и идеальная реальность. На втором уровне идеальная реальность представлена тремя компонентами: объективная идеальная реальность первого рода (ИРсубъективная идеальная реальность (ИР-2) и объективная идеальная реальность второго рода (ИР-3).

В контексте методологии MSP мы будем понимать данную концепцию следующим образом. Концепт стереотипа Research Instruments определим как ИР-2 («феномен сознания человека, а также продукты деятельности сознания, существующие внутри него») с той поправкой, что «феномен сознания человека» выражен в инструментах научного познания. Концепт стереотипа Epistemology Entity определим как ИР- («совокупность нематериальных продуктов деятельности сознания, находящихся вне его»). Под ИР-1 понимается идеальная реальность, которая «возникает в результате взаимодействия отдельных компонентов физической реальности и их взаимного отражения». Примем это как определение концепта «Ontology Entity». Пакет «Ontology Entity» содержит абстрактные классы, которые не могут иметь экземпляров. Приняв данное определение, мы можем сказать, что сущности данного пакета моделируют элементы объективной идеальной реальности первого рода. Понятие «физическая реальность» назначим концепту «World». Зависимость пакета «World» от «Ontology Entity»

будем понимать как проявление феномена так называемой «физической информации».

Классы Magnitude, доступные всем пакетам Универсума, по-видимому, тесно связаны с обобщенным определением информации, предложенным К.К. Колиным (это определение применимо как к материальным, так и к идеальным компонентам реальности). К.К. Колин придерживается атрибутивного подхода к определению понятия информация:

«Совокупность … различий и есть информация» (в смысле А.Д. Урсула).

Итак, мы определяем четыре стереотипа для архитектурных пакетов. Два из них («Research Instruments» и «Epistemology Entity») мы рассмотрим в третьей главе монографии, а сейчас обратимся к подробному рассмотрению пакетов, помечаемых стереотипами World и Ontology Entity.

Архитектурный пакет «World». Этот пакет моделирует изучаемую систему. Пакет содержит конкретные классы и диаграммы деятельности, отражающие алгоритмы поведения системы. Его содержимое есть результат декомпозиции системы на подсистемы.

Структурная декомпозиция занимает центральное место в системном анализе и известна достаточно хорошо. Этого нельзя сказать о декомпозиции поведения. По нашему мнению, для обоснования подбора стереотипов можно воспользоваться одной из логик изменения. Мы предлагаем следующий подход.

Алгоритмическая логика – это формальная система, которая допускает различные интерпретации. С точки зрения вычислительной семантики данную формальную систему мы будем интерпретировать как логику программирования, а с точки зрения предметной семантики – как некую логику изменения. Логику мы будем понимать в ее первоначальном смысле – как «науку о правильном мышлении», «искусство рассуждения». Наша цель исключительно утилитарная – использовать логику изменения как набор правил декомпозиции активности.

Формулы логики – это тройки {P} S {Q} (тройки Хоара), где P и Q – предикаты, а S – оператор или список операторов. Интерпретация логики отображает каждую формулу в ложь или истину.

Интерпретация тройки с точки зрения вычислительной семантики. Тройка {P} S {Q} истинна при условии, что если выполнение S начинается в состоянии, для которого высказывание P истинно, и завершается, то для постусловия высказывание Q истинно.

Интерпретация тройки с точки зрения предметной семантики. Тройка {P} S {Q} истинна при условии, что ситуация, для которой истинно высказывание P, исчезает, а ситуация, для которой истинно высказывание Q, возникает. Процесс S исчезновения и возникновения будем называть активностью. Пример: перемещение пешехода из пункта A в пункт B.

Подобная интерпретация алгоритмической логики приводит к временной (темпоральной) логике. Действительно, тройка Хоара очень похожа на формулу фон Вригта ATB, которая читается так: сейчас A, а в следующий момент B. Поэтому можно поступить иначе – взять за основу некоторую временную логику, например логику Пнуели, и определить для этой логики вычислительную семантику [23], [30]. Заметим, что логика времени является составной частью логики изменения. Мы решили взять за основу именно алгоритмическую логику потому, что такой подход ближе к стилю изложения данной книги. Для декомпозиции поведения воспользуемся алгоритмической логикой [62] и приведем ее краткое описание (подробнее см. [23]). Наиболее важными правилами вывода являются: аксиома присвоения, правило последовательной композиции, правило оператора if, правило оператора while, правило следования и правила, связанные с параллелизмом. Их вычислительная семантика соответствует семантике языков программирования. Предметная семантика будет следующая.

Оператор присвоения. Аксиома присвоения: {Pxe} x = e {P}, где Pxe есть замена переменных x на выражение e (текстуальная подстановка). Смысл этой аксиомы поясним на частном случае {Pab} a = b {P}, где a, b – некоторые объекты. Пусть утверждение P для объекта b истинно, тогда после присвоения a = b утверждение P будет истинно применительно к объекту a. Тем самым, эта аксиома постулирует такую разновидность активности, когда один объект подменяется на другой. Относительно предиката P объект a неотличим от b. Можно также сказать, что эта разновидность активности есть копирование.

Оператор композиции (;).

Правило композиции.

С точки зрения предметной семантики оператор композиции постулирует такой вид активности, которая соответствует понятию последовательность. Пример из теории динамических систем – свойство фазовой траектории, которое заключается в том, что фазовую траекторию можно разбить на два участка.

Оператор skip. Для этого оператора имеет место аксиома: {P} skip {P}.

С точки зрения предметной семантики оператор skip постулирует существование такого вида активности, который может быть определен термином «статика». Для этого оператора предикат P является инвариантом. Пример из теории динамических систем – устойчивый или неустойчивый узел. Этот вид активности тесно связан с понятиями активное ожидание. В системной динамике Дж. Форрестера этот вид активности нашел свое отражение в концепции запаздывания.

Приведем следующий код int x = 0; // высказывание «x == 0» истинно while (true) { x = SetValue(x);

if (x>0) x = x – 1; // эти два оператора задают оператор skip if (xcharacteristics = 0;

Thing b; b = *pa; // используется копирующий конструктор.

Однако если класс Thing является потомком класса TThread, подобный код вызывает ошибку на стадии компиляции. В квазипараллельном моделировании подобные объекты можно моделировать классом, для которого копирующий конструктор определен явно, но объявлен как private.

В приведенном выше коде, по существу, имеют место два объекта: исходный *pa и его копия b. Такие объекты мы будем называть информационными, поскольку они допускают тиражирование. Напротив, объекты, которые не могут быть копированы, будем называть вещественными. Для этих объектов выполняется закон сохранения их общего количества, если только объекты не создаются и не уничтожаются. Для вещественных объектов допустимо копирование только указателей. Мы будем полагать, что абстрактный класс «Substance» фиксирует это свойство. Напомним, что аксиома присвоения – это одна из центральных аксиом алгоритмической логики. Несмотря на то, что эти два рода объектов имеют весьма разные свойства, модель коммуникативного акта применима в обоих случаях. Идея разделения потоков на вещественные и информационные наиболее четко была высказана Дж. Форрестором в его системной динамике. Интересно, что термин «коммуникация» в ряде словарей трактуется именно в этих двух значениях: (а) как средства связи и (б) как средства сообщения (трубопроводы, пути, дороги).

Определим процедуры измерения для вещественных объектов. Мы предлагаем следующее наиболее общее решение. Рассмотрим класс, который не является потоковым классом, но полностью повторяет интерфейс исходного класса. В приведенном выше примере это будет класс IThing class IThing { int characteristics;

const IThing& operator = (const IThing &m) {// операция ‘=’ по умолчанию this->caracteristic = m.caracteristic;

const IThing& operator = (Thing &m) { this->characteristics = m.characteristics;

В этом классе перегружена операция присвоения и тем самым становится возможным получение мгновенных снимков потока Thing Thing *a = new Thing(false);

IThing *b = new IThing; *b = *a;

Объект *b класса IThing является информационным объектом, и его можно тиражировать (см. последнею строку кода). Можно не перегружать операцию присвоения, определенную по умолчанию (и лучше этого не делать); это сделано для большей наглядности. Для класса IThing необходимо также перегрузить операции равенства, отношения и арифметические операции, что позволит определить все необходимые измерительные процедуры. Мы для таких классов используем префикс I, подразумевая слово image, однако совпадение с общепринятым обозначением интерфейса также не случайно. Рассмотренное решение заставляет предположить, что необходимо определить отдельный стереотип, для определения таких классов. Однако мы не будем этого делать, поскольку предметная семантика этих классов не ясна.

По умолчанию все классы будем считать информационными объектами, если они не помечены стереотипами категории «структура». В эту категорию включим потоковые классы (потомки TThread) тройки объектной декомпозиции «Ontology Environment», «Ontology System» и «Ontology Atom».

Предметную семантику стереотипа Ontology Environment определим как «весь мир, кроме изучаемого объекта», и этот класс определяется на самом первом шаге декомпозиции. С точки зрения системного анализа объекты с этим стереотипом определяют функцию системы относительно окружающей среды и позволяют задать ее системные характеристики. Окружающая среда задается крайне схематично, однако ее связи с системой определяются с необходимой точностью. Как правило, анализируются горизонтальные и вертикальные связи. В простых случаях достаточно определить только начальные и граничные условия. Внутренним переменным класса «Ontology Environment»

нельзя назначать концепты, а программный код составляется исходя из соображений удобства.

Стереотипом Ontology System будем помечать классы самой изучаемой системы и классы подсистем всех ярусов иерархии, кроме нижниго. Внутренним переменным класса, локальным переменным и методам должны назначаться концепты (по крайней мере, в принципе), а программный код составляется исходя из соображений адекватности.

Предметная семантика стереотипа Ontology Atom определяется как конечный уровень декомпозиции изучаемой системы на подсистемы. Это могут быть акторы, интеллектуальные и рефлексирующие агенты. Композиция подобных объектов моделирует подсистему также весьма схематично, но их внешние связи определяются с необходимой точностью. Внутренним переменным класса «Ontology Atom» нельзя назначать концепты, а программный код составляется исходя из соображений удобства.

В настоящее время существует ряд математических теорий, опираясь на которые можно определить декомпозицию системы как формальную процедуру. Например, аппарат родов структур Н. Бурбаки. Очень интересный подход, основанный на этом математическом аппарате, развит Ю.И. Бродским [6]; см. сайт [40]. На наш взгляд, этот подход весьма тесно пересекается с проблемой декомпозиции систем, хотя сам автор придерживается несколько иной точки зрения.

Применение стереотипов. Сформулируем методику декомпозиции системы, которая в значительной степени опирается на рассмотренную выше логику изменения.

Правила вывода мы будем рассматривать в обратном порядке – от следствия к условию.

Тогда вместо правил вывода можно говорить о правилах декомпозиции активности.

Метод декомпозиции систем нашел свое отражение в таких методологиях, как IDEF0, DFD, а также в ООАП [8]. В имитационном моделировании особое значение имеет поведение систем, что требует обобщение этого метода на поведенческие аспекты декомпозиции. Для построения объектных моделей будем опираться на принцип, который можно назвать принципом объектно-темпоральной декомпозиции. Прежде всего, напомним, что система в UML SP – это система коммуникаций. Обычно, говоря о декомпозиции системы, подразумевают структурную декомпозицию. Мы под декомпозицией системы будем подразумевать выполнение декомпозиции как структуры, так и поведения системы. Результат декомпозиции системы представляет собой сеть коммуникаций, связывающую процессные центры, обрабатывающие сообщения, передаваемые по этой сети. Всякий раз, когда выполняется объектная декомпозиция системы, необходимо для этих объектов определять кванты их существования (т.е.

единицы дискретно-событийного времени).

Прежде всего, необходимо определиться со способом описания параллельных процессов. Существуют два способа и, судя по всему, они эквиваленты. Пусть есть несколько процессных центров и несколько документов. Если отслеживать историю документа, то описание сводится к последовательности процессных центров. Если отслеживать историю процессного центра, то получим последовательность обработанных документов. В теории параллельного программирования первый случай называют декомпозицией по информационным потокам, второй – декомпозицией по заданиям.

Декомпозиция по данным – это одновременная обработка двух или более документов одного типа; предполагается, что и обрабатывающих центров также больше. В бизнесмоделировании первый способ описания называется процессным подходом, второй – моделированием на основе организационно-штатной структуры. В механике сплошной среды первый способ называется методом Лагранжа, второй – методом Эйлера.

Процедура декомпозиции предполагает выполнение трех этапов: объектную декомпозицию, определение горизонтальных взаимодействий и определение квантов существования подсистем.

1. Объектная декомпозиция [8]. Декомпозиция системы должна быть проведена так, чтобы множества переменных стали непересекающимися [62]. Наиболее общее решение – это инкапсуляция переменных в объектах. Мы допускаем, что архитектурный паттерн, определяющий структурную декомпозицию – это паттерн Composite. Тем самым, модель изучаемой системы будет определяться стереотипами Окружающая среда («Ontology Environment»), Система («Ontology System»), Атом («Ontology Atom»), которыми будут помечаться соответствующие классы. Это предположение соответствует основным положениям системного анализа и закреплено в определении стереотипов.

2. Горизонтальные взаимодействия и горизонтальная синхронизация. Поскольку компоненты системы взаимодействуют друг с другом посредством разделяемых переменных, то одной объектной декомпозиции недостаточно для обеспечения взаимного невмешательства. Объектная декомпозиция определяет модель системы, в которой взаимодействия отсутствуют. На данном этапе определяются связи между объектами, выделенными на первом этапе. Еще раз напомним, что система в UML SP – это система коммуникаций. Процесс коммуникаций описывается диаграммами кооперации. Каждая диаграмма кооперации должна быть экземпляром диаграммы классов, так что каждый объект есть экземпляр некоторого класса, а каждая связь – экземпляр некоторой ассоциации. Для строгого анализа взаимодействий можно использовать метод глобальных инвариантов [62].

3. Вертикальная синхронизация. После того, как определены горизонтальные взаимодействия, можно определить, какова должна быть структура атомарной операции await(P) S; выделенных объектов; т.е. определить, как должен выглядеть для основного потока квант существования подсистем. Нижележащий уровень декомпозиции будем рассматривать как абсолютный темпомир.

Эти атомарные операции нижележащего уровня должны быть синхронизированы с потоком текущего уровня. Уточним, что потоки не могут быть вложенными, но они могут быть синхронизированными. Мы будем исходить из гипотезы темпоральной синхронизации иерархии. Горизонтальные связи в системе образуют как асинхронные взаимодействия, так и синхронные взаимодействия. Напротив, вертикальные связи в системе образуют только синхронные взаимодействия. Действительно, в противном случае иерархическая система как целое существовать не может. Этот вопрос обсуждается, например, в книге И.В. Прангишвили [47] как «закономерность расхождения темпов жизненных функций элементов системы». Для проверки отсутствия взаимного вмешательства можно использовать ослабленные утверждения (правило следования) [62].

Декомпозиция выполняется рекурсивно. Процесс декомпозиции заканчивается тогда, когда дальнейшая декомпозиция с точки зрения текущей задачи моделирования становится излишней.

Рассмотрим пример декомпозиции системы, используя изложенную выше методику.

Прогулки Иммануила Канта. Пусть необходимо построить имитационную модель, которая описывает следующую ситуацию. Некий философ просыпается всегда в пять часов утра. В строго определенное время он выходит из дома для прогулки и ровно через час возвращается домой. В остальное время, свободное от сна и обеда, философ занимается размышлениями. В десять часов вечера философ ложится спать. Эта последовательность действий повторяется каждый день.

Первый шаг декомпозиции – контекстная диаграмма (рис. 7). В результате объектной декомпозиции получим два объекта – саму изучаемую систему (класс Koenigsberg, помечается стереотипом Ontology System) и «все остальное» (класс Setting, помечается стереотипом Ontology Environment). Объект класса Setting определяет начальные и граничные условия для объекта класса Koenigsberg. Основной цикл потока Setting имеет период 365 дней.

Взаимодействие по горизонтальным связям сводится к годовому изменению степени освещенности, которое задает изменение граничных условий. Поток Setting каждые сутки устанавливает свойство season класса Koenigsberg. Это взаимодействие описывается специальным вариантом паттерна Producer/Consumer, когда не только Consumer ждет записи в буфер season, но и Producer должен ждать считывания записи.

Данный паттерн - одна из самых распространенных программных конструкций параллельного программирования. Если не вдаваться в подробности, то паттерн Producer/Consumer представляет собой ни что иное, как обычную очередь, и используется для передачи данных посредством разделяемых переменных.

Для выполнения синхронизации по вертикальным связям необходимо обеспечить рандеву потоков Setting и Koenigsberg. Квант существования (атомарное действие) системы Koenigsberg определим как активность от одной точки рандеву до другой.

Активность «Exist» (метод Execute) класса Koenigsberg моделирует суточное вращение и в нашей модели сводится к последовательному изменению значения булевой переменной day. Будем предполагать, что синхронизация происходит в полночь (day == false).

Поскольку поток Setting не может вмешаться в вычисления потока Koenigsberg, с точки зрения наблюдателя Setting, активность «Exist» класса Koenigsberg представляет собой событие; выполнение некоторого оператора в основном цикле. По той же причине, с точки зрения наблюдателя Koenigsberg, поток Setting выглядит приостановленным.

Для обеспечения рандеву используем стандартную схему с двумя разделяемыми объектами синхронизации TEvent (см. ПРИЛОЖЕНИЕ II). Сначала событие e1 сброшено и поток Setting ждет, когда поток Koenigsberg придет в точку рандеву и установит его.

Поток Koenigsberg приостанавливается. После чего поток Setting выполняет запись в свойство season класса Koenigsberg. Затем поток Setting устанавливает событие e2, что разрешает потоку Koenigsberg продолжить вычисления.

Второй шаг декомпозиции – декомпозиция контекстной диаграммы (рис. 8). В результате объектной декомпозиции получим объекты классов TowerClock и Townsman.

Жителей города моделируют экземпляры класса Townsman, а башенные часы – экземпляр класса TowerClock. Взаимодействие между жителями города и часами осуществляется через колокольню собора BellTower. Все вещественные объекты (Koenigsberg, TowerClock, Townsman) являются потомками класса TThread.

Горизонтальные связи. Взаимодействие между жителями города и башенными часами будем моделировать паттерном Producer/Consumer в его общей формулировке.

Каждый житель города в роли Consumer ожидает наступления очередного часа, после чего синхронизирует свои часы. Если по какой-то причине он не синхронизировал часы, то соответствующее сообщение ставится в очередь. В роли Producer выступает объект класса BellTower. Поскольку жителей города много, а башенные часы ничего не знают о них, естественно воспользоваться паттерном Observer [14] (см. рис. 8). Класс Subject посредством метода Attach позволяет подписываться всем желающим жителям города (аргумент Observer*) на оповещение и посредством метода Notify оповещает их. Одной из конкретных реализаций класса Subject будет класс BellTower, который моделирует колокольню с колоколом (другая реализация – класс, моделирующий циферблат). Зная взаимодействие, необходимо определить способ синхронизации. Для объектов класса Townsman мы будем использовать активное ожидание, т.е. активность каждого из объектов не приостанавливается, а сводится к циклической проверке ожидаемого события.

- e1: TBEvent;

- tow er_clock: Tow erClock;

+ Koenigsberg(bool CreateSuspended) + Execute( ) Вертикальные связи. Взаимодействие объекта TowerClock с системой Koenigsberg выражается в том, что сторож колокольни каждый день в астрономический полдень (day == true) устанавливает часы на 12 часов. Взаимодействие объектов класса Townsman с объектом Koenigsberg заключается в том, что физиологический процесс бодрствование/сон подстраивается под смену дня и ночи. Объекты имеют 24-х часовой цикл и всякий раз на 12-ой итерации приходят к точке рандеву. Точка рандеву у всех объектов одна и та же, поскольку рандеву моделирует взаимодействие с объектом Koenigsberg. Однако каждый объект может эту точку использовать по-разному, например, возможно взаимодействие с запаздыванием.

Для синхронизации потока TowerClock и потоков Townsman с потоком Koenigsberg будем использовать такую конструкцию, как барьер (barrier). Реализуем барьер как мультиобъектный вариант TEvent (класс TBEvent; этот класс можно собрать, используя TEvent). От класса TEvent этот класс отличается тем, что имеет внутренний счетчик.

Объект Koenigsberg вызывает метод ResetBarrierEvent и устанавливает счетчик в значении, равном числу объектов синхронизации, а событие барьера – в сброшенное состояние. Всякий раз, когда синхронизируемые объекты вызывают метод SetEvent, счетчик понижается на единицу и поток приостанавливает себя. Когда счетчик становится равным нулю, устанавливается событие барьера. Объект Koenigsberg ждет, пока не произойдет событие барьера объекта TBEvent.

Как и на предыдущем шаге, активность «Exist» (метод Execute) классов TowerClock и Townsman рассматривается потоком Koenigsberg как атомарное действие, т.е.

представляет собой событие. С точки зрения потоков TowerClock и Townsman время суток не меняется.

Третий шаг декомпозиции – определение атомарных объектов. В рамках данной задачи последующая декомпозиция является излишней. Поэтому все подсистемы, выделенные на предыдущем шаге декомпозиции, определим как атомарные объекты и пометим стереотипом Ontology Atom. Методы, помеченные стереотипом Exist, уточняем любым удобным способом, например, кодируем так, как определено на предыдущем шаге.

Существенное теоретическое и практическое значение в построении имитационных моделей имеет решение вопроса о том, что есть физическое время. В научной литературе можно найти множество концепций времени. Мы будем придерживаться следующего определения: « … физическое время – это количественная мера упорядоченной эволюции материального объекта как целого от его возникновения до гибели» [49]. Из этого определения следует, что время – гносеологическая сущность, т.е. продукт процедуры измерения. Это в свою очередь означает, что время непосредственно не должно определять ход событий в модельном мире. В противном случае мы должны будем признать онтологический характер времени. Определение также указывает на то, что должно измеряться – эволюция материального объекта. Причем не просто какое-то локальное изменение, а изменение объекта как целого. Сразу оговоримся, что в сложных системах, таких как общественные системы, есть все основания для введения онтологического времени (например, модель хронотопа).

Мы предлагаем следующую измерительную процедуру. Необходимо отслеживать изменение вещественного объекта (потока). Однако невозможно сделать его копию и сравнить затем копию с оригиналом. Поэтому необходимо создавать информационные объекты-копии и сравнивать эти объекты друг с другом. Воспользуемся методом, рассмотренным выше. Построим класс, который не является потоковым классом, но полностью повторяет интерфейс исходного класса. Для нашего примера это будет класс IKoenigsberg class IKoenigsberg { const IKoenigsberg& operator = (Koenigsberg &m) { bool operator == (const IKoenigsberg &m) { if (this->season == m.season) {return true;

В этом классе перегружена операция присвоения, и тем самым становится возможным получение мгновенных снимков потока Koenigsberg. Определенная по умолчанию операция присвоения не совпадает по сигнатуре с перегруженной операцией присвоения, и потому объекты IKoenigsberg могут быть копированы. Перегруженная операция равенства позволит сравнивать экземпляры класса IKoenigsberg друг с другом.

Теперь можно определить процедуру измерения контекстного или «космического»

времени. В методе Execute класса Setting зададим две локальные переменные типа IKoenigsberg, и на каждой итерации цикла потока будем записывать туда текущее и предшествующее состояние объекта Koenigsberg. Если сравнение покажет, что оба объекта класса IKoenigsberg не равны друг другу, будем увеличивать переменную iTime на единицу. На множестве целых чисел задано отношение порядка, поэтому iTime может отражать «упорядоченную эволюцию материального объекта», что, и объясняет выбор этой переменной в качестве «количественной меры».

Время системы Koenigsberg должно измеряться так же, как происходит синхронизация системы с атомарными объектами. Наблюдаемая переменная – это переменная day. Для этого случая также может быть использован класс IKoenigsberg, который объявлен в классе Koenigsberg как дружественный. Тем самым появляется возможность копировать и внутренние поля объектов класса Koenigsberg. Время атомарных объектов имеет смысл только как результат коммуникаций. Поэтому оно совпадает с показаниями часов жителей города. Во всех трех случаях применяются разные измерительные процедуры, что позволяет говорить о разновидностях времени. Повидимому, можно также говорить о мировом времени (время мира модели), понимая под этим синхронизированную иерархию всех трех разновидностей времени (год – сутки – час), или, точнее, как о результате применения комбинированной процедуры измерения.

Заметим, что единое время мира модели не то же самое, что абсолютное время Ньютона.

Вернемся к нашему примеру. Дать краткое объяснение теории пространства и времени Канта затруднительно, поскольку многие аспекты теории неясны. По Канту время – априорная форма восприятия Мира, данная человеку с момента рождения (см.

«Критика чистого разума»). Кант исходил из того, что наши ощущения имеют причины, которые он называет «вещами в себе». Восприятие состоит из двух частей: то, что обусловлено объектом, эту часть он называет ощущением, и то, что обусловлено нашим врожденным субъективным аппаратом. Эту последнюю часть он называет формой явления. Эта часть априорна в том смысле, что не зависит от опыта. Существуют две такие формы: пространство (для упорядочивания внешних ощущений) и время (для упорядочивания внутренних ощущений). Для моделирования философа создадим класс Philosopher, потомок класса Townsman. В этом классе метод Update замещен. Метод отличается тем, что содержит алгоритм (форма восприятия, данная человеку с момента рождения) последовательной записи событий обновления. Получается, что этот алгоритм и есть время по Канту. Точно так же ментальная карта местности, по которой совершает прогулки философ, есть пространство по Канту. В принципе, такое понимание времени согласуется с данным выше определением времени.

Итак, выше предложена методика объектно-темпоральной декомпозиции систем, в основе которой лежит одна из разновидностей логики изменения. Закончим на этом рассматрение архитектурного пакета «World» и обратимся к еще одному архитектурному пакету.

Архитектурный пакет «Ontology Entity». Определение классов этого пакета, возможно, наиболее трудоемкая часть рабочего потока Анализ. С точки зрения вычислительной семантики этот пакет определяет классы имитационной модели, пригодные для повторного использования в линейке имитационных моделей. Предметная семантика этого пакета значительно сложнее. Этот пакет описывает теорию изучаемого объекта и содержит классификацию, в которую входит моделируемая система;

представлен сущностями, помечаемыми стереотипами «Substance», «Taxonomy», «Meronomy», «Categorization», «Ontology Category» и «Ontology Space». В простых случаях достаточно определить только два класса («Substance» и «Ontology Space»), причем переменные состояния системы («Ontology Space») часто допустимо моделировать базовыми типами используемого языка программирования (int, bool, char и т.п.).

Для обоснования предметной семантики обратимся к теории классификации, основанной на принципе двойственности таксономии и мерономии. Этот подход развит в работах С.В. Мейена и Ю.А. Шрейдера и в наиболее законченном виде изложен в книге [59]. Морфизм – это некоторый способ сравнения объектов. Таксономия – группировка объектов по сходству. Таксон – это множество видов (но не объектов классификации). На множестве таксонов заданы два отношения – отношение включения и отношение пересечения. Таксономическая структура может быть иерархической и фасетной или же комбинированной. Мерономия – это сравнение объектов классификации по их строению.

Мерон – это часть архетипа. Архетип – это план строения всех объектов таксона;

некоторая конструкция из меронов. Архетип – это не структура. В физических системах архетип – это фазовое пространство системы. Математическую основу теории Мейена– Шрейдера составляет теория категорий. Множество таксонов является категорией C, где объекты категории – таксоны T, а морфизмы – отображения вложения таксонов.

Архетипы также образуют категорию R, где в качестве морфизмов выступают гомоморфизмы. Классификация – это функтор :CR из категории таксонов в категорию архетипов (функтор каждому таксону сопоставляет определенный архетип).

Определение стереотипов. Опираясь на эту теорию, введем стереотипы «Taxonomy», «Meronomy», «Categorization» (функтор), «Ontology Category» (таксон) и «Ontology Space» (мерон) (см. ПРИЛОЖЕНИЕ III). При таком выборе стереотипов отношение обобщения между классами «Ontology Category» можно рассматривать как метафору отношения включения между таксонами, а множественное наследование – как отношение пересечения. Таксономические структуры и архетипы не входит в метамодель UML SP, они создаются в процессе разработки модели. Пользовательские типы (классы «Ontology Space») определяют поля классов «Ontology Category»; либо непосредственно, либо в составе структур данных. Отношение зависимости «Categorization» пакета «Taxonomy» от пакета «Meronomy» отражает то, что внутренние переменные классов «Ontology Category» имеют типы «Ontology Space».

Под пространством будем понимать объект со стереотипом Ontology Space;

предметная семантика определяется как объект для размещения других объектов, образующих структуру системы. Определяющий признак пространства – два и более объекта не могут быть в одной и той же ячейке пространства. Поэтому пространство процесса – вся совокупность переменных, доступных процессу. Вычислительная семантика «Ontology Space» близка к понятию «структура данных».

Применение стереотипов. Теория классификации Мейена–Шрейдера позволяет не только определить стереотипы категории «классификация», но и предоставляет некоторые методы для построения «Research Analysis Model».

Рассмотрим сначала гносеологический раздел модели анализа. В имитационных моделях операциональные процедуры (сравнение, счет, измерение и т.д.) рассматриваются как процессы коммуникации между исследовательской установкой и объектом исследования. Из теории Мейена-Шрейдера следует, что необходимо определять процедуры определения признаков, процедуру принадлежности к таксону, процедуру определения архетипа, процедуру сравнения архетипов, процедуру функтора (по заданному таксону выводит архетип), процедуру принадлежности к классификации.

Для определения операциональных процедур хорошо подходят паттерны Iterator, Observer и Template Method.

Вернемся к онтологическому разделу модели анализа. Один из методов выделения классов анализа в UP – использование паттернов. Для выделения классов категории «классификация» предлагается использовать паттерн Bridge (см. [9]). Программная конструкция использует два класса – класс-манипулятор (Abstraction) и класс-тело (Implementor), причем класс-манипулятор имеет поле, в котором хранится указатель на класс-тело. Интерфейс (класс-манипулятор) определяет внешние признаки классифицируемых объектов, а реализация – их строение. По определению, паттерн Bridge отделяет абстракцию от реализации и минимизирует связность пакетов «Taxonomy» и «Meronomy». В ассоциации классов, прежде всего, необходимо найти класс, который может играть роль Abstraction. Этот класс должен быть абстрактным и объявлять интерфейс. Кроме того, класс должен иметь поле, которое содержит указатель на абстрактный класс, играющий роль Implementor. После чего классы раскладываются по пакетам «Taxonomy» и «Meronomy». Природа, конечно, не обязана быть устроена так, как этого требует паттерн Bridge. Поэтому данный метод следует рассматривать как один из возможных подходов к выделению классов.

Проиллюстрируем сказанное на следующем примере.

Автобусный рейс. Наиболее распространенная система классификации – иерархическая. Пусть необходимо построить имитационную модель автобусного рейса с автовокзала некоторого города. Расписание движения автобусов составляет классификационную систему для данной задачи. Мы допустим, что с данного автовокзала выполняются рейсы по одному междугороднему маршруту и двум пригородным маршрутам. Диаграмма классов для имитационной модели приведена на рис. 9.

Конкретный рейс моделируется экземплярами класса STripA1, который выполняется по маршруту SuburbanRouteA. Этому классу назначен концепт «Рейс A1».

Метод Exist задает единицу дискретно-событийного времени; моделирует посадку/высадку пассажиров в данном населенном пункте (операция Update) и перемещение объекта класса Bus в следующий населенный пункт. Маршрут моделируется динамическим списком из экземпляров подклассов класса Place. Классы BusStopStation и BusStation различаются операцией UpdateImp – в первом случае обновляется только часть пассажиров, во-втором – все.

«Environment»

+ Exist Допустим, что диаграмма классов не размечена стереотипами. Воспользуемся описанным выше методом определения классов анализа. На роль Abstraction подходит класс Route, тогда класс Place будет играть роль Implementor (см. рис. 9). Предполагая типовую двухслойную архитектуру, разложим классы по основным пакетам модели анализа. Классы TransportNetwork, Bus и STripA1 поместим в пакет «World», остальные классы разместим в пакете «Ontology Entity» так как показано на рис. 10. Заметим, что на рис. 10 нет необходимости указывать стереотипы классов, поскольку пакеты как раз и группируют классы по категориям. Мы приводим стереотипы для большей наглядности.

После того, как выполнено разделение классов по пакетам, становится возможным определение их стереотипов (см. рис. 9). Из рис. 10 видно, что классификация зависит от выбора классов пакета «Meronomy», т.е. от способа определения функтора. Например, в нашем случае в качестве альтернативной мерономии можно было бы в качестве меронов выбрать дороги, через которые проходит маршрут. Таксономия не изменилась бы, но классификация была бы уже другая.

Для моделирования пересечения таксонов используется множественное наследование. Классический пример фасетной системы классификации – периодическая система химических элементов Д.И. Менделеева. Этот пример рассмотрен в работе [21];

см. сайт [40], где приведена объектная модель атомов химических элементов. В работе рассмотрена «чисто» фасетная система, т.е. рассмотрен упрощенный вариант модели. В общем случае надо рассмотреть все периоды, поскольку периодическая система Д.И.

приведенная модель учитывает квантовые эффекты.

«Ontology Entity»

Bus schedule «Taxonomy»

Routes list Как видно из рис. 10 классификация не исчерпывает всех сущностей пакета «Ontology Entity», хотя и составляет большую часть его наполнения. Это в первую очередь относится к классам, помеченным стереотипом Substance. С точки зрения вычислительной семантики, подобные классы – это абстрактные классы архитектурного паттерна. C точки зрения предметной семантики, концепт этого стереотипа может быть определен посредством такого математического понятия, как каркас [59], а также близкого понятия «системы, нарисованные на системах» В.А. Лефевра [37]. Каркас K = M,, 2, – это кортеж, содержащий модель M,, сигнатуру 2 и аксиоматику. Применяется для определения моделей с отношениями из сигнатуры 2 удовлетворяющих аксиомам.

Каркас можно понимать как модель, которая определена только частично, или как каркас модели. Авторы [59], говоря о моделях, представленных посредством каркаса, используют метафоры «ткань» и «рисунок» для модели M, и для отношений из сигнатуры соответственно. В вырожденном случае класс «Substance» должен объявлять, по крайней мере, один метод «Exist», так как бессмысленно рассматривать объекты, которые не могут существовать. Классы «Substance» могут образовывать иерархию наследования, что моделируется вложенными пакетами.

Закончим на этом рассмотрения «Research Analysis Model» и обратимся к последней модели UML SP.

«Research Design Model» определяет правила (способ) описания модели на конкретном языке программирования и позволяет отделить элементы имитационной модели от ограничений, налагаемых синтаксисом этих языков. В данной работе всюду предполагается использование C++ (за редким исключением, когда приходится обращаться к Smalltalk), что, конечно же, не исключает и другие языки программирования, включая специализированные языки GPSS World, AnyLogic и др.

Особенностью потока работ по созданию модели дизайна в Scientific Profile является представление параллельных процессов, определенных в модели анализа, в виде последовательных операций, пригодных для описания на выбранном языке программирования. Затем вычислительный алгоритм должен быть исследован на точность и устойчивость. Модель дизайна создается в рабочем потоке Проектирование.

Подчеркнем, сущности, вводимые в «Research Design Model», никакого «физического»

смысла не имеют, и им нельзя назначать концепты; в Domain-Driven Design такие классы называются синтетическими.

Остановимся подробнее на вопросе перехода к квазипараллельному процессу.

Ясно, что между обоими процессами должна иметь место некая эквивалентность.

Открытым остается вопрос: что следует понимать под эквивалентностью в данном случае?

Рис. 11. Диаграмма классов для модели перемещения объектов В качестве модельной задачи рассмотрим симуляцию перемещения объекта по ячейкам пространства. Ячейки являются экземплярами класса SCell, который имеет поле prestoredObject (указатель на хранимый объект), два свойства left и right и метод exist.

Допустим, что объект может перемещаться только в одну сторону, например, вправо.

Метод put с параметром aCertainObject передает указатель на хранимый объект одной (правой, в нашем случае) из смежных ячеек. Пространство будем моделировать динамическим списком, который образует кольцо. Диаграмма классов для этой модели показана на рис. 11.

В начальном состоянии объект aCertainObject находится в первой ячейке пространства. Всякий раз, когда Исследователь посылает сообщение exist, объект aCertainObject перемещается в правую ячейку.

Рис. 12. Диаграмма кооперации для модели перемещения объектов На каждом шаге дискретно-событийного времени (процессы метода exist) объекты обмениваются сообщениями так, как это показано на рис. 12. Заметим, что это существенно параллельная модель. Все процессы, инкапсулированные в объектах классов Transporter, SCell и CertainObject, считаются параллельными (см. ПРИЛОЖЕНИЕ II).

Основные модели параллельного программирования:

(Process/Channel), Обмен сообщениями (Message Passing), Параллелизм данных (Data Parallel), Общая память (Shared Memory). В нашем примере синхронизация может выполняться любым из этих способов. Например, Процесс/канал реализуется тем, что для метода put выделяется специальное поле, которое исполняет роль буфера ввода, и на следующем такте дискретно-событийного времени переписывается в поле prestoredObject.

Механизм общей памяти может быть реализован посредством семафоров. Чаще других в имитационном моделировании используется механизм обмена сообщениями. Рассмотрим его подробнее.

Диаграмма деятельности показана на рис. 13. Процесс processing (обработать) выполняется тогда, когда ячейка находится в состояние full, а skip – в состояние empty (prestoredObject = NULL). Если ячейка full, то процесс начинается, определяет свое состояние как full, обрабатывает объект aCertainObject, передает указатель в смежную ячейку (сообщение с селектором put) и очищает поле prestoredObject:= NULL Если ячейка в состояние empty, то выполняется некоторое действие skip, выполняется прием сообщения из смежной ячейки, после чего полю prestoredObject будет присвоено значение сообщения (это может быть NULL).

Обратная задача распараллеливания, может быть решена одним из двух способов:

опираясь на концепцию событийно-ориентированного или процессно-ориентированного моделирования. Введем фиктивное свойство isEnabled для класса CertainObject, которое может принимать значение true или false. В методе exist контекста последовательно проверим все ячейки по свойству isEmpty; если ячейка не пустая, установим свойство isEnabled = true. Затем повторно обойдем все ячейки. Если ячейка не пустая и isEnabled = true, то обработаем объект aCertainObject и установим isEnabled = false, затем передадим объект в смежную ячейку. Иначе – пропускаем ячейку. В противном случае aCertainObject будет перемещаться по ячейкам пространства мгновенно.

Рис.13. Диаграмма деятельности для активности пространственной ячейки Можно допустить, что между композицией параллельных процессов «Research Analysis Model» и квазипараллельным процессом «Research Design Model» имеет место отношение наблюдаемой конгруэнции относительно операций процессной алгебры CCS (см. [17]). Конгруэнция означает то, что всякое допустимое преобразование одного процесса может быть выполнено и для другого; верно и обратное [67], [39]. Тем самым становится возможным изучение процесса «Research Analysis Model», работая с процессом «Research Design Model».

Итак, для обоснования подбора стереотипов UML SP мы использовали следующие научные концепции и теории: концепцию «трех миров» К. Поппера, концепцию «четырех миров» К. Колина, концепцию целостности и метод декомпозиции системного анализа, логику изменения, теорию классификации Мейена–Шрейдера. Эти теории и концепции не входят в метамодель UML SP, но составляют основу методологии MSP.

О языках программирования. Все современные объектно-ориентированные языки пригодны для создания имитационных моделей, в т.ч. такие популярные, как C++, Object Pascal (Delphi) и Java. В данной монографии практически всюду используется объектно-ориентированный язык C++. Этот язык склонен к сильной типизации, однако позволяет обойти порождаемые типизацией ограничения путем работы с указателями (как, впрочем, и в других языках). Не типизируемые языки, на наш взгляд, более выразительны с точки зрения имитационного моделирования. С другой стороны, типизация полезна и в имитационном моделировании, поскольку позволяет явно проследить таксономию пакета «Ontology Entity».

Именно в языке динамического программирования Smalltalk коммуникационная парадигма имитационного моделирования выражена лучше всего. Поэтому мы приведем краткое описание этого языка, тем более что в дальнейшем изложении будут встречаться некоторые понятия и термины, характерные для него. Некоторые темы рассматриваются в предположение, что реализация выполнена на Smalltalk.

Smalltalk был создан группой исследователей возглавляемой Аланом Кэйем в исследовательском центре Xerox PARC в 1970-х годах. В 1983 году была выпущена общедоступная реализация, известная как Smalltalk-80 Version 2 в виде образа (независимый от платформы файл, содержащий объекты) и спецификации виртуальной машины. Основная заслуга в реализации проекта принадлежит Ингалсу. Сейчас существует две реализации Smalltalk, являющиеся прямыми потомками Smalltalk-80 – Squeak и VisualWorks. Образ Smalltalk-80 version 2 запущен на Hobbes, виртуальной машине ST-80, реализованной на VisualWorks. Заметим, что VisualWorks – это программный продукт со свободной лицензией; его можно установить с сайта http://www.cincomsmalltalk.com/main/.

В языке есть всего три конструкции (см. http://ru.wikipedia.org/wiki/Smalltalk):

присваивание объекта переменной, и несколько синтаксических конструкций для определения объектов-литералов и временных переменных.

Основными идеями Smalltalk являются:

Всё – объекты. Строки, целые числа, логические значения, классы, блоки кода, память – всё представляется в виде объектов. Можно сделать программу, которая работает с классами как с объектами, например, генерирует код класса, а затем загружает его. Выполнение программы состоит из посылок сообщений между объектами. Любое сообщение может быть послано любому объекту; объект-получатель определяет, является ли это сообщение правильным, и что надо сделать, чтобы его обработать.

Динамическая типизация – это означает, что вы не указываете типы переменных в программе, а присваиваете переменным указатели на объекты. Тем самым одна и та же переменная может изменять свой тип в процессе выполнения программы. В языке C++ работа с указателями – альтернатива; в Smalltalk – это основная идея. Если сообщение не может быть обработано, то объект возвращает стандартное сообщение “Do not understand” и выполнение программы продолжается.

Мы часто ссылаемся на паттерны проектирования, изложенные в книге [14]. Для Smalltalk не все паттерны есть в указанном источнике, более полное изложение можно найти в [64].

Как показал опыт построения объектных моделей в ряде случаев одну и ту же модель имеет смысл построить на двух языках программирования. Желательно, чтобы один язык был типизируемым, а другой – не типизируемым. Это позволит избежать многих ловушек неадекватного моделирования, обусловленных особенностями конкретных языков.

Примеры и пояснения 1. Коммуникативный акт Как уже было сказано ранее, в монографии мы придерживаемся коммуникационной парадигмы имитационного моделирования. Поэтому нелишне напомнить основные модели коммуникативного акта [51], [29].

Модель К. Шеннона и У. Уивера. Одна из первых моделей коммуникации, предложена американскими учеными Клодом Шенноном и Уорреном Уивером (Warren Weaver) в конце 40-х годов.

Модель включает пять элементов: источник информации, передатчик, канал передачи, приемник и цель (место назначения), расположенные в линейной последовательности (линейная модель). В дальнейшем стало ясно, что в иных областях этой модели недостаточно. Другая модель включает шесть компонентов: источник, кодирующее устройство, сообщение, канал, декодирующее устройство и приемник («телефонная» модель). Помимо этого, Шеннон ввел такие понятия как количество информации, шум и избыточность.

В имитационном моделировании обеих моделей может оказаться недостаточно. В ряде случаев приходится прибегать к более сложным моделям, таким, как модель Якобсона.

Функциональная модель Р.О. Якобсона. В модели коммуникации или речевого события, по Якобсону, участвуют адресант и адресат, от первого ко второму направляется сообщение, которое написано с помощью кода. Контекст в модели Якобсона связан с содержанием сообщения, с информацией, им передаваемой, понятие контакта связано с регулятивным аспектом коммуникации. Оппозиция адресанта и адресата приводит к пониманию различения «лингвистики говорящего» и «лингвистики слушающего». Языковая реальность отправителя сообщения во многом не похожа на языковую реальность получателя сообщения.

Pages: |

| 2 | 3 |

Главная >> Монографии

[ СКАЧАТЬ ОРИГИНАЛ ДОКУМЕНТА .pdf ]

Похожие работы:

«К.В. Давыдов АДМИНИСТРАТИВНЫЕ РЕГЛАМЕНТЫ ФЕДЕРАЛЬНЫХ ОРГАНОВ ИСПОЛНИТЕЛЬНОЙ ВЛАСТИ РОССИЙСКОЙ ФЕДЕРАЦИИ: ВОПРОСЫ ТЕОРИИ Монография nota bene ББК 67 Д 13 Научный редактор: Ю.Н. Старилов доктор юридических наук, профессор, заслуженный деятель науки Российской Федерации, заведующий кафедрой административного и муниципального права Воронежского государственного университета. Рецензенты: Б.В. Россинский доктор юридических наук, профессор, заслуженный юрист Российской Федерации, действительный член...»

«ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ РОССИЙСКОЙ ФЕДЕРАЦИИ МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ЭКОНОМИКИ, СТАТИСТИКИ И ИНФОРМАТИКИ (МЭСИ) КАФЕДРА СОЦИАЛЬНО-ЭКОНОМИЧЕСКОЙ СТАТИСТИКИ Смелов П.А. Карманов М.В., Дударев В.Б., Зареченский А.М. МЕТОДОЛОГИЯ ЭКОНОМИКО-СТАТИСТИЧЕСКОГО ИССЛЕДОВАНИЯ ДЕМОГРАФИЧЕСКОЙ БЕЗОПАСНОСТИ И ЗДОРОВЬЯ ОБЩЕСТВА Коллективная монография Москва, 2009 г. УДК – 314.4, 314.8 Смелов П.А. Карманов М.В., Дударев В.Б., Зареченский А.М. Методология экономико-статистического...»

«Министерство образования и науки Российской Федерации Дальневосточный федеральный университет А.М. Кузнецов, И.Н. Золотухин Этнополитическая история Азиатско-Тихоокеанского региона в ХХ – начале ХХI вв. Владивосток Издательство Дальневосточного федерального университета 2011 1 http://www.ojkum.ru/ УДК 323.1 ББК 66.5(0) К 89 Работа выполнена в рамках Аналитической ведомственной целевой программы Развитие научного потенциала Высшей школы Рецензенты: М.А. Фадеичева, доктор политических наук,...»

«О. В. Лаврова Глубинная топологическая психотерапия: идеи о трансформации Введение в философскую психологию Издательство ДНК Санкт-Петербург 2001 УДК 159.962-159.964 ББК88 Л13 Лаврова О.В. Глубинная топологическая психотерапия: идеи о трансформации. Введение в философскую психологию: Монография (Серия Новые идеи в психологии). — СПб.: Издательство ДНК, 2001. — 424 с. ISBN 5-901562-06-2 Монография представляет собой теоретико-методологическую разработку интегративной немедицинской модели...»

«А.Ф. Меняев КАТЕГОРИИ ДИДАКТИКИ Научная монография для спецкурса по педагогике в системе дистанционного обучения студентов педагогических специальностей Второе издание, исправленное и дополненное. Москва 2010 ББК УДК МРецензенты: Заслуженный деятель науки РФ, доктор педагогических наук, профессор Новожилов Э.Д. Доктор педагогических наук, профессор Деулина Л.Д. Меняев А.Ф. Категории дидактики. Научная монография для спецкурса по педагогике в системе дистанционного обучения для студентов...»

«ФЕДЕРАЛЬНАЯ СЛУЖБА ИСПОЛНЕНИЯ НАКАЗАНИЙ ФЕДЕРАЛЬНОЕ КАЗЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ ВОРОНЕЖСКИЙ ИНСТИТУТ ФСИН РОССИИ П. Б. Стукалов ПОЛИТИЧЕСКИЕ И ПРАВОВЫЕ УЧЕНИЯ В РОССИИ ВО ВТОРОЙ ПОЛОВИНЕ XIX – НАЧАЛЕ XX ВЕКА: ВСЕРОССИЙСКИЙ НАЦИОНАЛЬНЫЙ СОЮЗ И ЕГО ИДЕОЛОГИ ВОРОНЕЖ 2011 1 УДК 94(47) ББК 63.3(2) С88 Н а у ч н ы й р е да к тор доктор исторических наук Л. М. Искра Ре ц е н з е н ты : кандидат исторических наук А. Ю. Минаков доктор политических наук Н. П....»

«Ю.Н. ВОДЯНИЦКИЙ ТЯЖЕЛЫЕ И СВЕРХТЯЖЕЛЫЕ МЕТАЛЛЫ И МЕТАЛЛОИДЫ В ЗАГРЯЗНЕННЫХ ПОЧВАХ Москва 2009 РОССИЙСКАЯ АКАДЕМИЯ СЕЛЬСКОХОЗЯЙСТВЕННЫХ НАУК ПОЧВЕННЫЙ ИНСТИТУТ имени В.В. ДОКУЧАЕВА Ю.Н. ВОДЯНИЦКИЙ ТЯЖЕЛЫЕ И СВЕРХТЯЖЕЛЫЕ МЕТАЛЛЫ И МЕТАЛЛОИДЫ В ЗАГРЯЗНЕННЫХ ПОЧВАХ Москва 2009 1 ББК 40.3 В62 УДК 631.41 Рецензент доктор биологических наук Д.Л.Пинский. Ю.Н. Водяницкий В62. Тяжелые и сверхтяжелые металлы и металлоиды в загрязненных почвах. – М.: ГНУ Почвенный институт им. В.В. Докучаева...»

«ГЕОДИНАМИКА ЗОЛОТОРУДНЫХ РАЙОНОВ ЮГА ВОСТОЧНОЙ СИБИРИ Федеральное агентство по образованию ГОУ ВПО Иркутский государственный университет Геологический факультет А. Т. Корольков ГЕОДИНАМИКА ЗОЛОТОРУДНЫХ РАЙОНОВ ЮГА ВОСТОЧНОЙ СИБИРИ 1 А. Т. КОРОЛЬКОВ УДК 553.411 : 551.2(571.5) ББК 26.325.1 : 26.2(2Р54) Печатается по решению научно-методического совета геологического факультета Иркутского государственного университета Монография подготовлена при поддержке аналитической ведомственной целевой...»

«Т. Г. Елизарова КВАЗИГАЗОДИНАМИЧЕСКИЕ УРАВНЕНИЯ И МЕТОДЫ РАСЧЕТА ВЯЗКИХ ТЕЧЕНИЙ Москва Научный Мир 2007 УДК 519.633:533.5 Т. Г. Елизарова. Квазигазодинамические уравнения и методы расчета вязких течений. Лекции по математическим моделям и численным методам в динамике газа и жидкости. М.: Научный Мир, 2007. – 350 с. Монография посвящена современным математическим моделям и основанным на них численным методам решения задач динамики газа и жидкости. Приведены две взаимосвязанные математические...»

«1 РОССИЙСКАЯ АКАДЕМИЯ НАУК RUSSIAN ACADEMY OF SCIENCES ДАЛЬНЕВОСТОЧНОЕ ОТДЕЛЕНИЕ FAR EASTERN BRANCH Институт экономических исследований Economic Research Institute Б.Л. КОРСУНСКИЙ С.Н. ЛЕОНОВ ДЕПРЕССИВНЫЙ РАЙОН В ПЕРЕХОДНОЙ ЭКОНОМИКЕ B.L. KORSUNSKIY S.N. LEONOV DEPRESSED AREAS IN TRANSITIONAL ECONOMY Vladivostok * Владивосток Dalnauka * Дальнаука УДК 338.26 (47+57) Корсунский Б.Л., Леонов С.Н. Депрессивный район в переходной экономике. Владивосток: Дальнаука. 1999. 155 с. ISBN 5-7442-0916-6. В...»

«Министерство образования Республики Беларусь УЧРЕЖДЕНИЕ ОБРАЗОВАНИЯ ГРОДНЕНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ИМЕНИ ЯНКИ КУПАЛЫ А.Н.НЕЧУХРИН ТЕОРЕТИКО-МЕТОДОЛОГИЧЕСКИЕ ОСНОВЫ РОССИЙСКОЙ ПОЗИТИВИСТСКОЙ ИСТОРИОГРАФИИ (80-е гг. ХIХ в. – 1917 г.) Монография Гродно 2003 УДК 94 ББК 63.3 Н59 Рецензенты: профессор, доктор философских наук У.Д.Розенфельд; доктор политических наук, доцент В.Н.Ватыль. Рекомендовано советом исторического факультета ГрГУ им. Я.Купалы. Нечухрин А.Н. Теоретико-методологические...»

«ФЕДЕРАЛЬНОЕ АГЕНТСТВО ЖЕЛЕЗНОДОРОЖНОГО ТРАНСПОРТА ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ ИРКУТСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ПУТЕЙ СООБЩЕНИЯ А.В. Крюков, В.П. Закарюкин, Н.А. Абрамов СИТУАЦИОННОЕ УПРАВЛЕНИЕ РЕЖИМАМИ СИСТЕМ ТЯГОВОГО ЭЛЕКТРОСНАБЖЕНИЯ Иркутск 2010 УДК 621.311 ББК К 85 Представлено к изданию Иркутским государственным университетом путей сообщения Рецензенты: доктор технических наук, проф. В.Д. Бардушко доктор технических наук, проф. Г.Г....»

«ИНСТИТУТ МИРОВОЙ ЭКОНОМИКИ И МЕЖДУНАРОДНЫХ ОТНОШЕНИЙ РОССИЙСКОЙ АКАДЕМИИ НАУК П.А. Гудев КОНВЕНЦИЯ ООН ПО МОРСКОМУ ПРАВУ: ПРОБЛЕМЫ ТРАНСФОРМАЦИИ РЕЖИМА Москва ИМЭМО РАН 2014 УДК 347.79 ББК 67.404.2 Кон 64 Серия “Библиотека Института мировой экономики и международных отношений” основана в 2009 году Рецензенты: А.Н. Вылегжанин, доктор юридических наук, профессор; заведующий кафедрой международного права МГИМО(У) МИД РФ, вице-президент Российской Ассоциации морского права, заслуженный юрист...»

«Межрегиональные исследования в общественных науках Министерство образования и науки Российской Федерации ИНО-центр (Информация. Наука. Образование) Институт имени Кеннана Центра Вудро Вильсона (США) Корпорация Карнеги в Нью-Йорке (США) Фонд Джона Д. и Кэтрин Т. Мак-Артуров (США) Данное издание осуществлено в рамках программы Межрегиональные исследования в общественных науках, реализуемой совместно Министерством образования и науки РФ, ИНО-центром (Информация. Наука. Образование) и Институтом...»

«Федеральное агентство по образованию Российской Федерации Государственное образовательное учреждение высшего профессионального образования Алтайский государственный университет Экономический факультет Кафедра бухгалтерского учета, аудита и анализа АУДИТ Издательство Алтайского государственного университета Барнаул 2006 ББК 65.053. р30 УДК 657.6 (078) Составитель: к.э.н., доцент Н.В. Пислегина Рецензент: к.э.н., доцент Ю. А. Радцева В методических указаниях приведены общие положения по написанию...»

«ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ УЧЕБНО-МЕТОДИЧЕСКИЙ ЦЕНТР ПО ОБРАЗОВАНИЮ НА ЖЕЛЕЗНОДОРОЖНОМ ТРАНСПОРТЕ ФИЛИАЛ ФЕДЕРАЛЬНОГО ГОСУДАРСТВЕННОГО БЮДЖЕТНОГО ОБРАЗОВАТЕЛЬНОГО УЧРЕЖДЕНИЯ “УЧЕБНО-МЕТОДИЧЕСКИЙ ЦЕНТР ПО ОБРАЗОВАНИЮ НА ЖЕЛЕЗНОДОРОЖНОМ ТРАНСПОРТЕ” в г. Новосибирске Уважаемые коллеги и партнеры! Профессорско-преподавательскому составу, студентам, постоянным покупателям предоставляются скидки на учебные издания в зависимости от количества приобретаемой продукции и года...»

«С. В. Сигова Восполнение кадрового дефицита на рынке труда Российской Федерации ББК 65.24 УДК 331 С34 Рецензенты: Рудаков М. Н., доктор экономических наук, профессор ПетрГУ Дружинин П. В., доктор экономических наук, заведующий отделом Института экономики КарНЦ РАН Сигова С. В. Восполнение кадрового дефицита на рынке труда Российской ФедераС34 ции / С. В. Сигова. – Петрозаводск: Изд-во ПетрГУ, 2009. – 188 с. ISBN 978-5-8021-1048-5 Монография посвящена вопросам совершенствования государственного...»

«Министерство образования Республики Беларусь Учреждение образования Витебский государственный университет имени П.М. Машерова БИОЛОГИЧЕСКОЕ РАЗНООБРАЗИЕ БЕЛОРУССКОГО ПООЗЕРЬЯ Монография Под редакцией Л.М. Мержвинского Витебск УО ВГУ им. П.М. Машерова 2011 УДК 502.211(476) ББК 20.18(4Беи) Б63 Печатается по решению научно-методического совета учреждения образования Витебский государственный университет имени П.М. Машерова. Протокол № 6 от 24.10.2011 г. Одобрено научно-техническим советом...»

«БЕЗОПАСНОСТЬ СОЦИАЛЬНОЙ СФЕРЫ В УСЛОВИЯХ СОВРЕМЕННОЙ ПОЛИКУЛЬТУРНОЙ РОССИИ Челябинск 2013 МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ ЧЕЛЯБИНСКИЙ ГОСУДАРСТВЕННЫЙ ПЕДАГОГИЧЕСКИЙ УНИВЕРСИТЕТ БЕЗОПАСНОСТЬ СОЦИАЛЬНОЙ СФЕРЫ В УСЛОВИЯХ СОВРЕМЕННОЙ ПОЛИКУЛЬТУРНОЙ РОССИИ КОЛЛЕКТИВНАЯ МОНОГРАФИЯ Челябинск 2013 УДК 371:34 ББК 74.04(2):67.4 Б Безопасность социальной сферы в условиях современной...»

«Электронное научное издание Альманах Пространство и Время. Т. 3. Вып. 2 • 2013 Electronic Scientific Edition Almanac Space and Time Elektronische wissenschaftliche Auflage Almabtrieb ‘Raum und Zeit‘ Теории, концепции, парадигмы Theories, Conceptions, Paradigms / Theorien, Konzeptionen, Paradigmen УДК 16:008 Сорина Г.В. Методология логико-культурной доминанты: психологизм, антипсихологизм, субъект Сорина Галина Вениаминовна, доктор философских наук, профессор философского факультета МГУ имени...»

наверх

<< ГЛАВНАЯ | КОНТАКТЫ

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА
(Авторефераты, диссертации, методички, учебные программы, монографии)

ИМИТАЦИОННОЕ МОДЕЛИРОВАНИЕ НА UML SP

ОГЛАВЛЕНИЕ

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА (Авторефераты, диссертации, методички, учебные программы, монографии)

ИМИТАЦИОННОЕ МОДЕЛИРОВАНИЕ НА UML SP

ОГЛАВЛЕНИЕ

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА
(Авторефераты, диссертации, методички, учебные программы, монографии)