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

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

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

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

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

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

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

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

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

В настоящее время на рынке инструментов моделирования информационных систем определились три лидера. Это американские компании 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. Дальнейшие статьи авторы планируют посвятить моделированию различных решений, широко используемых в современных ИС.

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

Объект Объект – осязаемая реальность, имеющая четко определенное поведение. Объект обладает состоянием, поведением, индивидуальностью Структура и поведение схожих объектов определяют общий для них класс => Объект = экземпляр класса Объект = экземпляр класса"> Объект = экземпляр класса"> Объект = экземпляр класса" title="Объект Объект – осязаемая реальность, имеющая четко определенное поведение. Объект обладает состоянием, поведением, индивидуальностью Структура и поведение схожих объектов определяют общий для них класс => Объект = экземпляр класса"> title="Объект Объект – осязаемая реальность, имеющая четко определенное поведение. Объект обладает состоянием, поведением, индивидуальностью Структура и поведение схожих объектов определяют общий для них класс => Объект = экземпляр класса">

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

Различие между классом и объектом Множество объектов со схожими свойствами (состояние, поведение, индивидуальность) = КЛАСС => Каждый объект = экземпляр класса Каждый объект = экземпляр класса"> Каждый объект = экземпляр класса"> Каждый объект = экземпляр класса" title="Различие между классом и объектом Множество объектов со схожими свойствами (состояние, поведение, индивидуальность) = КЛАСС => Каждый объект = экземпляр класса"> title="Различие между классом и объектом Множество объектов со схожими свойствами (состояние, поведение, индивидуальность) = КЛАСС => Каждый объект = экземпляр класса">

Иерархия классов: Родительский класс обладает фи" title="Принципы ООП. Наследование Наследование – принцип, в соответствии с которым знание о более общей категории разрешается применять для более частной категории Наследованиеиерархия классов Наследование -> иерархия классов: Родительский класс обладает фи" class="link_thumb"> 7 Принципы ООП. Наследование Наследование – принцип, в соответствии с которым знание о более общей категории разрешается применять для более частной категории Наследованиеиерархия классов Наследование -> иерархия классов: Родительский класс обладает фиксированным набором свойств => производный от него класс содержит тот же набор свойств + дополнительные свойства, характеризующие его уникальность иерархия классов: Родительский класс обладает фи"> иерархия классов: Родительский класс обладает фиксированным набором свойств => производный от него класс содержит тот же набор свойств + дополнительные свойства, характеризующие его уникальность"> иерархия классов: Родительский класс обладает фи" title="Принципы ООП. Наследование Наследование – принцип, в соответствии с которым знание о более общей категории разрешается применять для более частной категории Наследованиеиерархия классов Наследование -> иерархия классов: Родительский класс обладает фи"> title="Принципы ООП. Наследование Наследование – принцип, в соответствии с которым знание о более общей категории разрешается применять для более частной категории Наследованиеиерархия классов Наследование -> иерархия классов: Родительский класс обладает фи">

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

Принципы ООП. Полиморфизм Полиморфизм (греч. poly – много, morfos – форма) - это свойство некоторых объектов принимать различные внешние формы в зависимости от обстоятельств. Действия, выполняемые одноименными методами, могут отличаться в зависимости от того, к какому из классов относится тот или иной метод.

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

Универсальный язык моделирования UML. Предыстория В начале 90-х гг. 20 века – создание новых объектно-ориентированных языков программирования (Smalltalk, C++, Java) Разработано огромное количество методов проектирования объектно-ориентированного ПО Результат – разработка UML, с целью объединения достоинств различных подходов в один независимый от производителей язык моделирования.

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

Универсальный язык моделирования UML Авторы – Гради Буч (G. Booch), Джим Румбах (или Рамбо, D. Rumbaugh), Айвар Джекобсон (I. Jacobson). Первая версия языка появилась в 1996 г. В настоящее время все вопросы дальнейшей разработки UML сконцентрированы в рамках консорциума OMG. В 2004 г. – UML 2.0.

Диаграммы UML UML включает в себя 8 типов диаграмм: 1) диаграммы вариантов использования; 2) диаграммы классов; 3) диаграммы состояний; 4) диаграммы деятельности; 5) диаграммы кооперации; 6) диаграммы последовательности; 7) диаграммы компонентов; 8) диаграммы развертывания. Диаграммы взаимодействия Диаграммы реализации

