1 Ю. А. Кравченко CALS- технологии в решениях

1 Ю. А. Кравченко CALS- технологии в решениях SAP

2 ПРЕДИСЛОВИЕ Настоящее учебное пособие ориентировано на студентов специальностей 230104 и 230202, изучающих курс «CALS- технологии в решениях SAP», пособие может быть также использовано при проведении занятий и самостоятельных работ студентами и преподавателями других специальностей, а также при самообучении.

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

4 ВВЕДЕНИЕ В анализе и ведении жизненного цикла продукции на крупном современном предприятии имитационные методы моделирования занимают особо важное место. Современные САПР технологических процессов обеспечивают сквозное проектирование и имеют многомодульную структуру. Для решения актуальных проблем совместного функционирования компонентов САПР различного назначения, в составе модулей конкретной системы должны разрабатываться PDM-системы управления проектными данными. При разработке сложных систем и процессов широко применяются методы имитационного моделирования. Актуальной задачей является исследование смоделированных сложных систем и технологических процессов. Постановка задачи и синтез программы исследования может осуществляться на основе методов эволюционного моделирования. В настоящий момент изготовление сложных промышленных объектов подразумевает согласованность работы многих предприятий – участников жизненного цикла. CALS-технологии служат средством интеграции промышленных автоматизированных систем в многофункциональную систему, обеспечивающую создание единого информационного пространства. CALS-технологии являются средством эффективного взаимодействия существующих автоматизированных систем проектирования и управления . По аналогии с автоматизированным проектированием в CALS выделяют: лингвистическое, информационное, программное, математическое, методическое, техническое и организационное обеспечения.

5 ВВЕДЕНИЕ В контексте ЖЦ система проектирования программного обеспечения информационных систем (ПОИС) является составной частью процесса разработки и развития системы в целом. Поскольку сложность систем повышается, необходимо располагать эффективными методами моделирования. Наличие строгого стандарта языка моделирования является существенным. Язык моделирования должен включать: элементы моделей – фундаментальные концепции моделирования и их семантика; нотацию – визуальное представление элементов моделирования; правила применения элементов в рамках разрабатываемого ПО. Перечисленные проблемы указали на потребность в программно-технологических средствах специального класса – Case-средствах, реализующих Case-технологию, создание и сопровождение ПОИС. Case-технология представляет собой совокупность методов проектирования ИС, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех этапах разработки и сопровождения ИС и разрабатывать приложения в соответствии с информационными потребностями пользователя. Большинство существующих Case-средств основаны на методах структурного или объектно-ориентированного анализа и проектирования использующих спецификаций в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств.

6 ОСНОВЫ CALS - ТЕХНОЛОГИЙ Основы информационной интеграции Методическую основу совершенствования деятельности предприятия составляет анализ жизненного цикла (ЖЦ) продукции, выявление процессов, входящих в его состав, и реализацию парадигмы комьютерно-интегрированных производств (КИП) на основе CALS-технологий. В основе концепции CALS-технологий лежит использование единого информационного пространства, обеспечивающего единообразные способы обмена информации и взаимодействия всех участников жизненного цикла. Концепции или стандарты CALS определяют набор правил и стандартов, с помощью которых организуется данное взаимодействие. Преимущества применения CALS-технологий: 1. Ускорение разработки продукции и подготовки производства. 2. Сокращение производственных и эксплуатационных издержек. 3. Повышение уровня сервиса на этапах эксплуатации. 4. Исключение дублирования информации.

7 ОСНОВЫ CALS - ТЕХНОЛОГИЙ Жизненный цикл изделия – совокупность взаимосвязанных процессов создания и последовательного изменения состояния изделия, обеспечивающего потребность клиента. Смысл концепции – CALS-протокол цифровой передачи данных, обеспечивающий стандартный механизм их доставки и текущего изменения для проектирования сложных технических объектов, в отличие от бумажного и простейших форм электронного документа оборота, основанных на электронных образцах и бумажных носителях. В рамках CALS речь идет об использовании интегрированных информационных моделях БД, продукциях и моделях. Стратегией CALS является создание единого информационного пространства (ЕИП).

8 ОСНОВЫ CALS - ТЕХНОЛОГИЙ Информационная поддержка изделий Набор методов языков и моделей для представления в электронном виде информации об изделии (информационная поддержка изделий – ИПИ технологии) называется технологией представления данных. Предметная область – это множество объектов и существующие на этом множестве отношения. Информационная модель – представляет собой множество понятий (сущностей) в совокупности со значениями их свойств (атрибутами) и заданные на этом множестве отношения. При автоматизации каждого этапа ЖЦ изделия создают частную информационную модель предметной области.

9 ОСНОВЫ CALS - ТЕХНОЛОГИЙ Множество понятий и их атрибутов составляют модель частной задачи, а множество отношений между понятиями – логическую основу алгоритмов обработки информации. Модель, как правило, служит для обмена данными, являясь источником первичной информации для прикладных систем, и собирает все результаты обработки данных. Технологии интеграции данных представляют собой набор методов для интеграции автоматизированных процессов ЖЦ и относящихся к ним данных, представленных в электронном виде в рамках единого информационного пространства. Интеграция нужна для создания структуры, объединяющей ранее полученные частные информационные модели. Цель интеграции на первом этапе – это формирование на основе информационных стандартов совокупности электронных документов, аналогичных бумажным, и передача их участникам ЖЦ изделия. Второй этап интеграции – это создание взаимосвязанной совокупности процессов, составляющих и обеспечивающих ЖЦ изделия.

10 ОСНОВЫ CALS - ТЕХНОЛОГИЙ Электронный технический документ (ЭТД) ЭТД – надлежащим образом оформленная и зафиксированная на носителе техническая информация, представленная в пригодной для восприятия форме. ЭТД может иметь 2 формы представления: - внутреннюю (фиксация ЭТД на машинном носителе); - внешнюю (представление документа в доступном для визуального обозрения виде). Структура ЭТД: Реквизитная часть – последовательность записей, каждая из которых описывает один атрибут и содержит идентификатор его назначения. Содержательная часть – состоит из набора информационных единиц. ЭТД может быть простым и составным. ЭЦП (электронная цифровая подпись) – неотъемлемая часть ЭТД, предназначена для удостоверения информации, составляющей содержательную часть.

11 ОСНОВЫ CALS - ТЕХНОЛОГИЙ PDM-системы Одним из разделов ИПИ-технологии является технология управления данными PDM-системы. PDM (Product Data Management) Для реализации PDM-технологии существуют специализированные программные средства, называемые PDM–средствами. Основные задачи PDM-систем: - создание ЕИП для всех подразделений предприятий; - автоматизация и управление конфигурацией изделия; - построение системы качества продукции; - создание электронного архива технической документации. PDM-системы могут использоваться: как рабочая среда пользователя; как средство интеграции данных.

12 ОСНОВЫ CALS - ТЕХНОЛОГИЙ Функции рабочей среды пользователя: управление хранением данных и документов; управление процессами - система отслеживает все операции пользователя с данными, в том числе следит за версиями, кроме того, система управляет потоком работ и занимается протоколированием действий пользователя и изменений данных; управление составом изделия – система хранит информацию о составе изделия и его варианте, важной особенностью является наличие нескольких описаний для различных предметных областей; классификация – система позволяет производить распределение изделий и документов в соответствии с различными классификациями.

13 ОСНОВЫ CALS - ТЕХНОЛОГИЙ Преимущество использования PDM-систем состоит в сокращении времени разработки изделия, которое, в свою очередь, обусловлено 4 аспектами: сокращение временных затрат на поиск, копирование и архивирования данных; улучшение взаимодействия между конструкторами, технологами и другими участниками разработки, т.е. поддержка методики параллельного проектирования; улучшение контроля за потоком работ; увеличение доли заимствованных или слегка измененных компонентов изделий.

14 ОСНОВЫ CALS - ТЕХНОЛОГИЙ Система менеджмента качества (СМК) Можно выделить 5 основных функций PDM-системы как инструмента информационного обеспечения СМК. Поддержка планирования процесса (этап планирования) осуществляется с помощью управления нормативной документацией (т.е. хранение в виде электронных документов нормативной документации, отслеживание календарных планов, задание рабочих инструкций, а также требований характеристик продукции соответствующих технических заданий). Поддержка выполнения процесса (этап осуществления) – автоматизированное управление потоками работ. Поддержка проверки процессов и продукций (этап проверки) - автоматизированный контроль хранимой информации об изделии. Поддержка анализа результатов измерений (этап проверки). Это связано с огромными информационными массивами, накапливаемыми в ходе процесса функционирования СМК. Поддержка улучшений процессов (этап действия) – осуществляется путем управления изменениями и несоответствующей продукцией.

15 ОСНОВЫ CALS - ТЕХНОЛОГИЙ Интегрированная логистическая поддержка (ИЛП) Одним из факторов, определяющим конкурентоспособность на рынке, является совокупная стоимость владения изделием. Среди ключевых факторов, влияющих на стоимость владения изделия, называют его надежность и ремонтопригодность. Еще одним важным аспектом, определяющим затраты на этапе эксплуатации, является пригодность к поддержке, которая определяется как степень соответствия конструктивных характеристик и среды его эксплуатации требованиям обеспечения готовности к работе. Для решения проблемы пригодности к поддержке CALS предлагает использование ИЛП. ИЛП – это методология оптимизации стоимости ЖЦ изделия с учетом критериев наилучшей пригодности изделия к поддержке эксплуатации, надежности и ремонтопригодности, основанная на построении интегрированной логистической системы. ИЛП касается как заказчика, так и поставщика. Она работает на протяжении всего жизненного цикла, определяя потенциальные и фактические причины затрат на эксплуатацию, и позволяет принимать решение для их снижения путем изменения либо конструкции изделия, либо среды его эксплуатации. В настоящее время базовым международным стандартом является военный стандарт Def 00-60.

16 ОСНОВЫ CALS - ТЕХНОЛОГИЙ Реализация ИЛП. Процедура поставки начинается с приглашения к тендеру, поступающего от заказчика к поставщикам. Документы, представляемые заказчиками: план организации ИЛП (ILS Plan) – требования к ИЛП изделия; стратегию выполнения ЛА (LSA Strategy) – требования к проведению ЛА; описание условий использования (Use study); порядок работы (Statement of Work) - требования к перечню задач, которые обязательно должны быть выполнены поставщиком, а также отчетность по ним. Отчетность включает в себя следующие документы: перечень данных контракта (Contract Data Requirements List); описание информационных единиц (Data Item Descriptions) - требования к содержанию каждой информационной единицы; перечень данных БД ЛА (Data Selection Sheet) – обязательные информационные объекты;

17 ОСНОВЫ CALS - ТЕХНОЛОГИЙ В ответ поставщик должен предоставить заказчику свой набор тендерной документации: интегрированный план поддержки (Integrated Support Plan); план выполнения элементов ЛА (LSA Plan); планы реализации элементов ИЛП (ILS Elements Plans); план программы анализа неисправности (Failure Modes Effects and Criticality Analysis Programme Plan); план программы разработки процедуры обслуживания (Reliability Centered Maintenance Programme Plan); план программ и анализа ремонта (Level Of Repair Analysis Programme Plan); план управления документацией (Documentation Management Plan). Дальнейшее сотрудничество также происходит путем обмена стандартизованной информацией. Конкретные условия оговариваются контрактом.

18 ОСНОВЫ CALS - ТЕХНОЛОГИЙ Нормативная база CALS-технологий Стандартные интерфейсы взаимодействия в рамках единого информационного пространства предназначены для интеграции всех информационных систем, используемых участниками жизненного цикла изделия. В силу необходимости быстрой интеграции большого множества программных систем, интерфейсы взаимодействия необходимо согласовывать с международными стандартами для организации ЕИП. Функциональные стандарты предназначены для описания бизнес-процессов предприятия и их влияния на данные об изделии. Информационные стандарты предназначены для классификации структуры данных об изделии (базовым является стандарт ISO10303 STEP). Стандарты на программную архитектуру рассматривают архитектуру программных средств, позволяющую обмениваться данными без непосредственного участия пользователя. Коммуникационные стандарты предназначены для описания способов физической передачи данных Стандарты на интерфейс с пользователем описывают интерфейс, который предлагается для диалога с пользователем.

19 СТАНДАРТ STEP Принципы создания стандарта STEP Для организации ЕИП в CALS-технологиях предполагается применить интегрированную информационную модель изделия. Таким образом, возникает потребность в единой и понятной форме представлении информации об изделии, которая должна обеспечивать организацию информационного обмена между различными компьютерными системами (STEP – Standard for the Exchange of Product data). STEP - это стандарт, регламентирующий компьютерное представление данных об изделии и обмен ими. STEP создает полную информационную модель изделия, а также способы реализации обмена данными, представленными согласно его полной модели. Структуру STEP можно условно представить схемой, состоящей из трех уровней: Ядро стандарта содержит инструментарий STEP, с помощью которого задаются остальные компоненты, а также реализуется информационный обмен. Базовое представление информации об изделии, инвариантное по отношению к предметной области. Оно включает базовую информационную модель. Содержит представление информации об изделии, специфичное для конкретной предметной области.

20 СТАНДАРТ STEP Основные компоненты STEP Методы описания предназначены для всех информационных моделей и позволяют задать структуру данных для описания изделия. Методы реализации производят обмен данными и обмен информацией, представленной с помощью методов описания STEP. Методология тестирования на соответствие определяет основные принципы тестирования различных программных средств на соответствие стандарту STEP. Интегрированные ресурсы задают базовое представление информации об изделии. Являются основой для построения протокола применения. Протокол применения определяет специфичное для конкретной предметной области представление информации об изделии как основу для обмена данными, построенную на базе интегрированных ресурсов STEP.

21 СТАНДАРТ STEP Методы описания Предназначены для информационных моделей интегрируемых ресурсов и протоколов применения STEP. Для этого требуется формальный язык описания, понятный как компьютеру, так и пользователю. Основным методом описания стандарта STEP является язык EXPRESS (ISO 10303-11), представляющий собой формальный язык описания информационных моделей, т.е. язык информационного моделирования. Кроме текстового представления языка имеется и графическое (EXPRESS-G). На этом языке описываются данные об изделии, при этом предметная область не имеет значения. EXPRESS может применяться вне стандарта STEP, как самостоятельный язык информационного моделирования. Независимость EXPRESS от предметной области достигается за счет того, что применяется обобщенное понятие «сущность». Каждая сущность обладает характерными атрибутами, выражающими свойство моделируемого объекта.

22 СТАНДАРТ STEP Методы реализации. Для организации полноценного информационного обмена необходимы стандартные механизмы – методы реализации. Методы реализации представляют собой интерфейс между различными компьютерными системами, но не привязанный к какой-либо из них. Т.е. является независимым от программно-аппаратной платформы. В STEP имеется 2 метода реализации: формат обменного файла; программный интерфейс; Наиболее распространенным методом реализации является обмен с помощью файлов (в STEP это «обменный файл»). Обменный файл STEP – это текстовый или двоичный файл особой структуры, содержащий данные, являющиеся предметом обмена. Содержимое обменного файла задано информационной моделью и данными, соответствующими ей.

23 СТАНДАРТ STEP Интегрированные ресурсы. Теоретическая основа представления данных об изделии. Задают базовое представление данных, инвариантное по отношению к предметной области. Интегрированные ресурсы служат основой к построению специфичных для конкретной предметной области протоколов применения. Множество интегрированных ресурсов хранится в томах стандартов STEP. Все тома можно разделить на обеспечивающие инструмент описания ПО (предметной области) и описывающие конкретные области. Протокол применения. Является специальным представлением информации об изделии. Т.е. специфичным для конкретной предметной области, в отличие от базового представления в интегрированных ресурсах. Протоколы применения используют при организации обмена данными. Т.е. структура представляемой информации должна соответствовать представлению данных в конкретном протоколе. Каждое программное средство STEP может использовать один или несколько протоколов применения. Процесс построения специфичного представления на основе базового называется интерпретацией. Она состоит в выборе необходимых элементов базовой информационной модели и их интерпретации (приспособлений) в контексте предметной области. Т.е. информационная модель добавляется новыми атрибутами и ограничениями [5]. Каждый протокол применения STEP имеет свой набор абстрактных текстов, предназначенный для проверки степени соответствия некоторого программного продукта данному протоколу применения и содержит условия этого соответствия. Проверка производится согласно методологии тестирования.

24 СТАНДАРТ STEP Состав протокола применения. Любой протокол применения удовлетворяет четко определенным потребностям промышленности. Существует методология создания протоколов применения: указание предметной области и её требований к обмену данными (тип изделия, типы данных об изделии, этапы жизненного цикла); модель процессов предметной области (Application Activity Model, AAM), данный раздел описывает процессы предметной области, создающие и использующие данные об изделии. Описание представлено с помощью методологии функционального моделирования; справочная модель предметной области (Application Reference Model, ARM), где определяются информационные потребности процессов, выражаемые понятиями предметной области. Эти понятия собраны в группы (unit of functionality (UoF)). Информация представляется как в виде обычного текста, так и с помощью методологии информационного моделирования или языка EXPRESS;

25 СТАНДАРТ STEP интерпретированная модель предметной области. Данный раздел рассматривает стандартную информационную модель предметной области, с помощью которой организуется совместное использование или обмен данными об изделии; таблицы отображения. Отображают информационные потребности предметной области с помощью элементов стандартной информационной модели; классы соответствия. Данный раздел описывает подмножество информационной модели предметной области, которое программный продукт должен поддерживать для определенного уровня соответствия стандарту; набор абстрактных текстов, предназначенный для проверки соответствия некоторого программного средства данному протоколу.

