Михаил Васильев, Игорь Хомков, Сергей Шаповаленко

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

Ответить на все эти вопросы отнюдь не легко. Еще труднее ответить на них правильно. Анализ корпоративной информационной системы на любом этапе ее существования - сложное дело.

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

Сложность решаемой задачи;

Сложность разработки ИС;

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

Сложность описания отдельных подсистем ИС.

Объективные оценки может дать применение технологий моделирования. Построение модели, ее анализ и получение ответов на вопросы “что будет, если...?” позволяют спрогнозировать поведение ИС в различных ситуациях. Наиболее часто применяются стендовое макетирование и построение компьютерных моделей ИС.

В настоящее время на рынке инструментов моделирования информационных систем определились три лидера. Это американские компании MIL3 (система моделирования OPNET), Make Systems (система NetMaker XA) и CACI Products Company (система COMNET). На рис. 1 приведено главное окно системы OPNET. (В PC Week/RE, № 34/98, с. 36 на рис. 2 приведено окно графического представления результатов в системе OPNET.) Остановимся на одной из этих систем и на подходе, в ней реализованном, подробнее.

Технология моделирования ИС c использованием COMNET III

Очевидный путь моделирования сложных систем состоит в их декомпозиции по древнему принципу Divide et impera (Разделяй и властвуй. - Лат.). Иерархическое представление сложных ИС в виде набора связанных подсистем является ключом к раскрытию ситуации. Полученные в результате такой декомпозиции подсистемы могут быть в свою очередь разделены на подсистемы следующего уровня иерархии и так до бесконечности. Именно возможность декомпозиции сложных систем позволяет нам создавать их модели. Однако на этом пути крайне важно уметь вовремя остановиться.

Конечная стадия процесса декомпозиции определяется низшим уровнем абстракции, применяемым в каждой конкретной модели. Чрезмерно детальное дробление может привести к результату, прямо противоположному ожидаемому: вместо упрощения моделируемой системы можно прийти к ее усложнению, к тому, что называется “за деревьями не видно леса”. Таким образом, правильно выбранный уровень абстрагирования крайне важен для успешного моделирования.

Следующим шагом, облегчающим моделирование сложных систем, является обнаружение и выделение общих абстракций. Предположим, что мы уже выполнили декомпозицию моделируемой ИС и получили некую иерархию сущностей. Так, например, маршрутизатор Cisco 7500 и компьютер NS7000, снабженный несколькими сетевыми платами и выполняющий программную маршрутизацию, могут быть рассмотрены и как два совершенно разных объекта, и как два объекта, принадлежащие к одному и тому же классу маршрутизаторов. Декомпозиция системы с помощью метафоры классов в сочетании с корректно выбранным уровнем абстракции позволяет радикально упростить построение модели ИС.

Рис. 1. Главное окно системы OPNET

Обычно рассматривается два основных вида декомпозиции: алгоритмическая, разделяющая исследуемую систему по ее активным началам, т. е. протекающим в ней процессам в определенном порядке, и объектно-ориентированная, позволяющая разделить исследуемую систему на классы однотипных абстракций. Оба типа декомпозиции нашли свое применение в COMNET III.

Подход к построению моделей в COMNET III может быть представлен в виде стандартной последовательности шагов:

Описание топологии ИС и определение параметров оборудования;

Описание источников трафика и их поведения, описание загрузки сети;

Определение сценария моделирования.

Определение топологии ИС и связей источников трафика с узлами топологии представляет идеальное поле для применения объектно-ориентированной декомпозиции. Для описания поведения источников трафика и изменений загрузки сети во времени необходима алгоритмическая декомпозиция.

