У вас вопросы?
У нас ответы:) SamZan.net

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

Работа добавлена на сайт samzan.net:

Поможем написать учебную работу

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

Предоплата всего

от 25%

Подписываем

договор

Выберите тип работы:

Скидка 25% при заказе до 28.12.2024

БИЛЕТ_1

Существует четыре группы автоматических систем:

  1.  измерительно-информационные системы (ИИС);
  2.  системы автоматического контроля (САК);
  3.  системы автоматического регулирования (САР);
  4.  системы автоматического управления (САУ).

Развитие техники и методов управления в экономических, организационно-экономических и организационно-технических системах, необходимость повышения эффективности их функционирования привели к созданию принципиально нового класса систем управления – автоматизированных систем. Как известно, в любой системе управления решаются три основные задачи: 1) сбор и передача информации об управляемом объекте; 2) обработка информации и принятие решений; 3) выдача управляющего воздействия на объект управления.

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

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

  1.  Иерархичность структуры, т.е. возможность выделения отдельных элементов с устойчивыми пространственно-временными связями, имеющими подчиненный характер. Подчиненность выражается как структурным местоположением элементом подсистем, так и распределением управляющих функций.
  2.  Адаптация и самоорганизация системы в целом и отдельных ее подсистем. Поскольку нельзя создать АСУ, удовлетворяющую запросам пользователей в будущем, и она должна развиваться по мере изменения характера объекта управления и целей функционирования, то необходимо заложить в системе возможность ее совершенствования, т.е. адаптирования к изменениям внешней среды.
  3.  Наличие ЭВМ в подсистемах различных рангов для оптимизации принимаемых решений, преобразования и обработки истоков информации.

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

По уровню управления различают:

АСУ межгосударственные

АСУ общегосударственные

АСУ отраслевые и межотраслевые

АСУ предприятий и объединений (фирм)

АСУ подразделений предприятий

АСУ технологических процессов или операций.

По назначению или характеру объектов управления различают:

АСУ административные

АСУ общественно-политические

АСУ коммерческие

АСУ оборонные

АСУ транспортные

АСУ производственно-технические и др.

По характеру решаемых задач различают:

АСУ стратегические (например, перспективного планирования отрасли или фирмы)

АСУ тактические (например, текущего планирования)

АСУ оперативные

АСУ информационные.

По степени использования выходных результатов различают:

АСУ информационно-справочные

АСУ информационно-советующие

АСУ информационно-управляющие.

По структуре различают:

АСУ централизованные

АСУ иерархические

АСУ децентрализованные.

По характеру производства различают:

АСУ предприятиями с непрерывным производством

АСУ предприятиями с дискретным производством

АСУ предприятиями с дискретно-непрерывным производством.

По выполняемым функциям различают три класса АСУ:

1) АСУП – автоматизированные системы управления производством; 2) АСУТП – автоматизированные системы управления технологическим процессом; 3) САПР – системы автоматического проектирования.

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

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

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

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

По степени охвата управляемого процесса АСУТП делятся на локальные, т.е. управляющие отдельными станками, агрегатами, линиями, участками, и комплексные, которые управляют группами установок, цехами, имеющими АСУТП как подсистемы.

По степени участия человека в управлении технологическими процессами различают информационные, информационно-советующие и управляющие АСУТП.

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

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

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

Таблица 1.1

Группа предприятий

Основные составляющие АСУ

Характер интеграции

I

1. САПР

2. АСУТП

3. АСУП

Проектирование, технология, экономико-организационные процессы

II

1. САПР

2. АСУП

Проектирование, экономико-организационные процессы

III

1. АСУТП

2. АСУП

Технология, экономико-организационные процессы

IV

АСУП

Экономико-организационные процессы

В ИАСУ научно-производственным объединением можно выделить следующие автоматизированные системы (см. рис. 1):

САПР, которая конструирует изделия, узлы, детали, разрабатывает требования к ним;

АСУП, планирующая и координирующая работу всех структурных элементов (подразделений, подсистем) интегрированного автоматизированного производства;

АСНИ, исследующая готовые и проектируемые образцы изделий на соответствие требованиям ТЗ;

АСТПП, проектирующая технологические процессы и управляющие программы для станков с ЧПУ, технологическую оснастку, инструмент(Схема структуры КТС на уровне технологической линии представлена на рис. 1.1.1);

Автоматизированная система организационно-экономического управления, осуществляющая текущее и оперативное планирование и учет хода производственных процессов (АСОЭУ);

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

Распределенная система автоматического контроля, осуществляющая контроль качества функционирования интегрированного автоматизированного производства и качество изготовления изделий (САК);

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

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

Таким образом, компоненты АСУП-САПР-АСНИ генерируют своеобразную информационную среду для всего интегрированного автоматизированного производства, реализованную в виде верхнего уровня общего распределенного банка данных системы. Компоненты АСТПП, АСОЭУ, САК, АСУОТ объединяют в комплекс иерархии нижнего уровня интегрированного автоматизированного производства. На этом уровне решаются практические задачи организационно-технологического планирования и управления, автоматизировано подготавливаются технологические управляющие программы и осуществляется непосредственное цифровое управление технологическими объектами управления в режиме реального времени. Данные подсистемы нижнего уровня иерархии генерируют своеобразную внутреннюю информационную среду, реализованную в виде нижнего уровня общего распределенного банка данных интегрированного автоматизированного производства.

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


БИЛЕТ_2

Проектирование любого объекта, в том числе и АСУ требует предварительного анализа этого объекта с целью его структуризации.

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

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

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

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

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

Примеры организационной структуры АСУ приведены на  рис. 1.2, 1.3 и 1.4.

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

Состав функций реализуемых АСУ определяет ее назначение. Примеры функциональных подсистем АСУ воздушным движением страны:

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

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

подсистема текущего планирования полетов в аэроузле;

подсистема управления взлетом – посадкой самолетов в аэропорту.

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

    Рис. 1.1. Схема организационной структуры ИАСУ предприятием

Рис. 1.1.1. Схема структуры КТС на уровне технологической линии

Рис. 1.2. Организационная структура АСУ производственного объединения

Рис. 1.3. Пример организационной структуры АСУ воздушным движением страны

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 1.4. Типичные функциональные группы дискретного производства

Рис. 1.5. Пример функциональной структуры АСНИ

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

Рис. 1.7. Схема функциональной структуры ИАСУ ГАЦ

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

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

Рис. 1.10. Пример совмещения организационной и функциональной структур АСУ ВД

Рис. 1.11. Общая схема взаимосвязи управляющей и управляемой систем в условиях АСУ

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


БИЛЕТ_3_ Виды обеспечений АСОИУ и их структура

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

Эти средства называют видами (компонентами) обеспечения АСОИУ.

Различают следующие виды обеспечения АСУ:

организационное,

информационное,

математическое,

программное,

техническое,

лингвистическое,

правовое,

эргономическое.

Организационное обеспечение АСУ представляет собой совокупность средств и методов, предназначенных для проведения:

  1.  технико-экономического анализа существующей системы управления;
  2.   выбора и постановки задач автоматизации управления;
  3.   организации процесса функционирования объекта управления в условиях АСУ.

Оно необходимо для обеспечения взаимодействия персонала АСУ с техническими средствами и между собой в процессе решения задач управления. Структура организационного обеспечения на примере АСУ ВД представлена на рис. 1.12.

Рис. 1.12. Схема структуры организационного обеспечения АСУ ВД

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