Некоторые программные продукты (UML tools) IBM Rational Software Architect (IBM) IBM Rational Rose (IBM) ARIS UML Designer (IDS Sheer) Enterprise Architect (SPARX Software) Altova Umodel KUml, Dia, PowerDesigner И т.д. Подробнее:

Задание Самостоятельно изучить статью «UML basics: An introduction to the Unified Modeling Language»: /library/769.html?S_TACT=105AGX15&S_ CMP=EDU

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

Контрольная работа

" Объектно-ориентированное моделирование на основе UML "

Студент: Филатов Р.Д.

Липецк 2015

Введение

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

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

Унифицированный язык моделирования UML (Unified Modeling Language) представляет собой язык для определения, представления, проектирования и документирования программных систем, информационных систем, организационно-экономических систем, технических систем и других систем различной природы.

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

Создание диаграммы прецедентов

Диаграмма прецедентов (использования) называется диаграмма, на которой показана совокупность прецедентов и актеров, а также отношения (зависимости, обобщения и ассоциации) между ними. Диаграммы прецедентов применяются для моделирования вида системы с точки зрения прецедентов (или вариантов использования). Чаще всего это предполагает моделирование контекста системы, подсистемы или класса либо моделирование требований, предъявляемых к поведению указанных элементов. Этот вид диаграммы позволяет создать список операций, которые выполняет система. Диаграмма этого вида представляет важную информацию - это одно из основных преимуществ ее применения. Взглянув на варианты использования, можно понять, какие функциональные возможности будут заложены в систему. Рассматривая действующих лиц можно выяснить, кто конкретно будет с ней взаимодействовать. Изучая все множество вариантов использования и действующих лиц, определятся сфера применения системы (что она будет делать). Это помогает узнать также, что она не будет делать, и внести коррективы. На диаграмме нашей объектно-ориентированной модели (рисунок А.1) показаны два действующих лица (актера): банковский работник и клиент, а также семь основных действий, выполняемых моделируемой системой: открыть вклад, закрыть вклад, совершить операцию по покупке валюты, отказ по покупке валюты, совершить операцию по продаже валюты, начислить проценты, касса.

Создание диаграммы последовательности

Взаимодействие объектов в системе происходит посредством приема и передачи сообщений объектами-клиентами и обработки этих сообщений объектами-серверами. При этом в разных ситуациях одни и те же объекты могут выступать и в качестве клиентов, и в качестве серверов. Данный тип диаграммы позволяет отразить последовательность передачи сообщений между объектами, акцентирует внимание на временной упорядоченности сообщений. Диаграммы последовательности отражают поток событий, происходящих в рамках варианта использования. Например, вариант использования "Открыть вклад" предусматривает несколько возможных последовательностей, таких как вести вариант вклада или вести неправильный вариант вклада. Ввод данных о открытие вклада представлен на данной диаграмме последовательностей. Под сценарием понимается конкретный экземпляр потока событий. Эта диаграмма последовательности отображает поток событий в рамках варианта использования "Открыть вклад" (рисунок А.2). Проанализировав составные части системы, наглядно видно, что наиболее главная задача работы банковского работника - это ввод данных о вкладах. Получив всю нужную информацию, составляем описание сценариев: Банковский работник создает новый вклад. Банковский работник вводит данные в базу данных. Банковский работник вводит данные в базу данных, но при ее сохранении в базе данных возникает ошибка. Действующее лицо на диаграмме - Банковский работник. Т.к. все взаимодействие в объектно-ориентированных системах осуществляется при помощи сообщений между объектами, то классы должны позволять отправку или прием сообщений. При обмене сообщениями одни классы являются клиентами и принимают сообщения, а другие - серверами и отправляют сообщения. информационный прецедент программный

Создание диаграммы сотрудничества

Диаграммы сотрудничества - второй тип диаграмм взаимодействия -Collaboration Diagram - Г. Буч называет диаграммой объектов. Эта диаграмма не акцентирует внимание на последовательности передачи сообщений, она отражает наличие взаимосвязей вообще, то есть на этой диаграмме отражается наличие сообщений от клиентов к серверам. Диаграмма показывает взаимодействие между объектами, а не классами, то есть является мгновенным снимком объектов системы в некотором состоянии. Ведь объекты, в отличие от созданных на этапе проектирования классов, создаются и уничтожаются на всем протяжении работы программы. И в каждый момент имеется конкретная группа объектов, с которыми осуществляется работа. В связи с этим появляются такие понятия, как время жизни и область видимости объектов, которые будут рассмотрены далее.