26 СТАНДАРТ STEP Методология тестирования Для решения проблемы проверки соответствия программных продуктов существует методология тестирования на соответствие стандарту. Это набор методов проверки для определенного протокола применения STEP. Данный набор методов зависит от метода реализации обмена данными в конкретном программном средстве. Набор абстрактных текстов. Любая компьютерная система должна быть протестирована на соответствие стандарту. Специально для этого созданы наборы абстрактных текстов. Один набор составляет отдельный раздел стандартов, который содержит условия соответствия компьютерной системы стандарту обмена данных (протоколу применения). Для каждого протокола существует свой набор абстрактных тестов, который включает в себя перечень тестовых случаев использования данных об изделии. В нем также присутствует описание критериев, необходимых для признания корректности обработки компьютерной системой данного тестового случая и соответствия системы протоколу применения в целом.

27 СТАНДАРТ STEP Схема использования стандарта STEP Рис. 1. Использование международного стандарта ISO STEP. ОФ – обменный файл CAD – Computer Aided Design (САПР) CAE – Computer Aided Engineering (системы автоматизированного инженерного анализа) CAM - Computer Aided Manufacture (системы автоматизированной подготовки производства) PDM – Product Data Management (системы управления данными) ERP – Enterprise Resource Planning (системы управления ресурсами предприятия) SDAI – Standard DATA Access Interface С помощью программного интерфейса SDAI на одном или нескольких языках программирования организуется обмен с применением доступной БД по изделию. Первоначально проводится согласование протоколов применения. Компьютерные приложения должны поддерживать доступ к БД при помощи SDAI. Процесс обмена данными состоит в обращении приложений к БД с применением вызова функций интерфейса [5,8,21]. Вариант использования международного стандарта ISO STEP, представленный на рис.1, может быть применен как к отдельному предприятию, так и к партнерам по кооперации, в том числе к виртуальному предприятию.

28 ЯЗЫК ОПИСАНИЯ ДАННЫХ EXPRESS Основы языка Применяется для единой формы представления данных. Форма описания не должна допускать двусмысленную интерпретацию, иначе обмен данными будет невозможен. Язык EXPRESS является формализованным, т.е. допускает только толкование информации. Основные термины, используемые в EXPRESS Информация – это факты, понятия и инструкции в произвольном неформализованном виде. Информация об изделии – содержит факты, понятия и инструкции, характеризующие изделие. Данные – это формализованное представление информации, подходящее для передачи, интерпретации и обработки пользователями и компьютерами. Здесь факты, понятия, инструкции – формализованные значения. Информационная модель – это формализованная модель ограниченного набора фактов, понятий и инструкций, удовлетворяющих некоторым требованиям. Т.е. информационная модель изделия – это формализованная модель информации, описывающая изделие, ограниченная требованиями к его описанию. Язык EXPRESS является формой представления данных, т.е. EXPRESS – это язык информационного моделирования.

29 ЯЗЫК ОПИСАНИЯ ДАННЫХ EXPRESS Свойства языка EXPRESS Независимость от предметной области. Язык EXPRESS используется в качестве формы представления данных из различных предметных областей и поэтому должен быть нейтральным. Независимость от методов реализации обмена данными. В STEР используются 2 метода обмена данными: обменный файл; стандартный интерфейс SDAI. Поэтому, чтобы применять в них одну информационную модель язык EXPRESS, задающий ее, должен быть от них независим.

30 ЯЗЫК ОПИСАНИЯ ДАННЫХ EXPRESS Независимость от программных средств реализации обмена данными. В силу реализации обмена данными между различными аппаратно-программными платформами. Поддержка модульности информационных моделей и связей между ними. В силу того, что модель может быть достаточно велика и может пересекаться с моделями из других предметных областей, возникает необходимость разделения некоторых моделей на блоки, чтобы, с одной стороны, упростить их, а с другой, избежать избыточности. Таким образом, EXPRESS позволяет связывать несколько информационных моделей путем определения связей между их элементами. Воспринимаемость информационной модели как человеком, так и компьютером. Данный язык должен быть жестко формализованным, обладая единственным способом интерпретации заданной на нем информации. Но, кроме того, очень важна наглядность, так как информационные модели на EXPRESS создаются людьми.

31 ЯЗЫК ОПИСАНИЯ ДАННЫХ EXPRESS Объектно-ориентированный подход Суть этого подхода состоит в том, что основным элементом модели является не понятие предметной области, а нейтральное понятие «сущности». Сущность выражает некоторый абстрактный образец объекта реального мира. А сами объекты определяются с помощью «экземпляра сущности». Экземпляр сущности – это абстрактное понятие, называющее представителя класса объектов реального мира с общими характеристиками. Сущность выражает класс объектов, заданный общими характеристиками. Общие характеристики объектов определяются «атрибутами сущности». Атрибут сущности – абстрактное понятие, представляющее отдельную характеристику класса объектов реального мира. Каждый атрибут сущности обладает именем. Приведем пример описания сущности «line» (отрезок): ENTITY line; x1: real; y1: real; х2: real; y2: real; END_ ENTITY.

32 ЯЗЫК ОПИСАНИЯ ДАННЫХ EXPRESS Компоненты языка Информационная модель на языке EXPRESS выражается в виде текста, состоящего из синтаксических элементов (компонентов языка), включающих: алфавит; комментарии; зарезервированные слова; знаки; идентификаторы; литералы. Из этих компонентов формируются семантические элементы языка (понятия). Текст которых состоит из строк, строки из символов. Алфавит предназначен для формирования всех остальных компонентов, включает в себя арабские цифры, прописные и строчные буквы английского алфавита и специальные символы. Комментарии предназначены для повышения наглядности информационной модели. Бывают встроенные, которые могут встречаться в любом месте, они выделяются символами: (*…*). Могут быть хвостовыми, т.е. в конце строки, начинаются с дефиса. Зарезервированные слова предназначены для выражения различных понятий языка («сущность» - «entity»).

33 ЯЗЫК ОПИСАНИЯ ДАННЫХ EXPRESS Знаки предназначены для разделения других компонентов языка (например, пробел) или для задания операций над ними (например, «+»). Идентификаторы предназначены для наименования строительных блоков информационной модели. Идентификаторы не совпадают с зарезервированными словами. Литералы представляют собой самоопределяющиеся и неизменные значения. Они применяются для выражения значения атрибутов. В EXPRESS существует несколько типов литералов: двоичный, целочисленный, вещественный, простой строковый, кодированный строковый, логический; отличающихся набором и порядком следования, состоящих их символов алфавита языка. 1. Двоичный литерал Предназначен для представления двоичных чисел (рис. 2). %001011 Рис. 2. Структура двоичного литерала

34 ЯЗЫК ОПИСАНИЯ ДАННЫХ EXPRESS 2. Целочисленный литерал Предназначен для представления целых, десятичных цифр (рис.3). 3. Вещественный литерал Предназначен для представления вещественных десятичных чисел, состоящих из обязательной мантиссы и необязательной экспоненты (рис.4). 4.Простой строковый литерал Для представления текстовых значений не может занимать несколько строк и может быть либо простой, либо кодированный (рис. 5). 5. Логический литерал Для представления встроенных в EXPRESS констант (true, false, unknown) Рис.3. Структура целочисленного литерала Рис. 4. Структура вещественного литерала: а – мантисса, б – экспонента 3,3е-8 a) б) a) б) Рис. 5. Структура простого и кодированного строковых литералов: а-простой, б-кодированный

35 ЯЗЫК ОПИСАНИЯ ДАННЫХ EXPRESS Типы данных Основной функцией типа данных является задание области допустимых значений атрибута сущности. Всего в EXPRESS существует 5 категорий типов данных: - простые; - агрегированные; - поименованные; - составные; - обобщенные. Простой тип – встроенный тип данных. Областью его значений являются литералы. Понятие простого типа может быть использовано без предварительного объявления. Литералы не могут быть разложены на более мелкие составляющие. В EXPRESS присутствуют семь простых типов данных: - числовой тип (NUMBER). Все числовые литералы, включая вещественные и целочисленные; - вещественный тип (REAL). Все вещественные (нецелые) числа, без ограничения на точность. В противном случае точность указывается при объявлении типа после ключевого слова в скобках (например, REAL(5)) (рис.6). Рис. 6. Структура вещественного типа данных

36 ЯЗЫК ОПИСАНИЯ ДАННЫХ EXPRESS - целочисленный (INTEGER). Область значений – все целые числа (целочисленные литералы); - строковый (STRING). Область значений – последовательности символов. При необходимости ограничение последовательности символов указывается в круглых скобках после ключевого слова, по аналогии с вещественным типом. Если последовательность символов имеет фиксированную длину, то после объявления типа присутствует ключевое слово FIXED (рис.7). Рис. 7. Структура строкового типа данных

37 ЯЗЫК ОПИСАНИЯ ДАННЫХ EXPRESS - логический (LOGICAL). Область значений – логические литералы TRUE, FALSE, UNKNOWN. Старшинство значений обозначено неравенством: FALSE < UNKNOWN < TRUE; - булевский (BOOLEAN). Область значений – логические литералы TRUE, FALSE. Старшинство значений обозначено неравенством: FALSE < TRUE; - двоичный тип (BINARY). Область значений – это последовательность битов (двоичные литералы). Если последовательность битов имеет ограничение по длине, соответствующее значение указывается в круглых скобках. При фиксированной длине ключевое слово FIXED ставится после объявления типа (рис.8). Рис. 8. Структура двоичного типа данных

38 ЯЗЫК ОПИСАНИЯ ДАННЫХ EXPRESS Агрегированный тип представляет собой встроенный тип языка, элементами области значений которого являются наборы значений. В такой набор включается значение только одного типа, называемого базовым. А сам набор конкретных значений называется экземпляром агрегированного типа, а его отдельные значения называются элементами агрегированного типа. Существует четыре агрегированных типа: массив (ARRAY); список (LIST); множество (SET); мультимножество (BAG). На агрегированные типы языка могут накладываться дополнительные ограничения, требующие уникальности всех элементов, или разрешающие отсутствие отдельных элементов в наборе значений. Многомерные агрегированные типы. Для получения многомерного агрегированного типа необходимо задать в качестве базы одного агрегированного типа другой подобный тип. Таким образом можно получать агрегированные типы неограниченной вложенности, поддерживающее произвольное количество измерений.

39 ЯЗЫК ОПИСАНИЯ ДАННЫХ EXPRESS Поименованный тип - это специально объявленный в информационной модели тип данных, имеющий уникальное имя. Такие типы предназначены для двух случаев: если необходимо использовать сущность в качестве типа данных; когда не хватает возможностей языка EXPRESS и требуется их расширение. Определяемый тип данных задается на основе какого - либо другого типа данных, в том числе и определяемого, накладывая на него некоторые ограничения. Составной тип предназначен для задания типов с нестандартными для EXPRESS областями значений. Составные типы могут быть использованы только для формирования определяемых типов и не подходят для прямого указания областей значений атрибутов сущностей. Существует два основных типа данных: перечисление (ENUMERATION) и выбор (SELECT). Тип «Перечисление» явно перечисляет все экземпляры области значений. Тип «Выбор» задает перечень возможных областей значений.

40 ЯЗЫК ОПИСАНИЯ ДАННЫХ EXPRESS Понятия Семантические элементы, которые несут смысловую нагрузку и определяют содержание представленной информации, называются понятиями. В EXPRESS они выражают содержание информационной модели, сформулированной из конкретных сущностей, определяемых типов и строительных блоков, каждые из которых задаются путем объявления некоторого понятия на языке EXPRESS. Каждый блок имеет свой идентификатор (имя), который используется в ссылках на данный блок. Всего в EXPRESS существует семь основных понятий: Схема. Константы. Определяемый тип. Сущность. Глобальное правило. Функция. Процедура. Схема (SCHEMA). Понятие «схема» выражает отдельную информационную модель. Схема является самым общим понятием, все остальные понятия могут быть указаны внутри нее. Для того чтобы существовала возможность связывания нескольких информационных моделей в единую модель, используются интерфейсные спецификации, т.е. ссылки на соответствующие строительные блоки других схем. Наличие ссылок позволяет использовать строительные блоки других схем при построении данной. В теле схемы все объявления остальных компонентов идут в произвольном порядке (рис.9).

41 ЯЗЫК ОПИСАНИЯ ДАННЫХ EXPRESS Объявление схемы начинается с ключевого слова “SCHEMA”, за которым следует ее имя, и заканчивается ключевым словом “END_SCHEMA”. Между именем и завершением объявления находится тело схемы [5]. SCHEMA example;Интерфейсные спецификации Константы функция процедура сущность глобальное правило END_SCHEMA. Константы (CONSTANT). Понятие «константа» выражает поименованное значение некоторого типа данных, которые нельзя изменить. Базовым типом константы может быть простой агрегированный или поименованный тип. Константы могут быть заданы в рамках схемы глобального правила, функций или процедуры: SCHEMA имя

42 ЯЗЫК ОПИСАНИЯ ДАННЫХ EXPRESS CONSTANT int_lenth: INTEGER 100; ……………….; ……………….; END_CONSTANT; Определяемый тип (TYPE). Определяемый тип выражает поименованный тип данных языка EXPRESS, заданный на основе какого - либо (исходного) типа данных. Его назначением является расширение возможностей языка EXPRESS за счет создания типа с новыми свойствами. В качестве исходного могут выступать простой, агрегированный, другой определяемый или составной типы. При этом область значения вновь создаваемого определяемого типа будет либо полностью совпадать, либо являться подмножеством области значения исходного типа.

43 ЯЗЫК ОПИСАНИЯ ДАННЫХ EXPRESS Правило области значения определяемого типа. В объявлении определяемого типа задаются несколько правил области значений. Каждое такое правило представляет собой условие вхождения значения из области значений исходного в область значения определяемого типа, т.е. данное правило является своего рода фильтром, содержащим в себе выражение, которое в результате своего выполнения должно дать значение логического типа: ложь (FALSE), истина (TRUE) или неопределенность (UNKNOWN). Принцип отбора значений исходного типа, входящих в область значения определяемого типа, состоит в том, что такое значение подставляется в выражение каждого правила после ключевого слова SELF: TYPE week = INTEGER; WHERE R1: SELF ≥ 1; R2: SELF ≤ 7; END_TYPE; В данном примере указан определяемый тип «неделя» (week), - номер дня. Определение правил в области значения начинается с ключевого слова WHERE и продолжается вплоть до окончания объявления типа.

44 ЯЗЫК ОПИСАНИЯ ДАННЫХ EXPRESS Сущность (ENTITY). Является основным элементом языка. Имеет в рамках схемы уникальный идентификатор, основные свойства заданы с помощью атрибутов и локальных правил. В EXPRESS есть возможность определять отношение наследования между двумя или более сущностями, при котором сущность-потомок получает все свойства сущности-предка (рис.10). Атрибут сущности. Каждый атрибут имеет имя, которое должно быть уникальным. Имя атрибута раскрывает его значение в контексте сущности. Область его возможных значений задается путем спецификации типа данных атрибута. ENTITY name;

45 ЯЗЫК ОПИСАНИЯ ДАННЫХ EXPRESS Атрибуты бывают явные и вычисляемые. Явный атрибут выражает свойство сущности, которое обязательно должно получить некоторое заданное в явном виде значение. Применение ключевого слова OPTIONAL указывает на необязательность значения атрибута. В отличие от явного атрибута, значение вычисляемого определяется не в явном виде, а путем вычисления некоторого выражения. Все вычисляемые атрибуты объявляются в единой конструкции DERIVE, которая идет сразу за описанием явных атрибутов. ENTITY square; color: OPTIONAL STRING; side: REAL; DERIVE Perimeter: REAL := 4*side; area: REAL := side**2; END_ENTITY;

46 ЯЗЫК ОПИСАНИЯ ДАННЫХ EXPRESS Локальное правило сущности. Объявление сущности определяет область ее экземпляров. По умолчанию они являются корректными, что не всегда соответствует потребностям проектировщиков. Ограничение на область экземпляров определяют с помощью локальных правил сущности. В EXPRESS существует два вида локальных правил: правило уникальности; правило области значения. Правило уникальности Требует от всех экземпляров уникальности значения одного или нескольких атрибутов. Правило задается конструкцией при помощи ключевого слова UNIQUE.

47 ЯЗЫК ОПИСАНИЯ ДАННЫХ EXPRESS Правило области значения Это сокращение возможных значений атрибутов отдельного экземпляра. Такие правила выражают условия вхождения некоторого экземпляра в область экземпляров сущности, правил может быть несколько, каждое из которых представляет собой одно из условий. Экземпляр входит в область экземпляров сущности, если удовлетворяет всем установленным правилам. Все правила области значений сущности задаются в конструкции «WHERE». Наследование. В EXPRESS сущность определяется как класс объектов реального мира с общими характеристиками. Естественно, что существуют подклассы, в которых объекты, помимо характеристик классов, обладают еще набором собственных характеристик. Чтобы избежать дублирования обозначений свойств, введено отношение наследования. Оно устанавливает связь между сущностями, при которой области экземпляров одних сущностей, называемых потомками, становятся подмножеством экземпляров других сущностей (предков). Для спецификации предка используется конструкция «SUBTYPE OF».

48 ЯЗЫК ОПИСАНИЯ ДАННЫХ EXPRESS Интерфейс между схемами. Для упрощения восприятия EXPRESS позволяет разбивать крупные модели на более мелкие. Причем целостность большой модели сохраняется, т.к. существует инструмент задания связи между схемами, которое задается путем спецификации интерфейса между ними. Интерфейс предназначен для того, чтобы строительные блоки одной схемы были видимы в другой и могли там использоваться. Есть два типа интерфейсов между схемами: использование (USE FROM); ссылка (REFERENCE FROM).

49 ЯЗЫК ОПИСАНИЯ ДАННЫХ EXPRESS Рассмотрим пример реализации интерфейса между схемами с применением отношения наследования, правила области значений и уникальности: SCHEMA man; ENTITY person; name: STRING; age: INTEGER; WHERE born: age ≥ 0; END_ENTITY;

