УДК 681.3 ББК 32.973 Г47

Г47 Гладцын В. А., Яновский В. В. Средства моделирования вычислительных сетей: Учеб. пособие. СПб.: Изд-во СПбГЭТУ

"ЛЭТИ", 2001. 128 с. ISBN 5-7629-0405-9

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

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

УДК 681.3 ББК 32.973

Рецензенты: кафедра цифровой вычислительной техники и информатики Санкт-Петербургского государственного университета телекоммуникаций; д-р техн. наук проф. Н. В. Егоров (СПбГУ).

Утверждено редакционно-издательским советом университета

в качестве учебного пособия

2

Введение

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

Для удовлетворения современных требований к сетевой инфраструктуре она должна поддерживать следующие сетевые приложения и сервис:

•интегрированную передачу голосовых, видео- и цифровых данных;

•создание виртуальных локальных и частных сетей;

•управление сетью на основе правил;

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

•учет используемых ресурсов;

•управление пользователями;

•передачу многоадресного трафика;

•построение сетей Internet, Intranet, Extranet.

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

Интеллектуальная сеть предоставляет широкий выбор услуг и механизмов для обеспечения работы деловых приложений посредством реализации службы каталогов, разнообразных сетевых сервисов (коммутация, виртуальные локальные и частные сети, сети Frame Relay и ATM, правила доступа, защита, качество обслуживания, учет использования ресурсов).

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

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

3

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

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

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

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

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

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

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

4

1. ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ

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

1.1. Уровни проектирования

Непосредственное отношение к проектированию КИС имеют два направления деятельности:

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

2.Проектирование упомянутых компонентов КИС и инструментальных средств, ориентированных на многократное применение при разработке многих конкретных информационных систем.

Сущность первого направления может быть выражена словами "системная интеграция". Разработчик КИС должен быть специалистом в области системотехники, хорошо знать международные стандарты, состояние и тенденции развития информационных технологий и программных продуктов, владеть инструментальными средствами разработки приложений (CASE-cредствами) и быть готовым к восприятию и анализу автоматизируемых прикладных процессов, сотрудничая со специалистами соответствующей предметной области. Существует ряд фирм, специализирующихся на разработке проектов КИС (например, "Price Waterhouse", "Inotech", "Consistent Software" и др.)

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

Как собственно КИС, так и компоненты КИС, являются сложными системами, и поэтому при их проектировании целесообразно использовать

5

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

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

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

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

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

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

Результаты анализа – техническое предложение и бизнес-план создания КИС – представляются заказчику для окончательного согласования.

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

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

6

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

Рис. 1.1. Компоненты концептуального проектирования

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

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

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

Для понимания процесса проектирования на одном из конкретизирующих уровней рассмотрим вариант выбора магистральных каналов. Если территориально КИС располагается в одном здании или в нескольких близкорасположенных зданиях, то корпоративная сеть может быть выполнена в виде совокупности нескольких локальных подсетей типа Ethernet или Token Ring, связанных опорной сетью типа FDDI, АТМ или

7

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

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

работающие по технологии CALS (Computer Acquisition Life-Cycle System).

Возникающие при этом проблемы связаны с обеспечением информационной безопасности и надежности доставки сообщений.

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

Важное значение для создания открытых систем имеет унификация и стандартизация средств межпрограммного интерфейса или, другими словами, необходимо наличие профилей КИС для информационного взаимодействия программ, входящих в КИС. Профилем открытой системы называют совокупность стандартов и других нормативных документов, обеспечивающих выполнение системой заданных функций. Так, в профилях КИС могут фигурировать язык EXPRESS стандарта STEP, стандарт графического пользовательского интерфейса Motif, унифицированный язык SQL обмена данными между различными СУБД, стандарты сетевого взаимодействия, в профили САПР машиностроения может входить формат IGES, в случае САПР радиоэлектроники – формат EDIF и т. п.

1.2. Стандарты проектирования КИС

Технологии реинжиниринга и параллельного проектирования.

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

IDEF (Integrated Definition) разработана по программе Integrated ComputerAided Manufacturing в США. В этой совокупности имеются методики функционального, информационного и поведенческого моделирования и проектирования; кроме того, в ее состав в настоящее время входят

IDEF-методики (табл. 1.1).

8

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

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

SADT (Structured Analysis and Design Technique), предложенная в 1973 г.

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

Таблица 1.1

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

Разработка SADT-модели начинается с формулировки вопросов, на которые модель должна давать ответы, т. е. формулируется цель моделирования. Далее выполняются этапы;

1.Сбор информации. Источниками информации могут быть документы, наблюдение, анкетирование и т. п. Существуют специальные методики выбора экспертов и анкетирования.

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

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

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

9

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

