Информационные системы в экономике

Базовые конфигурации:

1С: Бухгалтерия 8,

1С: Управление Торговлей 8,

1С: Зарплата и управление персоналом 8,

1С: Управление производственным предприятием 8.

Последняя конфигурация включает все предыдущие



Рис. 4.5. Построение 1С

Базовые конфигурации:

1С: Бухгалтерия 8,

1С: Управление Торговлей 8,

1С: Зарплата и управление персоналом 8,

1С: Управление производственным предприятием 8.

Последняя конфигурация включает все предыдущие

Функционал конфигураций характеризуется схемой Рис 4.6.

Рис. 4.6. Базовые конфигурации 1С.

Функционал компонент приведен далее.

Клиенты (CRM)

Взаимодействие с клиентами

Классификация клиентов

Анализ эффективности контактов

Запасы

Закупки

Складской учет

Возвратная тара

Инвентаризация

Удаленный склад

Торговля

Заказы покупателей

Ценообразование

Оптовая торговля

Розничная торговля

Комиссионная торговля

Подключение торгового оборудования

Денежные средства

Оперативное планирование денежных средств

Касса

Банки

Клиент-банк

Взаиморасчеты с контрагентами

Бухгалтерия

Материальные ценности

Учет расчетов

Денежные операции

Торговые операции

Производственные операции

Основные средств и нематериальные активы

Заработная плата

Операции завершения периода

Стандартные отчеты

Налоги

НДС

Налог на прибыль

Упрощенная система налогообложения

ЕНВД

Налоговые декларации

Отчетность

Список отчетов

Формирование отчетов

Отчетность в электронном виде

Сохранение и повторное использование

Зарплата

Регламентированная зарплата

Управленческая зарплата

Налоги и взносы с оплаты труда

Персонифицированный учет для Пенсионного фонда

Персонал

Планирование потребностей и обеспечение кадрами

Компетенции и аттестации

Финансовая мотивация

Кадровый учет

МСФО

Трансляция данных для учета по МСФО

Основные средства по МСФО

Материальные ценности по МСФО

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

Бюджетирование

Финансовое планирование

Контроль исполнения финансовых планов

Бюджетная отчетность

Планирование

Планирование продаж

Укрупненное планирование производства

Посменное планирование

Планирование закупок

Мониторинг цен поставщиков

Производство

Данные об изделиях

Затраты

Давальческое сырье

Себестоимость

Основные средства

Данные об основных средствах

Управление ремонтами

4.7 Классификация КИС

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

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

Примеры: "1С", БЭСТ, "Инотэк", ИНФИН Инфософт. 5-50 тыс.$

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

Примеры: Concord XAL, Exact NS-2000, Platinum SQL, PRO/MIS, Scala, SunSystem, Docs Open. 50-200 тыс. $

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

Примеры: "БОСС-корпорация, "Галактика", "Парус-корпорация", JD Edwards, MFG-Pro, SyteLine. 50-500 тыс.$

г)Крупные интегрированные системы. Отличаются от средних набором вертикальных рынков и глубиной поддержки процессов управления большими многофункциональными группами предприятий (холдингов или ФПГ). >500 тыс.$

Примеры: SAP R/3, Baan IV, Oracle Applications, IFS Applications.



5. Моделирование систем по методологии IDEF

Методология IDEF содержит в себе целый ряд технологий.

5.1 Основные понятия

Вначале дадим несколько понятий, используемых далее.

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

Метод - это систематическая процедура или техника описания компонент системы (например, проектирование потоков и структур данных).

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

Средства - инструментарий для поддержки и усиления методов.

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

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

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

5.2 История вопроса

В конце 70-ых годов ХХ века ВВС США предложили и реализовали Программу интегрированной компьютеризации производства ICAM (Integrated Computer Aided Manufacturing), направленную на увеличение эффективности промышленных предприятий посредством широкого внедрения компьютерных (информационных) технологий. Для удовлетворения этой потребности в рамках программы ICAM была разработана методология IDEF (ICAM Definition). Она позволяет исследовать структуру, параметры и процессы производственных, технических, организационных, экономических систем (в дальнейшем, просто систем). В самом начале методология IDEF состояла из трех частных технологий моделирования, основанных на графическом представлении систем:

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

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

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