Как уже говорилось, граничные условия для декомпозиции ИС зависят от требуемого уровня абстракции. Абстрагирование позволяет разработчику, создающему проект ИС, или системному администратору, осуществляющему ее сопровождение, отделить наиболее существенные особенности ее поведения от того, как именно они реализуются. “Хорошей является такая абстракция, при которой подчеркиваются существенные для рассмотрения и использования детали и опускаются те, которые на данный момент несущественны или отвлекают внимание”*1. Так, в одной ситуации при описании компьютера достаточно определить его как источник трафика, не вдаваясь в подробное описание архитектуры, в другой же может потребоваться детальное рассмотрение таких его характеристик, как, скажем, количество процессоров и параметров дисковой подсистемы.

*1. Shaw M. Abstraction Techniquest in Modern Programming Languages. - IEEE Software, Oct. 1984, v. 1(4), p.10.

В системе COMNET полностью применим объектно-ориентированный метод декомпозиции, что позволяет существенно сократить сроки моделирования и сделать его процесс интуитивно-понятным, четко коррелирующим с реальной системой. Модель создается из объектов, своего рода “строительных блоков”, знакомых пользователю из опыта реальной жизни. С системой COMNET поставляется большая библиотека таких объектов - моделей реального сетевого оборудования и методов доступа к среде. Рассмотрим подробнее объектную модель COMNET (рис. 2).

Рис. 2. Базовая библиотека классов COMNET III

Объекты в этой системе могут быть разделены на два класса: используемые, во-первых, для описания топологии и, во-вторых, для описания трафика и характеристик загрузки сети. Базовый экран COMNET III с набором библиотечных классов приведен на рис. 3.

Рис. 3. Основной экран системы COMNET

Описание топологии в COMNET III

Такие основные понятия топологии в системе COMNET III, как узлы, соединения, дуги, были описаны в PC Week/RE, № 34/98, с. 34.

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

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

Класс узлов наследуют четыре новых класса.

Класс “Компьютер и узел связи” (C&C Node, Computer and Communications Node)

Эти объекты могут служить источниками или приемниками трафика, а также применяются для моделирования сложных программных систем, учитывающих загрузку процессора и дисковых подсистем. Узлы ИС, описанные с помощью C&C Node, могут быть использованы и для моделирования программных маршрутизаторов.

Класс “Группа компьютеров” (Computer Group Node)

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

Класс “Маршрутизатор” (Router Node)

Объекты этого типа применяются для моделирования аппаратных маршрутизаторов. Так же как и C&C Node, Router Node может выступать и источником, и приемником трафика, выполнять приложения, использующие аппаратные ресурсы узла (процессоры, дисковые подсистемы). Для более детального описания аппаратной реализации моделируемых объектов введен ряд дополнительных свойств, таких, как наличие и параметры внутренней шины, что позволяет моделировать внутреннее прохождение трафика между входными и выходными портами объекта.

Класс “Коммутатор” (Switch Node)

Объекты типа Switch Node, обладая возможностью маршрутизации, служат для моделирования коммутаторов, затрачивающих на передачу трафика между внутренними портами ничтожно малое время. Однако эти объекты, в отличие от трех предыдущих, не могут быть использованы ни как источник, ни как приемник трафика.

Объекты классов C&C Node, Computer Group Node и Router node для моделирования сложных программных систем включают репозиторий команд, использующих такие уже упомянутые свойства объектов, как характеристики дисковой подсистемы. В постоянно обновляющуюся библиотеку объектов различных классов, входящих в состав COMNET, включен широкий спектр моделей реально существующих аппаратных устройств.

Объект link наследует два новых объекта.

Класс “Соединение точка - точка” (Point-to-Point Link)

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

Класс “Множественный доступ” (Multiaccess link)

Полем для применения этого класса являются ситуации, когда несколько узлов имеют доступ к одной среде передачи данных. В свою очередь, этот объект наследуется рядом новых объектов, описывающих конкретные факты реализации метода доступа к среде, такие, как Carrier Detection, Token Passing, SONET и т. п. (см. рис. 2).

До сих пор мы рассматривали случаи, когда родительский объект наследуется одним объектом-потомком. Однако объектно-ориентированный подход предусматривает и более сложные ситуации с множественным наследованием. Эта форма наследования также применима в системе COMNET. Здесь множественное наследование использовано при создании объектов таких важных классов, как Транзитная сеть (Transit Network) и “Облако” (WAN Cloud).