Создание диаграммы классов

Class diagram (диаграммы классов) позволяет создавать логическое представление системы, на основе которого создается исходный код описанных классов. На диаграммах классов отображаются некоторые классы и пакеты системы. Это статические картины фрагментов системы и связей между ними. Объединять классы можно как угодно, однако существует несколько наиболее распространенных подходов.

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

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

Наконец, применяют комбинацию двух указанных подходов. Для дальнейшей организации классов разрешается вкладывать пакеты друг в друга. На высоком уровне абстракции можно сгруппировать классы по функциональности, создав пакет Security. Внутри него можно создать другие пакеты, сгруппировав отвечающие за безопасность классы по функциональности или по стереотипу. Ознакомившись с классами модели, объединим эти классы в пакеты по стереотипу. Были созданы следующие пакеты: Entities (Сущности), Boundaries (Границы) и Control (Управление). В эти пакеты были помещены советующие им классы (рисунок А.4).

Классы-сущности (entity classes) отражают основные понятия (абстракции) предметной области и, как правило, содержат хранимую информацию. В данный пакет были добавлены класса Вклад и ВкладВалюты.

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

Граничные классы (boundary classes) - позволяют действующему лицу взаимодействовать с системой. Каждому взаимодействию между действующим лицом и вариантом использования должен соответствовать по крайней мере один граничный класс.

Граничные классы (boundary classes) - это классы, которые расположены на границе системы и окружающей среды. Они включают все формы, отчеты, интерфейсы с аппаратурой (такой, как принтеры или сканеры) и интерфейсы с другими системами.

В данной модели была создана диаграмма классов (рисунок А.4) для сценария "Открыть новый вклад".

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

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

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

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

Литература

1. Боггс У., Боггс М.. UML и Rational Rose: Пер. с англ. - М.: Издательство "Лори", 2009.- 581 с, ил.

2. Буч Г., Рамбо Д., Джекобсон А. Язык UML для пользователя: Пер. с англ. - М.: ДМК, 2009.- 432 е., ил. (Серия "для программистов").

3. Ларман К. применение UML и шаблонов проектирования: Пер. с англ. - М.: Издательский дом "Вильяме", 2012. - 496 с, ил.

4. Кураев Е.А. Банковские системы: Издательский дом "Глория", 2013.-225 с.,ил (Валютные операции с вкладами)

5. Родионова В.М. Банковские операции: Под ред. Родионовой В.М.,2011 .- 112с, ил (Валютные операции с вкладами)

Размещено на Allbest.ru

...

Подобные документы

Использование программы Rational Rose 2000 для моделирования информационной подсистемы учета валютных операций с вкладами физических лиц. Создание диаграмм прецедентов, последовательности и сотрудничества. Основные добавленные атрибуты класса "Вклад".

курсовая работа , добавлен 23.06.2011


Этапы разработки объектно-ориентированной модели информационной подсистемы приемной комиссии для учета абитуриентов. Создание диаграмм для моделирования процесса обмена сообщениями между объектами. Порядок генерации программного кода на языке С++.

курсовая работа , добавлен 29.06.2011


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

курсовая работа , добавлен 25.06.2011


Разработка объектно-ориентированной подсистемы складского учета для фирмы "КавказЮгАвто". Краткая характеристика предметной области. Построение диаграмм размещения, прецедентов, последовательности, компонентов и классов. Генерация программного кода C++.

курсовая работа , добавлен 26.06.2011


Унифицированный язык моделирования. Методы объектно-ориентированного анализа и проектирования. Создание диаграммы последовательности и диаграммы сотрудничества. Главная диаграмма классов. Добавление связей между классами. Зависимость между пакетами.

курсовая работа , добавлен 23.06.2011


Общая характеристика склада как объекта хозяйственной деятельности. Создание диаграммы прецедентов и последовательности. Построение корпоративной диаграммы сотрудничества. Предназначение диаграммы классов и компонентов. Генерация программного кода C++.

курсовая работа , добавлен 23.06.2011