Программными средствами, которые реализуют технологии IDEF0, IDEF1 являются BPWin, ERWin, Designs, Altova.

В дальнейшем к трем технологиям добавились еще тринадцать, и IDEF стало расшифровываться как Integration Definition Metodology - Методология описания интеграции. Основными пользователями данной методологии являются Министерство обороны США, крупные и средние корпорации США и всего мира.

5.3 Перечень стандартов IDEF

Всего заявлено 16 стандартов IDEF. Дадим их перечень и краткое описание.

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

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

IDEF1X (IDEF1 Extended) - Data Modeling - технология проектирования реляционных (табличных) баз данных. Заключается в построении инфологических моделей данных типа "сущность-связь" (ERD - Entity-Relationship Diagram) в нотации этого стандарта.

IDEF2 - Simulation Model Design (проектирование модели поведения) - технология динамического моделирования систем.

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

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

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

IDEF6 - Design Rationale Capture Method (рациональный сбор данных о проекте) - технология использования рационального опыта проектирования. Назначение: сохранение рационального опыта проектирования информационных систем для предотвращения структурных ошибок при новом проектировании.

IDEF7 - Information System Auditing - технология аудита информационной системы.

IDEF8 - Human-System Interaction Design Method- технология проектирования интерфейса пользователя. IDFE8 фокусирует внимание разработчиков интерфейса на программировании желаемого взаимного поведения интерфейса и пользователя на трех уровнях:

выполняемой операции (что это за операция),

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

на деталях интерфейса (какие элементы управления предлагает интерфейс для выполнения операции).

IDEF9 - Business Constraint Discovery Method - технология анализа имеющихся условий и ограничений, в том числе физических, юридических, политических, и их влияния на принимаемые решения в процессе повторного проектирования.

IDEF10 - Implementation Architecture Modeling - моделирование архитектуры выполнения (физической реализации системы).

IDEF11 - Information Artifact Modeling - информационное моделирование артефактов.

IDEF12 - Organization Modeling- организационное моделирование.

IDEF13 - ThreeSchema Mapping Design - трехсхемное проектирование карт.

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

Стандарты IDEF7, IDEF10, IDEF11, IDEF12, IDEF13 определены как востребованные, однако так и не были полностью разработаны.



6. Технология IDEF0 функционального проектирования систем

Технология IDEF0 предназначена для создания функциональной модели, отображающей, что и в какой последовательности система делает. Стандарт принят в нескольких международных организациях, в том числе в НАТО и МВФ. Существует российский стандарт Р 50.1.028-2001 технологии IDEF0, принятый в 2001 году.

6.1 Синтаксис IDEF0

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

6.1.1 Блок

Блок описывает функцию. Типичный блок показан на рис. 6.1.

Рис. 6.1. Блок

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

Составить договорпланировать ресурсынаблюдать

наблюдать за выполнениемпроектировать системуэксплуатировать

разработать договоризготовить компонентпроверить деталь

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

6.1.2 Стрелка

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

Рис. 6.2. Синтаксис стрелок

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



6.1.3 Синтаксические правила блоков и стрелок

Для блоков применяются следующие правила:

Размеры блоков должны быть достаточными для того, чтобы включить имя и номер блока.

Блоки должны быть прямоугольными.

Блоки должны быть нарисованы сплошными линиями.

Для стрелок применяются следующие правила:

Ломаные стрелки изменяют направление только под углом 90 град.

Стрелки рисуются сплошными линиями различной толщины.

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

Концы стрелок должны касаться внешней границы блока, но не должны пересекать ее.

Стрелки присоединяются к блоку на его сторонах. Присоединение в углах не допускается.

6.1.4 Семантические правила блоков и стрелок

Имя блока должно быть активным глаголом или глагольным оборотом.

Каждая сторона блока должна иметь стандартное отношение "блок - стрелки": вход, управление, выход, механизм, вызов механизма (Рис 6.3).