Техническое обеспечение АСУ – это комплекс технических средств, обеспечивающий эффективное функционирование АСУ. Его специфика состоит в необходимости систематического обслуживания, проверки исправности, профилактики, различных видов ремонта. Эта специфическая область работы АСУ выполняется специалистами по электронике и вычислительной технике и не входит в круг обязанностей специалистов по разработке и эксплуатации АСУ. Однако проектирование всего комплекса технических средств АСУ, объединенного в обеспечивающую подсистему АСУ, является непосредственной задачей разработчиков системы. Структура технического обеспечения на примере АСУ ВД представлена на рис. 1.14.

Рис. 1.13. Схема структуры информационного обеспечения АСУ ВД

Рис. 1.14. Схема структуры технического обеспечения АСУ ВД

В плане реализации для конкретных АС технические средства могут образовывать достаточно сложные иерархические структуры на основе построения распределенных вычислительных сетей (РВС). Примеры таких структур приведены на рис.1.15,1.16.
БИЛЕТ_4

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

Программное обеспечение обычно разбивают на две части:

общее программное обеспечение,

специальное (функциональное) программное обеспечение.

Последнее в управляющих ЭВМ часто занимает 50-70 % от общего объема памяти программ.

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

программное обеспечение вычислительного процесса,

программное обеспечение технологии создания и сопровождения специального программного обеспечения (см. рис. 1.17).

Специальное программное обеспечение обычно разделяют на три компоненты:

пакеты прикладных программ,

программно-ориентированные системы,

программы организации вычислительного процесса (см рис. 1.18).

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

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

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

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

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

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

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

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

Рис. 1.16. Схема структуры распределенной вычислительной системы (РВС) для координации производства

Рис. 1.17. Схема структуры общего программного обеспечения АСУ

    Рис. 1.18. Схема структуры специального программного обеспечения

   Рис. 1.19. Типовая схема взаимосвязей программ АСУ.

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

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

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

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

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

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

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

Программы функционального контроля могут включаться:

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

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

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

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

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

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

  1.  зона программ организации вычислительного процесса;
  2.  зона входной информации;
  3.  зона выдаваемой информации;
  4.  зоны результатов обработки;
  5.  зоны контроля;
  6.  зоны хранения программ.

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


БИЛЕТ_5

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

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

2. Режим тестового контроля и поиска неисправностей. Его можно разделить на два подрежима:

  2.1. С помощью специальных диагностических тестов;

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

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

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

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

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

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

БИЛЕТ_6

Лингвистическое обеспечение АСУ – это совокупность языковых средств для формализации естественного языка, построения сочетания информационных единицы при общении персонала АСУ в условиях ее функционирования, общения персонала со средствами вычислительной техники. Структура лингвистического обеспечения на примере АСУ ВД приведена на рис. 1.21.

Рис. 1.20. Типовая схема структур расширения оперативной памяти

Рис. 1.21. Схема структуры лингвистического обеспечения АСУ ВД

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

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

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

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

Компоненты АСУ могут быть сгруппированы в три класса компонент:

  1.  функциональные компоненты, определяющие, какие функции управления объектом и в каком объеме выполняет АСУ;
  2.  организационные компоненты, регламентирующие порядок взаимодействия структурных подразделений объекта управления в процессе разработки, внедрения и функционирования АСУ;
  3.  3) компоненты системы обработки данных, отражающие разные аспекты внутренней структуры процессов и средств их технической реализации, обеспечивающих получение, хранение, обработку и передачу информации, необходимой для автоматизируемого управления объектом управления. Обобщенная схема структуры АСУ в виде укрупненной декомпозиции составляющих ее компонент представлена на рис.1.24.

Рис. 1.22.  Схема структуры математического обеспечения АСУ ВД

Рис. 1.23.  Схема структуры правового обеспечения АСУ

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

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

БИЛЕТ_7

2.1. Общий порядок проектирования АСУ

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

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

Работы по созданию новых и развитию существующих АСУ, осуществляются по стадиям и этапам. В общем случае их состав определен ГОСТ 34.601-90 и приведен в таблице 2.1.

Таблица 2.1. Стадии и этапы создания АСУ.

Стадии

Этапы
  1.  Формирование требований к АСУ
  1.   Обследование объекта и обоснование необходимости создания АСУ.
    1.   Формирование требований пользователя АСУ.
    2.   Оформление отчета о выполненной работе и заявки на разработку АСУ (тактико-технического задания).
  1.  Разработка концепции АСУ

2.1. Изучение объекта.

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

3.1. Разработка и утверждение технического задания (ТЗ).
  1.  Эскизный проект

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

4.2. Разработка документации на АСУ и ее части.
  1.  Технический проект

5.1. Разработка проектных решений по системе и ее частям.

5.2. Разработка документации на систему и ее части.

5.3. Разработка и оформление документации на поставку изделий для комплектования АСУ и (или) технических требований (технических заданий) на их разработку.

5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации.
  1.  Рабочая документация

6.1. Разработка рабочей документации на систему и ее части.

6.2. Разработка и адаптация программ.
  1.  Ввод в действие

7.1 Подготовка объекта автоматизации к вводу АСУ в действие.

  1.  Подготовка персонала
    1.  Комплектация системы поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями).
    2.  Строительно-монтажные работы
    3.   Пуско-наладочные работы.
    4.   Проведение предварительных испытаний.
    5.  Проведение опытной эксплуатации.
    6.   Проведение приемочных испытаний.
  1.  Сопровождение АСУ

8.1. Выполнение работ в соответствии с гарантийными обязательствами.

8.2. Послегарантийное обслуживание системы.

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

Конкретный состав выполняемых стадий и этапов устанавливается в техническом задании на АСУ и в договорах между участниками работ по созданию АСУ.

2.2. Содержание работ предпроектных стадий создания АСУ.

Стадии «Формирование требований к АСУ», «Разработка концепции АСУ» и «Техническое задание» относят к предпроектным стадиям создания АСУ. Основная цель их выполнения – обосновать необходимость создания АСУ, сформулировать требования, которым она должна удовлетворять, определить ее структуру, состав и последовательность выполняемых работ.

Первая стадия - «Формирование требований к АСУ», состоит из трех этапов.

На этапе 1.1. «Обследование объекта и обоснование необходимости создания АСУ» выполняют в общем случае следующие работы:

  1.  сбор информации о ранее выполненных разработках по созданию АСУ аналогичными объектами;
  2.  сбор данных об объекте автоматизации и осуществляемых видах его деятельности;
  3.  оценка качества функционирования объекта и осуществляемых им видов деятельности, выявление проблем, решение которых возможно средствами автоматизации;
  4.  оценка (технико-экономической, социальной и т.п.) целесообразности создания АСУ.


БИЛЕТ_8

Этап 1.2. «Формирование требований пользователя АСУ» включает две группы работ.

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

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

Этап 1.3. «Оформление отчета о выполненной работе и заявки на разработку АСУ (тактико-технического задания)» является завершающим для стадии «Формирование требований к АСУ». Этот этап заканчивается составлением отчета по ГОСТ 7.32 и заявкой на разработку АСУ.

