ПРИМЕНЕНИЕ ЯЗЫКА UML ПРИ ПРОЕКТИРОВАНИИ МАШИН КЛЕТОЧНЫХ АВТОМАТОВ Текст научной статьи по специальности «Компьютерные и информационные науки»

ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ

УДК 004.946; 519.673

Применение языка UML при проектировании машин клеточных автоматов

И.В.Матюшкин, А.В.Хамухин

Московский государственный институт электронной техники (технический университет)

Рассмотрено применение UML для разработки архитектуры машин клеточных автоматов (МКА). Сформулированы общие требования к МКА. Приведена абстрактная структура ячейки для МКА, адаптированной к мультиагентной технической системе. Диаграммы вариантов использования, классов и последовательностей созданы посредством программы StarUML.

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

Со времени принятия в 1997 г. группой OMG предложения фирмы Rational Software по разработке унифицированного языка моделирования (UML) этот язык стал популярным средством CASE-технологий [1, 2, 3, 4]. Сложившая практика использования UML, начиная уже с семантики примеров книги Гради Буча [1], прочно связывает его с разработкой информационных систем, в частности сложных баз данных (в дополнение к технике ER-диаграмм и ГОEF1x-нотации), которые главным образом ориентированы на бизнес-приложения. Однако сами авторы языка неоднократно отмечали, что значение UML выходит за рамки RUP-технологии создания программного обеспечения и следует считать его инструментом работы системного аналитика. При этом его правильнее назвать визуальным объектно-ориентированным языком метапрограмирования и одновременно метамоделирования [5].

Можно найти примеры UML-описаний при моделировании городской транспортной системы [6] или проектировании надежной геоинформационной системы [7]. Для специалистов в области микроэлектроники представляет интерес опыт использования UML для проектирования программно-аппаратных комплексов, работающих в режиме реального времени [8]. По-видимому, ограниченный опыт применения UML в научно-технических приложениях связан с двумя причинами. Во-первых, высокий уровень абстракции, задаваемый UML, не всегда соответствует уровню конкретики предметной области. Иными словами, по мере возрастания сложности исследуемой системы возрастает и объективная потребность в использовании UML, а значит для создания сравнительно простых программ при симуляции физических или технических процессов обращаться к UML действительно нецелесообразно. Во-вторых, существует консерватизм и инерция мышления самих программистов.

© И.В.Матюшкин, А.В.Хамухин, 2010

В настоящей работе рассмотрена разработка архитектуры САПР средствами UML для предметной области клеточных автоматов. Тематика клеточных автоматов (cellular automata) оказалась широко востребованной в последнее десятилетие, количество публикаций по ней неуклонно растет. Это связано как с ее фундаментальным значением, поскольку клеточный автомат (КА) является простейшей абстракцией в области параллельных вычислений и мультипроцессорных систем [9], так и с прикладным использованием моделей клеточных автоматов [10] для расчета пространственно-распределенных систем. Например, моделируются процессы диффузии, распространения лесного пожара, эпидемии или раковой опухоли.

В микроэлектронике КА применялись, например, для моделирования процесса травления при получении пористого кремния [11] или процесса термического окисления кремния [12]. Широко применяемые в настоящее время методы, основанные на решении систем дифференциальных уравнений в частных производных, оказываются недостаточно эффективными при моделировании процессов создания структур, размер которых сравним с размерами атомных дефектов поверхности, а также при моделировании многокомпонентных систем [13]. C начала 90-х гг. XX в. появились публикации, посвященные применению КА в топологическом проектировании, например, при исследовании планарных графов в задачах уплотнения упаковки элементов СБИС [14]. В функционально-логическом проектировании приложения КА связаны c созданием встроенных тестовых структур и задачей аппаратной генерации псевдослучайных чисел [15]. Нашли применение КА и в криптографии [16, 17]. Отдельным направлением является разработка на базе КА специализированных микропроцессоров для высокоскоростной обработки графической информации в режиме реального времени [18, 19]; здесь в одно целое связаны алгоритмическая и аппаратная составляющая задачи [20].