Рис. 6.3. Стороны блока



Каждый тип стрелки соединяется со своей стороной блока.

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

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

стрелки выхода должны связываться с правой стороной блока;

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

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

Это одно из главных соглашений IDEF0

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

Чтобы связать стрелку с меткой, следует использовать "молнию" ()

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

6.2 Диаграммы

IDEF0-модели состоят из трех типов документов:

графических диаграмм,

текста,

глоссария.

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

Рис. 6.4. Пример диаграммы IDEF0

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

6.3 Контекстная диаграмма верхнего уровня

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

Рис. 6.5. Контекстная диаграмма на бланке

6.4 Дочерняя диаграмма

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

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



Рис. 6.6. Декомпозиция

6.5 Нумерация блоков

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

Рис 6.7. Нумерация блоков



Показанные на рис. 6.7 коды означают, что диаграмма является декомпозицией 1-го блока диаграммы, которая, в свою очередь, является декомпозицией 6-го блока диаграммы А0, а сами коды образуются присоединением номера блока.

6.6 Стрелки блока

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

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

Рис. 6.8 показывает 5 возможных типов стрелок блока в IDEF0, каждый из типов соединяется со своей стороной блока.

Рис. 6.8. Пять типов стрелок

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

Спецификацииотчет об испытанияхбюджет

Производственные требованиядоговордиректива

Экономистнакладнаятребования

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

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

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

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

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

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

6.7 Внутренние стрелки

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

В IDEF0 существует шесть видов внутренних стрелок:

выход - вход,

выход - управление,

выход - механизм исполнения,

выход - обратная связь на управление,

выход - обратная связь на вход,

выход - обратная связь на механизм.

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

Рис. 6.9. Внутренняя стрелка "выход - вход"

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

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

Рис. 6.10. Внутренняя стрелка "выход - управление"

Рис. 6.11. Внутренняя стрелка "выход - механизм"

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

Рис. 6.12. Внутренняя стрелка "выход - обратная связь на управление"



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

Рис. 6.13. Внутренняя стрелка "выход - обратная связь на вход"

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

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



Рис. 6.14. Внутренняя стрелка "выход - обратная связь на механизм"

6.8 Другие виды стрелок

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

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

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

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

Туннели. Все граничные стрелки на дочерней диаграмме должны соответствовать стрелкам родительского блока кроме туннельных стрелок. Все стрелки родительского блока должны соответствовать граничным стрелкам на дочерней диаграмме кроме туннельных стрелок.

Туннель обозначается скобками в начале и\или в конце стрелки.

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

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

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

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



Рис. 6.17. Еще один пример применения туннеля

6.9 Правила построения диаграмм IDEF0

При построении диаграмм необходимо выполнять следующие правила.

В составе модели должна присутствовать контекстная диаграмма A-0, которая содержит только один блок. Номер единственного блока на контекстной диаграмме A-0 должен быть 0.

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

Блоки на диаграмме, расположенные вверху слева "доминируют" над блоками, расположенными внизу справа. "Доминирование" понимается как влияние, которое блок оказывает на другие блоки диаграммы.

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

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

Каждый блок дочерней диаграммы получает номер, помещаемый в правом нижнем углу; порядок нумерации - от верхнего левого к нижнему правому блоку. Номера от 1 до 6.

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

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

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

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

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

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

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

Рис. 6.18.

Стрелки соединяются, если они представляют сходные данные и их источник не указан на диаграмме (рис. 6.19).



Рис. 6.19.

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

Рис. 6.20.

Таким образом, обеспечивается показ обратной связи при минимальном числе линий и пересечений.

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

Рис 6.21.



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

Рис 6.22.

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

Рис 6.23.

Следует минимизировать число петель и поворотов каждой стрелки (рис.6.24).

Рис 6.24.



6.10 Стандартный бланк технологии IDEF0

На рис. 6.25 типовая диаграмма IDEF0 показана вместе с находящейся на ее полях служебной информацией. Служебная информация состоит из верхнего и нижнего колонтитулов (заголовка и "подвала").

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

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