50 ЯЗЫК ОПИСАНИЯ ДАННЫХ EXPRESS ENTITY worker; SUBTYPE OF (person); speciality: STRING; passport: STRING; UNIQUE a1: passport; WHERE adult: age ≥ 16; END_ENTITY; END_SCHEMA;

51 ЯЗЫК ОПИСАНИЯ ДАННЫХ EXPRESS SCHEMA car_driver; USE FROM man; ENTITY driver; SUBTYPE OF (worker); permis de condure: STRING; length of service: INTEGER; UNIQUE a2: permis de condure; END_ENTITY; END_SCHEMA;

52 ЯЗЫК ОПИСАНИЯ ДАННЫХ EXPRESS SCHEMA driver’s_information; REFERENCE FROM car_driver; ENTITY driver; who_is: worker; information: STRING; END_ENTITY; END_SCHEMA.

53 Company Logo Время ожидания обслуживания в очередях Время обслуживания заявок ВХОДНЫЕ ПАРАМЕТРЫ Системы массового обслуживания (СМО) Длины очередей заявок на входах Загрузка устройств в системе Вероятность обслуживания в заданные сроки

54 ОСНОВЫ ИМИТАЦИОННОГО МОДЕЛИРОВАНИЯ СЛОЖНЫХ ДИНАМИЧЕСКИХ СИСТЕМ Теория массового обслуживания В теории массового обcлyживaния объектами исследования являются сложные системы. Анализ процессов функционирования связан с исследованием прохождения через систему потока заявок. Разработчиков подобных сложных систем интересуют прежде всего такие параметры, как пропускная способность проектируемой системы, задержки заявок в системе, эффективность использования имеющегося оборудования и других средств. Анализ функционирования сложных систем носит статистический характер. При этом в качестве математического аппарата моделирования используют теорию массового обслуживания, а в качестве моделей систем - системы массового обслуживания (CMО). Типичными выходными параметрами в СМО являются числовые характеристики таких величин, как время обслуживания заявок в системе, длины очередей заявок на входах, время ожидания обслуживания в очередях, загрузка устройств системы, а также вероятность обслуживания в заданные сроки и т.п. СМО представляет собой некоторое средство (устройство), называемое обслуживающим аппаратом (ОА), вместе с очередями заявок на входах. Более сложные СМО состоят из многих взаимосвязанных ОА. Обслуживающие аппараты СМО в совокупности образуют статические объекты СМО, иначе называемые ресурсами.

55 Приоритеты обслуживания Бесприоритетные дисциплины - FIFO LIFO - случайные Относительные Абсолютные Динамические

56 ОСНОВЫ ИМИТАЦИОННОГО МОДЕЛИРОВАНИЯ СЛОЖНЫХ ДИНАМИЧЕСКИХ СИСТЕМ Дисциплиной обслуживания называют правило выбора заявки из очередей на обслуживание, а величину, выражающую преимущественное право на обслуживание, - приоритетом. В бесприоритетных дисциплинах все транзакты (заявки) имеют одинаковые приоритеты. Среди бесприоритетных дисциплин наиболее популярны дисциплины FIFO («первым пришел - первым обслужен»), LIFO («последним пришел - первым обслужен») и случайные (со случайным выбором заявок из очередей). Для приоритетных дисциплин строится очередь на входе ОА для заявок каждого приоритета. Заявка из очереди с низким приоритетом поступает на обслуживание, если пусты очереди с более высокими приоритетами. Различают приоритеты абсолютные, относительные и динамические. Заявка из очереди с более высоким абсолютным приоритетом, поступая на вход занятого ОА, прерывает уже начатое обслуживание заявки более низкого приоритета. В случае относительного приоритета прерывания не происходит, более высокоприоритетная заявка ждет окончания уже начатого обслуживания. Динамические приоритеты могут изменяться во время прохождения заявки в CMО.

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

58 ОСНОВЫ ИМИТАЦИОННОГО МОДЕЛИРОВАНИЯ СЛОЖНЫХ ДИНАМИЧЕСКИХ СИСТЕМ Определение временных зависимостей переменных, характеризующих состояние СМО, при подаче на входы любых требуемых в соответствии с заданием на эксперимент потоков заявок, называют имитационным моделированием СМО. Имитационное моделирование проводят путем воспроизведения в СМО фактов изменения значения любой переменной, характеризующей состояние системы (событий), происходящих в моделируемом времени. Подход, альтернативный имитационному моделированию, называют аналитическим исследованием СМО. Аналитическое исследование заключается в получении формул для расчета выходных параметров СМО с последующей подстановкой значений аргументов в эти формулы в каждом отдельном эксперименте. Используемые при имитационном и аналитическом моделировании модели СМО называются имитационными и аналитическими соответственно. Поскольку для аналитического моделирования не требуются сколько-нибудь значительные затраты вычислительных ресурсов, аналитические модели удобны в использовании. Но для сложных СМО аналитические модели если и удается получить, то только при принятии упрощающих допущений, ставящих под сомнение адекватность модели. Таким образом, основным подходом к анализу САПР на системном уровне проектирования считают имитационное моделирование, а аналитическое исследование используют для предварительной оценки различных вариантов систем .

59 59 Обязательные элементы имитационных моделей Источники входных заявок Устройства и накопители Управляющие элементы (УЗЛЫ) Имитационная модель

60 ОСНОВЫ ИМИТАЦИОННОГО МОДЕЛИРОВАНИЯ СЛОЖНЫХ ДИНАМИЧЕСКИХ СИСТЕМ Имитационное моделирование СМО Имитационные модели сложных систем состоят из источников входных заявок, устройств и накопителей, управляющих элементов (узлов). Источник входного потока заявок представляет собой алгоритм, в соответствии с которым вычисляются моменты tk появления заявок на входе системы. Источники могут быть зависимыми и независимыми. В зависимых источниках моменты появления заявок связаны с наступлением определенных событий (приход другой заявки). Типичным независимым источником является алгоритм выработки значений tk случайной величины с заданным законом распределения.

61 ОСНОВЫ ИМИТАЦИОННОГО МОДЕЛИРОВАНИЯ СЛОЖНЫХ ДИНАМИЧЕСКИХ СИСТЕМ В имитационной модели устройства представлены алгоритмами выработки значений интервалов обслуживания. Чаще всего это алгоритмы генерации случайных величин с заданным законом распределения. Накопители моделируются алгоритмами определения объемов памяти, занимаемых заявками, приходящими на вход накопителя. Обычно объем памяти, занимаемый заявкой, вычисляется как значение случайной величины, закон и/или числовые характеристики распределения могут зависеть от типа заявки. Узлы выполняют связующие, управляющие и вспомогательные функции в имитационной модели, служат для выбора направлений движения заявок, изменения их параметров и приоритета, разделения заявок на части, их объединения и т.п.

62 ОСНОВЫ ИМИТАЦИОННОГО МОДЕЛИРОВАНИЯ СЛОЖНЫХ ДИНАМИЧЕСКИХ СИСТЕМ Событийный метод Сущность событийного метода заключается в отслеживании на модели последовательности событий в том же порядке, в каком они происходили бы в реальной системе. Вычисления выполняют только для тех моментов времени и тех частей (процедур) модели, к которым относятся совершаемые события. Поскольку изменения состояний в каждом такте обычно наблюдаются лишь у малой доли ОА, событийный метод может существенно ускорить моделирование по сравнению с пошаговым методом, в котором на каждом такте анализируются состояния всех элементов.

63 ОСНОВЫ ИМИТАЦИОННОГО МОДЕЛИРОВАНИЯ СЛОЖНЫХ ДИНАМИЧЕСКИХ СИСТЕМ Работа начинается с обращения к моделям источников входных потоков. Такое обращение позволяет рассчитать момент генерации первой заявки. Этот момент вместе со ссылкой на заявку заносится в список будущих событий (СБС), а сведения о генерируемой заявке - в список заявок (СЗ). Запись в СЗ включает в себя имя заявки, значения ее параметров (атрибутов), место, занимаемое в данный момент в имитационной модели. В СБС события упорядочиваются по увеличению моментов наступления. Потом из СБС выбирают совокупность сведений о событиях, относящихся к наиболее раннему моменту времени. Эта совокупность переносится в список текущих событий (СТС), из которого извлекаются ссылки на события. Обращение по ссылке к СЗ позволяет установить место в имитационной модели заявки 1, с которой связано моделируемое событие. Пусть этим местом является устройство X. Далее программа моделирования выполняет следующие действия:

64 ОСНОВЫ ИМИТАЦИОННОГО МОДЕЛИРОВАНИЯ СЛОЖНЫХ ДИНАМИЧЕСКИХ СИСТЕМ 1) изменяет параметры состояния устройства; например, если заявка 1 освобождает X, а очередь к Х не была пуста, то в соответствии с заданной дисциплиной обслуживания из очереди к Х выбирается заявка 2 и поступает на обслуживание в X; 2) прогнозируется время наступления следующего события, связанного с заявкой 2, путем обращения к модели устройства, в которой рассчитывается продолжительность обслуживания заявки 2; сведения об этом будущем событии заносятся в СБС и СЗ;

65 ОСНОВЫ ИМИТАЦИОННОГО МОДЕЛИРОВАНИЯ СЛОЖНЫХ ДИНАМИЧЕСКИХ СИСТЕМ 3) происходит имитация движения заявки в сетевой имитационной модели (СИМ) по маршруту, определяемому заданной программой моделирования, до тех пор, пока заявка не придет на вход некоторого ОА; здесь либо заявка задерживается в очереди, либо путем обращения к модели этого ОА прогнозируется наступление некоторого будущего события, связанного с дальнейшей судьбой заявки 1; сведения об этом будущем событии также заносятся в СБС и СЗ; 4) в файл статистики добавляются необходимые данные. После отработки всех событий, относящихся к моменту времени tk, происходит увеличение модельного времени до значения, соответствующего ближайшему будущему событию, и рассмотренный процесс имитации повторяется.

66 ОСНОВЫ ИМИТАЦИОННОГО МОДЕЛИРОВАНИЯ СЛОЖНЫХ ДИНАМИЧЕСКИХ СИСТЕМ Сети Петри – это аппарат для моделирования динамических дискретных систем. В настоящее время сети Петри применяются в основном в моделировании. Развитие теории сетей Петри проводилось по двум направлениям. Формальная теория сетей Петри занимается разработкой основных средств, методов и понятий, необходимых для применения сетей Петри. Прикладная теория сетей Петри связана главным образом с применением сетей Петри к моделированию систем, их анализу и получающимся в результате этого глубоким проникновением в моделируемые системы. Моделирование в сетях Петри осуществляется на событийном уровне. Определяются, какие действия происходят в системе, какие состояние предшествовали этим действиям и какие состояния примет система после выполнения действия. Выполнения событийной модели в сетях Петри описывает поведение системы. Анализируя результаты выполнения, можно сказать о том, в каких состояниях пребывала или не пребывала система, какие состояния в принципе не достижимы.

67 ОСНОВЫ ИМИТАЦИОННОГО МОДЕЛИРОВАНИЯ СЛОЖНЫХ ДИНАМИЧЕСКИХ СИСТЕМ Сеть Петри определяется как четверка <Р, Т, I, O>, где Р и Т - конечные множества позиций и переходов, I и O - множества входных и выходных функций. В сетях Петри вводятся объекты двух типов: динамические, которые изображаются метками (маркерами) внутри позиций, и статические, которые соответствуют вершинам сети Петри. Маркировка - распределение маркеров по позициям. Маркеры могут перемещаться в сети. Каждое изменение маркировки называют событием, причем каждое событие связано с определенным переходом. События происходят мгновенно и разновременно при выполнении некоторых условий. Каждому условию в сети Петри соответствует определенная позиция. Совершению события соответствует срабатывание перехода, при котором маркеры из входных позиций этого перехода перемещаются в выходные позиции. Последовательность событий образует моделируемый процесс.

68 ОСНОВЫ ИМИТАЦИОННОГО МОДЕЛИРОВАНИЯ СЛОЖНЫХ ДИНАМИЧЕСКИХ СИСТЕМ Правила срабатывания переходов конкретизируют следующим образом: переход срабатывает, если для каждой из его входных позиций выполняется условие Ni >= Ki, где Ni - число маркеров в i-й входной позиции, Ki - число дуг, идущих от i-й позиции к переходу; при срабатывании перехода число маркеров в i-й входной позиции уменьшается на Ki, а в j-й выходной позиции увеличивается на Мj где Мj - число дуг, связывающих переход с j-й позицией. На рисунке показан пример распределения маркеров по позициям. Для срабатывания перехода эту маркировку можно записать в виде (2, 1, 3, 1) или (2 1 3 1). После срабатывания перехода маркировка принимает вид (0,0,0,4).

69 ОСНОВЫ ИМИТАЦИОННОГО МОДЕЛИРОВАНИЯ СЛОЖНЫХ ДИНАМИЧЕСКИХ СИСТЕМ

70 ОСНОВЫ ИМИТАЦИОННОГО МОДЕЛИРОВАНИЯ СЛОЖНЫХ ДИНАМИЧЕСКИХ СИСТЕМ Возможно ввести ряд дополнительных правил и условий в алгоритмы моделирования, получая ту или иную разновидность сетей Петри. Так, прежде всего, полезно ввести модельное время, чтобы моделировать не только последовательность событий, но и их привязку ко времени. Это осуществляется приданием переходам веса - продолжительности (задержки) срабатывания, которую можно определять, используя задаваемый при этом алгоритм. Полученную модель называют временной сетью Петри. Если задержки являются случайными величинами, то сеть называют стохастической. В стохастических сетях возможно введение вероятностей срабатывания возбужденных переходов.

71 ОСНОВЫ ИМИТАЦИОННОГО МОДЕЛИРОВАНИЯ СЛОЖНЫХ ДИНАМИЧЕСКИХ СИСТЕМ Так, на рисунке представлен фрагмент сети Петри, иллюстрирующий конфликтную ситуацию: маркер в позиции р2 может запустить либо переход t1, либо переход t2. В стохастической сети предусматривается вероятностный выбор срабатывающего перехода в таких ситуациях.

72 ОСНОВЫ ИМИТАЦИОННОГО МОДЕЛИРОВАНИЯ СЛОЖНЫХ ДИНАМИЧЕСКИХ СИСТЕМ Сеть называют функциональной, если задержки определяются как функции некоторых аргументов, которыми могут быть количество маркеров в каких-либо позициях, состояния некоторых переходов и т.п. Во многих задачах динамические объекты могут быть нескольких типов, и для каждого типа нужно вводить свои алгоритмы поведения в сети. В этом случае каждый маркер должен иметь хотя бы один параметр, обозначающий тип маркера. Такой параметр обычно называют цветом; цвет можно использовать как аргумент в функциональных сетях. Сеть Петри при этом называют цветной. Среди других разновидностей сетей Петри следует упомянуть ингибиторные сети, характеризующиеся тем, что в них возможны (ингибиторные) дуги. Наличие маркера во входной позиции связанно с переходом ингибиторной дугой, означает запрещение срабатывания перехода.

73 ОСНОВЫ ИМИТАЦИОННОГО МОДЕЛИРОВАНИЯ СЛОЖНЫХ ДИНАМИЧЕСКИХ СИСТЕМ Анализ сетей Петри При имитационном моделировании сложных систем на базе сетей Петри задают входные потоки заявок и определяют соответствующую реакцию системы. Выходные параметры рассчитывают путем обработки накопленного при моделировании статистического материала. Возможен и другой подход к использованию сетей Петри для анализа сложных систем. Он не связан с имитацией процессов и основан на исследовании таких свойств сетей Петри, как ограниченность, безопасность, сохраняемость, достижимость, живость.

74 ОСНОВЫ ИМИТАЦИОННОГО МОДЕЛИРОВАНИЯ СЛОЖНЫХ ДИНАМИЧЕСКИХ СИСТЕМ Ограниченность (или К-ограниченность) имеет место, если число меток в любой позиции сети не может превысить значения К. При проектировании автоматизированных систем определение К позволяет обоснованно выбирать емкости накопителей. Возможность неограниченного роста числа меток свидетельствует об опасности неограниченного роста длин очередей. Безопасность - частный случай ограниченности, а именно это l-ограниченность. Если для некоторой позиции установлено, что она безопасна, то ее можно представлять одним триггером. Сохраняемость характеризуется постоянством загрузки ресурсов, т.е. Ai Ni = const, где Ni - число маркеров в i-й позиции; Ai - весовой коэффициент.

75 ОСНОВЫ ИМИТАЦИОННОГО МОДЕЛИРОВАНИЯ СЛОЖНЫХ ДИНАМИЧЕСКИХ СИСТЕМ Достижимость Mk->Mj характеризуется возможностью достижения маркировки Mj из состояния сети, характеризуемого маркировкой Mk. Живость сети Петри определяется возможностью срабатывания любого перехода при функционировании моделируемого объекта. Отсутствие живости либо означает избыточность аппаратуры в проектируемой системе, либо свидетельствует о возможности возникновения зацикливаний, тупиков, блокировок. В основе исследования перечисленных свойств сетей Петри лежит анализ достижимости.

76 ОСНОВЫ ИМИТАЦИОННОГО МОДЕЛИРОВАНИЯ СЛОЖНЫХ ДИНАМИЧЕСКИХ СИСТЕМ Один из методов анализа достижимости любой маркировки из состояния М0 - построение графа достижимости. Начальная вершина графа отображает М0, а остальные вершины соответствуют другим маркировкам. Дуга из Mi в Мj означает событие Мi -> Мj и соответствует срабатыванию перехода t. В сложных сетях граф может содержать чрезмерно большое число вершин и дуг. Однако при построении графа можно не отображать все вершины, так как многие из них являются дублями (действительно, от маркировки Mk всегда порождается один и тот же подграф независимо от того, из какого состояния система пришла в Mk). Тупики обнаруживаются по отсутствию разрешенных переходов из какой-либо вершины, т.е. по наличию листьев — терминальных вершин. Неограниченный рост числа маркеров в какой-либо позиции свидетельствует о нарушениях ограниченности.

