Разработка компьютерной модели функционирования предприятия в условиях единичного производства (На примере ОАО "Сафоновский электромашиностроительный завод") Ефромеева Елена Валентиновна

Содержание к диссертации

Введение

Глава 1. Общая характеристика современного этапа развития информационных технологий - 10

1.1, Единая информационная среда предприятия 10

1.2, Этапы развития корпоративных информационных систем 13

1.3, Системы управления инженерными данными (PDM) 15

1.3.1. Технология управления жизненным циклом изделия (PLM) 15

1.3.2. Лидеры рынка 16

1.3.3. Лерспективы развития концепций PLM 17

1.3.4. Особенности национального рынка PDM 17

1 4. Управление документами и данными в области САПР 19

1.5. Организационно-техническая среда машиностроительного предприятия 20

1.6. Определение основных направлений работы 30

1.7 Выводы 34

Глава 2. Основные принципы моделирования и основные концепции унифицированного процесса разработки и языка моделирования UML 35

2.1. Принципы моделирования 35

2.2. Объектное моделирование 36

2.3. Унифицированный процесс и Унифицированный язык моделирования (Unified Modeling Language— UML) 39

2.4. Основные принципы унифицированного процесса. 43

2.4.1. Процесс, управляемый прецедентами 43

2.4,2,Процесс, основанный на архитектуре 44

2.4.3. Итеративный и инкрементный процесс 44

2.5. Фазы и технологические процессы UP 45

2.6. Конкретный пример применения UML 48

2.6.1, Конструкторско-технологическая подготовка производства (КТПП) в ОАО "СЭЗ" 48

2.6.2. Построение модели на примере технического центра 50

2.7. Обобщение результатов использоваїшя UML в начальной стадии 57

2.8. Выводы 59

Глава 3. Создание модели выполнения управленческих процессов ОАО «СЭЗ» в ходе КТПП электрических машин 60

3.1. Существующая схема проведения работ л о КТПП электрических машин 60

3.2. Моделирование бизнес-процессов работы технического центра 64

3.3. Модели и: представления 66

3.3.1. Модель прецедентов Начальное разбиение на подсистемы 69

3.3.2. Подсистема расчетного проектирования 70

3.3.3. Подсистема конструкторского проектирования 72

3.3.4.Подсистема подготовки технологической документации 74

3.4. Разработка прецедентов 75

3.4.1. Прецедент «Выбрать базовый образец» 7 5

3.4.2. Пакеты анализа и проектирования 77

3.4.3. Прецедент «Оценить требования заказчика» 7 8

3.5. Применение процессного подхода 78

3.6. Создание словаря модели 82

3.7. Вывод 91

Глава 4, Эффективная разработка и дальнейшее использование компьютерной модели функционирования производящего предприятия для совершенствования процессов КТПП АД 92

4.1. Создание бизнес-модели предприятия 92

4.2. Методика использования унифицированного метода и инструментальных средств для моделирования деятельности промышленного предприятия 95

4.2.1. Разработка бизнес-процесса 98

4.2.2. Методика создание пакета бизнес-процесса 100

4.3. Разработка прецедентов 107

4.4. Использование шаблонов 115

4.5. Оценка результатов 118

Основные выводы и результаты 121

Литература

• Единая информационная среда предприятия
• Унифицированный процесс и Унифицированный язык моделирования (Unified Modeling Language— UML)
• Существующая схема проведения работ л о КТПП электрических машин
• Методика использования унифицированного метода и инструментальных средств для моделирования деятельности промышленного предприятия

Введение к работе

Актуальность работы. За последние 30 лет стоимость разработки программного обеспечения устойчиво росла, тогда как стоимость создания и приобретения аппаратных средств столь же неуклонно падала. Теперь доля программного обеспечения в общей стоимости проекта оценивается примерно в 80%, тогда как ранее безусловно доминировала аппаратная составляющая [8].

Эволюция моделей процессов разработки ПО показана на рис. 1.

Рост сложное создаваемого ПО

Унифицированный процесс разработки

Итеративный подход

Спиральная модель

Комбинирование временных прототипов н инкрементной разработки

Создание

эволюционизирующих

прототипов в ходе

инкрементной

Временные прототипы разработки

Модель водопада

(поэтапный подход и

разработка ПО)

Годы

Рис, 1. Эволюция моделей процессов разработки программного обеспечения

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

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

В настоящее время в условиях рыночной экономики обостряется конкурентная борьба производителей, что влечет за собой необходимость поиска резервов повышения эффективности производства, сокращения сроков создания наукоемкого изделия и в т.ч. сроков его проектирования, повышения его качества и надежности. Сегодня промышленные предприятия нуждаются в интегрированных решениях по управлению жизненным циклом изделия - от идеи до утилизации. Такие PLM -решения (от английского Product Lifecycle Management) включают в себя CAD, САМ, САЕ, PDM, средства визуализации, планирования процессов, управление документооборотом, производственными данными, качеством и др. При этом должна быть обеспечена интеграция на уровне данных и моделей физически разобщенных коллективов (заказчиков, разработчиков, поставщиков, партнеров, производственников, маркетинговых и сервисных служб и т.д.) и процессов, которые могут располагаться/ происходить не только в разных подразделениях производственных предприятий, но и на разных континентах [1-4].

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

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

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

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

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

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

Чтобы понять, как работает современное предприятие, необходимо понять не только бизнес-процессы, но также данные, системы, оргструктуру, цели бизнеса, ключевые показатели, изделия, риски, правила, интерфейсы, уровень квалификации персонала и т.д. Более того, недостаточно и изучение всего этого в отдельности. Все эти понятия имеют значение только тогда, когда они взаимосвязаны. Важны именно их взаимоотношения и взаимодействия, Это и есть моделирование бизнеса. Тогда при моделировании процессов будет происходить документирование, анализ и разработка структуры бизнес-процессов, их взаимосвязей с ресурсами, необходимыми для выполнения процессов, и среды, где эти процессы будут использованы [80].

Применение моделирования позволяет решить различные задачи:

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

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

получить шаблон (решение, применимое в различных контекстах), позволяющий затем сконструировать систему;

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

В большинстве изданий, посвященных объектно-ориентированному анализу и проектированию, довольно подробно представлены примеры использования данного подхода компьютерного моделирования банковских систем, систем электронной коммерции и розничной торговли. Это работы таких известных разработчиков сложных программных систем, как Гради Буч, Джим Коналлен, Дин Леффингуэлл, Дон Уидриг, Крэг Ларман. Что касается промышленных предприятий, то для сложных наукоемких изделий (особенно это актуально для предприятий при выполнения индивидуальных заказов) эти решения еще должны быть найдены и созданы или, по крайней мере, улучшены и развиты. Решению этой задачи и посвящена настоящая диссертация.

Предметом компьютерного моделирования настоящей диссертации выступает деятельность производящего предприятия, связанная с совершенствованием управления координирования деятельности группы сотрудников в ходе подготовки производства наукоемких изделий, выполняемых по индивидуальным заказам в рыночных условиях. Компьютерное моделирование использовано для представления деятельности производящего предприятия от момента получения заказа до выпуска конструкторско-технологической документации, достаточной для организации производства наукоемкого изделия в условиях единичного производства. В качестве примера б работе рассматривается организация командной деятельности по подготовке производства асинхронных электродвигателей (АД) большой, мощности (до 2 МВатт) на Сафоновском электромашиностроительном заводе (ОАО «СЭЗ»), Данный завод выбран в качестве типового представителя для решения поставленных задач.

В машиностроительной области одним из самых трудоёмких этапов в освоении нового типа изделия является коиструкторско-технологическая подготовка производства (КТПГТ). Именно поэтому на этом этапе и следует выявлять возможности снижения стоимости и сокращения времени выхода конкурентоспособного изделия требуемого уровня качества на рынок, А это значит, что необходимо пересмотреть и найти новые решения по организации командной деятельности «производящего предприятия». Здесь под «производящим предприятием» будем понимать связку «ТЦ + завод» (технический центр + завод) или «КБ + завод» (конструкторское бюро + завод). Поэтому задача совершенствования командной деятельности по подготовке производства на современном машиностроительном предприятии является актуальной [78],

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

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

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

Научная новизна работы заключается:

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

2. в разработке методики получения компьютерной модели деятельности производящего предприятия при КТПП;

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

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

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

Практическая ценность работы состоит:

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

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

в обследовании ТЦ (с точки зрения вариантов использования) в рамках бизнес-процесса предприятия;

в получении формализованного описания бизнес-процессов (на примере подразделения ТЦ),

