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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Формальное описание предметной области с использованием UML основывается на иерархической структуре модельных представлений (см. рис. 4.5), состоящей из четырех уровней: 1) мета-метамодели; 2) мегамо- дели; 3) модели; 4) объектов.

Рис. 4.5.

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

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

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

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

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

  • диаграмма вариантов использования (Use Case Diagram );
  • диаграмма классов (Class Diagram );
  • диаграммы поведения (Behavior Diagrams );
  • диаграммы реализации (Implementation Diagrams).

Рис. 4.6.

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

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

  • диаграмма состояния (Statechart Diagram );
  • диаграмма деятельности {Activity Diagram);
  • диаграммы взаимодействия {Interaction Diagrams) :
  • - диаграмма последовательности {Sequence Diagram);
  • - диаграмма кооперации {Collaboration Diagram).

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

  • диаграмма компонентов {Component Diagram);
  • диаграмма развертывания {Deployment Diagram).

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

С точки зрения моделирования бизнес-процессов визуальное моделирование в IJML можно представить как некоторый процесс поуровневого спуска от наиболее общей и абстрактной концептуальной модели исходной системы к логической, а затем и к физической модели соответствующей программной системы. Для достижения этих целей сначала строится модель в форме так называемой диаграммы вариантов использования {Use Case Diagram ), которая описывает функциональное назначение системы или, другими словами, то, что система будет делать в процессе своего функционирования. Диаграмма вариантов использования является исходным концептуальным представлением или концептуальной моделью системы в процессе ее проектирования и разработки.

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

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

Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или акторов, взаимодействующих с системой с помощью так называемых вариантов использования. При этом актором {actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая способна служить источником воздействия на моделируемую систему так, как определит сам разработчик. В свою очередь, вариант использования {use case) служит для описания сервисов, которые система предоставляет актору. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актором. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие акторов с системой.

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

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

Таблица 4.1

Обозначение

Назначение

Вариант использования

f Проверить состояние (текущего счета ) клиента банка

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

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

Интерфейс

Датчик Устройство считывания шрихкода

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

Примечание

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

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

Окончание табл. 4.1

Обозначение

Назначение

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

Отношение ассоциации (association relationship)

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

Отношение расширения (extend relationship)

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

Отношение обобщения (generalization relationship)


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

Отношение включения (include relationship)


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

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


Рис. 4.7.

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

Не вдаваясь в описание семантики языка UML (она хорошо освещена в соответствующей литературе), приведем лишь результаты объектно-ориентированного анализа, показанные на рис. 4.8-4.12.

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


Рис. 4.8.


Рис. 4.9.


Рис. 4.10.


Рис. 4.11.


Рис. 4.12.

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

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

Таблица 4.2

Взаимосвязь объектов диаграмм UML и объектов имитационной модели

Объект диаграммы состояний

Объект имитационной модели

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

Объект диаграммы состояний

Объект имитационной модели

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

· Процедурные языки , которые представляют собой последовательность выполняемых операторов. Если рассматривать состояние ПК как состояние ячеек памяти, то процедурный язык – это последовательность операторов, изменяющих значение одной или нескольких ячеек. К процедурным языкам относятся FORTRAN, C, Ada, Pascal, Smalltalk и некоторые другие. Процедурные языки иногда также называются императивными языками. Код программы на процедурном языке может быть записан следующим образом:

оperator1; operator2; operator3;

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

· function1(function2(

· function3(beginning_date)));

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

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

if condition1 then operator1;

if condition2 then operator2;

if condition3 then operator3;

· Объектно-ориентированные языки , основанные на построении объектов как набора данных и операций над ними. Объектно-ориентированные языки объединяют и расширяют возможности, присущие процедурным и аппликативным языкам. К объектно-ориентированным языкам относятся C++, Object Pascal, Java.

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

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

Классификация ПП средств

Текстовые редакторы - основные их функции - ввод и редактирование текстовых данных.

Графические редакторы - обширный класс программ, предназначенных для создания и обработки графических изображений.

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

Модель натурная, если она есть материальная копия оригинала.

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

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

Есть и другие типы моделей.

Примеры моделей

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

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

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

Основные свойства любой модели:

· целенаправленность;

· конечность;

· упрощенность;

· приблизительность;

· адекватность;

· информативность;

· полнота;

· замкнутость и др.

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

Компьютерное моделирование – основа представления знаний как в компьютере, так и с помощью компьютера и с использованием любой информации, которую можно обрабатывать с помощью ЭВМ.

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

Компьютерное моделирование от начала и до завершения проходит следующие этапы.

1. Постановка задачи.

2. Предмодельный анализ.

3. Анализ задачи.

4. Исследование модели.

5. Программирование, проектирование программы.

6. Тестирование и отладка.

7. Оценка моделирования.

8. Документирование.

9. Сопровождение.

10. Использование (применение) модели.

При моделировании систем ПО выделяют два подхода: структурное моделирование и объектно-ориентированное моделирование. Каждый из этих подходов использует свои методы и средства. Язык моделирования должен включать: элементы модели , т. е. функциональные концепции моделирования и их семантику, нотацию , т. е. визуальное представление элементов моделирования и руководство по использованию . При моделировании широко используются инструментальные средства, называемые Case -средствами. Case -средство – это технология использования и эксплуатации систем ПО. Case -средство – это программное средство, которое поддерживает процессы жизненного цикла ПО . ЖЦ любого ПО – это период времени от принятия решения о необходимости создания ПО до изъятия ПО из эксплуатации. Все процессы ЖЦ ПО делятся на три группы: основные (5), вспомогательные (8), организационные (4). Для разработки моделей ЖЦ используется стандарт (ISO/IEC 12207). Стадия создания ПО – это часть процесса создания ПО, ограниченная временными рамками и заканчивающаяся выпуском конкретного продукта (модели, программы или документации). В состав ЖЦ ПО включают стадии :

1. Формирование требований к ПО

2. Проектирование

3. Реализация

4. Тестирование

5. Ввод в действие

6. Эксплуатация и сопровождение

7. Снятие с эксплуатации.

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

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

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

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

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

Абстракция – это процесс выявления основных характеристик какой-либо сущности, которые отличают ее от других сущностей.

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

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

Иерархия – это ранжирование или упорядочивание системы абстракций. Виды иерархических структур – это структура классов и структура объектов.

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

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

Устойчивость – свойство объекта существовать во времени и/или пространстве.

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

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

Языки моделирования

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

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

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

Объектно-ориентированное программирование

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

Основные концепции ООП

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

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

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

ООП характеризуется следующими принципами (по Алану Кею):

· все является объектом;

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

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

· каждый объект является представителем класса, который выражает общие свойства объектов данного типа;

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

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

Абстрагирование (abstraction) - метод решения задачи, при котором объекты разного рода объединяются общим понятием (концепцией), а затем сгруппированные сущности рассматриваются как элементы единой категории.

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

Инкапсуляция (encapsulation) - техника, при которой несущественная с точки зрения интерфейса объекта информация прячется внутри него.

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

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

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

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

Класс (class) - множество объектов, связанных общностью структуры и поведения; абстрактное описание данных и поведения (методов) для совокупности похожих объектов, представители которой называются экземплярами класса.

Объект (object) - конкретная реализация класса, обладающая характеристиками состояния, поведения и индивидуальности, синоним экземпляра.

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

Основы представления графических данных

Виды компьютерной графики

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

В зависимости от способа формирования изображений компьютерную 2D-графику принято подразделять на растровую, векторную и фрактальную .

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

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

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

Хотя компьютерная графика служит всего лишь инструментом, ее структура и методы основаны на передовых достижениях фундаментальных и прикладных наук: математики, физики, химии, биологии, статистики, программирования и мно­жества других. Это замечание справедливо как для программных, так и для аппаратных средств создания и обработки изображений на компью­тере. Поэтому компьютерная графика является одной из наиболее бурно развивающихся отрас­лей информатики и во многих случаях выступает «локомотивом», тянущим за собой всю компью­терную индустрию.

Растровая графика

Векторная графика

Трехмерная графика

Инженерная графика

Растровая графика

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

Разрешение оригинала;

Разрешение экранного изображения;

Разрешение печатного изображения.

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

Разрешение экранного изображения. Для экранных копий изображения элемен­тарную точку растра принято называть пикселом . Размер пиксела варьируется в зависимости от выбранного экранного разрешения (из диапазона стандартных зна­чений), разрешения оригинала и масштаба отображения.

Мониторы для обработки изображений с диагональю 20-21 дюйм (профессионального класса), как правило, обеспечивают стандартные экранные разрешения 640x480, 800x600, 1024x768, 1280x1024, 1600x1200, 1600x1280, 1920x1200, 1920x1600 точек. Расстояние между соседними точками люминофора у качественного монитора состав­ляет 0,22-0,25 мм.

Для экранной копии достаточно разрешения 72 dpi, для распечатки на цветном или лазерном принтере 150-200 dpi, для вывода на фотоэкспонирующем устройстве 200-300 dpi. Установлено эмпирическое правило, что при распечатке величина разрешения оригинала должна быть в 1,5 раза больше, чем линиатура растра устрой­ства вывода. В случае, если твердая копия будет увеличена по сравнению с ориги­налом, эти величины следует умножить на коэффициент масштабирования.

Разрешение печатного изображения и понятие линиатуры. Размер точки растро­вого изображения как на твердой копии (бумага, пленка и т. д.), так и на экране зависит от примененного метода и параметров растрирования оригинала. При растри­ровании на оригинал как бы накладывается сетка линий, ячейки которой образуют элемент растра . Частота сетки растра измеряется числом линий на дюйм (lines per inch - Ipi ) и называется линиатурой .

Размер точки растра рассчитывается для каждого элемента и зависит от интенсив­ности тона в данной ячейке. Чем больше интенсивность, тем плотнее заполняется элемент растра. То есть, если в ячейку попал абсолютно черный цвет, размер точки растра совпадет с размером элемента растра. В этом случае говорят о 100% заполняемости. Для абсолютно белого цвета значение заполняемости составит 0%. На практике заполняемость элемента на отпечатке обычно составляет от 3 до 98%. При этом все точки растра имеют одинаковую оптическую плотность, в идеале при­ближающуюся к абсолютно черному цвету. Иллюзия более темного тона создается за счет увеличения размеров точек и, как следствие, сокращения пробельного поля между ними при одинаковом расстоянии между центрами элементов растра (рис. 1). Такой метод называют растрированием с амплитудной модуляцией (AM).

Полиграфическое оборудование" href="/text/category/poligraficheskoe_oborudovanie/" rel="bookmark">полиграфического оборудования ; он применяется в основном для художествен­ных работ, при печати с числом красок, превышающим четыре.

Рис.2. Пример использования стохастического растра

Связь между параметрами изображения и размером файла. Средствами растровой графики принято иллюстрировать работы, требующие высокой точности в пере­даче цветов и полутонов. Однако размеры файлов растровых иллюстраций стре­мительно растут с увеличением разрешения. Фотоснимок, предназначенный для домашнего просмотра (стандартный размер 10x15 см, оцифрованный с разрешени­ем 200-300 dpi, цветовое разрешение 24 бита), занимает в формате TIFF с вклю­ченным режимом сжатия около 4 Мбайт. Оцифрованный с высоким разрешением слайд занимает 45-50 Мбайт. Цветоделенное цветное изображение формата А4 занимает 120-150 Мбайт.

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

Рис.3. Эффект пикселезации при масштабировании растрового изображения

Векторная графика

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

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

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

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

Рис. 4. Объекты векторной графики

Математические основы векторной графики

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

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

Прямая линия. Ей соответствует уравнение у = kx + b. Указав параметры k и b, всегда можно отобразить бесконечную прямую линию в известной системе коор­динат, то есть для задания прямой достаточно двух параметров.

Отрезок прямой. Он отличается тем, что требует для описания еще двух парамет­ров - например, координат x1 и х2 начала и конца отрезка.

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

x2+a1y2+a2xy+a3x+a4y+а5 = 0.

Таким образом, для описания бесконечной кривой второго порядка достаточно пятя; параметров. Если требуется построить отрезок кривой, понадобятся еще два параметра.

Кривая третьего порядка. Отличие этих кривых от кривых второго порядка состоит в возможном наличии точки перегиба. Например график функции у = x3 имеет точ­ку перегиба в начале координат (рис. 15.5). Именно эта особенность позволяет сде­лать кривые третьего порядка основой отображения природных объектов в век­торной графике. Например линии изгиба человеческого тела весьма близки к кривым третьего порядка. Все кривые второго порядка, как и прямые, являются частными случаями кривых третьего порядка.

В общем случае уравнение кривой третьего порядка можно записать так:

x3 + а1у3 + а2x2у + a3xy2 + a4x2 + а5y2 + а6xy + a7x + а8y + а9 = 0

Таким образом, кривая третьего порядка описывается девятью параметрами. Опи­сание ее отрезка потребует на два параметра больше.

Рис.5. Кривая третьего порядка (слева) и кривая Безье (справа)

Кривые Безье. Это особый, упрощенный вид кривых третьего порядка (с. рис. 5). Метод построения кривой Безье (Bezier ) основан на использовании пары касатель­ных, проведенных к отрезку линии в ее окончаниях. Отрезки кривых Безье описы­ваются восемью параметрами, поэтому работать с ними удобнее. На форму линии влияет угол наклона касательной и длина ее отрезка. Таким образом, касательные играют роль виртуальных «рычагов», с помощью которых управляют кривой.

Отрезками кривых Безье можно аппроксимировать сколь угодно сложный контур. Наряду с линией другим основным элементом векторной графики является узел (опорная точка). Линии и узлы используются для построения контуров. Каждый контур имеет несколько узлов. Форма контуров в векторных редакторов изменяется путем манипуляции узлами. Это можно сделать одним из следующих способов: перемещением узлов, изменением свойств узлов, добавлением или удалением узлов. В основе всех процедур связанных с редактированием контуров лежит работа с узлами. При выделении узловой точки криволинейного сегмента у нее появляются одна или две управляющие точки, соединенные с узловой точкой касательными линиями. Управляющие точки изображаются черными закрашенными точками. Расположение касательных линий и управляющих точек определяет длину и форму криволинейного сегмента, а их перемещение приводит к изменению формы контура.

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

Любое программирование осуществляется по одному из четырех принципов:

· принцип модульности

· принцип «от общего к частному»

· принцип пошаговости

· принцип структурирования

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

1. размер модуля должен быть ограничен;

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

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

4. входные параметры и результат модуля желательно передавать не через глобальные переменные, а через формальные параметры и результат функции.

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

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

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

· простой последовательности действий;

· конструкции выбора или оператора if;

· конструкции повторения или цикла.

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

· первоначально программа формулируется в виде некоторого неформального действия на естественном языке;

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

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

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

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

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

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

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

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

Структурное программирование - модульное нисходящее пошаговое проектирование алгоритма и структур данных.

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

· объектно-ориентированный анализ (ООА),

· объектно-ориентированное проектирование (ООД),

· объектно-ориентированное программирование (ООП).

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

· удовлетворяет заданным (возможно, неформальным) функциональным спецификациям;

· согласована с ограничениями, накладываемыми оборудованием;

· удовлетворяет явным и неявным требованиям по эксплуатационным качествам и потреблению ресурсов;

· удовлетворяет явным и неявным критериям дизайна продукта;

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

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

Программа - это числовая модель проектируемой системы.(рис. 1.3.1.)

Рис. 1.3.1.

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

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

· условные обозначения - язык для описания каждой модели;

· процесс - правила проектирования модели;

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

Хороший метод проектирования базируется на прочной теоретической основе и при этом дает программисту известную степень свободы самовыражения.

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

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

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


Рис. 1.3.2

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

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

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

PagesCount: integer;

function CompareWithBook(OtherBook: TBook): integer;

procedure ShowTitle;

constructor Create(NewTitle, New

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

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

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

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

Бурное развитие 1980-ые годы.

Главное не процедура или функция, а объект .

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

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

Появились методы объектно-ориентированного анализа и проектирования OOA/OOD. Они позволяют проектировать системы до написания кода, так чтоб проект был задокументирован. С помощью модели можно исправить недочёты без затрат.

2 вида диаграмм:

1) Структурные модели

2) модели поведения

В дальнейшем UML стал использоваться не столько для проектирования ИС, сколько для анализа и перепроектирования БП.

Моделирование бизнеса с помощью UML предполагает построение двух моделей:

1) прецедентная модель (вопрос 16)

2) объектная модель (анализ структурной модели, описывающийся внешней структурой бизнеса и т.д)(вопрос 17).

Прецедентная модель бизнеса

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



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

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

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


Объектная модель бизнеса.

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

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



Виды анализа БП.

Существуют различные классификации видов анализа. Классификация по объекту анализа позволяет выделить:

1. Анализ окружения

~ Анализ макроокружения (Политического, Экономического, технологического)

~ Анализ микроокружения (клиентов, поставщиков, конкурентов)

2. Анализ бизнеса (Продукции, Оборудования, Кадров).

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

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

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

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

· количественный (основан на объективном измерении и дальнейшей обработке количественных параметров)

1) статистический (корреляционный, регрессионный, кластерный)

2) экономический (детерминированный факторный анализ, балансовый)

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

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