Термин «машины клеточных автоматов» (МКА) впервые появился в 1991 г. [21]. МКА является системой автоматизации проектирования клеточных автоматов; задавая правила функционирования клеточного автомата, можно реализовывать ту или иную математическую модель (или просто получать красивые изображения по принципу «искусство ради искусства»). Кроме того, МКА может помогать профессиональному математику формулировать или проверять гипотезы в области теории однородных структур; при некотором расширении МКА можно исследовать структуры фрактального типа.

Уровень сложности данной предметной области благоприятствует использованию UML для разработки МКА. Надо отметить, что в смежных областях уже имеется опыт такого использования - это проблематика искусственного интеллекта [22] и распределенных систем (локальные сети описаны в [23]). Для построения диаграмм нами использовалась свободно распространяемая программа StarUML [24].

Требования, предъявляемые к МКА. Цель разработчика программного обеспечения всегда состояла в предсказании и упреждении потенциальных пожеланий заказчика (пользователя). Можно выделить четыре группы пользователей:

1) обычные пользователи, увлеченные красотой получаемых картинок и качеством анимации [25];

2) специалисты по математическому моделированию, которым важно удобство задания КА, симулирующего физические (или даже социальные) процессы;

3) разработчики распределенных систем, нуждающиеся в наибольшей свободе для выбора нестандартных правил, прежде всего относящихся к топологии КА и усложнению структуры ячейки, включая введение вероятностных мотивов и черт гетерогенности. Тогда КА превращается в мультиагентную систему, что характерно, например, для мультипроцессорных систем;

4) специалисты-математики, пытающиеся экспериментальным путем сформулировать или косвенно подтвердить гипотезы в области теории КА.

Из-за ограниченности вычислительных возможностей компьютера требования разных групп пользователей могут противоречить друг другу. Очевидно, что усложнение структуры ячейки (3-я группа), означающее увеличение памяти, приходящейся на ячейку, от 1 бита, достаточного для симуляции игры Конуэя, до 64 байт, при 3 D-топологии поля размера 256x256x256 повлечет за собой задействование всей оперативной памяти типичного компьютера (1 Гб), а при попытке использования дискового кэша катастрофически упадет быстродействие. При поиске компромисса следует попытаться удовлетворить принципу независимости архитектуры программы от деталей реализации. Заметим, что к настоящему времени созданы несколько МКА, аппаратно реализованные на специализированных многопроцессорных системах ([26, 27] и отчасти [18, 20]).

Для всех групп пользователей, особенно 2-й и 3-й, необходимо предусмотреть расширение МКА на тот случай, когда потребуется вводить информацию непосредственно в КА во время симуляции. Классический подход к КА как к закрытой системе, реализованный в [21] и изначально полагаемый в теории КА, не приводит к успеху при моделировании существенно открытых систем или систем, нацеленных на обработку сигналов (в частности, когда КА рассматривается как объект управления).

При создании информационных систем обычно требуется вначале составить логическую модель предметной области или по крайней мере сформировать ее концептуальный базис. В нашем случае это по большей части, хотя и не полностью, сделано самими математиками при формулировке понятия КА. Основными концептами здесь выступают: ячейка, шаблон соседства, локальная функция переходов, конфигурация [28]. При симуляции частично гетерогенных КА можно говорить об индексах соседства или функции соседства, а также о типах ячеек. Кроме того, при анализе опыта многочисленных программных реализаций игры Конуэя оказываются полезными следующие свойства МКА:

- широкое использование библиотек начальных фигур;

- интерактивное задание начальной конфигурации;

- управление скоростью симуляции;

- интерфейсные шаблоны для визуализации поля КА.

Основное требование к МКА состоит в том, чтобы предоставлять пользователю возможность средствами среды разработчика (IDE) конструировать КА из «кирпичиков» (они комплиментарны упомянутым выше понятиям), выбирать вариант его графического/файлового представления, вычислять общие характеристики его симуляции и, возможно, управлять процессом симуляции.

Конкретизируя это требование для разработчика, можно выделить такие желаемые свойства МКА:

- явное задание структуры ячейки (и ее типа);