Данная программная система нашла свое применение в ОАО «Сафоновский электромашиностроительный завод».

Апробация. Основные положения и выводы диссертационной работы докладывались и обсуждались на заседаниях СКИБ факультета МЕУП МГТУ «Станкин», в ходе работы Первой Всероссийской научно-практической конференции "Применение ИЛИ- технологий в производстве", (2003 г., МАТИ) и Всероссийской научно-практической конференции "Наука, техника и технологии нового века" (2003 г., Кабардино-Балкарский государственный университет им. Х.М. Бербекова).

10 1 Общая характеристика современного этапа развития информационных технологий 1.1 Единая информационная среда предприятия

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

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

Бурное развитие в последние годы технических средств, прежде всего персональных компьютеров (ПК), сетевых технологий, коммуникационных систем, программного обеспечения привело к углублению и расширению процессов информатизации общества, созданию и внедрению на предприятиях современных информационных технологий [1-4,21-25,32].

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

Современный этап развития информационных технологий в промышленности связан технологиями непрерывной информационной поддержки жизненного цикла изделия или продукта, т.е. использованием технологий создания, поддержки и применения единого информационного пространства на всех этапах жизненного цикла продукции - от ее про ектирования до эксплуатации[2,11,19].

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

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

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

системы автоматизированного проектирования (САПР) различных уровней;

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

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

измерительно-вычислительные системы;

система управления предприятием;

компьютерная сеть предприятия.

Рассмотрим подробнее рис. 1.1. Окружение современного предприятия включает планирование и управление ресурсами промышленных предприятий (ERP), управление

12 поставками и цепочками поставок (SCM), управление взаимоотношениями с клиентами (CRM), финансово-экономический анализ я ведение бюджета, управление бизнес-процессами и электронным документооборотом, электронный бизнес и управление заказами через Интернет (В2В) [17-19,63,82].

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

Управление отношениями с клиентом (Customer Relationship Management, CRM) определяется изменениями, произошедшими на рынке за последние десятилетия: усиление конкуренции, увеличение количества товаров и услуг, рост издержек на хранение и транспортировку продукции. Все это заставило современные предприятия использовать новые способы для удержания конкурентного преимущества и увеличения доходов. Именно поэтому многие предприятия стараются всеми способами привлекать новых клиентов и удерживать имеющихся, устанавливая долгосрочные и успешные отношения. Основная проблема заключается в том, что в последние время увеличилось количество клиентских потребностей, покупателям требуется более персонализированный сервис, товары и услуги, адаптированные под их потребности. Среднестатистические ежегодные расходы на CRM-системы приведены в табл. 1.1.

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

Табл. 1Л .Среднестатистические ежегодные расходы на CRM-системы

ІЗ 1.2 Этапы развития корпоративных информационных систем

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

В конце 60-х годов крупные компании со множеством автоматизированных рабочих мест стали искать способ упростить управление производственными процессами. Первым шагом на этом пути стало появление идеи единой модели данных в масштабе всей организации. Так появилась концепция систем MRP (Material Requirements Planning) -автоматизированное планирование потребности сырья и материалов для производства. Главное достижение MRP-систем - минимизация издержек, связанных со складскими запасами.

Следующий этап развития корпоративных информационных, систем связан с появлением концепции MRP II (Manufacturing Resource Planning - та же аббревиатура, но другое содержание). Системы этого класса способны планировать все производственные ресурсы предприятия: сырье, материалы, оборудование с его реальной производительностью, трудозатраты [5-7].

Развитием концепций автоматизированного управления занимается американская некоммерческая организация APICS (American Production and Inventory Control Society). Она объединяет производителей (заказчиков), консультантов и разработчиков программного обеспечения.

По стандарту APICS MRP II включает следующие функции:

5. Sales and Operation Planning - Планирование продаж и производства

6. Demand Management — Управление спросом

7. Master Production Scheduling - Составление плана производства

8. Material Requirement Planning - Планирование потребностей в сырье и материалах

9. Bill of Materials - Спецификации продукции

10. Inventory Transaction Subsystem — Складская подсистема

11. Scheduled Receipts Subsystem - Отгрузка готовой продукции

12. Shop Flow Control — Управление производством на цеховом уровне

13. Capacity Requirement Planning - Планирование производственных мощностей

14. Input/output control - Контроль входа/выхода

15. Purchasing - Материально-техническое снабжение

16. Distribution Resource Planning- Планирование запасов сбытовой сети

13. Tooling Planning and Control - Планирование и управление инструментальными средствами

14. Financial Planning - Финансовое планирование

15. Simulation - Моделирование

16. Р erformance Measurement - Оценка результатов деятельности

Когда в список учитываемых при планировании ресурсов добавились другие, в частности, финансовые, появился термин ERP (Enterprise Resource Planning) - планирование ресурсов в масштабе предприятия.

Различие между концепциями MRP II и ERP заключается в том, что первая ориентирована на производство, а вторая - на бизнес. Например, тшше вещи, как условия кредитования заказчика по отгрузке готовой продукции, попадают в поле зрения ERP, но не MRPII.

ERP, однако, не является вершиной эволюции. Фундаментальное ограничение систем ERP: они автоматизируют внутреннюю деятельность предприятия (т.н. back-office). Со второй половины середины 90-х годов признанные поставщики ERP-систем, такие как SAP, испытывали нарастающее давление со стороны молодых компаний, предлагающих средства автоматизации функций, обращенных вовне (front-office). Широкое распространение получили концепции CRM (Customer Relations Management) и SCM (Supply Chain Management) -управление отношениями соответственно с заказчиками и с поставщиками. Реальные и прогнозируемые объемы рынка CRM-систем показаны в табл. 1,2,

К настоящему времени ведущие поставщики ERP-систем так или иначе научились справляться с этими задачами [8,57,59,61,81-86,99-103].

Табл. 1,2. Объемы рынка CRM-систем реальные и прогнозируемые

На расширение функциональности, на сферу взаимодействия предприятия с его заказчиками нацелена концепция CSRP (Customer Synchronized Resource Planning).

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

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

15 риск неудачи внедрения в этой области велик даже на Западе. Авторитетная консалтинговая компания Gartner Group заявила о завершении эпохи ERP-систем в 1999 году. На смену была предложена концепция ERP II - Enterprise Resource and Relationship Processing, управление внутренними ресурсами и внешними связями предприятия.

В2С (Business to Customer) и В2В (Business to Business) - обозначения широких классов программных продуктов, обслуживающих взаимоотношения предприятий с покупателями (В2С) и между собой (В2В).

Этапы развития корпоративных систем отражает следующая схема:

ERP И

МИР II

1 "J'J! .'!!' >* '".'.Л'".¹

1.3 Системы управления инженерными данными (PDM) 1,3.1 Технология управления жизненным циклом изделия (PLM)

Растет уровень автоматизации разработки продуктов, и одновременно растет популярность систем управления инженерными данными (Product Data Management, PDM), позволяющих управлять всей конструкторско-технологической документацией и предоставлять дополнительные данные, экспортированные из других корпоративных систем, из справочников или нормативных источников. Интерес к таким системам наблюдается и на Западе, и в России [5-11,59,62-72,79].

Аналитическая компания CIMdata () опубликовала данные о состоянии мирового рынка систем PDM за прошлый год и представила прогноз на будущее. По ее оценке, в 2001 г. мировой рынок PDM вырос на 25% — до 3,6 млрд, долл. Объем мирового рынка PDM показан на диаграмме 1. При этом доля услуг составила 53% (более 1,9 млрд. долл.), а ПО — 47% (более 1,6 млрд.).

в¹.; »rt л j і e мліч^ил не e О Soft ware

*12.1)00

19JS 1ФЭ6 1*117 1*)Э8 199Э 2000 2001 20*2 20UJ 2в04 25 2006

Est. Est. Est. Est. Est.

Диаграмма l. Объем мирового рынка PDM [Источник: CIMdata]

Как полагают аналитики, такой значительный рост доказывает, что предприятия признали важную роль технологии управления жизненным циклом изделия (Product Lifecycle Management, PLM) в достижении успеха в условиях высокой конкуренции. Системы PDM являются неотъемлемой составной частью комплекса средств PLM, который также включает:

базовые стандарты и технологии (XML, средства визуализации, совместной работы и интеграции приложений);

инструменты подготовки информации (системы автоматизированного проектирования — CAD, конструирования — САЕ, производства — САМ и т.д.);

вспомогательные программы (хранение данных, управление информацией, документооборот);

функциональные приложения (управление конфигурациями, версиями);

бизнес-решения, построенные на базе перечисленных платформ.