77 ОСНОВЫ ИМИТАЦИОННОГО МОДЕЛИРОВАНИЯ СЛОЖНЫХ ДИНАМИЧЕСКИХ СИСТЕМ Приведем пример анализа достижимости, На рис. а показана сеть Петри, а на рис. б - соответствующий ей граф достижимых разметок. Вершины графа на рис. б соответствуют маркировкам (состояниям сети Петри), представленным в виде последовательности цифр, цифры означают количества меток в позициях, перечисляемых в порядке р1, р2, p3 р4, р5. Дуги помечены обозначениями срабатывающих переходов. Живость сети очевидна, так как срабатывают все переходы, тупики отсутствуют.

78 ОСНОВЫ ИМИТАЦИОННОГО МОДЕЛИРОВАНИЯ СЛОЖНЫХ ДИНАМИЧЕСКИХ СИСТЕМ

79 ОСНОВЫ СASE-ТЕХНОЛОГИЙ Эволюция CASE-средств CASE-технологии развивались с целью преодоления ограничений ручных применений, методологий структурного анализа и проектирования. CASE-технологии не являются самостоятельными методологиями и используются для более эффективного их применения. Выделяют 2 генерации CASE-средств: CASE-средства анализа требований, проектирования спецификаций и структуры, редактирования интерфейсов (первая генерация CASE-I); CASE-средства генерации исходных текстов и реализации интегрированного окружения поддержки полного жизненного цикла (ЖЦ) разработки программного обеспечения (ПО) (вторая генерация CASE-II).

ОСНОВЫ СASE-ТЕХНОЛОГИЙ CASE-средства анализа требований, проектирования спецификаций и структуры, редактирования интерфейсов Эволюция CASE-средств CASE-средства генерации исходных текстов и реализации интегрированного окружения поддержки полного жизненного цикла (ЖЦ) разработки программного обеспечения (ПО) 80

81 ОСНОВЫ СASE-ТЕХНОЛОГИЙ CASE-I. Применялись в основном системными аналитиками и проектировщиками. Эта технология включала в себя средства поддержки графических моделей, проектирования спецификаций, экранных редакторов и словарей данных. Т.е. не была предназначена для поддержки полного жизненного цикла и концентрировала внимание на начальных шагах проекта – системном анализе определений и требований, системном проектировании и логическом проектировании БД. CASE-II. Имеет более развитые возможности. Использует средства автоматической кодогенерации, обеспечивает полную функциональную поддержку графических системных требований и спецификаций проектирования; контроля, анализа и связывания системной информации, а также информации по управлению проектированием; построение прототипов и моделей системы; тестирование верификации и анализа сгенерированных программ; генерации документов по проекту; контроль на соответствие стандартов по всем этапам жизненного цикла.

82 ОСНОВЫ СASE-ТЕХНОЛОГИЙ CASE–модель жизненного цикла программного обеспечения CASE-технологии предлагают новый автоматизированный подход к построению жизненного цикла программного обеспечения. В CASE изменяются все фазы жизненного цикла программного обеспечения. Наибольшие изменения касаются фаз анализа и проектирования. В табл. 1 представлены результаты сравнения традиционной разработки программных проектов и разработки с применением CASE-технологий.

Модель жизненного цикла программного обеспечения 83

Case - модель жизненного цикла программного обеспечения Системное тестирование Автоматическая кодогенерация Контроль проекта Проектирование спецификаций Прототипирование Сопровождение 84 ЭТАПЫ

85 ОСНОВЫ СASE-ТЕХНОЛОГИЙ Фаза прототипирования заменяет традиционную фазу системного анализа. Наиболее автоматизированными фазами являются фазы контроля проекта и кодогенерации. Из приведенного сравнения можно сделать вывод, что благодаря применению CASE-модели ЖЦ ПО, большее количество временных затрат отводится на важные этапы анализа и проектирования. Это становится возможным за счет замены рутинной ручной генерации кодов автоматической кодогенерацией, что впоследствии приводит к сокращению временных затрат на тестирование, т.к. количество ошибок при автоматической кодогенерации резко сокращается.

86 ОСНОВЫ СASE-ТЕХНОЛОГИЙ Состав, структура и особенности CASE-средств Фактически CASE-средства представляют собой новый тип графически ориентированных инструментов. Обычно к ним относят любое программное средство, обеспечивающее автоматическую помощь при разработке программного обеспечения, его сопровождений или деятельности по управлению проектами. Такое средство должно иметь следующие черты: 1. Развитые графические возможности для документирования и описания систем программного обеспечения, а также для улучшения интерфейса с пользователем. 2. Интеграция, обеспечивающая легкую передачу данных и позволяющая управлять всем процессом проектирования и разработки программного обеспечения непосредственно через процесс планирования. 3. Использование репозитария (компьютерного хранилища).

87 ОСНОВЫ СASE-ТЕХНОЛОГИЙ Помимо перечисленных основополагающих принципов графической ориентации интеграции и локализации всей проектной информации в репозитарии, в основе концептуального построения CASE лежат следующие положения: Человеческий фактор (легкость, удобность и экономичность проектирования). Широкое использование базовых программных средств (БД, СУБД, компиляторы с различных языков программирования, отладчики документации, оболочки экспертных систем, базы знаний). Автоматизированная и автоматическая кодогенерация. Доступность для разных категорий пользователей. Рентабельность. Сопровождаемость, обеспечивающая способность адаптации при изменении требований и целей проекта.

88 ОСНОВЫ СASE-ТЕХНОЛОГИЙ Интегрированный CASE-пакет содержит 4 основные компоненты: 1. Средство централизованного хранения всей информации о проектируемом программном обеспечении в течение всего жизненного цикла (репозитарий). Репозитарий должен обеспечивать: инкрементный режим при вводе описания объектов; распространение действия нового или скорректированного описания на информационное пространство всего проекта; синхронизацию поступления информации от различных пользователей; хранение версий проектов и его отдельных компонент; сборку любой запрошенной версии; контроль информации на корректность, полноту и состоятельность;

89 ОСНОВЫ СASE-ТЕХНОЛОГИЙ 2. Средства ввода данных в репозитарий, которые также предназначены для организации взаимодействия с CASE-пакетами. 3. Средства анализа проектирования и разработки, предназначенные для обеспечения планирования и анализа различных описаний. 4. Средства вывода. Служат для документирования, управления пакетом и кодовой генерации. Все перечисленные компоненты в совокупности должны: - поддерживать графические модели; - контролировать ошибки; - организовывать и поддерживать репозитарий; - поддерживать процесс проектирования и разработки.

Основные компоненты интегрированного CASE- пакета 90

91 ОСНОВЫ СASE-ТЕХНОЛОГИЙ Графические модели CASE-программы являются схематическими проектами и формами, что упрощает восприятие. Для представления программ применяются структурные диаграммы различных типов. Для CASE существует 4 типа диаграмм: Диаграммы функционального проектирования (DFD) – диаграммы потоков данных. Диаграммы моделирования данных (ERD) – диаграммы «сущность-связь». Диаграммы моделирования поведения (STD) – диаграммы переходов состояний. Структурные диаграммы (карты).

92 ОСНОВЫ СASE-ТЕХНОЛОГИЙ Все диаграммы описывают отношения между модулями и внутримодульную структуру. Создание и модификация данных диаграмм осуществляется с помощью специальных графических редакторов (диаграммеров), которые обеспечивают: создание иерархических связанных диаграмм, в которых комбинируются графические и текстовые объекты; создание и редактирование объектов в любом месте диаграммы; создание, перемещение и выравнивание группы объектов, изменение их размеров, масштабирование; сохранение связей между объектами при их перемещении и изменении размеров; автоматический контроль ошибок. Полученные диаграммы дают ясное понимание и решение проблемы. Позволяют проанализировать функционирование связи между разработчиками, обеспечивают стандартизацию представления данных.

93 ОСНОВЫ СASE-ТЕХНОЛОГИЙ Организация репозитария Основные функции: хранение, доступ, обновление, анализ и визуализация всей информации. Содержимое репозитария включает в себя: 1) описание объекта; 2) отношение с другими объектами; 3) контроль информации; 4) правила обработки. Каждый информационный объект в репозитарии описывается перечислением его свойств: идентификаторы, имена-синонимы, тип, текстовое описание, хранилище, компоненты, область значений. Кроме этого, хранятся все перекрестные ссылки, правила формирования и редактирования объектов, а также контроля информации о времени его последнего обновления, номер версии и т.д.

94 ОСНОВЫ СASE-ТЕХНОЛОГИЙ На основе репозитария осуществляется интеграция CASE-средств и разделение системной информации между разработчиками. Уровни интеграции: общий пользовательский интерфейс, передача данных между средствами, единая система для интеграции этапов разработки, передача данных между аппаратными платформами. Репозитарий является базой для стандартизации и автоматически строит следующие основные отчеты: 1) отчеты по содержимому; 2) отчеты по перекрестным ссылкам; 3) отчеты по результатам анализа; 4) отчеты по декомпозиции объектов. Важные функции управления и контроля проекта также реализуются на основе репозитария. В частности через репозитарий может осуществляться контроль безопасности (ограничения доступа, привилегии доступа, контроль версий, контроль изменений и др).

95 ОСНОВЫ СASE-ТЕХНОЛОГИЙ Activity Report [А0] Банк Inputs: Платежные документы Outputs: Передвижение наличных средств Controls: Законы, Сроки, Расчет баланса, Срок отправки наличных Mechanisms: Терминалы БД, Вычислительная техника, Машины, Операторы, Управленческий персонал, Экспедиторы Sub-Activities: [А1] Операционные залы [А2] Управление банком [A3] Центральный офис [А1] Операционные залы Inputs: Платежные документы Outputs: Принятые платежные документы

96 ОСНОВЫ СASE-ТЕХНОЛОГИЙ Controls: Законы, Расчет баланса Mechanisms: Операторы, Терминалы БД [А2] Управление банком Inputs: Принятые платежные документы Outputs: Оформление финансовых операций Controls: Законы, Расчет баланса, Сроки Mechanisms: Управленческий персонал, Вычислительная техника [A3] Центральный офис Inputs: Оформление финансовых операций Outputs: Передвижение наличных средств Controls: Срок отправки Mechanisms: Экспедиторы, Автомашины

97 ОСНОВЫ СASE-ТЕХНОЛОГИЙ Контроль ошибок CASE обеспечивает автоматическую верификацию и контроль проекта на полноту и состоятельность на ранних этапах жизненного цикла. Типы контроля Контроль синтаксиса диаграммы и типов ее элементов: по синтаксису: любой функциональный элемент диаграммы должен иметь, по крайней мере, 1 входной и 1 выходной поток данных; 2 элемента данных не могут быть непосредственно связанными; по типам: функциональный элемент должен всегда использоваться для представления процедурной компоненты, поток данных всегда должен быть представлен компонентой данных.

98 ОСНОВЫ СASE-ТЕХНОЛОГИЙ Контроль полноты состоятельности диаграмм. Все элементы должны быть идентифицированы и представлены в репозитарии. Контроль декомпозиции функции. Включает оценку качества на основе различных метрик программного обеспечения. Сквозной контроль диаграмм одного или различных типов на предмет их состоятельности по уровням – это вертикальное и горизонтальное балансирование диаграмм. При вертикальном балансировании (диаграмма одного типа) выявляются несбалансированные потоки данных между детализируемой и детализирующей диаграммами. Горизонтальная диаграмма определяет некорректность между словарями различных типов диаграмм.

99 ОСНОВЫ СASE-ТЕХНОЛОГИЙ Поддержка процесса проектирования и разработки Для поддержки процесса проектирования и разработки используются следующие возможности CASE-пакетов: покрытие жизненного цикла, поддержка прототипирования, поддержка структурных методологий, автоматическая кодогенерация. При покрытии жизненного цикла наибольшее внимание уделяется анализу требований и проектированию спецификаций, последние являются основой всего проекта. Важную роль на ранних этапах жизненного цикла играют возможности поддержки прототипирования. Такие средства, как генераторы меню, экранов и отчетов позволяют быстро построить прототипы пользовательских интерфейсов и снабдить модели функционирования системы с позиции конечного пользователя.

100 ОСНОВЫ СASE-ТЕХНОЛОГИЙ Поддержка структурных методологий осуществляется за счет их автоматизации на следующих двух уровнях: Подготовка документации, графическая поддержка построения структурных диаграмм, продуцирование спецификаций для детализации функциональных блоков. Корректное использование шагов обработки и методов. Кодогенерация осуществляется на основе репозитария и позволяет автоматически построить 80-90% объектных кодов. Автоматическая кодогенерация производится в основном с помощью целевых языков (С, ADA) либо на основе модели, полученной из проектных спецификаций.

101 КЛАССИФИКАЦИЯ CASE-СРЕДСТВ Все CASE-средства делятся на типы, категории и уровни. Классификация по типам отражает функциональную ориентацию CASE-средств в технологическом процессе. 1. АНАЛИЗ И ПРОЕКТИРОВАНИЕ. Средства данной группы используются для создания спецификаций системы и ее проектирования; они поддерживают широко известные методологии проектирования. Их целью является определение системных требований и свойств, которыми система должна обладать, а также создание проекта системы, удовлетворяющей этим требованиям и обладающей соответствующими свойствами. На выходе продуцируются спецификации компонент системы и интерфейсов, связывающих эти компоненты, а также архитектура системы и детальная схема проекта, включающая алгоритмы определения структур данных. 2. ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ И ФАЙЛОВ. Средства данной группы обеспечивают логическое моделирование данных, автоматическое преобразование моделей данных, автоматическую генерацию схем БД и описаний форматов файлов на уровне программного кода.

102 КЛАССИФИКАЦИЯ CASE-СРЕДСТВ 3. ПРОГРАММИРОВАНИЕ. Средства этой группы поддерживают этапы программирования и тестирования, а также автоматическую кодогенерацию из спецификаций, получая полностью документированную выполняемую программу. Помимо диаграммеров различного назначения и средств поддержки работы с репозитарием, в эту группу средств включены и традиционные генераторы кодов, анализаторы кодов (как в статике, так и в динамике), генераторы наборов тестов, анализаторы покрытия тестами, отладчики. 4. СОПРОВОЖДЕНИЕ И РЕИНЖИНИРИНГ. К таким средствам относятся документаторы, анализаторы программ, средства реструктурирования и реинжениринга. Их целью является корректировка, изменение, анализ, преобразование и реинжиниринг существующей системы. Средства позволя­ют осуществлять поддержку всей системной документации, включая коды, спецификации, наборы тестов: контролировать покрытие тестами для оценки полноты тестируемости: управлять функционированием системы и т.п. Особый интерес представляют средства обеспечения мобильности и реинжиниринга.

103 КЛАССИФИКАЦИЯ CASE-СРЕДСТВ Средства реинжиниринга включают: статические анализаторы для продуцирования схем системы ПО из ее кодов; динамические анализаторы; документаторы, позволяющие автоматически получать обновленную документацию при изменении кода; редакторы кодов, автоматически изменяющие при редактировании и все предшествующие коду структуры; средства доступа к спецификациям, их модификации и генерации нового кода; средства реверсного инжиниринга, транслирующие коды в спецификации. 5. ОКРУЖЕНИЕ. Средства поддержки платформ для интеграции, создания и придания товарного вида CASE-средствам. 6. УПРАВЛЕНИЕ ПРОЕКТОМ. Средства, поддерживающие планирование, контроль, руководство, взаимодействие, т.е. функции, необходимые в процессе разработки и сопровождения проектов.

104 КЛАССИФИКАЦИЯ CASE-СРЕДСТВ Классификация по категориям определяет уровень интегрированности по выполняемым функциям и включает вспомогательные программы (tools), пакеты разработчика (toolkit) и инструментальные средства (workbench). Верхние (Upper) CASE часто называют средствами компьютерного планирования. Они призваны повышать эффективность деятельности руководителей фирмы и проекта путем сокращения затрат на определение политики фирмы и на создание общего плана проекта. Средние (Middle) CASE считаются средствами поддержки этапов анализа требований и проектирования спецификаций и структуры ПО. Их использование существенно сокращает цикл разработки проекта; при этом важную роль играет возможность накопления и хранения знаний, обычно имеющихся только в голове разработчика-аналитика, что позволит использовать накопленные решения при создании других проектов. Кроме того, средние CASE обеспечивают возможности быстрого документирования требований и быстрого прототипирования. Нижние (Lower) CASE являются средствами разработки ПО (при этом может использоваться до 30% спецификаций, созданных средствами среднего CASЕ). Главными преимуществами нижних CASE являются: значительное уменьшение времени на разработку, облегчение модификаций, поддержка возможностей прототипирования (совместно со средними CASE).

105 ОСНОВЫ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ (ИС) Основы методологии и технологии Основу проекта любой ИС составляют методологии, технологии и инструментальные средства проектирования (CASE-средства). Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают выполнение процессов ЖЦ. Технология проектирования - совокупность трех составляющих: пошаговая процедура - последовательность технологических операций проектирования; критерии и правила, используемые для оценки результатов выполнения технологических операций; нотации (графических и текстовых средств), используемые для описания проектируемой системы. Технологические инструкции, составляющие основное содержание технологии, состоят из описания последовательности технологических операций, условий, в зависимости от которых выполняется та или иная операция, и описаний самих операций. Применение любой технологии проектирования, разработки и сопровождения ИС невозможно без выработки ряда стандартов, которые должны соблюдаться всеми участниками проекта. К таким стандартам относятся:

106 106 Обязательные элементы имитационных моделей методологии технологии CASE-средства Основа проекта

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

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