В общем случае основная часть отчета состоит из восьми разделов (РД–50–34.698-90).

  1.  Раздел «Характеристика объектов и результатов его функционирования» содержит общую характеристику объекта, включающую требования к объекту со стороны вышестоящей организации и (или) характер взаимодействия с внешней средой, организационную структуру объекта, требования к объему, номенклатуре и качеству результатов его функционирования.
  2.  Раздел «Описание существующей информационной системы» содержит сведения о функциональной и информационной структуре системы, ее качественных и количественных характеристик, показывающих взаимодействие ее компонентов в процессе функционирования. К таким характеристикам относят номенклатуру и объемы обрабатываемой информации, сроки и периодичность обработки, применяемые формальные методы решения задач и используемые технические средства.
  3.  В разделе «Описание недостатков существующей информационной системы» приводят результаты диагностического анализа системы. Его цель – оценить качество функционирования и организационно-технологический уровень системы, с точки зрения обеспечения объектом управления поставленных перед ним целей и задач, выявить недостатки в организации и технологии функционирования информационных процессов, определить степень влияния этих недостатков на качество функционирования системы.
  4.  В разделе «Обоснование необходимости совершенствования информационной системы объекта» показывают возможность повышения показателей функционирования объекта до уровня требуемых, за счет совершенствования его информационной системы путем создания АСУ.
  5.  Раздел «Цели, критерии и ограничения создания АСУ» содержит формулировки производственно-хозяйственных, научно-технических, экономических и др. целей создания АСУ, критерии, позволяющие оценивать степень достижения этих целей, а также характеристику ограничений по созданию АСУ (временные, стоимостные, трудовые и т.д.).
  6.  Раздел «Функции и задачи создаваемой АСУ» содержит обоснование выбора перечня автоматизируемых функций и комплексов задач с указанием очередности их внедрения, требования к характеристикам реализации функций и задач в соответствии с общими техническими требованиями к АСУ конкретного вида.
  7.  Раздел «Ожидаемые технико-экономические результаты создания АСУ» содержит перечень основных источников экономической эффективности, получаемых в результате создания АСУ, оценку ожидаемых изменений основных технико-экономических и социальных показателей производственно-хозяйственной деятельности объекта, оценку ожидаемых затрат на создание и эксплуатацию АСУ, с распределением их по очереди создания АСУ и по годам, а также ожидаемые обобщающие показатели экономической эффективности АСУ.
  8.  Раздел «Выводы и предложения» - завершающий раздел отчета по стадии «Формирование требований к АСУ». Этот раздел рекомендуется разделить на три подраздела.

8.1. Подраздел «Выводы о производственно-хозяйственной необходимости и технико-экономической целесообразности создания АСУ» содержит сопоставление ожидаемых результатов создания АСУ с установленными целями, принципиальное решение о создании АСУ (положительное или отрицательное).

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

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

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

Перейдем ко второй стадии – «Разработка концепции АСУ». Эта стадия в общем случае состоит из четырех этапов.

На этапе 2.1. «Изучение объекта» организация-разработчик АСУ по специальной программе проводит детальное изучение объекта автоматизации с целью:

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

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

На этапе 2.3. «Разработка вариантов концепции АСУ и выбор варианта концепции АСУ, удовлетворяющего требованиям пользователя» организация-разработчик, в общем случае, выполняет следующий комплекс работ:

  1.  разрабатывает альтернативные варианты концепции создаваемой АСУ, то есть определяются варианты облика и тех принципов и руководящих идей, которые могут быть положены в основу АСУ;
  2.  разрабатывает планы реализации каждого альтернативного варианта и дает оценку необходимых для этого ресурсов;
  3.  дает оценку преимуществ и недостатков каждого варианта, осуществляет выбор оптимального рационального варианта;
  4.  определяет требования, гарантирующие качество функционирования выбранного варианта АСУ, условия приемки системы.

На этапе 2.4. «Оформление отчета о выполненной работе» организация-разработчик подготавливает и оформляет отчет согласно требованиям ГОСТ 7.32. В основной части этого отчета приводят:

  1.  описание результатов изучения объекта автоматизации;
  2.  описание и оценку преимуществ и недостатков разработанных альтернативных вариантов концепции создаваемой АСУ, их сопоставительный анализ, на предмет удовлетворения требованиям пользователя;
  3.  обоснование выбора оптимального рационального варианта концепции и описание предлагаемой АСУ;
  4.  ожидаемые результаты и эффективность реализации выбранного варианта, ориентировочный план его реализации; 5) необходимые затраты ресурсов и требования, гарантирующие качество АСУ; 6) условия приемки системы.


БИЛЕТ_9_ Содержание проектных работ на стадии «Техническое задание». Структура и состав итогового документа стадии

Стадия 3 – «Техническое задание» - это очень важная стадия. Она состоит из одного этапа.

На этапе 3.1. «Разработка и утверждение технического задания на создание АСУ» проводят разработку, оформление, согласование и утверждение технического задания на АСУ. Техническое задание (ТЗ) разрабатывают и оформляют в соответствии с ГОСТ 34.602-89. Оно является основным документом, определяющим требования и порядок создания АСУ; в соответствии с ним проводится разработка АСУ и ее приемка при вводе в действие. ТЗ на АСУ содержит следующие 9 разделов, которые могут быть разделены на подразделы:

  1.  общие сведения;
  2.  назначение и цели создания (развития) системы;
  3.  характеристика объектов автоматизации;
  4.  требования к системе;
  5.  состав и содержание работ по созданию системы;
  6.  порядок контроля и приемки системы;
  7.  требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
  8.  требования к документированию;
  9.  источники разработки.
  10.  В разделе «Общие сведения» указывают: полное наименование системы и ее условное обозначение; шифр темы или договора; наименование организаций-разработчиков и заказчика системы; основание для выполнения работ и сроки их выполнения; сведения об источниках и порядке финансирования работ по созданию системы; порядок оформления и предъявления заказчику результов работы по созданию системы.
  11.  В разделе «Назначение и цели создания (развития) системы» указывают вид автоматизируемой деятельности и перечень объектов автоматизации, на которых предполагается ее использование, приводят наименования и требуемые значения тех показателей объекта автоматизации (технических, экономических и др.), которые должны быть достигнуты в результате создания АСУ, указывают критерии оценки достижения целей.
  12.  В разделе «Характеристики объекта автоматизации» приводят краткие сведения об объекте автоматизации со ссылкой на документы, содержащие такую информацию, а также сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды.
  13.  Раздел «Требования к системе» состоит из следующих подразделов: 1) требования к системе в целом; 2) требования к функциям (задачам) выполняемым системой; 3) требования к видам обеспечения.

4.1. В подразделе «Требования  к системе в целом» указывают требования к структуре и функционированию системы, численности и квалификации персонала и режиму его работы, безопасности и надежности работы, эргономические требования, требования по сохранности информации при авариях, другие специальные требования, обусловленные особенностями и условиями функционирования АСУ.

4.2. В подразделе «Требования по видам обеспечения» в зависимости от вида системы приводят требования к математическому, информационному, лингвистическому, программному и другим видам обеспечения АСУ. Рассмотрим эти требования более подробно.

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

Для информационного обеспечения системы приводят требования: 1) к составу, структуре и способам организации данных в системе; 2) к информационному обмену между компонентами системы и со смежными системами; 3) по использованию государственных, отраслевых и других классификаторов и унифицированных форм документов; 4) по применению систем управления базами данных; 5) к структуре процесса сбора, обработки, передачи данных в системе и представлению данных; 6) к защите данных от разрушений при авариях и сбоях в системе и от несанкционированного доступа; 7) к процедуре придания юридической силы документам, продуцируемым техническими средствами АСУ.

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

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

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

Для организационного обеспечения системы приводят требования к: 1) структуре и функциям подразделений, участвующих в функционировании системы или обеспечивающих ее эксплуатацию; 2) организации функционирования системы и порядку взаимодействия персонала АСУ и объекта управления; 3) защите от ошибочных действий персонала системы.

  1.  Раздел ТЗ «Состав и содержание работ по созданию (развитию) системы» должен содержать перечень стадий и этапов работ по созданию системы, сроки их выполнения и перечень организаций-исполнителей. Кроме этого, в этом разделе приводят перечень документов, предъявляемых по окончании соответствующих стадий и этапов, вид и порядок проведения экспертизы технической документации, программу работ по обеспечению требуемого уровня надежности создаваемой системы и ее метрологическому обеспечению.
  2.  В разделе «Порядок контроля и приемки системы» указывают: 1) виды, состав, объем и методы испытаний системы или ее частей; 2) общие требования к приемке работ по стадиям, порядок согласования и утверждения приемочной документации; 3) статус приемочной комиссии.
  3.  В разделе «Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие» необходимо привести перечень основных мероприятий и их исполнителей.
  4.  В разделе «Требования к документированию» приводится перечень подлежащих разработке документов, вид и формы их представления заказчику.
  5.  В разделе «Источники разработки» должны быть перечислены документы и информационные материалы, на основании которых разрабатывалось ТЗ и которые должны быть использованы при создании системы.

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

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