Средства PDM охватывают все разделы PLM, позволяя интегрировать различные системы этого комплекса. По направлениям деятельности доходы на рынке PDM распределились следующим образом: 54% получили создатели комплексных систем— EDS, Parametric Technology (РТС), SAP, IBM/Dassault, MatrixOne и другие, 26% — интеграторы и консалтинговые компании, а 20% — производители специализированных продуктов — І2, Documentum, FileNET и Cimage NovaSoft [8,59].

1.3.2 Лидеры рынка

Три отрасли промышленности по-прежнему составляют основу рынка PDM. Лидируют здесь компании, работающие в области электроники и телекоммуникаций. Их расходы на PDM в 2001 г. вплотную подошли к 965 млн. долл., что на 20% больше по сравнению с 2000 г. Транспортное машиностроение, представленное, главным образом, автомобилестроительными

17 компаниями и их поставщиками, отметилось в прошлом году 675 млн. по сравнению с 630 млн. в 2000 г. Космические фирмы потратили 465 млн. долл. против 401 млн. годом раньше. На диаграмме 2 показаны лидеры мирового рынка PDM.

.#

^

$700 _п

$600

$500

$400

= $300 +-

$200 $100

^

*

в Services

a Software arid Maintenance

^

v«

4№

4^

^

Диаграмма 2. Лидеры мирового рынка PDM [Источник: CIMdata]

1.3.3 Перспективы развития концепций PLM

Что касается прогноза на будущее, то по оценке аналитиков из CIMdata в ближайшие 5 лет инвестиции предприятий в технологии PLM будут расти. В числе основных причин такого прогресса аналитики называют рост популярности концепций PLM среди предприятий среднего бизнеса (раньше их основными потребителями были крупные предприятия), расширение функциональных возможностей PDM-продуктов, распространение систем коллективной работы, вовлекающих пользователей в процесс обработки информации о продукции, а также интеграцию решений PLM с другими корпоративными системами, такими как CRM, SCM, ERP и т. д. Как и в этом году, основная часть расходов предприятий на PDM придется на услуги: их доля в среднем составит 55%, а доля ПО — 45%. Это привлекает к данному рынку внимание консалтинговых компаний, которые стараются вступить в альянсы с ведущими поставщиками PDM-продуктов, чтобы предоставлять заказчикам законченные решения [8]. PDM будет увеличиваться на 25% в год и к 2006-му достигнет $11 млрд. долл.

1.3.4 Особенности национального рынка PDM

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

IS достигается и снижение себестоимости продукции. Как только руководители предприятий осознают важность качественных характеристик и себестоимости, они увеличат инвестиции в PLM/PDM. Постепенное возрождение российской промышленности, безусловно, влияет на рост спроса предприятий на средства САПР, в частности, на системы PDM [44,49,52,58,88]. К сожалению, платежеспособность заказчиков пока оставляет желать лучшего. Интерес к таким системам сейчас растет в геометрической прогрессии, а спрос — только в арифметической. Хотя рынок PDM в России пока находится в начальной стадии формирования, темпы его роста увеличиваются. Потенциально объем этого рынка очень велик -— примерно миллион рабочих мест или порядка 3—5 млрд. долл. Однако с учетом состояния отечественной экономики и производства реально он может составлять 30—50 млн. долл. в год [5-10].

По характеру развития российский рынок PDM несколько отличается от мирового. Если на Западе системы PDM начинают завоевывать признание у предприятий среднего бизнеса, то в России их в основном приобретают крупные организации. Эти технологии пользуются спросом в проектных организациях, которым в процессе работы приходится решать большое количество задач с партнерами, субподрядчиками, производственными объединениями. Еще одно отличие — соотношение сервиса и ПО. На западном рынке PDM доля сервиса выше, чем доля ПО, а у нас все наоборот [8]. Современные PDM-системы относятся к так называемым "некоробочным" решениям — их недостаточно просто купить, необходимы серьезные усилия по внедрению, а эти требования, к сожалению, не всегда понятны для заказчика. В нашей стране вполне закономерно, что доля ПО на рынке PDM значительно выше, чем доля сервиса. Ведь рынок находится в начальной стадии формирования и далек от насыщения. По мере роста числа внедрений PDM доля сервиса будет расти. Национальное своеобразие проявляется и в подходе к внедрению PDM. Для оснащения предприятий современными PDM-технологиями большое значение имеют стратегии реализации информационных технологий. Сейчас наиболее распространенным является подход "снизу вверх", когда проблемы решаются по мере их поступления. В результате предприятия часто приобретают разрозненные решения для автоматизации архива, управления документооборотом, интеграции приложений, управления проектами, управления каталогом комплектующих и т.д. Однако в последнее время в технологии PDM произошли важные изменения, благодаря которым возможно решить проблему автоматизации всех инженерных задач в рамках единой системы. Но для этого внедрение информационных технологий должно идти "сверху вниз" [6,10].

Что происходит сегодня с российскими пользователями и разработчиками систем автоматизированного проектирования, подготовки производства, управления инженерными данными об изделиях (CAD/CAM/PDM)?

По мнению компании АСКОН (центральный офис находится в Санкт-Петербурге), уже почти 14 лет выпускающей и внедряющей программные продукты CAD/CAM/PDM, уверенный подъем рынка продолжается. Он обусловлен, в первую очередь, продолжением роста в российской промышленности. Главной тенденцией рынка является значительное увеличение интереса к полноценным комплексным решениям и платежеспособного спроса на них. Руководство российских промышленных предприятий осознает, что для сохранения конкурентоспособности (не только на мировом рынке, но и на внутреннем) необходимо автоматизировать все этапы проектирования, подготовки производства, выпуска продукции в рамках единого решения по управлению предприятием.

1.4 Управление документами и данными в области САПР

В настоящее время уже очевидно, что эффективная работа современного предприятия немыслима без применения компьютерных технологий. Естественно, на разных предприятиях пути решения этой задачи, уровень автоматизации различны. Те предприятия, которые входят в крупные финансово-промышленные группы, экспортно-ориентированные отрасли, находятся в этом плане, конечно, на наиболее высокой ступени. Тем не менее, они постоянно вынуждены решать проблему совершенствования своих систем, выбора новых решений, появляющихся на рынке, учитывать возможности интеграции различных продуктов [1,2,24,25,32],

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

Во всех случаях предприятия, автоматизирующие производство, сталкиваются с необходимостью внедрения систем, отвечающих за управление документами и данными в области САПР [13,14,19,23 -25]. Если попытаться проанализировать путь компьютеризации предприятий, то можно увидеть следующее: вначале, естественно, приобретаются компьютеры, на них устанавливается прикладное программное обеспечение, обучается персонал. В результате повышается эффективность персональной работы сотрудников.

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

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

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

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

Работа с элементами этих баз данных должна быть связана с относящимися к ним электронными документами. Например, ведение состава сборочной единицы должно быть связано с работой над электронными конструкторскими документами, содержащими геометрические модели деталей и узлов, чертежи, текстовыми документами и т.д [28,29,32].

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

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

1.5 Организационно-техническая среда машиностроительного предприятия

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

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

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

%

Индивидуальные решения

.^Сценарии

Типовые решения

%

15-20 %

і Простота

использования

Ру вдводитвль

Пользователе

Рис. 1.2. Распределение пространства «Функциональность решаемых задач - простота использования» [Источник: «The Business of I. Т. Portfolio Management»] Известно, что инженерно-техническая информация принадлежит к числу наиболее ценных активов предприятия, В последнее время, в связи с переходом от серийного планового производства к мелкосерийному позаказному, значительно возросла номенклатура выпускаемых предприятиями изделий, что привело к многократному росту объема инженерно-технической информации. В условиях конкуренции предприятия вынуждены постоянно совершенствовать выпускаемые изделия, что ведет к появлению большого количества их модификаций и исполнений, производство которых необходимо планировать, решая задачи минимизации издержек с учетом требований заказчиков. Для управления производством в подобных условиях разработано множество разнообразных систем автоматизации. Эффективность управления не в последнюю очередь зависит от достоверности а актуальности данных, А это значит, что эффективная работа предприятия невозможна без системы, объединяющей результаты деятельности всех подразделений и связывающей все существующие на предприятии автоматизированные системы. Решение проблемы повышения эффективности производящего предприятия при выполнении индивидуальных заказов основывается на создании таких методов организации и управления в сочетании с соответствующим оборудованием, которые обеспечивают выполнение этого заказа с достаточно высокой производительностью и степенью автоматизации. Задача построения модели хода производственного процесса возникает как на этапе проектирования соответствующего технического комплекса, так и на этапе его эксплуатации [20,34].