109 ОСНОВЫ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ (ИС) Стандарт проектирования должен устанавливать: набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации; правила фиксации проектных решений на диаграммах, в том числе: правила именования объектов, набор атрибутов для всех объектов и правила их заполнения на каждой стадии, правила оформления диаграмм и т. д.; требования к конфигурации рабочих мест разработчиков, включая настройки операционной системы, настройки CASE-средств, общие настройки проекта и т. д.; механизм обеспечения совместной работы над проектом, в том числе: правила интеграции подсистем проекта, правила поддержания проекта в одинаковом для всех разработчиков состоянии (регламент обмена проектной информацией, механизм фиксации общих объектов и т.д.), правила проверки проектных решений на непротиворечивость и т. д.

110 ОСНОВЫ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ (ИС) Стандарт оформления проектной документации должен устанавливать: комплектность, состав и структуру документации на каждой стадии проектирования; требования к ее оформлению (включая требования к содержанию разделов, подразделов, пунктов, таблиц и т.д.), правила подготовки, рассмотрения, согласования и утверждения документации с указанием предельных сроков для каждой стадии; требования к настройке издательской системы, используемой в качестве встроенного средства подготовки документации; требования к настройке CASE-средств для обеспечения подготовки документации в соответствии с установленными требованиями.

111 ОСНОВЫ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ (ИС) Стандарт интерфейса пользователя должен устанавливать: правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления; правила использования клавиатуры и мыши; правила оформления текстов помощи; перечень стандартных сообщений; правила обработки реакции пользователя.

112 ОСНОВЫ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ (ИС) RAD-методология разработки приложений Одним из подходов к разработке ПО является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий 3 компонента: небольшую команду программистов (от 2 до 10 человек); короткий, но тщательно проработанный производственный график (от 2 до 6 мес.); повторяющийся цикл, при котором разработчики запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком в процессе разработки. Жизненный цикл ПО по методологии RAD состоит из нескольких фаз:

113 ОСНОВЫ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ (ИС) На фазе анализа и планирования требований пользователи системы определяют функции, которые она должна выполнять, выделяют наиболее приоритетные из них, требующие проработки в первую очередь, описывают информационные потребности. Определение требований выполняется в основном силами пользователей под руководством специалистов. Ограничивается масштаб проекта, определяются временные рамки для каждой из последующих фаз. Кроме того, определяется сама возможность реализации данного проекта в установленных рамках финансирования, на данных аппаратных средствах и т.п. Результатом данной фазы должны быть список и приоритетность функций будущей ИС, предварительные функциональные и информационные модели ИС.

114 ОСНОВЫ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ (ИС) На фазе проектирования часть пользователей принимает участие в техническом проектировании системы. CASE-средства используются для быстрого получения работающих прототипов приложений. Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы. Анализируется и корректируется функциональная модель. Каждый процесс рассматривается детально. Определяются требования разграничения доступа к данным. На этой же фазе происходит определение набора необходимой документации.

115 ОСНОВЫ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ (ИС) На фазе построения выполняется непосредственно сама быстрая разработка приложения. На данной фазе производят итеративное построение реальной системы на основе полученных в предыдущей фазе моделей, а также требований нефункционального характера. Программный код частично формируется при помощи автоматических генераторов, получающих информацию непосредственно из репозитария CASE-средств. Конечные пользователи на этой фазе оценивают получаемые результаты и вносят коррективы, если в процессе разработки система перестает удовлетворять определенным ранее требованиям. Тестирование системы осуществляется непосредственно в процессе разработки. После окончания работ каждой отдельной команды разработчиков производится постепенная интеграция данной части системы с остальными, формируется полный программный код, выполняется тестирование совместной работы данной части приложения с остальными, а затем тестирование системы в целом. Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.

116 ОСНОВЫ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ (ИС) На фазе внедрения производится обучение пользователей, организационные изменения и параллельно с внедрением новой системы осуществляется работа с существующей системой (до полного внедрения новой). Так как фаза построения достаточно непродолжительна, планирование и подготовка к внедрению должны начинаться заранее, как правило, на этапе проектирования системы. Приведенная схема разработки ИС не является абсолютной. Возможны различные варианты, зависящие, например, от начальных условий, в которых ведется разработка.

117 ОСНОВЫ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ (ИС) Методология RAD неприменима для построения сложных расчетных программ, требующих написания большого объема уникального кода. Не подходят для разработки по методологии RAD приложения реального времени. Оценка размера приложений проводится на основе так называемых функциональных элементов (экраны, сообщения, отчеты, файлы и т.п.) Подобная метрика не зависит от языка программирования, на котором ведется разработка. Размер приложения, которое может быть выполнено по методологии RAD, для хорошо отлаженной среды разработки ИС с максимальным повторным использованием программных компонентов, определяется при помощи следующей таблицы:

118 ОСНОВЫ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ (ИС)

119 ОСНОВЫ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ (ИС) В качестве итога перечислим основные принципы методологии RAD: разработка приложений итерациями; необязательность полного завершения работ на каждом из этапов жизненного цикла; обязательное вовлечение пользователей в процесс разработки ИС; необходимое применение CASE-средств, обеспечивающих целостность проекта; применение средств управления конфигурацией, облегчающих внесение изменений в проект и сопровождение готовой системы; необходимое использование генераторов кода; использование прототипирования, позволяющее полнее выяснить и удовлетворить потребности конечного пользователя; тестирование и развитие проекта, осуществляемые одновременно с разработкой; ведение разработки немногочисленной хорошо управляемой командой профессионалов; грамотное руководство разработкой системы, четкое планирование и контроль выполнения работ.

120 СТРУКТУРНЫЙ ПОДХОД ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ (ИС) Основные принципы структурного подхода При разработке с помощью структурного подхода ИС разбивается на автоматизируемые функции, т.е. на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы "снизу-вверх" от отдельных задач ко всей системе целостность теряется, возникают проблемы при информационной стыковке отдельных компонентов.

121 СТРУКТУРНЫЙ ПОДХОД ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ (ИС) Распространенные методологии структурного подхода базируются на ряде общих принципов. В качестве двух базовых принципов используются: принцип "разделяй и властвуй" - принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения; принцип иерархического упорядочивания - принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.

122 СТРУКТУРНЫЙ ПОДХОД ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ (ИС) Остальные принципы не являются второстепенными, поскольку игнорирование любого из них может привести к провалу всего проекта. Основными из этих принципов являются следующие: принцип абстрагирования - заключается в выделении существенных аспектов системы и отвлечении от несущественных; принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы; принцип непротиворечивости - заключается в обоснованности и согласованности элементов; принцип структурирования данных - заключается в том, что данные должны быть структурированы и иерархически организованы .

123 СТРУКТУРНЫЙ ПОДХОД ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ (ИС) В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой, и отношения между данными. Каждой группе средств соответствуют определенные виды диаграмм, наиболее распространенными среди которых являются следующие: SADT (Structured Analysis and Design Technique) - модели и соответствующие функциональные диаграммы; DFD (Data Flow Diagrams) - диаграммы потоков данных; ERD (Entity-Relationship Diagrams) - диаграммы "сущность-связь". На стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм. Перечисленные модели в совокупности дают полное описание ИС независимо от того, является ли она существующей или вновь разрабатываемой. Состав диаграмм в каждом конкретном случае зависит от необходимой полноты описания системы.

124 СТРУКТУРНЫЙ ПОДХОД ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ (ИС)

125 СТРУКТУРНЫЙ ПОДХОД ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ (ИС)

126 СТРУКТУРНЫЙ ПОДХОД ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ (ИС)

127 СТРУКТУРНЫЙ ПОДХОД ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ (ИС)

128 СТРУКТУРНЫЙ ПОДХОД ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ (ИС)

129 СТРУКТУРНЫЙ ПОДХОД ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ (ИС)

130 СТРУКТУРНЫЙ ПОДХОД ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ (ИС) Методология SADT Методология SADT разработана Дугласом Россом. На ее основе разработана, в частности, известная методология IDEF0 (Icam DEFinition), которая является основной частью программы ICAM (Интеграция компьютерных и промышленных технологий), проводимой по инициативе ВВС США. Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Основные элементы этой методологии основываются на следующих концепциях: графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описывается посредством интерфейсных дуг, выражающих "ограничения", которые в свою очередь определяют, когда и каким образом функции выполняются и управляются;

131 СТРУКТУРНЫЙ ПОДХОД ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ (ИС) строгость и точность. Выполнение правил SADT требует достаточной строгости и точности, не накладывая в то же время чрезмерных ограничений на действия аналитика. Правила SADT включают: ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков); связность диаграмм (номера блоков); уникальность меток и наименований (отсутствие повторяющихся имен); синтаксические правила для графики (блоков и дуг); разделение входов и управлений (правило определения роли данных); отделение организации от функции, т.е. исключение влияния организационной структуры на функциональную модель. Методология SADT может использоваться для моделирования широкого круга систем и определения требований и функций, а затем для разработки системы, которая удовлетворяет этим требованиям и реализует эти функции. Для уже существующих систем SADT может быть использована для анализа функций, выполняемых системой, а также для указания механизмов, посредством которых они осуществляются.

132 СТРУКТУРНЫЙ ПОДХОД ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ (ИС) Иерархия диаграмм Создание SADT-модели начинается с представления всей системы в виде простейшей (обобщенной) компоненты - одного блока и дуг, изображающих интерфейсы с функциями вне системы. Поскольку единственный блок представляет всю систему как единое целое, имя, указанное в блоке, является общим. Это верно и для интерфейсных дуг - они также представляют полный набор внешних интерфейсов системы в целом. Затем блок, который представляет систему в качестве единого модуля, детализируется на другой диаграмме с помощью нескольких блоков, соединенных интерфейсными дугами. Эти блоки представляют основные подфункции исходной функции. Данная декомпозиция выявляет полный набор подфункций, каждая из которых представлена как блок, границы которого определены интерфейсными дугами. Каждая из этих подфункций может быть декомпозирована подобным образом для более детального представления. Любая подфункция может содержать только те элементы, которые входят в исходную функцию. Кроме того, модель не может опустить какие-либо элементы, т.е., как уже отмечалось, родительский блок и его интерфейсы обеспечивают контекст. К нему нельзя ничего добавить, и из него не может быть ничего удалено. Модель SADT - серия диаграмм с сопроводительной документацией, разбивающих сложный объект на составные части, которые представлены в виде блоков. Детали каждого из основных блоков показаны в виде блоков на других диаграммах. Каждая детальная диаграмма является декомпозицией блока из более общей диаграммы. На каждом шаге декомпозиции более общая диаграмма называется родительской для более детальной диаграммы [1]. Дуги, входящие в блок и выходящие из него на диаграмме верхнего уровня, являются теми же самыми, что и дуги, входящие в диаграмму нижнего уровня и выходящие из нее, потому что блок и диаграмма представляют одну и ту же часть системы (рис.16). На рис. 17 представлены различные варианты выполнения функций соединения дуг с блоками. Некоторые дуги присоединены к блокам диаграммы обоими концами, у других же один конец остается неприсоединенным. Неприсоединенные дуги соответствуют входам, управлениям и выходам родительского блока. Источник или получатель этих пограничных дуг может быть обнаружен только на родительской диаграмме. Неприсоединенные концы должны соответствовать дугам на исходной диаграмме. Все граничные дуги должны продолжаться на родительской диаграмме, чтобы она была полной и непротиворечивой. На SADT-диаграммах не указаны явно ни последовательность, ни время. Обратные связи, итерации, продолжающиеся процессы и перекрывающиеся (по времени) функции могут быть изображены с помощью дуг. Рис. 16. Декомпозиция диаграмм [1]

133 СТРУКТУРНЫЙ ПОДХОД ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ (ИС) Связи могут выступать в виде комментариев, замечаний, исправлений и т.д. (рис. 18). Как было отмечено, механизмы (дуги с нижней стороны) показывают средства, с помощью которых осуществляется выполнение функций. Механизм может быть человеком, компьютером или любым другим устройством, которое помогает выполнять данную функцию (рис. 19). Каждый блок на диаграмме имеет свой номер. Блок любой диаграммы может быть далее описан диаграммой нижнего уровня, которая, в свою очередь, может быть далее детализирована с помощью необходимого числа диаграмм. Таким образом, формируется иерархия диаграмм (рис. 20). Для того, чтобы указать положение любой диаграммы или блока в иерархии, используются номера диаграмм. Например, А21 является диаграммой, которая детализирует блок 1 на диаграмме А2. Аналогично, А2 детализирует блок 2 на диаграмме А0, которая является самой верхней диаграммой модели. На рис. 20 показано типичное дерево диаграмм. Рис. 17. Варианты выполнения функций соединения дуг с блоками Рис. 18. Пример обратной связи Рис. 19. Пример механизма Рис. 20. Иерархия диаграмм

134 СТРУКТУРНЫЙ ПОДХОД ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ (ИС) Построение модели анализируемой ИС Модель системы определяется как иерархия диаграмм потоков данных (ДПД или DFD), описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи пользователю. Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы ИС с внешними входами и выходами. Они детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока процессы станут элементарными и детализировать их далее невозможно. Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те в свою очередь преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям - потребителям информации. Таким образом, основными компонентами диаграмм потоков данных являются: внешние сущности; системы/подсистемы; процессы; накопители данных; потоки данных.

135 СТРУКТУРНЫЙ ПОДХОД ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ (ИС) Внешние сущности Внешняя сущность - материальный предмет или физическое лицо, представляющее собой источник или приемник информации (заказчики, персонал, поставщики, клиенты, склад). Определение некоторого объекта или системы в качестве внешней сущности указывает на то, что она находится за пределами границ анализируемой ИС. В процессе анализа некоторые внешние сущности могут быть перенесены внутрь диаграммы анализируемой ИС, если это необходимо, или, наоборот, часть процессов ИС может быть вынесена за пределы диаграммы и представлена как внешняя сущность. Внешняя сущность обозначается квадратом, расположенным как бы "над" диаграммой и бросающим на нее тень, для того, чтобы можно было выделить этот символ среди других обозначений: Системы и подсистемы При построении модели сложной ИС она может быть представлена в самом общем виде на так называемой контекстной диаграмме в виде одной системы, как единого целого, либо может быть декомпозирована на ряд подсистем. Подсистема (или система) на контекстной диаграмме изображается следующим образом Номер подсистемы необходим для ее идентификации. В поле имени вводится наименование подсистемы в виде предложения с подлежащим и соответствующими определениями и дополнениями.

136 СТРУКТУРНЫЙ ПОДХОД ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ (ИС) Процессы Процесс - преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом. Физически процесс может быть реализован различными способами: это может быть подразделение организации (отдел), выполняющее обработку входных документов и выпуск отчетов, программа, аппаратно реализованное логическое устройство и т.д. Процесс на диаграмме потоков данных изображается, как показано на рис. 28. Рис. 28. Процесс [1] Номер процесса необходим для его идентификации. В поле имени вводится наименование процесса в виде предложения с активным глаголом в неопределенной форме (вычислить, рассчитать, проверить, определить, создать, получить), за которым следуют существительные в винительном падеже, например: "Ввести сведения о клиентах"; "Выдать информацию о текущих расходах"; "Проверить кредитоспособность клиента". Использование таких глаголов, как "обработать", "модернизировать" или "отредактировать" означает, как правило, недостаточно глубокое понимание данного процесса и требует дальнейшего анализа [1,14]. Информация в поле физической реализации показывает, какое подразделение организации, программа или аппаратное устройство выполняет данный процесс.

137 СТРУКТУРНЫЙ ПОДХОД ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ (ИС) Накопители данных Накопитель данных - абстрактное устройство для хранения информации, которую можно в любой момент поместить в накопитель и через некоторое время извлечь, причем способы помещения и извлечения могут быть любыми. Накопитель данных может быть реализован физически в виде ящика в картотеке, таблицы в оперативной памяти, файла на магнитном носителе и т.д. Накопитель данных на диаграмме потоков данных изображается, как показано на рис. 29. Рис. 29. Накопитель данных [1] Накопитель данных идентифицируется буквой "D" и произвольным числом. Имя накопителя выбирается из соображения наибольшей информативности для проектировщика. Накопитель данных в общем случае является прообразом будущей базы данных и увязывается с информационной моделью.

138 ПОДХОДЫ РЕОРГАНИЗАЦИИ ДЕЯТЕЛЬНОСТИ ПРЕДПРИЯТИЯ Методика BSP (Business System Planning) Методика BSP - подход, помогающий предприятию определить план создания информационных систем, удовлетворяющих его ближайшие и перспективные информационные потребности. Информация является одним из основных ресурсов и должна планироваться в масштабах всего предприятия. Информационная система проектируется независимо от текущего состояния и структуры предприятия. BSP основывается на нисходящем анализе информационных объектов и регламентирует 13 этапов выполнения работ. В начале выделяются три организационных этапа, обеспечивающих запуск проекта. Основой этих трех этапов является подготовка к анализу. На четвертом этапе формируется перечень основной деятельности предприятия и содержащихся в них бизнес-процессов. Пятый этап выделяет основные логически связанные классы данных. Таким образом, в итоге формируется матрица связи, где по вертикали приведены деятельности, реально необходимые для связей бизнес-процессов, а по горизонтали - необходимые классы данных. На пересечении строк и столбцов указывается тип доступа к классам данных. Шестой этап - анализ существующих на предприятии деловых и системных взаимодействий. По аналогии с пятым строятся следующие матрицы, демонстрирующие использование существующих и планируемых информационных подсистем: Матрица руководители - процесс. Основные обязанности руководителей и степень их вовлеченности в основные бизнес-процессы. Матрица информационные системы – руководители. Показывает, какими системами, существующими или планируемыми, пользуются руководителями. Информационные системы - процессы. Создается отношение между системами и бизнес-процессами. Информационные системы – файлы данных. Соотношение между системами и файлами данных. На седьмом этапе с использованием построенных матриц в беседе с руководителями решаются следующие задачи: уточнение матрицы; определение и оценка необходимой руководству информации; определение приоритетов потребностей; определение текущих задач; привлечение на свою сторону руководства. Восьмой этап обрабатывает результаты седьмого этапа, где каждая выявленная проблема фиксируется с указанием ее возможного решения. Далее все проблемы разделяются на 3 вида: проблемы, не относящиеся к автоматизации и не затрагивающие информационные системы; проблемы, связанные с существующими информационными системами; проблемы, связанные с будущими системами. Информация о проблемах первого вида передается руководству предприятия для принятия решений. Оставшиеся проблемы сортируются по бизнес-процессам. На девятом этапе традиционными методами осуществляются проектирование архитектуры информационной системы. Десятый этап определяет приоритеты в реализации и намечает последовательность ее этапов. Этап одиннадцатый определяет планирование модификаций информационной системы в связи с построенным процессом появления новых требований к такой системе. Этапы двенадцатый и тринадцатый - выработка рекомендаций и планов формирования отчетности по проведенным работам. В дальнейшем осуществляются изменения, направленные на подготовку предприятия к использованию спроектированной информационной системы.