Таблица 6.1 Элементы заголовка

Поле	Назначение
USED AT	Внешние ссылки на данную диаграмму (заполняется на печатном документе вручную)
Author, date, project, rev	Содержит ФИО автора диаграммы, дату создания, наименование проекта, в рамках которого она создавалась, дату последних изменений
Notes 1 ... 10	Зачеркивается очередная цифра при очередном исправлении
Working	Новая диаграмма, глобальные изменения или новый автор для существующей диаграммы
Draft	Диаграмма достигла некоторого приемлемого для читателей уровня и готова для представления на утверждение.
Recommended	Диаграмма и тексты прорецензированы и утверждены. Какие-либо изменения не предвидятся
Publication	Диаграмма одобрена и утверждена. Изменения не предвидятся.
Reader	ФИО читателя
Date	Дата знакомства читателя с диаграммой
Context	Набросок расположения блоков на родительской диаграмме, на котором подсвечен декомпозируемый данной диаграммой блок. Для контекстной диаграммы в поле помещается ТОР

Рис 6.25. Стандартный бланк

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

Таблица 6.2. Элементы "подвала"

Поле	Назначение
Node	Номер диаграммы, совпадающий со ссылкой родительского блока.
Title	Имя родительского блока
Number (еще называют С-Number)	Уникальный идентификатор данной версии данной диаграммы. Cостоит из инициалов автора и последовательного номера, например KVG005. Если диаграмма замещает другую диаграмму, номер заменяемой диаграммы может быть заключен в скобки - KVG005 (KVG004).



7. Технология IDEF3 по описанию процессов

Официально стандартIDEF3 "Сбор данных по описанию процессов" был опубликован в США в 1995году.

7.1 Предназначение IDEF3

IDEF3 является стандартом документирования технологических процессов, происходящих на предприятии и в учреждении. Он предоставляет графические инструменты для исследования и моделирования их сценариев.

Пример документирования процесса подготовки договора в IDEF3 показан на рис 7.1.

Рис 7.1. Схема процесса в стандарте IDEF3

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

Исполнение каждого сценария сопровождается двумя потоками документов, которые определяют:

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

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

Средства документирования и моделирования IDEF3 позволяют решать следующие задачи:

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

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

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

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

7.2 Схема процесса

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

На рис. 7.2 изображена Схема процесса для сценария заявки на товары.

Рис 7.2. Пример Схемы процесса

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

Каждая работа может быть декомпозирована, т.е. детализирована с любой необходимой точностью. Например, мы можем декомпозировать работу "Заказ бывшему поставщику", представив ее отдельным процессом и построив для нее Схему процесса. Эта диаграмма будет называться дочерней, по отношению к изображенной на рис. 7.2, а та, соответственно родительской. Номера блоков дочерних диаграмм включают номер родительского блока. Т.е., если родительский блок имеет номер "3", то блоки на его декомпозиции будут иметь номера "3.1", "3.2" и т.д.

Стрелки на диаграмме отображают перемещения объекта между работами в ходе процесса. Стрелки на Схеме процесса бывают трех видов (табл. 7.1):

Таблица 7.1. Стрелки Схемы процесса

Тип	Изображение	Смысл
Предшествование		Вторая работа начинается только после завершения первой
Объектный поток		Выход первой работы является входом второй, поэтому вторая работа начинается только после завершения первой
Нечеткое отношение		Вторая работа может начаться и даже закончиться до завершения первой

7.3 Перекресток

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

Таблица 7.2. Типы перекрестков Схем процесса

Обозначение	Наименование	Смысл при слиянии стрелок	Смысл при ветвлении стрелок
	Асинхронное И	Все предшествующие процессы должны быть завершены	Все следующие процессы должны быть запущены
	Синхронное И	Все предшествующие процессы должны быть завершены одновременно	Все следующие процессы запускаются одновременно
	Асинхронное Или	Хотя бы один из предшествующих процессов должен быть завершен	Хотя бы один из следующих процессов должен быть запущен
	Синхронное Или	Если несколько предшествующих процессов завершаются, то одновременно	Если несколько следующих процессов запускаются, то одновременно
	Исключающее Или	Только один предшествующий процесс должен быть завершен	Только один следующий процесс запускается