В заключение этого раздела отметим, что фактически сформулированное ТЗ полностью определяет логику функционирования создаваемой АСУ. Поэтому стадию технического задания можно назвать стадией логического проектирования создаваемой АСУ. Логическому проектированию предшествует концептуальное проектирование (стадия 2 по ГОСТу), а ему – предпроектный анализ (стадия 1 по ГОСТу). Таким образом, технологический процесс создания АСУ на предпроектных стадиях можно представить в виде следующей обобщенной схемы (см. рис. 2.1.)

Рис. 2.1. Технологический процесс создания АСУ Обобщенная характеристика работ, выполняемых в процессе логического проектирования АСУ приведена на рис. 2.2.


БИЛЕТ_10 Обобщенная характеристика этапа «Логическое проектирование АСОИУ

2.3. Содержание работ проектных стадий создания АСУ

Непосредственное проектирование создаваемой АСУ осуществляется на стадиях: 4. «Эскизный проект»; 5. «Технический проект»; 6. «Рабочая документация».

Работы, выполняемые на стадии 4. «Эскизный проект», носят предварительный характер. На этой стадии, как правило, решают общесистемные задачи, для чего: 1) определяют функциональную и организационную структуры создаваемой АСУ и структуру комплекса технических средств; 2) уточняют функции подсистем и состав относящихся к ним комплексов задач и отдельных задач; 3) разрабатывают и обосновывают концепцию

Рис. 2.2 Обобщенная характеристика этапа «Логическое проектирование системы»

информационной базы и ее укрупненную структуру; 4) уточняют функции системы управления базой данных, функции и параметры основных программных средств. Завершается данная стадия разработкой документов, виды которых определены ГОСТ 34.201. Требования к содержанию некоторых из этих документов приведены ниже в главе 4 данного пособия.

Основные проектные решения по созданию АСУ принимаются на стадии 5. «Технический проект». Эта стадия включает в себя четыре этапа.

На этапе 5.1. «Разработка проектных решений по системе и ее частям» выполняют работы, связанные с поиском и принятием общих решений по системе и ее частям:

  1.  функционально-алгоритмической структуре системы;
  2.  по функциям персонала и организационной структуре;
  3.  по структуре комплекса технических средств;
  4.  по алгоритмам и применяемым языкам;
  5.  по организации и ведению информационной базы, системе классификации и кодирования информации;

по программному обеспечению.


На этапе 5.2. «Разработка документации на АСУ и ее части» проводят разработку, оформление, согласование и утверждение документации в объеме, необходимом для описания полной совокупности принятых проектных решений и достаточном для дальнейшего выполнения работ по созданию АСУ. Виды документов – по ГОСТ 34.201. Требования к содержанию некоторых из этих документов приведены ниже в главе 4 данного пособия.

На этапе 5.3. «Разработка и оформление документации на поставку изделий для комплектования АСУ и (или) технических требований (технических заданий) на их разработку» проводят подготовку и оформление документации на поставку изделий для комплектования АСУ, определяют технические требования и составляют ТЗ на разработку изделий, которые не изготовляются серийно.

На этапе 5.4. «Разработка заданий на проектирование в смежных частях проекта объекта автоматизации» осуществляют разработку, оформление, согласование и утверждение заданий на проектирование в смежных частях проекта объекта автоматизации для проведения строительных, электротехнических, санитарно-технических и других подготовительных работ, связанных с созданием АСУ. Обобщенная характеристика стадии «Технический проект» представлена на рис. 2.3. Отметим, что стадию «Технический проект» еще называют стадией «Физического проектирования». Этим подчеркивается тот факт, что на этой стадии переходят от умозрительного, желаемого проектирования, на стадиях «Техническое задание» (ее можно по другому назвать стадией логического проектирования) и этапе «Эскизный проект», к реальному проектированию.

Стадия 6. «Рабочая документация» состоит из двух этапов.

На этапе 6.1. «Разработка рабочей документации на систему и ее части» осуществляют разработку рабочей документации, содержащей все сведения, которые требуются для обеспечения выполнения работ по вводу АСУ в действие и ее эксплуатации, а также для поддержания уровня эксплуатационных характеристик системы в соответствии с принятыми проектными решениями, ее оформление, согласование и утверждение. Виды документов, которые разрабатывают на этой стадии, определены ГОСТ 34.201. Требования к содержанию некоторых из этих документов приведены в главе 4 данного пособия.

На этапе 6.2. «Разработка или адаптация программ» проводят разработку программ и программных средств системы, выбор, адаптацию и (или) привязку приобретаемых программных средств, разработку программной документации в соответствии с государственными стандартами Единой системы программной документации (ЕСПД). Требования к содержанию некоторых из документов программного обеспечения АСУ приведены в главе 4 данного пособия. Обобщенная характеристика этой стадии представлена на рис. 2.4. Эту стадию еще называют стадией программной реализации системы.

Рис. 2.3. Обобщенная характеристика этапа «Физическое проектирование системы»


БИЛЕТ_11, 12_ Обобщенная характеристика этапа «Физическое проектирование АСОИУ»

2.4. Содержание работ на стадиях ввода в действие и сопровождения АСУ

Стадия 7. «Ввод в действие», в общем случае, состоит из восьми этапов.

На этапе 7.1. «Подготовка объекта к вводу АСУ в действие» осуществляют реализацию принятых проектных решений по организационной структуре АСУ, обеспечивают подразделения объекта управления необходимыми инструктивно-методическими материалами, внедряют классификаторы информации.

Этап 7.2. «Подготовка персонала» включает обучение персонала и проверку его способности к работе по обеспечению функционирования АСУ.

На этапе 7.3. «Комплектация АСУ поставляемыми изделиями» обеспечивают получение необходимых изделий серийного и единичного производства, материалов и монтажных изделий.

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

На этапе 7.5. «Пуско-наладочные работы» проводят автономную наладку технических средств, загрузку информации в базу данных и проверку системы ее ведения, комплексную наладку всех средств системы.

Этап 7.6. «Проведение предварительных испытаний» включает испытания АСУ на работоспособность и соответствие ТЗ, устранение неисправностей и внешние изменения в документацию на АСУ. Завершается этап формированием акта о приемке АСУ в опытную эксплуатацию.

На этапе 7.7. «Проведение опытной эксплуатации» проводят опытную эксплуатацию АСУ, анализируют полученные результаты и, при необходимости, выполняют доработку программного обеспечения и дополнительную наладку технических средств. Заканчивается этап актом о завершении опытной эксплуатации.

Этап 7.8. «Проведение приемочных испытаний» выполняют с целью определения соответствия разработанной АСУ техническому заданию. После проведения испытаний и устранения недостатков, выявленных при испытаниях, оформляется акт о приемке АСУ в постоянную эксплуатацию.

Стадия 8. «Сопровождение АСУ» состоит из двух этапов.

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

Этап 8.2. «Послегарантийное обслуживание» включает работы по анализу функционирования системы, выявлению отклонения фактических эксплуатационных характеристик АСУ от проектных значений, устранению выявленных недостатков, внесению необходимых изменений в документацию на АСУ.

