С чего начинается построение модели
Основные этапы построения модели.
В качестве основных этапов моделирования можно выделить следующие:
1. Постановка задачи моделирования;
2. Изучение моделируемой системы;
3. Выбор метода решения задачи;
4. Подготовка к решению задач;
5. Решение задачи моделирования;
6. Анализ полученной информации.
Постановка задачи. Определяется (объект) система, для которой необходимо разработать модель и формулируется цель моделирования. На этом этапе важно понять, для решения какой задачи создается математическая модель. Здесь нужно помнить приводимое в работе [24] высказывание: «Прежде чем решать задачу, подумай, что делать с ее решением».
Изучение системы. Сущность этапа заключается в составлении содержательного и формализованного описаний. В зависимости от того, предполагается ли моделировать технологический процесс или производственную систему, проводят разные работы:
· Если моделировать технологический процесс, то необходимо изучить его теоретические основы и составить уравнения математической модели. При составлении уравнений используют уравнения материального и теплового баланса, сведения из физики, физической химии, теории процессов, теории размерностей, математической статистики, результаты натурных экспериментов и другие сведения.
· Если моделировать производственную систему, то приступают к ее изучению. Для этого осуществляют хронометраж ее работы.
· Составляют описание системы на обычном языке, и оно включает: функции агрегатов и механизмов (основных и вспомогательных); последовательности работ на каждом агрегате; сведения о случайных факторах (внутренних и внешних) и вероятностных характеристиках работ; ограничения, накладываемые на деятельность агрегатов; потоки (материальные, энергетические, информационные); буферные емкости; транспортные сети; управляющие воздействия; ресурсы и ограничения на ресурсы; стратегии управления; способы прогнозирования длительностей работ.
· Продумывают способы формализации системы. С этой целью систему или производственный процесс представляют, например, в виде «черного ящика», кусочно-линейного марковского процесса, потока жидкости, системы массового обслуживания.
Выбор метода решения задачи. Известны три метода решения модели: логический, аналитический и численный с применением средств вычислительной техники (компьютер).
Подготовка к решению.Подготовка к решению представляет собой дальнейшую работу по формализации системы:
· разрабатывается функциональная блок-схема модели;
· разрабатыается алгоритм, по которому ЭВМ осуществит расчеты и имитацию функционирования системы;
· составляется и отлаживается программа, реализующая алгоритм;
· разрабатываются базы данных входных и выходных переменных;
· разрабатывается визуализация и анимация функционирования модели.
· При предварительном моделировании проверяют адекватность модели, уточняют модель.
· При основном моделировании получают решение поставленной задачи.
Анализ полученной информации.На этом этапе, с одной стороны, анализируют результаты эксперимента с целью выработки рекомендаций по совершенствованию существующей системы, а, с другой стороны, изучают возможности постановки новых задач.
· нетождественного сходства свойств и отношений, которое существует между реальным объектом и моделью.
· Соответствия полученного решения фиксированным значениям основных параметров системы и начальных условий. Обычно при исследовании системы приходится многократно моделировать процесс ее функционирования, варьируя исходные данные задачи.
Дата добавления: 2015-10-05 ; просмотров: 9961 ; ЗАКАЗАТЬ НАПИСАНИЕ РАБОТЫ
Основные этапы компьютерного моделирования
Вы будете перенаправлены на Автор24
Каждый этап моделирования определяет поставленная задача и цели моделирования. В общем случае процесс построения и исследования модели может быть представлен с помощью схемы:
I этап. Постановка задачи
Включает в себя три стадии:
Задача описывается на обычном языке.
Все множество задач можно разделить по характеру постановки на 2 основные группы:
Первая группа содержит задачи, в которых требуется исследовать, как изменятся характеристики объекта при некотором воздействии на него, т.е. требуется получить ответ на вопрос «Что будет, если. ».
Например, что будет, если магнитную карточку положить на холодильник? Что будет, если повысить требования для поступления в вуз? Что будет, если резко повысить плату за коммунальные услуги? и т. п.
Вторая группа содержит задачи, в которых требуется определить, что нужно сделать с объектом, чтобы его параметры удовлетворили определенное заданное условие, т.е. требуется получить ответ на вопрос «Как сделать, чтобы. ».
Например, как построить урок математики, чтобы детям был понятен материал? Какой режим полета самолета выбрать, чтобы полет был безопаснее и экономически выгоднее? Как составить график выполнения работ на строительстве, чтобы оно было закончено максимально быстро?
Определение цели моделирования
На этой стадии среди многих характеристик (параметров) объекта выделяются наиболее существенные. Один и тот же объект при разных целях моделирования будет иметь разные существенные свойства.
Например, при построении модели яхты для участия в соревнованиях моделей судов, существенными будут ее судоходные характеристики. Для достижения поставленной цели построения модели будет отыскиваться ответ на вопрос «Как сделать, чтобы…?»
При построении модели яхты для совершения на ней путешествий, долгосрочных круизов, кроме судоходных характеристик существенным будет ее внутреннее строение: количество палуб, комфортабельность кают, наличие других удобств и т.д.
При построении компьютерной имитационной модели яхты для проверки надежности ее конструкции в штормовых условиях, моделью яхты будет представлять собой изменение изображения и расчетных параметров на экране монитора при изменении значений входных параметров. Будет решаться задача «Что будет, если…?»
Цель моделирования позволяет установить, какие данные будут исходными, чего нужно достичь в результате и какие свойства объекта можно не учитывать.
Таким образом происходит построение словесной модели задачи.
Подразумевается четкое выделение объекта, который моделируется, и его основных свойств.
II этап. Формализация задачи
Связан с созданием формализованной модели, т.е. модели, которая записана на каком-либо формальном языке. Например, показатели рождаемости, которые представлены в виде таблицы или диаграммы, являются формализованной моделью.
Под формализацией понимают приведение существенных свойств и признаков объекта моделирования к определенной форме.
Формальной моделью является модель, которая получена в результате формализации.
Для решения задач с помощью компьютера наиболее подходящим является математический язык. Формальная модель фиксирует связи между исходными данными и конечным результатом с помощью разных формул, а также наложения ограничений на допустимые значения параметров.
III этап. Разработка компьютерной модели
Начинается с выбора инструмента моделирования (программной среды), с помощью которого будет создаваться и исследоваться модель.
От выбора программной среды зависит алгоритм построения компьютерной модели и форма его представления.
Готовые работы на аналогичную тему
Например, в среде программирования формой представления является программа, которая написана на соответствующем языке. В прикладных средах (электронные таблицы, СУБД, графических редакторах и т.д.) формой представления алгоритма является последовательность технологических приемов, которые приводят к решению задачи.
Заметим, что одну и ту же задачу можно решить с помощью разных программных сред, выбор которой зависит, в первую очередь, от ее технических и материальных возможностей.
IV этап. Компьютерный эксперимент
Тестирование модели – проверка правильности построения модели.
На этой стадии выполняется проверка разработанного алгоритма построения модели и адекватности полученной модели объекту и цели моделирования.
Для проверки правильности алгоритма построения модели используются тестовые данные, для которых заранее известен конечный результат. Чаще всего тестовые данные определяются ручным способом. Если в ходе проверки результаты совпадают, значит разработан правильный алгоритм, а если нет – то нужно найти и устранить причину их несоответствия.
Тестирование должно отличаться целенаправленностью и систематизацией, усложнение же тестовых данных должно выполняться постепенно. Для определения правильности построения модели, которая отражает существенные для цели моделирования свойства оригинала, т.е. ее адекватности, необходим подбор таких тестовых данных, которые будут отражать реальную ситуацию.
К исследованию модели можно переходить только после успешного прохождения тестирования и уверенности в том, что создана именно та модель, которую необходимо исследовать.
V этап. Анализ результатов
Является основным для процесса моделирования. Решение о продолжении или завершении исследования принимается по итогам именно этого этапа.
В случае, когда результаты не соответствуют целям поставленной задачи, делают вывод о том, что на предыдущих этапах были допущены ошибки. Тогда необходимо выполнить коррекцию модели, т.е. вернуться к одному из предыдущих этапов. Процесс должен повторяться до тех пор, пока результаты компьютерного эксперимента не будут соответствовать целям моделирования.
Моделирование данных: зачем нужно и как реализовать
Моделирование данных ощутимо упрощает взаимодействие между разработчиками, аналитиками и маркетологами, как и сам процесс создания отчетов. Поэтому я перевела статью IBM Cloud Education о ценности моделирования и от себя добавила инфо о способах трансформации данных для моделирования.
Моделирование данных
Узнайте, как моделирование данных использует абстракцию для представления и лучшего понимания природы данных в информационной системе предприятия.
Что такое моделирование данных
Моделирование данных — это создание визуального представления о всей информационной системе либо ее части. Цель в том, чтобы проиллюстрировать типы данных, которые используются и хранятся в системе, отношения между этими типами данных, способы группировки и организации данных, их форматы и атрибуты.
Модели данных строятся на основе бизнес-потребностей. Правила и требования к модели данных определяются заранее на основе обратной связи с бизнесом, поэтому их можно включить в разработку новой системы или адаптировать к существующей.
Данные можно моделировать на различных уровнях абстракции. Процесс начинается со сбора бизнес-требований от заинтересованных сторон и конечных пользователей. Эти бизнес-правила затем преобразуются в структуры данных. Модель данных можно сравнить с дорожной картой, планом архитектора или любой формальной схемой, которая способствует более глубокому пониманию того, что разрабатывается.
Моделирование данных использует стандартизированные схемы и формальные методы. Это обеспечивает последовательный и предсказуемый способ управления данными в организации или за ее пределами.
В идеале модели данных — это живые документы, которые развиваются вместе с потребностями бизнеса. Они играют важную роль в поддержке бизнес-процессов и планировании ИТ-архитектуры и стратегии. Моделями данных можно делиться с поставщиками, партнерами и коллегами.
Преимущества моделирования данных
Моделирование упрощает просмотр и понимание взаимосвязей между данными для разработчиков, архитекторов данных, бизнес-аналитиков и других заинтересованных лиц. Кроме того, моделирование данных помогает:
Уменьшить количество ошибок при разработке программного обеспечения и баз данных.
Унифицировать документацию на предприятии.
Повысить производительность приложений и баз данных.
Упростить отображение данных по всей организации.
Улучшить взаимодействие между разработчиками и командами бизнес-аналитики.
Упростить и ускорить процесс проектирования базы данных на концептуальном, логическом и физическом уровнях.
Типы моделей данных
Разработка баз данных и информационных систем начинается с высокого уровня абстракции и с каждым шагом становится все точнее и конкретнее. В зависимости от степени абстракции модели данных можно разделить на три категории. Процесс начинается с концептуальной модели, переходит к логической модели и завершается физической моделью.
Концептуальные модели данных. Также они называются моделями предметной области и описывают общую картину: что будет содержать система, как она будет организована и какие бизнес-правила будут задействованы. Концептуальные модели обычно создаются в процессе сбора исходных требований к проекту. Как правило, они включают классы сущностей (вещи, которые бизнесу важно представить в модели данных), их характеристики и ограничения, отношения между сущностями, требования к безопасности и целостности данных. Любые обозначения обычно просты.
Логические модели данных уже не так абстрактны и предоставляют более подробную информацию о концепциях и взаимосвязях в рассматриваемой области. Они содержат атрибуты данных и показывают отношения между сущностями. Логические модели данных не определяют никаких технических требований к системе. Этот этап часто пропускается в agile или DevOps-практиках. Логические модели данных могут быть полезны для проектов, ориентированных на данные по своей природе. Например, для проектирования хранилища данных или разработки системы отчетности.
Физические модели данных представляют схему того, как данные будут храниться в базе. По сути, это наименее абстрактные из всех моделей. Они предлагают окончательный дизайн, который может быть реализован как реляционная база данных, включающая ассоциативные таблицы, которые иллюстрируют отношения между сущностями, а также первичные и внешние ключи для связи данных.
Процесс моделирования данных
Моделирование данных начинается с договоренности о том, какие символы используются для представления данных, как размещаются модели и как передаются бизнес-требования. Это формализованный рабочий процесс, включающий ряд задач, которые должны выполняться итеративно. Сам процесс обычно выглядят так:
Определите сущности. На этом этапе идентифицируем объекты, события или концепции, представленные в наборе данных, который необходимо смоделировать. Каждая сущность должна быть целостной и логически отделенной от всех остальных.
Определите ключевые свойства каждой сущности. Каждый тип сущности можно отличить от всех остальных, поскольку он имеет одно или несколько уникальных свойств, называемых атрибутами. Например, сущность «клиент» может обладать такими атрибутами, как имя, фамилия, номер телефона и т.д. Сущность «адрес» может включать название и номер улицы, город, страну и почтовый индекс.
Определите связи между сущностями. Самый ранний черновик модели данных будет определять характер отношений, которые каждая сущность имеет с другими. В приведенном выше примере каждый клиент «живет по» адресу. Если бы эта модель была расширена за счет включения сущности «заказы», каждый заказ также был бы отправлен на адрес. Эти отношения обычно документируются с помощью унифицированного языка моделирования (UML).
Полностью сопоставьте атрибуты с сущностями. Это гарантирует, что модель отражает то, как бизнес будет использовать данные. Широко используются несколько формальных шаблонов (паттернов) моделирования данных. Объектно-ориентированные разработчики часто применяют шаблоны для анализа или шаблоны проектирования, в то время как заинтересованные стороны из других областей бизнеса могут обратиться к другим паттернам.
Назначьте ключи по мере необходимости и определите степень нормализации. Нормализация — это метод организации моделей данных, в которых числовые идентификаторы (ключи) назначаются группам данных для установления связей между ними без повторения данных. Например, если каждому клиенту назначен ключ, этот ключ можно связать как с его адресом, так и с историей заказов, без необходимости повторять эту информацию в таблице с именами клиентов. Нормализация помогает уменьшить объем дискового пространства, необходимого для базы данных, но может сказываться на производительности запросов.
Завершите и проверьте модель данных. Моделирование данных — это итеративный процесс, который следует повторять и совершенствовать под потребности бизнеса.
Типы моделирования данных
Моделирование данных развивалось вместе с системами управления базами данных (СУБД), при этом типы моделей усложнялись по мере роста потребностей предприятий в хранении данных.
Иерархические модели данных представляют отношения «один ко многим» в древовидном формате. В модели этого типа каждая запись имеет единственный корень или родительский элемент, который сопоставляется с одной или несколькими дочерними таблицами. Эта модель была реализована в IBM Information Management System (IMS) в 1966 году и быстро нашла широкое применение, особенно в банковской сфере. Хотя этот подход менее эффективен, чем недавно разработанные модели баз данных, он все еще используется в системах расширяемого языка разметки (XML) и географических информационных системах (ГИС).
Реляционные модели данных были предложены исследователем IBM Э. Ф. Коддом в 1970 году. Они до сих пор встречаются во многих реляционных базах данных, обычно используемых в корпоративных вычислениях. Реляционное моделирование не требует детального понимания физических свойств используемого хранилища данных. В нем сегменты данных объединяются с помощью таблиц, что упрощает базу данных.
Реляционные базы данных часто используют язык структурированных запросов (SQL) для управления данными. Эти базы подходят для поддержания целостности данных и минимизации избыточности. Они часто используются в кассовых системах, а также для других типов обработки транзакций.
В ER-моделях данных используют диаграммы для представления взаимосвязей между сущностями в базе данных. ER-модель представляет собой формальную конструкцию, которая не предписывает никаких графических средств её визуализации. В качестве стандартной графической нотации, с помощью которой можно визуализировать ER-модель, была предложена диаграмма «сущность-связь» (Entity-Relationship diagram). Однако для визуализации ER-моделей могут использоваться и другие графические нотации, либо визуализация может вообще не применяться (например, только текстовое описание).
Объектно-ориентированные модели данных получили распространение как объектно-ориентированное программирование и стали популярными в середине 1990-х годов. Вовлеченные «объекты» — это абстракции сущностей реального мира. Объекты сгруппированы в иерархии классов и имеют связанные черты. Объектно-ориентированные базы данных могут включать таблицы, но могут также поддерживать более сложные связи. Этот подход часто используется в мультимедийных и гипертекстовых базах данных.
Размерные модели данных разработал Ральф Кимбалл для быстрого поиска данных в хранилище. Реляционные и ER-модели делают упор на эффективное хранение и уменьшают избыточность данных, а размерные модели упорядочивает данные таким образом, чтобы легче было извлекать информацию и создавать отчеты. Это моделирование обычно используется в системах OLAP.
Две популярные размерные модели данных — это схемы «звезда» и «снежинка». В схеме «звезда» данные организованы в факты (измеримые элементы) и измерения (справочная информация), где каждый факт окружен связанными с ним измерениями в виде звездочки. Схема «снежинка» напоминает схему «звезда», но включает дополнительные слои связанных измерений, что усложняет схему ветвления.
Инструменты для моделирования данных
Сегодня широко используются многочисленные коммерческие и CASE-решения с открытым исходным кодом, в том числе различные инструменты моделирования данных, построения диаграмм и визуализации. Вот несколько примеров:
erwin Data Modeler — это инструмент моделирования данных, основанный на языке IDEF1X, который теперь поддерживает и другие нотации, включая нотацию для размерного моделирования.
Enterprise Architect — это инструмент визуального моделирования и проектирования, который поддерживает моделирование корпоративных информационных систем и архитектур, программных приложений и баз данных. Он основан на объектно-ориентированных языках и стандартах.
ER/Studio — это программа для проектирования баз данных, совместимая с некоторыми из самых популярных СУБД. Она поддерживает как реляционное, так и размерное моделирование данных.
Бесплатные инструменты моделирования данных включают решения с открытым исходным кодом, такие как Open ModelSphere.
Для того, чтобы преобразовать данные в структуру, которая соответствует требованиям модели, можно использовать встроенный механизм регулярных запросов, которые выполняются в Google BigQuery, Scheduled Queries и AppScript. Их легко можно освоить, потому что это привычный SQL, но проводить отладку в Scheduled Queries практически нереально. Особенно, если это какой-то сложный запрос или каскад запросов.
Есть специализированные инструменты для управления SQL-запросами, например, dbt и Dataform.
dbt (data build tool) — это фреймворк с открытым исходным кодом для выполнения, тестирования и документирования SQL-запросов, который позволяет привнести элемент программной инженерии в процесс анализа данных. Он помогает оптимизировать работу с SQL-запросами: использовать макросы и шаблоны JINJA, чтобы не повторять в сотый раз одни и те же фрагменты кода.
Главная проблема, которую решают специализированные инструменты — это уменьшение времени, необходимого на поддержку и обновление. Это достигается за счет удобства отладки.
Знакомство с парадигмами построения моделей предметной области
Введение
Возможно, кто-то задаст вопрос, а причем тут математика? Отвечу сразу: все, что здесь изложено, относится непосредственно к математике.
Изучая литературу по теории построения моделей предметной области, я обнаружил серьезный пробел. Авторы статей и книг сразу берут одну из нотаций моделирования: ER-диаграммы, или диаграммы классов, и в быстром темпе начинают их использовать для описания предметной области. При этом описание парадигмы, в которой производится это моделирование остается вообще не раскрытым. А следовательно, не раскрытыми остаются ограничения той или иной нотации. Увы, мы все умеем строить модели, но мало кто умеет объяснить то, что он построил в одной из существующих парадигм. Поэтому я часто слышу дикие с точки зрения любой парадигмы термины: класс типов, типы классов, виды типов и так далее, но ни разу не слышал корректный термин «класс классов». Этот пробел в нашем образовании очень серьезен. И я объясню почему.
Давайте зададим аналитикам простой вопрос.
Те, кто моделировал процессы, наверно, знакомы с нотацией BPMN. Очень часто при моделировании операции по заключению договора я встречаю такой фрагмент диаграммы:
Видно, что в результате заключения договора рождается нечто, что передается в другую операцию. Но что обозначает элемент диаграммы в виде листа с загнутым уголком? Нам надо точно знать, что именно передается из одной операции в другую, иначе трудно будет объяснить другим, что от них требуется. Итак, что создается на выходе из операции «Заключить договор»?
Варианты ответов, которые я слышал, следующие:
Как мы строим модель сущего?
Посмотрите на рисунок. На нем схематично изображен процесс построения модели сущего.
Таким образом, мы видим, что парадигма, модель и нотация – это то, что находится в сознании субъекта. Мы видим, что сущее, описание парадигмы, описание нотации и представление модели – это то, что находится вне субъекта.
Если мы делаем ДОПУЩЕНИЕ, что мир ДЕЙСТВИТЕЛЬНО состоит из 4-Д пространства-времени и объектов в нем расположенных, то картинку можно перерисовать так:
Особенности парадигм
Для описания мира мы обычно используем две парадигмы: парадигму Аристотеля и логическую парадигму. Обе они покоятся на предположении о том, что мир предметен и представляет из себя 4-Д пространство-время. Но между парадигмами есть различия, которые я должен подчеркнуть.
Хорошо, когда парадигма и нотация согласованы. Тогда возможности парадигмы будут полностью использованы. И тогда становится возможным «мышление при помощи записей». То есть, можно будет рисовать представление модели одновременно с ее созданием. Так мыслят многие, когда, например, пишут статьи, рисуют картины, или чертят чертежи.
С парадигмой Аристотеля согласуется моделирование в виде таблиц. Однако связи между таблицами – это то, что Аристотель не планировал. Поэтому нотация ER-диаграмм, хоть и основана на парадигме Аристотеля, но выходит за ее границы. Нотация диаграмма классов также идет за пределы парадигмы Аристотеля и не согласуется с ней. Она служит для моделирования программного кода. В предметном мире вы не найдете ни наследования, ни инкапсуляции. Все эти термины программирования, а не предметной области. Для описания предметной области диаграммы классов и ER-диаграммы подходят, как сказал Левенчук одной из своих статей, между плохо и очень плохо. Многие не знают этих ограничений, и потому считают, что ограничений нет вообще. Это заблуждение лечится только одним способом – изучением логической парадигмы. Для логической парадигмы используется две нотации, описанные в стандарте ИСО 15926.
Существует спор между инженерами и философами. Инженеры часто упрекают философов, что те, мол, занимаются словоблудием. Философы говорят о том, что если бы не их словоблудие, не было бы инженеров. А математики молчат. Но фокус в том, что математика и философия до 20-го века были слиты вместе. Декарт и Кантор – великие философы – математики. Задача была простая. Мало было придумать парадигму, надо было придумать нотацию для передачи моделей в этой парадигме другим гражданам, а также надо было уметь проверить парадигму на непротиворечивость. Решением этой задачи занималась наемница философии – математика. Но в 20-м веке Рассел предположил, что надо отделить математику от философии. Просто потому что математика давала результаты слишком далекие от нашего эмпирического опыта. И вместо того, чтобы постулировать ограниченность нашего опыта, Рассел поступил в духе антропоцентризма, — он предложил более не думать над смыслом математических открытий. Молодец! Мы пожинаем плоды этого разделения сейчас. Теперь мало, кому известны парадигмы и для чего они существуют. Плодятся множество нотаций, оторванных от парадигм, задача которых удовлетворить потребности здесь и сейчас. А то, что они противоречивы и границы их возможностей не описаны, — это мало кого волнует. Жаль, потому что в результате нотации массово используется для построения моделей предметных областей людьми, которые не знают ограничений этих нотаций. Однако, не все так плохо. Есть те, кому это известно. В книге на странице 36-37 написано:
Программные объекты в некотором смысле соответствуют объектам реального мира, но не являются их точными моделями или копиями. Хотя полученная диаграмма классов проектирования не до конца соответствует модели предметной области, некоторые имена классов и их характеристики совпадают. Объектно-ориентированные проектные решения и языки позволяют уменьшить разрыв между представлением информации в виде программных компонентов и ментальными моделями предметной области. Это улучшает образность представления.
Хорошо, когда создаваемые модели удовлетворяют свойствам: полнота (все, что мы хотели сказать, должно присутствовать в модели), непротиворечивость (одна часть описания должна не противоречить другой части), расширяемость (добавление новых данных не должно приводить к возникновению противоречий). Для того, чтобы модель имела указанные свойства, парадигма построения моделей должна позволять это сделать. Парадигма Аристотеля не удовлетворяет требованию непротиворечивости и расширяемости моделей. Именно поэтому на смену Аристотелевской пришла логическая парадигма, основанная на теории множеств.
Построение одной модели более чем для одного объекта
Построив одну модель для одного объекта, можно попробовать посмотреть, насколько она подходит другому объекту. Или так: можно сразу строить модель с учетом того, что она будет описывать много объектов реального мира. Так мы получаем одну универсальную модель для множества объектов одновременно. Это очень облегчает задачу описания реального мира. Мы находим предметы чем-то похожие друг на друга и описываем их одной моделью. Конечно, некоторые индивидуальные черты придется «дописывать» для каждой модели отдельно, но это мелочи по сравнению с индивидуальным описанием каждого объекта отдельно. Именно так мы поступаем, когда создаем чертеж, на основании которого потом может быть создан один функциональный объект, а может и много! Эти объекты образуют множество, или класс. Про любой объект этого класса можно сказать, что чертеж является его моделью. Аристотель использовал другую риторику. Он говорил, что чертеж — есть описание типа объектов. А объекты — есть экземпляры этого типа.
Как поступает сценарист, пишущий сценарий? Он делает сценарий, а будет ли поставлен по нему спектакль и сколько будет в итоге представлений, — он не знает. Сценарий может быть моделью одного выступления, например, празднования Нового 2015 года. Или он может моделировать множество выступлений, как, например, сценарий балета Щелкунчик. Понятно, что сценарий – один, а выступлений – много. В логической парадигме это описание выглядело бы так: есть множество всех выступлений, подмножество этого множества – есть выступления, сделанные на основе сценария «Балет Щелкунчик».
То же самое в парадигме Аристотеля выглядело бы так. Есть объекты — выступления. Любое выступление – есть экземпляр выступления. Есть объекты другого типа – это выступления, сделанные по одному сценарию «Балет Щелкунчик». Любое выступление по этому сценарию – это экземпляр выступления «Балет Щелкунчик». Одно и то же выступление одновременно является экземпляром выступления и экземпляром выступления «Балет Щелкунчик». При этом Аристотель сейчас должен немного заволноваться, потому что он такого не говорил! У него нет того, что один объект может принадлежать разным типам! Это уже наша интерпретация, основанная на моделировании в виде ER-диаграмм. Это и еще много чего не позволяют построить непротиворечивую модель предметной области на основе парадигмы Аристотеля.
Модель информационных объектов
Таким образом, в логической парадигме объектам одного множества может быть поставлена в соответствие одна модель:
Объекты, которые мы описываем одинаковыми моделями, мы называем похожими и относим их к одному классу. Например, класс насекомых, или класс болтовых соединений. Кроме того, одна модель также может быть представлена множеством информационных объектов. Например, одна модель болтового соединения может иметь множество представлений в виде разных листов ватмана с рисунком на нем, в виде зарисовок в тетрадях и так далее. Понятно, что все эти представления используют одну нотацию, но при этом все они разные:
Во всем множестве представлений нас интересуют лишь те, которые сделаны по определенным правилам. Например, мы не хотим рассматривать чертежи, высеченные из камня. Для этого нам надо ввести дополнительные правила, по которым будут создаваться информационные объекты, которые нас устроят. Эти правила составят модель уже самих информационных объектов. Так получается следующая иерархическая структура:
Множество информационных моделей описывается моделью информационных объектов. Модель эта находится в головах и людей. Эта модель порождается в результате применения специальной парадигмы, которая рассматривает объект предметной области как информационный. Потом после применения нотации модель информационных моделей может быть выражена в виде представлений этой модели.
Таким образом, любой объект может иметь модель и ее представление. В свою очередь представление также может иметь свою модель и так до бесконечности. Эта бесконечность — одно из очень серьезных ограничений логической парадигмы. Разрешать это противоречие я не умею. Но честно признаю, что ограничения логической парадигмы есть, и они в том, что рано или поздно нам придется оборвать цепь моделей и сослаться на здравый смысл.
Договор
Если применить построенную конструкцию к нарисованной в самом начале статьи диаграмме, то у нас возникают вопросы: что такое договоренность? Это реальность, или модель реальности? Что такое договор? Что такое листочки с печатями? Что такое файл в формате MS Word? Что такое запись в БД? И что она фиксирует: договор, договоренность, реальность?
Я нарисовал кусок модели, начиная с договоренности, но не расшифровывал, что такое сама договоренность.
Мы видим, что реальная модель предметной области довольно сложна. При этом мы не нарисовали всех подробностей и не нарисовали всех уровней модели, потому что умение работать с MS Word не предполагает знания формата хранения данных. А знание формата хранения данных не означает знание правил управления печатной головкой. И так далее. Есть физические объекты и субъекты, есть информационные объекты и функциональные, и связаны они порой довольно сложными иерархическими связями. Надо учиться эти связи моделировать и передавать другим в качестве знаний.
Например, 7-ми уровневая сетевая модель OSI – есть иерархическая модель физических и информационных объектов.
В сокращенном варианте приведенная модель выглядит так:
И вот это уже узнаваемая конструкция. В ней исключены сущности, которые можно пропустить с точки зрения моделирования данных. Но теперь, глядя на нее, вы знаете о тех связях, которые их связывают. Порой, чтобы построить корректную модель, необходимо знать много больше, чем нарисовано. И моя статья как раз демонстрирует ход мыслей, которые может делать любой, чтобы не ошибиться. Попробуйте порассуждать над любым вопросом в вашей предметной области. Попробуйте задавать вопросы до тех пор, пока не начнете ясно понимать, что вы видите. Иначе будет так:
Мы дальтоники. Только не в смысле: цвета не различаем, нет. Мы не различаем смысл слов, употребляемых в разном контексте.
То, что мы говорим сокращенные фразы, смысл которых определяется контекстом, — это вынужденная мера для выживания. Мы должны иметь возможность быстро изъясняться: Глянь: голодный волк! вместо: Погляди: объект, принадлежащий множеству волков, одновременно принадлежит классу голодных живых существ! Но, употребляя сокращенные фразы, мы не должны забывать об их полном смысле, и должны уметь этот смысл восстанавливать. Однако, пока происходит обратный процесс: используя сокращенные элементы языка, мы все дальше и дальше удаляемся от понимания того, что скрывается за ними.
Когда я еду в деревню, то готовлюсь к празднику слуха. Разговор деревенских полон смысла, оттенков и музыки. Я вижу, что, произнося слова, деревенский житель не просто жонглирует ментальными конструкциями, как это принято в городской среде, он одновременно переживает и образы, скрытые за словами, и погружен всем своим существом в контекст, в котором живут эти образы. Переживание образов и контекста как основы удерживает целостность конструкций, и не дает повода для возникновения противоречий.
В отличие от деревенского, городской житель, наученный восприятию слов в отрыве от контекста, может использовать стандартные языковые шаблоны. Это приводит к потере сначала контекста, а потом и размытию смысла самих слов. Отрыв слов от контекста не позволяет удержать целостность и непротиворечивость конструкций. В итоге происходит подлог: набор языковых паттернов подменяет знание. Поскольку слушателями такого человека часто являются такие же как и он, — неспособные одновременно удерживать в сознании и смысл и контекст, то этот фокус проходит. Я встречаю мастеров жонглирования словами. Это те, кто умеют менять контекст, и в соответствии с этим менять языковые паттерны: психотерапевты, учителя, мошенники и хорошие политики, хорошие аналитики. А вот плохие учителя, например, не понимают в чем секрет такой гибкости и умеют лишь имитировать действия хороших. Секрет прост – переживание контекста дает возможность сохранять целостность, а умение менять контекст, дает возможность творить.