Все перекрестки в Схеме процесса нумеруются, перед номером ставится буква "J".

7.4 Примеры перекрестков

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



Рис 7.3. Асинхронное И

Пример 2. Лекции. Перекресток "исключающее Или" например, отображает тот факт, что студент не может одновременно быть направлен на лекции по двум разным курсам (рис 7.4).

Рис 7.4. Исключающее Или

Пример 3. Оплата. После покупки покупатель может расплатиться карточкой, наличными, карточкой и наличными вместе (рис 7.5).



Рис 7.5. Асинхронное ИЛИ

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

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

7.5 Схема объекта

Схемы объекта рассматривают тот же самый процесс "С точки зрения объекта". На рис. 7.6 представлен процесс подготовки договора с точки зрения самого договора.



Рис 7.6. Пример Схемы объекта

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

Таблица 7.3. Стрелки Схем объекта

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

Ссылки на работу в Схеме объекта бывают трех типов (Таблица 7.4).

Таблица 7.4. Ссылки

Тип	Изображение	Смысл
Вызвать и продолжить		Ссылка нуждается только в инициации
Вызвать и ждать		Ссылка нуждается в инициации и завершении
Заметка		Комментарий



8. Технология IDEF1Х информационного моделирования

Официально стандарт IDEF1X "Обобщенное описание для информационного моделирования" (Integration Definition For Information Modeling) был опубликован в США в 1993 году.

8.1 Предназначение IDEF1X

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

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

Технология IDEF1X подразделяется на уровни. Каждый уровень соответствует определенной фазе проекта. Такой подход полезен при создании систем по принципу "сверху вниз".

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

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

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



8.2 Основные понятия ER-диаграмм

Мы опишем работу с ER-диаграммами в нотации Баркера. Пример ER-диаграммы приведен на рис 8.7.

Рис 8.1. ER-диаграмма

Сущность - собирательное понятие повторяющегося объекта внешнего мира: предмета, явления, процесса, события.

Каждая сущность должна иметь наименование, выраженное существительным в единственном числе.

Примерами сущностей могут быть такие классы объектов как "Поставщик", "Сотрудник", "Накладная".

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

Рис 8.2. Сущность

Экземпляр сущности - это конкретный представитель сущности.

Например, экземпляром сущности "Сотрудник" может быть "Сотрудник Иванов".

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

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

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

Например, сущность "Подразделение банка" имеет такие атрибуты как наименование, местоположение, численность. Примеры атрибутов сущности "Сотрудник": "Табельный номер", "Фамилия", "Имя", "Отчество", "Должность", "Зарплата" и т.п.

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

Рис 8.3. Атрибуты

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

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

Сущность может иметь несколько различных ключей.

Ключевые атрибуты изображаются на сущности подчеркиванием (рис 8.10).

Рис 8.4. Ключевой атрибут

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

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

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

Графически связь изображается линией, соединяющей две сущности (рис 8.11).

Рис 8.5. Связь



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

8.3 Типы связей

Различают три типа связей между двумя сущностями (рис 8.12).

Рис 8.6. Типы связей

Связь между двумя сущностями Е1 и Е2 относится к типу "один к одному", если для каждого экземпляра первой сущности можно указать 0 или 1экземпляр второй сущности и для каждого экземпляра второй сущности можно указать 0 или 1 экземпляр первой сущности.

Примерами связей типа 1:1 служат связи между:

студентами и зачетными книжками,

государствами и валютами,

офицерами и табельным оружием,

автомобилями и прицепами,

компьютерами и материнскими платами,

гражданами и заграничными паспортами.

У каждого студента или нет зачетной книжки, или есть только одна. И для каждой зачетки или студент не указан, или имеется только один.

Связь между двумя сущностями Е1 и Е2 относится к типу "один ко многим", если для каждого экземпляра первой сущности можно указать 0 или более экземпляров второй сущности и для каждого экземпляра второй сущности можно указать 0 или 1 экземпляр первой сущности.