- свободное задание 1D-, 2D- и 3D-топологии и сложных топологий (например, на сфере или на поверхности геометрических тел), а также граничных условий для поля КА, в частности его замыкание в рамках одной МКА;

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

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

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

- предоставление библиотек окрестностей и библиотек локальных функций перехода;

- возможность внедрения внешнего кода для локальных функций перехода;

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

- использование для КА различных шаблонов оформления, что особенно критично для 3Б-структур;

- интерфейс для управления процессом симуляции, например останова по требованию или при «гибели» всех ячеек;

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

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

Специальные требования, обусловленные инженерными приложениями. Если КА служит для моделирования многокомпонентной технической системы, при котором каждая ячейка имитирует состояние некоторого типичного элемента (например, элементарного микропроцессорного ядра), то необходимо дополнительно специфицировать структуру ячеек, которая изначально дается недифференцированно. Отметим, что в лабораторных разработках число ядер мультипроцессорной системы доходит до 100 [29]. При этом МКА могли бы оказаться полезными лишь на начальных стадиях проектирования таких систем, дополняя штатные средства моделирования. Инженерные приложения заставляют придавать КА черты частичной гетерогенности.

На рис.1 показана предлагаемая общая архитектура ячейки для инженерных приложений. Состояние ячейки разделяется на три компоненты:

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

- секция R, скрытая от внешнего мира и представляющая собой память ячейки; при этом можно задать универсальную для КА функцию изменения памяти на каждом ходу t симуляции R(t) = f (I(t), D(t), R(t -1)) ;

- секция D, позволяющая получать информацию извне и служащая для управления симуляцией КА; например, если D-часть есть 1 бит, то логической единице соответствует разрешение на исполнение функции перехода, а нулю - запрет на такое исполнение.

Также в структуре ячейки выделим идентификатор и коммуникационный блок. Хотя технически доступ к ячейке можно реализовать через матричный индекс поля КА, предпочтительнее использовать широко применяемый в практике программирования прием индивидуальных ID («каждый объект должен быть именован»). Через тип ячейки можно, например, определять иерархию ячеек, т.е. структурировать КА отношением подчинения. Коммуникационная секция С содержит информацию о типе ячейки и о то-

Идентификационный номер

^ ID В Вход для управления

Я Внутренность ячейки: ее память и функция записи

С У

I Выход для сигналов

Коммуникационная часть: тип ячейки; ,

шаблон окрестности

Рис. 1. Обобщенная структура ячейки клеточного автомата, ориентированная на инженерные приложения

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

Данная спецификация полезна и для частных случаев, не относящихся к инженерным приложениям: симуляции тьюрмитов, симуляции автоматов класса «с памятью», а также при изучении взаимодействия двух «параллельных» KA. Для тьюрмитов на D-уровне сохраняется вектор направления движения, а .R-уровень пуст. Для автоматов с памятью удобно сохранять на .R-уровне вектор предшествующих состояний, т.е. R(t ) = {I (t -1), I (t - 2),...I (t - n)} (n - глубина памяти). Теоретический интерес может представлять моделирование двух параллельных «вселенных» на общем множестве ячеек; в этом случае их связь осуществляется через .R-уровень, а структура ячейки усложняется (в частности, в С-блоке удваиваются шаблоны соседства и указатели на функции перехода).

UML-описание машины клеточных автоматов. Разработка диаграмм велась средствами утилиты StarUML версии 5.0.2.1570 (open source). StarUML™ строго придерживается спецификации UML, разработанной OMG для моделирования программ, максимально соответствуя стандарту UML 1.4 и следуя нотации UML 2.0 на основе устойчивой метамодели. StarUML ™ оперирует файлами в стандартном формате XML и включает много полезных встроенных компонентов с различными функциональными возможностями: генерация исходных текстов на языках программирования, конвертация исходных текстов в модели, импорт файлов Rational Rose, обмен модельной информацией с другими программными средствами, с использованием XMI, поддержка шаблонов проектирования. Все модели, представления и диаграммы, созданные в StarUML™, сохраняются в одном проектном файле.