Поведенческие аспекты приложений отражает методика IDEF3. Если методика IDEF0 связана с функциональными аспектами и позволяет отвечать на вопрос: "Что делает система?", то в IDEF3 детализируются и конкретизируются IDEF0-функции – IDEF3-модель отвечает на вопрос: "Как система это делает?" В IDEF3 входят два типа описаний:

•процесс-ориентированные, представляемые в виде последовательности операций;

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

Методики инфологического проектирования баз данных реализуются системами информационного моделирования. Широко используются язык и методика создания информационных моделей приложений IDEF1X, развивающая более раннюю методику IDEF1. Кроме того, развитые коммерческие СУБД, как правило, имеют в своем составе совокупность CASE-средств проектирования приложений.

В IDEF1X имеется ясный графический язык для описания объектов и отношений в приложениях. Этот язык есть язык диаграмм "сущность–связь" (ERD – Entity-Relations Diagrams). Разработка информационной модели по IDEF1X выполняется в несколько стадий.

Стадия 0. Выяснение цели проекта и составление плана сбора информации. Обычно, исходные положения для информационной модели вытекают из IDEF0-модели.

Стадия 1. Выявление и определение сущностей. Это неформальная процедура.

Стадия 2. Выявление и определение основных отношений. Результат представляется или графически в виде ER-диаграмм, или в виде матрицы

отношений, элемент которой Aij = 1, если имеется связь между сущностями

i и j, и Aij = 0 в противном случае; транзитивные связи не указываются. Стадия 3. Детализация неспецифических отношений, определение

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

Стадия 4. Определение атрибутов и их принадлежности сущностям.

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

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

10

"часть–целое", перехода и т. п. В методике имеются правила связывания объектов (термов) в правильные предложения и аксиомы интерпретации термов.

Развитие BPR-методик продолжается в США по программе IICE (Information Integration for Concurrent Engineering). Уже разработаны прототипы следующих методик:

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

•IDEF8 – проектирование диалога человека с технической системой;

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

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

Основные положения стандартов IDEF0 и IDEF1X использованы также при создании комплекса стандартов ISO 10303, задающих технологию STEP для представления в компьютерных средах информации, относящейся к промышленному производству. В свою очередь, стандарты STEP, совокупность языков, таких как Express и SGML, а также разрабатываемые стандарты P-LIB и MANDATE составляют основу технологии CALS информационного обеспечения всех этапов жизненного цикла промышленных изделий.

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

Спецификации проектов программных систем. Важное значение

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

CASE.

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

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

•элементарной частью диаграммы каждого уровня является конструкция "вход–функция–выход";

•необходимая дополнительная информация содержится в файлах поясняющего текста.

Вбольшинстве случаев функциональные диаграммы являются диаграммами потоков данных (DFD – Data Flow Diagram). В DFD блоки (прямоугольники) соответствуют функциям, дуги – входным и выходным

11

потокам данных. Поясняющий текст дается в виде "словарей данных", в которых указываются компонентный состав потоков данных, число повторений циклов и т. п. Для описания структуры информационных потоков можно использовать нотацию Бэкуса–Наура.

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

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

Поведенческие модели описывают процессы обработки информации. В системах CASE их представляют в виде граф-схем, диаграмм перехода состояний, таблиц решений, псевдокодов (языков спецификаций), языков программирования, в том числе языков четвертого поколения (4GL).

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

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

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

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

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

Языки четвертого поколения направлены на описание программ как совокупностей заранее разработанных программных модулей. Поэтому одна команда языка 4GL может соответствовать значительному фрагменту программы на языке 3GL. Примерами языков 4GL могут служить

Informix-4GL, JAM, NewEra.

12

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

1.3. Инструментарий проектировщика КИС

Проектирование современной информационной системы состоит из трех базовых направлений (рис. 1.2):

•формализации бизнес-процессов предприятия и выработки концепции их автоматизации;

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

•создания прикладного программного обеспечения (ПО) и интеграции его с выбранными системными средствами.

Концептуальное

проектирование

Проектирование Проектирование вычислительной ПО

сети

Проект КИС

Рис. 1.2. Составные части проекта КИС

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

13

1.3.1.Архитектура средств проектирования

Всовременных информационных технологиях важное место отводится инструментальным средствам и средам разработки КИС, и в частности системам разработки и сопровождения их ПО. Эти технологии и среды образуют системы, называемые CASE-системами.

Используется двоякое толкование аббревиатуры CASE, соответствующее двум направлениям использования CASE-систем. Первое из них – Computer Aided Software Engineering – переводится как

"автоматизированное проектирование программного обеспечения"; соответствующие CASE-системы часто называют инструментальными средами разработки ПО (RAD – Rapid Application Development). Второе – Computer Aided System Engineering – подчеркивает направленность на поддержку концептуального проектирования сложных систем, преимущественно слабоструктурированных. Такие CASE-системы часто называют системами BPR (Business Process Reengineering).

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

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

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

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

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