Оба класса являются наследниками двух родительских классов - Subnet и Link. Форма наследования изображена на рис. 2. Рассмотрим этот вариант подробнее.

Класс “Подсеть” (Subnet)

Исключительно важный класс. Используемый для создания иерархических топологий ИС, он позволяет корректно описывать подсети с различными алгоритмами маршрутизации, причем независимые от алгоритма, применяемого на магистрали. Кроме того, подсети используются, чтобы скрыть излишнюю детализацию при моделировании сложных ИС. В COMNET с их помощью описываются системы с произвольной глубиной вложения. Соединения между внутренней топологией подсети и топологией магистрали осуществляются с помощью точек доступа (access points), число которых может быть произвольным (см. рис. 3).

Класс “Транзитная сеть” (Transit Net)

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

Класс “Облако” (WAN Cloud)

Объекты этого класса, позволяющие создавать абстрактные представления для глобальных сетей, также наследуют свойства объектов-родителей - Subnet и Link. С точки зрения топологии объект WAN Cloud функционирует подобно объекту “соединение”, его пиктограмма подключается непосредственно к узлам. С точки зрения внутренней структуры облако состоит из набора виртуальных соединений (virtual circuit) и каналов доступа (access links), разновидности соединения точка - точка для моделирования глобальных сетей.

Описание трафика и загрузки сети в COMNET III

Как мы уже говорили, модель ИС в COMNET включает в себя две части: описание топологии системы и описание источников трафика и загрузки сети. Мы рассмотрели базовый спектр объектов, связанных с топологией. Теперь обратимся к объектам, описывающим трафик.

COMNET предоставляет широкий спектр средств для описания трафика.

Класс “Сообщение” (Message)

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

Класс “Отклик” (Response)

Объекты этого класса могут быть использованы только для посылки ответных сообщений. Они управляются приходами сообщений, созданных объектами классов Message или Response. Получателем сообщений класса Response всегда будет объект класса Node, к которому подключен источник управляющих сообщений (класса Response или Message).

Класс “Вызов” (Call)

Объекты класса Call применяются для создания моделей сетей с коммутацией каналов. Источник вызова описывается набором таких параметров, как закон распределения, длительность и, с учетом класса маршрутизации, требований к пропускной способности.

Класс “Сессия” (Session)

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

Отметим также, что в COMNET III применяются так называемые файлы описания внешнего трафика (external traffic files), получить которые можно с помощью различных анализаторов трафика.

Особый интерес представляют объекты класса “Приложение” (Application), являющегося результатом множественного наследования классов Message, Response, Call и Session (см. рис. 2). Его объекты позволяют наиболее гибко описывать в рамках модели рабочую загрузку сети и поведение источников трафика. Более того, при их использовании могут быть легко смоделированы практически любые виды программных систем, в том числе распределенных, таких, как СУБД, почтовые системы и пр.

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

В репозитории команд узла, а следовательно, и в объекте класса Application могут содержаться следующие команды:

Transport Message (передать сообщение). Эта команда представляет собой результат наследования объекта классом Application родительского объекта класса Message.

Setup (установить) - результат наследования класса Session.

Answer Message (ответить на сообщение) является наследником класса Response.

Filter Message (фильтровать сообщения). Эта команда позволяет приостановить все операции, описанные в объекте класса Application, до тех пор, пока не будет получено сообщение, удовлетворяющее условиям фильтрации.

Process (обработка). С помощью этой команды осуществляется моделирование обработки, вызывающей загрузку процессора.

Read и Write (чтение и запись). Две эти команды также позволяют моделировать занятость процессора узла, но уже в контексте взаимодействия с дисковой подсистемой чтения и записи файлов.