Стандарт UML 2.0 содержит описание более чем восьми типов диаграмм, здесь приведены лишь наиболее важные из них. Сформулированные выше требования к MKA также предполагают определенный уровень разработанности проблемы, поэтому некоторые особенно сложные аспекты представлены в диаграммах упрощенно (в частности, это относится к трехчленной структуре ячейки).

При разработке MKA нами учтена возможность использования нескольких компьютеров для одновременного проведения вычислений и с этой целью были введены два типа актора (actor) в диаграмму использования (Use Case Diagram): Пользователь и Aд-министратор. Отношение обобщения между ними говорит о том, что Aдминистратор может быть и Пользователем. Варианты использования (рис.2) обозначаются эллипсами, в которых кратко описывается функция системы (или, что примерно то же самое -цель актора). Семантически каждый вариант использования - это некий сценарий взаимодействия между актором и системой.

Создать или выбрать правило перехода можно только, если пользователем определена окрестность, а окрестность может быть выбрана или создана только в случае наличия поля KA. ^оме того, автомат можно считать полностью созданным только при заданном начальном состоянии, но поскольку начальное состояние, вероятно, будет меняться значительно чаще самого автомата, то от пользователя к соответствующему варианту использования проведена отдельная ассоциация. Для моделирования автомата

Рис. 2. Диаграмма использования МКА

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

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

Пользователь взаимодействует с системой через интерфейсы DevelopementEnvironment -среды разработки и Modeller - интерфейс моделирования автомата. Они реализуются пакетом GUI и, таким образом, пользователь взаимодействует с системой только через графический интерфейс пользователя. Пакет GUI может использовать, например, инструментальную библиотеку OpenGL для отображения результатов моделирования.

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

Deploy Controller

Рис.3. Диаграмма классов МКА

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

DeploymentTarget содержит всю функциональность, связанную с конечными вычислителями модели. Например, пакет DeploymentCenter использует интерфейс TargetService (используя интерфейс Connector) для управления запуском вычислений и определения текущего состояния целевой машины. DeploymentTarget использует интерфейс SubAutomata для проведения вычислений, а именно - запускает часть автомата на собственных вычислительных мощностях. Подавтоматы связаны друг с другом по средствам пакета Connector. Определение же того, какая именно часть должна вычисляться подавтоматом производится на основе данных от DeploymentCenter, что выражено отношением зависимости.

Центральный пакет всей системы - Automata. Он реализует все интерфейсы, связанные с логикой работы клеточного автомата. Connector - это интерфейс межпроцессного взаимодействия. Он определяет функции для передачи данных между различными узлами вычислительной сети и среды разработки. Реализует этот интерфейс пакет ConnectionSystem. Через Connector можно соединяться не только с другими компьютерами в сети, но и с другими процессами на текущей машине либо с вычислителями, находящимися, например, на шине PCI. Интерфейс Modeller использует интерфейс AutomataController для управления автоматом - запустить, выполнить n шагов, сохранить состояние и т.д. Их взаимодействие осуществляется так же через интерфейс Connector.

Таким образом, структура системы оказалась достаточно насыщенной (рис.3). На рис.4. приведен фрагмент общей диаграммы классов, детализирующий сам КА.

Почти все классы зависят от типа точки (Point). Точку можно задавать различными способами - в декартовых координатах на двумерной или трехмерной плоскости либо в радиальных/сферических/цилиндрических координатах и все это скрывается в классе Point. Класс Space определяет полностью пространство. Для этого необходимо реализовать две функции, которые преобразуют класс Point в 64-битный индекс массива, в котором будет храниться состояние клетки. При этом класс Space может пользоваться

Рис.4. Представление на диаграмме классов контейнера Automata, в котором реализовано

математическое ядро МКА