Подсистема управления методологией проектирования

представлена в виде базы знаний БЗ УПР. В этой базе знаний содержатся такие сведения о предметной области, как информационная модель (например, в виде диаграмм "сущность–связь"), иерархическая структура

14

проектируемых объектов (например, в виде И-ИЛИ-дерева), описания типовых проектных процедур, типовые фрагменты маршрутов проектирования – так называемые потоки (flows) процедур, соответствие между процедурами и имеющимися пакетами прикладных программ, ограничения на их применение и т. п. Часто БЗ УПР дополняется обучающей подсистемой, используемой для подготовки специалистов к использованию САПР.

Средства

управления

проектом

Ядро

Рис. 1.3. Архитектура "идеальной" среды проектирования

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

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

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

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

15

данные или данные нового объекта. Описания задач даются в виде графов или на языках расширения.

Интеграция может осуществляться на основе унифицированных форматов или общего банка данных. Пример унифицированного формата –

TES (Tool Encapsultion Specification), предложенного консорциумом CFI (CAD Framework Initiative). Информация из TES используется для создания конверторов файлов при инкапсуляции.

Подсистема пользовательского интерфейса включает текстовый и графический редакторы и поддерживается системами многооконного интерфейса типа Х Window System или Open Look.

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

Так, в состав САПР Microstation (фирма Bentley Systems) включены RAD-среда Microstation Basic и язык MDL (Microstation Development Language) c cоответствующей программной поддержкой. Среда Microstation Basic близка по своим функциям к среде MS Visual Basic, в ней имеются генератор форм, редактор, конструктор диалога, отладчик. Язык MDL – С-подобный; с его помощью можно лаконично выразить обращения к проектным операциям и процедурам.

САПР Спрут (российская фирма "Sprut Technologies") вообще создана как инструментальная среда для разработки пользователем потоков задач конструкторского и технологического проектирования в машиностроении с последующим возможным оформлением потоков в виде пользовательских версий САПР. Сконструированный поток поддерживается компонентами системы, в число которых входят графические 2D- и 3D-подсистемы, СУБД, продукционная экспертная система, документатор, технологический процессор создания программ для станков ЧПУ, постпроцессоры.

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

CALS-технологии является концепция EPD (Electronic Product Definition)

фирмы "Computervision". В соответствии с ней в CALS систему должны входить следующие компоненты:

•комплекс прикладных программ автоматизированного проектирования (проектирующие подсистемы САПР), включая программы для конструирования изделий и инженерного анализа проектных решений;

•подсистема автоматизации технологической подготовки производ-

ства;

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

•средства управления данными;

16

•средства визуализации и разработки документации;

•CASE-подсистема;

•языковые средства межпрограммных обменов;

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

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

1.3.2. Инструментальное программное обеспечение

Средства концептуального проектирования. На рынке программных продуктов имеется много CASE-систем для концептуального проектирования КИС. Чаще всего в них поддерживается методология IDEF. В России широко известны продукты BPEin, ERWin, OOWin фирмы "Logic Works", Design/IDEF фирмы "Meta Software", Rational Rose фирмы "Rational Software", Silverrun фирмы "CSA" и др.

BРwin (Business Processing) служит для разработки функциональных моделей по методике IDEF0.

ERwin предназначена для разработки информационных моделей по методике IDEF1X. Имеются средства, обеспечивающие интерфейс с серверами БД (от пользователя скрыто общение на SQL-языке), перевод графических изображений ER-диаграмм в SQL-формы или в форматы других популярных СУБД. В систему включены также типичные для CASE средства разработки экранных форм.

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

Ряд программных продуктов, реализующих IDEF-модели, разработаны фирмой KBSI, в частности, ProSim реализует IDEF3, SmartER

– IDEF1 и IDEF1X, SmartClass – IDEF4.

Поведенческое моделирование предприятий предусмотрено также в некоторых системах реинжиниринга, например в системе BAAN IV.

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

17

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

•средствам программирования;

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

•средствам верификации (анализа) программ;

•средствам документирования.

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

Примерами широко известных инструментальных сред RAD являются

VB (Visual Basic), Delphi, PowerBuilder (соответственно, продукты фирм "Microsoft", "Borland", PowerSoft). Применение инструментальных сред существенно сокращает объем ручной работы программистов, особенно при разработке интерфейсных частей программ.

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

•окно меню с пунктами "File", "Edit", "Window" и т. п., реализующими функции, очевидные из названия пунктов;

•окно формы, на котором собственно и создается прототип экрана будущей прикладной программы;

•палитра инструментов – набор изображений объектов пользовательского интерфейса, из которых можно компоновать окно формы;

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

