Непейвода Н.Н., Скопин И.Н. Основания программирования

Подождите немного. Документ загружается.

Глава 15

Моделирование

С самого своего отделения от прачеловека человек строил вычислитель-

ные модели. Лунно-солнечно-венерианские календари, видимо, знали уже в

Гиперборее (или Арктиде: легендарной прародине цивилизации, далеко на

Севере, там, где полгода день и полгода ночь); во всяком случае, они най-

дены на костях мамонтов в Сибири. Так что математическое моделирование

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

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

кто занимается проблематикой информатики и программирования.

Одной из первичных целей использования вычислительных машин бы-

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

данных модели обычно называют предметной областью. При таком модели-

ровании вычислительные машины используются как инструмент проециро-

вания модели на оборудование: модель (как правило, математическая) здесь

остается вне комплекса вычислительных средств, а задача программистов

сводится к построению ее интерпретации на данном оборудовании. Другой

вид моделирования — когда модель предметной области включается в вычи-

слительную систему. Это можно делать по-разному, и компьютерные модели

можно подразделить на несколько классов, в зависимости от того, что требу-

ется от моделирования.

Исторически первый классом моделей, появивишийся задолго до вычи-

слительных машин, для которого вычислительные средства являются лишь

инструментом, — вычислительные модели. Древние строили их на костях

мамонтов [47], варвары использовали мегалиты типа Стоунхеджа, европей-

цы XVIII века использовали часовые механизмы, европейцы и американцы

первых двух третей XX века — аналоговые машины. Этот тип моделирова-

805

806

ГЛАВА 15. МОДЕЛИРОВАНИЕ

ния стал одним из первых применений первых компьютеров.

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

машины — непосредственное построение систем объектов (в любом пони-

мании этого слова), которые отображают в вычислительной системе реаль-

ные объекты и их связи, признанные существенными в заданных для моде-

ли аспектах предметной области. В этой области мы сталкиваемся с мно-

жеством стратегий и приемов отображения выделенных аспектов реального

мира.

Часто здесь в качестве цели рассматривается принятие решений на осно-

ве модельных данных, по разным причинам подменяющих данные реально-

сти (невозможность или затруднительность их получения,упрощение для на-

блюдения и др.). Этот вариант получил название имитационного моделиро-

вания.Пожалуй, автором его можно считать Клавдия Птолемея, построивше-

го имитационную модель Солнечной системы в геоцентрических координа-

тах, моделируя движения планет как движения систем сфер. Так что и здесь

история метода началась значительно раньше истории его внедрения в про-

граммирование. Но первые вычислительные машины были слишком прими-

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

машин Цузе они доросли до него. И сразу же стало ясно, что такие модели

требуют своих программных средств.

Появилось довольно много языков и систем программирования (как пра-

вило, включавших собственный жаргон для описания моделей, и тем самым

являвшихся скорее недоделанными языками), ориентированных на модели-

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

претендовали на возможность всеобщего применения для имитационного

моделирования. Был ряд прагматических разработок,из которых дольше все-

го удерживалась

CSSL

на базе

FORTRAN

. Из общего прагматического ря-

да выделялись

GPSS

(язык, построенный на базе

FORTRAN

Ўа для моде-

лирования поведения вычислительных устройств — этакая «самопримени-

мость» моделирования с использованием вычислительного оборудования),

SIMSCRIPT

Simula

(языки общего назначения для данной сферы примене-

ния). Последний из упомянутых языков заслуживает особого внимания пре-

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

проработанную систему, а не просто набор средств, помогающих описывать

модели программами. Осознание продуктивности такого подхода позволило

им осуществить в этой области блестящий для своего времени прорыв

Simula

, впервые создавший концепцию объектного программирования.

Еще один класс систем моделирования, также связываемый с принятием

807

решений, исходит из сбора и хранения реальных данных (опять-таки касаю-

щихся лишь выделенных аспектов), которые отображают сведения об объек-

тах предметной области. Это информационные системы.

Все упомянутые выше варианты моделирования носят прикладной ха-

рактер в том смысле, что назначение соответствующих систем — обслужи-