Таким образом, с помощью классов Application, Message, Response, Session и Call возможно как гибкое моделирование текущей загрузки сети, так и детальное описание поведения программных систем, входящих в состав ИС. Исключительно важно, что эти классы позволяют моделировать сложные распределенные программные системы и их влияние на существующую сетевую инфраструктуру сети.

Объекты COMNET III: параметрическое абстрагирование

Говоря о базовом наборе классов COMNET III, крайне важно упомянуть о применимости к ним так называемого параметрического абстрагирования. Этот подход позволяет создавать новые объекты - экземпляры класса с различными свойствами. Такие важные технологические решения, как, скажем, Gigabit Ethernet, могут быть очень просто смоделированы путем изменения параметров рассматриваемой абстракции - свойств выбранного класса.

Рассмотрим пример. Допустим, мы моделируем локальную сеть, использующую на MAC-подуровне случайный метод доступа с контролем несущей и определением коллизий (CSMA/CD, класс соединений с множественным доступом), однако стандарт канального уровня, предложенный производителем сетевого оборудования, несколько отличается от “родного” IEEE 802.3. Подобная ситуация при использовании продукта, не реализующего объектно-ориентированный подход, могла бы вызвать некоторые неточности. Разработчик был бы вынужден использовать стандарт, предлагаемый производителем продукта, вероятнее всего - классический 802.3. На рис. 4 изображено интерфейсное окно COMNET III, с помощью которого пользователь может редактировать параметры этого стандарта - количество ретрансмиссий в случае обнаружения коллизий, длину заголовка кадра и т. д. Иными словами, пользователь сам осуществляет параметризацию объекта.

Рис. 4. Параметризация соединения 10BaseT стандарта IEEE 802.3

Итак, мы решаем вопрос о соответствии эталонного стандарта и стандарта производителя. Дальнейшие наши действия сводятся к тому, чтобы пополнить библиотеку объектов класса CSMA/CD новым стандартом, который определил пользователь. Для этого достаточно добавить новые параметры. Аналогично мы можем поступить с аппаратными узлами, источниками трафика, параметрами WAN Cloud и т. д.

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

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

Режим “Копирование-вставка внешней модели” (Intermodel copy-paste)

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

В дальнейшем вся проблема состоит в том, чтобы объекты из одной модели перенести в другую. Для решения удобно пользоваться режимом COMNET III Intermodel copy-paste (копирование - вставка внешней модели), обеспечивающим перенос из модели в модель вновь создаваемых объектов со всеми свойствами за исключением тех, которые локальны для модели-источника.

Приведем пример. Допустим, мы переносим из одной модели в другую фрагмент сети, имеющий некоторую загрузку. Трафик описывается объектами класса Message. Свойством таких объектов, локальным для модели-источника, является его направленность (destination). Остальные свойства будут перенесены без изменений из объектов, наследующих классы Node (C&C node, Computer group, Router, Switch), Link и др., не привязанных к модели-источнику.

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

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

Модульное построение узлов

Рассмотрим процедуру создания объекта нового класса на основе множественного наследования.

Предположим, перед разработчиком ставится задача построения подробной модели аппаратного устройства (например, маршрутизатора, несколько интерфейсных модулей которого объединены интерфейсной шиной). Целью построения модели является определение задержки на интерфейсной шине. В стандартном описании COMNET III шина описывается двумя параметрами: пропускной способностью и частотой. Ясно, что такого описания нам недостаточно. Однако в нашем распоряжении есть объект, позволяющий описать шину как отдельное устройство, - соединение. В общем-то это не совсем стандартное решение, но, проведя необходимую параметризацию объекта класса Link, мы получим модель шины как полнофункционального устройства, реализующего, например, функцию арбитража. Изображенный на рис. 5 объект MPRouter смоделирован именно таким способом. Интерфейсная шина здесь работает по алгоритму Token Bus.

Рис. 5. Параметризация источника трафика при переносе

фрагмента модели в другую модель (Session Source)

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

Возможность задания состояний объектов