•окно редактора кода, на котором пользователь записывает создаваемую вручную часть кода;

•окно проекта – список модулей и форм в создаваемой программе.

18

Для написания событийных процедур в Visual Basic используется язык и текстовый редактор языка Basic, в Delphi – язык и редактор языка Object Pascal. Несомненным преимуществом среды разработки распределенных приложений Delphi является готовая поддержка наиболее современных архитектур доступа к разделяемым компонентам, в частности, CORBA. В CASE-системе фирмы "IBM", включающей части VisualAge (для клиентских приложений) и VisualGen (для серверных приложений), базовым языком выбран SmallTalk. В среде разработки приложений клиент–сервер SQLWindows оригинальные фрагменты программ пишутся на специальном языке SAL. Нужно заметить, что для реализации вычислительных процедур и, в частности, для написания миниспецификаций, используется обычная для 3GL технология программирования.

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

кним относятся средства выполнения следующих функций:

•поддержки ODBC и ADO, что дает возможность работы с различными СУБД;

•разработки баз данных;

•разработки трехзвенных систем распределенных вычислений;.

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

•управления версиями при групповой разработке ПО;

•моделирования и анализа процесса распределенных вычислений.

Создание сред RAD для сетевого программирования требует решения ряда дополнительных проблем, обусловливаемых многоплатформенностью, обилием применяемых форматов данных и т. п. Решение этих проблем, а также устранение некоторых особенностей языка С++, усложняющих программирование, достигнуто в языке программирования Java. Для этого языка разработана своя инструментальная среда JDK (Java Developer's Kit). В ней имеются библиотека классов и инструментальные средства, такие как компилятор байт-кодов, интерпретатор, просмотрщик аплетов, отладчик, формирователь оконных форм и т. п. Значительное внимание уделяется разработке инструментальных сред для создания Web-узлов, примером подобной среды может служить HAHTSite фирмы "HAHTSoftware". Для разработки Java-программ из готовых компонентов служит среда IBM Visial Age for Java, в которой имеются (как и в среде VB) учебная, профессиональная и общецелевая версии.

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

19

2.МЕТОДИКА ПРОЕКТИРОВАНИЯ ВЫЧИСЛИТЕЛЬНЫХ СЕТЕЙ

2.1.Задача сетевого проектирования

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

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

Подобно любому другому компоненту предприятия, сеть ЭВМ подвергается непрерывным изменениям. Эти изменения вызваны двумя базовыми факторами:

1)потребностью в новых услугах, предоставляемых с помощью ВС;

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

Оптимальное решение проблемы проектирования сети предприятия задается следующими целями (рис. 2.1):

•минимизацией стоимости (т. е. формирование по возможности наиболее дешевой сети);

•максимизацией отношения цена/производительность (ускорение возврата капиталовложений);

•повышением качества обслуживания (QoS) (например, снижение времени задержки при предоставлении услуги);

•минимизацией риска потерь (повышение надежности);

•максимизацией прибыли предприятия (например, завоевание новых рынков посредством работы в национальных и в общемировых сетях);

•максимизацией расширяемости (т. е. гибкости) сети;

•укреплением престижа фирмы;

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

20

Рост прибыли

Укрепление престижа фирмы

Повышение качества

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

Повышение гибкости

СОЗДАНИЕ ОПТИМАЛЬНОЙ СЕТИ ПРЕДПРИЯТИЯ

Минимизация стоимости

Минимизация рисков

Рис. 2.1. Цели сетевого проектирования

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

Далее перечислены основные исходные данные для процесса проектирования сети:

1.Локализация потребностей в услугах.

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

3.Выбор структуры сети с определением доступности конкретных услуг для конкретных областей.

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

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

21

2.2. Требования к методике

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

Методика должна обеспечивать надежную процедуру, которая поддерживает сбор данных (информационное обследование), создание множества проектов (собственно проектирование) и их оценку (анализ), а также окончательный выбор оптимального проекта и его внедрение (рис. 2.2). Процесс сетевого проектирования включает моделирование сети AS-IS ("как есть"). Для облегчения создания сетевых проектов TO-BE ("как должно быть"), поддерживается фиксация текущих и возможных в будущем рабочих нагрузок. Для каждого альтернативного проекта выполняются многоаспектные исследования, результатом которых является документация по обоснованию проекта. Методика также предусматривает разработку и дополнение библиотек описания сетевых технологий, представляющих современные и перспективные технологии вычислительных и телекоммуникационных сетей. Таким образом, предлагаемая методика разработана для использования совместно со средствами моделирования сетей для помощи в разработке сетевой архитектуры, которая затем может быть проверена и проанализирована с учетом различных сетевых технологий

Рис. 2.2. Сфера действия методики

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

22