22 Традиционно производственные стратегии обычно ставили целью сведение к минимуму затрат или модификацию изделия (рис. 1.3).

Время

Рис. 1.3. Распределение финансовых ресурсов производящего предприятия при подготовке и выпуске изделий рыночного спроса Не отказываясь от этих стратегий, многие предприятия принимают сейчас новые стратегии, которые основаны на качестве и/или времени (сроках) [1]. При этом критерии качества применяются не только к конечному продукту, но также ко всем соответствующим процессам - проектированию, производству и послепродажному обслуживанию, а основанные на времени стратегии фокусируются на сокращении времени, которое требуется для выполнения различных операций (например, для разработки и сбыта новых изделий, для реагирования на изменение потребительского спроса, для поставки изделия) (рис. 1.4).

6, Удовлетворенность качеством и
"""-*. производительностью

7. Гибкость освоения новых рынков

8. Послепродажное расширение свойств изделия

^ 9.Быстрый старт новых

3. Ускорение технической

подготовки производства (быстрое начало производства) 2. Сокращение стоимости внесения изменений на поздних этапах

Рис. 1.4. Возможности ИТ по управлению финансовыми

ресурсами производящего предприятия

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

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

Анализ традиционных процессов указывает на недостаточно высокую упорядоченность и систематизацию интеллектуального труда и, как следствие этого, наблюдается слабая подготовленность производства к работе в условиях информационных технологий. Это, в свою очередь, может привести к потере конкурентоспособности предприятия. Информационные технологии здесь рассматриваются как инструмент поддержки создания и изготовления наукоемкого изделия в условиях постоянного насыщения производства средствами вычислительной техники [36,43-49].

Традиционное распределение затрат при подготовке производства

L ..

I-

время Рис. 1.5. Перераспределение затрат при традиционной и компьютерной подготовке производства

1-ш О

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

На рис. 1.6. довольно детально показано представление компонент организационно-технической среды машиностроительного предприятия. '

КОМПОНЕНТЫ {обеспечение)

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

Методическое (в том числе лингвистическое

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

Программное

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

Техническое

Производственная система

Базовый программно-технический комплекс

^С (ПЭВМ, локальные вычислительные сети, внешние устройства, оборудование о ЧПУ и т.д.)

Рис, 1.6. Формализованное представление компонент организационно-технической среды машиностроительного предприятия

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

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

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

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

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

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

26 осуществляющий оперативный учет (в западкои литературе именуемый OLTP - On-Line Transaction Processing), и слой, в котором хранятся структурированные (т. е. систематизированные в соответствии с требованиями среднего управляющего персонала) данные. Вместе они образуют управленческую ИС (информационную систему) нижнего уровня (в западной интерпретации - Management Information System - MIS), позволяющую менеджерам видеть разнообразную информацию.

Бизнес-результат

Поток работ

материаль финан- информа-

Рис. 1.7. Единое информационное пространство

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

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

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

На рис. 1.8 трехгранная пирамида показана с точки зрения окружения современного предприятия в соответствии с рис. 1.1. На этом рисунке самым нижним является транспортный слой, т.е. доставка необходимой информации. Это телекоммуникационные сети, Web-hosting, Интернет-Сервис-Провайдинг, Следующий слой - это электронные инструменты, которые позволяют производить различные операции. Сюда же относится и вопрос построения интранет (сети внутри предприятия), Интранет направлен на то, чтобы предприятие было нормально организованным, имело понятную структуру и легко контролировалось.

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

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

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

Бизнес-результат

Л j5* Хранилища (У $ дранных, системная П

S> rV /иНТеГрЭЦИ;

системы

РШОЖЕНИЯ

ПРОЦЕССЫ

ИНСТРУМЕНТЫ

СЕТИ

CSRP= ERP+CRM

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

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

Инструментарий администрирования децентрализованной системы - полезная вещь, но настрой на управление всеми действиями работников из центра не продуктивен. Электронные средства должны стимулировать творческий потенциал работников и производительность их труда. Какие бы ценные указания ни давало высшее руководство, работникам интеллектуального труда необходимы еще и средства исследования, обмена друг с другом идеями и полученными результатами, а также внесения в бизнес-процессы изменений в реальном масштабе времени. Расширение полномочий работников с применением электронного инструментария моделирования позволит компаниям в ' каждой отрасли оторваться от основной массы конкурентов [80].

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

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

Компьютерная модель должна стать своего рода «периферийной нервной системой и кровеносными сосудами предприятия» [97,100], во главе которой стоит руководитель или групповой руководящий орган, кто принимает ответственные решения по сигналам от «нервной системы», корректируя ее поведение и постоянно обучая, вплоть до выработки автоматических «рефлекторных» реакций на типовые ситуации. Это позволило бы сделать компьютерную модель инструментом творческого создания эффективной организаций, обучения всего персонала новым правилам работы и формирования корпоративной культуры.

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

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

1.6 Определение основных направлений работы

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

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

Цель моделирования в данном случае состоит в разработке модели, которая адекватно воспроизводит процесс прохождения проекта в ходе конструкторско-технологической подготовки производства (КТПП) с использованием передовых технологий и самых прогрессивных инструментальных средств. В результате, можно в более сжатые сроки создавать комплексные программные приложения, в гл. систем управления производством. Благодаря современным компьютерным технологиям появилась возможность использовать для отладки программ метод нисходящего проектирования, значительно упрощающего работу по концептуализации и структурированию комплексных приложений реального времени. Эти инструментальные средства позволяют создавать комплексные приложения в виде набора хорошо структурированных компоновочных модулей, каждый из которых можно отдельно от других разрабатывать, тестировать и повторно использовать (рис. 1.10). Метод компонентного моделирования позволяет повторно использовать код для различных продуктов, ускоряя тем самым время выхода продуктов на рынок и сокращая сроки их окупаемости [29,56].

УРОВНИ РЕШЕНИИ

КОМПОНЕНТЫ

редметная область

аза данных и знаний

Правила выполнения

действий (процессов)

Графический ⁴ интерфейс

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

Рис. 1.10. Моделирование системы как развивающийся и итеративный процесс

Итак, модели выгодны, потому что они:

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

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

3. Обеспечивают системный подход к решению проблем.

4. Дают более ясное понимание проблемы.

5. Позволяют руководству анализировать вопросы типа «а что если?,,»

6. Требуют от пользователей четкого определения цели анализа.

7. Служат последовательным инструментом для оценки.

8. Позволяют пользователям использовать всю мощь математики и компьютеров для решения проблем,

9. Обеспечивают единый подход к анализу проблем.

Такие модели должны содержать строго связанные элементы и необходим язык, с помощью которого можно с различных точек зрения описать представления архитектуры системы на протяжении цикла ее разработки. И таким языком моделирования стал язык UML. Язык UML - это система обозначений для визуального представления моделей программных систем в объектно-ориентированной терминологии [12-16,26-30,33].

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

В качестве методологии моделирования выбран унифицированный процесс разработки. Он декларирует объектный подход к построению моделей, и является наиболее адекватным средством (среди формальных) описания реального мира. Унифицированный процесс компании Rational (Rational Unified Process— RUP) является примером специализированной версии унифицированного процесса.

Rational Rose является уникальным CASE-средством, чьи графические возможности, основанные на UML, способны решить задачи, связанные с любым проектированием и моделированием: от общей модели процессов (абстрактной) предприятия до конкретной (физической) модели класса б создаваемом ПО. Работа в Rational Rose заключается в проектировании определенного вида диаграмм, задавая при этом все свойства, отношения и взаимодействие друг с другом. При разработке любой ИС в первую очередь возникает проблема взаимопонимания подрядчика и заказчика уже на стадии договоренности о структуре системы. Имея такой инструмент, как Rational Rose, проектировщик (аналитик) всегда может показать заказчику не абстрактное словесное описание процесса, а его конкретную модель (на экране ПК или в печатном виде - неважно). Значит, Rational Rose позволит быстрее утрясти с заказчиком все детали планируемой системы [12,28].

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

Модель системы - это гарантия правильного и единого понимания ее концепции как разработчиком так и заказчиком;

Объектная методология разработки ПО - Унифицированный процесс разработки. Это наиболее адекватное средство построения модели системы;

Для однообразного отображения результата применения методологии необходим единый язык - нотация UML.

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

1. выполнить объектно-ориентированный анализ КТПП АД, т.е. сформировать модель прецедентов, где определяются функциональные требования к системе в терминах актеров и прецедентов (глава 1, 3, прил. 1, прил. 3);

2. выделить, обосновать и разработать набор моделей деятельности подразделения ТЦ при реализации индивидуальных заказов (глава 2, 3, прил. 4);

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

4. создать бизнес-пример высокоуровневой модели предметной области при построении единого информационного пространства для решения задач КТПП (глава 3, прил. 4);

5. разработать конкретные прецеденты до генерации программного кода (глава 3, 4, прил. 5);

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

3);

7. разработать методику получения компьютерной модели деятельности производящего
предприятия при КТПП (глава 4).

1.7. Выводы

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

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

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

10. Сформулирована необходимость в едином языке для однообразного отображения результата применения методологии - нотация UML.

11. Сформулированы задачи, решаемые в диссертационной работе.

35 2 Основные принципы моделирования и основные концепции унифицированного процесса разработки и языка моделирования UML

2.1 Принципы моделирования

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

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

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

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

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

Третий принцип; лучшие модели - те, что ближе к реальности.

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

36 Поскольку модель всегда упрощает реальность, задача в том, чтобы это упрощение не повлекло за собой какие-либо существенные потери.

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

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

2.2 Объектное моделирование

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

Алгоритмический метод представляет традиционный подход к созданию программного обеспечения. Основным строительным блоком является процедура или функция, а внимание уделяется прежде всего вопросам передачи управления и декомпозиции больших алгоритмов на меньшие. Ничего плохого в этом нет, если не считать того, что системы не слишком легко адаптируются. При изменении требований или увеличении размера приложения (что происходит нередко) сопровождать их становится сложнее [31,37,117-119].

Наиболее современным подходом к разработке программного обеспечения является объектно-ориентированный [28-42]. Здесь в качестве основного строительного блока выступает объект или класс. В самом общем смысле объект - это сущность, обычно извлекаемая из словаря предметной области или решения, а класс является описанием множества однотипных объектов. Каждый объект обладает идентичностью (его можно поименовать или как-то по-другому отличить от прочих объектов), состоянием (обычно с

37 объектом бывают связаны некоторые данные) и поведением (с ним можно что-то делать или он сам может что-то делать с другими объектами) [56].

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

Несмотря на явное преимущество объектно-ориентированных технологий анализа и проектирования перед структурными, их распространение было незначительным, поскольку ни один из методов не давал единой и цельной объектной модели системы. Каждый метод хорошо освещал одну или несколько сторон реальной системы, оставляя в тени множество других, не менее важных сторон. Кроме того, отсутствие единого стандарта очень мешало широкому распространению объектно-ориентированных методов при разработке программного обеспечения [16,26-30].

В течение 1994-96 годов создатели трех наиболее распространенных методологий -Гради Буч (ВООСН), Джим Рамбо (ОМТ - Object Modeling Technique) и Айвар Якобсон (OOSE - Object Oriented Software Engineering) объединили свои усилия под эгидой Rational Software Corporation на создание единого языка моделирования, который объединил бы все существенные и успешные разработки в данной области и стал бы стандартом языка объектного моделирования. Грандиозный труд, в котором наряду с Rational участвовали представители множества компаний, таких, как Microsoft, IBM, Hewlett-Packard, Oracle, DEC, Unisys, IntelliCorp, Platinum Technology и нескольких сотен других завершился созданием в январе 1997 года версии 1.0 Объединенного Языка Моделирования - Unified Modeling Language (UML), которая после бурного обсулсдения в течение 1997 года превратилась в сентябре в версию 1.1 и была передана в OMG для принятия UML в качестве отраслевого стандарта расширяемого языка объектного моделирования. OMG - некоммерческая международная организация, в которую входят более 600 ведущих мировых компаний и отвечающая за принятие стандартов в области информационных технологий. Теперь же пришло время для стандарта расширяемого языка визуального моделирования, и, учитывая огромный успех UML в мире, мало кто сомневается в его успешном распространении.

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

Рис. 2,1, Моделирование системы как развивающийся и итеративный процесс

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

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

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

39 международных стандартов описания структуры программных систем в последнее время становится унифицированный язык моделирования UML. Унифицированный язык моделирования является стандартным инструментом для создания документированных каркасов ("чертежей") программного обеспечения.

2.3 Унифицированный процесс и Унифицированный язык моделирования (Unified Modeling Language— UML)

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

Унифицированный процесс компании Rational (Rational Unified Process — RUP) является примером специализированной версии унифицированного процесса, образованной за счет добавления элементов в настраиваемую структуру. "Rational Rose стала стандартом при разработке приложений и бизнес-моделировании", - сказал Роджер Оберг (Roger Oberg), вице-президент Rational [66]. UP широко использует унифицированный язык моделирования (Unified Modeling Language— UML). Основой UML является модель, способная в контексте процесса разработки программного обеспечения упростить реальность, что помогает команде проекта понять наиболее сложные аспекты программного обеспечения [12].

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

Rational Rose корпорации Rational Software считается сегодня лидирующей в мире CASE-системой, подъем продаж которой пришелся на период с 1996-го по текущий год. UML стал стандартным языком объектно-ориентированной разработки не без подачи Rational Software, которая не только выпускает программные продукты, где используется UML^ но и активно принимает участие в организации Object Management Group (OMG), занятой созданием и обновлением спецификаций языка UML и т, д.

Своеобразным признанием заслуг Rational Software стало включение усеченного

40 варианта продукта Rational Rose в знаменитый пакет разработчика Microsoft Visual Studio. Правда, название поменялось с Rational Rose на Visual Modeler. Многие, используя Visual Modeler, так и не знают, с чем же на самом деле они работают.

Выше уже упоминался ряд проблем на пути выпуска ПО. Вот что предлагает RUP для решения подобных проблем:

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

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

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

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

16. Полный контроль всего происходящего в проекте посредством создания специальных архивов.

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

18. Использование визуального моделирования.

8. Применение не только механизмов объектно-ориентированного (00)
программирования, но и 00 мышления и подхода.

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

БИВЛЬОТЕКА язык, UML состоит из словаря и правил, позволяющих комбинировать входящие в него слова

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

ориентированны на концептуальное и физическое представление системы (рис. 2.2).

Руководствуясь стандартом UML, создается несколько представлений, в каждом из

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

представления показаны на рис, 2.1 и 2,2,

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

Логическое представление описывает структуру системы,

Компонентное представление указывает, как логические элементы «вписываются» в конечный продукт.

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

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

Поскольку сложное целое нельзя понять, гладя на него лишь с одной стороны, в UML определено много разных диаграмм, которые позволяют сосредоточиться на различных аспектах моделируемой системы. Т.е. достаточно полная модель системы допускает некоторое число взаимосвязанных представлений, каждое из которых отражает некоторый аспект поведения системы или ее структуры. При этом статическое и динамическое представления системы являются наиболее общими представлениями и в свою очередь могут подразделяться на другие более частные представления (рис. 2.2). Статические модели описывают структурные свойства, в то время как динамические - поведенческие свойства системы[29].

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

Хорошие диаграммы облегчают понимание модели. Продуманный выбор диаграмм при

моделировании системы позволяет задавать правильные вопросы о ней, помогает грамотной постановке задачи и проясняет последствия принимаемых решений [31]. В UML выделяют как самостоятельные представления 8 типов диаграмм, которые отображены на рис. 2.2.

Компоненты

статической.

части

системы

Компоненты динамической части системы/

МОДЕЛИ СИСТЕМЫ

Рис. 2.2. Общая схема моделей и типов диаграмм в процессе объектно-ориентированного анализа и проектирования в среде UML

2.4 Основные принципы унифицированного процесса.

2.4,1 Процесс, управляемый прецедентами

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

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

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

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

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

для клиентов, так как они видят отражение своих требований в тексте описания

прецедентов. Ведь клиенту иногда трудно увидеть воплощение собственных

условий в контексте требований.

S Прецеденты пишутся на родном языке пользователей. Если прецедент описан

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

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

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

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

Некоторые книги предлагают другие приемлемые определения, например: Крэг Ларман. «Применение UML и шаблонов проектирования» [3], Дин Леффингуэдл, Дон Уидриг. «Принципы работы с требованиями к программному обеспечению» [13], Уэнди Боггс, Майкл Боггс. «UML и Rational Rose» [12], Гома Хасан «UML, Проектирование систем реального времени, параллельных и распределенных приложений» [29],

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

Архитектура в первую очередь определяется терминами представления шести моделей (рис. 2.3). (Краткие описания этих моделей приведены ранее в главе при описании UML.) Эти представления отражают "архитектурно значимые" элементы моделей; все представления вместе взятые образуют архитектурное описание. Команда проекта создает архитектурное описание на ранних стадиях разработки, а затем в ходе всех видов деятельности, связанных с проектом, расширяет и совершенствует его.

2.4.3 Итеративный и инкрементный процесс Третий основной принцип унифицированного процесса - это его итеративная и инкрементная природа. Итерация представляет собой мини-проект, результатом' которого является версия системы и который завершается внешним либо внутренним выпуском. Считается, что эта версия является улучшенным (инкрементным) вариантом предыдущей версии, поэтому результат итерации называется инкрементом.

2.5 Фазы и технологические процессы UP Невозможно выявить все требования на ранних этапах проектирования. Появление новых требований учитывается в процессе разработки, шганируя проект в несколько итераций, RUP состоит из пяти основных технологических процедур и четырех этапов и является итеративным [37]. На каждом цикле выполняются все четыре этапа и рассматривается, как далеко удалось продвинуться в технологических процедурах и их продуктах. В унифицированном процессе разработай проходим четыре фазы проекта: начальная фаза (фаза исследований) (inception), уточнение (elaboration), конструирование (построение) (construction) и ввод в действие (развертывание) (transition).

Модель анализа

Модель проектирования

Модель реализации

Модель прецедентов

Модель развертывания

Модель тестирования

Рис. 2.3. Шесть основных моделей унифицированного процесса

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

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

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

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

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

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

Еще одним преимуществом такого подхода к моделированию системы является то, что среда Rational Rose способна генерировать "скелетный код" системы. Для использования этой возможности следует разработать компоненты и диаграмму компонентов на раннем этапе конструирования. Генерацию кода молшо начать сразу после создания компонентов и нанесения на диаграмму зависимостей между ними, В результате будет автоматически построен код, который можно создать, основываясь на проекте системы. Это не означает, что с помощью Rose можно получить любой код, реализующий бизнес-логику приложений. Результат сильно зависит от используемого языка программирования, но в общем случае предполагает определение классов, атрибутов, областей действия (общих (public), закрытых (private) и защищенных (protected)), прототипов функций и операторов наследования. Это позволяет съэкономить время, так как написание кода вручную -— довольно кропотливая и утомительная работа. Получив код, программисты могут сконцентрироваться на специфических аспектах проекта, связанных с бизнес-логикой.

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

В унифицированном процессе выделяют пять технологических процессов, которые присутствуют в ходе выполнения всех четырех фаз: управление требованиями (требования), анализ, проектирование, реализация и тестирование [12,37]. Каждый технологический процесс

47 представляет собой последовательность видов деятельности, которые выполняют исполнители проекта.

Далее приводится краткое описание каждого технологического процесса.

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

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

> Анализ

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

> Построение (проектирование)

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

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

> Реализация

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

> Тестирование

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

2.6 Конкретный пример применения UML

Рассмотрим возможности UML по описанию деятельности конструкторско-технологической подготовке производства асинхронных двигателей (КТПП АД) на примере конкретного предприятия - ОАО "СЭЗ".

2.6.1 Конструкторско-технологической подготовка производства в ОАО "СЭЗ"

КТПП в ОАО "СЭЗ" представляет собой комплекс технических, организационных и производственных мероприятий по созданию конструкций, разработке технологии и оснастки, освоению выпуска новых электродвигателей, обеспечению ритмичного бесперебойного производства, высокого качества изделий [50-55].

Для выполнения всего комплекса работ по КТПП создан технический центр (ТЦ).

Организационная структура и структура управления части ТЦ приведена на рис. 2,4. На рис.

2.5 показано место ТЦ в компьютеризированном сертифицированном производстве.

. у «

Руководитель технического центра

Отдел главного

конструктора (ОГК)

(главный конструктор)

Отдел технологической

подготовки производства

(ОТПП)

(главный технолог)

Отдел размножения и

хранения документации

(ОРиХДО

(начальник отдела)

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

несерийной продукции

(ОКНП)

(начальник отдела)

Бюро асинхронных

машин (начальник бюро)

Бюро изменений (начальник бюро)

Бюро рвдакционно-

издательских

работ(начальник бюро)

Коиструеторское

-бюро по проектированию

оснастки (начальник бюро)

Бюро сварочно-

эаготовительных и

штамповочных

работ

(начальник бюро)

Бюро механообработки' (начальник бюро)

Технический центр

Рис. 2.4. Функциональная структура подразделений ТЦ в ходе КТПП АД В ОАО имеется большой массив, насчитывающий более 150 наименований документов только эксплуатационной документации, к последним относятся паспорта, технические описания, формуляры, руководства по эксплуатации и т.п. документы на выпускаемые АД [54,55]. На рис.2.6 показана иерархия компонентов, участвующих в моделировании Профессиональной деятельности в компьютерной среде. Каждый из ниже лежащих уровней не зависит и не знает о реализации выше расположенных уровней.

ксп -

комп ыотеризированное сертифиц up ое an ное про изеодсгпе о для выпуска наукоемких изделий под заказ

ТЦ"- технический центр

КИП-комп мотерное \\ интегрированное / производство

АСК-автоматизированная система расчета и конструирования электрических машин

АСТГПТ-

автоматизированная

АСУГТ-

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

система

технологической

подготовки

п ро из вод ства

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

Технологическое оборудование

гдгег у^..*.^ч":-гУ1щг^щ

^

< -w₄ . ^.-^".г-^'.'м^а.-'^^ямвав^

Рис. 2.5. Место ТЦ в рамках компьютеризированного сертифицированного производства В результате анализа базы знаний по КТПП АД, имеющейся в ОАО, можно сделать следующие выводы:

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

2. Этот опыт нашел свое отражение в отраслевых стандартах и справочниках, где в явном виде нет алгоритмов и готовых рецептов решения задач КТПП, Есть некоторые правила и рекомендации, касающиеся отдельных примеров проектирования, использование которых защищает специалиста от серьезных просчетов.

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

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

1. Документ

2. Электронный шаблон документа

І~—і

3. Типовые методики формирования
документа

4. Экранные формы
5.События

6. Деловой процесс, использующий:

расчет по вычислительным зависимостям;

параметризацию графических заготовок;

выбор из меню;

редактирование и генерирацию графических решений;

заполнение формы с данными в диалоге;

отбор из таблиц по «ключу»;

утверждение или отклонение представленных решений.

7. Таблицы, содержащие:

формализованное техническое задание (только для чтения, одно на проект);

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

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

выходные результаты (запоняются после выполнения делового процесса);

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

8. Единое информационное пространство

в форме словаря понятий прикладной

области

9. Текущие значения, накопленные в ходе

выполнения проекта или заданные по

умолчанию

Рис. 2.6. Иерархия компонентов, участвующих в моделировании перехода от традиционной деятельности к компьютерной 2.6.2 Построение модели на примере технического центра

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

перемещения, но и как производящую единицу, обеспечивающую информационные решения,

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

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

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

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

Единая информационная среда предприятия

В настоящее время в условиях рыночной экономики обостряется конкурентная борьба производителей, что влечет за собой необходимость поиска резервов повышения эффективности производства, сокращения сроков создания наукоемкого изделия и в т.ч. сроков его проектирования, повышения его качества и надежности. Сегодня промышленные предприятия нуждаются в интегрированных решениях по управлению жизненным циклом изделия - от идеи до утилизации. Такие PLM -решения (от английского Product Lifecycle Management) включают в себя CAD, САМ, САЕ, PDM, средства визуализации, планирования процессов, управление документооборотом, производственными данными, качеством и др. При этом должна быть обеспечена интеграция на уровне данных и моделей физически разобщенных коллективов (заказчиков, разработчиков, поставщиков, партнеров, производственников, маркетинговых и сервисных служб и т.д.) и процессов, которые могут располагаться/ происходить не только в разных подразделениях производственных предприятий, но и на разных континентах [1-4].

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

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

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

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

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

Чтобы понять, как работает современное предприятие, необходимо понять не только бизнес-процессы, но также данные, системы, оргструктуру, цели бизнеса, ключевые показатели, изделия, риски, правила, интерфейсы, уровень квалификации персонала и т.д. Более того, недостаточно и изучение всего этого в отдельности. Все эти понятия имеют значение только тогда, когда они взаимосвязаны. Важны именно их взаимоотношения и взаимодействия, Это и есть моделирование бизнеса. Тогда при моделировании процессов будет происходить документирование, анализ и разработка структуры бизнес-процессов, их взаимосвязей с ресурсами, необходимыми для выполнения процессов, и среды, где эти процессы будут использованы [80].

Применение моделирования позволяет решить различные задачи: - визуализировать систему в ее текущем или желательном для нас состоянии; - определить структуру или поведение системы; - получить шаблон (решение, применимое в различных контекстах), позволяющий затем сконструировать систему; - документировать принимаемые решения, используя полученные модели. В большинстве изданий, посвященных объектно-ориентированному анализу и проектированию, довольно подробно представлены примеры использования данного подхода компьютерного моделирования банковских систем, систем электронной коммерции и розничной торговли. Это работы таких известных разработчиков сложных программных систем, как Гради Буч, Джим Коналлен, Дин Леффингуэлл, Дон Уидриг, Крэг Ларман. Что касается промышленных предприятий, то для сложных наукоемких изделий (особенно это актуально для предприятий при выполнения индивидуальных заказов) эти решения еще должны быть найдены и созданы или, по крайней мере, улучшены и развиты. Решению этой задачи и посвящена настоящая диссертация. Предметом компьютерного моделирования настоящей диссертации выступает деятельность производящего предприятия, связанная с совершенствованием управления координирования деятельности группы сотрудников в ходе подготовки производства наукоемких изделий, выполняемых по индивидуальным заказам в рыночных условиях. Компьютерное моделирование использовано для представления деятельности производящего предприятия от момента получения заказа до выпуска конструкторско-технологической документации, достаточной для организации производства наукоемкого изделия в условиях единичного производства. В качестве примера Б работе рассматривается организация командной деятельности по подготовке производства асинхронных электродвигателей (АД) большой, мощности (до 2 МВатт) на Сафоновском электромашиностроительном заводе (ОАО «СЭЗ»), Данный завод выбран в качестве типового представителя для решения поставленных задач.

В машиностроительной области одним из самых трудоёмких этапов в освоении нового типа изделия является коиструкторско-технологическая подготовка производства (КТПГТ). Именно поэтому на этом этапе и следует выявлять возможности снижения стоимости и сокращения времени выхода конкурентоспособного изделия требуемого уровня качества на рынок, А это значит, что необходимо пересмотреть и найти новые решения по организации командной деятельности «производящего предприятия». Здесь под «производящим предприятием» будем понимать связку «ТЦ + завод» (технический центр + завод) или «КБ + завод» (конструкторское бюро + завод). Поэтому задача совершенствования командной деятельности по подготовке производства на современном машиностроительном предприятии является актуальной [78],

Унифицированный процесс и Унифицированный язык моделирования (Unified Modeling Language— UML)

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

Унифицированный процесс компании Rational (Rational Unified Process — RUP) является примером специализированной версии унифицированного процесса, образованной за счет добавления элементов в настраиваемую структуру. "Rational Rose стала стандартом при разработке приложений и бизнес-моделировании", - сказал Роджер Оберг (Roger Oberg), вице-президент Rational [66]. UP широко использует унифицированный язык моделирования (Unified Modeling Language— UML). Основой UML является модель, способная в контексте процесса разработки программного обеспечения упростить реальность, что помогает команде проекта понять наиболее сложные аспекты программного обеспечения [12].

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

Rational Rose корпорации Rational Software считается сегодня лидирующей в мире CASE-системой, подъем продаж которой пришелся на период с 1996-го по текущий год. UML стал стандартным языком объектно-ориентированной разработки не без подачи Rational Software, которая не только выпускает программные продукты, где используется UML но и активно принимает участие в организации Object Management Group (OMG), занятой созданием и обновлением спецификаций языка UML и т, д.

Своеобразным признанием заслуг Rational Software стало включение усеченного варианта продукта Rational Rose в знаменитый пакет разработчика Microsoft Visual Studio. Правда, название поменялось с Rational Rose на Visual Modeler. Многие, используя Visual Modeler, так и не знают, с чем же на самом деле они работают. Выше уже упоминался ряд проблем на пути выпуска ПО. Вот что предлагает RUP для решения подобных проблем: 1. Выпускать программное обеспечение, пользуясь принципом промышленного подхода. То есть так, как поступают любые заводы и фабрики: определяя стадии, потоки, уточняя обязанности каждого участника проекта. Именно промышленный подход позволит достаточно оперативно выпускать новые версии ПО, которые при этом будут надежными и качественными. 2. Расширять кругозор специалистов для снятия барьеров. Ведь в подавляющем большинстве случаев специалисты из разных отделов просто говорят на разных языках. Соответственно, снятие языкового барьера должно вести к ускорению работы над программным обеспечением. 3. Использовать итеративную разработку вместо каскадной, существующей в настоящее время. Принцип итерации заключается в повторяемости определенной последовательности процессов с целью доведения элемента до безошибочного состояния. 4. Обязательное управление требованиями. Всем известно, что по ходу разработки в систему вносятся изменения (самой группой разработчиков или заказчиком - неважно). Rational предлагает мощную систему контроля управления требованиями: их обнаружение и документирование, поддержку соглашений между разработчиками и заказчиками, 5. Полный контроль всего происходящего в проекте посредством создания специальных архивов. 6. Унифицированный документооборот, приведенный в соответствие со всеми известными стандартами. Это значит, что каждый этап в разработке сопровождаются унифицированными документами, которыми должен пользоваться каждый участник проекта. 7. Использование визуального моделирования. 8. Применение не только механизмов объектно-ориентированного (00) программирования, но и 00 мышления и подхода. UML - это язык для визуализации, специфицирования, конструирования и документирования артефактов программных систем. Артефакт -диаграмма, документ, модель, закон и т. д. - нечто, описывающее определенное понятие предметной области. Как и любой БИВЛЬОТЕКА язык, UML состоит из словаря и правил, позволяющих комбинировать входящие в него слова и получать осмысленные конструкции. В языке моделирования словарь и правила ориентированны на концептуальное и физическое представление системы (рис. 2.2). Руководствуясь стандартом UML, создается несколько представлений, в каждом из которых основное внимание уделяется различным аспектам. Наиболее распространенные представления показаны на рис, 2.1 и 2,2, Представление вариантов- использования призвано сконцентрировать внимание на описании функциональности и поведении системы. Логическое представление описывает структуру системы, Компонентное представление указывает, как логические элементы «вписываются» в конечный продукт. Представление размещения описывает, как программные компоненты привязаны к аппаратному обеспечению. Итак, при проектировании программной системы очень полезно сначала создать модели, отражающие важные детали проблемы из реальной жизни (в нашем случае - из производственной практики конкретного предприятия), для решения которой и конструируется информационная система. Такие модели должны содержать строго связанные элементы и необходим язык, с помощью которого можно с различных точек зрения описать представления архитектуры системы на протяжении цикла ее разработки.

Поскольку сложное целое нельзя понять, гладя на него лишь с одной стороны, в UML определено много разных диаграмм, которые позволяют сосредоточиться на различных аспектах моделируемой системы. Т.е. достаточно полная модель системы допускает некоторое число взаимосвязанных представлений, каждое из которых отражает некоторый аспект поведения системы или ее структуры. При этом статическое и динамическое представления системы являются наиболее общими представлениями и в свою очередь могут подразделяться на другие более частные представления (рис. 2.2). Статические модели описывают структурные свойства, в то время как динамические - поведенческие свойства системы[29].

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

Существующая схема проведения работ л о КТПП электрических машин

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

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

Итак, UML (Rational Rose) используется в начальной стадии: Для описания модели вариантов использования бизнес-процесса, для выявления ролей и взаимосвязей в организации (предприятии), S для обеспечения исчерпывающего представления о том, какие изменения нужно внести в сами бизнес-процессы, чтобы успешно реализовать новую систему. Определение вариантов использования и действующих лиц. (UML) можно применять для документирования этих вариантов использования и действующих лиц, а таюке для создания диаграмм, показывающих связи между ними. Полученные диаграммы вариантов использования должны давать достаточно полное представление о свойствах системы (в данном случае о деятельности подразделения): 1) С помощью диаграмм вариантов использования потребители и менеджеры проекта получат общее представление о системе и смогут принять решение о путях совершенствования. 2) С помощью диаграмм вариантов использования и документации менеджеры проекта смогут разделить проект на отдельные управляемые задачи. 3) Из документации по вариантам использования аналитики и потребители смогут понять, что будет делать готовая система. Одно из преимуществ данного подхода к моделированию бизнес-процесса состоит в простоте описания зависимостей между моделями бизнес-процесса и компьютерной системой. Это повышает производительность процесса разработки программного обеспечения, а также помогает удостовериться, что система способна удовлетворить реальные бизнес-потребности. Преобразование одной модели в другую можно кратко описать следующим образом: Сотрудники предприятия (ТЦ) становятся актерами (исполнителями) разрабатываемой системы, Описанные для сотрудников предприятия (ТЦ) варианты использования можно автоматизировать; это поможет выявить прецеденты (варианты использования) системы и определить необходимые функциональные возможности. Сущности бизнес-процесса поддерживаются системой и помогают выявить классы сущностей при анализе модели системы. Прецедент описывает последовательность действий, выполняемых системой с целью предоставить полезный результат конкретному исполнителю (актеру). Другими словами, прецеденты описывают взаимодействие между пользователем и системой, Уделяя основное внимание тому, что система "делает" для пользователя. Кроне того, поскольку действия описываются последовательно, легко "проследить действие" и понять, что делает система.

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

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

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

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

Практически все мировые производители CASE-средств заявили о реализации поддержки UML в ближайших версиях своих продуктов. Но уже сегодня существуют множество CASE-средств, автоматизирующих процесс анализа и проектирования в UML (Rational Rose, Paradigm Plus, Select Enterprise, Microsoft Visual Modeler for Visual Basic и др.), поддерживающих множество языков программирования, таких, как C++, Java, Delphi, Power Builder, Visual Basic, Centura, Forte, Ada, Smalltalk, а также позволяющих осуществлять генерацию базы данных для большинства из существующих SQL-серверов. Модели, разработанные в UML, позволяют значительно упростить процесс кодирования и направить усилия программистов непосредственно на реализацию системы.

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

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

При этом диаграмма может утратить свою полезность для пользователей, но станет важна для разработчиков, тестировщиков и остальных участников команды проекта. На рис. 3.14 показана диаграмма последовательности для прецедента «Выбрать базовый образец», полученная на втором этапе. В прил. 1 на рис. 1 приведен пример кооперативной диаграммы для прецедента «Выбрать базовый образец». Здесь представлена вся та информация, которая была и на диаграмме последовательности, но кооперативная диаграмма по-другому описывает поток событий. Из нее легче понять отношения между объектами, однако труднее уяснить последовательность событий. По этой причине часто для сценария создают диаграммы обоих типов. Хотя они служат одной и той же цели и содержат одну и ту же информацию, но представляют ее с различных точек зрения. Для того чтобы провести процесс генерации программного кода, необходимо все элементы модели именовать на английском языке. Эти имена входят в словарь программных конструкций. Все диаграммы, выполненные с использованием английского языка, помещены в Приложение 1 настоящей диссертации. На рис.2 приложения 1 показана диаграмма последовательности для прецедента «Выбрать базовый образец», полученная после данного преобразования. Диаграммы последовательности в рамках унифицированного процесса разработки используются командой разработчиков для распределения операций между классами, В прил. 1 на рис, 3 приведен пример соответствующей кооперативной диаграммы для прецедента «Выбрать базовый образец». Основными элементами модели анализа в пределах унифицированного процесса являются классы анализа. Эти классы выявляются с помощью диаграмм взаимодействия, описанных выше. Поэтому идея пакета классов естественно реализуется в виде «пакета анализа», содержащего классы анализа и диаграммы взаимодействия. На рис. 4 прил. 1 частично представлено содержимое пакета анализа под названием Анализ Нач. отдела (для прецедента «Выбрать базовый образец»). Со временем команда разработчиков должна расширить этот пакет, включив в него диаграммы взаимодействия и классы анализа, связанные с другими прецедентами Нач. отдела (Глава 4), Итак, было рассмотрено взаимодействие объектов системы. Теперь рассмотрим некоторые элементы логического представления модели. Кроме диаграмм взаимодействия в логическое представление входят: Классы, Диаграммы классов, Диаграммы вариантов использования, Атрибуты и операции, Диаграммы состояний. Модель проектирования содержит классы, которые в рамках унифицированного процесса называются классами проектирования. Проследим кратко формирование таких классов [3,12-16]. Класс проектирования должен содержать полный набор операций. В прил. 1 на рис. 5 показана диаграмма классов для прецедента «Выбрать базовый образец». Далее необходимо выявить атрибуты. (Словарь) Атрибут - это фрагмент информации, связанный с классом. Модель проектирования — это пакет, состоящий из классов проектирования, интерфейсов классов и подсистем, а также реализаций прецедентов на уровне проектирования. Команда разработчиков обычно начинает определять классы на относительно высоком уровне абстракции. В начале этапа проектирования классы уточняются, а затем формируются классы анализа. С увеличением количества деталей в контексте унифицированного процесса определяются классы проектирования. Далее будут добавлены классы проектирования, приведенные на диаграмме последовательности для прецедента «Выбрать базовый образец». Операции классов не были изображены на исходных диаграммах классов, приведенных в прил. 1. Описание прецедента порождает диаграмму последовательности, на которой выполняется распределение обязанностей между объектами, упомянутыми в описании прецедентов. Такие обязанности реализуются через операции классов и методы указанных классов. В этом и состоит разработка на основе прецедентов. Рассмотрим подробно еще один прецедент (вариант использования) - «Оценить требования заказчика». В при л. і на рис. 6 показана диаграмма последовательности для прецедента «Оценить требования заказчика», полученная на первом этапе. Далее сообщения соотносятся с операциями, а объекты должны быть соотнесены с классами. В прил. 1 на рис, 7 показана диаграмма последовательности для прецедента «Оценить требования заказчика», полученная на втором этапе. В прил. 1на рис. 8 прил. 1 приведен пример кооперативной диаграммы для прецедента «Оценить требования заказчика». Этот подход ориентирован не на организационную структуру, а на бизнес-процессы. Вернемся к первому рисунку этой главы (рис. 3.1). Бизнес-процессы, Б отличие от организационной структуры, меняются реже и, как правило, основных бизнес-процессов на предприятии немного. Это наиболее перспективный подход, основными чертами его являются: широкое делегирование полномочий и ответственности исполнителям; сокращение количества уровней принятия решения; сочетание принципа целевого управления с групповой организацией труда; повышенное внимание к вопросам обеспечения качества продукции или услуг, а также работы предприятия в целом; автоматизация технологий выполнения бизнес-процессов.

Для изучения бизнес-процессов необходим анализ текущего состояния [89-91, 94, 95]. Дело в том, что очень часто общая производительность оборудования и приложений по каким-то причинам перестает удовлетворять предъявляемым потребностям. При этом имеется некоторое ощущение, что в системе есть "узкое место", которое не дает возможности всем остальным компонентам работать в полную силу. Требуется обнаружить это "узкое место" и предложить варианты улучшения ситуации.

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

Во главе средств разработки нового поколения стоят методологии моделирования реального мира [92,93]. Они позволяют донести знания о предметной области, полученные на стадии обследования до стадии реализации. Информация должна быть понятна как заказчику, так и разработчику, иначе будет получена неадекватная система. Методология позволяет формализовать информацию, полученную из уст заказчика, выявить в ней закономерности и противоречия. Эта идея позаимствована из других областей науки и техники (например, разработка чертежа перед постройкой некоторого механизма), однако для программного обеспечения существует очень много нюансов, затрудняющих стадию проектирования. Например, конечный продукт не имеет материальной основы, следовательно, на стадии проектирования невозможно описать полностью все характеристики продукта, т.к. его полное описание — есть сам продукт. В нашем случае ситуация сложнее, проект системы должен правильно отражать также бизнес-процесс некоторого предприятия. Модель нужна заказчику как представление нашего понимания его бизнес-процесса, а нам — как формальное описание функций системы [111,112]. На ранних стадиях разработки преобладают функциональные диаграммы, на поздних диаграммы классов и их состояний.

Похожие диссертации на Разработка компьютерной модели функционирования предприятия в условиях единичного производства (На примере ОАО "Сафоновский электромашиностроительный завод")

Автоматизация системы управления и контроля за бизнес-процессами предприятия на основе системы сбалансированных показателей (На примере ОАО "Сафоновский электромашиностроительный завод") Бродский Леонид Львович

Разработка модели и алгоритмов функционирования газлифтной скважины как объекта системы оперативного управленияБарашкин, Роман Леонардович

Разработка моделей и алгоритмов функционирования единой информационной среды для автоматизации производства навигационной аппаратурыКоновалов Михаил Александрович

Исследование и разработка интегрированной системы динамических моделей функционирования и управления производствомНизамутдинов, Олег Беланович

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

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

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

Разработка алгоритма оптимального управления и планирования отдельными участками металлургических заводов Ипатова Эльмира Рафиковна

Исследование и разработка моделей и средств поддержки принятия организационных решений в нечетком аспектеШифрин Борис Маркович

Разработка модели данных автоматизированной системы управления технической подготовкой многономенклатурного производстваБредихин, Алексей Вячеславович