Рис. 2.4. Обобщенная характеристика этапа «Программа реализация проекта системы»


БИЛЕТ_13_ Методы анализа документооборота в исследуемом объекте автоматизации. Матричная информационная модель

3.1. Методы анализа документооборота в исследуемом объекте управления

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

Результаты анализа объекта и системы управления фиксируются в специальных документах. Комплект этих документов называют системной спецификацией. Использование системных спецификаций при анализе и проектировании АСУ позволяет:

  •  Систематизировать полученные в результате анализа данные и представить их в наглядном и удобном для дальнейшего использования виде;
  •  Упростить и облегчить передачу результатов работы одних специалистов другим;
  •  Обеспечить взаимозаменяемость исполнителей;
  •  Формализовать процедуры ввода исправлений и дополнений;
  •  Облегчить контроль качества выполнения каждого этапа работы.

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

Этапы разработки

Наименование форм документации

I. Изучение структуры, целей и ограничений существующей системы управления
  1.  Описание организации
  2.  Структурная схема организации
  3.  Таблица целей и функций организации
  4.  Характеристика задач организации
  5.  Описание функций подразделения
  6.  Описание информационных потоков подразделений
  7.  Структурная схема каждого подразделения
  8.  Таблица функций подразделения
  9.  Обобщенная структурно-информационно-временная схема

II. Изучение и анализ информационных потоков и алгоритмов переработки данных в существующей системе управления
  1.  Характеристики документов
  2.  Описание документов
  3.  Характеристики массивов
  4.  Описание массивов
  5.  Характеристики процедур (задач)
  6.  Описание процедур (задач)
  7.  Схема детального анализа процедур

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

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

Схема потока информации задается указанием отношений вхождения относительно каждого элемента потока.

Элементами потока информации могут быть:

а) документы;

б) элементы документов (показатели, реквизиты);

в) операторы (люди, устройства, подразделения).

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

ДОП______________1


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

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

На основании обработки полученных данных о документах и показателях получают различного рода аналитические материалы о документообороте. Наиболее простым представлением документооборота является его графическое представление (см. рис. 3.4).

Более сложной является так называемая матричная информационная модель (см. рис. 3.5, 3.6).

шифр документа

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

шифр подразделения – поставщика

шифр подразделения – получателя

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

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

периодичность разработки документа

шифр вида документа (активный, пассивный)

объем документа (в строках, знаках)

количество экземпляров

трудоемкость составления

примечания

1

2

3

4

5

6

7

8

9

10

11

12

Рис. 3.2. Пример анкеты для характеристики документа

шифр подразделения сообщающего сведения

шифр документа

шифр показателя

шифр подразделения, где показатель используется

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

шифр периодичности разработки документа

шифр значности показателя

шифр вида показателя

шифр вида документа

примечания

шифр I-го показателя

шифр документа

шифр подразделения - поставщика

шифр действия

…

шифр II-го показателя

шифр документа

шифр подразделения - поставщика

шифр действия

1

2

3

4

5.1

5.2

5.3

5.4

5.X

5.XI

5.XII

5XII

6

7

8

9

10

Рис. 3.3. Пример анкеты для характеристики показателей

ДОП______________2

ДОП______________3

ДОП______________4

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

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

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

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

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

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

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

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

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

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

Если структурные компоненты (элементы) потока x1,x2,…,xn сопоставить  вершинам графа x1,x2,…,xn и каждую пару вершин xi и xj соединить дугой, идущей от xi к xj в том и только в том случае, когда компонента xi является   входом компоненты xj, то получится схема, называемая информационным графом. Информационный граф может быть построен для уровня документов, уровня показателей и синтетического уровня (документы и показатели).

Пользуясь известными свойствами графов, можно выявить ряд важных  характеристик схем потоков информации. Для этого образуем матрицу А с n строками и k столбцами А=║aij║, где

 

Если G – информационный граф и А – его матрица смежности, то элемент a (λ) ij матрицы А(λ) , полученной возведением матрицы А в степень λ, равен числу различныых путей длиной λ, идущих от вершин xi и xj.

Последовательность матриц А1, А2,…, АN и матрица  позволяют выявить следующие свойства  схемы потока информации:

Свойство1.  Порядок πj компоненты xj формально определяется соотношением

 δ j (λ ≤ πj) >0;

 δ j (λ = πj+1) =0 ,

где δ j (λ) – сумма элементов j-го столбца матрицы Аj; πj – номер такта (длина наибольшего пути, связывающего xi с xj), к которому «готовы» все составляющие элементы потока xi к xj.

Свойство 2. Число  (максимум находится по всем компонентам потока) называется порядком информационного графа. Для N справедливо соотношение АN ≠ 0 и АN+1 = 0. Соответствующая схема потока называется N-тактичной.

Свойство 3. Признаком контура (ошибка обследования) служит появление ненулевых элементов на главной диагонали любой из матриц Аλ.

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

Свойство 5. Аналогично свойству 4, равенство нулю суммы элементов строки матрицы А служит признаком для выделения выходных функциональных результатов, а сумма этих чисел равна числу компонент, в которые входит xj.

Свойство 6. Если при некотором i=j одновременно δ j (λ=1)=0 и δ i (λ=1)=0, то к рассматриваемой схеме потока информации эта компонента отношения не имеет (ошибка обследования).

Свойство 7. Число путей длины λ от компоненты xi к xj определяется элементом a (λ) ij матрицы Аλ.

Свойство 8. Число всевозможных путей от компоненты xi к xj определяется элементом δij матрицы δ=.

Свойство 9. Отличные от нуля элементы j-го столбца матрицы δ указывают все компоненты, участвующие в формировании xj, а ненулевые элементы i-той строки матрицы δ указывают все элементы, при формировании которых используется элемент xj.

Свойство 10. Номер такта j, после которого может быть “погашен” во внешней памяти элемент xi, равен максимальному значению порядка элемента, для которого элементы i-й строки матрицы А отличны от 0.

Свойство 11. Число тактов, в течение которых компонента «хранится» во внешней памяти, равна θi=τi – πi.

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

а) определить последовательность решения задач, установив порядок (ранг) πj каждой задачи;

б) выделить активные и пассивные компоненты потока относительно операторов управления;

в) выявить дублирующую информацию и связи;

г) подготовить данные для расчета памяти ЭВМ и организации работы системы.


БИЛЕТ_14_ Структурный анализ систем средствами IDEF-моделирования

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

Методология описания бизнес-процессов IDEF3

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

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

Пример описания процесса с использованием методологии IDEF3 изображен на рис. 3.6.1. IDEF3 может быть использован как метод проектирования бизнес-процессов, а так же он органично дополняет традиционное моделирование с использованием методологии IDEF0.

Рис. 3.6.1. Описание процесса в методологии IDEF3.

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

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

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

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

Другой важной компонентой в модели IDEF3 является действие, или «единица работы» (Unit of work – UOW). Диаграммы IDEF3 отображают действие в виде прямоугольников, причем действие именуется с использованием глаголов и отглагольных существительных. Действию присваивается уникальный идентифицированный номер, который не используется вновь даже в тех случаях, когда в процессе построения модели действие удаляется. В диаграммах IDEF3 номер действия обычно предваряется номером его родителя (см. рис. 3.6.2).

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

Рис. 3.6.2. Изображение и нумерация действий в диаграмме IDEF3

Таблица 3.1.1. Возможные типы связей между действиями

Изображение

Название

Назначение

Временное предшествование(Temporal precedence)

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

Объектный поток (Object flow)

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

Нечеткое отношение (Relationship)

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

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

Принять

   исправления