Любой объект в COMNET может находиться в нескольких состояниях. К примеру, для объектов классов Link и Node возможны состояния up, down, failure (включен, выключен, ошибка). Можно также моделировать переходы между этими состояниями и анализировать влияние перехода на моделируемую ИС (рис. 6).

Рис. 6. Определение параметров текущего состояния объекта (Node Properties)

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

Итак, мы рассмотрели основные инструменты и наиболее общие методики построения моделей в COMNET III. Дальнейшие статьи авторы планируют посвятить моделированию различных решений, широко используемых в современных ИС.

7. Геометрическое моделирование. Виды систем моделирования. Внутреннее представление моделей.

Геометрическое моделирование.

Можно выделить 2 задачи:

1.Построение геометрической модели уже существующего тела.

2.Синтез геометрической модели нового объекта.

При решении 1-ой задачи требуется задание большого количества точек, принадлежащих поверхности объекта. При решении 2-ой задачи геометрическое моделирования, выполняемого в интерактивном режиме основное требование к средствам формирования и представления геометрической модели – удобство манипулирования моделью. Выделяют 3 вида геометрических моделей: каркасные, поверхностные, твёрдотельные.

Каркасная модель представляет собой мн-во вершин и мн-во рёбер, объединяющих данные вершины.

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

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

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

Поверхностная модель объекта представляет собой “скорлупу”, внутри которой пустота, из-за этого возникают проблемы при разбиении объекта на конечные элементы при просчёте масс-инерционных хар-к и при контроле взаимопроникновения деталей в сборке. Поверхностного моделирование явл. Кропотливым процессом – требует знаний по начерт.геом. и развитого пространственного мышления.

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

построение скруглений, построение отверстий на гранях, построение рёбер жёсткости, построение фасок.

Твёрдотельная модель хранится в САПР в виде дерева построения.

Преимущество твёрдотельного моделирования:

1.Простота параметризации.

2.Возможность расчёта масс-инерционных хар-к и разбивка на сетку конечных элементов.

3.Относительная простота моделирования.

Недостаток: ограниченность конструктивных форм создаваемых моделей.

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

1 стр-ра представляет собой дерево , опис-щее историю прим-я булевских операций к примитивам. Журнал операций называется конструктивным пред­ставлением объемной геометрии (Constructive Solid Geometry – CSG representation ). Дерево называется деревом CSG (GSG tree ).

2 стр-ра содержит сведения о границах объема (вершинах, ребрах, гранях и их соединении друг с другом). Это представление называется граничным представлением (boundary representation – В- rep ), а структура данных – структурой B - rep (B - rep data structure ).

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

Моделирование - один из основных методов познания, который очается в выделении из сложного явления (объекта) некоторых чаcтей и нении их другими объектами, более понятными и удобными для ания, объяснения и разработки.

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

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

Геометрическое моделирование раздел математического

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

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

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

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

Этапы геометрического моделирования:

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

Разработка геометрического алгоритма решения поставленной задачи;

Реализация алгоритма при помощи инструментальных средств:

Анализ и интерпретация полученных результатов. Методы геометрического моделирования:

Аналитический:

Графический;

Графический, с использованием средств машинной графики:

Графоаналитические методы.

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

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

8. Графические языки высокого уровня.

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

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

автоматизация программирования для оборудования с ЧПУ;

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

системы геометрического моделирования.

Одним из первых проблемно-ориентированных языков, имеющих средства для описания геометрической информации, явился язык АРТ (AUTOMATED PROGRAMMING TOOLS). Этот язык послужил основой для разработки разнообразных систем автоматизации программирования для станков с ЧПУ.

В качестве примеров систем с автономным языком высокого уровня могут также служить системы геометрического моделирования трехмерных тел – COMPAC и СИМАК-Д.