данными из класса SpaceConstraints в котором хранятся характеристики пространства, например ширина и высота поля. Класс Neigborhood определяет окрестность каждой отдельно взятой точки. При помощи этого класса можно полностью определять топологию пространства. Например, если необходима топология типа «тор», можно в двумерном пространстве задать для граничных точек окрестности соответствующим образом, причем границы пространства можно определить при помощи класса SpaceConstraints. Класс CellBehavior определяет поведение клеток, а именно правило перехода и инициализацию в зависимости от текущего состояния. Для возможности моделирования частично гетерогенных КА будем считать, что у разных клеток может быть разное поведение. Для того чтобы определить, у какой клетки какое поведение, используется класс-ассоциация CellLocater. CellState - состояние клетки, так же полностью определяется пользователем. Правило перехода использует именно эту структуру для своей работы и пространство состоит из двух массивов состояний StatesArray - для предыдущего состояния (используемого в правиле перехода) и для последующего (генерируемого правилом перехода). Отношения агрегирования, с помеченными кратно-стями, отражают эту ситуацию.

Диаграмма последовательностей (Sequence Diagram) отображает динамику поведения МКА (рис.5). Первый процесс реализован процедурой DoStep(), когда пользователь опосредованно дает команду клеточному автомату сделать шаг симуляции и вызывается соответствующая функция пространства Space. Таким образом запускается глобальная функция перехода. Далее циклически для каждой клетки имеют место процессы 2-11:

- 2: ищется правило перехода при помощи функции класса-ассоциации CellLocater::GetCellByCoords;

- 3: возвращается объект класса c: Cell, отвечающий данным координатам;

- 4: вызывается правило перехода данной клетки Cell::DoStep();

- 5-6: определяются соседние клетки, исходя из имеющегося правила перехода - при помощи функции Neighborhood::GetNeighborhood();

Рис.5. Диаграмма последовательностей для математического ядра МКА

- 7-10: для каждой клетки окрестности считывается ее состояние посредством соответствующих функций класса Space; далее они обрабатываются по предписаниям локальной функции перехода;

- 11: значение текущей ячейки модифицируется.

Таким образом, создание UML-описания является важнейшим шагом в разработке сложных программ, а без продуманной архитектуры такая программа заранее обречена на неудачу при попытках ее дальнейшей модификации. Существующие МКА либо разрабатывались в 90-х гг. закрытыми научными группами и потому недоступны широким кругам пользователей, либо слишком «легкие» с точки зрения функциональности, не позволяя изменять топологию или размерность КА. Авторами ведется работа над созданием МКА SoftCAM. Представленные результаты продемонстрировали удобство применения UML при разработке прикладного обеспечения.

Литература

1. Буч Гради, Рамбо Джеймс, Якобсон Ивар. Язык UML. Руководство пользователя (The Unified Modeling Language: Users Guide). - М.: ДМК Пресс, 2007. - 496 с.

2. Фаулер Мартин. UML. Основы UML. - 3-е изд. - М.: Символ-Плюс, 2006. - 192 с.

3. Трофимов С.А. CASE-технологии. Практическая работа в Rational Rose. - М.: Бином-Пресс, 2002. -288 с.

4. ЛеоненковА. Самоучитель UML 2 (Серия «Самоучитель»). - СПб.: БХВ-Петербург, 2007. - 576 с.

5. Rapicault Pascal, Rigault Jean-Paul. Open implementation of UML meta-model(s) making meta-modeling and meta-programming meet // Lecture Notes in Computer Science. - 2001. - Vol. 2192. - P. 02760278.

6. Chabrol Michelle, Sarramia David. Object oriented methodology based on UML for urban traffic system modeling // Lecture Notes in Computer Science. - 2000. - Vol. 1939. - P. 0425-0440.

7. Casanova Miro, Wallet Thomas, D'Hondt Maja. Ensuring quality of geographic data with UML and OCL // Lecture Notes in Computer Science. - 2000. - Vol. 1939. - P. 0225-0240.

8. Селик Браин, Румбаух Джим. Использование UML при моделировании сложных систем реального времени // ObjecTime Limited & Rational Software Corporation. - URL: http://www.interface. ru/home.asp?artId=4810

9. Talia D., Naumov L. Parallel Cellular Programming for Emergent Computation / Eds. Hoekstra A.G., Kroc J., SlootP.M.A. // Simulating Complex Systems by Cellular Automata. - Spinger, 2010. - P. 357-384.

10. Наумов Л. Метод введения обобщенных координат и инструментальное средство для автоматизации проектирования программного обеспечения вычислительных экспериментов с использованием клеточных автоматов: дис. на соиск. уч. ст. канд. тех. наук. - СПб: изд-во СПбГУ ИТМО, 2007. - 283 с.