Рис. 3.6.3. Связь типа «временное предшествование» между действиями 1.1 и 1.2

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

Рис. 3.6.4. Объектная связь между действиями 1.1 и 1.2

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

Рис. 3.6.5. Связь типа «нечеткое отношение»

Наиболее часто нечеткие отношения используются для описания специальных случаев связей предшествования, например, для описания альтернативных вариантов временного предшествования. На рис: 3.6.6. вертикальные линии показывают начало; и окончание действий 1.1 и 1.2, имеющих предшественную связь. В соответствии с порядком действий, показанным на рис. 3.6.3, внесение исправлений в работу начинается после принятия всех замечаний от рецензентов.

Рис. 3.6.6. Временная шкала выполнения действий для рис. 3.6.3.

Связь нечеткого отношения, альтернативная предшественной связи на рис. 3.6.3, представлена на рис. 3.6.7. В этом примере внесение исправлений начинается по мере получения замечаний от рецензентов, т.е. до непосредственного окончания действия по принятию замечаний.

Рис. 3.6.7. Альтернативная связь предшествования

На рис. 3.6.8 приведена соответствующая этой ситуации временная шкала.

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

Рис. 3.6.8. Альтернативная временная шкала

  Начало А1.2  Окончание А1.2

Рис. 3.6.9. Вариант альтернативной временной шкалы 

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

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

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

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

• сворачивающие соединения объединяют потоки. Завершение одного или нескольких действий вызывает начало выполнения другого действия.

В табл. 3.1.2 объединены три типа соединений.

Таблица 3.1.2. Типы соединений

Графическое обозначение

Название

Вид

Правила инициации

&

Соединение «и»

Разворачивающее

Каждое конечное действие обязательно инициируется

Сворачивающее

Каждое исходное действие обязательно должно завершиться

X

Соединение «эксклюзивное “или”»

Разворачивающее

Одно и только одно конечное действие инициируется

Сворачивающее

Одно и только одно исходное действие должно завершиться

O

Соединение «или»

Разворачивающее

Одно или несколько конечных действий инициируются

Сворачивающее

Одно или несколько исходных действий должны завершиться

Примеры разворачивающих и сворачивающих соединений приведены на рис. 3.6.10.

Рис. 3.6.10. Два вида соединений

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

Соединение «эксклюзивное “или”». Вне зависимости от количества действий, связанных со сворачивающим или разворачивающим соединением «эксклюзивное “или”», инициировано будет только одно из них, и поэтому только оно будет завершено перед тем, как любое действие, следующее за сворачивающим соединением «эксклюзивное “или”», сможет начаться. Если правила активации соединения известны, они обязательно должны быть документированы либо в его описании, либо пометкой стрелок, исходящих из разворачивающего соединения, как показано на рис. 3.6.12.

Рис.3.6.11. «И»-соединения

Рис. 3.6.12. Соединение «эксклюзивное “или”»

Соединение «или» предназначено для описания ситуаций, которые не могут быть описаны двумя предыдущими типами соединений. Аналогично связи нечеткого отношения соединение «или» в основном определяется и описывается непосредственно системным аналитиком. На рис. 3.6.13 соединение J2 может активизировать проверку данных чека и/или проверку суммы наличных. Проверка чека инициируется, если покупатель желает расплатиться чеком, проверка суммы наличных – при оплате наличными. И то, и другое действие инициируются при частичной оплате как чеком, так и наличными.

Рис. 3.6.10. Соединение «или»

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

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

Таблица 3.1.3. Виды синхронных соединений

Графическое обозначение

Тип

Вид

Правила инициации

&

Соединение «и»

Разворачивающее

Все действия начнутся одновременно

Сворачивающее

Все действия закончатся одновременно

О

Соединение «или»

Разворачивающее

Может быть, несколько действий начнутся одновременно

Сворачивающее

Может быть, несколько действий закончатся одновременно

Х

Соединение «эксклюзивное «или»»

Разворачивающее

Одновременное начало действий невозможно

Сворачивающее

Одновременное окончание действий невозможно

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

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

Рис.3.6.14. Синхронное соединение

Парность соединений. Все соединения на диаграммах должны быть парными, из чего следует, что любое разворачивающее соединение имеет парное себе сворачивающее. Однако типы соединений не обязательно должны совпадать. На рис. 3.6.15 разворачивающее «и»-соединение имеет парное сворачивающее «или»-соединение. Интерпретация соединения J1 аналогична случаю, показанному на рис. 3.6.11. Соединение J2 интерпретируется следующим образом: после включения пожарной сигнализации и/или вызова пожарных, и/или начала тушения производится запись в журнал.

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

Рис.3.6.15. Пример комбинации двух типов соединений

Рис. 3.6.16. Диаграмма IDEF3 с комбинацией соединений

Для ссылки на другие разделы описания процесса используют указатели – специальные символы. Они позволяют привлечь внимание пользователя к каким-либо важным аспектам модели.

Указатель изображается на диаграмме в виде прямоугольника, похожего на изображение действия. Имя указателя обычно включает его тип (например, ОБЪЕКТ, UOB и т.п.) и идентификатор (табл. 3.1.4). На рис. 3.6.17 показан указатель типа ОБЪЕКТ.

Таблица 3.1.4. Указатели и их назначения

Тип указателя

Назначение

ОБЪЕКТ(OBJECT)

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

ССЫЛКА(GOTO)

Для реализации цикличности выполнения действий. Указатель ССЫЛКА может относиться и к соединению

ЕДИНИЦА ДЕЙСТВИЯ(Unit of Behavior – UOB)

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

ЗАМЕТКА(NOTE)

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

УТОЧНЕНИЕ(Elaboration – ELAB)

Для уточнения или более подробного описания изображенного на диаграмме. Указатель УТОЧНЕНИЕ обычно используется для описания логики ветвления у соединений

На рис. 3.6.18 показан пример отображения важного для данной модели отношения между действием и объектом.

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

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

  

Рис. 3.6.17. Указатель ОБЪЕКТРис.3.6.18. Указатель ОБЪЕКТ ссылается

на действие

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

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

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

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

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

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

Таблица 3.1.5. Резервирование номеров действий

Аналитик

Диапазон номеров IDEF3

1

1–99

2

100–199

3

200–299

1

300–399

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

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


БИЛЕТ_15_ Методология функционального моделирования IDEF0. Привести примеры

Методология функционального моделирования IDEF0 – это технология описания системы в целом как множества взаимозависимых действий или функций. Важно отметить функциональную направленность: IDEF0-функции системы исследуются независимо от объектов которые обеспечивают их выполнение. "Функциональная" точка зрения позволяет четко отделить аспекты назначения системы от аспектов ее физической реализации. Пример диаграммы IDEF0 приведем на рис. 3.6.19 а, 3.6.19 б, 3.6.19 в, 3.6.19г.

Наиболее часто IOEF0 применяется как технология исследования и проектирования систем на логическом уровне. По этой причине IDEF0, как правило, используется на ранних этапах разработки проекта до IDEF3-моделирования, для сбора данных и моделирования процесса "как есть". Результаты IDEF0-анализа могут применяться при проведении проектирования с использованием моделей IDEF3 и диаграмм потоков данных.

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

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

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

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

Синтаксис графического языка IDEF0 включает блоки, стрелки, диаграммы и правила.

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

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

Рис. 3.6.20. Пример блока

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

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

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

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

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

I (Input) – вход – то, что потребляется в ходе выполнения процесса;

С (Control) – управление – ограничения и инструкции, влияющие на ход выполнения процесса;

О (Output) – выход – то, что является результатом выполнения процесса;

М (Mechanism) – исполняющий механизм – то, что используется для выполнения процесса, но остается неизменным.

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