Система COMPAC (COMPUTER ORIENTED PART CODING) предназначена для формирования описания объемных тел из объемных элементов формы – (метод конструктивной геометрии). Кроме трех базовых объемных элементов (кубы, цилиндры, конусы), могут использоваться профилированные детали, получаемые перемещением замкнутого контура вдоль прямой или дуги, а также тела вращения, получаемые вращением замкнутого контура вокруг оси. Элементы задаются, позиционируются и оразмериваются языковыми конструкциями, напоминающими АРТ. Составление детали из объемных элементов производится с помощью операций объединения, вычитания и отсечения.

Отличия СИМАК-Д от COMPAC состоят в несколько ином входном языке и ином наборе базовых элементов формы, включающем в себя точку, плоскость, прямоугольный параллелепипед, круговые цилиндры и конус.

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

довольно значительные затраты на создание языка и транслятора с него;

затраты на внедрение, на включение языка в работающую систему программирования и на обучение пользователей, которые не всегда охотно берутся за изучение еще одного языка, а предпочитают пользоваться процедурными расширениями известных им алгоритмических языков: ALGOL, FORTRAN, PL-1, PASCAL и т.д.;

трудности с последующим расширением языка;

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

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

9. Объектно-ориентированное моделирование.

Объектно-ориентированное моделирование (feature - based modeling ) позволяет конструктору создавать объемные тела, используя привычные элементы форм (features ). Созданное тело несет в себе информацию об этих элементах в допол­нение к информации об обычных геометрических элементах (вершинах, ребрах, гранях и др.). Например, конструктор может давать команды типа «сделать от­верстие такого-то размера в таком-то месте» или «сделать фаску такого-то раз­мера в таком-то месте», и получившаяся фигура будет содержать сведения о на­личии в конкретном месте отверстия (или фаски) конкретного размера. Набор доступных в конкретной программе элементов формы зависит от спектра приме­нения этой программы.

Большинством систем объектно-ориентированного моделирования поддержива­ются такие элементы, которые используются при изготовлении деталей: фаски, отверстия, скругления, пазы, выемки и т. д. Такие элементы называются произ­водственными , поскольку каждый из них может быть получен в результате кон­кретного процесса производства. Например, отверстие создается сверлением, а выемка – фрезерованием. Следовательно, на основании сведений о наличии, размере и расположении производственных элементов можно попытаться авто­матически сформировать план технологического процесса. Автоматическое пла­нирование технологического процесса, если оно будет разработано на практиче­ском уровне, перебросит мост между CAD и САМ, которые в настоящий момент существуют отдельно друг от друга. Таким образом, в настоящий момент лучше моделировать объекты, подобные изображенному на рис. 5.20, с использованием команд объектно-ориентированного моделирования «Выемка» и «Отверстие», а не просто булевских операций. Модель, созданная при помощи таких команд, облегчит планирование технологического процесса, если не сделает его полно­стью автоматическим. Использование производственных элементов в моделиро­вании иллюстрирует рис. 5.21.

Один из недостатков объектно-ориентированного моделирования заключается в том, что система не может предоставить все элементы, нужные для всех возмож­ных приложений. Для каждой задачи может потребоваться свой набор элементов. Чтобы исключить этот недостаток, большинство систем объектно-ориентирован­ного моделирования поддерживают какой-либо язык, на котором пользователь при необходимости может определять свои собственные элементы. После опре­деления элемента необходимо задать параметры, указывающие его размер. Эле­менты, как и примитивы, могут быть разного размера, а задаются размеры пара­метрами в момент создания элемента. Создание элементов разного размера путем присваивания различных значений соответствующим параметрам является раз­новидностью параметрического моделирования.

Дисциплина «Лингвистическое и программное обеспечение САПР» (Беспалов В.А.)

Понятие автоматизации проектирования и его лингвистического обеспечения

Базовое и управляющее лингвистическое обеспечение.

Организация диалога в САПР, средства обеспечения диалогового режима.

Принципы организации трансляторов.

Обобщенная структура компилятора.

Синтаксический анализатор.

Языки проектирования и программирования.

Основы теории языков и формальных грамматик.

Способы записи синтаксиса языка. Организация лексического анализа.