11. Than O., Buttgenbach S. Simulation of anisotropic chemical etching of crystalline silicon using a cellular automata model // Sensors and actuators. - P. a, 45(1):85. - 1994. - October.

12. A new simulator for the oxidation process in integrated circuits fabrication based on cellular automata / G. Sirakoulis et al. // Materials Science and Engineering. - 1999. - 7. - P. 631-640.

13. Разработка физических принципов и алгоритмов компьютерного моделирования базовых процессов формирования микроструктур методами вероятностного клеточного автомата / А.Н.Агафонов и др. // Вестн. Сам. гос. техн. ун-та. Сер. Физ.-мат. науки. - 2007. - 1(14). - C. 99-107.

14. Fawaz S. Al-Anzi. Efficient Cellular Automata Algorithms for Planar Graph and VLSI Layout Homotopic Compaction // International Journal of Computing and Information Sciences. - 2003. - Vol. 1, № 1. - paper 1.

15. Cellular Automata Based Test Structures with Logic Folding / Biplab K. Sikdar et al. // Proc. of 18-th Intern. Conf. on VLSI Design (VLSID'05). - 2005 - P. 71-74.

16. Benny Applebaum, Yuval Ishaiy, Eyal Kushilevitz. Cryptography by Cellular Automata or How Fast Can Complexity Emerge in Nature? // «Innovations in Computer Science» (ICS'2010): proc. of Conf. (Beijing, China, January 5-7, 2010). - 2010.

17. Somanath Tripathy, Sukumar Nandi. LCASE: Lightweight Cellular Automata-based Symmetric-key Encryption // International Journal of Network Security. - 2009. - Vol.8, N 2. - P. 243-252.

18. Takeshi Ikenaga. Highly-parallel two-dimensional cellular automaton architecture and its application to real-time image processing. - PhD Thesises - Waseda University, Japan, 2001. - 165 c.

19. Theory and application of cellular automata for pattern classification / Pradipta Maji et al. // Fundamenta Informaticae. - 2003. - N 58. - P. 321-354.

20. Woudenberg M. Using FPGAs to Speed Up Cellular Automata Computations. - Master's thesis for University of Amsterdam, 2006.

21. Тоффоли Т., Марголус Н. Машины клеточных автоматов. - Пер. с англ. - М.: Мир, 1991. - 280 с.

22. UML for behavior-oriented multi-agent simulations / Oechslein Christoph et al. // Lecture Notes in Computer Science. - 2002. - Vol. 2296. - P. 0217-0227.

23. Mirandola Raffaela, Cortellessa Vittorio. UML based performance modeling of distributed systems // Lecture Notes in Computer Science. - 2000. - Vol. 1939. - P. 0178-0194.

24. Документация на сайте разработчиков StarUML. - URL: http://staruml.sourceforge.net/en/ documentations.php

25. Don Hopkins. Fun with Cellular Automata. - URL: http://www.art.net/~hopkins/Don/art/cell.html

26. Legendi T. Cellprocessors in Computer Architecture // Comp. Linguist. and Comp. Languages. -1976. - Vol. 11 - N 2. - P. 147-167.

27. A parallel cellular automata environment on multicomputer for computational science / M.Cannataro et al. // Parallel Computing. - 1995. - Vol. 21. - P. 803-823.

28. Аладьев В.З. Классические однородные структуры. Клеточные автоматы. - CA: Palo Alto, Fultus Corporation, 2009. - 536 c.

29. Интел представляет 80-ядерные процессоры. - URL: http://www.compdoc.ru/comp/cpu/intel-presents-80-nucleus-processors/

Статья поступила 10 июня 2010 г.

Матюшкин Игорь Валерьевич - кандидат физико-математических наук, доцент кафедры проектирования и конструирования интегральных микросхем МИЭТ. Область научных интересов: разработка программного и математического обеспечения в области нанотехнологий и проектирования технологического САПР. E-mail: mivmiv@aport.ru

Хамухин Андрей Владимирович - студент МИЭТ.