139 ОПРЕДЕЛЕНИЕ НЕОБХОДИМОСТИ ВНЕДРЕНИЯ CASE-СРЕДСТВ Анализ существующих CASE-средств Потребности организации в CASE-средствах должны сравниваться с реальной ситуацией на рынке или собственными возможностями разработки. При проведении анализа рыночной ситуации необходимо выяснить возможность интеграции конкретного CASE-средства с другими средствами, используемыми организацией. Кроме того, важно получить достоверную информацию о средствах, основанную на реальном пользовательском опыте и сведениях от пользовательских групп. Критерии успешного внедрения Определяемые критерии должны позволять количественно оценивать степень удовлетворения каждой из потребностей, связанных с внедрением. По каждому критерию должно быть определено его конкретное оптимальное значение. На определенных этапах внедрения эти критерии должны анализироваться для того, чтобы определить текущую степень удовлетворения потребностей. Помимо продуктивности и качества, полезную информацию о состоянии внедрения CASE-средств также могут дать и другие характеристики организационных процессов: согласованность проектных результатов; точность стоимостных и плановых оценок; изменчивость внешних требований; соблюдение стандартов организации; степень повторного использования существующих компонентов ПО; объем и виды необходимого обучения; типы и моменты обнаружения проектных ошибок; вычислительные ресурсы, используемые CASE-средствами.

140 ОПРЕДЕЛЕНИЕ НЕОБХОДИМОСТИ ВНЕДРЕНИЯ CASE-СРЕДСТВ Реализация пилотного проекта Основные цели реализации Цель пилотного проекта - экспериментальная проверка правильности решений, принятых на предыдущих этапах, и подготовка к внедрению. Пилотный проект - первоначальное реальное использование CASE-средства в предназначенной для этого среде. Пилотный проект должен обладать многими из характеристик реальных проектов, для которых предназначено данное средство. Он имеет следующие цели: подтвердить достоверность результатов оценки и выбора; определить, действительно ли CASE-средство годится для использования в данной организации; собрать информацию, необходимую для разработки плана практического внедрения; приобрести собственный опыт использования CASE-средства. Пилотный проект необходим для оценки качества функционирования CASE-средства и его поддержки со стороны поставщика после того, как средство установлено. Основная функция пилотного проекта - принятие решения относительно приобретения или отказа от использования CASE-средства. Провал пилотного проекта позволяет избежать значительных и дорогостоящих неудач в дальнейшем, поскольку пилотный проект обычно связан с приобретением относительно небольшого количества лицензий и обучением узкого круга специалистов. Первоначальное использование новой CASE-технологии в пилотном проекте должно тщательно планироваться и контролироваться. Пилотный проект включает следующие шаги (рис. 44).

141 ОПРЕДЕЛЕНИЕ НЕОБХОДИМОСТИ ВНЕДРЕНИЯ CASE-СРЕДСТВ Внедрение выбранного на основе пилотного проекта CASE - средства Организационная деятельность по выполнению пилотного проекта и подготовке отчетов должна выполняться в установленном порядке. Специального внимания требуют вопросы приобретения, поддержки, экспертизы и обновления версий. Приобретение, установка и интеграция Выбранное CASE-средство должно быть приобретено, интегрировано в проектную среду и настроено в соответствии с требованиями пилотного проекта. Процесс приобретения может включать подготовку контракта, переговоры, лицензирование и другую деятельность, которая выходит за рамки данных рекомендаций. Эта деятельность требует затрат времени и человеческих ресурсов, которые должны быть учтены при планировании. План должен предусматривать возможность отказа от выбранного средства на данном этапе из-за договорных разногласий. Когда процесс приобретения завершен, средство должно быть установлено, оттестировано и принято в эксплуатацию. Тестирование должно показать, что поставленный продукт соответствует требованиям контракта, обладает необходимой полнотой и корректностью. Этап приемки может быть предусмотрен контрактом, его реальный срок может отличаться от того, который был предусмотрен первоначально в плане пилотного проекта. Особое внимание необходимо уделить соблюдению всех требований поставщика к параметрам среды функционирования CASE-средства. После завершения приемки может потребоваться настройка и интеграция. Настройка может включать модификацию интерфейсов, связанную с требованиями специалистов проектной группы, а также установкой прав доступа и привилегий. Настройка должна оставаться в рамках тех возможностей, которые предоставляет само средство. Если новое средство должно использоваться в совокупности с некоторыми другими средствами, необходимо определить взаимодействие средств и требуемую интеграцию. Для интеграции новых средств с существующими может потребоваться построение специальных оболочек. Сложная интеграция может потребовать привлечения сторонних экспертов. Поддержка Поддержка должна включать: контакты с опытными пользователями в других организациях и участие в работе групп пользователей. Внутренняя поддержка должна осуществляться специалистами, знакомыми с установкой средств и работой с ними. Такой тип поддержки должен специальным образом планироваться. Особое внимание должно быть уделено средствам, работающим в сетях или обладающих репозитариями, поддерживающими многопользовательскую работу [19]. Периодические экспертизы Обычные процедуры экспертизы проектов, существующие в организации, должны выполняться и для пилотного проекта, при этом особое внимание должно уделяться именно пилотным аспектам проекта. Помимо этого, результаты экспертиз должны служить мерой успешного использования CASE-средств. Обновление версий Пользователи CASE-средства могут ожидать периодического обновления версий со стороны поставщика в течение выполнения пилотного проекта. При этом необходимо тщательное отношение к интеграции этих версий. Следует заранее оценить влияние этих обновлений на ход проекта. Новые версии могут как обеспечить новые возможности, так и породить новые проблемы. Например, новая версия может потребовать видоизмененного или дополнительного обучения, а также может оказать отрицательное воздействие на уже выполненную к этому моменту работу .

142 ОПРЕДЕЛЕНИЕ НЕОБХОДИМОСТИ ВНЕДРЕНИЯ CASE-СРЕДСТВ Анализ результатов внедрения CASE-средств Результаты внедрения пилотного проекта необходимо оценить и сопоставить с изначальными потребностями организации, критериями успешного внедрения CASE-средств, базовыми метриками и критериями успеха пилотного проекта. Такая оценка устанавливает возможные проблемы и важнейшие характеристики пилотного проекта, которые могут повлиять на пригодность CASE-средства для организации. Она должна также указать проекты или структурные подразделения внутри организации, для которых данное средство является подходящим, и дать информацию относительно совершенствования процесса внедрения в дальнейшем. По результатам оценки пилотного проекта определяется позиция по следующим трем вопросам: Целесообразно ли внедрять CASE-средство? Какие конкретные особенности пилотного проекта привели к его успеху (или неудаче)? Какие проекты или подразделения в организации могли бы получить выгоду от использования средств ? Принятие решения о целесообразности внедрения CASE-средств Организация должна сделать существенные инвестиции в CASE-средства. Если средства удовлетворили или даже превысили ожидания организации, то решение о внедрении может быть принято достаточно просто и быстро. Может оказаться, что в рамках пилотного проекта средства не оправдали тех ожиданий, которые на них возлагались. Анализ пилотного проекта может показать, что причиной неудачи явился более чем один фактор. Последующие попытки внедрения CASE-технологии должны четко выявить все причины неудачи. В экстремальных случаях тщательный анализ может показать, что в настоящий момент организация просто не готова к успешному внедрению сложных CASE-средств. В такой ситуации организация может попытаться решить свои проблемы другими средствами. Принятие решения о внедрении Возможным решением должно быть одно из следующих: Внедрить средство. В этом случае рекомендуемый масштаб внедрения должен быть определен в терминах структурных подразделений и предметной области. Выполнить дополнительный пилотный проект. Такой вариант должен рассматриваться только в том случае, если остались конкретные неразрешенные вопросы относительно внедрения CASE-средства в организации. Отказаться от средства. В этом случае причины отказа от конкретного средства должны быть определены в терминах потребностей организации или критериев, которые остались неудовлетворенными. Перед тем, как продолжить деятельность по внедрению CASE-средств, потребности организации должны быть пересмотрены на предмет своей обоснованности. Отказаться от использования CASE-средств. Пилотный проект может показать, что организация либо не готова к внедрению CASE-средств, либо автоматизация данного аспекта процесса создания и сопровождения ПО не дает никакого эффекта для организации. В этом случае причины отказа от CASE-средств должны быть также определены в терминах потребностей организации или критериев, которые остались неудовлетворенными. При этом необходимо понимать отличие этого варианта от предыдущего, связанного с недостатками конкретного средства. Результатом данного этапа является документ, в котором обсуждаются результаты пилотного проекта и детализируются решения по внедрению.

143 ЗАКЛЮЧЕНИЕ В представленном учебном пособии рассматриваются концептуальные основы организации информационного взаимодействия субъектов на этапах проектирования, производства, испытаний, эксплуатации, сервиса и т.д. Изучаются основы Cals- и Case-технологий. CALS-технологии обес­печивают единообразие описания и интерпретации данных неза­висимо от места и времени их получения в общей системе, имею­щей масштабы вплоть до глобальных: структура проектной, технологической и эксплуатационной документации, языки ее представления должны быть стандартизованными. Тогда становится реальной успешная работа над общим проектом разных коллективов, разделенных во времени и пространстве и применяющих разные системы CAЕ/CAD/CAM. CASE- технологии предлагают новый, основанный на автоматизации подход к концепции жизненного цикла программного обеспечения и служат инструментарием для поддержки и усиления методов структурного анализа и проектирования. При этом трудозатраты на кодирование и тестирование значительно уменьшаются. В учебном пособии представлены следующие ключевые разделы: информационная поддержка жизненного цикла изделий; электронный документ и электронный документооборот; управление данными об изделии (PDM-технологии); ИПИ-технологии в информационной поддержке систем управления (менеджмента) качеством; интегрированная логистическая поддержка (ИЛП); стандарт STEP; язык описания данных Express; основы Case-технологий; понятие структурного анализа, диаграммы потоков данных; спецификации управления, средства структурного проектирования; проведение обследования деятельности предприятия; концептуальные основы Case-технологий, классификация Case-средств; подходы к улучшению деятельности предприятия; методы оценки деятельности предприятия; ключевые моменты реорганизации; определение потребности в Case-средствах; выполнение пилотного проекта. Приводятся примеры, задаются упражнения для самостоятельной работы. В конце пособия даны контрольные вопросы для проведения рейтинга и экзамена.

144 SAP Product Lifecycle Management, SAP PLM Компания SAP является мировым лидером в области создания и внедрения систем управления бизнес-процессами. В разделе проблем управления жизненным циклом наукоемкой продукции компанией SAP предложено решение «Управление жизненным циклом продукта» (SAP Product Lifecycle Management, SAP PLM).

145 145 SAP Product Lifecycle Management, SAP PLM создание и выпуск инновационных продуктов оптимизация процессов и систем разработки повышение конкурентоспособности SAP PLM

146 SAP Product Lifecycle Management, SAP PLM Решение для управления жизненным циклом продукта SAP PLM предоставляет полноценную поддержку всех связанных с продуктом процессов, включая разработку концепции, производство и техническое обслуживание. SAP PLM позволяет: - создавать и выпускать инновационные продукты, удовлетворяющие или создающие рыночный спрос; - оптимизировать процессы и системы разработки для ускорения вывода продуктов на рынок, обеспечивая соответствие отраслевым, качественным и нормативным стандартам; - стать более конкурентоспособным и выгодно использовать рыночные возможности в своих целях.

Концепция SAP PLM Процессы Ресурсы Продукт 147

148 SAP Product Lifecycle Management, SAP PLM Концепция PLM предполагает, что создается единое информационное пространство (ЕИП), охватывающее и описывающее три краеугольные компоненты: Продукт - Процессы - Ресурсы и взаимосвязи между ними. Наличие такой объединенной модели обеспечивает возможность быстро и эффективно взаимодействовать всем этим трём компонентам, оптимизируя решение в соответствии с требованиями бизнеса. Работа всех проектантов, конструкторов, технологов с единой информационной моделью обеспечивает снижение издержек на многочисленные согласования, неизбежные при традиционной технологии работы, и исключает наличие дублирующих или взаимоисключающих версий документов.

149 SAP Product Lifecycle Management, SAP PLM На практике это позволяет сократить материальные и временные затраты на создание конечного продукта и запуск его в производство, минуя многочисленные отладочные варианты, воплощаемые в реальности, то есть получить проект продукта, готового буквально с первых экземпляров к отправке потребителю. Мировая практика уже имеет примеры в даже таких сложных отраслях, как, например, авиастроение, когда самый первый собранный самолет нового проекта после проверочных испытаний был передан в реальную эксплуатацию. Конечно, такие идеальные случаи все-таки редки, но количество испытательно-доводочных вариантов продукции в современной автомобильной, авиационной, станкостроительной промышленности сократилось кардинально, а сроки на создание новых продуктов буквально в разы. Существуют целые классы технических объектов, в которых опытные образцы просто невозможны (например, электростанция) и реальные эксперименты на оценку и доводку их функционирования до оптимального уровня несоизмеримо дороги.

150 SAP Product Lifecycle Management, SAP PLM Однако, PLM - не панацея, спасающая от ошибок при организации бизнес- процессов. Риск создать неудачный продукт при использовании PLM-технологий значительно снижается, но при одном важном условии. Это условие - компетентность специалистов, занятых созданием продукта. PLM не заменяет специалистов, а значительно увеличивает эффективность их труда. Соответственно, имея в руках столь мощный инструмент, некомпетентный конструктор способен внести ошибку, которая как снежный ком вызовет цепочку других ошибочных или неоптимальных решений. Поэтому внедрение PLM - это не только закупка соответствующего программного обеспечения, это еще и обязательная тщательная подготовка кадров, которые будут работать с ними.

151 SAP Product Lifecycle Management, SAP PLM SAP PLM является частью SAP Business Suite - это модульное решение, поддерживающее комплексные отраслевые процессы. Таким образом, компании могут одновременно оптимизировать и реализовывать бизнес и ИТ-стратегии, что предоставляет организациям уникальную возможность работать в единой интегрированной среде, охватывающей все бизнес-процессы предприятия. Решение «Управление жизненным циклом продукта » является серьезной основой для успешной разработки и вывода на рынок новых продуктов и изделий, а также объединяет информацию и специалистов, организуя их эффективную и слаженную работу. Благодаря решению «Управление жизненным циклом продукта» предприятия могут интегрировать в общий процесс различные подразделения, включая отделы маркетинга, продаж, планирования, а также производство, материальное снабжение, техническое обслуживание и ремонт. Кроме того, данное решение обеспечивает возможность совместной работы партнеров, поставщиков, субподрядчиков, поставщиков услуг и даже клиентов.

152 Системы ERP Функции автоматизированных систем управления предприятием (АСУП) в различных сочетаниях объединяются в несколько групп, соответственно появляются разновидности АСУП с названиями ERP, MRP, MES, SCM и др. Обычно функции управления поставками и отношениями с заказчиками относят к функциям ERP, но иногда эти функции реализуются в самостоятельных системах SCM и CRM соответственно. Наиболее полно функции управления предприятиями представлены в системах ERP (Enterprise Resource Planning), т.е. АСУП обычно отождествляют с системами ERP.

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

154 Системы ERP В соответствии со Словарем APICS (American Production and Inventory Control Society), термин «ERP-система» может употребляться в двух значениях. Во-первых, это информационная система для идентификации и планирования всех ресурсов предприятия, которые необходимы для осуществления продаж, производства, закупок и учета в процессе выполнения клиентских заказов. Во-вторых (в более общем контексте), это методология эффективного планирования и управления всеми ресурсами предприятия, которые необходимы для осуществления продаж, производства, закупок и учета при исполнении заказов клиентов в сферах производства, дистрибьюции и оказания услуг.

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

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

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

158 PLM как интеграция PDM- и ERP- систем Если обратиться к проблематике управления жизненным циклом изделий, то в несколько упрощенном виде ее можно представить в виде формулы: PLM = PDM + ERP. Однако эти две составляющие сегодня являются не совсем равнозначными. Дело в том, что исторически PLM выросла из круга задач PDM, которые в свою очередь имеют родителями системы САПР (CAD). Поэтому, посмотрев на предлагаемые сегодня PLM-платформы, легко видеть, что они в большинстве своем базируются на применении CAD- или PDM- технологий, а ERP рассматривают как дополнительную внешнюю компоненту.

159 PLM как интеграция PDM- и ERP- систем Для реализации единого информационного пространства нужно сделать следующий шаг и объединить PLM (т.е. связку САПР – PDM) с ERP, так как значительная часть информации об изделиях создается и управляется учетными системами. Потребность переносить в ERP данные, полученные в САПР в результате проектирования, неоспорима. Так, например, чтобы эффективно планировать процессы проектирования, управлять работой складов и другими аспектами разработки, необходимо обладать информацией о составе проектируемых изделий. Подобные данные зачастую переносятся из САПР в ERP вручную.