Примерами связей 1:М служат связи между

банками и вкладами,

вкладами и взносами,

накладными и пунктами накладной,

типами кузова и автомобилями,

группами и студентами,

отделами и сотрудниками,

ведомостями и строками ведомостей,

товарами и ценами,

районами и клиентами,

клиентами и заявками.

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

Связь "один ко многим" самая распространенная.

Связь между двумя сущностями Е1 и Е2 относится к типу "многие ко многим", если для каждого экземпляра первой сущности можно указать 0 или более экземпляров второй сущности и для каждого экземпляра второй сущности можно указать 0 или более экземпляров первой сущности.

Примерами связей M:N служат связи между

продуктами и странами,

студентами и дисциплинами,

сотрудниками и проектами,

заявками и товарами,

книгами и авторами,

автомобилями и заправочными станциями,

проживавшими и комнатами общежитий,

магазинами и покупателями.

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

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

Например, связь между странами и продуктами типа M:N получается с помощью промежуточной сущности "Поставка" и двух связей "один ко многим" (рис 8.13).

Рис.8.7. Реализация связи "многие ко многим"

Связь между студентами и дисциплинами типа M:N получается с помощью промежуточной сущности "Экзаменационная оценка".

Связь М:1 это связь 1:М.

Каждая связь может иметь одну из двух модальностей связи(рис 8.14):



Рис 8.8. Модальность

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

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

Связь может иметь разную модальность с разных концов (Рис. 8.5).

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

Каждый <экземпляр СУЩНОСТИ 1><МОДАЛЬНОСТЬ СВЯЗИ><НАИМЕНОВАНИЕ СВЯЗИ><ТИП СВЯЗИ><экземпляр СУЩНОСТИ 2>.

Каждая связь может быть прочитана как слева направо, так и справа налево. Связь на Рис. 8.5 читается так:

Слева направо: "Каждый сотрудник может иметь несколько детей".

Справа налево: "Каждый ребенок должен принадлежать ровно одному сотруднику".

8.4 Пример разработки ER-модели

При разработке ER-моделей мы должны получить следующую информацию о предметной области:

Список сущностей предметной области.

Список атрибутов сущностей.

Описание связей между сущностями.

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

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

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

Хранить информацию о покупателях.

Печатать накладные на отпущенные товары.

Следить за наличием товаров на складе.

Выделим все существительные в этих предложениях - это будут потенциальные кандидаты на сущности и атрибуты. Проанализируем их. Непонятные термины будем выделять знаком вопроса:

Покупатель - явный кандидат на сущность.

Накладная - явный кандидат на сущность.

Товар - явный кандидат на сущность

(?)Склад - а вообще, сколько складов имеет фирма? Если несколько, то это будет кандидатом на новую сущность.

(?)Наличие товара - это, скорее всего, атрибут, но атрибут какой сущности?

Сразу возникает очевидная связь между сущностями - "покупатели могут покупать много товаров" и "товары могут продаваться многим покупателям". Первый вариант ER-диаграммы выглядит так (рис 8.15).

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

Рис 8.9. Связь между сущностями

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

Рис 8.10. Уточненная ER-диаграмма



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

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

Каждый товар имеет наименование, цену, единицу измерения.

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

Каждый склад имеет свое наименование.

Снова выпишем все существительные, которые будут потенциальными атрибутами, и проанализируем их:

Юридическое лицо - термин риторический, мы не работаем с физическими лицами. Не обращаем внимания.

Наименование покупателя - явный атрибут покупателя.

Адрес - явный атрибут покупателя.

Банковские реквизиты - явный атрибут покупателя.

Наименование товара - явный атрибут товара.

(?)Цена товара - похоже, что это атрибут товара. Отличается ли этот атрибут от цены в накладной?

Единица измерения - явный атрибут товара.

Номер накладной - явный уникальный атрибут накладной.

Дата накладной - явный атрибут накладной.

(?)Список товаров в накладной - список не может быть атрибутом. Вероятно, нужно выделить этот список в отдельную сущность под названием "Строка накладной".

...