Разработка модели информационной подсистемы для учета заказов клиентов автосервиса с применением языка UML. Создание диаграммы прецедентов, последовательности, сотрудничества и классов, используя методы Rational Rose 2000. Генерация программного кода C++.

курсовая работа , добавлен 22.06.2011


Особенности объектно-ориентированного проектирования. Основные понятия объектно-ориентированного подхода. Основы языка UML, варианты его использования. Диаграммы классов и взаимодействия. Разработка диаграммы прецедентов (вариантов использования).

курсовая работа , добавлен 13.05.2014


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

курсовая работа , добавлен 21.06.2011


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

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

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

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

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

Онтологический инжиниринг возник в середине 90-ых годов в крупных корпорациях, где проблемы обработки информация приобрели особую остроту и стали критическими. Стало очевидным, что основным узким местом в технологиях корпоративного управления является обработка знаний , накопленных специалистами компании, так как именно знания обеспечивают преимущество перед конкурентами. Так появился термин «Управление Знаниями» или «Менеджмент Знаний» (МЗ). МЗ трактуется как совокупность процессов, которые управляют созданием, распространением, обработкой и использованием информации внутри предприятия.

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

· объектно-ориентированный анализ (Object-Oriented Analysis, OOA),

• объектно-ориентированное проектирование (Object-Oriented Design, OOD),

· объектно-ориентированное программирование (Object-Oriented Programming, OOР).

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

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

Для моделирования таких систем UML предоставляет свыше десятка типов диаграмм, моделирующих структуру и функционирование («поведение») объектных систем с разных точек зрения. Моделирование начинается с анализа и моделирования предметной области программной системы и разработки требований её пользователей. Разработанный список требований представляется Use-Case-диаграмами UML. Затем моделируется структура системы в форме «структурных» диаграмм:

Диаграмм классов (Class Diagram),

Диаграмм программных компонентов (Component) и

Диаграмм развёртывания программных компонентов на программно-аппаратной платформе (Deployment Diagram).

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

Алгоритмы взаимодействия программных объектов (Sequential- и Collaboration-диаграммы),

Поведение дискретных объектов (Statechart-диаграммы),