вание специалистов, интересы которых лежат вне области программирова-

ния и информатики. Вместе с тем моделирование как метод, используемый

в данной отрасли человеческой деятельности, не ограничивается уровнем

приложений. С самого начала развития этой отрасли моделирование имеет

весьма разнообразные цели. Здесь и моделирование вычислительными ма-

шинами математических систем вычислений (к сожалению, далеко не всегда

достаточно точное), и построение абстрактных вычислителей, моделирую-

щих в языках действия конкретных вычислителей (адекватность таких моде-

лей вполне удовлетворительна), и даже моделирование процесса разработки

программной системы

CASE

-средствами (уровень точности зависит от соот-

ветствия между предметной областью и областью, на которую ориентирован

используемый инструмент). Полный перечень задач такого рода привести не

представляется возможным.

Методов моделирования, направлений и подходов к нему великое множе-

ство. В данной книге мы касаемся лишь некоторых аспектов моделирования,

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

обсуждаемого подхода. Мы не будем подменять систематическое изложение

методов моделирования поверхностным обзором, а вместо этого дадим пред-

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

можно столкнуться в том или ином случае.

В частности, вопросы, скажем, связанные с аналитическими моделями

и задачи статистического моделирования – предмет специального изучения,

и в программистском плане можно счиать, что они сводятся к правильному

выполнению этапа анализа жизненного цикла разрабатываемой системы и к

соблюдению должных регламентов технологии разработки. В то же время,

есть общие положения, которые проявляются в подавляющем большинстве

проектов, цель которых — моделирование. К ним относятся:

a) вычислительные трудности моделирования (точность и корректность ре-

зультатов счета, правильность их интерпретации и т. п.);

b) информационное обеспечение моделирования (задачи создания и исполь-

зования информационных систем);

808

ГЛАВА 15. МОДЕЛИРОВАНИЕ

c) моделирование времени (вопросы, касающиеся того, какую роль играет

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

§ 15.1. МОДЕЛИ И ВЫЧИСЛЕНИЯ

Любые расчеты, для которых применяется вычислительное оборудова-

ние, можно рассматривать как моделирование вычислений над математиче-

скими объектами вычислениями, которые осуществляются на реальной ма-

шине. И здесь возникает первое препятствие для использования получаемых

данных: законы, которым подчиняется оперирование с математическими

объектами, не действуют на объектах, которые используются на уровне

машинного представления данных.

Недостаточно говорить о точности вычислений, понимая просто исполь-

зование нужного количества знаков «после запятой». Хорошо известно, что

ошибки счета, возникающие из-за округлений, могут накапливаться и приво-

дить к ситуациям, когда они оказывают существенное влияние на значащие

разряды чисел. Но и тогда, когда мы можем считать точными исходные ар-

гументы операций, участвующих в вычислениях, не исключаются ситуации,

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

мер — нарушение ассоциативности сложения: легко подобрать четыре такие

числа A, B, C и D, для которых, а точнее, для машинных представлений ко-

торых неверно, что

(A + B) + (C + D) = A + (B + C) + D

(придумайте сами такие числа для вашего компьютера).

Гарантированные вычисления (вычисления на компьютере, обеспечива-

ющие доказательную правильность некоотрых свойств результата) — сложд-

нейший аспект алгоритмики, игнорируемый в стандатных курсах для студен-

тов. Существуют тонкие, но частные, теоретические проработки и постро-

енные на них методики, с помощью которых можно бороться в ошибками

счета. Безусловно, их надо знать и использовать на практике. Но надо четко

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

определены при их разработке.

Хуже всего то, что запись программы на языке программирования про-

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

контроль их появления даже в случаях, когда он возможен, резко снижает эф-

фективность счета. В результате у пользователя создается впечатление, что

15.1. МОДЕЛИ И ВЫЧИСЛЕНИЯ

809

«все правильно» и можно интерпретировать результаты счета как реальные

величины.

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

поддержки преодоления ошибок за счет контроля разрядности (например,

средства типизации арифметических значений в

Ada

— см. п. 9.2.5). Однако

даже эти весьма скромные и не отвечающие реальной потребности средства,

достаточно легко применимые к поименованным (пусть даже косвенно) объ-

ектам, не применимы к промежуточным результатам вычислений, которые

не видны в исходной программе и которые неотделимы от платформы вычи-

слений.

Мы не собираемся подменять систематическое изложение разделов вы-

числительной математики, изучающих численные методы, заведомо непол-

ными выдержками и рецептами. Наша цель состоит в одном: предупредить

читателя и посоветовать ему для получения необходимых знаний обращаться

к первоисточникам.

Пример 15.1.1. Давно известно (см. напр. [24]), что вычисление собствен-

ных значений — безнадежно некорректная задача, и что на самом деле в

практических целях нужно вычислять инвариантные подпространства ли-

нейных операторов. В

CERN FORTRAN

накоплена громадная библиотека чи-

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

та, как

FORTRAN

. О качестве проработки этих методов красноречиво гово-

рит факт наличия в этой библиотеке целого раздела, посвященного вычисле-

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

не ходят в одиночку.

Конец примера 15.1.1.

То, о чем шла речь выше — объективные факторы. Но есть еще и субъек-

тивные факторы, также препятствующие адекватности выполнения и ис-

толкования расчетов. Они проявляются из-за того, что программирование

выполняют конкретные люди, которым свойственно ошибаться. Эти факто-

ры можно классифицировать следующим образом:

a) ошибки в исходных допущениях — разработчики неправильно понимают