Рис. 3.6.21. Каждый тип стрелки соединяется с определенной стороной функционального блока

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

Дадим подробное назначение каждой стрелки.

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

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

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

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

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

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

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

Комбинированные стрелки. В IDEF0 существует пять основных видов комбинированных стрелок: 1) выход – вход, 2) выход – управление, 3) выход – механизм исполнения, 4) выход – обратная связь на управление и 5) выход – обратная связь на вход.

1) Стрелка выход – вход применяется, когда один из блоков должен полностью завершить работу перед началом работы другого блока. Так, на рис. 3.6.22 формирование счета должно предшествовать приему заказа.

Рис. 3.6.22. Комбинация стрелок выход – вход

2) Стрелка выход – управление отражает ситуацию преобладания одного блока над другим, когда один блок управляет работой другого. На рис. 3.6.23 принципы формирования инвестиционного портфеля влияют на поведение брокеров на бирже.

Рис. 3.6.23. Комбинированная стрелка выход – управление

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

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

Рис. 3.6.24. Комбинированная стрелка выход – механизм исполнения

Рис. 3.6.25. Комбинированная стрелка выход – обратная связь на управление

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

Рис. 3.6.26. Комбинированная стрелка выход – обратная связь на вход

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

Рис.3.6.27. Разъединенная на две части и переименованная стрелка

На IDEF0-диаграммах есть еще стрелки вида (). Такие стрелки называют туннелями. Они связаны с понятием связанных стрелок, которое используется для управления уровнем детализации диаграмм. На рис. 3.6.28, например, стрелка "корпоративная информационная система" – важный механизм исполнения для данной диаграммы, но, возможно, она более нигде не используется в модели. Туннель в данном случае используется как альтернатива загромождению родительских диаграмм помещением на них несущественных для их уровня стрелок.

Рис. 3.6.28. Пример применения туннеля

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

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

Все элементы заголовка диаграммы перечислены в табл. 3.1.6.

Рис. 3.6.29. Пример применения туннеля

Таблица 3.1.6. Элементы заголовка диаграммы IDEF0

Поле

Назначение

USED AT

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

Author, date, project

Содержит ФИО автора диаграммы, дату создания, дату последнего внесения изменений, наименование проекта, в рамках которого она создавалась

Notes 1 ... 10

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

Status

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

Working

Новая диаграмма, глобальные изменения или новый автор для существующей диаграммы

Draft

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

Recommended

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

Publication

Диаграмма готова для окончательной печати и публикации

Reader

ФИО читателя

Date

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

Context

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

Все элементы "подвала" диаграммы перечислены в табл. 3.1.7.

Таблица 3.1.7. Элементы "подвала" диаграммы IDEF0

Поле

Назначение

Node

Номер диаграммы, совпадающий с номером родительского функционального блока

Title

Имя родительского функционального блока

Number (еще называют С-Number)

Уникальный идентификатор данной версии данной диаграммы. Таким образом, каждая новая версия данной диаграммы будет иметь новое значение в этом поле. Как правило, С-Number состоит из инициалов автора (которые предполагаются уникальными среди всех аналитиков проекта) и последовательного уникального идентификатора, например SDO005. При публикации эти номера могут быть заменены стандартными номерами страниц. Если диаграмма замещает другую диаграмму, номер заменяемой диаграммы может быть заключен в скобки – SDO005 (SDO004). Это обеспечивает хранение истории изменений всех диаграмм модели

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

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

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

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

• Почему моделируется данный процесс?

• Что выявит данная модель?

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

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

• Каковы задачи менеджера?

• Каковы задачи клерка?

• Кто контролирует работу?

• Какая технология нужна для выполнения каждого шага? и т.п.


БИЛЕТ_16_ Структурный анализ потоков данных в АСОИУ с помощью диаграмм DFD

Так же, как и диаграммы IDEF0, диаграммы потоков данных (Data Flow Diagrams – DFD) моделируют систему как набор действий, соединенных друг с другом стрелками. Диаграммы потоков данных могут содержать два новых типа объектов: объекты, собирающие и хранящие информацию, – хранилища данных и внешние сущности – объекты, моделирующие взаимодействие с теми частями системы (или другими системами), которые выходят за границы моделирования (рис. 3.6.36).

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

Построение DFD-диаграмм в основном ассоциируется с разработкой программного обеспечения, поскольку нотация DFD изначально была разработана для этих целей. В частности, графическое изображение объектов на DFD-диаграммах этой главы соответствует принятому Крисом Гейном (Chris Gane), Тришем Сарсоном (Irish Sarson) – .авторами DFD-метода, известного как метод Гейна-Сарсона. Другой распространенной нотацией DFD является так называемый метод Йордана-Де Марко (Yourdon-DeMarсo).

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

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

Рис. 3.6.37. Контекстная DFD-диаграмма

Функциональный блок DFD моделирует некоторую функцию, которая преобразует сырье в какую-либо продукцию (или, в терминах IDEF, вход в выход). Хотя функциональные блоки DFD и изображаются в виде прямоугольников с закругленными углами, они почти идентичны функциональным блокам IDEF0 и действиям IDEF3. Как и действия IDEF3, функциональные блоки DFD имеют входы и выходы, но не имеют управления и механизма исполнения, как IDEF0. В некоторых интерпретациях нотации DFD Гейна-Сарсона механизмы исполнения IDEF0 моделируются как ресурсы и изображаются в нижней части прямоугольника (рис. 3.6.38).

Рис. 3.6.38. Элемент DFD-диаграммы, построенной по нотации Гейна-Сарсона

Внешние сущности обеспечивают необходимые входы для системы и/или являются приемниками для ее выходов. Одна внешняя сущность может одновременно предоставлять входы (функционируя как поставщик) и принимать выходы (функционируя как получатель).


Рис. 3.6.36. Пример DFD-диаграммы

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

Рис. 3.6.39. Обозначение внешней сущности

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

Рис. 3.6.40. Двунаправленный поток между блоком и внешней сущностью

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

Рис. 3.6.41. Обозначение хранилища данных на DFD-диаграмме

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

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

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

Рис. 3.6.42. Разветвление стрелки, иллюстрирующее декомпозицию данных

Рис. 3.6.43. Объединение потоков в один

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

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

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

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

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

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

Рис. 3.6.44. Компоненты номера функционального блока DFD

Аналогично, номер каждой внешней сущности содержит префикс Е (External entity) и уникальный номер сущности в модели (например, Е5).

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


БИЛЕТ_17_


БИЛЕТ_18_


БИЛЕТ_19_


БИЛЕТ_20_


БИЛЕТ_21_ Математическая модель оптимизации движения информационных потоков в проектируемой АСОИУ

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

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

Wp (t) – входной поток первичной (внешней) информации, поступающей в подразделение p в момент времени t;

Vip (t) – информационный поток из подразделения i данной организации в подразделение p этой же организации, , i ≠ p.

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

Wp (t) = fp(t) + Sp(t) + Cp(t) + εp     (1)

где Wp(t) – объем первичной информации (в байтах, документах, документостроках и т.д.), поступающей для обработки в подразделение p в момент времени t;

fp(t) – трендовая составляющая потока;

Sp(t) – сезонная составляющая потока;

Cp(t) – циклическая составляющая потока;

εp – случайная составляющая потока, причем M[εp]=0; D[εp]=const.

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

Рассмотрим с формально-логической точки зрения процесс обработки информации в подразделении p, которое будем считать «черным ящиком», преобразующим входную информацию Vвх (совокупный объем входной информации, который поступил в момент времени t в подразделение р) в выходную Vвых . Это можно записать так:

     (2)

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

   (3)

Поэтому в динамике, т.е. с учетом временного фактора, равенство (2) примет вид:

  (4)

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