160 PLM как интеграция PDM- и ERP- систем Для реализации единого информационного пространства нужно сделать следующий шаг и объединить PLM (т.е. связку САПР – PDM) с ERP, так как значительная часть информации об изделиях создается и управляется учетными системами. Потребность переносить в ERP данные, полученные в САПР в результате проектирования, неоспорима. Так, например, чтобы эффективно планировать процессы проектирования, управлять работой складов и другими аспектами разработки, необходимо обладать информацией о составе проектируемых изделий. Подобные данные зачастую переносятся из САПР в ERP вручную.

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

162 PLM как интеграция PDM- и ERP- систем В то время как CAD- и PDM-системы обычно интегрированы друг с другом, их взаимодействие с ERP в лучшем случае ограничивается однонаправленной передачей данных. Такой подход снимает необходимость ручного переноса информации из САПР в управленческую систему, т.е. ликвидирует наиболее острые проблемы, однако его еще нельзя назвать полноценной интеграцией.

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

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

165 PLM как интеграция PDM- и ERP- систем

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

167 PLM как интеграция PDM- и ERP- систем

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

169 PLM как интеграция PDM- и ERP- систем Планируя объединение САПР и ERP, нельзя забывать, что далеко не всю информацию нужно обязательно передавать. В некоторых случаях достаточно обеспечить лишь доступ к одной системе из другой, скажем, через портал. Это позволит снизить затраты на интеграцию и ускорить реализацию проекта. Через Web-браузер пользователи смогут просматривать данные из различных источников – например, сведения о складских запасах и затратах из ERP или чертежи и модели из САПР. “В несложных производствах со значительным количеством типовых узлов, где проектирование занимает незначительную часть времени, выпуск идет небольшими сериями, а справочник материалов изменяется мало, можно, наверное, обойтись порталами”.

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

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

172 Построение модели подсистемы взаимодействия ERP и САПР При реализации решения в масштабах предприятия на первый план выходят следующие требования: быстродействие; гибкость; масштабируемость; безопасность.

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

174 Построение модели подсистемы взаимодействия ERP и САПР Гибкость Задачи, стоящие перед предприятием, со временем могут существенно меняться. Изменяется штатное расписание, подчиненность отделов, бизнес-процессы, номенклатура выпускаемой продукции и т.д. В связи с этим гибкость системы и возможность модификации ее настроек без привлечения специалистов компании-разработчика (силами сотрудников службы автоматизации предприятия) представляется очевидной. Но для этого необходимо иметь административный пароль доступа к данным и полное описание структуры данных. Кроме того, преимуществом является то, что система поддерживает стандартные средства разработки (языки высокого уровня, скриптовые языки и т.п.), имеет открытый интерфейс прикладного программирования (API), а также поддерживает современные стандарты и форматы обмена данными (XML, ISO 10303 STEP и др.).

175 Построение модели подсистемы взаимодействия ERP и САПР Как показывает практика, в настоящее время наиболее распространены следующие схемы организации взаимодействия между системами PDM и ERP: написание специализированных модулей интеграции с использованием API обеих систем; через универсальные форматы обмена данными типа XML, STEP и т.п. Каждая из этих схем имеет свои плюсы и минусы: при работе через API часто возникает необходимость в большей производительности, но использование XML обеспечивает в ряде случаев гораздо более гибкое решение. Однако чрезмерно увлекаться программированием не следует, иначе можно получить систему, хорошо отвечающую сегодняшним задачам, но практически закрытую, что может вызвать проблемы при необходимости внесения в нее в будущем каких-либо изменений.

176 Построение модели подсистемы взаимодействия ERP и САПР Масштабируемость Масштабируемость является одним из ключевых требований, предъявляемых к корпоративным системам. Масштабируемость решения зависит от следующих факторов: архитектуры решения и модели данных. Хотелось бы отметить, что само по себе построение решения в архитектуре «клиент-сервер», «трехзвенной», «Web-ориентированной» и т.п. не дает гарантий хорошей масштабируемости системы. Очень многое зависит и от того, как спроектирована модель данных (например, одна и та же структура данных может обеспечивать хорошую производительность при запросах одного типа, но очень сильно «проваливаться» на запросах другого типа). Разработчики каждый раз стоят перед дилеммой: повысить гибкость системы, но расплатиться за это снижением производительности или оптимизировать производительность, пожертвовав гибкостью;

177 Построение модели подсистемы взаимодействия ERP и САПР возможностей по экстенсивному наращиванию мощности программно-аппаратного комплекса (поддержка кластерных решений и т.п.); возможностей по смене программно-аппаратной платформы без изменения модели данных (например, переход с СУБД MS SQL Server на Oracle). Исходя из вышесказанного, более предпочтительными являются решения, поддерживающие широкий спектр программно-аппаратных платформ и позволяющие гибко менять модель данных.

178 Построение модели подсистемы взаимодействия ERP и САПР Безопасность Под безопасностью решения понимается не только защита данных от несанкционированного доступа на всех уровнях, но и надежность, и отказоустойчивость системы в целом. Плюсом в этом случае является применение стандартных, проверенных решений по обеспечению безопасности, при этом снижается риск оказаться заложником «самодельных» решений. Большое значение имеет состав обеих систем. Интеграция невозможна, пока не построена объединенная среда САПР – PDM, включающая и технологические модули, а со стороны ERP не внедрен хотя бы контур калькуляции нормативной себестоимости, а еще лучше – контур производства. В первую очередь нужно четко поставить цели и задачи, которые предприятие собирается решить, и, уже исходя из них, определить объем интеграции, т. е. понять, какие данные будут транслироваться из одной системы в другую.

179 Функциональная схема интеграции ERP- и PDM- систем

180 Функциональная схема интеграции ERP- и PDM- систем Их взаимодействие происходит на основе API-интерфейса. Также есть возможность обмена с базой данных ERP файлами обмена типа XML. Для прямого доступа к базе данных создан WEB-сервер. Последний нужен для общения с клиентами, поиска заказчиков, доступа сотрудников предприятия к нужной информации. На следующем рисунке показана схема взаимодействия ERP и САПР на протяжении жизненного цикла продукции. На схеме видны значительные пересечения друг с другом контуров процессов, поэтому автоматизация проектирования заключается не просто в оснащении подразделений программным продуктом, но и в обеспечении совместимости и целостности данных внутри предприятия.

181 Функциональная схема интеграции ERP- и PDM- систем

182 Функциональная схема интеграции ERP- и PDM- систем Для создания непрерывного конструкторского цикла объединена ERP- система и система конструкторской и технологической подготовки в рамках единой информационной системы, что связывает специализированные производственные системы CAD/CAM с приложениями на базе ERP, позволяя включить конструкторско-технологические подразделения в единое информационное пространство.

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

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

185 Практика внедрения PLM К примеру, филиал ОАО "ГМК "Норильский никель" в 2000 году провел тендер на внедрение на предприятии АСУ для решения задач управления складскими запасами, снабжения и логистики на базе ERP-системы. Победила компания SAP c продуктом SAP R/3. Количество пользователей системой на предприятии на сегодняшний день составляет 1500 человек. Специалисты отдела информационных технологий ЗФ ОАО "Норильский никель" отмечают, что внедрение системы SAP позволило реализовать всю цепочку снабжения -от формирования потребности до списания материально-технических ресурсов в едином контролируемом информационном пространстве. С другой стороны, процесс внедрения, о котором говорят компании, представляя презентацию продуктов, не соответствует реальному сроку даже в отдаленном приближении. Вместо декларируемого месяца продукт был внедрен на предприятии за два года. Перейти на ERP от стандартной программы 1C, расширив количество пользователей в десятки раз, оказалось непросто.

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

187 Движение от САПР к PLM Рассмотрим диаграмму временных и материальных издержек промышленного предприятия (рис.). Не менее 70% затрат приходится на производственные функции, и именно в сфере производственной деятельности могут быть скрыты основные резервы, способствующие сокращению сроков выпуска новой продукции и повышению конкурентоспособности предприятия. Обычно 5-10% времени, которое отводится для самого процесса, занимает непосредственно выпуск изделия, а все остальное - подготовительные работы.

188 Движение от САПР к PLM Создание сложного изделия невозможно без его графического представления - рисунка, схемы, чертежа. Бурное развитие промышленности в прошлых веках потребовало от чертежа универсальности - чертеж, выполненный одним инженером, должен понять любой другой специалист, имеющий соответствующее образование. В итоге появились стандарты на оформление, а конструктора получили кульман - удобный инструмент для выполнения чертежей. Но со временем быстродействие ручного черчения перестало устраивать. Постоянно увеличивались объемы работ, а главное - росло количество типовых разработок на основе существующих изделий, ужесточились требования к срокам выпуска изделия. На помощь пришла интенсивно развивающаяся компьютерная отрасль: появление доступных и не слишком сложных в освоении (по сравнению с тем, что было раньше) компьютеров дали старт конструкторским системам CAD (Computer-Aided Design). Сначала такие системы представляли собой электронные кульманы - все, что прежде делалось карандашом и линейкой, было заменено соответствующими электронными командами, но не более того. Однако даже такая автоматизация приносила плоды: по мере накопления базы электронных чертежей все легче становилось проектировать новые и модифицированные изделия.

189 Движение от САПР к PLM Двумерное проектирование активно развивалось до середины 1990-х годов. Системы обзавелись несметным количеством приложений, библиотек, надстроек, позволивших максимально автоматизировать и упростить большинство чертежных задач. Появились и развились в отдельные направления расчетные системы CAE (Computer-Aided Engineering), системы проектирования обработки изделий на станках с числовым программным управлением CAM (Computer-Aided Manufacturing) и многие другие специализированные приложения, основанные на работе с данными, предоставляемыми CAD-системами. Параллельно развивался класс систем технологической подготовки производства САПР ТП (Computer-Aided Process Planning, CAPP), предназначенных для формирования технологических данных об изделии, ведения централизованного архива этой информации и автоматизированного выпуска технологической документации.

190 Движение от САПР к PLM Однако плоское проектирование все-таки неестественно для человека - ведь мы мыслим в трехмерном пространстве, живем в окружении трехмерных объектов. Развитие информационных технологий позволило вывести технологии проектирования на новый уровень. Появление трехмерного моделирования оказалось настоящим прорывом, вначале доступным только пользователям мощных графических Unix-станций. По-настоящему массовым 3D-моделирование стало ближе к середине 1990-х годов, когда 3D-CAD-системы были переведены на платформу PC. Объемная модель помогает в реализации массы сопутствующих функций. 3D-модель можно использовать для решения расчетных задач (анализ напряжений, перемещений, колебаний, гидродинамики, теплопередачи), подготовки управляющих программ для станков с ЧПУ, а также реалистичных изображений для технической документации и рекламных материалов, создания физических образцов на установках быстрого прототипирования. По 3D-модели создаются чертежи - причем делать это существенно проще, чем вручную, поскольку вся геометрия на чертеже формируется автоматически, позволяя конструктору не задумываться о правильности построения видов, разрезов и сечений. За CAD-системами практически все CAM/CAE-пакеты стали трехмерными, позволив при определенных условиях отказаться от чертежа вообще.

191 Движение от САПР к PLM Важнейшим преимуществом трехмерного моделирования является возможность исправления ошибок на ранней стадии проектирования, до появления первых опытных образцов. А коррекция проекта на цифровой стадии несоизмеримо дешевле, чем обнаружение недочетов после изготовления дорогостоящей опытной партии. Еще пятнадцать лет назад аналитическая компания Gartner Group произвела оценку стоимости исправления одной-единственной ошибки на различных стадиях подготовки производства: $1 Концептуальное проектирование. $10 Конструкторская проработка изделия. $100 Изготовление макета изделия. $1 000 Проектирование технологической оснастки. $10 000 Изготовление оснастки. $100 000 Выпуск установочной серии. $1 000 000 Серийное производство.

192 Движение от САПР к PLM В направлении развития 3D-систем существует ряд проблем. Моделирование больших сборок по прежнему является сложным для многих CAD-систем, эргономика работы конструктора пока далека от идеала. В то же время, чем мощнее система, тем она труднее в освоении и работе. 2D-проектирование также остается востребованным. Во-первых, многие компании привыкли работать в плоскости и создали множество библиотек и приложений именно для автоматизации 2D-работ. Во-вторых, есть области, которые традиционно остаются двухмерными независимо от степени использования 3D - например, разработка электрических схем. В результате мы имеем широчайший выбор программных продуктов, от легких узкофункциональных двумерных решений до САПР тяжелого класса стоимостью в десятки тысяч долларов за рабочее место, позволяющих осуществить полный цикл разработки сколь угодно сложного изделия.

193 Движение от САПР к PLM Автоматизировав с помощью комплекса CAD/CAM/CAE/CAPP все направления подготовки производства, предприятие получает в свои руки цифровую модель изделия - это более высокий уровень, чем просто использование 3D-CAD-системы. Цифровая модель содержит как геометрию изделия, так и все необходимые расчетные данные, карты технологических процессов, ведомости, управляющие программы для станков, электронные описания изделия и технические руководства и т.д. Но огромный массив цифровой информации не только приносит пользу, но и доставляет значительные проблемы хранения, анализа и обработки.

194 Движение от САПР к PLM Экономический эффект от этапной автоматизации минимален - ведь процесс проектирования остается последовательным. В результате ни полной экономической отдачи, ни действительно значимого сокращения срока подготовки производства автоматизация не приносит, хотя положительный эффект и достигается.

195 Движение от САПР к PLM Более того, разработка и подготовка производства сложной, наукоемкой продукции - групповой процесс, в котором могут принимать участие даже группы предприятий. В процессе разработки изделия возникает ряд проблем, влияющих на успех всего проекта. Это в первую очередь отсутствие возможности видеть ключевые ресурсы, вовлеченные в процесс разработки, в их фактическом состоянии на данный момент времени, это организация совместной работы коллектива специалистов с привлечением компаний, поставляющих какие-либо компоненты для разрабатываемого изделия. Существенно сократить сроки подготовки производства можно только одним способом - за счет параллельного выполнения работ и тесного взаимодействия всех участников процесса. Эта задача решается за счет создания единого информационного пространства (ЕИП) предприятия, другими словами, единого пространства цифровых данных о корпоративной продукции.

196 Движение от САПР к PLM Здесь появляется новый класс систем, нацеленных на решение задач организации и координации работ инженерного персонала, - систем управления данными об изделии, PDM (Product Data Management). Современные PDM решают гораздо более широкий круг задач, чем обычное архивирование информации, позволяя полноценно реализовать следующую ступень развития САПР-технологий, аккумулировать цифровую информацию об изделии и непрерывно управлять информацией на протяжении всего жизненного цикла изделия (ЖЦИ). Что и является концепцией PLM (Product Lifecycle Management) - принципиальным моментом современного этапа автоматизации промышленного производства.

197 Движение от САПР к PLM PDM-система является средством интеграции множества используемых на предприятии прикладных автоматизированных систем (CAD/ CAM/ CAE/ CAPP/ ERP/MRP) за счет сбора поступающей из них данных в логически единую информационную модель на основе стандартных интерфейсов взаимодействия (рис.). Пользователями PDM-системы могут быть все сотрудники виртуального предприятия-участника жизненного цикла наукоемкого объекта.

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

199 Company Logo Управление составом изделия Управление архивом информации ФУНКЦИИ PDM Функционал PDM-систем Управление процессами Классификация Вспомогательные функции

200 Движение от САПР к PLM Главная задача PDM-системы - предоставить соответствующему сотруднику в соответствии с правами доступа необходимую информацию в нужное время и в удобной форме. Функционал PDM-системы можно разделить на несколько групп: Управление архивом информации. Все документы в PDM-системе хранятся в специальной подсистеме - электронном архиве, который обеспечивает целостность данных, организует доступ к ним пользователей в соответствии с назначенными правами и позволяет осуществлять поиск. Управление процессами. PDM-система выступает в качестве рабочей среды пользователей и отслеживает все их действия, включая версии создаваемых ими данных. Кроме того, PDM-система управляет потоком работ и занимается отслеживанием и протоколированием действий пользователей и изменений данных.

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

202 Движение от САПР к PLM Внедрение PDM - энергоёмкий процесс (рис.) с привлечением значительных ресурсов как со стороны предприятия, так и со стороны поставщика программного обеспечения. Потребуется изменить все процессы - от работы конструктора до полного пересмотра стандартов предприятия. PDM-система не просто программное обеспечение, которое можно установить и запустить. Это новая технология работы предприятия, новый режим функционирования бизнес-процессов.

203 Движение от САПР к PLM

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

205 Движение от САПР к PLM Перед проектной группой ставится целый комплекс задач: установка системы, организация работы и настройка серверов, настройка и наполнение баз данных и их адаптация к требованиям предприятия, организация автоматизированного обмена заданиями между сотрудниками и подразделениями. Как видно, объем работ значительный - внедренческий проект PDM-системы по трудоемкости не уступает внедрению системы управления корпоративного уровня.

206 SAP PLM – решение Основная терминология и общие принципы SAP ERP Основы mySAP ERP. Технологии SAP ERP предназначены для контроля и описания взаимодействия основных бизнес-процессов в областях управления: заготовкой и планированием материалов; данными жизненного цикла; выполнением производства; складами и запасами; заказами клиентов; основными средствами и сервисным обслуживанием; программами и проектами; человеческим капиталом; внутренней и внешней финансовой отчетностью, а также – реализации бизнес- информации и аналитики и стратегического планирования на предприятии.

Компоненты SAP NetWeaver SAP EP (enterprise portal) SAP BW (business information warehouse) SAP XI (exchange infrastructure) 207 SAP Web AS (application server)

208 SAP PLM – решение Для поддержки архитектуры корпоративных сервисов (enterprise services architecture – ESA) в SAP применяется прикладная и интеграционная платформа SAP NetWeaver, построенная на основе технологии веб-сервисов. Необходимые функции для отраслевых решений предоставляют четыре компонента SAP NetWeaver: 1) SAP EP (enterprise portal) – интеграция трудовых ресурсов (организация многоканального доступа); 2) SAP BW (business information warehouse) – интеграция информации (бизнес-информация и аналитика, управление знаниями); 3) SAP XI (exchange infrastructure) – интеграция процессов (управление бизнес-процессами, инфраструктура обмена); 4) SAP Web AS (application server) – прикладная платформа (на основе языков Java и Abap).