условия, в которых должно применяться проектируемое программное из-

делие;

b) алгоритмические ошибки — используются некорректные или неприме-

нимые в конкретных условиях алгоритмы;

810

ГЛАВА 15. МОДЕЛИРОВАНИЕ

c) ошибки проектирования — декомпозиция проекта проведена без учета

требований корректности расчетов (не предусмотрен контроль результа-

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

согласования межмодульных взаимодействий и др.);

d) индивидуальные ошибки программирования — неправильно запрограм-

мированные верные алгоритмы,нарушение регламентов разработки и про-

ектной дисциплины;

e) ошибки в применении программного изделия и/или в интерпретации ре-

зультатов счета — результаты трактуются не в соответствии с исходны-

ми предположениями и допущениями.

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

ные препятствия, можно указать следующее: заранее всесторонне продумай-

те концепции развиваемого проекта, уделите внимание организационным во-

просам, регламентирующим технологию разработки, учитывайте опыт соб-

ственных и чужих ошибок, дабы не повторять их. Не стоит игнорировать

общие предписания и рекомендации, которые сопутствуют вашей разработ-

ке, и, в частности, осознанно выбирайте жизненный цикл развития проекта.

Среди общих рекомендаций особое место занимают вопросы стилей, кото-

рым вы будете следовать при выполнении программистских работ. Надо чет-

ко осознавать, что только адекватность стиля решаемой задаче может, если

не гарантировать качество решения, то хотя бы способствовать успеху.

§ 15.2. МОДЕЛИРОВАНИЕ ВРЕМЕНИ

Время — одно из центральных мпонятий при имитационном моделирова-

нии. Понятие времени в модели, если оно не соответствует реалиям предмет-

ной области чаще всего просто губит модель, делает работу с ней неадекват-

ной. Поэтому нужно рассмотреть разные подходы к моделированию време-

ни.Конкретная модель времени выбирается исходя из потребностей, которые

диктуются прикладной областью и тем, как используются модели. Поэтому

разделим задачи моделирования на два класса в соответствии с принимаемой

точкой зрения на модельное время:

• наблюдение — соответствует имитационному моделированию, в кото-

ром модельное время, а точнее, связанные с ним события только от-

слеживается, а все эндогенные (внешние) воздействия осуществляют-

ся как коррекции траекторий развития имитационной системы. В этот

15.3. ИНФОРМАЦИОННЫЕ СИСТЕМЫ С ВРЕМЕНЕМ

811

класс попадают также системы прямого мониторинга реальных про-

цессов, когда внешняя коррекция траекторий не допускается;

• реальное развитие — соответствует информационным системам с вре-