Принципы работы лексических и синтаксических анализаторов.

Понятие автоматизации проектирования и его лингвистического обеспечения.

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

ЛО САПР – совокупность языков, терминов, определений, необходимых для выполнения автоматизированного проект-я. ЛО имеет место наряду с: техническим, математическим, информационным, программным, методическим и организационным обеспечением САПР. Основу ЛО САПР составляют спец. языковые средства (языки проектирования), предназначенных для описания процедур автоматизир. пр-я и проектных решений. Обычно они наз-ся проблемно-ориентированными языками (ПОЯ). 2 вида построения ПОЯ:

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

2. ПОЯ соединяет в себе средства алгоритмического языка со специальными языковыми средствами моделирования геометрических объектов.

ПОЯ представляет из себя комплексы лингвистических и программных средств, кот. должны включать след. элементы:

набор терминальных символов ПОЯ

интерпретатор ПОЯ

средства синтаксического анализа

средства пакетирования директив

библиотеки базовых функций ПОЯ

интерфейс для связи с СУБД

Интерпритатор- программа или устройство, осуществляющее пооператорную трансляцию и выполнение исходной программы.

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

Базовое и управляющее лингвистическое обеспечение.

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

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

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

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

... » Рассматриваются вопросы построения подсистемы САПР метеорологической поддержки (МП... практических занятий по дисциплине «концепции современного... интеллектуального анализа данных. Интеллектуальный анализ, параллельные алгоритмы, интеллектуальный ...

При разработке программного обеспечения существует несколько подходов к моделированию. Важнейшие из них – алгоритмический (структурный) и объектно-ориентированный.

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

Наиболее современным подходом к разработке программного обеспечения яв­ляется объектно-ориентированный. Здесь в качестве основного строительного блока выступает объект или класс. В самом общем смысле объект - это сущность, обычно извлекаемая из словаря предметной области или решения, а класс явля­ется описанием множества однотипных объектов. Каждый объект обладает иден­тичностью (его можно поименовать или как-то по-другому отличить от прочих объектов), состоянием (обычно с объектом бывают связаны некоторые данные) и поведением (с ним можно что-то делать или он сам может что-то делать с други­ми объектами).

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

Если принять объектно-ориентированный взгляд на мир, необходимо отве­тить на ряд вопросов. Какая структура должна быть у хорошей объ­ектно-ориентированной архитектуры? Какие артефакты должны быть созданы в процессе работы над проектом? Кто должен создавать их? И, наконец, как оценить результат?

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

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

Технология разработки программных систем, в основу которых положена парадигма представления окружающего мира в виде объектов, являющихся экземплярами соответствующих классов, получила название - объектно-ориентированный анализ и проектирование (ООАП) - OOA&D (Object-Oriented Analysis/Design). В рамках этой технологии язык UML является средством графического представления результатов моделирования не только программного обеспечения, но и более широких классов систем и бизнес-приложений, с использованием объектно-ориентированных понятий. При этом явным образом обеспечивается взаимосвязь между базовыми понятиями для моделей концептуального и физического уровня, достигается масштабируемость моделей, что особенно важно для сложных многоцелевых систем.

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

Языки объектно-ориентированного моделирования стали появляться между серединой 1970-х и концом 1980-х годов, когда началась разработка подходов к объектно-ориентированному анализу и проектированию (ООАП) систем. К середине 1990-х годов некоторые из методов были существенно улучшены. Известными в этот период становятся: метод Гради Буча (Grady Booch - Воосh"93); метод Джеймса Румбаха (James Rumbaugh - Object Modeling Technique); метод Айвара Джекобсона (IvarJacobson- Object Orienter Software Engineering).

История языка UML (Unified Modeling Language) берет начало с октября 1994 года, когда Буч и Румбах из Rational Software Согрогаtion начали работу по |унификации своих методов. Проект так называемого унифицированного метода версии 0.8 был подготовлен и опубликован в ноябре 1995 года. Осенью того же года к ним присоединился Джекобсон, главный технолог из компании ObjectoryАВ (Швеция), с целью интеграции своего метода ООSЕ с двумя предыдущими.

В этот период поддержка разработки языка UML становится одной из целей консорциума OMG (Object Management Group) – образован в 1989 году. Язык UML приобретает статус второго стратегического направления в работе OMG. Усилия Г. Буча, Дж. Румбаха и А. Джекобсона привели к появлению документов, содержащих описание собственно языка UML версии 0.9 (1996 г.)

Rational Software Согрогаtion вместе с несколькими организациями, изъявили желание выделить ресурсы для разработки строгого определения языка UML, учредила консорциум партнеров UML В январе 1997 года опубликован документ с описанием языка UML 1.0.

Из более чем 800 компаний и организаций, входящих в настоящее время в состав консорциума OMG, особую роль продолжает играть Rational Software Согрогаtion, которая стояла у истоков разработки языка UML. Эта компания разработала и выпустила в продажу одно из первых инструментальных СА8Е-средств Rational! Rose 98, в котором была реализована нотация различных диаграмм языка UML. В феврале 2003 г. компания Rational Software Согрогаtion была приобретена IBM, и с этого момента она имеет официальное название IBM Rational Software.

В настоящее время все вопросы дальнейшей разработки языка UML скон­центрированы в рамках консорциума OMG. Соответствующая группа специалистов обеспечивает публикацию материалов, содержащих описание последующих версий языка UML. Очередной этап развития данного языка закончился в марте 1999 года, когда консорциумом OMG было опубликовано описание языка UML 1.3. Следующей версией языка UML стала версия 1.5, специфицированная в марте 2003 г. В 2004 г. вышла версия UML 2.0.

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

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

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

диаграмма вариантов использования (use case diagram)

диаграмма классов (class diagram)

диаграммы поведения (behaviorг diagrams)

диаграммы взаимодействия (interaction diagrams)

диаграмма кооперации (collaboration diagram)

диаграмма последовательности (sequence diagram)

диаграмма состояний (statechart diagram)

диаграмма деятельности (activity diagram)

диаграммы реализации (implementation diagrams)

диаграмма компонентов (component diagram)

диаграмма развертывания (deployment diagram)

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

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

Диаграмма классов – статическая структура модели системы в терминологии классов ООП

Диаграмма кооперации – структурный аспект взаимодействия объектов системы через передачу и прием сообщений

Диаграмма последовательности – временной аспект взаимодействия объектов системы

Диаграмма состояний – описание поведения системы в терминах переходов и состояний

Диаграмма деятельности – моделирование процесса выполнения операций (частный случай диаграммы состояний)

Диаграмма компонентов – описание физического представления системы, определяющее ее архитектуру (первая из двух диаграмм реализации)

Диаграмма развертывания – представление общей конфигурации и топологии распределенной системы (вторая из двух диаграмм реализации)

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

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

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

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

Концептуальной основой является объектная модель, которая строится с учетом следующих принципов:

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

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

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

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

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

Диаграмма (Diagram) - это графическое представление множества элементов. Чаще всего она изображается в виде связного графа с вершинами (сущностями) и ребрами (отношениями) и представляет собой некоторую проекцию системы.

Объектно-ориентированный подход обладает следующими преимуществами:

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

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

Сравнение существующих методик

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

Несомненным достоинством функциональных моделей является реализация структурного подхода к проектированию ИС по принципу "сверху-вниз", когда каждый функциональный блок может быть декомпозирован на множество подфункций и т.д., выполняя, таким образом, модульное проектирование ИС . Для функциональных моделей характерны процедурная строгость декомпозиции ИС и наглядность представления.

При функциональном подходе объектные модели данных в виде ER-диаграмм "объект - свойство - связь" разрабатываются отдельно. Для проверки корректности моделирования предметной области между функциональными и объектными моделями устанавливаются взаимно однозначные связи.

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

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

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

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

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

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

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