Процессы, протекающие в объектной системе (Activity-диаграммы.

В качестве примера на рис. 36 представлены требования пользователей к электронному книжному магазину (в форме Use-Case-диаграмм системы Rational Rose).

Рис 36. Use Case-диаграммы Rose-проекта eBookShop

Рис. 37. Диаграмма классов предметной области Rose-проекта eBookShop

Рис. 38. Полная статическая модель Rose-проекта eBookShop (в форме UML-диаграммы Классов)

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

Методики объектно-ориентированного моделирования совершили коренной переворот в архитектуре современных информационных систем. На смену традиционной архитектуры алгоритмической обработки данных пришла архитектура, базирующаяся на (объектных) моделях (Model-Driven Architecture, MDA).

ArCon. Дизайн интерьеров и архитектурное моделирование для всех Кидрук Максим Иванович

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

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

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

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

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

Применение объектного подхода дает множество преимуществ.

На порядок возрастает скорость создания планов и чертежей.

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

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

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

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

Рис. 1.1. Пример иерархического представления строительного плана, созданного на основе объектного подхода

Примечание

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

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

Примечание

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

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

В первую очередь (и это очевидно) это ограниченность набора готовых объектов, а также невозможность произвольного их изменения. Это отбирает гибкость у программы, из чего следует, что принцип объектного проектирования может быть применен только в специализированных системах (таких, к примеру, как ArCon, Professional Home Design Platinum и пр.). Разработчикам таких систем необходимо основательно учитывать специфику отрасли, для автоматизации и решения задач которой предназначается программный продукт, а также максимально расширять возможность настройки свойств предлагаемых объектов.

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

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

Примечание

Забегая наперед, скажу, что проекты ArCon+ 2005 можно экспортировать в различные как двухмерные, так и трехмерные форматы, используя группу команд Файл? Экспортировать в формате (рис. 1.2). Важно отметить, что в программе поддерживаются такие известные форматы обмена данных, как VRML, DXF, формат системы 3ds Max, а также возможность сохранения проекта в выполнимый EXE-файл (подробнее об этом написано далее).

Рис. 1.2. Поддерживаемые форматы для экспорта проектов из ArCon

Еще хуже дело обстоит с импортом данных из других систем. Если они не приведены к определенному формату, «взять» их внутрь объектной специализированной системы невозможно. Скажем, при импорте чертежа из AutoCAD в ArCon может быть загружено лишь изображение. При этом ArCon никак самостоятельно не сможет распознать, где в открытом изображении окна, двери, стены и т. п., и тем более присвоить отдельным объектам вполне разумные свойства. Это значит, что дальнейшее редактирование чертежа в ArCon, как и «поднятие» его в 3D, невозможно. Импортирование, по существу, становится бессмысленным, поэтому преимущественное большинство объектно-ориентированных проектных систем не имеют функций для чтения графических данных извне.

Однако, несмотря на такие существенные недостатки, легкость в работе, а главное – скорость и наглядность выполнения проектов берут верх. Как следствие, в последнее время системы, подобные рассматриваемой в этой книге программе ArCon, нашли широкое применение при решении различных задач проектирования.

Из книги Питон - модули, пакеты, классы, экземпляры. автора Бройтман Олег

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

Из книги 3ds Max 2008 автора Верстак Владимир Антонович

Объектно-ориентированное моделирование 3ds Max 2008 – объектно-ориентированная программа, то есть все, что создается в программе, является объектами. Геометрия, камеры и источники света на сцене – это объекты. Объектами также являются модификаторы, контроллеры, растровые

Из книги Эффективное использование C++. 55 верных способов улучшить структуру и код ваших программ автора Мейерс Скотт

Глава 6 Наследование и объектно-ориентированное проектирование Объектно-ориентированное программирование (ООП) существует почти 20 лет, поэтому, вероятно, вы имеете некоторое представление о наследовании, производных классах и виртуальных функциях. Даже если вы

Из книги Основы объектно-ориентированного программирования автора Мейер Бертран

Объектно-ориентированное конструирование ПО У нас уже накоплено достаточно оснований, чтобы попытаться определить ОО-конструирование ПО. Это будет лишь первый набросок, более конкретное определение последует в следующей лекции.ОО-конструирование ПО (определение 1)

Из книги Программирование на языке Ruby [Идеология языка, теория и практика применения] автора Фултон Хэл

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

Из книги VBA для чайников автора Каммингс Стив

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

Из книги Программирование для карманных компьютеров автора Волков Владимир Борисович

Из книги Основы программирования на Java автора Сухов С. А.

11.1. Рутинные объектно-ориентированные задачи Of his quick objects hath the mind no part, Nor his own vision holds what it doth catch… Вильям Шекспир. Сонет 113 Если вы вообще не знакомы с ООП, то эта глава вас ничему не научит. А если вы понимаете, что такое ООП в языке Ruby, то, наверное, ее и читать не стоит.

Из книги C++ для начинающих автора Липпман Стенли

Объектно-ориентированное программирование и VBA В результате своей эволюции Visual Basic превратился в (почти) объектно-ориентированный язык программирования. Хотя освоение приемов работы с объектами и представляет некоторую трудность в начале знакомства с VBA, ожидаемая

Из книги автора

Глава 12. Объектно-ориентированное программирование. В этой главе...~ Концептуализация объектов~ Понимание свойств, методов и событий - главных компонентов VBA-объектов~ Работа с объектными моделями~ Использование форм как объектов~ Выяснение и установка свойств объектов~

Из книги автора

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

Из книги автора

ОБЪЕКТНО-ОРИЕНТИРОВАННОЕ ПРОГРАММИРОВАНИЕ НА JAVA 7. КЛАССЫ Базовым элементом объектно-ориентированного программирования в языке Java является класс. В этой главе Вы научитесь создавать и расширять свои собственные классы, работать с экземплярами этих классов. Напомним,

Из книги автора

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

Из книги автора

Процедурно-ориентированное программирование В части II были представлены базовые компоненты языка С++: встроенные типы данных (int и double), типы классов (string и vector) и операции, которые можно совершать над данными. В части III мы увидим, как из этих компонентов строятся

Из книги автора

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

Из книги автора

17.1.1. Объектно-ориентированное проектирование Из чего складывается объектно-ориентированное проектирование четырех рассмотренных выше видов запросов? Как решаются проблемы их внутреннего представления?С помощью наследования можно определить взаимосвязи между