менем, которые отслеживают события, реально происходящие в пред-

метной области, и привносят сведения о них, в частности, для коррек-

тировки хранимых данных - реальных, продуцируемых до момента,

считающегося текущим, и прогнозируемых, вычисляемых для после-

дующей за этим моментом траекторией развития хранения данных.

В первом случае имеется столько моделей развития имитируемой системы,

сколько вариантов воздействий предусмотрено. При анализе получаемых ре-

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

мент для подобных приложений должен обеспечить пользователя средства-

ми сравнения моделей, согласованного с воздействиями. Во втором случае

нельзя обойтись без согласования модельного и реального времени.

Здесь имеется целый спектр решений, начиная от квантованного предста-

вления времени (это важно, например, при имитации поведения тактируемо-

го вычислительного оборудования для проверки проектных архитектурных

решений или в иных в целях) до отслеживания времени при наступлении

событий.

§ 15.3. ИНФОРМАЦИОННЫЕ СИСТЕМЫ С ВРЕМЕНЕМ

Учет времени — одно из критических мест в современных информаци-

онных системах. Именно здесь в них возникают связи с моделировнаием.

Обсудим возникшую ситуацию.

В настоящее время наиболее попоулярным видом информационных си-

стем являются реляционные базы данных. Моделирование в данной обла-

сти возникает, когда разрабатываются средства ведения баз данных. Как мы

имели возможность убедиться, почти полная монополия реляционных СУБД

обусловлена не столько неоспоримыми их преимуществами, сколько успеш-

ным захватом экологической ниши. Те же причины, по которым применение

таких систем для хранения объектных сред является неадекватным, относят-

ся и к задачам, связанным с необходимостью информационных систем со

временем.

Наиболее очевидное, и, как обычно, одно из наиболее неудачных реше-

ний в данном вопросе — реализовать в реляционных таблицах специальный

812

ГЛАВА 15. МОДЕЛИРОВАНИЕ

атрибут, отвечающий за отслеживание временных изменений хранимых дан-

ных, и рассматривать его как обычный атрибут хранимых данных. Этот путь

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

мени в запросах все-таки принципиально отличается от того, как оперируют

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

пример, в свое время был предложен диалект языка

SQL

, в предложениях

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

нигде его не определяя. Но этот диалект так и остался диалектом, не получив

распространения.

Немногим лучше объектные и объектно-реляционные СУБД с временем

(например, POSTGREATE). Здесь, правда, за счет сетевой модели предста-

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

никак не задействован, со всеми вытекающими отсюда последствиями.

Если проанализировать как часто используют СУБД с временем в при-

кладных информационных системах, то выяснится, что реального распро-

странения они не получили. Обычно, когда требуется оперирование с време-

нем, оно реализуется на уровне приложений, т. е. без поддержки средствами