209 SAP PLM – решение Однако, не все решения SAP основаны на SAP NetWeaver. Существуют другие продукты, например, SAP Business One, который связан с системной средой SAP посредством XML. Данный компонент реализован на языке С++ и может быть установлен в различных ОС MS Windows. SAP Business One содержит в себе функции из различных областей управления бизнес-процессами (финансы; управление клиентами, закупками, складами и т.д.). Современный этап развития систем SAP начался с системы SAP R/3, уже имеющей двухуровневую архитектуру (SAP-базис и SAP-приложение), которая вошла компонентом в представленную в 2003 году систему mySAP ERP – пакет решений в составе mySAP Business Suite (рис.):

210 mySAP Business Suite

211 mySAP ERP mySAP ERP (enterprise resource planning) – планирование ресурсов предприятия mySAP CRM (customer relationship management) – управление связями с клиентами; mySAP PLM (product lifecycle management) – управление жизненным циклом продукта; mySAP SRM (supplier relationship management) – управление отношениями с поставщиками; mySAP SCM (supply chain management) – управление логистической цепочкой.

212 SAP PLM – решение Организационные уровни Организационные уровни. В приложениях SAP организационные единицы отражают структуру предприятия. Организационными элементами являются самостоятельные объекты (заводы, склады, пункты продаж, места возникновения прибыли). Мандант (client) – виртуальное предприятие (группа предприятий), которое представляет собой единицу верхнего уровня иерархии всех организационных элементов. В баланс данного предприятия включается центральный организационный элемент финансовой отчетности – балансовая единица (company code). В рамках виртуального предприятия балансовых единиц может быть несколько, каждая из которых будет отображать конкретное предприятие (enterprise), компанию (company) и дочернюю компанию (subsidiary). Для планирования производства (factory) центральной организационной единицей логистики является завод (plant).

213 SAP PLM – решение Организационные уровни Одна балансовая единица (company code) может иметь в подчинении несколько заводов, присваиваемых ей в настройке. Условиями продаж клиенту управляет элемент – сбытовая организация (sales organization), имеющая нижним уровнем своей иерархии для представления линеек товаров отделы (departments), сектора (divisions), бизнес сферы (business areas) объединенные организационным элементом – сектор (division). При описании возможных многочисленных складов (warehouses) используется элемент – скалды (storage locations) (таблица). Все организационные единицы присваиваются одному или нескольким приложениям системы.

214 SAP PLM – решение Организационные уровни

215 SAP PLM – решение Организационные уровни Организационную структуру, для которой осуществляется ведение и перерасчет затрат и выручки называют контроллинговой единицей (controlling area) – отдельная единица учета затрат. Рынок сбыта (sales area) – совокупность сбытовой организации (sales organization), каналов сбыта (distributional channels) и секторов (divisions). Каждая страна для заводов находящихся на ее территории имеет одну закупочную организацию (purchaising organization), которая выполняет закупки для всех заводов в стране и их проводку в балансовой единице (company code) этой страны.

216 SAP PLM – решение Основные данные Основные данные. Постоянно используемые в SAP-системе для нескольких бизнес-процессов данные называются основными (master data), например, клиенты (customers), материалы (materials) и поставщики (vendors). Основные данные клиентов (customer master data) включают в себя информацию описывающую отношения между компанией и ее клиентом (запросы клиента, поставки, платежные документы и т.д.) и организованы в трёх уровнях (рис): в уровне манданта (client) – общие данные (general data); в уровне балансовой единицы (company code) – бухгалтерские данные (financial accounting data); в уровне рынка сбыта (sales area) – данные сбыта (sales data).

217 SAP PLM – решение Основные данные

218 SAP PLM – решение Основные данные Прикладные программы, используемые в SAP для организации бизнес-процессов: создания заказа клиента (customer order); проводки входящего платежа (incoming payment); утверждения уведомления об отсутствии (leave request), называются транзакциями (transactions). Запись данных, создаваемая при выполнении каждой транзакции – документом (document). Документ содержит в себе всю необходимую заданную информацию из основных данных (master data) и организационных элементов (organizational elements).

219 SAP PLM – решение Основные данные При формировании потребности в материалах в приложении Закупки (Purchasing) можно автоматически создать заявку (order requirement). Создавая заказ (order), необходимо задать обязательные данные (поставщик (supplier), материал (material), завод (plant) и другую информацию, соответствующую закупочной организации (purchasing organization)).

220 SAP PLM – решение Основные данные С момента поступления материала (goods receipt) выполняется ряд обязательных действий: сравнивается с заказом количество поступившего материала; создается документ материала (material document) для обновления данных о запасе (inventory) в приложении Управление материалами (Material management (MM)); в приложении Финансы (Financial accounting (FI)) создаются документы проведения материала по счету запасов (stock account) или счету расхода (consumption account) и проводки суммы счета (amount invoice posted) по счету поступления материала (дебет/debit) и счету кредитора (кредит/credit); счет-фактура (invoice) поступает в приложение Контроль счетов (Invoice verification), где проверяется правильность расчетов и других данных. в Финансах (FI) выполняется обработка платежей (payment processing), с помощью которой принимаются решения о способах оплаты и банковских расчетах.

221 SAP PLM – решение Основные данные Заказ клиента (sales order) является основой процесса сбыта в приложении Продажи (Sales (SD)). При продаже изделий со склада заказ клиента создается для материала в запасе. В данном случае, затраты (costs) и выручка (revenues) рассчитываются автоматически и создается документ исходящей поставки (delivery document). Фактурирование (billing) поставки выполняется после отпуска материала (goods issue) со склада и его проводки. Можно также создать транспортный заказ (transfer order) на основе заказа на перемещение запаса (transport order). В процессе фактурирования в приложении SD создается документ счета (invoice document), а выручка переносится в приложение Контроллинг (Controlling). После клиентского платежа (payment) и его получения поставщиком в FI выполняется проводка поступления платежа.

222 SAP PLM – решение Основные данные Предоставление же услуг является прямым процессом создания услуги (services generation process), который также связан с заказом клиента – носителем затрат (cost bearer). Т.е. затраты и выручку можно провести отдельно в приложении SD. В данном случае отсутствуют этапы транспортировки и поставки. Позиция заказа клиента (носителя затрат) проводится для всех транзакций создания услуг (service generation). С помощью позаказного расчета затрат (order settlement) после предоставления услуги данные о затратах и выручке переносятся в приложение Учет результатов (profitability analysis (CO-PA)).

223 SAP PLM – решение Основные данные Принципы анализа и составления отчетов. При выполнении приложениями транзакций обрабатываемые данные обновляются в информационной системе логистики (ИСЛ)(Logistic information system (LIS)). Данная система отвечает за агрегирование и сохранение информации, анализируемой потом в информационной системе сбыта (ИСС) (Sales information system (SIS)). Использование агрегированных данных позволяет сократить время реакции системы и повысить качество генерируемых отчетов. Анализ данных из оперативных и бизнес- приложений, а также внешних источников SAP- систем проводит SAP BW. Процессы сбора данных контролируют инструментальные средства администратора (ИСАдм) (Administrator workbench (AWB)).

224 SAP PLM – решение Основные данные Оперативную аналитическую обработку OLAP (On-Line Analytical Processing) из больших объемов оперативных и исторических данных также осуществляет SAP BW. Технологии OLAP были разработаны для анализа данных в системах баз данных с целью поддержки принятия решений и ориентированы, главным образом, на обработку нерегламентированных интерактивных запросов. Основной целью анализа является количественная и качественная оценка достигнутых результатов и/или динамики деятельности компании. Используемые для этого методы сводятся к генерации различного рода выборок, формированию агрегированных данных, трансформациям способов представления данных. Возможности для всестороннего анализа пользователям предоставляет компонент Business Explorer (BEx).

225 SAP PLM – решение Компоненты SAP PLM При разработке конструкторской документации данные создаются с помощью систем CAD и переносятся в систему управления предприятием при помощи интерфейса PLM. Система управления документами (document management system (DMS)) позволяет сохранить первичные документы в защищенных областях SAP и создавать соединения с другими объектами. Браузер структуры продукта позволяет на одном экране просмотреть всю информацию об изделии (основная запись материала (material master), спецификации (bills of material), технологические карты (routings) и документы (documents)). За внесение изменений в данные в зависимости от даты, серийного номера или других параметров, определяемых пользователем, отвечает служба изменений. Управление конфигурацией вводит и переносит данные по изделию путем тиражирования.

226 SAP PLM – решение Компоненты SAP PLM Следовательно, структуру компонентов управления данными жизненного цикла можно описать следующим образом: 1) управление документами (document management): - управление версиями; - управление статусами; - формирование защищенных областей; - интеграция с другими объектами;

227 SAP PLM – решение Компоненты SAP PLM 2) управление структурой продуктов (product structure management): - управление материалами; - управление документами; - управление спецификациями; - управление техкартами, классами и т.д.; - браузер структуры продукта; - инструментальные средства инжиниринга и тиражирования; 3) интеграция (integration): - интеграция решений CAD с использованием интерфейса PLM;

228 SAP PLM – решение Компоненты SAP PLM 4) служба изменений и управление конфигурацией (engineering change and configuration management): - внесение изменений в объекты; - документирование конфигурации; - тиражирование данных в другие системы. Система управления документами интегрирует внешние файлы в mySAP ERP, позволяя выбирать их формат. Требуемым объектом является инфо-запись (info record) документа, управляющая обработкой первичных данных. Инфо-запись документа связана с другими объектами, например, материалами и оборудованием, получающими доступ к первичной информации, которая хранится в различных защищенных областях доступных через концепцию полномочий для просмотра и обработки из полей инфо-записи документа.

229 SAP PLM – решение Компоненты SAP PLM Документ содержит специфичные данные и состоит из инфо-записи и ее первичного документа, представленного в электронном или бумажном виде. Инфо-записи имеют свои версии и классификацию и позволяют управлять файлами первичных документов, контролируя ход их обработки. Первичные документы могут храниться в защищенной области. Отображение и редактирование инфо-записи производится с помощью средства просмотра – языка ECL или посредством интеграции с Microsoft Office. Внешние системы САПР подключаются к SAP при помощи интерфейса PLM, а системы архивации – с помощью интерфейса ArchiveLink. Преимущества инфо-записи в SAP ERP проиллюстрированы на рисунке.

230 Функциональные возможности инфо-записи документа в SAP ERP

231 SAP PLM – решение Компоненты SAP PLM При необходимости организации доступа к информации первичных документов из других объектов SAP можно создать соединение между инфо-записью и этими объектами, в числе которых могут быть: материал (material); оборудование (equipment); техническое место (function location); заявка (purchase requisition); документ (document); заказ на поставку (purchase order); номер изменения (change number);

232 SAP PLM – решение Компоненты SAP PLM операция сетевого графика (network operation); производственный заказ (production order); клиент (customer); позиция торгового документа (sales document item) и т.д. Также с инфо-записью документа можно соединять спецификации, документацию и информацию с экрана. Соединение объектов может выполняться либо на стороне объекта, либо на стороне документа. Соединения можно использовать для обращения к основной записи материала.

233 SAP PLM – решение Приложения PLM и классификация Интерфейс PLM даёт возможность подключать к mySAP ERP множество внешних систем для обеспечения обмена данными. В числе таких систем чаще всего присутствуют: системы CAD; классификационные системы (classification systems); географические информационные системы (GIS) и офисные приложения. При помощи интерфейса PLM организован двунаправленный обмен данными между mySAP ERP и внешними системами. Перенос данных может осуществляться с использованием графического интерфейса пользователя (ГИП) (Grafical user interface (GUI)).

234 SAP PLM – решение Приложения PLM и классификация В этом случае экраны SAP применяются в качестве диалоговых окон. В противном случае, если GUI не используется, данные вводятся в диалоговых окнах BAPI (Business API) — программный интерфейс для доступа к методам бизнес объектов SAP R/3 системы, который может быть реализован как метод класса, так и как RFC (Request for Comments) вызов. RFC – запрос комментариев из серии пронумерованных информационных документов Интернета, содержащих технические спецификации и стандарты, широко применяемые в глобальной сети. Интерфейс PLM базируется на стандартной библиотеке SAP RFC или других технологиях, например, SAP Java Connector.

235 SAP PLM – решение Приложения PLM и классификация Для упрощения поиска объектов предусмотрена классификация, позволяющая определять не только точный номер объекта, но и его атрибуты и параметры. Организована возможность поиска похожих объектов в пределах установленных ограничений на точность критериев сравнения. Новая основная запись материала создается как компонент спецификации (component for the BOM – bill of material). Для определения места позиции данного нового материала выполняется поиск по соответствующим классам материалов. При обнаружении необходимого, на экран выводятся признаки классов (characteristics of the classes). Процесс поиска запускается после присвоения признаков. Результатом поиска является список материалов (list of materials), содержащий значения признаков, совпадающих с заданными критериями выбора. После чего, найденный соответствующий материал копируется в спецификацию (рис.).

236 Цикл определения спецификации для новой позиции

237 SAP PLM – решение Приложения PLM и классификация В SAP PLM создается система классов, где определяются атрибуты (признаки), которые наиболее полно и корректно описывают продукт. Далее эти признаки создаются с указанием специфичных значений признаков и присваиваются не материалу, а целому классу. Классам присваиваются соответствующие объекты. Документ может включаться в другой класс как основная запись материала. Классификация выполняет следующие основные функции: 1) создание признаков и их допустимых значений; 2) ведение классов и присвоение им соответствующих признаков; 3) создание объектов и присвоение их определенным классам; 4) поиск объектов.

238 SAP PLM – решение Приложения PLM и классификация Таким образом, классификация осуществляет присвоение объектов классу и присвоение признаков в классе. Классификация производится либо непосредственно для объекта, либо в соответствующих транзакциях системы классификации. При описании комплексных изделий в компонентах: сбыт (sales) и производство (product) выполняются задачи по конфигурированию (configuration). Изделие изготавливаемое в различных вариантах называется конфигурируемым материалом (configurable material), который включает все возможные свойства (признаки) продукта для их дальнейшего отбора по заданным критериям в производимый объект.

239 SAP PLM – решение Приложения PLM и классификация Все компоненты, которые могут понадобиться для производства конкретного варианта материала содержаться в спецификации конфигурируемого материала (BOM of the configurable material), для создания конфигурации спецификации (configure the BOM) (выбора компонентов для конечного определенного варианта изделия) применяется описание отношений (dependencies) (рис.). Технологическая карта (routing) или список задач (task list) конфигурируемого материала – это перечень всех операций, которые могут оказаться необходимыми для производства определенного варианта изделия. Для выбора необходимых операций также используется описание отношений (dependencies) (рис.).

240 Конфигурируемые основные данные

241 SAP PLM – решение Браузер структуры изделия Графический браузер структуры изделия (graphical product structure browser) – основное навигационное информационное средство в компоненте mySAP PLM, которое представляет собой древовидную структуру и отражает функциональные связи между объектами. В браузере любой объект может быть вызван и изменен. Все изменения отображаются сразу после подтверждения с помощью кнопки «обновить» (refresh). Ограничение вывода на экран подробных данных осуществляется при помощи фильтров (filters) в соответствии с заданными требованиями. За просмотр в браузере первичных документов (originals) отвечает инструмент Enterprise Application Integration (EAI).

242 Инструментальные средства инжиниринга Инструментальные средства инжиниринга (ИСИ) (Engineering workbench (EWB)) позволяют не только создавать, но и вести спецификации и технологические карты, формируя отношения между их позициями в рабочем списке (worklist). Рабочий список содержит выбранные для обработки ИСИ объекты, которые копируются в него из базы данных. После завершения обработки выбранных объектов (создания новых, изменения или удаления) рабочий список сохраняется.

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

244 SAP PLM – решение Служба изменений Служба изменений (Engineering change management (ECM)) – централизованная логистическая функция для изменения основных данных. Проводимые изменения группируются, контролируются и документируются при необходимости. ECM может применяться для сохранения истории версий различных объектов (спецификаций, технологических карт). Кроме того, определяется область действия (effectivity) изменения (change), активность которой позволяет изменению вступить в силу. Данный параметр может определяться моментом времени.

245 SAP PLM – решение Служба изменений Изменения вступающие в силу автоматически в определенной области действия, становятся активными во всех сегментах логистической цепочки, например, для заказов клиента (sales orders), планирования потребности материалов (ППМ) (material requirement planning (MRP)) и управления производством (shop floor), но только в том случае, если для этих областей установлен ключ деблокирования (key is set).

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

247 SAP PLM – решение Служба изменений Общие данные об изменении (краткое описание, область действия, статус) вводятся в его заголовок (header). Выбор соответствующих видов объектов позволяет определить допустимость применения к ним данного номера изменения. Сами объекты, подлежащие изменению, их спецификации и технологические карты указываются в управляющей записи объекта (object management records). Номеру изменения можно также присвоить связанные документы (accompanying documents) в форме инфо-записей документов. Поиск номеров изменения производится при помощи классификации. Точные сроки начала действия изменения для определенных объектов позволяют контролировать альтернативные даты (alternative dates).

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

249 SAP PLM – решение Служба изменений Данные об изменяемом объекте и его статусе также вводятся в заголовок заявки на изменение (engineering change request (ECR)). Пользователь сможет начать изменять объекты с момента преобразования заявки на изменение (ECR) в запрос на изменение (engineering change ordert (ECO)) (рис.). Заявка на изменение (ECR) и запрос на изменении (ECO) отличаются от основной записи изменения сетью статусов, отображающих процессы запроса, проверки и реализации изменений. За координацию информационных потоков по всем видам операций отвечает система управления потоками операций (Workflow management system), что позволяет пользователям получать оперативное представление правильной информации.

250 SAP PLM – решение Служба изменений