Министерство образования Российской Федерации Государственное образовательное учреждение высшего профессионального образования Таганрогский государственный радиотехнический университет
В.И.ФИНАЕВ А.В.ПУШНИН
ИНФОРМАЦИОННОЕ ОБЕСПЕЧЕНИЕ СИСТЕМ УПРАВЛЕНИЯ
Таганрог 2003
2 УДК 681.3 В.И.Финаев, А.В.Пушнин. Информационное управления. Таганрог: Изд-во ТРТУ, 2001. 91 с.
обеспечение
систем
Изложены основные сведения, необходимые при изучении дисциплины «Информационное обеспечение систем управления». Рассматриваются основные этапы проектирования информационно-управляющей системы, функциональное проектирование SADT-технологии; информационное обеспечение, базы данных, системы управления базами данных, языки описания данных и языки манипулирования данными в системах управления базами данных. Монография предназначена для студентов и аспирантов высших учебных заведений.
Печатается по решению редакционно-издательского Таганрогского государственного радиотехнического университета.
совета
Рецензенты: Региональный (областной) центр новых информационных технологий, директор центра, д.т.н., профессор В.М.Курейчик; А.В. Маргелов, д.т.н., профессор, ведущий научный сотрудник ТНИИС.
©
Таганрогский государственный радиотехнический университет, 2003
3 Содержание ВВЕДЕНИЕ ГЛАВА 1. ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОУПРАВЛЯЮЩЕЙ СИСТЕМЫ 1. ИНФОРМАЦИОННО-УПРАВЛЯЮЩИЕ СИСТЕМЫ 2. СТРУКТУРА ИНФОРМАЦИОННО-УПРАВЛЯЮЩИХ СИСТЕМ 3. ИНФОРМАЦИОННЫЙ АНАЛИЗ ИНФОРМАЦИОННОУПРАВЛЯЮЩИХ СИСТЕМ 4. МЕТОДОЛОГИЯ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННО-УПРАВЛЯЮЩИХ СИСТЕМ 4.1. Начальные этапы разработки 4.2. Организация разработки информационно-управляющих систем 4.3. Рабочая документация по проектированию 4.3.1. Техническое задание на ИУС 4.4.2. Технический проект ИУС 4.4.3. Рабочий проект ИУС ГЛАВА 2. ФУНКЦИОНАЛЬНОЕ ПРОЕКТИРОВАНИЕ – SADT-ТЕХНОЛОГИИ 1. ПРИНЦИПЫ ФУНКЦИОНАЛЬНОГО SADT МОДЕЛИРОВАНИЯ 2. СИСТЕМЫ И МОДЕЛИ SADT 3. СИНТАКСИС И ПРИМЕНЕНИЕ ДИАГРАММ 46 4. СИНТАКСИС МОДЕЛЕЙ И РАБОТА С НИМИ 5. ПРОЦЕСС МОДЕЛИРОВАНИЯ ГЛАВА 3. ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ 1. ОПРЕДЕЛЕНИЕ БАЗ ДАННЫХ И СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ 1.1. Данные и модели данных 1.2. Связи, сущности и язык моделирования 1.3. Ключи 1.4. Целостность баз данных 2. РЕЛЯЦИОННЫЙ ПОДХОД ПРИ ПРОЕКТИРОВАНИИ СУБД 2.1. Реляционная структура данных 2.2. Реляционная база данных 2.3. Задачи проектирования 2.4. Процедура проектирования БИБЛИОГРАФИЧЕСКИЙ СПИСОК
4 6 6 12 18 24 24 26 30 30 31 33 38 38 40 53 61 65 65 65 70 74 76 77 77 79 80 86
4
Введение Государственный образовательный стандарт высшего профессионального образования Российской Федерации по направлению подготовки дипломированного специалиста 651900 «Автоматизация и управление» определяет область профессиональной деятельности «Автоматизация и управление». Автоматизация и управление - это область науки и техники, которая включает в себя совокупность средств, способов и методов человеческой деятельности, направленных на создание и применение алгоритмического, аппаратного и программного обеспечения систем и средств контроля и управления подвижными объектами, автономными системами, технологическими линиями и процессами, освобождающих человека частично или полностью от непосредственного участия в процессах получения, преобразования, передачи и использования энергии, материалов и информации. Объектами профессиональной деятельности инженеров по направлению «Автоматизация и управление» являются автоматические и автоматизированные системы и средства контроля и управления, их математическое, информационное, техническое и программное обеспечение; способы и методы их проектирования, отладки, производства и эксплуатации в различных отраслях народного хозяйства. Объектами автоматизации и управления являются: объекты промышленности, сельского хозяйства, энергетики, транспорта, торговли, медицины и т.д.; технологические и производственные процессы; техническое диагностирование, научные исследования и производственные испытания. Таким образом, современный инженер обязан знать современные информационные технологии и уметь их применять в практике проектирования информационно-управляющих и автоматизированных систем. Информационное обеспечение необходимо при решении многих задач: - построение математических моделей технических систем, технологических процессов и производств как объектов автоматизации и управления; - разработка алгоритмического и программного обеспечения систем автоматизации и управления объектами различной физической природы; - создание современных аппаратно-программных средств исследования, проектирования, технического диагностирования и промышленных испытаний средств и систем автоматизации и управления; - создание и совершенствование методов моделирования, анализа и синтеза автоматических и автоматизированных систем контроля и управления объектами различной природы, в том числе с использованием современных компьютерных технологий;
5 - проектирование архитектуры аппаратно-программных комплексов автоматических и автоматизированных систем контроля и управления общепромышленного и специального назначений в различных отраслях народного хозяйства; - разработка функциональной, логической и технической организации автоматических и автоматизированных систем контроля и управления, их технического, алгоритмического и программного обеспечения на основе современных методов, средств и технологий проектирования; - производство технических средств и программных продуктов, создание систем автоматизации и управления заданного качества; - подготовка аппаратно-программных комплексов систем автоматизации и управления и их передача на изготовление и сопровождение; - разработка программ и методик испытаний, проведение испытаний аппаратно-программных средств и систем автоматизации и управления; - организация процесса разработки и производства средств и систем автоматизации и управления заданного качества; - организация работы коллектива разработчиков, принятие управленческих решений; - планирование разработки средств и систем автоматизации и управления; - выбор технологии, инструментальных средств и средств вычислительной техники при организации процессов исследования, проектирования, технического диагностирования и промышленных испытаний автоматических и автоматизированных систем контроля и управления. Данное пособие содержит три главы. В первой главе изложены основные сведения по методам проектирования информационно-управляющих систем. Определены основные понятия, рассмотрены структуры, приведена методика информационного анализа и методология проектирования информационно-управляющей системы. Во второй главе изучаются принципы функционального проектирования –SADT-технологии. Рассмотрены системы и модели SADT, синтаксис моделей и работа с ними, процесс моделирования. В третьей главе изложены основы проектирования баз данных. Приведены определения основных понятий баз данных и системы управления базами данных. Изложен реляционный подход при проектировании систем управления базами данных.
6
ГЛАВА 1 ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОУПРАВЛЯЮЩЕЙ СИСТЕМЫ 1. ИНФОРМАЦИОННО-УПРАВЛЯЮЩИЕ СИСТЕМЫ Под системой понимают множество элементов, находящихся в отношениях и связях друг с другом, которое образует определенную целостность, единство [1 - 4]. Представление о системе связывается с такими понятиями, как элемент, целостность, структура, связь, отношение, подсистема. Понятие «система» предполагает рассмотрение объекта как целого, состоящего из совокупности элементов. Любую систему можно расчленить на конечное число частей, называемых подсистемами. Каждую подсистему, в свою очередь, можно разделить на конечное число более мелких подсистем, вплоть до получения подсистем первого уровня — так называемых элементов системы. Под структурой системы понимают относительно устойчивый порядок внутренних пространственных связей между ее отдельными элементами, определяющий функциональное назначение системы и ее взаимодействие с внешней средой [5]. Под целостностью (эмерджетностью) системы понимается принципиальная несводимость свойств системы к сумме свойств составляющих ее элементов и невыводимость из последних свойств целого (т.е. системы). Известны три типа связей между элементами: функционально необходимые, сингерические (которые при кооперативных действиях некоторых частей обеспечивают увеличение их общего эффекта до величины, большей суммы эффектов от тех же независимо действующих частей), избыточные (являются излишними или противоречивыми). Изменение состояния системы влияет на состояние ее выходов. Желаемое состояние выходов называется целью системы, а функция, определяющая изменение состояния выходов, — целевой функцией системы. Для оценки отклонения фактического состояния выходов от желаемого вводится критерий цели. Системой управления называется система, в которой реализуется процесс управления путем взаимодействия объекта управления и управляющей части. Различают автоматические и автоматизированные (информационноуправляющие) системы управления. В системах автоматического управления (САУ), состоящих из объекта управления и управляющего
7 устройства (управляющей части), человек непосредственного участия в процессе управления не принимает. В информационно-управляющих системах (ИУС) предполагается обязательное участие людей в процессах управления. Сбор, анализ и преобразование информации в информационно-управляющих системах выполняется с помощью вычислительной техники. ИУС - система управления с применением современных автоматических средств обработки данных (ЭВМ, автоматических устройств накопления, регистрации, отображения и др.) и экономико-математических методов для решения основных задач управления производственно-хозяйственной деятельностью предприятия. ИУС - человеко-машинная система, использующая современные экономико-математические методы, средства электронно-вычислительной техники и связи, а также новые организационные принципы управления для отыскания и реализации на практике наиболее эффективного управления соответствующим объектом (системой). В экономических (организационных) информационно-управляющих системах в качестве элементов можно рассматривать: - средства производства (установки, оборудования, инструмент); предметы труда (сырье, материалы, полуфабрикаты), - трудовые ресурсы (рабочие, инженерно-технические работники, служащие); - техническую и технологическую документацию (чертежи, инструкции, стандарты, управляющие и отчетные документы и пр.). Все составные части ИУС требуют привлечения специалистов различных областей знаний. Работы в области автоматизации процессов управления требуют глубокого анализа сущности автоматизируемых процессов, выделения объектов автоматизации, правильного формулирования целей управления и определения этапности автоматизации с учетом реальных сроков, возможностей технической реализации и экономических факторов. Объектом управления в ИУС может быть рабочее место, конвейер, участок, цех, предприятие, объединение и т.д. К объекту управления относят ту часть элементов, которые непосредственно участвуют в процессе материального производства и его обслуживания. К управляющей части системы относят множества элементов, необходимых для осуществления процесса управления объектом. Это управленческий персонал, технические средства и методы управления. Управляющая часть системы оперирует с документами. Поэтому для эффективного управления производственной системой необходим непрерывный обмен информацией между объектом управления и управляющей частью. В управляющую часть информация поступает от вышестоящих организаций (государственный план и директивные указания) и от объекта
8 управления (сведения о поступлении материалов, деталей, комплектующих изделий, притоке рабочей силы; о выпуске продукции и ее качестве, затратах материалов и труда; о причинах, нарушающих нормальное протекание производственных процессов - срыве поступления материалов, поломках оборудования, браке). Управляющая часть вырабатывает управляющие воздействия на объект управления и отчетную информацию для вышестоящих организаций. Процесс выработки управляющего воздействия на объект управления имеет следующие этапы: - определение цели воздействия и установление возможных изменений в других подсистемах; - разработка путей, методов и средств воздействия; - создание организационной системы; - принятие решения, его внедрение; - контроль хода внедрения; - коррекция воздействия в ходе реализации принятого решения. Современные ИУС представляют собой сложные человеко-машинные системы, в которых сочетается машинная переработка информации с координирующей деятельностью человека-оператора. За человеком остаются наиболее сложные, не поддающиеся формализации задачи, такие, например, как постановка проблемы, принятие решения в условиях неполной информации и неопределенности, контроль переработки информации. Поэтому важной задачей при создании информационно-управляющей системы является правильное распределение функций между человеком и ЭВМ. Рассмотрим, как можно оценить эффект от внедрения ИУС. В качестве критерия обычно используют прибыль. Этот критерий лучше других возможных показателей отражает рост национального дохода, способствует ускорению ввода в действие объектов и мощностей, улучшению использования производственных фондов, увеличению объема реализованной продукции. Показатель прибыли служит основой взаимоотношений с бюджетом, а также основным источником формирования фондов предприятия. Использование прибыли в качестве критерия оптимальности сводит к минимуму количество требуемых ограничений. Эффективность внедрения ИУС можно оценивать исходя из роста прибыли. Можно использовать также в качестве критерия эффективности минимум удельных затрат труда на выполнение планов или себестоимости изготовленной продукции либо максимум чистого или валового продукта предприятия. В некоторых задачах, реализуемых с помощью ИУС, вполне возможны и целесообразны свои локальные критерии, отличающиеся от общего критерия системы, например стабильность использования ресурсов.
9 При решении многих задач надо считаться с наличием не одного, а ряда критериев. Учет многокритериальности задачи может быть сведен к формированию некоторого комплексного критерия, представляющего собой, например, сумму отдельных критериев, каждый из которых наделяется определенным «весовым» коэффициентом. В основу разработки ИУС положены следующие принципы: новых задач, системного подхода, первого руководителя, непрерывного развития системы, автоматизации документооборота, согласованности пропускных способностей отдельных частей системы, типовости, однократности ввода данных и др. Эффективность ИУС повышается при решении задач, которые при традиционной технологии управления невозможно решить либо они решаются частично (принцип новых задач). К ним относятся задачи оптимизации. На уровне предприятия это задачи определения оптимального производственного плана, оптимального оперативно-календарного планирования, оптимального управления материальными ресурсами предприятия, оперативного анализа хода производственного процесса. Второй принцип - это системный (комплексный) подход к созданию ИУС. Проектирование должно основываться на системном анализе как объекта, так и управляющей части. Принцип первого руководителя состоит в том, что разработку и внедрение ИУС нужно производить под руководством первого руководителя соответствующего объекта. Согласно принципу непрерывного развития системы необходимо при проектировании ИУС предусмотреть возможность быстро реагировать на возникновение новых задач управления и совершенствование старых в процессе развития предприятий. Принцип автоматизации документооборота означает, что надо автоматизировать не только те или иные расчеты, но и оформление выходных документов, сбор исходных данных и в определенной мере передачу их и управляющих воздействий. Согласно принципу согласованности пропускных способностей желательно обеспечить равенство пропускных способностей последовательных звеньев. Информационный результат, выдаваемый предшествующим устройством, является исходной информацией для последующего. Поэтому устройства должны быть согласованы также по используемым в системе носителям и по кодам. Принцип типовости важен при разработке программ и сводится к максимальному использованию стандартных подпрограмм и типизации программ решения задач. Значение для информационно-управляющих систем имеет принцип однократности ввода данных в машину, согласно которому многократное
10 использование любого рода сведений при решении задач на ЭВМ не должно приводить к повторному вводу каких-то данных в память ЭВМ. Особое значение для большинства ИУС имеет проблема надежности. Для повышения надежности работы систем управления применяют высоконадежные технические средства, автоматическое резервирование важнейших узлов и блоков, введение автоконтроля и т.д. ИУС должны обладать также повышенной живучестью. Под живучестью понимают способность системы к определенной компенсации последствий нарушений и повреждений отдельных ее устройств. Живучесть позволяет системе продолжать выполнение основных функций при утрате или временном снижении некоторых второстепенных показателей (точности, быстродействия, объема обрабатываемой информации). Классификация ИУС затруднена разнообразием объектов управления, на которых эти системы могут применяться. Необходимо при классификации определить принцип управления объектом. В системе управления можно выделить три принципа: отраслевой, территориально-отраслевой и территориальный. Принцип отраслевого управления положен в основу управления тяжелой промышленностью. Принцип территориально-отраслевого управления применяется в легкой промышленности и некоторых непромышленных отраслях. Принцип территориального управления характерен для управления министерствами, ведомствами, а также деятельностью исполнительных органов местного управления. Следующий признак классификации - уровень иерархии в управлении, для которого применяется данная система. К таким уровням можно отнести: - для территориальных систем: федеральный, областной, городской, районный; - для промышленных систем: отрасль, подотрасль, объединение, предприятие, производство, цех, участок, установка. В зависимости от уровня иерархии информационно-управляющие системы подразделяются: - на автоматизированные системы управления технологическими процессами (АСУТП); - автоматизированные системы управления предприятиями (АСУП); - отраслевые АСУ (ОАСУ); - общегосударственные автоматизированные системы (ОГАС). АСУП и ОАСУ должны быть совместимы по целевым функциям, методам обработки информации, техническим средствам. Важным признаком является функциональное назначение системы или ее место в общей организационной структуре управления. По функциональным признакам выделяют, например, автоматизированные системы плановых расчетов, материально-технического снабжения, государственной
11 статистики; по производственному признаку - системы управления промышленными объектами, подготовкой производства и др.; по ресурсным признакам - системы управления объектами обеспечения различными ресурсами и услугами. По типу процесса, являющегося объектом автоматизации, можно рассматривать информационно-управляющие системы (по назначению): - управления технологическими процессами (АСУТП); - управления организационными процессами (АСОУ); - проектирования (АСПРО); - планирования и управления испытаниями (АСПИ); - управления научно-техническим прогрессом (АСУНТ). Слияние АСУТП и АСОУ дает единые интегрированные (комплексные) АСУ. В этих системах большая часть информации циркулирует в виде кодированных сигналов и специальных типов документов на машинных носителях записи. По характеру производства различают АСУТП для непрерывных производств, для производств с дискретным технологическим циклом и для производств со смешанными, непрерывно-дискретными технологическими процессами. АСУТП первого типа создаются на предприятиях химической, энергетической, нефтеперерабатывающей и ряда других отраслей промышленности с непрерывными технологическими процессами. Причем параметры процессов представляют собой также непрерывные величины (давление, температура, расход жидкости и пара, концентрация смеси компонент, влажность и т. п.), измеряемые датчиками главным образом с непрерывным выходным сигналом. АСУТП второго типа внедряются на предприятиях машиностроительной, приборостроительной, радиотехнической, электротехнической и других отраслей промышленности, где производство имеет дискретный характер. На таких предприятиях используется на рабочих местах универсальное оборудование, за каждым рабочим местом закрепляется множество операций; для дискретного производства присуще наличие большого количества изделий и деталей, отличающихся трудоемкостью изготовления, технологическими маршрутами, длительностью производственного цикла, а также дискретностью параметров процессов. К производствам непрерывно-дискретного типа относятся предприятия металлургической, цементной, пищевой и других отраслей промышленности.
2. СТРУКТУРА ИНФОРМАЦИОННО-УПРАВЛЯЮЩИХ СИСТЕМ
12 Организация протекающих внутри системы информационных и управляющих процессов основана на принятой для этого внутренней структуре. При изучении характера структур любую систему можно рассматривать как некоторую совокупность взаимосвязанных элементов (объектов, понятий, процессов). Каждая такая система Sj является обособленной и может рассматриваться как некоторая часть (подсистема) более общей системы S (метасистемы): Sj∈S. Взаимосвязь между системами S и Sj строится по принципу иерархии, предусматривающей подчиненность подсистемы Sj метасистеме S как в структурном местоположении, так и в распределении управляющих функций. Разделять систему можно несколькими способами, получая различное число частей (подсистем). Полученное в результате такого членения множество всех подсистем будем называть М - множеством системы S. Метасистему S можно представить в виде дерева, на котором выделяются отдельные подсистемы, относящиеся к разным уровням (рис. 2.1). Наличие полученных при этом подсистем и взаимосвязей между ними и образует структуру системы S0. S0
S1
S11 S111
S112
S2
S12
S121
Уровень 0
S21 S122
Уровень 1
S3
S22
S231
S23
S31
S232
Уровень 2
S32
S321
S322
Уровень 3
Рис. 2.1 В ИУС организовывать подсистемы можно по функциональному и организационному признаку или по составу системных элементов. Деление по функциональным признакам ведется в соответствии с имеющимися функциями системы, а по организационным - с учетом специфических особенностей иерархической структуры системы. Членение системы по составу элементов производится с учетом структуры самих элементов при выполнении ими функций. Подсистему можно рассматривать как некую часть системы, сформированную и выделенную по определенному признаку, охватывающую соответствующую группу задач и имеющую самостоятельную частную цель. Под иерархичностью структуры системы управления понимается пирамидальный принцип ее построения с подчинением низших ступеней
13 высшим. Функции контроля и управления распределяются на несколько уровней с приоритетом управляющих сигналов старших уровней. Иерархическое строение системы обеспечивает повышенную устойчивость к внешним возмущениям, позволяет локализовать конфликты, возникающие внутри системы, является основным условием согласования элементов системы с ее глобальными целями. Пример иерархической структуры управления отраслью промышленности приведен на рис. 2.2. Министр Директор объединения Начальник производственнодиспетчерского отдела
Начальник цеха
Начальник цеха
Начальник цеха
Цех №1
Цех №1
Цех №1
Рис. 2.2 Важное значение при управлении иерархической системой имеет проблема координации. Координация как функция управления представляет собой процесс, направленный на обеспечение пропорционального и гармоничного развития совокупности различных сторон объекта (технической, производственной и др.) при оптимальных для данных условий трудовых, денежных и материальных затратах. Координирование подсистем означает такое воздействие на подсистемы, которое заставляет их действовать согласованно. Процесс координирования в общем случае подразделяется на две части: установление операционных правил, предписывающих членам организации, как они должны действовать (выбор способов координации), и практическое обеспечение выполнения этих правил в деятельности организации (выбор конкретных значений координирующего воздействия). Централизация - это концентрация принятия решений на высшем уровне, децентрализация - делегирование ответственности за ряд основных решений на более низкие уровни иерархии. Централизация непосредственно решает проблему координации и управления деятельностью подразделений, помогает устранять дублирование функций и нежелательное
14 «соперничество» между руководителями подразделений при принятии решений. Децентрализация способствует принятию решений на том уровне, где легче всего выработать наилучшие решения и получить всю необходимую информацию. Проблему соотношения централизации и децентрализации следует рассматривать с позиций рационального сочетания автономии и координации. ИУС, как и любая система управления, состоит из четырех основных компонентов: - объективно необходимых функций (работ) управления: планирование, учет и регулирование; - структуры подразделений аппарата управления; - производственно-экономической информации; - технических средств сбора и преобразования информации. В организационной структуре ИУС можно выделить служебные, функциональные, информационные и технические связи. Служебная связь (линейная) - связь между выше- и нижестоящими элементами. Функциональная связь - связь между выше- и нижестоящими элементами, но при этом вышестоящий элемент уже не решает того, что должен делать нижестоящий (указания, рекомендации). Информационная связь — связь между элементами, обычно стоящими на одном уровне и обменивающимися осведомительной информацией. Техническая связь - связь между работниками, выполняющими одну и ту же функцию. Определяющими являются служебные и функциональные связи. В зависимости от вида связей элементы структуры делятся на линейные, функциональные и обслуживающие. Линейные элементы реализуют весь объем функций управления: они выполняют основные управляющие функции, несут всю полноту власти и ответственности за итоги деятельности и использование рекомендаций и советов вспомогательных элементов. Функциональные элементы изучают отдельные функции управления (планирование, прогноз, анализ) и выступают в роли экспертов линейных элементов. Обслуживающие элементы (канцелярия, архив) обеспечивают работу основных и функциональных элементов. В реальной структуре управления помимо указанных трех типов элементов выделяется еще ступень руководства, под которой понимают совокупность звеньев, расположенных на одном уровне. Количество нижестоящих элементов, подчиняющихся вышестоящему элементу, называется радиусом действия руководителя.
15 Структуры реальных систем управления можно разделить на три основных типа в зависимости от вида связей между элементами: линейная функциональная, линейно-функциональная, матричная. При линейной структуре, показанной на рис.2.3, каждый элемент имеет только одного непосредственного «начальника». Связи - линейные. Такая структура предполагает четкое распределение полномочий и обязанностей каждого элемента. К недостаткам такой структуры относится трудность координации между элементами на первой ступени. Элемент А
…
Элемент В1
Элемент C1
…
Элемент C2n
Элемент Вn
Элемент Cn1
…
Элемент Cnn
Рис. 2.3 При функциональной структуре, приведенной на рис.2.4, предполагается введение специализации руководителей. В этой структуре не решена проблема координации, т.к. каждый нижестоящий элемент получает указание от нескольких руководителей, и поэтому не всегда можно определить порядок их выполнения. Управляющий элемент по функции
А1
В11
…
Управляющий элемент по функции
Аn
…
В1n
Вn1
…
Вnn
Рис. 2.4 При линейно-штабной структуре, приведенной на рис.2.5, за основу принимается линейная структура, но к каждому руководителю прикрепляется группа (штаб) квалифицированных специалистов. При этом обеспечивается высокое качество принимаемых решений, но при усложнении функций управления штаб увеличивается.
16 В линейно-функциональной структуре, приведенной на рис.2.6, можно реализовать основные достоинства как линейной, так и функциональной структур. Для этого помимо линейных связей вводятся и функциональные связи между штабами. При усложнении управления и дальнейшей специализации отдельных функций число связей возрастает и возникает проблема координации и согласования указаний различных функциональных служб штаба. Эту проблему должны решать линейные элементы. Штаб А1
Штаб B1
C11
Элемент А1
В1
…
Вn
C1n
Cn1
Штаб Bn
…
Cnn
Рис. 2.5 Штаб А1
Штаб B1
C11
Элемент А1
В1
…
Вn
C1n
Cn1
Штаб Bn
…
Cnn
Рис. 2.6 При матричной структуре управления, вид которой приведен на рис.2.7, на время выполнения отдельных проектов создаются подвижные группы из специалистов отдельных функциональных служб. Каждый специалист находится в двойном подчинении. Функциональные службы отвечают за профессиональную подготовку своих специалистов и подбирают исполнителей для каждой конкретной темы, а руководитель проекта непосредственно отвечает за выполняемую работу во время проектирования. Известны два основных подхода к созданию эффективных систем управления. Первый основан на модели процесса управления. Согласно этому подходу
17 (называемому иногда дескриптивным), подробнейшим образом изучают действующую управляющую часть системы и строят модель процесса управления. Руководство
Руководитель проекта А
Руководитель проекта В
Конструкторский отдел Инженерконструктор по проекту А
Производственный отдел Техник по проекту А
…
…
Инженер конструктор по проекту В
Техник по проекту В
Отдел планирования Инженерплановик по проекту А …
Инженер плановик по проекту В
Технологический отдел Инженертехнолог по проекту А …
Инженер технолог по проекту В
Рис. 2.7 Второй подход основан на модели объекта управления. Такая модель (которую называют прескриптивной) реализует предъявляемые к конкретному объекту требования и цели его функционирования и позволяет сформировать отвечающий им процесс управления. Даже на основе результатов исследования объективных закономерностей и условий функционирования объекта обычно не удается построить единую модель объекта управления. Создается комплекс взаимосвязанных моделей, каждая из которых отражает закономерности функционирования той или иной подсистемы или решение конкретной задачи системы. Методологической основой проектирования организационных структур управления служит системный анализ. Одной из исходных посылок этой методологии является необходимость построения организационной структуры, ориентированной на определение целей и подцелей, методы решения той или иной задачи. Организационная структура строится на основе структуры решений и требуемых для их реализации ресурсов [6]. Системный анализ осуществляется в следующем порядке. Первый этап - постановка задачи, включающая определение изучаемого объекта, постановку целей и задание критериев. Второй этап - осуществление первичной структуризации исследуемой системы. При определении границ системы в нее стараются включить все элементы, оказывающие сколько-нибудь существенное воздействие на функционирование. Принимают во внимание воздействие внешней среды на систему, обратное влияние считается несущественным. Первичная структуризация состоит в ориентировочном членении системы на составные
18 части (подсистемы и элементы). Структуризация системы является важной отличительной чертой системного анализа. Третий этап - составление математической модели исследуемой системы. Элементы системы и воздействие на нее описывают с помощью определенных параметров. С введением параметра задается область его применения. Выявив параметры, определяют связи между ними, которые могут задаваться равенствами и неравенствами, таблицами, включающими все случаи сочетания значений параметров, и другими способами. При этом учитывают изменение значений параметров во времени и наличие во многих случаях не детерминированных, а вероятностных зависимостей. На четвертом этапе исследуют построенные модели и прогнозируют развитие системы, для чего на построенных моделях «проигрывают» (обычно с помощью ЭВМ) варианты тех или иных воздействий внешней среды и выявляют возможные результаты. Пятый этап - анализ результатов прогнозирования, полученных на предыдущем этапе, проверка их соответствия целям и критериям, разработка рекомендаций по необходимому совершенствованию. Далее снова повторяют четвертый и пятый этапы, вплоть до получения приемлемого результата.
3. ИНФОРМАЦИОННЫЙ АНАЛИЗ ИНФОРМАЦИОННОУПРАВЛЯЮЩИХ СИСТЕМ Под информационным анализом понимают изучение состава документов и определение объема формируемой и используемой информации, а также разработку схемы документооборота предприятия и модели информационных связей. Анализ потоков и состава документированной информации на предприятии выполняется в два этапа: - изучают и упорядочивают документы и содержащуюся в них информацию, классифицируют и описывают характеристики документов и показателей; - анализируют применяемую на предприятии документированную информацию и разрабатывают рекомендации по устранению бесполезной ее избыточности и по рационализации информационных связей и структуры документов. Для анализа документированной информации необходимо определить состав исходного множества применяемых на предприятии документов и содержащихся в них наименований показателей, а также классифицировать документы и показатели на группы по сходным частным признакам. Анализ информационных характеристик объекта автоматизации проводится на основе собранных материалов обследования после их
19 предварительной обработки и систематизации. Работы по анализу рекомендуется проводить в следующей последовательности: - составление перечня документов, формируемых в каждом структурном подразделении или функциональной подсистеме, и группировка документов по основным классификационным свойствам; - анализ терминологии, применяемой в документах, и обеспечение смыслового единства информации; - систематизация, группировка и анализ применяемых показателей; - классификация показателей, разработка системы кодирования и шифрации документов и показателей; - построение схем документообразования (схем взаимосвязи документов) и определение уровня документов внутри подразделения (начальный, промежуточный, конечный); - построение маршрутов движения документов в структурных подразделениях и функциональных подсистемах, - анализ маршрутов движения документов и выявление элементов нерациональной организации информационных потоков, - построение схем взаимосвязи показателей и их анализ; - анализ алгоритмов формирования показателей; - построение схемы документооборота в целом по предприятию составление информационной модели объекта; - расчет объемов и интенсивностей потоков информации в структурных подразделениях, функциональных подсистемах и в целом по предприятию за месяц, квартал и год; - разработка рекомендаций по устранению дублирования документов и и стандартизации форм документов, показателей, унификации рационализации маршрутов движения документов и схем формирования показателей. Определение общего перечня форм документов, циркулирующих в отдельных структурных подразделениях, и группировка документов по основным классификационным признакам - одна из первых задач информационного анализа информационно-управляющей системы. Все документы делят на внутренние, разрабатываемые на предприятии, и внешние, поступающие из внешней среды. Это позволяет определить документы, которые можно усовершенствовать, для которых можно изменить маршруты движения, и документы, для которых реализация этих процедур затруднительна. Значение при проектировании технологического процесса обработки данных имеет периодичность составления и обработки документов на предприятии. При анализе информационных потоков производят группировку документов, циркулирующих на предприятии, в зависимости от способа их получения. Выделяют две группы документов: первичные и сводные.
20 Первичные документы можно классифицировать по следующим признакам: - размещению в них показателей - анкетные, зональные, табличные, комбинированные; - количеству отражаемых хозяйственных операций - однострочные и многострочные; - способу охвата хозяйственных операций - разовые и накопительные; - полноте информации - с обязательным минимумом реквизитов и с частью обязательных реквизитов; - степени механизации процессов заполнения документов - полностью механизированные, частично механизированные и заполняемые вручную; - по способу обработки документов - обрабатываемые вручную, на ЭВМ. Классификация и группировка п ервичных документов по этим признакам позволяют провести их анализ для унификации. Процесс унификации документов состоит в сокращении количества их реквизитов, устранении повторяющихся показателей и перенесении постоянных и нормативных показателей в «память» системы. Интерес представляет группировка документов по их участию в формировании новых документов. После систематизации форм документов в соответствующей картотеке или справочнике форм и их группировки по основным признакам необходимо произвести шифрацию документов. При разработке системы шифрации и кодирования необходимо учесть следующие основные требования автоматизированных систем обработки данных: - минимальная разрядность кода; - определение по шифру номера подразделения, где формируется документ; - возможность классификации документа по назначению - плановый, учетный, нормативный, ответный, контрольный. Документы, идентичные по форме и применяемые для подразделений одного и того же уровня иерархии управления, вносятся в картотеку документов один раз с указанием шифров всех подразделений, где они формируются. Составляется картотека показателей, применяемых в документах. Наименование показателей образуется из наименований реквизитов-оснований и реквизитов-признаков, входящих в наименование документа. Шифры наименованиям показателей присваиваются в соответствии с классификатором наименований показателей. Для анализа маршрутов движения документов, технологии их обработки и рационализации документооборота по каждому подразделению строятся организационные схемы внутриструктурных потоков информации. Эта схема представляет собой таблицу, где в строках указаны документы и перечень операций по их обработке, а в столбцах - управленческий персонал, выполняющий операции обработки документов. Пример схемы
21 внутриструктурных потоков информации для производственного предприятия приведен на рис. 3.1. Разрабатываются схемы взаимосвязи документов, пример которой приведен на рис.3.2. Наименование документа
Перечень выполняемых операций
Структурные единицы внутри подразделения Мастер
Контроллер Нормировщик
Рабочий
Бухгалтерия
Заполнение Выдача рабочему Сменные задания
Прием продукции от рабочего Отметка об исполнении задания Оформление реквизитов
Наряд
Перенос в наряд данных о выработке Таксировка наряда Оформление наряда Передача в бухгалтерию
Возникновение документа
Движение документа
Обработка документа
Формирование на основе данного документа информации в других документах
Рис. 3.1 Чтобы детально проанализировать маршруты движения документов, для каждой функции подсистемы на основании схем взаимосвязей документов (рис.3.2) и организационных схем внутри структурных потоков информации строят схемы организации и движения информации в функциональных подсистемах, пример которой приведен на рис.3.3.
22
Отчет о выполнении плана ПЭО
ОТиЗ
ПДО
Цехпоставщик
Месячное производство Задание по расчету технически обоснованных норм
ПЭО
Отчет о об использовании рабочего времени Наряд Цех Накладная на сдачу готовой продукции
Календарный график Накладная на получение продукции
Бухгалтерия
Накладная на сдачу готовой продукции
ПДО
Суточный рапорт Акт приемки
Цех поставщик
ПЭО – планово-экономический отдел, ОтиЗ – отдел труди и заработной платы, ПДО – производственно-диспетчерский отдел
Рис. 3.2
23
Уровни управления Наименование документов
Внешний Внутренний Министерство Директор Главный ОГК ОГТ ПЭО ПДО ОМТС инженер
Конструкторскотехнологическая документация Карты сводных затрат материалов План выпуска продукции Подетальная узловая программа Расчет потребоности в материалах Возникновение документа
Движение документа
Обработка документа
Формирование на основе данного документа информации Утверждение и согласование документа в других документах ОГК – отдел главного конструктора, ОГТ – отдел главного технолога, ОМТС – отдел материально-технического снабжения
Рис. 3.3 Это позволяет представить путь движения документа от одного структурного подразделения к другому и формирование каждого документа внутри тех или иных подразделений. Условные обозначения показывают, где
24 возникает документ, где он хранится после завершения всего цикла обработки, целый ряд других операций (например, утверждение, согласование документа), количество издаваемых экземпляров и т. д.Схема дает возможность выявить: - дублирование операций, когда аналогичные по содержанию документы возникают в разнородных структурных подразделениях на основании одного и того же массива информации (элементы дублирования можно устранить изменением маршрута движения документов, созданием при формировании документа нужного числа копий и т. д.); - сложный маршрут движения документов с возвратами к исходным пунктам (эту нерациональность можно устранить перераспределением функций, их объединением и т. д.; правильное перераспределение функций меняет информационный поток, сокращает длительность прохождения документа, устраняет возвратные петли и т. д.): - несоответствие структуры и функций отдельных подразделений (при этом пути движения документов имеют изломы, так как документ передается в одно структурное подразделение и участвует в формировании какого-либо еще документа в другом подразделении). В случае соответствия структуры и функций подразделений документ используется для формирования какого-либо другого документа именно в том структурном подразделении, куда он передается. Для проектирования новых схем организации и движения информации необходимы сведения о системе экономических показателей, используемых в данной подсистеме управления, об алгоритмах и формальном математическом аппарате их получения и преобразования. Анализ системы показателей осуществляется в процессе построения структурной схемы их взаимосвязи. Схема позволяет проследить, в каком документе впервые появляется данный показатель, как он участвует в формировании производных показателей в том же документе и в какие документы он переносится. В схеме указываются алгоритмы формирования показателей. В структурной схеме взаимосвязи показателей применимы требования к движению документов. Каждый производный показатель должен образовываться в каком-то одном документе и только один раз. Во все остальные документы он переносится по мере необходимости без какихлибо дополнительных расчетных операций. Для анализа алгоритмов образования показателей следует разработать символику, представляющую показатели, признаки и операции, выполняемые над ними. На основе данных форм обследования можно рассчитать объемы информации, циркулирующей в каждом структурном подразделении или функциональной подсистеме. Для этого по каждому документу рассчитывают средний объем алфавитно-цифровой информации. С учетом периодичности заполнения определяют суммарный объем информации по данному документу за плановый период. Просуммировав информацию по
25 всем документам подразделения, функциональной подсистемы или предприятия в целом, находим общий объем информации, содержащейся в документах применительно к подразделениям или подсистемам. Результаты обследования управленческих работ и потоков информации для удобства описания и полноты анализа можно представить в виде информационных моделей. Информационная модель позволяет символически выразить технологию подготовки и маршруты движения документов, алгоритмы формирования показателей, а также взаимосвязь между всеми рабочими группами данного подразделения, подразделениями предприятия и внешней средой. Назначение модели в том, что она характеризует потоки информации, необходима для анализа документооборота, а также выбора комплекса технических средств. Для проведения анализа материалов обследования необходимо по результатам обследования сгруппировать показатели и документы по основным классификационным свойствам, проверить полноту проведенного обследования, построить схемы формирования и информационные схемы взаимосвязи показателей, документов, задач управления и схемы движения документов.
4. МЕТОДОЛОГИЯ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННО-УПРАВЛЯЮЩИХ СИСТЕМ 4.1. Начальные этапы разработки Основа методологии разработки ИУС - учет специфических особенностей, отличающих информационную систему от технических систем, соблюдение принципа проведения разработки и внедрения на основе системного анализа. Должно быть проведено всестороннее обследование системы, выполнено ее моделирование, выявлен комплекс автоматизируемых функций, определена структура системы и ее подсистем, выбран наилучший вариант из возможных проектных решений. На практике часто встречается локальный подход к проектированию ИУС. Предпроектная стадия практически игнорируется и после общего ознакомления с объектом автоматизации выбирают отдельные задачи существующей системы для решения их на ЭВМ. Организационная структура, набор и методы решения задач практически остаются неизменными. Проектирование и внедрение заключается в моделировании отдельных задач, их программировании и внедренци машинных методов расчета. Последовательно наращивая такие задачи, получают поэтапное внедрение информационно-управляющих систем. При разработке ИУС полезно выделить как самостоятельные логические этапы разработки внешнее и внутреннее проектирование. Такие аспекты
26 проектирования в ИУС четко выделены и имеют, в известной степени, самостоятельное значение. Эти этапы при разработке ИУС выполняются специалистами различного профиля. Внешнее проектирование формулирует цель и критерий эффективности будущей системы, выявляет ограничения. Создается и экспериментально проверяется модель системы. Определяются границы системы; фиксируются факторы внешней среды, имеющие значение для системы; определяются существенные связи, виды входных сигналов, на которые должна реагировать система; связанные с ними изменения выходных параметров. Затем следует этап выяснения взаимодействия системы с внешней средой; определения того, что и зачем будет делать система, почему она должна действовать именно так, а не иначе. Внутреннее проектирование определяет содержание самой системы - как, какими способами и средствами будет система выполнять свои функции, кто, где и когда будет выполнять необходимые операции и процедуры. Внешнее и внутреннее проектирование не являются самостоятельными, независимыми друг от друга этапами, они пересекаются и требуют взаимного согласования. Сначала проводится внешнее проектирование для некоторых идеальных, ничем не ограниченных внутренних возможностей системы, а затем, в первом приближении, внутреннее проектирование, выявляя при этом ограничения, не позволяющие системе функционировать так, как это требуется в результате предварительного внешнего проектирования. Согласование заключается в изменении либо требований внешнего проектирования, либо ограничений внутреннего, либо и того и другого. После такого согласования переходят к детальной, углубленной проработке вопросов внутреннего проектирования. Важное свойство любой системы - наличие связей между ее элементами, а также между системой и ее внешней средой. Связи должны быть выявлены и изучены в существующей системе управления и определены для проектируемой. Направленность связей, как правило, от входа к выходу системы (в противном случае их называют обратными связями) позволила ввести понятие потока. Основой любой производственной системы являются материальные потоки, которые на входе системы состоят из сырья, полуфабрикатов, комплектующих изделий и других исходных материалов. Материальный поток проходит через подразделения системы, где происходит обработка материалов, и поступает на выход системы в виде ее продукции. Выходная продукция одной системы может полностью или частично поступать на вход другой системы. Аналогично материальному потоку можно выделить энергетический поток тепловую и электрическую энергию; поток финансов, трудовых ресурсов и т.п. Особое значение в системах управления имеют потоки информации, или
27 информационные потоки. Их особое значение определяется ролью информации в процессе управления. На входе системы управления в состав информационного поока входит информация о состоянии управляемого объекта, о параметрах входных потоков — материальных, энергетических и других, а также информация о состоянии внешней среды. Комплекс исследований, направленных на выявление общих тенденций и факторов развития системы и определение мероприятий по ее совершенствованию, называют диагностическим анализом. Эти исследования начинают с выявления и формулировки или уточнения цели и критериев эффективности системы и ее подсистем. Сформулированные цели и критерии функционирования и развития системы являются основой для программы дальнейшего диагностического анализа, которая включает в себя выявление общих тенденций развития системы; факторов, способствующих и препятствующих достижению цели; общих и специфических свойств системы; особенностей взаимодействия с внешней средой и т. п.
4.2. Организация разработки информационноуправляющих систем Разработка ИУС представляет собой комплекс научно-исследовательских, проектных, инженерно-технических и организационных работ. Для подавляющего большинства систем установлены следующие стадии их создания: предпроектная, разработки технического и рабочего проектов и ввод в эксплуатацию. В особых случаях, при разработке сложных, уникальных информационноуправляющих систем, может быть выделена стадия разработки эскизного проекта, предшествующая техническому проекту; при разработке типовых решений для экспериментальных систем может быть установлена стадия «Анализ функционирования системы». Ход работ по созданию информационно-управляющих систем удобно представлять в виде сетевых графиков. Детальные сетевые графики разработки содержат тысячи или десятки тысяч операций; их вид определяется в значительной мере спецификой организации, для которой разрабатывается информационно-управляющая система. Рассмотрим обобщенный сетевой график укрупненных этапов разработки и внедрения системы, показанный на рис. 4.1. Работы по созданию любой ИУС начинаются с предварительного ознакомления с будущей системой, позволяющего определить целесообразность создания ИУС для данной организации или предприятия (операция 0—1). Эту работу выполняет небольшая группа высококвалифицированных специалистов, не более 4—5 человек.
28
Стадии
П Р Е Д П Р О Е К Т Н А Я Р
Обследование, подготовка техникоэкономического обоснования
0
1
План по создания информационноуправляющей системы Техникоэкономическое обоснование
2 Подготовка технического задания
3
4
Техническое задание
29 Рис. 4.1 В состав группы входят представители организации, для которой создается система, в дальнейшем именуемой «заказчиком», а также специалисты по созданию ИУС, в том числе будущий руководитель работ со стороны организации, ведущей разработку системы, в дальнейшем именуемой «разработчиком». На этом этапе в общем виде определяют основные цели и ограничения существующей и разрабатываемой ИУС, возможность повышения эффективности управления при создании ИУС. По результатам работы группы принимается решение о финансировании работ по созданию данной ИУС. После принятия решения о финансировании работ по созданию ИУС формируются коллективы, участвующие в разработке (операция 1—2), которые готовят технико-экономическое обоснование на разработку системы. Организационно-техническое руководство разработкой ИУС со стороны разработчика осуществляет главный конструктор (в научноисследовательских организациях) или главный инженер проекта (в специализированных проектных организациях). Анализирует и разрабатывает систему группа специалистов - инженеровсистемотехников. К работам по созданию систем «разработчик» может привлекать специализированные организации, которые ответственны за качество и сроки выполнения работ перед разработчиком. Разработчик отвечает за указанные работы перед заказчиком и вышестоящими организациями. Со стороны заказчика работы возглавляет главный инженер или заместитель руководителя организации. Руководитель должен обеспечить подготовку, обсуждение и утверждение технического задания; необходимые условия для эффективного сотрудничества разработчиков с коллективом своей организации; подготовку к внедрению и непосредственно внедрение и эксплуатацию системы. У заказчика создается специализированное подразделение, основные функции которого: - участие в разработке проектной документации; - контроль хода разработки; подготовка к функционированию ИУС, в том числе обучение персонала; - организация опытной эксплуатации и поэтапного промышленного внедрения задач и подсистем ИУС; - определение фактического экономического эффекта от внедрения ИУС и т. п. Для координации работ исполнителей заказчик создает специальную группу во главе с руководителем работ, в которую на правах заместителя
30 входит главный конструктор (или главный инженер проекта). Коллектив разработчиков приступает к детальному изучению и анализу существующей системы (операция 2 - 3), выполняя внешнее проектирование. Выявляются цели, критерии эффективности, существующие ограничения для системы в целом и ее подсистем, уточняется перечень подсистем, выполняемые ими функции, решаемые задачи. Параллельно с анализом существующей системы подготавливаются решения по ее совершенствованию. При изучении существующей системы анализируют организационную и функциональную структуры, технико-экономические характеристики; исследуют материальные потоки; потоки и состав информации между подразделениями и внутри них; методы планирования и учета. Завершающей работой рассматриваемого этапа является разработка технического задания (ТЗ) на создание ИУС (операции 3-4). ТЗ содержит описание основных целей создания системы, критерии эффективности ее функционирования, назначение и особенности организации управления. В нем указаны состав и характеристики комплексов решаемых задач, информационного, программного и технического обеспечения; установлены очереди разработки и внедрения, сроки их выполнения. В отдельном разделе определяют экономическую эффективность создаваемой информационно-управляющей системы. Техническое задание - официальный документ, определяющий требования к создаваемой системе. После экспертизы и корректировки ТЗ утверждают в установленном порядке. Для сложных систем, не имеющих аналогов, проводят эскизное проектирование системы (операции 4-5), рассматривают варианты структурной схемы, состав и способы формирования информационного обеспечения, укрупненные схемы алгоритмов обработки данных. Эскизный проект - документированное описание предлагаемой системы управления. Его подготовка позволяет выполнить начальные этапы проектирования, представить заказчику в удобной форме намечаемые основные проектные решения. Если принято решение о разработке эскизного проекта, он должен быть согласован и утвержден заказчиком. На стадии подготовки технического проекта решения, содержащиеся в эскизном проекте, корректируют и детализируют. После утверждения ТЗ выделяют специализированные группы, каждая из которых ведет разработку одной или нескольких подсистем (операции 46). Эти группы уточняют перечень задач по функциональным подсистемам, их постановку и алгоритмизацию. Группы работают вместе с разработчиками информационной подсистемы, проводя взаимное согласование состава и характеристик входных и выходных сигналов. Отдельные группы специалистов создают разделы технического проекта,
31 относящиеся к техническим средствам (операции 4-7) и экономической эффективности (операции 4-8). Результатом работы всех групп является технический проект (событие 9). На этапе рабочего проектирования кроме системщиков в работе участвуют программисты и специалисты по техническим средствам. Программисты разрабатывают по системным спецификациям схемы программ и программные спецификации, затем пишут и отлаживают программы (операции 9-10); проводят связную отладку комплексов программ по задачам (операции 10-11). Рабочий проект включает раздел, относящийся к техническим средствам (операции 9-10). Системщики создают рабочие инструкции персоналу ИУС (операции 9-13), одновременно ведут расчеты для раздела технического проекта по экономической эффективности системы (операции 9-14). Все эти разделы сводятся в рабочий проект (событие 11). После официального утверждения рабочего проекта начинается ввод системы в эксплуатацию. Если технические средства были готовы ранее, то на них начинается опытная эксплуатация (операции 11-15). Если технические средства не подготовлены, то ведется их монтаж и освоение (операции 11-16). Пока система может функционировать на арендуемых технических средствах, а затем опытная эксплуатация продолжается на подготовленных средствах в соответствии с рабочим проектом (операции 16-17). В период опытной эксплуатации выявляют и корректируют недостатки предыдущих этапов разработки. В конце опытной эксплуатации окончательно отрабатывают все программы ЭВМ и инструкции персоналу, отлаживают технические средства и проверяют работу ИУС при полной нагрузке в реальном масштабе времени. ИУС передается в промышленную эксплуатацию (операции 17-18), где возможна ее частичная модернизация или решение о существенной реконструкции (операции 18-0).
4.3. Рабочая документация по проектированию Разработка ИУС и состав официальной документации регламентируются общеотраслевыми руководящими методическими материалами. В настоящее время продолжают действовать стандарты, утвержденные Госкомитетом по науке и технике Совета Министров СССР, а также стандарты, введенные постановлениями Госстандарта РФ [например, 7 - 9]. Официальными рабочими документами по проектированию информационно-управляющих систем являются техническое задание, технический проект (ТП) и рабочий проект на информационноуправляющую систему.
32 4.3.1. Техническое задание на ИУС. Оно представляет собой утвержденный в установленном порядке документ, определяющий цели, требования и основные исходные данные, необходимые для разработки системы, и содержащий предварительную оценку ее экономической эффективности (ГОСТ 19675—74). Техническое задание определяет требования к задачам ИУС, техническому, информационному и математическому обеспечению системы и регламентирует организацию разработки, объемы работ и затраты. При разработке ТЗ на ИУС устанавливаются очереди создания (для АСУП не более двух) и определяется перечень подсистем и задач, предусмотренных в составе каждой очереди. Очередность разработки системы и состав очередей обуславливаются важностью принимаемого комплекса задач для данной системы, возможностью приобретения и введения в эксплуатацию необходимых технических средств соответствующего технического уровня, подготовленностью к внедрению системы, необходимостью минимизации суммарных затрат, созданием информационной базы системы, возможностью использования в последующих разработках результатов проектирования и внедрения первой очереди ИУС. Техническое задание должно содержать: - основание для разработки: постановление или приказ вышестоящей организации; - основные положения, характеризующие функционирование системы: степень централизации управления, рекомендуемый порядок планирования и учета деятельности, особенности производственных и информационных взаимосвязей и др.; - состав подсистем и задач с обоснованным указанием очередности их разработки и внедрения; - предложения по улучшению существующей системы управления; - перечень предварительно выбранных технических средств; - намечаемый размер затрат и укрупненный расчет экономической эффективности. 4.4.2. Технический проект ИУС. Он представляет собой утвержденную в установленном порядке техническую документацию, содержащую общесистемные проектные решения, алгоритмы решения задач, а также оценку экономической эффективности системы и перечень мероприятий по подготовке объекта к внедрению (ГОСТ 19675—74). Разработка ТП ведется на основании утвержденного ТЗ в такой последовательности: общий технический проект; технический проект первой очереди; технический проект второй очереди. Разработка технического проекта второй очереди может проводиться независимо от степени завершенности работ по первой очереди.
33 В отдельных сложных случаях, когда невозможно выявить рациональные проектные решения без сопоставления вариантов, на стадии технического проекта должны прорабатываться различные варианты; однако необходимость такой проработки нескольких вариантов должна быть указана в ТЗ на информационно-управляющую систему. Общий технический проект включает в себя разделы: - общая структура системы с указанием подсистем и общих принципов функционирования системы; - перечень задач, решаемых в составе каждой подсистемы, и выходные параметры задач; - схемы документооборота между подсистемами; - общие принципы математического обеспечения системы; - укрупненная структура комплекса технических средств; - важнейшие мероприятия по подготовке к внедрению системы, подготовка кадров, организация нормативного хозяйства; - расчет экономической эффективности системы; - укрупненный график разработки и внедрения системы. Технический проект имеет следующий состав документов: - ведомость технического проекта; - обоснование проектных решений: а) структуры системы, подсистем и задач, а также комплекса технических средств со ссылкой на аналогичные системы; б) данные об установленном объеме разработки системы, источниках и объеме финансирования; в) обзор аналогичных систем в виде сравнительной таблицы; - уточненная смета затрат на создание системы с учетом научноисследовательских и проектных работ, необходимых для создания данной очереди; - расчет экономической эффективности по официальной методике; - характеристика данной очереди системы в целом и отдельно по каждой подсистеме. Характеристика функциональной подсистемы, содержащая перечень подразделений, охваченных подсистемой; укрупненное описание распределения функций между подразделениями и схему информационных связей между ними; увязку задач в подсистеме. Характеристика системы в целом также содержит перечень функциональных подсистем; укрупненную схему их внешних связей; перечень и характеристики документов и сообщений, образующих эти связи; схему увязки подсистем по входам и выходам; - постановка задачи, определяющая круг объектов, для которых предназначена данная задача: а) краткое содержание постановки задачи; б) периодичность решения и временные ограничения; в) связь с другими задачами;
34 г) необходимая оперативная, нормативно-справочная и выходная информация; д) алгоритм решения и контрольный пример; - подготовка объекта к внедрению системы - документ, содержащий перечень необходимых мероприятий, исполнителей, сроки и формы завершения работ; - организация фонда нормативно-справочной информации. В документе приводится состав справочников нормативно-справочной информации с указанием задач, для которых они используются, описание организации их создания, поддержания в рабочем состоянии и методик внесения изменений; - система шифровки документов и отдельных параметров системы (реквизитов); - выбор комплекса технических средств (КТС), содержащий выбор типа и расчет количества основного и вспомогательного оборудования, расчет численности персонала, решения по периферийным техническим средствам, спецификации для размещения заказа на оборудование; - технические задания на проект монтажа периферийного КТС, содержащие чертежи размещения технологического оборудования и технические условия на монтаж; - характеристика выбранной системы математического обеспечения, содержащая описание системы и ее состав, преимущества и недостатки, технические требования на новые программы. 4.4.3. Рабочий проект ИУС. Он представляет собой утвержденную в установленном порядке техническую документацию, содержащую уточненные и детализированные общесистемные проектные решения, программы и инструкции по решению задач, а также уточненную оценку экономической эффективности автоматизированной системы управления и уточненный перечень мероприятий по подготовке объекта к внедрению (ГОСТ 19675—74). Рабочий проект содержит следующие документы: - ведомость документов рабочего проекта; - обоснование дополнительных проектных решений, принятых после утверждения технического проекта и утвержденных в установленном порядке; - уточненный расчет экономической эффективности системы по официальной методике; - технология ввода и регистрации информации; - формы первичных и промежуточных документов, заполняемых вручную и используемых для решения задач, с указанием маршрутов движения документов отдельно для каждой задачи;
35 - должностные инструкции, составляемые персонально для каждого должностного лица, участвующего в функционировании системы, с указанием действий в случае отказа технических средств; - формы нормативно-справочной информации, инструкции по их заполнению и внесению изменений; - альбом шифров, содержащий систему шифровки и альбом шифров; - программы организации и ведения массивов нормативносправочной информации, включая тип ЭВМ и необходимый комплект внешних устройств, особенности организации и ведения массивов информации, описание программ, инструкции по вводу входных документов и по эксплуатации программ, исходные тексты программ; - рабочие программы и инструкции. По каждой задаче производится описание алгоритмов и рабочих программ, инструкции по вводу входных данных и по эксплуатации программ, а также программы и контрольный пример; - характеристика комплекса технических средств, содержащая спецификацию оборудования, описание и техническую характеристику всех устройств, перечень стандартных процедур работы с ними, схему функциональных связей устройств, схему и чертежи их размещения, принципиальные электрические схемы связи и питания. Характеристика охватывает как оборудование вычислительного центра, диспетчерских пунктов, так и периферийные технические средства, располагаемые в производственных помещениях. В случае необходимости в рабочий проект включается также эксплуатационная документация на новые, нестандартные устройства, разработка которых выполнялась для данной системы, а также чертежи строительной части проекта и монтажа технических средств. Вопросы. 1. Что понимается под структурой системы? 2. Что понимается под эмерджентностью системы? 3. Какие три типа связей между элементами известны? 4. Какие принципы положены в основу разработки информационноуправляющих систем? 5. Как классифицируют информационно-управляющие системы по типу процесса? 6. Какие связи выделяют в организационной структуре информационноуправляющих систем? 7. Как можно разделить структуры реальных систем управления? 8. В чем выражен первый этап системного анализа при проектировании организационных структур управления?
36 9.. В чем выражен второй этап системного анализа при проектировании организационных структур управления? 10. В чем выражен третий этап системного анализа при проектировании организационных структур управления? 11. В чем выражен четвертый этап системного анализа при проектировании организационных структур управления? 12. В чем выражен пятый этап системного анализа при проектировании организационных структур управления? 13. Что является методологической основой проектирования организационных структур управления? 14. Что понимается под информационным анализом информационноуправляющих систем? 15. По каким признакам классифицируют первичные документы? 16. Что представляет собой внешнее проектирование? 17. Что определяет внутреннее проектирование? 18. Что называют диагностическим анализом? 19. Какие стадии существуют при проектировании систем? 20. Что содержит в себе техническое задание? 21. Какие разделы включает в себя общий технический проект? 22. Какой состав документов должен содержать технический проект? 23. Какие документы должен содержать рабочий проект? Ответы. 1. Относительно устойчивый порядок внутренних пространственных связей между отдельными элементами системы, определяющий функциональное назначение системы и ее взаимодействие с внешней средой. 2. Принципиальная несводимость свойств системы к сумме свойств составляющих ее элементов и невыводимость из последних свойств целого (т.е. системы). 3. Функционально необходимые, сингерические, избыточные связи. 4. Принципы новых задач, системного подхода, первого руководителя, непрерывного развития системы, автоматизации документооборота, согласованности пропускных способностей отдельных частей системы, типовости, однократности ввода данных и др. 5. Управление технологическими процессами, управление организационными процессами, проектирования, планирования и управления испытаниями, управление научно-техническим прогрессом. 6. Служебные, функциональные, информационные и технические связи. 7. Линейная функциональная, линейно-функциональная, матричная. 8. Постановка задачи, включающая определение изучаемого объекта, постановку целей и задание критериев. 9. Осуществление первичной структуризации исследуемой системы. При определении границ системы в нее стараются включить все элементы,
37 оказывающие сколько-нибудь существенное воздействие на функционирование. Принимают во внимание воздействие внешней среды на систему, обратное влияние считается несущественным. Первичная структуризация состоит в ориентировочном членении системы на составные части (подсистемы и элементы). Структуризация системы является важной отличительной чертой системного анализа. 10. Составление математической модели исследуемой системы. Элементы системы и воздействие на нее описывают с помощью определенных параметров. С введением параметра задается область его применения. Выявив параметры, определяют связи между ними, которые могут задаваться равенствами и неравенствами, таблицами, включающими все случаи сочетания значений параметров, и другими способами. При этом учитывают изменение значений параметров во времени и наличие во многих случаях не детерминированных, а вероятностных зависимостей. 11. Исследуют построенные модели и прогнозируют развитие системы, для чего на построенных моделях «проигрывают» (обычно с помощью ЭВМ) варианты тех или иных воздействий внешней среды и выявляют возможные результаты. 12. Анализ результатов прогнозирования, полученных на предыдущем этапе, проверка их соответствия целям и критериям, разработка рекомендаций по необходимому совершенствованию. 13. Системный анализ. 14. Изучение состава документов и определение объема формируемой и используемой информации, а также разработку схемы документооборота предприятия и модели информационных связей. 15. По размещению в документах показателей, количеству отражаемых хозяйственных операций, способу охвата хозяйственных операций, полноте информации, степени механизации процессов заполнения документов, по способу обработки документов. 16. Формулирует цель и критерий эффективности будущей системы, выявляет ограничения. Создается и экспериментально проверяется модель системы. 17. Содержание самой системы - как, какими способами и средствами будет система выполнять свои функции, кто, где и когда будет выполнять необходимые операции и процедуры. 18. Комплекс исследований, направленных на выявление общих тенденций и факторов развития системы и определение мероприятий по ее совершенствованию. 19. Предпроектная стадия, стадии разработки технического и рабочего проектов и ввод в эксплуатацию. 20. Основание для разработки: постановление или приказ вышестоящей организации, основные положения, характеризующие функционирование системы: степень централизации управления, рекомендуемый порядок
38 планирования и учета деятельности, особенности производственных и информационных взаимосвязей и др., состав подсистем и задач с обоснованным указанием очередности их разработки и внедрения, предложения по улучшению существующей системы управления, перечень предварительно выбранных технических средств, намечаемый размер затрат и укрупненный расчет экономической эффективности. 21. Общая структура системы с указанием подсистем и общих принципов функционирования системы, перечень задач, решаемых в составе каждой подсистемы, и выходные параметры задач, схемы документооборота между подсистемами, общие принципы математического обеспечения системы, укрупненная структура комплекса технических средств, важнейшие мероприятия по подготовке к внедрению системы, подготовка кадров, организация нормативного хозяйства, расчет экономической эффективности системы, укрупненный график разработки и внедрения системы. 22. Ведомость технического проекта, обоснование проектных решений, уточненная смета затрат на создание системы, расчет экономической эффективности, характеристика данной очереди системы в целом и отдельно по каждой подсистеме, постановка задачи, документ подготовки объекта к внедрению системы, фонд нормативно-справочной информации, система шифровки документов и отдельных параметров системы, выбор комплекса технических средств, технические задания на проект монтажа периферийного КТС, характеристика выбранной системы математического обеспечения. 23. Ведомость документов рабочего проекта, обоснование дополнительных проектных решений, уточненный расчет экономической эффективности системы, технология ввода и регистрации информации, формы первичных и промежуточных документов, должностные инструкции, формы нормативно-справочной информации, инструкции по их заполнению и внесению изменений, альбом шифров, содержащий систему шифровки и альбом шифров, программы организации и ведения массивов нормативно-справочной информации, рабочие программы и инструкции, характеристика комплекса технических средств.
39
ГЛАВА 2 ФУНКЦИОНАЛЬНОЕ ПРОЕКТИРОВАНИЕ SADT-ТЕХНОЛОГИИ 1. ПРИНЦИПЫ ФУНКЦИОНАЛЬНОГО SADT МОДЕЛИРОВАНИЯ Использование экспертных систем, языков программирования, систем автоматизации производства постоянно расширяется, в том числе и при проектировании автоматизированных и автоматических систем управления технологическими процессами. Эффективность применения экспертных систем, языков программирования, систем автоматизации производства зависит от способности предварить их разработку и внедрение описанием всего комплекса проблем, которые необходимо разрешить, указанием того, какие функции системы должны быть автоматизированы, определением точек интерфейса человек-машина и того, как взаимодействует система со своим окружением. Этап постановки задачи проектирования системы давно уже считается основным при создании высококачественных систем. SADT (Structured Analysis and Design Technique - технология структурного анализа и проектирования) - одна из самых известных и широко используемых систем проектирования, созданная Дугласом Т. Россом. SADT-технология нашла применение при решении задач программного обеспечения телефонных сетей, системной поддержки и диагностики, долгосрочного и стратегического планирования, автоматизации производства и проектирования, управлением финансами и материально-техническим снабжением и т.д. SADT-технология создана для описания системы и ее среды до определения требований к критериям управления, структуре системы управления, программному обеспечению и к любым другим параметрам системы управления. Создатели SADT-технологии изобрели графический языки набор процедур анализа для понимания системы прежде, чем можно представить себе ее воплощение. SADT-технология применяется на ранних этапах процесса создания системы, который называют в системном анализе «жизненным циклом системы» В SADT–технологии существует понятие SA-блока. Это обозначение связанно с иерархической многоуровневой модульной системой. Каждый уровень представлял собой законченную систему (блок), поддерживаемую и контролируемую системой (блоком), находящейся над ней. Любая система проектирования должна быть объектно-ориентированна, объекты, включая
40 системы управления, которые создаем для работы с ними, должны определяться и описываться сверху вниз до требуемого уровня детализации. На рис.1.1 представлена иллюстрация SA-блока. Управление Вход
Субъект
Выход
Механизм
Рис.1.1 Вход при наличии управления преобразуется в выход с помощью механизма (исполнителя). Выходы одного блока могут быть входами или управлениями (или исполнителями) для других блоков. Блоки именуются, а дуги помечаются с использованием естественного языка. Дуги могут разветвляться и соединяться, а каждый блок может быть декомпозирован. Входы управления и выходы определяют интерфейсы между блоками, а исполнители позволяют при необходимости в определенной степени объединять объекты. Границы блоков согласованы. Иерархия и взаимосвязанная совокупность диаграмм блоков связей являются моделью. Диаграмма ограничивается не более чем шестью блоками для того, чтобы детализация осуществлялась постепенно. Вместо одной громоздкой модели используется несколько небольших взаимосвязанных моделей, значения которых взаимно дополняют друг друга, делая понятной структуризацию сложного объекта. SADT–технология позволяет формализовать процесс создания информационной системы, ориентированной на управление, разбивая его на следующие этапы: - анализ - определение того, что система будет делать; - проектирование - определение подсистем и их взаимодействие; - реализация - разработка подсистем по отдельности; - объединение - соединение подсистем в единое целое; - тестирование - проверка работы системы; - установка - введение системы в действие; - функционирование - использование системы. Исследования показали, что большой процент ошибок в системе возник в процессе анализа и проектирования, гораздо меньше их было допущено при реализации и тестировании, а цена (временная и денежная) обнаружения и исправления ошибок становилась выше на более поздних стадиях проекта. Например, исправление ошибки на стадии проектирования стоит в 2 раза, на
41 стадии тестирования - в 10 раз, а на стадии эксплуатации системы - в 100 раз дороже, чем на стадии анализа. На обнаружение ошибок, допущенных на этапе анализа и проектирования, расходуется примерно в 2 раза больше времени, а на их исправление - примерно в 5 раз, чем на ошибки, допущенные на более поздних стадиях. Кроме того, ошибки анализа и проектирования обнаруживались часто самими пользователями. SADT–технология на начальных этапах создания системы позволяет лучше понять рассматриваемую проблему. Это сокращает затраты на создание, эксплуатацию системы, а кроме того, повышает ее надежность. SADT–технология - это способ уменьшить количество дорогостоящих ошибок за счет структуризации на ранних этапах создания системы, улучшения контактов между пользователями и разработчиками и сглаживания перехода от анализа к проектированию.
2. СИСТЕМЫ И МОДЕЛИ SADT Существует несколько определений систем [1,2,3], первые из которых базировались на понятиях элементов ai и связей гj между ними. Система S определялась следующими вариантами: (2.1) S≡
, где A={ai}, R={rj}, S≡<{ai},{rj}>, где ai∈A, rj∈R, (2.1а) S≡<{ai}&{rj}>, где ai∈A, rj∈R, (2.1б) Берталанфи определил систему как «комплекс взаимодействующих компонентов» [10] или как «совокупность элементов, находящихся в определенных отношениях друг с другом и со средой» [11]. Если элементы разнородны, то это определяет их деление на разные множества, например, A, B, C. Определение системы будет иметь вид S ≡ . Известно определение, сделанное М. Месаровичем [12]. Выделяется множество Х входных объектов и множество Y выходных результатов. Между ними установлено обобщающее отношение пересечения. Определения могут иметь вид S⊆X×Y, S⊆Х∩Y. (2.2) Если вид отношения ri применим только к элементам разных множеств и не используются внутри каждого из них, то система будет задана: (2.3) S≡<{ai,гj,bk}>, ai∈A, гj∈R, bk∈B, причем {ai,гj,bk} - элементы новой системы, образованной из исходных множеств А и В. В определение А.Холла [13] включены свойства для уточнения элементов и связей: (2.4) S≡.
42 А. И. Уёмов предложил двойственные определения, в одном из которых свойства qi характеризуют элементы аi, а в другом свойства qj характеризуют связи гj S ≡<{ai}&{rj(qi)}>, ai∈A, гj∈R, qi∈QR, (2.5) S ≡<{ai(qi)}&{rj}>, ai∈A, гj∈R, qi∈QA. Затем в определениях системы было введено понятие цели: S≡, (2.6) где Z - цель, совокупность или структура целей. Появились определения, в которых уточнены условия целеобразования среда SR, интервал времени ΔT, в течение которого будет существовать система и цели S≡. (2.7) Затем в определение системы был включен наблюдатель N: S≡, (2.8), где N - лицо, рассматривающее объект или процесс в виде системы при их исследовании или принятии решения. Известно определение Ю.И.Черняка: «система есть отражение в сознании субъекта (исследователя, наблюдателя) свойств объектов и их отношений в решении задачи исследования, познания» [14], (2.9) S≡<А,QA,R,Z,N>. В понятии системы объективное и субъективное составляют диалектическое единство. Говорят не о материальности или нематериальности системы, а о подходе к объектам исследования как к системам, о различном представлении их на разных стадиях познания и создания. Сложное взаимодействие системы с ее окружением отражено в определении В.Н.Садовского и Э.Г.Юдина, в котором: - система образует особое единство со средой; - любая исследуемая система представляет собой элемент системы более высокого порядка; - элементы любой исследуемой системы, в свою очередь, выступают как системы более низкого порядка. Выделяет систему из среды наблюдатель. Неспособность дать простое описание и обеспечить понимание систем делает их проектирование и создание трудоемким и дорогостоящим процессом и повышает степень их ненадежности. С ростом технического прогресса адекватное описание систем становится все более актуальной проблемой. SADT - это методология [15-17], разработанная специально для того, чтобы облегчить описание и понимание искусственных систем. SADTтехнология основана на концепциях системного моделирования. Описание системы с помощью SADT называется моделью.
43 В SADT-моделях используются как естественный, так и графический языки. Для передачи информации о конкретной системе источником естественного языка служат люди, описывающие систему, а источником графического языка - сама методология SADT. При применении SADT-технологии модель может быть сосредоточена либо на функциях системы, либо на ее объектах. SADT-модели, ориентированные на функции, называют функциональными моделями, а ориентированные на объекты системы - моделями данных. Функциональная модель представляет с требуемой степенью детализации систему функций, которые в свою очередь отражают свои взаимоотношения через объекты системы. Модели данных дуальны к функциональным моделям и представляют собой подробное описание объектов системы, связанных системными функциями. Применение методологии SADT обеспечивает создание множества моделей для более точного описания сложной системы. SADT-модель дает полное и адекватное описание системы, имеющее конкретное назначение. Это назначение, называемое целью модели, следует из формального определения модели в SADT: если объект М может быть использован для получения ответов на вопросы относительно системы S с точностью А, то М есть модель системы S. Если модель отвечает не на все вопросы (не позволяет решать все поставленные задачи) или ее ответы недостаточно точны, то модель не соответствует поставленной цели. SADT закладывает основы практического моделирования. Задачи для SADT-модели формулируются на раннем этапе проектирования. Суть задач должна быть выражена в одной - двух фразах. На рис. 2.2 показана разработка модели для определения цели модели экспериментального механического цеха (ЭМЦ). После постановки задачи и изучения описания процесса разработчик составил список вопросов и свел этот список в одно предложение - цель модели. Список вопросов сохраняется как детализация этого предложения. Информация, содержащаяся в модели, будет отвечать на поставленные вопросы. Моделируемая система никогда не существует изолированно, а всегда связана с окружающей средой. Иногда трудно определить, где кончается система и начинается среда. В методологии SADT подчеркивается необходимость точного определения границ системы. SADT-модель всегда ограничивает свой субъект, т.е. модель устанавливает, что является и что не является субъектом моделирования, описывая то, что входит в систему.
44
ИСПОЛЬЗУЕТСЯ В:
АВТОР: Marca ПРОЕКТ: ЭМЦ
√
ДАТА: 02/20/93 ПЕРЕСМОТР:
РАБОЧАЯ ВЕРСИЯ
ЧИТАТЕЛЬ
ДАТА
КОНТЕКСТ:
ЭСКИЗ Top
РЕКОМЕНДОВАНО ЗАМЕЧАНИЯ: 1 2 3 4 5 6 7 8 9 10
ПУБЛИКАЦИЯ
Вопросы:
Цель:
Каковы обязанности мастера? Каковы обязанности механика? Кто контролирует задание? Как продвигаются по цеху материалы? На каких этапах требуется чертеж? В какой момент на процесс влияют стандарты качества? На каких этапах требуются инструменты? Что происходит с забракованными деталями?
Определять обязанности каждого работника экспериментального механического цехи и понять, как эти обязанности взаимосвязаны между собой с тем, чтобы написать учебное пособие.
2
Претенденты: Мастер Механик Контроллер Начальник
УЗЕЛ: ЭМЦ/А-0
Начальник цеха
1
Процесс обучения для различных типов работников требует декомпозиции в зависимости от обязанностей, которые выполняют эти работники в цехе (см. замечание №5 на диаграмме DAM001).
Только с этой точки зрения можно показать взаимосвязи между отдельными работами и обязанностями персонала.
НАЗВАНИЕ: Цель и точка зрения МОДЕЛИ ЭМЦ
НОМЕР:
DAM002
Рис.2.1 С определением модели связан наблюдатель, с позиций которого изучается система и проектируется модель системы. В SADT предусмотрено рассмотрение модели с одной и той же «точки зрения». На рис.2.1 показано, что в модели экспериментального механического цеха перечисляют лиц
45 (механик, контролер), с точки зрения которых рассматривается механический цех. Заметим, что, как правило, одна из множества возможных точек зрения может дать описание, удовлетворяющее цели модели. На рис.2.1 показано, что для создания согласованной модели механического цеха можно встать на точку зрения как мастера, так и механика или контролера, но ни одна из них сама по себе не даст модели, которая позволила бы написать учебное руководство для всего персонала. С позиции начальника цеха можно увидеть все виды работ, выполняемых в цехе. С его точки зрения можно проследить взаимосвязи обязанностей различных работников Точка зрения начальника цеха позволяет проектировщику модели определить роль каждого работника в изготовлении отдельных деталей и описать координацию обязанностей персонала. После того как определен наблюдатель, формулирующий цель и точку зрения модели, начинается первая интеграция процесса моделирования по методологии SADT. Наблюдатель определяет, что включить в модель, а что исключить из нее. Точка зрения наблюдателя диктует проектировщикам модели и выбор нужной информации о наблюдателе и форму ее подачи. Окончание моделирования происходит при достижении поставленной цели. Конечный результат процесса моделирования связан с получением тщательно взаимоувязанных описаний системы, начиная с описания самого верхнего уровня системы и оканчивая описанием деталей или операций. Каждое из таких тщательно взаимосогласованных описаний называется диаграммой. SADT-модель объединяет диаграммы в иерархические структуры. Диаграммы верхних уровней иерархии модели менее детализированы, чем диаграммы нижних уровней. Модель SADT можно представить в виде древовидной структуры диаграмм, где верхняя диаграмма является наиболее общей, а самые нижние наиболее детализированы. В качестве примера на рис.2.2 представлены две диаграммы из модели экспериментального механического цеха. Верхняя диаграмма (на вершине модели) описывает механический цех как функцию, в основе которой лежит преобразование входящих рабочих комплектов (заготовок, сырья, документации) в детали при определенном контроле качества. Нижняя диаграмма детализирует верхнюю диаграмму, указывая на три главные функции механического цеха: управление выполнением заданий, выполнение задания и контроль качества выполнения. Таким образом, общая функция, указанная на верхней диаграмме, детализируется с помощью трех функций на нижней диаграмме. Это пример того, как SADT организует описание системы, создавая иерархию добавляющихся на каждом уровне деталей
46 На рис.2.2 показано также обозначенное дугами взаимное влияние трех функций нижней диаграммы, которые символизируют объекты механического цеха. Если посмотрите на диаграмму, то заметите, что некоторые дуги доходят до ее границы. Посмотрите внимательнее и увидите, что имена этих дуг совпадают с теми, что указаны на дугах верхней диаграммы. Это пример того, как SADT соединяет диаграммы в модели через объекты системы. Такая схема соединения требует согласованного наименования и учета объектов системы с тем, чтобы две диаграммы можно было рассматривать как связанные между собой Например, функциональный блок на верхней диаграмме имеет семь дуг, и каждая из них может быть найдена среди дуг, идущих к границе или от границы диаграммы на следующем уровне. Вопросы. 1. В чем состоит назначение методологии SADT? 2. Что представляет собой SADT-модель? 3. Какие основополагающие понятия существуют в SADT-модели?
47 АВТОР: Marca ПРОЕКТ: Книга
ИСПОЛЬЗУЕТСЯ В:
√
ДАТА: 03/16/92 ПЕРЕСМОТР:
РАБОЧАЯ ВЕРСИЯ
ЧИТАТЕЛЬ
ДАТА
КОНТЕКСТ:
ЭСКИЗ Top
РЕКОМЕНДОВАНО ЗАМЕЧАНИЯ: 1 2 3 4 5 6 7 8 9 10
ПУБЛИКАЦИЯ
Требования по срокам выполнения задания
Справочник стандартов качества
Рабочий комплект
Готовая деталь Изготовить нестандартную деталь
Станки и инструменты
Оценка степени завершения задания
0
Персонал механического цеха Цель:
Понять, какие функции должны быть включены в процесс изготовления нестандартной детали и как эти функции взаимосвязаны между собой с тем, чтобы написать учебное пособие для персонала цеха
Точка зрения:
УЗЕЛ: ЭМЦ/А-0
Начальник цеха
НОМЕР:
НАЗВАНИЕ: Изготовить нестандартную деталь
(DAM004) DAM005
ИСПОЛЬЗУЕТСЯ В:
АВТОР: Marca ПРОЕКТ: ЭМЦ
ДАТА: 03/16/92 ПЕРЕСМОТР:
√
РАБОЧАЯ ВЕРСИЯ
ЧИТАТЕЛЬ
ДАТА
КОНТЕКСТ:
ЭСКИЗ РЕКОМЕНДОВАНО
ЗАМЕЧАНИЯ: 1 2 3 4 5 6 7 8 9 10
Требования по срокам выполнения задания
Рабочий комплект I1
С1
ПУБЛИКАЦИЯ Справочник стандартов качества
Штамп «Принято»
С2
Статус задания
Управлять выполнением задания А1
О2
Оценка степени завершения задания О1
План выполнения задания
Готовая деталь
Чертеж
Мастер Сырье и заготовки Выполнить задание
Станки и инструменты I2
А2
Деталь с биркой
Принятое, но не законченное задание
Законченное или незаконченное задание
Брак Рабочий Контролировать качество выполнения А3
Принятое задание
Забракованное задание
Персонал механического цеха
УЗЕЛ: ЭМЦ/А-0
Контроллер М1
НАЗВАНИЕ: Изготовить нестандартную деатль
НОМЕР:
(DAM0032) DAM006
Рис.2.2
48 Ответы. 1. Сложности описания многих систем объясняются тем, что эти системы слишком велики, но они могут быть упрощены за счет обобщающих предположений. Методология SADT создана для представления таких сложных систем путем построения моделей. 2. SADT-модель - это описание системы, у которой есть единственный наблюдатель (субъект), цель и одна точка зрения. Целью служит набор вопросов, на которые должна ответить модель. Точка зрения - позиция, с которой описывается система 3. Цель и точка зрения - это основополагающие понятия SADT. Описание модели SADT организовано в виде иерархии взаимосвязанных диаграмм. Вершина этой древовидной структуры представляет собой самое общее описание системы, а ее основание состоит из наиболее детализированных описаний.
3. СИНТАКСИС И ПРИМЕНЕНИЕ ДИАГРАММ Диаграмма является основным рабочим элементом при создании модели. Разработчик диаграмм и моделей в терминологии SADT называется автором. Диаграммы имеют собственные синтаксические правила, отличающиеся от синтаксических правил моделей. Каждая SADT-диаграмма содержит блоки и дуги. Блоки изображают функции моделируемой системы. Дуги связывают блоки вместе и отображают взаимодействия и взаимосвязи между ними. На рис.3.1 приведен пример типичной SADT-диаграммы. Диаграмме дается название, которое располагается в центре нижней части ее бланка. На каждой диаграмме написана стандартно идентифицирующая информация: автор диаграммы, частью какого проекта является работа, дата создания или последнего пересмотра диаграммы, статус диаграммы. Вся идентифицирующая информация располагается в верхней части бланка диаграммы. Блоки. Функциональные блоки на диаграммах изображаются прямоугольниками. Блок представляет функцию или активную часть системы, поэтому названиями блоков служат глаголы или глагольные обороты. Например, названиями блоков диаграммы выполнить задание являются: определить степень выполнения задания, выбрать инструменты, подготовить рабочее место, обработать на станке и собрать, как показано на рис.3.1. SADT-технология рекомендует, чтобы в диаграмме было не менее трех и не более шести блоков. В этом случае SADT-диаграммы и SADT-модели наглядны.
49 ИСПОЛЬЗУЕТСЯ В:
АВТОР: Marca ПРОЕКТ: ЭМЦ
ДАТА: 03/16/92 ПЕРЕСМОТР:
√
РАБОЧАЯ ВЕРСИЯ
ЧИТАТЕЛЬ
КОНТЕКСТ:
ДАТА
ЭСКИЗ РЕКОМЕНДОВАНО
ЗАМЕЧАНИЯ: 1 2 3 4 5 6 7 8 9 10
DAM006
ПУБЛИКАЦИЯ
План выполнения С1 задания
Статус задания
Заготовки
О2
Определить степень выполнения задания
Следующий шаг задания Законченное или незаконченное задания
1 Сырье и заготовки
О1 Детали
Указания Сырье
Обработать на станке и собрать 4
I1 Брак I3 Результаты обработки
Станки и инструменты
Набор инструментов
Выбранные инструменты
Выбрать инструменты
I2
2
Подготовить рабочее место 3
Станки в цехе
УЗЕЛ: ЭМЦ/А-0
Оборудованное рабочее место Чертежи и указания
НОМЕР:
НАЗВАНИЕ: Изготовить нестандартную деатль
(DAM0032) DAM006
Рис.3.1 В SADT каждая сторона блока имеет определенное назначение. Левая сторона блока предназначена для входов, верхняя - для управления, правая для выходов, нижняя - для механизмов. Это отражает определенные системные принципы: входы преобразуются в выходы, управление ограничивает или предписывает условия выполнения преобразований, механизмы показывают, кто, что и как выполняет функцию. Например, четвертый блок диаграммы выполнить задание может быть интерпретирован следующим образом: детали, сырье и брак, обрабатываются на станке и собираются в результаты обработки с использованием оборудованного рабочего места. Блоки SADT не размещаются на диаграмме случайным образом. Они размещаются по степени важности. В SADT этот относительный порядок называется доминированием. Доминирование понимается как влияние, которое один блок оказывает на другие блоки диаграммы. Наиболее доминирующий блок обычно размещается в верхнем левом углу диаграммы, а наименее доминирующий - в правом нижнем углу. В результате получается «ступенчатая» схема (см. рис.3.1 для блоков 1,2,3).
50 Топология диаграммы показывает, какие функции оказывают большее влияние на остальные. Чтобы подчеркнуть это, SADTаналитик может перенумеровать блоки в соответствии с порядком их доминирования. Порядок доминирования может обозначаться цифрой, размещенной в правом нижнем углу каждого прямоугольника: 1 будет указывать на наибольшее доминирование, 2 - на следующее после наибольшего, и т.д. Блоки в SADT должны быть перенумерованы. Номера блоков служат однозначными идентификаторами для системных функций и автоматически организуют эти функции в иерархию модели. Используя номера блоков и оценивая влияние, которое один блок оказывает на другой, аналитик может организовать модель по принципу функционального доминирования. Это позволяет согласовать иерархический порядок функций в модели с уровнем влияния каждой функции на остальную часть системы. Дуги. Дуги на SADT-диаграмме изображаются одинарными линиями со стрелками на концах. Для функциональных SADT-диаграмм дуга представляет множество объектов. Дуги в SADT могут представлять планы, задания, данные в компьютерах, машины и любую другую информацию. Дуги диаграммы выполнить задание на рис. 3.1 представляют данные, написанные на бумаге, физические материалы, инструменты, рабочие чертежи, рабочую среду и управленческую информацию. Так как в SADT дуги изображают объекты (или данные), то они описываются существительными или существительными с определениями, располагающимися достаточно близко к линии дуги. Между объектами и функциями возможны четыре отношения: вход, управление, выход, механизм. Каждое из этих отношений изображается дугой, связанной с определенной стороной блока. По соглашению левая сторона блока предназначена для входных дуг, верхняя сторона - для управленческих дуг, правая сторона - для выходных дуг, нижняя сторона для дуг механизмов. Входные дуги изображают объекты, используемые и преобразуемые функциями. Например, в процессе изготовления детали сырье трансформируется функцией обработать на станке и собрать. Управленческие дуги представляют информацию, управляющую действиями функций. Управляющие дуги несут информацию, которая указывает, что должна выполнять функция. Например, следующий шаг задания определяет, какие нужно выбрать инструменты, какие потребуются станки и цеха и как инструменты и станки должны использоваться при изготовлении детали. Выходные дуги изображают объекты, в которые преобразуются входы. Например, обработать на станке и собрать преобразует сырье и брак в результаты обработки, которые в конечном итоге становятся деталями.
51 Дуги механизмов отражают, по крайней мере частично, как функции системы реализуются. Например, подготовить рабочее место организует инструменты и станки в эффективное пространство для следующего шага задания. Это - рабочая среда, называемая оборудованным рабочим местом. Она обозначает место, где рабочий изготавливает деталь, реализуя функцию обработать на станке и собрать. Таким образом, механизмы изображают физические аспекты функции (склады, людей, организации, приборы). SADT-диаграмма составлена из блоков, связанных дугами, которые определяют, как блоки влияют друг на друга. Это влияние может выражаться либо в передаче выходной информации к другой функции для дальнейшего преобразования, либо в выработке управляющей информации, предписывающей, что именно должна выполнять другая функция. Например, блок обработать на станке и собрать влияет на блок определить степень выполнения задания, выдавая ему результаты обработки для оценки, а блок определить степень выполнения задания влияет на очередную операцию блока обработать на станке и собрать с помощью следующего шага задания. Другими словами, существует сильная управляющая связь блока определить степень выполнения задания с блоком обработать на станке и собрать и наряду с ней более слабая связь по входу-выходу от блока обработать на станке и собрать к блоку определить степень выполнения задания. Таким образом, SADT-диаграммы не являются ни блок-схемами, ни просто диаграммами потоков данных. Это предписывающие диаграммы, представляющие входные-выходные преобразования и указывающие правила этих преобразований. Дуги на них изображают интерфейсы между функциями системы, а также между системой и ее окружающей средой. В методологии SADT требуется только пять типов взаимосвязей между блоками для описания их отношений: управление, вход, обратная связь по управлению, обратная связь по входу, выход-механизм. Связи по управлению и входу являются простейшими, поскольку они отражают прямые воздействия, которые интуитивно понятны и очень просты. Отношение управления возникает тогда, когда выход одного блока непосредственно влияет на блок с меньшим доминированием. Например, блок определить степень выполнения задания влияет на блок выбрать инструменты в соответствии с детальными указаниями, содержащимися в описании следующего шага задания. Отношение входа возникает тогда, когда выход одного блока становится входом для блока с меньшим доминированием, например, выход блока определить степень выполнения задания, называемый законченное или незаконченное задание, становится входом функции обработать на станке и собрать при выполнении следующего шага задания.
52 Обратная связь по управлению и обратная связь по входу являются более сложными, поскольку они представляют итерацию или рекурсию. А именно выходы из одной функции влияют на будущее выполнение других функций, что впоследствии влияет на исходную функцию. Обратная связь по управлению возникает тогда, когда выход некоторого блока влияет на блок с большим доминированием. Рассмотрим для примера диаграмму изготовить нестандартную деталь на рис. 3.2. ИСПОЛЬЗУЕТСЯ В:
АВТОР: Marca ПРОЕКТ: ЭМЦ
ДАТА: 03/16/92 ПЕРЕСМОТР:
√
РАБОЧАЯ ВЕРСИЯ
ЧИТАТЕЛЬ
ДАТА
КОНТЕКСТ:
ЭСКИЗ РЕКОМЕНДОВАНО
ЗАМЕЧАНИЯ: 1 2 3 4 5 6 7 8 9 10
Требования по срокам выполнения задания
Рабочий комплект I1
С1
ПУБЛИКАЦИЯ Справочник стандартов качества
Штамп «Принято»
С2
Статус задания
Управлять выполнением задания А1
О2
Оценка степени завершения задания О1
План выполнения задания
Готовая деталь
Мастер Сырье и заготовки Выполнить задание
Станки и инструменты I2
А2
Деталь с биркой
Принятое, но не законченное задание
Законченное или незаконченное задание
Брак Рабочий Контролировать качество выполнения А3
Принятое задание
Забракованное задание
Персонал механического цеха УЗЕЛ: ЭМЦ/А-0
Контроллер М1 НАЗВАНИЕ: Изготовить нестандартную деталь
НОМЕР:
(DAM003) DAM006
Рис.3.2 Функция управлять выполнением задания ограничивает действие функции контролировать качество выполнения с помощью чертежа, в котором указаны разрешенные допуски. Кроме того, дуга штамп «принято», являющаяся выходом блока контролировать качество выполнения, организует работу блока управлять выполнением задания, поскольку именно штамп «принято» указывает, что задание завершено. Штамп «принято» влияет на будущую деятельность блока управлять выполнением задания, поэтому соответствующая дуга направлена назад. Связь по входной обратной связи имеет место тогда, когда выход одного
53 блока становится входом другого блока с большим доминированием. Например, задания, отвергнутые функцией контролировать качество выполнения, отсылаются на вход блока выполнить задание в качестве брака. Дуга в SADT редко изображает один объект. Обычно она символизирует набор объектов. Например, дуга, именуемая рабочий комплект, отражает техническое задание, чертеж, план-график, некоторое сырье и заготовки. Так как дуги представляют наборы объектов, они могут иметь множество начальных точек (источников) и конечных точек (назначений). Поэтому дуги могут разветвляться и соединяться различными сложными способами. Для объяснения того, как дуги представляют разъединение и соединение наборов объектов, в SADT были разработаны специальные соглашения относительно представления и описания разветвлений и соединений дуг. Разветвления дуг, изображаемые в виде расходящихся линий, означают, что все содержимое дуг или его часть может появиться в каждом ответвлении дуги. Дуга всегда помечается до разветвления, чтобы дать название всему набору. Кроме того, каждая ветвь дуги может быть помечена или не помечена в соответствии со следующими правилами: - непомеченные ветви содержат все объекты, указанные в метке дуги перед разветвлением (т.е. все объекты принадлежат этим ветвям); - ветви, помеченные после точки разветвления, содержат все объекты или их часть, указанные в метке дуги перед разветвлением (т.е. каждая метка ветви уточняет, что именно содержит ветвь). Например, на диаграмме изготовить нестандартную деталь дуга принятое задание включает несколько объектов и разветвляется в нескольких направлениях. Дуга штамп «принято» влияет на блок управлять выполнением задания; принятое, но незаконченное задание идет в блок выполнить задание для следующей обработки, а деталь с биркой идет в блок управлять выполнением задания для окончательной проверки и поставки. Слияние дуг в SADT, изображаемое как сходящиеся вместе линии, указывает, что содержимое каждой ветви идет на формирование метки для дуги, являющейся результатом слияния исходных дуг. После слияния результирующая дуга всегда помечается для указания нового набора объектов, возникшего после объединения. Кроме того, каждая ветвь перед слиянием может помечаться или не помечаться в соответствии со следующими правилами: - непомеченные ветви содержат все объекты, указанные в общей метке дуги после слияния (т.е. все объекты исходят из всех ветвей); - помеченные перед слиянием ветви содержат все или некоторые объекты из перечисленных в общей метке после слияния (т.е. метка ветви ясно указывает, что содержит ветвь).
54 Например, сырье и заготовки как часть дуги рабочий комплект сходятся вместе с принятым, но незаконченным заданием для формирования главного входа в функциональный блок выполнить задание. Сырье и заготовки - это название, включающее и те и другие объекты, поэтому дуга после соединения получает эту метку. Идентификация версий диаграмм С-номерами. При создании SADTмодели одну и ту же диаграмму вместе с ее блоками и дугами перечерчивают несколько раз, что приводит к появлению различных ее вариантов. Чтобы различать разные версии одной и той же диаграммы, в SADT используют схему контроля конфигурации диаграмм, основанную на хронологических номерах, или С-номерах. С-номерные коды образуются из инициалов автора и последовательных номеров. Эти коды ставятся в нижнем правом углу SADT-бланка. Например, DAM010 - это С-номер для диаграммы выполнить задание на рис. 3.2. Если диаграмма заменяет более старый вариант, то автор (разработчик) помещает предыдущий С-номер в скобках. Например, диаграмма DAM010 заменяет предыдущую версию DAM009. Каждый автор проекта SADT ведет реестр всех созданных им диаграмм, нумеруя их последовательными целыми числами. Для этого используется бланк реестра С-номеров SADT. На рис. 3.3 приведен реестр С-номеров рассматриваемой модели экспериментального механического цеха. Вопросы. 1. Какое количество блоков допустимо в SADT-диаграмме? 2. Как различают версии одной и той же диаграммы? 3. Что изображают блоки и как они располагаются на SADT-диаграмме? 4. Что изображают дуги на SADT-диаграмме? Ответы. 1. SADT-диаграмма содержит от трех до шести блоков, связанных дугами, и имеет при построении модели несколько версий. 2. Для того чтобы различать версии одной и той же диаграммы, используются С-номера. 3. Блоки на диаграмме изображают системные функции, а дуги изображают множество различных объектов системы. Блоки обычно располагаются на диаграмме в соответствии с порядком их доминирования, т.е. их важностью относительно друг друга. 4. Дуги, связывающие блоки, изображают наборы объектов и могут разветвляться и соединяться различными сложными способами. Однако, разветвляясь и соединяясь, дуги должны во всех случаях сохранять представляемые ими объекты.
55 ИСПОЛЬЗУ -ЕТСЯ В:
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
АВТОР: Marka ДАТА: 02/24/92 ПРОЕКТ ЭМЦ ПЕРЕСМОТР:
√
РАБОЧАЯ ВЕРСИЯ ЭСКИЗ РЕКОМЕНДОВАНО ЗАМЕЧАНИЯ: 1 2 3 4 5 6 7 8 9 10 ПУБЛИКАЦИЯ C – номера начинаются с 000 А0 Изготовить нестандартную деталь 25 А0 Изготовить нестандартную деталь 26 А0 Изготовить нестандартную деталь 27 А0 Изготовить нестандартную деталь 28 А0 Изготовить нестандартную деталь 29 А0 Изготовить нестандартную деталь 30 А0 Изготовить нестандартную деталь 31 А1 Управлять выполнением задания 32 А1 Управлять выполнением задания 33 А2 Выполнить задание 34 А2 Выполнить задание 35 А3 Контролировать кач-во выполнения 36 А3 Контролировать кач-во выполнения 37 ЭМЦ-1 Папка для рецензирования 38 А2G1 Выполнить задание 37 А2 Выполнить задание 40 А23 Подготовить рабочее место 41 А23 Подготовить рабочее место 42 А23 Подготовить рабочее место 43 А23F1 Готовый станок 44 А11 Получить зад-е и назначить исполн. 45 А12 Изучить зад-е и сплан. Выполнение 46 А24 Обработать на станке и собрать 47 48 49
УЗЕЛ: ЭМЦ/Text
НАЗВАНИЕ: Реестр С-номеров
ЧИТАТЕЛЬ ДАТА
КОНТЕКСТ Tоp
50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 Номер: DAM00
Рис.3.3
4. СИНТАКСИС МОДЕЛЕЙ И РАБОТА С НИМИ Для адекватного описания системы требуется несколько SADT-диаграмм. Совокупность SADT-диаграмм становится SADT-моделью. В SADT существуют также правила синтаксиса моделей. Синтаксис SADT-моделей позволяет определить границу модели, связать диаграммы в одно целое и обеспечить точное согласование между диаграммами. SADT-модель является иерархически организованной совокупностью диаграмм. Диаграммы состоят из трех-шести блоков, каждый из которых потенциально может быть детализирован на другой диаграмме. Каждый блок может пониматься как отдельный тщательно определенный объект. Разделение такого объекта на его структурные части (блоки и дуги, составляющие диаграмму) называется декомпозицией. Декомпозиция формирует границы, и каждый блок в SADT рассматривается как формальная граница некоторой части целой системы. Блок и касающиеся его дуги определяют точную границу диаграммы, представляющей декомпозицию этого блока. Эта диаграмма, называемая
56 диаграммой с потомком, описывает все, связанное с этим блоком и его дугами, и не описывает ничего вне этой границы. Декомпозируемый блок называется родительским блоком, а содержащая его диаграмма соответственно родительской диаграммой. Принцип ограничения объекта встречается на каждом уровне. Один блок и несколько дуг на самом верхнем уровне используются для определения границы всей системы. Этот блок описывает общую функцию, выполняемую системой. Дуги, касающиеся этого блока, описывают главные управления, входы, выходы и механизмы этой системы. Диаграмма, состоящая из одного блока и его дуг, определяет границу системы и называется контекстной диаграммой модели. Таким образом, этот блок изображает границу системы: все, лежащее внутри него, является частью описываемой системы, а все, лежащее вне него, образует среду системы. На рис.4.1 показан верхний уровень модели экспериментального механического цеха. ъ
ИСПОЛЬЗУЕТСЯ В:
АВТОР: Marca ПРОЕКТ: Книга
ДАТА: 03/16/92 ПЕРЕСМОТР:
√
РАБОЧАЯ ВЕРСИЯ
ЧИТАТЕЛЬ
ДАТА
Top
РЕКОМЕНДОВАНО ЗАМЕЧАНИЯ: 1 2 3 4 5 6 7 8 9 10
КОНТЕКСТ:
ЭСКИЗ
ПУБЛИКАЦИЯ
Требования по срокам выполнения задания
Справочник стандартов качества
Рабочий комплект
Готовая деталь Изготовить нестандартную деталь
Станки и инструменты
0
Оценка степени завершения задания
Персонал механического цеха Цель:
Понять, какие функции должны быть включены в процесс изготовления нестандартной детали и как эти функции взаимосвязаны между собой с тем, чтобы написать учебное пособие для персонала цеха
Точка зрения:
УЗЕЛ: ЭМЦ/А-0
Начальник цеха
НАЗВАНИЕ: Изготовить нестандартную деталь
НОМЕР:
(DAM004) DAM005
Рис.4.1 Блок с названием изготовить нестандартную деталь описывает самую общую функцию механического цеха и имеет нулевой номер. Этот блок представляет весь экспериментальный механический цех. Дуги требования по срокам выполнения задания и справочник стандартов качества определяют, как экспериментальный механический цех преобразует рабочие комплекты и станки и инструменты в готовые детали и оценку степени завершенности задания. Они определяют
57 интерфейс между экспериментальным механическим цехом и остальной частью аэрокосмической компании. SADT-модели развиваются в процессе структурной декомпозиции сверху вниз. Сначала декомпозируется один блок, являющийся границей модели, на одной диаграмме. Затем декомпозируется один (или больше) из блоков первой диаграммы на другой диаграмме с тремя-шестью блоками и т.д. Название диаграммы совпадает с названием декомпозируемого блока. Результатом является модель, диаграмма верхнего уровня которой описывает систему в общих терминах «черного ящика», а диаграммы нижнего уровня описывают очень детализированные аспекты и операции системы. В методологии SADT идентифицируется каждая диаграмма данной модели посредством «номера узла». Номер узла для контекстной диаграммы имеет следующий вид: название модели или аббревиатура, косая черта, заглавная буква A (Activity в функциональных диаграммах), дефис и ноль. Например, номером узла для контекстной диаграммы модели экспериментального механического цеха является ЭМЦ/А-0. Номером узла диаграммы, декомпозирующей контекстную диаграмму, является тот же номер узла, но без дефиса (например, ЭМЦ/АО). Все другие номера узлов образуются посредством узла родительской диаграммы номера добавления к номеру декомпозируемого блока. На рис.4.2 показаны две диаграммы модели экспериментального механического цеха, отображающие связь между родительской диаграммой и диаграммой-потомком. Номер узла на первой диаграмме - ЭМЦ/АО, номер узла на второй диаграмме - ЭМЦ/А1. Диаграмма ЭМЦ/А1 декомпозирует блок 1 диаграммы ЭМЦ/АО. (Первый ноль при образовании номера узла принято опускать, поэтому вместо ЭМЦ/А01 пишется ЭМЦ/А1.) С-номера применяются для связки диаграмм при движении как вверх, так и вниз по иерархии модели. Обычно С-номер диаграммы, декомпозирующей некоторый блок, впервые появляется непосредственно под этим блоком на родительской диаграмме. Это образует «направленную вниз» связь от родительской диаграммы к диаграмме-потомку. На рис.4.2 С-номер DAM008 диаграммы управлять выполнением задания размещен ниже блока 1 на диаграмме изготовить нестандартную деталь. Это указывает на то, что функция управлять выполнением задания была декомпозирована. Как только образуется направленная вниз связь, на диаграмме-потомке формируется ссылка на родительскую диаграмму.
58
ИСПОЛЬЗУЕТСЯ В:
АВТОР: Marca ПРОЕКТ: ЭМЦ
ДАТА: 03/16/92 ПЕРЕСМОТР:
√
РАБОЧАЯ ВЕРСИЯ
ЧИТАТЕЛЬ
ДАТА
КОНТЕКСТ:
ЭСКИЗ РЕКОМЕНДОВАНО
ЗАМЕЧАНИЯ: 1 2 3 4 5 6 7 8 9 10
Требования по срокам выполнения задания
Рабочий комплект I1
С1
ПУБЛИКАЦИЯ Справочник стандартов качества
Штамп «Принято»
С2
Статус задания
Управлять выполнением задания А1
О2
Оценка степени завершения задания О1
План выполнения задания
Готовая деталь
Мастер Сырье и заготовки Выполнить задание
Станки и инструменты I2
А2
Деталь с биркой
Принятое, но не законченное задание
Брак Рабочий
Законченное или незаконченное задание
Контролировать качество выполнения А3
Принятое задание
Забракованное задание
Контроллер Персонал механического цеха УЗЕЛ: ЭМЦ/А-0
М1 НАЗВАНИЕ: Изготовить нестандартную деталь
НОМЕР:
(DAM003) DAM006
59
ИСПОЛЬЗУЕТСЯ В:
АВТОР: Marca ПРОЕКТ: ЭМЦ
ДАТА: 03/16/92 ПЕРЕСМОТР:
√
РАБОЧАЯ ВЕРСИЯ
ЧИТАТЕЛЬ
КОНТЕКСТ:
ДАТА
ЭСКИЗ РЕКОМЕНДОВАНО
ЗАМЕЧАНИЯ: 1 2 3 4 5 6 7 8 9 10 Незанятый рабочий Рабочий комплект I1
Получить задание и назначить исполнителя 1 Стеллаж входных заданий
Порядок выполнения задания и чертеж
DAM006
ПУБЛИКАЦИЯ Требования по срокам выполнения задания
С3 Статус задания
Назначение
Изучить задание и спланировать выполнение 2
С1
С2 Штамп «Принято»
Проблемы
План выполнения задания
О3
Этапы обработки на станке
План-график
Степень завершенности Оценить время выполнения задания
Рабочий
Оценка степени завершенности задания О1
Временные оценки 3 Контролировать Оценка статуса график выполнения задания Все 4 выполненные шаги
Деталь с биркой I2
УЗЕЛ: ЭМЦ/А1
Готовая деталь
Завершить задание 5
НАЗВАНИЕ: Управлять выполнением задания
НОМЕР:
О2
(DAM007) DAM008
Рис.4.2 В области контекста SADT-бланка (правый верхний угол) автор изображает каждый блок родительской диаграммы маленькими
60 квадратиками, заштриховывает квадратик декомпозируемого блока и размешает С-номер родительской диаграммы возле заштрихованного квадратика. Это образует связь, «направленную вверх», к родительской диаграмме. Метод соединения диаграмм посредством однозначно определенных номеров гарантирует, что именно нужная версия диаграммы станет частью модели. На рис.4.2 область контекста бланка диаграммы управлять выполнением задания содержит три квадратика - по одному для каждого блока диаграммы изготовить нестандартную деталь. Первый блок заштрихован. Это указывает на то, что данная диаграмма декомпозирует первый блок диаграммы DAM008. Методология структурного анализа должна гарантировать правильное соединение всех диаграмм для образования согласованной модели. SADTдиаграммы имеют внешние дуги, как бы выходящие наружу и ведущие к краю страницы. Эти дуги являются интерфейсом между диаграммой и остальной частью модели. Необходимо, чтобы все внешние дуги диаграммы были согласованы с дугами, образующими границу этой диаграммы. Диаграмма должна быть состыкована со своей родительской диаграммой. Внешние дуги должны быть согласованы по числу и наименованию, но не обязательно по расположению, с дугами, касающимися декомпозированного блока родительской диаграммы. Например, у блока 1 (см. рис.4.2) диаграммы изготовить нестандартную деталь восемь граничных дуг: входы рабочий комплект и деталь с биркой, управления требования по срокам выполнения задания, штамп «принято» и статус работы, а также выходы оценка степени завершенности задания, готовая деталь, план выполнения задания. Все эти внешние дуги и их имена можно найти на диаграмме управлять выполнением задания. В SADT принята система обозначений, позволяющая аналитику точно идентифицировать и проверять связи по дугам между диаграммами. Эта схема кодирования дуг – ICOM, которая получила название по первым буквам английских эквивалентов слов вход (Input), управление (Control), выход (Output), механизм (Mechanism). Коды ICOM позволяют быстро проверять согласованность внешних дуг диаграммы с граничными дугами соответствующего блока родительской диаграммы. Они обеспечивают согласованность декомпозиции, поскольку все дуги, входящие в диаграмму и выходящие из нее, должны быть учтены. На рис.4.2 дуга требования по срокам выполнения задания может быть отслежена от ее начала (С1 блока 0 диаграммы ЭМЦ/ А-0) на границе модели через верхнюю часть диаграммы ЭМЦ/АО к блоку управлять выполнением задания (СЗ блока 4 диаграммы ЭМЦ/ А1). При построении диаграммы следующего уровня дуги, касающиеся декомпозируемого блока, используются в качестве источников и приемников
61 для дуг, которые создаются на новой диаграмме. После завершения диаграммы ее внешние дуги стыкуются с родительской диаграммой для обеспечения согласованности. На рис.4.3 показано кодирование связей между SADT-диаграммами.
Требования по срокам выполнения задания Рабочий комплект
С1
Справочник стандартов качества
Штамп «Принято»
Оценка степени завершения задания Рабочий комплект I1
С2
Статус задания
Управлять выполнением задания А1
Готовая деталь
О2
Готовая деталь
О1
План выполнения задания Чертеж
Станки и оборудование
Оценка степени завершенности задания
Сырье и заготовки Выполнить задание
Станки и инструменты I2
А2
Деталь с биркой
Принятое, но не законченное задание
Законченное или незаконченное задание
Рабочий
Контролировать качество выполнения А3
Мастер
Персонал механического цеха
Принятое задание
Брак
Забракованное задание Контроллер
М1 Персонал механического цеха
Рис.4.3 Присваивание кодов ICOM внешним дугам новой диаграммы происходит согласно следующим правилам. Правило 1. Рисунок новой диаграммы следует представить внутри разлагаемого блока. Продлите внешние дуги почти до края диаграммы. Зрительно соедините каждую внешнюю дугу диаграммы с соответствующей граничной дугой декомпозируемого блока. На рис. 3.3 в некоторых местах применены пунктирные линии для изображения процесса зрительного соединения. Правило 2. Присвойте код каждой зрительной связи. Используйте буквы I для входных дуг, С - для связей между дугами управления, О - для связей между выходными дугами, М - для связей между дугами механизма. Правило 3. Добавьте после каждой буквы цифру, соответствующую положению данной дуги среди других дуг того же типа, касающихся родительского блока. Причем входные и выходные дуги пересчитываются сверху вниз, а дуги управлений и механизмов пересчитываются слева направо (см. рис.4.3). Запишите каждый код около окончания каждой внешней дуги. На рис.4.3 приведены субъект и его границы (блок и прилегающие дуги) и декомпозирующая его диаграмма. Граница субъекта изображена жирной
62 линией для того, чтобы подчеркнуть, как внешние дуги связаны с соответствующими граничными дугами. На диаграмме пунктирными линиями изображены зрительные связи только между выходными дугами и соответствующими им граничными дугами. Другие связи легко определить зрительно. В соответствии со схемой кодирования на рис.4.3 были применены коды ICOM: II, 12, Cl, C2, 01, 02, Ml. Кодирование дуг ICOM-метками произведено в зависимости от того, к какой стороне родительского блока примыкает данная дуга. Кодирование ICOM создает совокупность неявных связующих звеньев между страницами, которые можно быстро изменить при изменении границ. Эти неявные межстраничные связующие звенья облегчают процесс чтения и рецензирования SADT-диаграмм, а также проверку, насколько согласованно произведена декомпозиция. Коды ICOM упрощают работу, связанную с внесением вручную локальных изменений в диаграмму, и объединяют различные варианты диаграмм так, что они хорошо стыкуются в модели. Номера узлов, С-номера и коды ICOM определяют подавляющее большинство ситуаций внутренних связей в модели. Однако между родительскими диаграммами и диаграммами-потомками могут возникать некоторые специфические ситуации, в которых разумное использование синтаксиса модели улучшает описание модели, а именно: - при разветвлении и соединении внешних дуг; - при изменении входных дуг на управляющие и наоборот; - когда дуги «входят в тоннель». Рассмотрим примеры этих особых ситуаций, в которых применимы такие средства изображения для прояснения и упрощения описания системы. Во всех этих случаях данные при пересечении границ диаграмм сохраняются, т.е. все входные данные некоторым образом используются для образования всех выходных данных. Ключом для понимания таких ситуаций является то, что дуги SADT изображают иерархические наборы данных. Одна из особых ситуаций заключается в разветвлении или соединении внешних дуг между диаграммами. Например, две внешние выходные дуги на диаграмме могут быть частями общей выходной дуги на границе блока. Это может произойти, если аналитик вместо того, чтобы обычным способом соединить их на диаграмме, ocтавляет это соединение неявным. Узнать об этом непоказанном соединении или разветвлении можно, заметив, что коды ICOM для двух разных дуг совпадают. Особая ситуация возникает также тогда, когда входная дуга превращается в дугу управления и наоборот. Это происходит, если дуга управления (или входная), касающаяся границы блока, используется при декомпозиции диаграммы как входная (или соответственно управленческая) дуга.
63 Две другие особые ситуации возникают, когда дуги «входят в тоннель» между диаграммами. Дуга «входит в тоннель» тогда, когда она является внешней дугой, которая отсутствует на родительской диаграмме (имеет скрытый источник), а также если она касается блока, но не появляется на диаграмме, которая его декомпозирует (имеет скрытый приемник). Тоннельные дуги от скрытого источника начинаются скобками, чтобы указать, что эти дуги идут из какой-то другой части модели или прямо извне модели. На рис..4.3 дуга незанятый рабочий С1 блока получить задание и назначить исполнителя на диаграмме ЭМЦ/А1 входит в тоннель и поэтому она не касается блока управлять выполнением задания на родительской диаграмме ЭМЦ/АО. Тоннельные дуги, имеющие скрытый приемник, кончаются скобками, чтобы отразить тот факт, что такая дуга идет к какой-то другой части модели или выходит из нее или что она не будет более в этой модели рассматриваться. На рис. 4.2 все дуги механизмов диаграммы изготовить нестандартную деталь являются тоннельными и указывают на то, что они не будут показаны при декомпозиции соответствующих блоков. Вопросы. 1. Как классифицируют SADT-диаграммы при декомпозиции ограниченных объектов? 2. С какой целью используются С-номера? 3. С какой целью используются коды ICOM? 4. С какой целью используется номер узла? 5. С какой целью применяют технические приемы типа «вхождения дуг в тоннель»? Ответы. 1. SADT-диаграммы являются декомпозициями ограниченных объектов. Объект ограничивается блоком и касающимися его дугами. Диаграмма, содержащая границу, называется родительской диаграммой, а диаграмма, декомпозирующая блок родительской диаграммы, называется диаграммойпотомком. 2. Для связывания родительской диаграммы и диаграммы-потомка используются С-номера, так что модель всегда сохраняет актуальность. 3. Коды ICOM используются для того, чтобы стыковать диаграммупотомка с родительской диаграммой. 4. Номер узла идентифицирует уровень данной диаграммы в иерархии модели. 5. Когда диаграммы в модели становятся слишком трудными для чтения, для упрощения описания системы могут разумным образом использоваться специальные технические приемы типа «вхождение дуг в тоннель».
64
5. ПРОЦЕСС МОДЕЛИРОВАНИЯ Процесс моделирования в SADT включает сбор информации об исследуемой области, документирование полученной информации и представление ее в виде модели и уточнение модели посредством итеративного рецензирования. Процесс моделирования подсказывает путь выполнения согласованной и достоверной структурной декомпозиции, что является ключевым моментом в квалифицированном анализе системы. SADT-методология объединяет итеративный процесс создания модели, нотации, управляющие конфигурацией модели, язык ссылок для диаграмм, язык функций моделей с графическим языком описания системы, а также рекомендации по реализации аналитических проектов. Нотации, управляющие конфигурацией, гарантируют, что новые диаграммы будут корректно встроены в иерархическую структуру модели. Язык ссылок в SADT, правила сокращений для ссылок, адресованных к отдельным частям диаграммы, облегчают оформление замечаний при рецензировании модели. Язык функций позволяет декларативно определять правила работы системы, что часто является особенно важным завершающим шагом в описании системы. На рис. 5.1 изображен процесс моделирования в SADT, описанный с помощью SADT-диаграммы. Диаграмма показывает, что процесс моделирования в SADT является итеративной последовательностью шагов, приводящих к точному описанию системы. В основе процесса моделирования лежит разделение функций, выполняемых участниками создания SADT-проектов: эксперты являются источниками информации, авторы создают диаграммы и модели, библиотекарь координирует обмен письменной информацией, читатели рецензируют и утверждают модели, а Комитет технического контроля принимает и утверждает модель. В процессе моделирования сведения об изучаемой системе получают с помощью методики сбора информации - опросов или интервью.
65
ИСПОЛЬЗУЕТСЯ В:
АВТОР: Marca ПРОЕКТ: ЭМЦ
ДАТА: 02/15/92 ПЕРЕСМОТР:
ЗАМЕЧАНИЯ: 1 2 3 4 5 6 7 8 9 10
√
РАБОЧАЯ ВЕРСИЯ
√
ЭСКИЗ
√
РЕКОМЕНДОВАНО
√
ПУБЛИКАЦИЯ
ЧИТАТЕЛЬ
ДАТА
КОНТЕКСТ: Top
Планы и цели проекта Потребности в информации
Знания и опыт
Опросить
Факты о системе
А1 Создать модель А2
Диаграммы модели папки
Статус принятия
Опубликованные модели
Эксперт Распространить материалы А3
Напоминания
Автор Папки с комментариями
Рецензировать А4
Оценка статуса
Библиотекарь Читатели
Папки с комментариями УЗЕЛ: Процесс/А-0
НАЗВАНИЕ: Моделировать с помощью SADT
Обсудить и принять А5 Комитет технического контроля НОМЕР:
66 Рис.5.1 Для получения наиболее полной информации SADT предлагает использовать различные ее источники (читать документы, опрашивать людей, наблюдать за работой системы). Независимо от конкретного источника информации методология SADT рекомендует руководствоваться определенной целью при его использовании. Во время опроса графический язык SADT используется как средство для заметок, которые служат основой для построения диаграмм. Создание модели (блок 2 на рис.5.1) - это второй важный этап в процессе моделирования, на котором аналитик документирует полученные им знания о данной проблемной области, представляя их в виде одной или нескольких SADT-диаграмм. Процесс создания модели осуществляется с помощью специального метода детализации ограниченного субъекта. В SADT автор вначале анализирует объекты, входящие в систему, а затем использует полученные знания для анализа функций системы. На основе этого анализа создается диаграмма, в которой объединяются сходные объекты и функции. Модели проходят через серию последовательных улучшений до тех пор, пока они в точности не будут соответствовать поставленной цели моделирования. Одной из основных компонент методологии SADT является итеративное рецензирование, в процессе которого автор и эксперт многократно совещаются (устно и письменно) относительно достоверности создаваемой модели. Итеративное рецензирование называется циклом автор/читатель. Цикл автор/читатель начинается в тот момент, когда автор принимает решение распространить информацию о какой-либо части своей работы с целью получения отзыва о ней. Материал для распространения оформляется в виде «папок» - небольших пакетов с результатами работы, которые обсуждаются другими специалистами в течение определенного времени. Сделанные письменные замечания также помещаются в папку в виде нумерованных комментариев. Папки с замечаниями являются, таким образом, обратной связью, которую авторы получают на свою работу. Читатели - это те, кто читает и критикует создаваемую модель (см. блок 4 на рис. 5.1), а затем помещает замечания в папки. Обычно отдельная папка рецензируется одновременно несколькими читателями, и все их замечания поступают к определенному сроку к автору. Затем автор отвечает на каждое замечание и обобщает критику, содержащуюся в замечаниях. С помощью таких обсуждений можно достаточно быстро обмениваться идеями. Таким образом, методология SADT поддерживает как параллельный, так и асинхронный просмотр модели, что
67 является наиболее эффективным способом распределения работы в коллективе. На практике над различными частями модели могут совместно работать множество авторов, потому что каждый функциональный блок модели представляет отдельный субъект, который может быть независимо проанализирован и декомпозирован. Таким образом, модель сама координирует работу коллектива авторов, в то время как процесс совместное рецензирование моделирования SADT координирует возникающих идей. Организация своевременной обратной связи имеет важнейшее значение для эффективного моделирования. В SADT существует наблюдатель за процессом рецензирования. На рис.5.1 показано, что эту роль выполняет библиотекарь, который является главным координатором процесса моделирования в SADT, обеспечивая своевременное и согласованное распространение рабочих материалов. Библиотекарь распространяет полученные от авторов папки, контролирует их движение, рассылает напоминания о своевременном возвращении авторам папок с замечаниями и о сроках ответов авторов на предложения читателей. Кроме того, библиотекарь печатает законченные модели после того, как они одобрены и приняты к использованию. Как только завершено создание модели с требуемым уровнем детализации и модель проверена, она может применяться для достижения поставленной цели. Например, модель экспериментального механического цеха создана для описания деятельности различных работников механического цеха, хотя результирующая модель всегда предназначалась как основа учебного руководства для нового персонала. Если эта модель точно описывает работу персонала в цехе, но не может служить для подготовки учебного руководства, она бесполезна. Точная модель не всегда полезна. В процессе SADT-моделирования рекомендуется выделить специальную группу людей, ответственных за то, что создаваемая в процессе анализа модель будет точна и используема в дальнейшем. Эта группа, называемая Комитетом технического контроля (см. блок 5 на рис.5.1), отвечает за контроль качества моделей, создаваемых авторами SADT-проекта. Комитет следит за выполняемой работой и ее соответствием конечным целям всего проекта. Члены Комитета обсуждают модель и оценивают, насколько она может быть использована и будет использована соответствующим образом в ходе выполнения проекта для достижения его глобальных целей. Комитет оценивает, насколько применима данная модель. Если модель признана Комитетом применимой, она публикуется. В противном случае авторам направляются замечания для необходимой доработки.
68 Вопросы. 1. Что представляет собой процесс моделирования в SADT? 2. Какова роль библиотекаря? 3. Какова роль комитета технического контроля? Ответы. 1. SADT - это методология, потому что она интегрирует процесс моделирования, управление конфигурацией проекта, использование дополнительных языковых средств и руководство проектом со своим графическим языком. Процесс моделирования может быть разделен на несколько этапов: опрос экспертов, создание диаграмм и моделей, распространение документации, оценка адекватности моделей и принятие их для дальнейшего использования. 2. Библиотекарь обеспечивает своевременный обмен информацией. 3. Комитет технического контроля оценивает модели с точки зрения их реального использования.
69
ГЛАВА 3 ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ 1. ОПРЕДЕЛЕНИЕ БАЗ ДАННЫХ И СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ 1.1. Данные и модели данных В теории баз данных описания разных явлений, понятий, предметов и их свойств принято называть данными [18]. Запись данных осуществляется с помощью некоторого средства общения на выбранном носителе. Данные и их представление (семантика) записывают совместно. Например, «Быстродействие микросхемы – 10-6 секунды». В данной записи «Быстродействие микросхемы» – данное, а «10-6 секунды» – его семантика. Данные и интерпретация могут быть разделены. Например, данные «Характеристики интерфейса С1-Фл для физических линий (ФЛ) связи» могут быть представлены в виде таблицы, пример которой приведен в табл.1.1. В верхней части табл.1.1 отдельно от данных приводится их интерпретация (наименование). Таблица 1.1 Интерпретация Rнвых (Ом)
Uпер (В)
Uпр (В)
δ (%)
50…300
≤150
≤1
≥0,02
10
12..48
150±30
150±30
≤1
≥0,05
10
48..72 72..144 144..192
120±24
120±24
1 2 3
≥0,05
10
Параметр
Тип ФЛ
Режим обмена
R (кбит/с)
С1-ФЛ-НУ
2- и 4проводная 4проводная 4проводная
Асинхронный, синхронный Синхронный
До 20
Rнвх (Ом)
Данные
С1-ФЛ-БИ
С1-ФЛ-КИ
Синхронный
В табл.1.1 приняты следующие обозначения: - R - скорость передачи; - Rнвх - входное номинальное сопротивление устройства преобразования сигнала (УПС);
70 устройства - Rнвых - выходное номинальное сопротивление преобразования сигнала; - Uпер - амплитудное значение линейного сигнала на передаче; - Uпр - амплитудное значение линейного сигнала на приеме; - δ - вершина выброса на вершине посылки относительно амплитуды импульса. Использование программного продукта для получения, хранения и обработки данных обычно приводит к еще большему разделению данных и интерпретации, чем это показано в табл.1.1. Разработчики прикладных программ размещают нужные им данные в файлах, организуя их наиболее удобным для себя образом. Одни и те же данные могут иметь в разных приложениях совершенно разную организацию (разную последовательность размещения в записи, разные форматы одних и тех же полей и т.п.). Этот недостаток приводит к тому, что любое изменение структуры записи файла, производимое одним из разработчиков, приводит к необходимости изменения другими разработчиками тех программ, которые используют записи этого файла. Для упорядочивания структур данных, наличия единых процессов их получения, записи, хранения и выбора в начале 60-х годов были разработаны специальные программные комплексы, называемые системами управления базами данных (СУБД), которые определяют не только процедуры для ввода и хранения самих данных, но и описывают их структуры. Файлы, снабженные описанием хранимых в них данных и находящиеся под управлением СУБД, стали называть банками данных, а затем базами данных (БД). На рис.1.1 приведена иллюстрация, показывающая назначение СУБД, связь данных, а также подключение к СУБД программ пользователей. Язык запросов СУБД позволяет обращаться за данными, как из программ, так и с терминалов (рис. 1.1). Сформировав некоторый запрос, получим искомые данные. Применение СУБД при работе с данными требует большего время, чем на обмен аналогичными данными прямо из файлов, специально созданных для того или иного приложения. СУБД предоставляет доступ к данным любым пользователям и выполняет многие функции, среди которых: - физическое размещение в памяти данных и их описание; - поиск запрашиваемых данных; - разрешение конфликтов при одновременном запросе одних и тех же данных многими пользователями (прикладными программами); - обеспечение защиты данных от некорректных обновлений и (или) несанкционированного доступа; - поддержание баз данных в рабочем состоянии.
71
Основная программа СУБД
О З У
При выполнении запроса на чтение данных, выданного прикладной программой или непосредственно с терминала, СУБД выполняет действия: - интерпретация запроса; - поиск всех описаний данных, на которые выдан запрос; - формирование команд, по которым операционная система пересылает из запоминающих устройств в буферы СУБД содержимое всех физических записей с требуемыми данными; - выделение из этих записей нужных
Программа первого пользователя СУБД
Программа второго пользователя СУБД
……. Программа N-го
72 Рис.1.1 При выполнении основных из этих функций СУБД применяет различные описания данных. Описания данных создаются следующим образом. Проектирование базы данных полностью соответствует методам, описанным в первой главе, поэтому проектирование базы данных начинается с анализа предметной области и выявления требований к базам данных отдельных пользователей. Проектирование выполняет специалист (или группа специалистов) – администратор базы данных (АБД). Вначале АБД создает неформальное описание базы данных, обобщая представления о содержимом базы данных, полученное в результате опроса пользователей, а также собственные представления о данных, которые могут потребоваться в будущих программных приложениях. Это описание, выполненное с использованием естественного языка, математических формул, таблиц, графиков и других средств, понятных всем людям, работающих над проектированием базы данных, называют инфологической моделью данных (см. рис. 1.2). Предметная область
Пользователь
…….
Пользователь
ИНФОЛОГИЧЕСКАЯ МОДЕЛЬ ДАННЫХ
ДАТАЛОГИЧЕСКАЯ МОДЕЛЬ ДАННЫХ
ФИЗИЧЕСКАЯ МОДЕЛЬ ДАННЫХ
БАЗА ДАННЫХ
Рис.1.2
АБД
73 Инфологическая модель независима от физических параметров среды хранения данных и не изменяется до тех пор, пока какието изменения в реальном мире не потребуют изменения в ней определений данных. Так как доступ к данным осуществляется с помощью конкретной СУБД, то модели данных должны быть описаны на языке описания этой СУБД. Такое описание, создаваемое АБД по инфологической модели данных, называют даталогической моделью данных. Нужные данные отыскиваются СУБД на внешних запоминающих устройствах по физической модели данных. Представление моделей в виде подобной трехуровневой системы позволяет обеспечить независимость хранимых данных от использующих их программ. АБД может переписать хранимые данные на другие носители информации, реорганизовать их физическую структуру, изменив лишь физическую модель данных. АБД может подключить к системе любое число новых пользователей, дополнив даталогическую модель. Произведенные АБД изменения физической и даталогической моделей не будут замечены пользователями системы. Трехуровневая система моделей обеспечивает развитие системы баз данных без изменений в существующих приложениях. Существуют различные даталогические модели. Самые простые (первые) - иерархические даталогические модели. Данные имеют древовидную структуру, просты в организации, определено наличие заранее заданных связей между сущностями, существует сходство с физическими моделями данных. Однако подобные даталогические модели работают на медленных ЭВМ с ограниченными объемами памяти. Сетевые модели создавались для малоресурсных ЭВМ. Они характеризуются сложными структурами. Программист должен детально знать термины, внутренние языки СУБД, логическую структуру базы данных и прочее. Сетевые модели сложны и «теряют» данные. Сегодня наиболее распространены реляционные модели, которые будут подробно рассмотрены ниже. Инфологическую модель данных строят по аналогии с естественным языком. Конструктивными элементами инфологических моделей являются сущности, связи между ними и их свойства (атрибуты). Сущность – любой различимый объект, информацию о котором необходимо хранить в базе данных. Различают такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к множеству однородных личностей, предметов, событий, выступающих как целое. Экземпляр сущности относится к конкретному элементу в множестве. Например, типом сущности может быть ЭЛЕМЕНТ СХЕМЫ, а экземпляром – резистор, диод, трансформатор, микросхема и т.д. Атрибут – поименованная характеристика сущности.
74 Наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей. Например, атрибут ВЕЛИЧИНА СОПРОТИВЛЕНИЯ может быть определен для сущностей: РЕЗИСТОР, ПЕРЕМЕННОЕ СОПРОТИВЛЕНИЕ. Атрибуты используются для определения того, какая информация должна быть собрана о сущности. Каждому экземпляру сущности присваивается только одно значение атрибута. Абсолютное различие между типами сущностей и атрибутами отсутствует. Атрибут является таковым только в связи с типом сущности. В другом контексте атрибут может выступать как самостоятельная сущность. Например, для проектировщика котроллера ВЕЛИЧИНА СОПРОТИВЛЕНИЯ – это только атрибут применяемых элементов, а для производителя сопротивлений – тип сущности. Ключ – минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся атрибутам. Связь – ассоциирование двух или более сущностей. Основным требований к организации базы данных является обеспечение возможности отыскания одних сущностей по значениям других, для чего необходимо установить между ними определенные связи. Базы данных могут содержать сотни, тысячи сущностей. Между ними могут быть установлены миллионы связей. Наличие такого множества связей и определяет сложность инфологических моделей.
1.2. Связи, сущности и язык моделирования При построении инфологических моделей можно применить язык ERдиаграмм (Entity-Relationship - сущность-связь). В моделях сущности изображаются прямоугольниками, ассоциации – ромбами или шестиугольниками, атрибуты – овалами, а связи между ними – ненаправленными ребрами, над которыми обычно проставляют степень связи (1 или буква, заменяющая слово «много») и пояснение. Между двумя сущностями А и В возможно существование четырех видов связей: - один к одному (см. рис.1.3,а); - один к многим (см. рис.1.3,б); - многие к одному(см. рис.1.3,в); - многие к многим (см. рис.1.3,г). Существуют более сложные связи: - множество связей между одними и теми же сущностями (см. рис.1.4,а); - тренарные связи (см. рис.1.4,в)
75 - связи более высоких порядков, семантика (смысл) которых иногда очень сложна. Помимо ER-диаграмм, которые используются для построении небольших моделей, применяется более содержательный язык инфологического моделирования (ЯИМ), в котором сущности и ассоциации представляются предложениями вида: СУЩНОСТЬ (атрибут 1, атрибут 2 , ..., атрибут n) АССОЦИАЦИЯ [СУЩНОСТЬ S1, СУЩНОСТЬ S2, ...] (атрибут 1, атрибут 2, ..., атрибут n) где S – степень связи, а атрибуты, входящие в ключ, должны быть отмечены с помощью подчеркивания. 1
А
1
АВ
В
1
Назначение
1
1
Назначение
М
Электронные злементы
М
Назначение
1
Контроллер
Сопротивление
Диапазон изменения
а 1
А
АВ
М
В
Контроллер б
А
М
1
АВ
В
Электронные злементы
в
А
М
АВ
N
В
Электронный злементы г
Рис.1.3
М
Назначение
N
Контроллеры
76
1 Начальник производственного участка
Мастер
М
М N
Персонал рабочих участка
Службы участка а
Мастер
М
Технологический процесс изготовления детали
N
Детали
Параметры детали б
Рис.1.4 Для примера (см. рис.1.4,б) связей между сущностями, применение ЯИМ произойдет следующим образом: Мастер (Наименование производственного участка, Фамилия, Имя, Отчество, Паспортные данные, Табельный номер); Рабочий (Профессия, Фамилия, Имя, Отчество, Паспортные данные, Табельный номер); Деталь (Наименование, Перечень операций, Требуемые станки, Перечень инструментов и оснастки). Вид ER-диаграммы приведен на рис.1.5. Для выявления связей между сущностями необходимо определить сами сущности. Это сложная задача, т.к. в разных предметных областях один и тот же объект может быть сущностью, атрибутом или ассоциацией.
77
Ключ М
Производственный участок
Ключ М
Ключ Ж
Ключ Ж Профессия
Перечень операций
Наименование
Фамилия
Фамилия Мастер
М
Имя
N Детали
Имя
Рабочие …
… Табельный номер
Перечень станков
Перечень инструментов
Перечень оснастки
Табельный номер
Рис.1.5 Рассмотрим классификацию сущностей. К.Дейт [19] ввел три класса сущностей: стержневые, ассоциативные и характеристические, а также подкласс ассоциативных сущностей – обозначения. Стержневая сущность (стержень) – это независимая сущность. В рассмотренных ранее примерах стержни – это «Мастер», «Деталь», «Рабочий» и другие, названия которых помещены в прямоугольники. Ассоциативная сущность (ассоциация) – это связь вида «многие к многим» («к многим» и прочее) между двумя или более сущностями или экземплярами сущности. Ассоциации рассматриваются как полноправные сущности. Ассоциации могут участвовать в других ассоциациях и обозначениях точно так же, как стержневые сущности. Ассоциации могут обладать свойствами, т.е. иметь не только набор ключевых атрибутов, необходимых для указания связей, но и любое число других атрибутов, характеризующих связь. Например, ассоциация «Деталь» (см. рис.1.5) содержит ключевые атрибуты «Наименование», «Операции» и прочее.
78 Характеристическая сущность (характеристика) – это связь вида «многие к одной» или «одна к одной» между двумя сущностями (частный случай ассоциации). Цель характеристики состоит в описании или уточнении некоторой другой сущности. Необходимость в них возникает тогда, когда сущности имеют многозначные свойства. Программный продукт может иметь несколько версий, одна и та же микросхема изготавливается разными предприятиями и т.д. Существование характеристики полностью зависит от характеризуемой сущности: контроллер лишится статуса работающего блока, если микросхема выйдет из строя. Для описания характеристики используется новое предложение ЯИМ, имеющее в общем случае вид: ХАРАКТЕРИСТИКА (атрибут 1, атрибут 2, ...) {СПИСОК ХАРАКТЕРИЗУЕМЫХ СУЩНОСТЕЙ}.
Обозначающая сущность или обозначение – это связь вида «многие к одной» или «одна к одной» между двумя сущностями и отличается от характеристики тем, что не зависит от обозначаемой сущности. Для языка ER-диаграмм применяют изображения, показанные на рис. 1.6. Стержень
Ключ
Ассоциация
Ассоциация
Характеристика
Атрибут
Обозначение
Рис.1.6 Обозначения используют для хранения повторяющихся значений больших текстовых атрибутов: «кодификаторы» чертежей и документов, наименований предприятий и их цехов, перечень деталей и т.п. Описание обозначения внешне отличается от описания характеристики только тем, что обозначаемые сущности заключается не в фигурные скобки, а в квадратные: ОБОЗНАЧЕНИЕ (атрибут 1, атрибут 2, ...)[СПИСОК ОБОЗНАЧАЕМЫХ СУЩНОСТЕЙ]. Обозначения не рассматриваются как полноправные сущности. Обозначения и характеристики не являются полностью независимыми сущностями, поскольку они предполагают наличие некоторой другой сущности, которая будет обозначаться или характеризоваться. Они представляют собой частные случаи сущности и могут иметь свойства, участвовать в ассоциациях, обозначениях и иметь свои собственные характеристики. Определим стержневую сущность как сущность, которая не является ни ассоциацией, ни обозначением, ни характеристикой. Такие сущности имеют
79 независимое существование, хотя они и могут обозначать другие сущности, как, например, профессии рабочих обозначают производственные участки или даже цеха.
1.3. Ключи Минимальность в определении ключа (см. разд. 1.2) означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся атрибутам. Каждая сущность обладает хотя бы одним возможным ключом. Один из них принимается за первичный ключ. При выборе первичного ключа следует отдавать предпочтение несоставным ключам или ключам, составленным из минимального числа атрибутов. Нецелесообразно использовать ключи с длинными текстовыми значениями, предпочтительнее использовать целочисленные атрибуты. Например, для идентификации чертежа детали можно использовать уникальный номер чертежа. Нельзя чтобы первичный ключ стержневой сущности (любой атрибут, участвующий в первичном ключе) принимал неопределенное значение. Определим понятие внешних ключей. Если сущность С связывает сущности А и В, то она должна включать внешние ключи, соответствующие первичным ключам сущностей А и В. Если сущность В обозначает сущность А, то она должна включать внешний ключ, соответствующий первичному ключу сущности А. Например, «Рабочие» обозначают «Цеха» и включают внешний ключ «Наименование цеха», соответствующий первичному ключу сущности «Цеха предприятия». Связь между первичными и внешними ключами сущностей иллюстрируется рис. 1.7. На рис.1.7 для обозначения любой из ассоциируемых сущностей (стержней, характеристик, обозначений или даже ассоциаций) применен новый обобщающий термин «Цель» или «Целевая сущность». При решении задачи выбора способа представления ассоциаций и обозначений в базе данных для определения каждого внешнего ключа необходимо ответить на следующие три вопроса. Вопрос 1. Может ли данный внешний ключ принимать неопределенные значения (NULL-значения)? Не существует ли некоторый экземпляр сущности данного типа, для которого неизвестна целевая сущность, указываемая внешним ключом? Например, невозможно – микросхема неизвестного назначения. Вопрос 2. Что должно случиться при попытке удаления целевой сущности, на которую ссылается внешний ключ? Например, при удалении
поставщика поставку.
микросхем,
80 который осуществил, по крайней мере, одну
Ассоциация Цель 1 Первичный ключ цели 1
Первичный ключ ассоциации Другие поля цели 1
Первичный ключ цели 2
Другие поля цели 21
Внешний ключ 1
Внешний ключ 2
...
...
Внешний ключ N
Первичный ключ цели N
Другие поля цели цели N 1
Цель 2
Поля, не входящие в первичный ключ
Цель N
а - ассоциации Обозначение (Характеристика) …
Обозначающий атрибут, являющийся внешним ключом 1
…
Обозначаемая (характеризуемая) сущность Первичный ключ
Другие поля
б – обозначения (характеристики)
Рис.1.7 Существуют три возможности: - каскадируется операция удаления «каскадируется» с тем, чтобы удалить также поставки этого поставщика; - ограничивается удаляются лишь те поставщики, которые еще не осуществляли поставок (операция удаления отвергается); - устанавливается - для всех поставок удаляемого поставщика NULL-значение внешний ключ устанавливается в неопределенное значение, а затем этот поставщик удаляется при условии, что данный внешний ключ не содержит NULL-значений. Вопрос 3. Что должно происходить при попытке обновления первичного ключа целевой сущности, на которую ссылается некоторый внешний ключ? Например, может быть предпринята попытка обновить номер такого поставщика микросхемы, для которого имеется, по крайней мере, одна соответствующая поставка. Существуют три возможности: - каскадируется операция обновления «каскадируется» с тем, чтобы обновить также и внешний ключ в поставках этого поставщика; - ограничивается обновляются первичные ключи лишь тех поставщиков, которые еще не осуществляли поставок (операция обновления отвергается);
81 - устанавливается - для всех поставок такого поставщика NULL-значение внешний ключ устанавливается в неопределенное значение, а затем обновляется первичный ключ поставщика при условии, что данный внешний ключ не содержит NULL-значений. Для каждого внешнего ключа в проекте проектировщик базы данных должен специфицировать не только поле или комбинацию полей, составляющих этот внешний ключ, и целевую таблицу, которая идентифицируется этим ключом, но также и ответы на указанные выше вопросы. Характеристики - это обозначающие сущности, существование которых зависит от типа обозначаемых сущностей. Обозначение представляется внешним ключом в таблице, соответствующей этой характеристике. Рассмотренные выше ограничения на внешний ключ должны специфицироваться следующим образом: - NULL-значения не допустимы; - удаление из (цель) каскадируется; - обновление (первичный ключ цели) каскадируется. Указанные спецификации представляют зависимость по существованию характеристических сущностей.
1.4. Целостность баз данных Целостность ( integrity – нетронутость, неприкосновенность, сохранность, целостность) – понимается как правильность данных в любой момент времени. СУБД не может контролировать правильность каждого отдельного значения, вводимого в базу данных, поэтому целостность может быть достигнута лишь в определенных пределах. Поддержание целостности базы данных рассматривают как защиту данных от неверных изменений или разрушений. СУБД имеют ряд средств обеспечения поддержания целостности. Выделяют три группы правил целостности: - целостность по сущностям; - целостность по ссылкам; - целостность, определяемая пользователем. Не допускается, чтобы какой-либо атрибут, участвующий в первичном ключе, принимал неопределенное значение. Значение внешнего ключа должно быть: - либо равным значению первичного ключа цели; - либо полностью неопределенным, т.е. каждое значение атрибута, участвующего во внешнем ключе должно быть неопределенным.
82 Для любой конкретной базы данных существует ряд дополнительных специфических правил, которые относятся к ней одной и определяются разработчиком. Чаще всего контролируется: - уникальность тех или иных атрибутов; - диапазон значений (величина сопротивления от 1 КОм до 1,4 Ком); - принадлежность набору значений (металл медь или алюминий).
2. РЕЛЯЦИОННЫЙ ПОДХОД ПРИ ПРОЕКТИРОВАНИИ СУБД 2.1. Реляционная структура данных Для обработки данных применяются операции из теории множеств. Это обусловлено тем, что модели данных достаточно адекватно задают в виде теоретико-множественных описаний (соответствие, отображение, отношение). Отношение – relation (англ.). Наименьшая единица данных реляционной модели – это отдельное атомарное (неразложимое) для данной модели значение данных. В одной предметной области назначение, габариты, вес изделия могут рассматриваться как единое значение, а в другой – как три различных значения. Доменом называется множество атомарных значений одного и того же типа. Например, домен микросхем – множество их наименований, домен конкретной микросхемы – ее назначение и множество ее параметров. Смысл доменов состоит в следующем. Если значения двух атрибутов берутся из одного и того же домена, то следует сравнить эти два атрибута. Например, при выборе микросхем можно сформировать запрос «Выдать перечень взаимозаменяемых по параметрам микросхем». Если же значения двух атрибутов берутся из различных доменов, то нет необходимости в этом сравнении. Отношение на доменах D1, D2, ..., Dn состоит из заголовка и тела. На рис. 2.1 приведен пример отношения для параметров микросхем цифроаналоговых и аналогово-цифровых преобразователей. Заголовок (на рис. 1.1 он назывался интерпретацией) состоит из такого фиксированного множества атрибутов A1, A2, ..., An, что существует взаимно однозначное соответствие между этими атрибутами Ai и определяющими их доменами Di (i=1,2,...,n). Тело состоит из множества кортежей (строки тела отношения). Каждый кортеж состоит из множества двоек «атрибут-значение» (Ai-Vi), (i=1,2,...,n)
83 по одной двойке для каждого атрибута Ai в заголовке. Для любой заданной двойки «атрибут-значение» Vi является значением из единственного домена Di, который связан с атрибутом Ai. Отношение Заголовок отношения Тип микросхемы
Нелинейность
Дифференциальная нелинейность
Абсолютная погрешность
Выходное напряжение низкого уровня
Выходное напряжение высокого уровня
Ток потребления Icc1
Ток потребления Icc2
А1
А2
А3
А4
А5
А6
А7
А8
V1
V2
V3
V4
V5
V6
V7
V8
К272ПВ1А
±0,05
±0,1
±0,127
0,3
2,4
3
5
К272ПВ1Б
±0,1
±0,2
±0,127
0,3
2,4
3
5
………
….
….
….
….
….
….
….
Тело отношения
D1
D2
D3
D4
D5
D6
D7
D8
Домены
Рис. 2.1 Степень отношения – это число его атрибутов. Отношение степени один называют унарным, степени два – бинарным, степени три – тернарным, ..., а степени n – n-арным. Например, на рис.2.1 «Микросхема» – 8. Кардинальное число или мощность отношения – это число его кортежей. Мощность отношения «Микросхема» равна числу строк, входящих в тело отношения. Кардинальное число отношения изменяется во времени в отличие от его степени. Два кортежа отношения не могут быть дубликатами друг друга, т.к. множества не содержат все совпадающие элементы. Пусть R – отношение с атрибутами A1, A2, ..., An. Говорят, что множество атрибутов K=(Ai, Aj, ..., Ak) отношения R является возможным ключом R тогда и только тогда, когда они удовлетворяют двум независимым от времени условия: - уникальность: в произвольный заданный момент времени никакие два различных кортежа R не имеют одного и того же значения для Ai, Aj, ..., Ak. - минимальность: ни один из атрибутов Ai, Aj, ..., Ak не может быть исключен из K без нарушения уникальности.
84 Каждое отношение обладает хотя бы одним возможным ключом, т.к. по меньшей мере, комбинация всех его атрибутов удовлетворяет условию уникальности. Один из возможных ключей (выбранный произвольным образом) принимается за его первичный ключ. Остальные возможные ключи, если они есть, называются альтернативными ключами. Вышеупомянутые и некоторые другие математические понятия явились теоретической базой для создания реляционных СУБД, разработки соответствующих языковых средств и программных систем, обеспечивающих их высокую производительность, и создания основ теории проектирования баз данных. Пользователь реляционных СУБД применяет эквиваленты этих понятий: - отношение – таблица (иногда файл); - кортеж – строка (иногда запись); - атрибут – столбец, поле. При этом принимается, что «запись» означает «экземпляр записи», а «поле» означает «имя и тип поля».
2.2. Реляционная база данных Реляционная база данных – это совокупность отношений, содержащих всю информацию, которая должна храниться в БД [20 – 22]. Пользователи воспринимают такую базу данных как совокупность таблиц. В табл. 2.1 приведены примеры задания базы данных, построенные по инфологической модели базы данных «Детали». При составлении подобных таблиц выполняются требования. 1. Каждая таблица состоит из однотипных строк и имеет уникальное имя. 2. Строки имеют фиксированное число полей (столбцов) и значений. Множественные поля и повторяющиеся группы недопустимы, т.е. в каждой позиции таблицы на пересечении строки и столбца всегда имеется в точности одно значение или ничего. 3. Строки таблицы обязательно отличаются друг от друга хотя бы единственным значением, что позволяет однозначно идентифицировать любую строку такой таблицы. 4. Столбцам таблицы однозначно присваиваются имена, и в каждом из них размещаются однородные значения данных. 5. Полное информационное содержание базы данных представляется в виде явных значений данных. Такой метод представления является единственным. Не существует каких-либо специальных связей или указателей, соединяющих одну таблицу с другой.
85 6. При выполнении операций с таблицей ее строки и столбцы можно обрабатывать в любом порядке безотносительно к их информационному содержанию. Этому способствует наличие имен таблиц и их столбцов, а также возможность выделения любой их строки или любого набора строк с указанными признаками. Таблица 2.1 Детали: Д Название Назначение 1 2 3 4 Расход материала: Д Материал Вес 1 2 3 4
Материал: М Имя 1 2 3 4 5 6 7 8
Поставщики материала:
Поставки: П М 1 1 1 1 2 2 2 3 3 4 4 5 5 5
П 1 2 3 4 5 Города: Город
Страна
Размеры: Д 1 1 1 2 2 3 3 3 4 4
Сорт
Вес
Цена
L
H
V
Дата
2.3. Задачи проектирования Информационные управляющие системы предприятий содержат много БД, распределенных между несколькими ЭВМ, связанными сетью, различных подразделений. Собрать данные в одной интегрированной базе данных может небольшое предприятие при решении небольшого числа задач. БД могут объединять данные, необходимые для решения одной или нескольких прикладных задач. Эти БД называют прикладными БД. БД могут объединять данные, относящиеся к какой-либо предметной области (например, финансам, оборудованию, производимым изделиям, комплектующим и т.п.). Эти БД называют предметными БД.
86 Предметные БД позволяют обеспечить поддержку любых текущих и будущих приложений, поскольку набор их элементов данных включает в себя наборы элементов данных прикладных БД. Предметные БД создают основу для обработки неформализованных, изменяющихся и неизвестных запросов и приложений. Если осуществлять проектирование БД на текущих и предвидимых приложениях, то можно ускорить создание информационной системы, структура которой учитывает наиболее часто встречающиеся пути доступа к данным. Методологии проектирования применяют как предметный, так и прикладной подходы. Предметный подход используется для построения первоначальной информационной структуры, а прикладной – для ее совершенствования с целью повышения эффективности обработки данных. При проектировании информационной управляющей системы проводят анализ целей системы и выявляют требования к ней отдельных пользователей. Сбор данных начинается с изучения сущностей предприятия и процессов, использующих эти сущности. Сущности группируются по следующим признакам: - сходству, т.е. частоте их использования для выполнения тех или иных действий; - количеству ассоциативных связей между ними (например, станок – рабочий, мастер – производственный участок, контроллер – микросхема и прочее). Сущности или группы сущностей, обладающие наибольшим сходством и (или) с наибольшей частотой ассоциативных связей, объединяются в предметные БД. Для проектирования и ведения каждой предметной БД (нескольких БД) назначается АБД, который принимает непосредственное участие (руководит) проектированием базы. Основная цель проектирования БД – это сокращение избыточности хранимых данных, позволяющее оптимизировать объем используемой памяти, уменьшать затраты на многократные операции обновления избыточных копий и устранение возможности возникновения противоречий из-за хранения в разных местах сведений об одном и том же объекте. При проектировании БД применяется понятие универсального отношения. В одно универсальное отношение включаются все представляющие интерес атрибуты, и оно может содержать все данные, которые предполагается размещать в БД в будущем. Для малых БД (включающих не более 15 атрибутов) универсальное отношение может использоваться в качестве отправной точки при проектировании БД. При применении универсального отношения существуют следующие трудности: - избыточность;
87 - потенциальная противоречивость; - аномалии включения; - аномалии удаления. Избыточность данных связана с тем, что данные могут повторяться (табл.2.1). Это нежелательное явление. Потенциальная противоречивость или аномалии обновления проявляется в том, что вследствие избыточности можно обновить данные в одной строке, оставляя их неизменными в других. Если поставщик материала М1 сообщил о своем переезде в другой город и была обновлена строка с материала М1, то у поставщика материала М1 появляется два адреса, один из которых не актуален. Следовательно, при обновлениях необходимо просматривать всю таблицу для нахождения и изменения всех подходящих строк. Аномалии включения состоит в том, что в БД не может быть записан новый поставщик, если поставляемый им материал не используется в производстве деталей. Нельзя ввести и новый материал, который предлагает существующий поставщик. Аномалии удаления существует при необходимости удаления всех материалов, поставляемых данным поставщиком, или всех деталей, при изготовлении которых применяются эти материалы. При таких удалениях будут утрачены сведения о поставщике. Эти сложности не будут существовать, если выделить в отдельные таблицы сведения о деталях, материалах, расходе материалов, поставщиках и их поставках, а также создать связующие таблицы «Детали» и «Поставки». При проектировании БД выполняют нормализацию. Нормализация – это разбиение таблицы на две или более, обладающие лучшими свойствами при включении, изменении и удалении данных. Окончательная цель нормализации сводится к получению такого проекта базы данных, в котором каждый факт появляется лишь в одном месте, т.е. исключена избыточность информации. Это делается не столько с целью экономии памяти, сколько для исключения возможной противоречивости хранимых данных. Каждая таблица в реляционной БД удовлетворяет условию, в соответствии с которым в позиции на пересечении каждой строки и столбца таблицы всегда находится единственное атомарное значение, и никогда не может быть множества таких значений. Любая таблица, удовлетворяющая этому условию, называется нормализованной. Ненормализованные таблицы (таблицы, содержащие повторяющиеся группы) не допускаются в реляционной БД. Всякая нормализованная таблица автоматически считается таблицей в первой нормальной форме, сокращенно 1НФ. В дополнение к 1НФ определяют дальнейшие уровни нормализации – вторую нормальную форму (2НФ), третью нормальную форму (3НФ) и т.д. По существу, таблица находится в 2НФ, если она находится в 1НФ и удовлетворяет некоторому
88 дополнительному условию, суть которого будет рассмотрена ниже. Таблица находится в 3НФ, если она находится в 2НФ и, помимо этого, удовлетворяет еще другому дополнительному условию и т.д. Таким образом, каждая нормальная форма является более ограниченной, более желательной, чем предшествующая. Теория нормализации основывается на наличии той или иной зависимости между полями таблицы. Определены два вида таких зависимостей: функциональные и многозначные. Определим функциональную зависимость. Поле В таблицы функционально зависит от поля А той же таблицы в том случае, когда в любой заданный момент времени для каждого из различных значений поля А обязательно существует только одно из различных значений поля В. Допускается, что поля А и В могут быть составными. Например, в табл.2.1 поле «Страна» функционально зависит от составного ключа «Поставщик, Город». Однако последняя зависимость не является функционально полной, так как Страна функционально зависит и от части ключа – поля «Город». Определим полную функциональную зависимость. Поле В находится в полной функциональной зависимости от составного поля А, если оно функционально зависит от А и не зависит функционально от любого подмножества поля А. Определим многозначную зависимость. Поле А многозначно определяет поле В той же таблицы, если для каждого значения поля А существует хорошо определенное множество соответствующих значений В. В табл.2.2 приведен пример многозначной зависимости. Деталь Деталь 1 Деталь 1 Деталь 1 Деталь 1 Деталь 1 …
Станок Станок 1 Станок 1 Станок 2 Станок 2 Станок 2 …
Таблица 2.2 Рабочий Петров Иванов Петров Сидоров Федоров …
Существует более строгое определение нормальной формы. Таблица находится в первой нормальной форме (1НФ) тогда и только тогда, когда ни одна из ее строк не содержит в любом своем поле более одного значения и ни одно из ее ключевых полей не пусто. Таблица находится во второй нормальной форме (2НФ), если она удовлетворяет определению 1НФ и все ее поля, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом.
89 При проведении нормализации таблиц, в которые введены цифровые (или другие) заменители составных и (или) текстовых первичных и внешних ключей, следует хотя бы мысленно подменять их на исходные ключи, а после окончания нормализации снова восстанавливать. Таблица находится в третьей нормальной форме (3НФ), если она удовлетворяет определению 2НФ и не одно из ее неключевых полей не зависит функционально от любого другого неключевого поля. Таблица находится в нормальной форме Бойса-Кодда (НФБК), если и только если любая функциональная зависимость между полями сводится к полной функциональной зависимости от возможного ключа. В следующих нормальных формах (4НФ и 5НФ) учитываются не только функциональные, но и многозначные зависимости между полями таблицы. Для их описания познакомимся с понятием полной декомпозиции таблицы. Полной декомпозицией таблицы называют такую совокупность произвольного числа ее проекций, соединение которых полностью совпадает с содержимым таблицы. Таблица находится в пятой нормальной форме (5НФ) тогда и только тогда, когда в каждой ее полной декомпозиции все проекции содержат возможный ключ. Таблица, не имеющая ни одной полной декомпозиции, также находится в 5НФ. Четвертая нормальная форма (4НФ) является частным случаем 5НФ, когда полная декомпозиция должна быть соединением ровно двух проекций. Не просто подобрать реальную таблицу, которая находилась бы в 4НФ, но не была бы в 5НФ. Таким образом, нормализация – это процесс последовательной замены таблицы ее полными декомпозициями до тех пор, пока все они не будут находиться в 5НФ. На практике же достаточно привести таблицы к НФБК и с большой гарантией считать, что они находятся в 5НФ. Это требует проверки, хотя нет алгоритма такой проверки. Рассмотрим процесс приведения таблиц к НФБК. Процесс приведения основывается на том, что единственными функциональными зависимостями в любой таблице должны быть зависимости вида K→F, где K – первичный ключ, а F – некоторое другое поле. Это следует из определения первичного ключа таблицы, в соответствии с которым K->F всегда имеет место для всех полей данной таблицы. Цель нормализации состоит именно в том, чтобы избавиться от всех других функциональных зависимостей, которые имеют иной вид, чем K→F. Если подменить на время нормализации коды первичных (внешних) ключей на исходные ключи, то следует рассматривать два события. Событие 1. Таблица имеет составной первичный ключ вида, скажем, (К1,К2), и включает также поле F, которое функционально зависит от части этого ключа, например, от К2, но не от полного ключа. В этом случае
90 следует формировать другую таблицу, содержащую К2 и F (первичный ключ – К2), и удалить F из первоначальной таблицы: Заменить T(K1,K2,F), первичный ключ (К1,К2), ФЗ К2→F на T1(K1,K2), первичный ключ (К1,К2), и T2(K2,F), первичный ключ К2. Случай 2. Таблица имеет первичный (возможный) ключ К, не являющееся возможным ключом поле F1, которое функционально зависит от К, и другое неключевое поле F2, которое функционально зависит от F1. В этом случае формируется другая таблица, содержащая F1 и F2, с первичным ключом F1, и F2 удаляется из первоначальной таблицы: Заменить T(K,F1,F2), первичный ключ К, ФЗ F1→F2 на T1(K,F1), первичный ключ К, и T2(F1,F2), первичный ключ F1. Для любой заданной таблицы, повторяя применение двух рассмотренных правил, почти во всех практических ситуациях можно получить множество таблиц, которые находятся в окончательной нормальной форме и не содержат каких-либо функциональных зависимостей вида, отличного от K→F. Рассмотрим пример. Применим рассмотренные правила для полной нормализации универсального отношения «Деталь». Шаг 1. Определение первичного ключа таблицы. Предположим, что каждая деталь имеет уникальное название, относится к единственному виду и приготавливается по единственной технологии, т.е. название детали однозначно определяет ее назначение и технологию изготовления. Пусть название организации поставщика материалов и город однозначно определяют этого поставщика, а город – страну его нахождения. Поставщик может осуществлять в один и тот же день только одну поставку каждого материала, т.е. название материала, название организации поставщика, город и дата поставки однозначно определяют вес и цену поставленного материала. Тогда в качестве первичного ключа отношения «Деталь» определим следующий набор атрибутов: Деталь, Дата_И (Изготовления), Материал, Поставщик, Город, Дата_П. Шаг 2. Выявление полей, функционально зависящих от части составного ключа. Поле Название функционально зависит только от поля Деталь, как и поле Назначение, т.е. Деталь→Название, Деталь→Назначение. Получим зависимости, определяющие, как и кто будет изготавливать деталь: Деталь→Технология изготовления (Деталь, Дата_И)→Количество Материал→Качество
91 (Деталь, Материал)→Вес Город→Страна (Поставщик, Город, Дата_П)→Цена Шаг 3. Формирование новых таблиц. Полученные функциональные зависимости определяют состав таблиц, которые можно сформировать из данных универсального отношения: Деталь (Деталь, Название, Назначение) Технологии (Деталь, Технология) Расход (Деталь, Дата_И, Количество) Материалы (Материал, Качество) Состав (Деталь, Материал, Вес) Города (Город, Страна) Поставщики (Поставщик, Город, Дата_П, Вес, Цена). Шаг 4. Корректировка исходной таблицы. После выделения из состава универсального отношения указанных выше таблиц, там остались лишь сведения о поставщиках, для хранения которых целесообразно создать таблицу Поставщики (Поставщик, Город), т.е. использовать часть исходного первичного ключа, так как остальные его части уже ничего не определяют. Таким образом, процедура последовательной нормализации позволила получить проект лучший, чем тот, который приведен в табл.2.1.
2.4. Процедура проектирования Процесс проектирования информационных управляющих систем является достаточно сложной задачей. Он начинается с построения инфологической модели данных, т.е. идентификации сущностей. При построении даталогической модели выполняют следующие действия. 1. Представить каждый стержень (независимую сущность) таблицей базы данных (базовой таблицей) и специфицировать первичный ключ этой базовой таблицы. 2. Представить каждую ассоциацию (связь вида «многие к многим» или «многие к многим к многим» и т.д. между сущностями) как базовую таблицу. Использовать в этой таблице внешние ключи для идентификации участников ассоциации и специфицировать ограничения, связанные с каждым из этих внешних ключей. 3. Представить каждую характеристику как базовую таблицу с внешним ключом, идентифицирующим сущность, описываемую этой характеристикой. Специфицировать ограничения на внешний ключ этой таблицы и ее первичный ключ – по всей вероятности, комбинации этого
92 внешнего ключа и свойства, которое гарантирует «уникальность в рамках описываемой сущности». 4. Представить каждое обозначение, которое не рассматривалось в предыдущем пункте, как базовую таблицу с внешним ключом, идентифицирующим обозначаемую сущность. Специфицировать связанные с каждым таким внешним ключом ограничения. 5. Представить каждое свойство как поле в базовой таблице, представляющей сущность, которая непосредственно описывается этим свойством. 6. Для того чтобы исключить в проекте непреднамеренные нарушения каких-либо принципов нормализации, выполнить процедуру нормализации. 7. Если в процессе нормализации было произведено разделение какихлибо таблиц, то следует модифицировать инфологическую модель базы данных и повторить перечисленные шаги. 8. Указать ограничения целостности проектируемой базы данных и дать (если это необходимо) краткое описание полученных таблиц и их полей. На рис. 2.2 показан синтаксис описания проектных решений. Создать таблицу «ТАБЛИЦУ» «ОПИСАНИЕ ТАБЛИЦЫ Первичный ключ «ПОЛЯ»
Внешний ключ «ПОЛЯ» ИЗ «ЦЕЛЬ» NULL значения
«ДОПУСТИМЫ» «НЕ» «КАСКАДИРУЕТСЯ»
Удаление из «ЦЕЛЬ»
«ОГРАНИЧИВАЕТСЯ» «УСТАНАВЛИВАЕТСЯ NULL ЗНАЧЕНИЕ» «КАСКАДИРУЕТСЯ»
Обновление «КЛЮЧ ЦЕЛИ»
«ОГРАНИЧИВАЕТСЯ» «УСТАНАВЛИВАЕТСЯ NULL ЗНАЧЕНИЕ»
Поля
«ПОЛЕ» тип данных Формат
Ограничение целостности и описания полей
Рис.2.2 На рис. 2.2 применены следующие понятия:
93 - «ТАБЛИЦА» имя проектируемой базовой таблицы; - «ОПИСАНИЕ ТАБЛИЦЫ» - любой текст, характеризующий назначение и (или) содержание таблицы; - «ПОЛЯ» - описание имен полей, разделенных запятыми; - «ЦЕЛЬ» - имя таблицы, первичный ключ которой используется как внешний ключ проектируемой таблицы; - «КЛЮЧ ЦЕЛИ» - специфируется «первичный ключ» цели; - «ПОЛЕ» - имя поля проектируемой таблицы, включая и имена внешних ключей. Контрольные вопросы 1. Как осуществляют запись данных? 2. С какой целью разработаны СУБД? 3. Определите понятие языка запросов СУБД. 4. Перечислите основные функции СУБД. 5. Что называется инфологической моделью данных? 6. Что называется даталогической моделью данных и какие модели существуют? 7. Определите понятие сущности. 8. Определите понятие типа сущности. 9. Определите понятие экземпляра сущности. 10. Определите понятие атрибута. 11. Определите понятие ключа. 12. Определите понятие связи. 13. Какие виды связей могут быть между двумя сущностями? 14. Определите назначение ER-диаграмм. 15. Какие классы сущностей существуют? 16. Определите понятие стержневой сущности. 17. Определите понятие ассоциативной сущности. 18. Определите понятие характеристической сущности. 19. Определите понятие первичного ключа. 20. Определите понятие внешнего ключа. 21. Определите понятие целостности базы данных. 22. Определите понятие домена. 23. Определите понятие заголовка. 24. Определите понятие тела. 25. Определите понятие степени отношения. 26. Определите понятие мощности отношения. 27. Дайте определение реляционной базы данных. 28. Какие требования должны выполняться при составлении таблиц реляционной базы данных? 29. В чем состоят задачи проектирования баз данных? 30. Какая классификация баз данных существует?
94 31. По каким признакам группируются сущности? 32. Определите понятие универсального отношения. 33. Что такое нормализация при проектировании баз данных? 34. Какие действия выполняются при построении даталогической модели?
95
БИБЛИОГРАФИЧЕСКИЙ СПИСОК 1. Уемов А.И. Системный подход и общая теория систем. М.: Мысль, 1978. 2. Месарович М., Такахара И. Общая теория систем: математические основы. М.: Мир, 1978. 3. Финаев В.И., Глод О.Д. Основы теории систем. Учебное пособие. – Таганрог: Изд-во ТРТУ, 2000. 4. Рогозов Ю.И., Финаев В.И. Проектирование информационноуправляющих систем. Учебное пособие. – Таганрог: Изд-во ТРТУ, 2002. 5. Костюк В.И., Зайченко Ю.П., Кирилюк Н.И. и др. Основы построения АСУ. Учебное пособие для вузов. М.: Сов. радио, 1977. 6. Сыроежин И. М. Очерки теории производственных организаций. М.: Экономика, 1970. 7. Государственный стандарт Российской Федерации. Унифицированные системы документации. Унифицированная система организационнораспорядительной документации. ГОСТ Р 6.30-97 8. Государственный стандарт Союза ССР. Единая система программной документации. ГОСТ 19.004-80. 9. Государственный стандарт Союза ССР. Виды, комплектность и обозначение документов при создании автоматизированных систем. ГОСТ 34.201-89. 10. Берталанфи Л. фон. История и статус общей теории систем// Системные исследования: Ежегодник, 1972. -М.: Наука, 1973. - с.20-37. 11. Сигорский В.П. Математический аппарат инженера. - Киев: Техника, 1977. 766 с. 12. Месарович М., Такахара И. Общая теория систем: математические основы. - М.: Мир, 1978. -311 с. 13. Холл А. Опыт методологии для системотехники. М.: Сов. радио, 1975. -448с. 14. Черняк Ю.И. Системный анализ в управлении экономикой. -М.: Экономика, 1975. -191 с. 15. Brackett, J., and C. McGowan: "Applying SADT to Large System Problems", SofTech Technical Paper TP059,January 1977. 16. Connor, M.: "Structured Analysis and Design Technique - SADT", Auerbach portfolio 32-04-02, 1979. 17. Дэвид А. Марка и Клемент МакГоуэн. Методология структурного анализа и проектирования. – М.: Мир, 1992. 18. Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем. – М.: Финансы и статистика, 1989. – 351 с.
96 19. Дейт К. Руководство по реляционной СУБД DB2. – М.: Финансы и статистика, 1988. – 320 с. 20. Джексон Г. Проектирование реляционных баз данных для использования с микроЭВМ. -М.: Мир, 1991. – 252 с. Кириллов В.В. Структуризованный язык запросов (SQL). – СПб.: ИТМО, 1994. – 80 с. 21. Мейер М. Теория реляционных баз данных. – М.: Мир, 1987. – 608 с. 22. Тиори Т., Фрай Дж. Проектирование структур баз данных. В 2 кн., – М.: Мир, 1985. Кн. 1. – 287 с.: Кн. 2. – 320 с.
97
Финаев Валерий Иванович Пушнин Алексей Валерьевич
ИНФОРМАЦИОННОЕ ОБЕСПЕЧЕНИЕ СИСТЕМ УПРАВЛЕНИЯ Ответственный за выпуск Финаев В.И. Редактор Белова Л.Ф. Корректор Селезнева Н.П.
ЛП №020565 Офсетная печать Заказ №
Подписано к печати Усл. п.л. – 5,6 Уч.-изд.л. – 5,4 Тираж 500 “С”
_____________________________________________________ Издательство Таганрогского государственного радиотехнического университета ГСП 17А, Таганрог, 28, Некрасовский, 44 Типография Таганрогского государственного радиотехнического университета ГСП 17А, Таганрог, 28, Энгельса, 4