СУБД. Причина тому глубже, чем просто неэффективная реализация (если

бы актуальность такой поддержки была осознана, нужные реализационные

механизмы, конечно же, сумели бы придумать, как это было сделано для са-

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

альной проработки понятия времени в системах, которые мы охарактеризо-

вали свойством реального развития.

Рассмотрим одну из важнейших побудительных причин применения СУБД:

поддержка целостности данных. Без этого качества, предоставленного для

всех пользователей в унифицированном виде, особенно при коллективном

использовании, никакая СУБД не может претендовать на полезность. Имен-

но поэтому понятие целостности и средства ее поддержки нашли свое от-

ражение и в теоретических исследованиях, и в проектах. Именно поэтому к

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

какую поддержку целостности нужно возложить на СУБД, а какую ее часть

целесообразно оставить на стороне приложений. Одним из наиболее значи-

тельных достижений этих соглашений следует рассматривать формирование

транзакционного механизма, который в части, касающейся целостности, га-

рантирует что ни при каких обстоятельствах согласованность данных и их

связей не нарушается.

Целостность в реляционных СУБД — это, прежде всего, обеспечение в

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

15.3. ИНФОРМАЦИОННЫЕ СИСТЕМЫ С ВРЕМЕНЕМ

813

т. е. нельзя просто так удалить элемент данных, на который ссылаются какие-

либо другие элементы. Также нельзя произвольно манипулировать полями

(добавлять и удалять их) без соответствующего контроля, который влечет за

собой возможность рассогласования связей. Если же проанализировать, что

может означать рассогласование связей при использовании СУБД с време-

нем (именно это и не было сделано для упомянутых выше разработок), то

сразу же обнаруживается, что в соответствующих им информационных си-

стемах необходимо отслеживать не только атрибутные связи, но и зависимо-

сти от времени. В самом деле, события, происходящие в предметной обла-

сти и отраженные в соответствующих хранимых объектах системы, влияют

на другие объекты, причем даже на те их атрибуты, которые появятся или

изменятся в будущем. Это требует того, чтобы будущие сведения предста-

влялись динамическими ограничениями на домены соответствующих атри-

бутов,чтобы при занесении в базу данных сведений об объектах происходила

корректировка хранимых данных, причем направленная как в будущее, так и

в прошлое. Необходимо также корректировать и запросы, которые зависят от

таких актах модификации данных. Словом, понятие временной целостности,

без которого СУБД, обеспечивающие информационные системы с временем,

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

которой, на наш взгляд, объясняет сегодняшнюю непопулярность таких си-

стем.

В данном случае мы наблюдаем исключительно редкий в современной

иформатике феномен:пользователи информационных систем с временем от-

вергают концептуально слабо проработанные системы. Видимо, это объяс-

няется тем, что пользователи систем рассматривают их не как программные

системы, а как базу реальных данных, и поэтому подходят к ним с точки

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

программистами.

Характеристической особенностью современного программиста являет-

ся умение работать в исключительно плохо организованной обстановке сред-

ствами, которые по сути своей либо не подходят для решаемой задачи, либо

плохо согласуются друг с другом. Он должен уметь приспосабливать содер-

жание задачи к извращенным формам, которые ему предлагают доступные

средства. Именно поэтому задача концептуальной целостности практически

никогда не ставится, а задача нахождения и устранения либо обхода концеп-

туальных противоречий просто замалчивается.

Пока профессиональной доблестью будет считаться умение извлекать глан-

ды через любое отверстие в системе, приципиальных продвижений в про-

814

ГЛАВА 15. МОДЕЛИРОВАНИЕ

граммировании ждать трудно, и оно будет все больше инструментом, по вы-

ражению Г. Вейценбаума, компьютерной контрреволюции.

§ 15.4. МОДЕЛИРОВАНИЕ И ИНФОРМАЦИОННЫЕ СИСТЕМЫ

Вопросы, которые возникают при решении задач создания и использова-

ния информационных систем, могут рассматриваться в трех планах.

1. Соотношение между построением конкретных моделей и их информа-

ционным обеспечением.

2. Информационные системы рассматриваются как отрасль моделирова-

ния, применяемого для принятия решений.

3. Моделирование организации сбора и хранения сведений (в управляю-

щих системах, в системах реального времени и т. д.).

Три эти аспекта смыкаются в соотношениях между понятиями информаци-

онной системы, базы данных и системы управления базами данных (СУБД).

В наиболее общем виде информационная система —система,которая обес-

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

выделить часть действий, производимых безотносительно смысла данных,

то получится следующий список:

a) поступление данных;

b) хранение данных;

c) модификация данных;

d) получение, или извлечение, данных.

Такие действия называют манипулированием данными. Эта часть действий,

связанных с информационной системой,обеспечивается базой данных.Един-

ственное, что база данных в состоянии знать — некоторые формальные кри-

терии корректности данных. Она может (и должна!) проверять эти критерии,

когда данные поступают на хранение и когда они модифицируются.

Пример 15.4.1. В качестве одного из примеров критериев естественно рас-

смотреть доменный анализ. Модифицируемое или вновь вводимое данное

проверяется на принадлежность некоторому множеству, называемому доме-

ном допустимых значений. Домен может зависеть от других данных. Напри-

мер, зарплата заместителя может быть от 60 до 80% зарплаты начальника.

Конец примера 15.4.1.