Уровень протоколов маршрутизации

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

Проектирование информационных систем – Наместников А.М.

 

Классификация информационных систем

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

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

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

· По типу хранимых данных ИС

– фактографические (хранят числа и текст, можно выполнять различные операции).

– Документальные (хранят документы, обработка данных не производится).

· По степени автоматизации:

– Ручные (без использования технических средств)

– Автоматические (операции по переработке информации выполняются без участия человека)

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

· По характера обработки данных:

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

– информационно-решающие (функции информационно-поисковых систем + операции переработки информации по определенному алгоритму).

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

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

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

· По сфере применения:

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

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

– ИС автоматизированного проектирования (САПР) (для автоматизации функций инженеров-проектировщиков, конструкторов, архитекторов, дизайнеров при создании новой техники или технологии);

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

· По уровня управления

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

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

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

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

Метод проектирования ИС «снизу-вверх» и «сверху-вниз».

Снизу-вверх

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

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

Такой подход отчасти сохраняется и сегодня.

Проблема данного метода:

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

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

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

Сверху-вниз

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

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

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

Проблемы данного метода:

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

Заложенные "сверху" жесткие рамки не дают возможности гибко адаптировать систему к специфике деятельности конкретного предприятия.

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

Объектная структура и функциональная структура проектируемой информационной системы

Объектная структура

Объект — это сущность, которая используется при выполнении некоторой функции или операции (преобразования, обработки, формирования).

На внешнем уровне детализации модели выделяются:

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

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

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

- уточняется состав классов объектов,

- определяются их атрибуты и взаимосвязи.

Таким образом строится обобщенное представление структуры предметной области.

Далее концептуальная модель на внутреннем уровне отображается в виде:

- файлов базы данных,

- входных и выходных документов ИС.

Динамические объекты представляются единицами переменной информации или документами

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

Функциональная структура

Функция (операция) - некоторый преобразователь входных объектов в выходные.

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

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

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

Функция может быть представлена:

- одним действием,

- некоторой совокупностью действий.

Каждой функции может соответствовать некоторый процесс, в котором могут существовать свои подпроцессы.

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

На внешнем уровне моделирования определяется список основных бизнес-функций или видов бизнес-процессов. Обычно таких функций насчитывается 15–20.

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

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

 

1. Функциональная методика IDEF0

Методология IDEF0 есть этап развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Teqnique).

В основе методологии лежат четыре основных понятия:

- функциональный блок,

- интерфейсная дуга,

- декомпозиция,

- глоссарий.

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

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

- верхняя сторона имеет значение "Управление" (Control);

- левая сторона имеет значение "Вход" (Input);

- правая сторона имеет значение "Выход" (Output);

- нижняя сторона имеет значение "Механизм" (Mechanism).

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

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

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

Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).

Декомпозиция (Decomposition) является основным понятием стандарта IDEF0.

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

Последним из понятий IDEF0 является глоссарий (Glossary).

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

Этот набор называется глоссарием и является описанием сущности данного элемента.

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

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

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

Этим достигается структурная целостность IDEF0–модели.

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

Для решения подобных задач в стандарте IDEF0 предусмотрено понятие туннелирования.

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

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