Пусть Xp(t) – объем входной информации, который может быть обработан в подразделении р в единицу времени,

Vp(t) – совокупный объем информации, поступившей в подразделение р, но не обработанной к моменту  времени t.

Тогда, если интервал времени ∆t  мал, то можно записать, что прирост необработанной информации за время   ∆t:

Vp (t + ∆t) – Vp (t) = (Vpвх(t) – Xp(t)) ∆t + O (∆t2)    (5)

Поделив (5) на ∆t при ∆t→0, получим:

   (6)

Дифференциальное уравнение (6) определяет динамику изменения объема необработанной в подразделении р информации.

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

,          (7)

где  - количество информации, поступившей в подразделение р из других (n – 1) подразделений организации,

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

Введем еще одни обозначения.

Обозначим через ψpj(Vpвых) функции, характеризующие объем информации, передаваемой от подразделения р подразделению с номером .

Поскольку в действительности

         (8)

то вся вновь созданная в подразделении р информация распределяется между (n–1) подразделениями организации в соответствии с функциями:

  (9)

Теперь можно определить структуру модели. Основные соотношения из (6), (7), (8) и (9) следующие:

      (10)

          (11)

,          (12)

где Wp(t) определяется формулой (1).

Считая заданными функции  – определяется структурой и назначением подразделений организации.

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

для определения эндогенных, т.е. внутренних, n2+2n переменных модели, т.е. функций

Vp(t) – объем необработанной информации в единицу времени информации в подразделении р,

v pj(t) – объемы информации, передаваемой от одного подразедления к другому,

Xp(t) – объем информации, обрабатываемой в единицу времени подразделением р,

имеем n дифференциальных и n2 обычных уравнений.

Поскольку система уравнений (10) – (12) является неопределенной, то представляет интерес постановка задачи как оптимизационной.

Пусть:  – предельная пропускная способность подразделения p в момент времени t. Ее величина соответствует полной загрузке персонала и технических средств данного подразделения;   – предельная пропускная способность подразделения в начальный момент времени;

Cp(Xp) – заданная функция величины затрат на обеспечение пропускной способности подразделения p в размере X единиц информации в единицу времени. Эти затраты складываются из заработной платы сотрудников данного подразделения и средств, необходимых для технического обслуживания ПЭВМ, другой вычислительной и оргтехники, а также затрат на сопровождение ПО;

Up(t) – прирост максимальной пропускной способности подразделения в период t. Отрицательная величина соответствует продаже или выходу из строя тех или иных технических средств, увольнению или болезни сотрудников и т.д.; т.е.

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

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

   (13)

,      (14)

,         (15)

,   ,  (16)

,        (17)

,      (18)

,      (19)

,      (20)

Здесь Т – горизонт планирования, а – ограничения на величину «задолженности» подразделения р по обработке информации. Введение ограничений (20) необходимо для обеспечения формального  требования неотрицательной величины необработанной информации, т.к. обработка информации «впрок» до ее получения невозможна. Ограничение сверху на Vp(t) объясняется требованием завершения обработки информации в срок по всем цепочкам процессов ее преобразования.

Рассмотренный вариант модели соответствует полностью распределенной обработке данных в организации, т.к. условиями (17) задаются ограничения на пропускные способности каждого подразделения, чем неявно предполагается возможность перераспределения технических средств между ними. При централизованном варианте СОД условия (17) должны быть заменены на:

,         (21)

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

Кроме того, вместо системы функций , Up(t) должна рассматриваться лишь пара функций  и U(t), где U(t) – прирост мощностей по обработке информации специализированного вычислительного подразделения в момент времени t. При этом условия (18) и (19) заменяются на:

,       (22)

,       (23)

и требуют переопределения функции  и Kp(U).

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

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

    (24)

а ограничения (20) должны быть заменены на

     (25)

     (26)

где  c(t) – лимит на текущие затраты учреждения в период t,

k(t) – лимит на капитальные затраты учреждения.

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

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


БИЛЕТ_22_ Построение макромодели АСОИУ на предпроектной стадии ее разработки

Одной из важнейших целей предпроектного анализа создаваемой АСУ является построение ее макромодели. Такая макромодель состоит из 4-х матриц следующего вида:

а)  цели системы управления – (матрица Φ0),

б)  цели системы управления – функции (матрицы Φ1),

в)  функции системы управления – задачи (матрицы Φ2),

г)  задачи – информационные потребности (матрицы Φ3).

Для построения этих матриц может применяться экспертный метод.

Рассмотрим, как строятся эти матрицы, и какие результаты  можно получить путем их анализа.

Начинается построение макромодели с построения матрицы «цели - цели» (Φ0). Пусть путем экспертного опроса выявлены цели проектируемой АСУ:

Таблица 3.2

Номер цели

Формулировка цели

Обеспеч цели

1

Увеличить выпуск _________________ продукции до 10 тыс. шт.

2 и 7

2

Повысить рентабельность производства

–

3

Обеспечить ритмичность работы производства

2

4

Повысить обоснованность планов

3

5

Обеспечить выполнение заказов в срок

3

6

Упорядочить потребление материалов

2

7

Повысить качество продукции

2

Полученные данные можно представить в виде графа целей G1 и матрицы  целей Φ0.

Рис. 3.7 Граф целей G1

Матрица целей Ф0

цель

цель 

1

2

3

4

5

6

7

1

1

1

2

3

1

4

1

5

1

6

1

7

1

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


БИЛЕТ_17_


БИЛЕТ_17_


БИЛЕТ_17_


БИЛЕТ_17_


БИЛЕТ_17_


БИЛЕТ_17_


PAGE  2


Логическое проектирование

Эскизный проект

Техническое задание

Концептуальное проектирование

Определение требований к АСУ

Решение о разработке АСУ

EMBED Photoshop.Image.6 \s

EMBED Photoshop.Image.6 \s

EMBED Photoshop.Image.6 \s

5                   g6                   g7   

7

6

5

4

3

2

1

g1                               g2                   g3                   g4   

Внести исправления

1.2

Принять рекомендации рецензентов

1.1

0, если xi не соединяется с xj

1, если xi соединяется с xj

aij=




1. Лекция 2 ОБЩИЕ СВОЙСТВА И ФУНКЦИИ КРОВИ Кровь и лимфу принято называть внутренней средой организма
2. на тему- Международный имидж России и способы его оптимизации Специальность ~ Связи с общественностью
3. Реферат Что мы знаем о финансах шесть важнейших финансовых концепций
4. Бельгия
5. Эндокринная система
6. Этапы становления Киевской Руси
7.  Основные понятия и методы защиты данных Интерес к вопросам защиты информации в последнее время вырос что
8. Вступление Хорошо поставленный голос ясная и правильная речь это залог вашего успешного общения
9. Методические рекомендации к составлению конспектов утренней гимнастики физкультурных занятий вопросы для
10. Острая внебольничная пневмония
11. Красноярский медицинский техникум группы курса специальности 060501 Сестринское дело
12. ИНСТИТУТ МЕЖДУНАРОДНЫХ ЭКОНОМИЧЕСКИХ СВЯЗЕЙ Факультет мировой экономики и международной торговли
13. Основные понятия Специальная обработка ~ это комплекс организационных и технических мероприятий по
14. Обеспечение правомерности и законности сделок с недвижимостью
15. Реферат Правоспособность граждан
16. Общая и неорганическая химия Л
17. Які мутації називають генні Генні мутації ~ зміни нуклеотидної послідовності ДНК в межах одного гена
18. варианты решения конфликтных ситуаций
19. .Г. г. Казатин ул.
20. . Общие положения

Материалы собраны группой SamZan и находятся в свободном доступе