Презентация на тему: Технологии информационной поддержки жизненного цикла объектов аэрокосмической

Технологии информационной поддержки жизненного цикла объектов аэрокосмической техники
Зачем МНЕ этот курс?
Лекция № 1. Жизненный Цикл ОАКТ
Технологии информационной поддержки жизненного цикла объектов аэрокосмической
IDEF0 – ICOM -блок
модель ЖЦ АКТ
модель ЖЦ АКТ
модель ЖЦ АКТ
Технологии информационной поддержки жизненного цикла объектов аэрокосмической
Лекция № 2. Виды автоматизированных систем
Технологии информационной поддержки жизненного цикла объектов аэрокосмической
Иерархия задач управления предприятием
Технологии информационной поддержки жизненного цикла объектов аэрокосмической
ИТ в ЖЦ
ИТ в ЖЦ
CALS
Концептуальна модель CALS
CALS
Лекция № 3. Подходы к классификации АС
Классификация «по мощности»
«Легкие» системы
«Средние» системы
«Тяжелые» системы
Технологии информационной поддержки жизненного цикла объектов аэрокосмической
Лекция № 4. Системы УПРАВЛЕНИЯ ПРОЕКТНЫМИ ДАННЫМИ
Сложность управления проектными данными
Оценка информационной емкости объекта проектирования
Лидеры CAD / CAM / CAE / PDM в машиностроении
Этапы развития систем управления проектными данными
Классификация систем управления проектными данными
Функции систем Product Data Management (PDM)
Функции систем PDM
Функции систем PDM
Функции систем PDM
Функции систем PDM
Функции систем PDM
Функции систем PDM
Функции систем PDM
Функции систем PDM
Функции систем PDM
Лекция № 5. Форматы обмена данными между САПР
Собственные форматы САПР
Формат геометрических моделлеров
Стандартные форматы
Стандартные форматы
Конверторы
Лекция № 6. Управление жизненным циклом продукции
САПР и БД
Технологии информационной поддержки жизненного цикла объектов аэрокосмической
Взаимо- действие САПР с АСУП
ERP
Лекция № 7. Модели жизненного цикла
Каскадная модель
Модифицированная каскадная модель
V-образная модель
Спиральная модель
Технологии информационной поддержки жизненного цикла объектов аэрокосмической
Итеративная модель
Итеративная модель
Модель CMM
Модель CMM I
Лекция № 8. МЕТОДОЛОГИИ РАЗРАБОТКИ ПО
Классификация методологий разработки ПО
SCRUM
SCRUM
Экстремальное программирование
Экстремальное программирование
KANBAN
Dynamic System Development Method
Microsoft Solutions Framework
Rational Unified Process
Rational Unified Process
Лекция № 9. UML
Диаграмма сценариев использования
Диаграмма сценариев использования
Диаграмма сценариев использования
Диаграмма сценариев использования
Диаграмма состояний
Диаграмма состояний
Диаграмма последовательности
Диаграмма последовательности
Диаграмма деятельности
Диаграмма классов
Лекция № 10. CASE и подходы к проектированию
CASE
SADT
IDEF0
IDEF 1, IDEF1X
IDEF 3
DFD
ER- модель
Основные понятия ER- диаграмм
Виды обеспечения
1/93
Средняя оценка: 4.6/5 (всего оценок: 91)
Код скопирован в буфер обмена
Скачать (4876 Кб)
1

Первый слайд презентации: Технологии информационной поддержки жизненного цикла объектов аэрокосмической техники

Лектор: к.т.н., старший преподаватель кафедры 105 Каратанов Александр Владимирович

Изображение слайда
2

Слайд 2: Зачем МНЕ этот курс?

Обязанности: участие в командной разработке и внедрении бизнес-решений (информационных систем по управлению данными) на базе PLM-технологий; проведение обследований, анализ требований заказчика и формирование ТЗ; настройка и развертывание внедряемых решений в соответствии с ТЗ; тестирование и разработка пользовательской документации; консультирование пользователей и сопровождение систем. Специалист по внедрению PLM/PDM Уровень зарплаты Город Требуемый опыт работы от 90 000 руб. Москва, Петровско-Разумовская 1–3 года Приветствуется: наличие сертификатов по работе и администрированию PLM/PDM систем; опыт настройки и тестирования интеграции между различными информационными системами; знание методологий (например, IDEF0/IDEF3/IDEF1X) и владение инструментами моделирования (ARIS); знание основ программирования на Java.

Изображение слайда
3

Слайд 3: Лекция № 1. Жизненный Цикл ОАКТ

Жизненный цикл изделия (ЖЦИ или ЖЦ, жизненный цикл продукции) — совокупность взаимосвязанных процессов последовательного изменения состояния продукции от начала исследования и обоснования разработки до прекращения эксплуатации изделия, применения (хранения) материала [Р 5.605.80-93, ДСТУ 3278-95]. Альтернативное определение Жизненный цикл изделия — совокупность процессов, выполняемых от момента выявления потребностей общества в определенной продукции до момента удовлетворения этих потребностей и утилизации продукта [Стандарт ИСО 9004-1-94. Управление качеством и элементы системы качества (п.5.1.1)]. *ОАКТ – объекты аэрокосмической техники

Изображение слайда
4

Слайд 4

Альтернативное определение 2 Жизненный цикл изделия — совокупность всех процессов в период существования изделия (технической системы). Взаимосвязь этих процессов может быть представлена спиралью качества. Спираль качества – модель взаимосвязанных видов деятельности, влияющих на качество продукции или услуг на различных стадиях от определения потребностей до оценки их удовлетворения. Эти виды деятельности ( см. рис.): 1 - маркетинг и изучение рынка ; 2 - разработка технических требований и проектирование продукции ; 3 - технологическая подготовка производства ; 4 - материально-техническое снабжение; 5 - производство ; 6 - контроль и испытания ; 7 - упаковка и хранение; 8 - реализация и распределение ( поставка ) продукции; 9 - монтаж и эксплуатация ; 10 - техническое обслуживание ; 11 - утилизация после использования. Фазы 2, 3, 5, 6, 9, 10 относятся к сфере инженерной деятельности ( Engineering ); фазы 1, 4, 7, 8, 11 - к управленческой деятельности ( Management ). Engineering – это процесс практической реализации результатов научной деятельности.

Изображение слайда
5

Слайд 5: IDEF0 – ICOM -блок

Процесс создания ОАКТ может быть описан в терминах входов, выходов, управлений и механизмов реализации функций и задач, т.е. представлен функциональными схемами стандарта IDEF 0 как композиция ICOM -блоков. В правом нижнем углу блока указывается его имя. Имя состоит из буквы и числа, которое обозначает положение блока в модели. Например: А21 – означает, что это первый блок декомпозиции второго блока. Для концептуальной модели имя будет обозначаться так: А-0. Выход из одного ICOM- блока должен обязательно присутствовать на входе другого. А-0 Пример концептуальной модели для процесса проектирования ОАКТ.

Изображение слайда
6

Слайд 6: модель ЖЦ АКТ

2. Разработка – стадия ЖЦ, заключающаяся в изменении состояния продукции – от формулирования требований технического задания на выполнение опытно-конструкторских работ по созданию продукции до воплощения их в новых опытных образцах, в новых материалах. 3. Производство – стадия ЖЦ, на которой осуществляются организация и промышленное изготовление продукции. Включает в себя постановку на производство, установившееся производство и снятие с производства. 4. Эксплуатация – стадия ЖЦ, на которой реализуется, поддерживается и восстанавливается качество изделия. Эксплуатация изделия включает в себя в общем случае: ввод в эксплуатацию, использование, хранение, транспортирование, техническое обслуживание, текущий и средний ремонт, прекращение эксплуатации, списание (передачу, утилизацию, уничтожение). 5. Капитальный ремонт – стадия ЖЦ, предполагающая ремонт, выполняемый для восстановления исправности и полного или близкого к полному восстановлению ресурса изделия с заменой или восстановлением любых его частей, включая базовые. В соответствии со стандартами ДСТУ 3278-95 и ГОСТ Р 15.000-94 необходимо выделить следующие стадии жизненного цикла АТ : 1. Исследование и обоснование разработки – стадия ЖЦ от возникновения замысла до обоснования возможности и целесообразности создания изделий и материалов.

Изображение слайда
7

Слайд 7: модель ЖЦ АКТ

Будем полагать, что понятия процессов разработки и проектирования синонимичны, и что это процесс составления описания, необходимого для создания еще не существующего объекта на основе первичного описания этого объекта, или алгоритма его функционирования, или алгоритма процесса. В процессе разработки при затрате максимум 20..25% времени от всей работы и не более 5..10% средств принимается 75..80% основных решений по проекту (технических и организационных). В соответствии со стандартами ГОСТ 2.103-68, ДСТУ 3974-2000 и ГОСТ Р 15.201-2000, а также работой Егера «Проектирование самолетов» можем выделить ряд работ, проводимых на стадиях «исследование и обоснование разработки» и «разработка». Исследование и обоснование разработки – стадия, результатом которой является техническое задание, формулирующее требования к объекту проектирования. Разработку ТЗ предваряют предпроектные исследования, в ходе которых проводятся научно-исследовательские работы (НИР). Этот комплекс работ обычно называют « внешним проектированием ». Разработка включает в себя: 1. Предварительное проектирование – стадия разработки технического предложения, в котором содержатся уточненные требования к объекту проектирования. 2. Эскизное проектирование, на котором происходит определение схемных и конструктивных решений изделия, дающих общее представление о его устройстве и принципах работы, результат – эскизный проект. 3. Техническое проектирование – стадия, позволяющая определить окончательные конструктивные решения, дающие полное представление о конструкции изделия, результат технический проект. 4. Рабочее проектирование – последняя стадия проектирования: разработка полного комплекта конструкторской документации для изготовления и испытания изделия, называемого рабочей конструкторской документацией. Стадию разработки обычно называют « внутренним проектированием », а вместе с внешним они образуют цикл опытно-конструкторских работ.

Изображение слайда
8

Слайд 8: модель ЖЦ АКТ

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

Изображение слайда
9

Слайд 9

Изображение слайда
10

Слайд 10: Лекция № 2. Виды автоматизированных систем

Автоматизированная система (АС) – система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций [ГОСТ 34.003-90. Автоматизированные системы. Термины и определения ]. Отдельные фазы жизненного цикла продукции обеспечиваются различными автоматизированными системами. Эти системы можно подразделить на два обширных класса: – системы автоматизации проектирования (САПР, или по определению международных стандартов ECSS «technical information systems - CAD/CAM, analysis packages»); – системы автоматизации управления (АСУ, или по определению ECSS «management information systems - finance, planning etc.») [ECSS-E-40A, p.7]. Системы автоматизированного проектирования (САПР) подразделяются на САПР конструкций изделий (САПР-К) и САПР технологий (САПР-Т, они же – автоматизированные системы технологической подготовки производства, АСТПП) – они применяются на стадиях разработки и производства, а этап научно-исследовательских работ (НИР) и обеспечивают АСНИ. [ДСТУ 2226-93. Автоматизовані системи. Терміни]: АСНИ (автоматизированные системы научных исследований) - АС, предназначенная для проведения научных исследований и экспериментов и управления ими. САПР - АС, предназначенная для автоматизации процесса проектирования изделия, конечным результатом которого является комплект проектно-конструкторской документации, достаточной для изготовления и последующей эксплуатации объекта проектирования. АСТПП - АС, предназначенная для автоматизации проектирования технологических процессов и подготовки производства.

Изображение слайда
11

Слайд 11

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

Изображение слайда
12

Слайд 12: Иерархия задач управления предприятием

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

Изображение слайда
13

Слайд 13

Изображение слайда
14

Слайд 14: ИТ в ЖЦ

PLM-система (англ. product lifecycle management ) — прикладное программное обеспечение для управления жизненным циклом продукции. CAD ( Computer Aided Design ) – САПР, предназначенная для создания геометрической модели и конструкторской документации. CAE ( Computer - Aided Engineering ) – система автоматизации инженерных расчётов (анализа и симуляции физических процессов, моделирования и   оптимизации изделия). CAM ( Computer - Aided Manufacturing ) – система технологической подготовки производства изделий, обеспечивающая автоматизацию программирования и управления оборудованием с ЧПУ (числовым программным управлением) или ГАПС (гибких автоматизированных производственных систем). Русским аналогом термина является АСТПП (автоматизированная система технологической подготовки производства). Управление цепями поставок (англ. supply chain management, SCM ) — управленческая концепция и организационная стратегия, заключающаяся в интегрированном подходе к планированию и управлению всем потоком информации о сырье, материалах, продуктах, услугах, возникающих и преобразующихся в логистических и производственных процессах предприятия, нацеленном на измеримый совокупный экономический эффект (снижение издержек, удовлетворение спроса на конечную продукцию).

Изображение слайда
15

Слайд 15: ИТ в ЖЦ

CALS – информационная поддержка изделия на всех этапах жизненного цикла ( Continuous Acquisition and Life - Cycle Support ). ERP – система планирования и управления ресурсами предприятия ( Enterprise Resource Planning ). MRP – система планирования производства и требований к материалам ( Manufacturing Requirement Planning ). MES – производственные исполнительные системы ( Manufacturing Executive System ). PDM – система управления проектными данными ( Product Data Management ). S&SM – Sales and Service Management, системы управления реализацией и послепродажным обслуживанием. SCADA – Supervisory Control And Data Acquisition, АСУТП. CNC – Computer Numerical Control, ЧПУ. CPC – Collaborative Product Commerce. MES, SCM, CRM, ERP, MRP-II – автоматизированные системы управления производством. SCADA, CNC – автоматизированные системы управления оборудованием и технологическими процессами.

Изображение слайда
16

Слайд 16: CALS

Годы Определение термина CALS 1985 Computer aided of logistics support – компьютерная поддержка логистических систем 1988 Computer aided acquisition and lifecycle – компьютерные поставки и поддержка жизненного цикла 1993 Continual aided acquisition and lifecycle – поддержка непрерывных поставок и жизненного цикла 1995 Commerce at light speed – бизнес в высоком темпе 1997 Continuous acquisition and lifecycle support – непрерывная поддержка жизненного цикла продукта CALS – концепция, объединяющая принципы и технологии информационной поддержки жизненного цикла продукции на всех его стадиях, основанная на использовании ЕИП, обеспечивающая единообразные способы управления процессами и взаимодействия всех участников этого цикла: заказчиков продукции (включая государственные учреждения и ведомства), поставщиков (производителей) продукции, эксплуатационного и ремонтного персонала, реализованная в соответствии с требованиями системы международных стандартов, регламентирующих правила указанного взаимодействия преимущественно посредством электронного обмена данными. CALS

Изображение слайда
17

Слайд 17: Концептуальна модель CALS

Жизненный цикл изделия ИПИ-принципы ИПИ-технологии Основные ИПИ-принципы : анализ и реинжиниринг бизнес - процессов (business-processes analysis and reengineering); безбумажный обмен данными ( paperless data interchange ) с использованием электронно-цифровой подписи (ЭЦП); системная информационная поддержка ЖЦИ на основе использования единого информационного пространства (ЕИП), обеспечивающая минимизацию затрат в ходе ЖЦ; информационная интеграция за счет стандартизации информационного описания объектов управления; разделение программ и данных на основе стандартизации структур данных и интерфейсов доступа к ним, ориентация на готовые коммерческие программно-технические решения ( commercial of the shelf ), соответствующие требованиям стандартов; параллельное проектирование ( concurrent engineering – параллельный инжиниринг).

Изображение слайда
18

Слайд 18: CALS

а Различия между PLM (a) и CALS (б) подходами в создании ЕИП б

Изображение слайда
19

Слайд 19: Лекция № 3. Подходы к классификации АС

Классификация по типам

Изображение слайда
20

Слайд 20: Классификация «по мощности»

Традиционная (наиболее популярная) классификация САПР по функциональным возможностям («по мощности») предполагает выделение трех классов систем – «легких», «средних» и «тяжелых».

Изображение слайда
21

Слайд 21: Легкие» системы

Обеспечивают автоматизацию одного из этапов подготовки производства (обычно оформление технической документации – чертежей и технологических карт, или подготовку управляющих программ для 2-2.5-координатной обработки). Средства функционального проектирования неразвиты, обычно представлены модулями кинематического и динамического анализа плоских механизмов. Примеры: CAD-системы – AutoCAD (до версии 13), ADEM/CAD (до версии 3), T-FLEX CAD 2D, КОМПАС-График (2D), SprutCAD 2D и др., в последнее время - MechaniCS, ElectriCS, TechnologiCS; CAM-системы – NC Tool, ADEM/NC (до версии 3), T-FLEX ЧПУ 2D и др. CAE-системы – Working Model 2D (анализ механизмов). Условия эффективного применения: • несложная продукция; • разработки в отдельных подразделениях ведутся независимо (т.е. нет необходимости в системе PDM); • используется традиционная схема документооборота (т.е. нет необходимости в автоматизации делопроизводства); • документирование производится главным образом на бумажных носителях.

Изображение слайда
22

Слайд 22: Средние» системы

Обеспечивают автоматизацию нескольких взаимосвязанных этапов подготовки производства. Могут содержать средства как функционального проектирования ( CAE ), так и конструкторской ( CAD ) и технологической ( CAM ) подготовки производства. Могут быть реализованы либо как интегрированные пакеты, либо как функционально-независимые программные продукты на основе единой структуры данных (в том числе - в виде набора модулей, разработанных партнерами разработчика головного модуля). Примеры : CAD -системы – SolidWorks, SolidEdge, Autodesk Mechanical Desktop, ADEM / CAD (от версии 3), T - FLEX CAD 3 D, КОМПАС 3 D ; CAM -системы – SolidCAM, EdgeCAM, ADEM / NC (от версии 3), Гемма 3 D, T - FLEX ЧПУ 3 D, SprutCAM и др. CAE- системы – Design Space (ANSYS AutoFEA), Visual NASTRAN, CosmosWorks, Dynamic Designer (Motion, Thermal,...), T-FLEX / ИСПА и др. К системам среднего класса относятся также разработанные в конце 90-х гг. «облегченные» версии мощных систем – Prelude ( EUCLID ), PT / Products ( Pro / Engineer ), UG / Creator ( Unigraphics ). Условия эффективного применения: высокотехнологичная продукция средней сложности (например, современная бытовая техника); предусмотрена постепенная реорганизация системы управления предприятием (т.е. возможна автоматизация делопроизводства и использование систем PDM / TDM ); планируется поэтапное финансирование (т.е. требуется постепенное расширение функций системы). Системы этой группы по своим возможностям непрерывно приближаются к системам высокой мощности.

Изображение слайда
23

Слайд 23: Тяжелые» системы

Обеспечивают автоматизацию всех этапов подготовки производства. К этой категории относятся многофункциональные интегрированные системы универсального назначения, а также специализированные автономные комплексы инженерного анализа ( CAE ). Некоторые модули этих систем также являются партнерскими разработками (например, встроенные модули анализа часто являются сокращенными версиями автономных CAE -систем). Примеры : Интегрированные CAE / CAD / CAM -системы – Unigraphics, Pro / Engineer, CATIA, Euclid (ныне развитие системы прекращено), CADDS -5 (в 1998 г. поглощена PTC ), I - DEAS (в 2001 г. поглощена UG ). Примыкают к этой группе системы Cimatron, MicroStation. Автономные CAE -системы – ANSYS, NASTRAN, ABAQUS, LS - Dyna, MARC, Star - CD и др. Условия эффективного применения: высокотехнологичная особо сложная продукция либо наличие концепции нового класса изделий; коллективная работа над проектом, включая параллельное проектирование; наличие подготовленных кадров; наличие современного производственного оборудования.

Изображение слайда
24

Слайд 24

Изображение слайда
25

Слайд 25: Лекция № 4. Системы УПРАВЛЕНИЯ ПРОЕКТНЫМИ ДАННЫМИ

Замечание [Норенков]: Особенность большинства системных сред САПР машиностроения – системы PDM объединяют функции управления данными и управления процессом проектирования (DesPM). Система управления проектными данными ( PDM – Product / Project Data Management ) обеспечивает хранение данных, доступ к ним, защиту информации, управление конфигурацией изделия (ведение версий проекта и внесение изменений), создание спецификаций и т.п. Может быть интегрирована с системой управления процессом проектирования DesPM. Система управления процессом проектирования ( DesPM – Design Process Management ) обеспечивает слежение за состоянием проекта, координацию и синхронизацию параллельной работы исполнителей. Обычно включает средства маршрутизации ( Workflow ) – построения маршрутов прохождения проектных документов (согласование, утверждение и т.п.). Подсистема управления методологией проектирования (может входить в состав DesPM ) предназначена для построения маршрута проектирования (последовательности проектных процедур) на основе предварительного описания задачи. Должна основываться на базе знаний, включающей И-ИЛИ-граф объекта проектирования, описания проектных процедур и типовые фрагменты маршрутов проектирования, соответствие между процедурами и прикладными программами.

Изображение слайда
26

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

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

Изображение слайда
27

Слайд 27: Оценка информационной емкости объекта проектирования

Работа с геометрической моделью самолета (общей сборки) требует около 8 Гбайт ОЗУ (для вывода неполной модели – фюзеляж, одна консоль крыла с двигателем, авионика, шасси – потребовалось 3,6 Гбайт). 32-разрядная архитектура допускает адресацию лишь до 4 Гбайт. Т.е. назрел переход на 64-разрядную архитектуру – версия CATIA для такой техники уже выпущена. Среди всех PDM-систем только три способны работать с объектом такой сложности, как самолет – ENOVIA, TeamCenter и Windchill. АНТК вынужден вести проект машины сразу в трех CAD-системах: CADDS-5, CATIA (собственные) и Unigraphics (Воронежский завод). К тому же приходится обеспечивать синхронизацию данных между двумя PDM – ENOVIA и Optegra. [Долгих И.В., АНТК, сентябрь 2005 г.] : модель самолета Ан-148 состоит из 3,5 млн. деталей, из них 65 тыс. оригинальных, в т.ч. 50 тыс. механообрабатываемых.

Изображение слайда
28

Слайд 28: Лидеры CAD / CAM / CAE / PDM в машиностроении

Сложность управления проектными данными обусловлена следующими особенностями САПР [Норенков И.П., Основы автоматизированного проектирования, 2002] : Компания Dassault Systems Siemens PLM Software PTC Autodesk Верхний уровень CATIA V 6 R 2 013x Unigraphics NX 9.0 Pro/ENGINEER Wildfire 4.0 - Ядро CNEXT Parasolid Granite One - Ср. уровень Solid Works 201 5 Solid Edge ST6 Pro/Desktop 8 Inventor 2015 Ядро Parasolid Parasolid - ACIS PDM ENOVIA SmarTeam V5R19 Teamcenter 10 Windchill 10.2

Изображение слайда
29

Слайд 29: Этапы развития систем управления проектными данными

Изображение слайда
30

Слайд 30: Классификация систем управления проектными данными

Появлению полнофункциональных систем управления проектированием предшествовало использование систем управления документацией Technical Document Management ( TDM ) – документо -ориентированных систем (т.е. базирующихся на структуре документа). В отличие от них, системы Product Data Management ( PDM ) базируются на составе изделия, хотя одновременно обеспечивают и управление документацией. Состав функций этих систем постоянно расширяется, появляются их новые подклассы с новыми наименованиями, например: cPDM – Collaborative Product Definition Management; cPLM – Collaborative Product Lifecycle Management; cPLS – Collaborative Product Lifecycle Support; Это системы, «производные от PDM », но с дополнительными функциями – управление данными в течение всего жизненного цикла изделия при совместной работе разнопрофильных групп пользователей. Предприятия России, Беларуси, Украины и других стран СНГ используют также следующие системы: Search компании Интермех (Минск), T - FLEX DOCs компании Топ Системы, ЛОЦМАН: PLM компании АСКОН, Lotsia PDM Plus компании Лоция Софт, SWR - PDM компании SolidWorks - Russia, PDM STEP Suite Центра прикладной логистики, APPIUS PDM компании APPIUS и некоторые другие. К числу наиболее распространенных PDM-систем относятся: ENOVIA – разработка компаний IBM и Dassault Systemes, Teamcenter компании Unigraphics Solutions, ныне Siemens PLM, Windchill и Pro / Intralink компании Parametric Technology Corp., SmarTeam компании Smart Solutions (дочернее предприятие компании Dassault Systemes ) PDMWorks компании SolidWorks

Изображение слайда
31

Слайд 31: Функции систем Product Data Management (PDM)

1. Управление конфигурацией (структурой) изделия ( Configuration Management ) : 1.1) генерация спецификаций (аналогична функциям генераторов спецификаций CAD -систем); 1.2) синхронизация данных CAD - PDM, т.е. поддержание соответствия межу данными CAD и PDM (отслеживание ссылок), что означает: 1.2.1) доступ к данным CAD из PDM и к данным PDM из CAD ; 1.2.2) синхронизация атрибутов (установление соответствия: например, если в CAD задано « M =   V », то после изменения размеров модели в CAD -системе должно автоматически измениться значение атрибута «масса» в PDM ). 1.3 ) формирование состава изделия (исполнений, версий): а) выбор свойства в CAD -системе; Синхронизация атрибутов SmarTeam–SolidWorks б) выбор ответного атрибута в PDM -системе. Пример: Search – отображение состава версий (исполнений) изделия

Изображение слайда
32

Слайд 32: Функции систем PDM

1.3.1) правила выбора состава для определенной модификации (например, разные комплекты оборудования и вооружения для одного и того же самолета в вариантах фронтового истребителя и истребителя-перехватчика ); 1.3.2) задание допустимых замен комплектующих изделий (например, по наличию на складе включать в комплект шины Омского или Ярославского заводов); Желтые кружки – изделия, для которых указаны допустимые заменители, зеленые кружки – сами допустимые заменители. Управление заменами может быть выполнено непосредственно из схемы. пример : система APPIUS - PDM, модуль Конфигуратор : правила управления структурой экземпляра изделия на основе И-ИЛИ-графа; если модель содержит вычисляемые переменные, для них можно задать выражения или формулы ; возможна фильтрация списка значений переменных – например, исключить значение «ткань» для абажура, если мощность лампочки более 100 Вт. Пример: Search обеспечивает работу с допустимыми заменами составных частей изделия в режимах: один-на-один; один-на-много; много-на-один и много-на-много.

Изображение слайда
33

Слайд 33: Функции систем PDM

1.3.3) отслеживание применяемости по дате и/или серийному номеру (например, подсборка АХ.101.7 с № от … до … входит в сборку АХ.101 с № от … до …). SmarTeam – навигация с отображением дерева структуры, моделей и чертежей Teamcenter Engineering – применяемость по дате 1.4) навигация по структуре изделия. Search – навигация с отображением структуры в виде схемы; из схемы возможно открытие моделей и чертежей

Изображение слайда
34

Слайд 34: Функции систем PDM

1.5) сравнение структур различных исполнений (версий) изделия. а) сравнение по дереву структуры (в отчете сопоставление количества компонентов для разных исполнений) Teamcenter Engineering – сравнение вариантов состава изделия 1.6) управление изменениями: 1.6.1) автоматизация процессов внесения изменений ; правила (алгоритмы) проведения изменений могут быть описаны с различной степенью детализации – см. примеры: б) «графическая история» версий

Изображение слайда
35

Слайд 35: Функции систем PDM

1.6.2) контроль информации об изменениях, выпуск и хранение документов (извещения, журнал изменений, листы регистрации и др.). Search поддерживает 3 типа документов об изменениях по ГОСТ – предложение об изменении, предварительное извещение, извещение об изменении; ведется история изменений 1.7) визуализация компонентов (иногда рассматривается как самостоятельная функция): визуальное представление изделия любой сложности и динамическая навигация по 3 D сборке независимо от конкретных САПР, в которых выполнены модели отдельных компонентов. PDM STEP Suite – автоматическое уведомление об изменении Teamcenter Engineering – типовые опции визуализации

Изображение слайда
36

Слайд 36: Функции систем PDM

2. Управление документами ( Document Management ) 2.1) ввод документов (в том числе с помощью средств их автоматического распознавания), их регистрация и индексирование (например, оформление регистрационных карточек с полями для атрибутов); 2.2) группирование документов в логические папки без физического перемещения файлов; 2.3) управление версиями документов, регламентация и регистрация вносимых в них изменений; Пример : в системе SWR - PDM версии документа отражают его изменения в течение жизненного цикла или альтернативные варианты, а итерации в пределах версии обеспечивают возможности отката изменений: Lotsia PDM, модуль LS Flow – шаблон утверждения договора 2.4 ) поиск документов по различным признакам; 2.5) маршрутизация документов в зависимости от типа бизнес-процедуры (может быть жесткой при фиксированных маршрутах или свободной ), учет их движения, протоколирование вносимых в них резолюций; (функция может быть реализована общей подсистемой Workflow ) ;

Изображение слайда
37

Слайд 37: Функции систем PDM

2.6) автоматическое уведомление ответственных лиц о состоянии ( статусе ) документов и содержащихся в них директивах и рекомендациях; В различных PDM -системах состав статусов и их наименования могут несколько различаться, например: рабочий, принятый, архивный, готов к выпуску и др. Например, в системе SmarTeam документ может находиться в одном из пяти состояний: “У автора”, “У руководителя”, “На изменении”, “Утвержден” и “В хранилище”. SmarTeam – настройка взаимодействия с ERP -системой SAP R /3 ( Integration Manager, Attribute Manager ) Lotsia PLM – контроль исполнения и присвоение статуса документам 2.7) контроль исполнения предписываемых документами действий (функция может быть реализована общей подсистемой Workflow ); 2.8) разграничение прав доступа к документам; 2.9 ) автоматическое архивирование чертежей и связанных с ними документов; 2.10) интерфейсы к системам ERP (АСУП). Пример : изменение статуса документа в системе SmarTeam

Изображение слайда
38

Слайд 38: Функции систем PDM

3. Управление потоками работ ( Workflow Management ) : 3.1) создание моделей бизнес-процессов т.е. формализованных описаний потоков работ, типичных для процессов производства (подсистема может одновременно обеспечивать и маршрутизацию документов ). 3.2) мониторинг – контроль текущего состояния работ, в том числе: 3.2.1) отслеживание потоков работ между рабочими местами, подразделениями, субподрядчиками и поставщиками. 3.2.2) отслеживание личных пакетов заданий каждого из пользователей. Системы Workflow должны автоматически генерировать предупреждения в случае замедления процесса и указывать узел, где он застопорился или замедлился ; отражать состояние процесса; предоставлять статистику по процедурам и функциям. Пример : система SmarTeam, пакет (подсистема) SmartFlow содержит шаблоны сетевых графиков для типовых процессов. Задания в сетевых графиках могут иметь триггеры событий, которые выполняются либо когда задание получено, либо когда задание выполнено. Шаблоны процессов в модуле SmartFlow системы SmarTeam Особенность проектирования и производства сложной техники – кооперация большого числа предприятий-изготовителей, деятельность которых должна быть строго согласована. Например, в изготовлении самолета F 22 Raptor участвовали три основных подрядчика ( Boeing, Pratt & Whitney, Lockheed Martin Aeronautics ) и около 1000 субподрядчиков и поставщиков из 44 штатов. В этих условиях жизненный цикл изделия рассматривается как совокупность ЖЦ конечного продукта и ЖЦ входящих в его состав компонентов.

Изображение слайда
39

Слайд 39: Функции систем PDM

Анализ данных о расходах. Консолидация данных о закупках, что позволяет отслеживать расходы компании и соответствие нормативным требованиям. Совместная работа над запросами контрактных предложений. Оптимизация процессов, связанных со сбором и анализом данных, полученных в ответ на запросы контрактных предложений и расценок. Упрощение поддержки принятия решений и моделирования ситуаций благодаря наличию широких возможностей оптимизации. Ведение переговоров через Интернет. Возможность вести переговоры, касающиеся практически любых товаров и услуг. Позволяет планировать, отслеживать и категоризировать интересующие события на аукционах. Совместная работа в сфере снабжения. Позволяет специалистам по снабжению осуществлять совместную работу в режиме реального времени, пользоваться специальными инструментами для объявления сделок, сообщать о заключении новых соглашений, собирать и распространять знания, имеющие отношение к поиску поставщиков и управлять проектами снабжения. Эти задачи смыкаются с традиционными для ERP -систем задачами управления запасами. Teamcenter – пример цепочки поставок и календарного графика 4. Взаимодействие с поставщиками (управление цепочками поставок – Supply Chain Management, SCM ) : 4.1 ) оптимизация комплектации : выбор состава комплектующих изделий (например, по минимальной стоимости при ограничениях на уровень качества либо по наивысшему качеству при ограничениях на стоимость и т.п.); выбор поставщиков ; планирование закупок ; 4.2) поддержка совместной работы с поставщиками и партнерами по обеспечению изделия комплектующими: разработка и контроль календарных планов разработки, изготовления и поставки; оценка уровня запасов по всем комплектующим изделиям; принятие решений о необходимости пополнения запасов; подготовка заявок; контроль качества поставок. Например, система Teamcenter располагает следующими возможностями стратегической организации снабжения: Работа с данными о поставщиках. Получение, сбор и обработка информации об отдельных поставщиках, в том числе сведений о показателях их деятельности и описаний их возможностей. На основе этих сведений можно оперативно находить, выбирать и отслеживать потенциальные источники поставок.

Изображение слайда
40

Слайд 40: Функции систем PDM

5. Взаимодействие с заказчиками (Customer Relationship Management, CRM) : 5.1) обеспечение удовлетворения требований заказчиков по каждому экземпляру изделия; содержание и объем этих работ определяется так называемыми стратегиями позиционирования изделий, в частности, такими как: сборка на заказ (ATO – Assembl y - To-Order ) из типовых компонентов: изготовление продукции начинается только после получения заказа. разработка на заказ ( ETO – Engineer ing - To-Order ) : производственный цикл начинается после получения заказа с конструкторской подготовки производства. 5.2) поддержка взаимодействия с заказчиками : сведения о клиентах, история отношений с ними, маркетинг, реклама (семинары, мастер-классы, тест-драйвы), продажа, доставка, обслуживание продукции и др. 5.3) управление сервисом : обработка жалоб, работа с обращениями клиентов и др. К этой группе функций иногда относят аналитические задачи поиска статистических закономерностей в данных о клиентах для выработки наиболее эффективной стратегии маркетинга, продаж, обслуживания клиентов и т. д. 6. Управление жизненным циклом ( Lifecycle Management ) : 6.1 ) создание банка формализованных описаний этапов жизненного цикла изделий ; 6.2) разграничение полномочий и уровней доступа исполнителей по этапам ЖЦ изделия; 6.3) мониторинг с детализацией до этапа, как правило, во взаимодействии с Workflow.

Изображение слайда
41

Слайд 41: Лекция № 5. Форматы обмена данными между САПР

[А. Чечетка, К. Кекурс. Формат JT как основа единой интероперабельной платформы разработки // CAD / CAM / CAE Observer, 2006, # 6, 7]: «Современные технологии позволяют осуществлять проектирование и поддержку изделий в глобальном масштабе. Но для того, чтобы делать это, им нужны эффективные средства для обмена проектными данными между существенно отличающимися друг от друга программными системами. Проблему интероперабельности многие крупные производители стараются решить, заставляя своих поставщиков применять те же системы проектирования, что и у них. Это ограничивает свободу поставщиков выбирать инструменты, наиболее удобные для их вида деятельности… Вместе с тем, когда все пользуются разными системами, это потенциально увеличивает затраты всех сторон. Современная тенденция – использование стандартов обмена информацией, позволяющих компаниям управлять всеми аспектами ЖЦИ независимо от конкретных программных решений, применяемых ими». /См. выше/ Системы проектирования, созданные разными разработчиками, используют свои собственные форматы данных – например, в системе Unigraphics версии 14 было предусмотрено свыше 100 различных форматов, из них геометрических и графических – около 20. Поэтому в машиностроительных САПР основное внимание уделяется обмену геометрическими данными. В качестве форматов обмена используются: – собственные форматы САПР; – форматы «геометрических ядер» САПР (систем геометрического моделирования); – стандартные («нейтральные») форматы. https://en.wikipedia.org/wiki/Comparison_of_computer-aided_design_editors - сравнение различных САПР.

Изображение слайда
42

Слайд 42: Собственные форматы САПР

Преимущества : минимальные потери данных при обмене ; возможность при определенных условиях (при использовании специальных программных модулей) передавать структуру модели, а иногда и параметризованные модели вместе со вспомогательными элементами (эскизами и др.). Недостатки : требуется отдельный транслятор на каждую пару взаимодействующих систем ; надежность обмена гарантируется только при передаче данных между конкретными версиями (релизами) систем. Сравнение объемов – одна и та же модель Body ( Sprinkler ). sldprt сохранена в различных форматах: *. sldprt - 537,088 байт *. x _ t ( Parasolid ) - 279,092 *. sat ( ACIS ) - 809,638 *. iges - 1,920,276 *. step - 1,347,952 *. stl ( bin ) - 912,284 *. stl ( ASCII ) - 4,863,985 Этот способ обмена подвергается критике с момента появления первых САПР за «неэкономность», но сохраняется в современных CAD / CAM -системах из-за популярности ряда форматов. Примеры DWG  (от англ.  drawing  — чертеж) — бинарный формат файла, используемый для хранения двухмерных (2D) и трёхмерных (3D) проектных данных и метаданных ( AutoCAD, nanoCAD, IntelliCAD, Caddie ). Форматы.dws («drawing standards» — стандарты чертежа),.dwt («drawing template» — шаблон чертежа) также являются форматом DWG. SLDPRT – 3D формат изображения, используемый CAD программным обеспечением SolidWorks, содержит 3D-объект или «часть», которые могут быть объединены с другими частями в единую сборку (.SLDASM файл).

Изображение слайда
43

Слайд 43: Формат геометрических моделлеров

● Формат SAT ( моделлер ACIS ) Система геометрического моделирования ACIS – разработка компании Spatial Technologies. Формат SAT первоначально предназначался для внутреннего представления данных в системах, основанных на ядре ACIS, но по мере роста популярности этих систем превратился в «фактический стандарт» межсистемного обмена. Формат представляет как геометрию, так и топологию объекта, однако не содержит специальных средств передачи инженерных данных. Тип файла - текстовый. ● Формат XMT ( моделлер Parasolid ) Геометрический моделлер Parasolid – разработка компании Shape Data, ныне собственность Unigraphics Solutions. Считается наиболее быстродействующим ядром. Типы файлов геометрических моделей - текстовый XMT _ TXT (.x _ t ) и двоичный XMT _ BIN (.x _ b ). Двоичный компактнее, но поддерживается не всеми системами. Структура обменного файла подобна файлу формата *. SAT, но вместо наименований объектов используются их коды. Наиболее распространенные моделлеры – ACIS и Parasolid, на базе которых создано большое число CAD / CAM / CAE -систем. Особенности реализации XT -обмена в CAD -системах SolidWorks 2001 : Импортирует только поверхности и солиды с учетом цвета, кривые и точки игнорируются. Возможно сокращение порядка построения сборки до одного уровня, т.е. без сохранения иерархии. Пример : Передача модели из Unigraphics v.17 в SolidWorks 2003 в формате X _ T ( Parasolid ) – структура модели не передается, в дереве модели единственный элемент « Imported 1», редактирование которого невозможно. Пример : фрагмент файла формата SAT 500 0 1 0 37 SolidWorks(1999207)-Sat-Convertor-2.0 11 ACIS 5.0 NT 24 Tue Mar 18 11:05:22 2003 1 9.9999999999999995e-007 1e-010 -0 body $-1 $1 $-1 $2 # -1 lump $-1 $-1 $3 $0 # -2 transform $-1... no_rotate no_reflect no_shear # -3 shell $-1 $-1 $-1 $4 $-1 $1 # -4 face $-1 $5 $6 $3 $-1 $7 reversed single # -5 face $-1 $8 $9 $3 $-1 $10 forward single # -6 loop $-1 $-1 $11 $4 # -7 torus-surface $-1 0 0.020320000000000001 0 0 1 0 0.0068580000000000004 0.00050799999999999999 0 0 1 forward_v I I I I # -8 face $-1 $12 $13 $3 $-1 $14 forward single # -9 loop $-1 $-1 $15 $5 # -10 cone-surface $-1 0 0 0 0 -1 0 0 0 -0.0063500000000000006 1 I I 0 1 1 forward I I I I # -11 coedge $-1 $16 $17 $18 $19 reversed $6 $-1 # ... -4572 point $-1 0.028187878777263982 0.060237648093274997 0.012954 # -4573 point $-1 0.025835217222116777 0.05401168498717502 0.012954 # -4574 straight-curve $-1 0.038952950820528055 0.05876422667396719 0.012954 -0.9063077870366526 -0.422618261740694 0 I I # -4575 ellipse-curve $-1 0 0.025654 0 0 -1 0 0 0 -0.003936999999999987 1 l l # End-of-ACIS-data Пример: фрагмент файла формата XMT_TXT **ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz************************** **PARASOLID !"#$%&'()*+,-./:;<=>?@[\]^_`{|}~0123456789************************** **PART1; MC=x86; MC_MODEL=INTEL_PENTIUM; MC_ID=unknown; OS=unknown; OS_RELEASE=unknown; FRU=Top Systems, Ltd.; APPL=T-FLEX Parametric Pro v.7.1; SITE=Moscow, Russia; USER=unknown; FORMAT=text; GUISE=transmit; KEY=D:\T-Flex Ptoject\kulachok4_5.xmt_txt; FILE=D:\T-Flex Ptoject\kulachok4_5.xmt_txt; DATE=9-okt-2002; **PART2; SCH=SCH_1400153_14000; USFLD_SIZE=7; **PART3; **END_OF_HEADER***************************************************************** T51 : TRANSMIT FILE created by modeller version 140015317 SCH_1300000_130067 12 1 1938 0 2 0 0 0 0 1e3 1e-8 0 0 3 1 0 1 1 4 5 6 7 8 9 10 0 0 0 0 0 0 26918 70 2 0 1 0 0 4 1 20 4 11 11 1 T0 0 0 0 0 0 0 13 4 55 0 1 0 12 0 0 13 0 -1409286143 0 0 9568260 704643073 704643073 26920 50 5 54 0 14 15 0 16 +.013 -.01146812862004 59.00803007010891465 0 -.573576436351046 -.819152044288992 0.819152044288992 - .573576436351046 0 0 0 0 0 0 0 31 6 1906 0 9 17 0 0 +-.014.01532212414040495.0 0424764779919666 1 0 0 0 0 -1.0054 0 0 0 0 0 0 0 29 7 1885 0 10 18 0.021.0099 2837233231248.003987952862028525 0 0 0 0 0 0 0 19 8 16 0 1 13 0 19 V0 0 0 0 0 0 0 16 9 1879 0 ?20 0 21 6 0 0 1 -1426063113 0 0 12582912 822083593 822083593 273 40 18 10 1883... ... .02100000000631975.0002738027498727335.02532163580 85527.02099999999827665 -.00854789293776554.02281559109971835.021000000000315 55 -.01492119296906722.01880806057999085.02100000000009745 -.01800932737913655 .01512269086378685.0210000000000038 -.01933612201465225.0135392983944022 0 0 0 0 0 0 0 127 2 398 4 4 0 0 0 0 0 0 0 127 9 399 4 3 1 1 1 1 1 1 4 0 0 0 0 0 0 0 128 2 400 0 1 0 0 0 0 0 0 0 128 9 401 -.1231898174900154 0.1141363617040468.1 987452590214045.2885244392781275.47758790453496.665737862354071.856386687820 8 1 0 0 0 0 0 0 0 141 395 316 402 150 147 0 0 0 0 0 0 0 141 396 231 150 402 147 0 0 0 0 0 0 0 141 402 310 396 395 147 0 0 0 0 0 0 0 81 1 101 1348 403 99 0 0 88 0 0 0 0 0 0 0 0 0 80 1 403 404 405 9000 0 0 0 0 3 5 0 0 0 FFFFFFFTFFFFFF1 0 0 0 0 0 0 0 81 1 88 1342 403 86 0 0 0 101 0 0 0 0 0 0 0 0 79 14 405 TF_Start_Point0 0 0 0 0 0 0 19 13 56 0 1 0 8 4 S0 0 0 0 0 0 0 141 16 208 16 16 5 0 0 0 0 0 0 0 74 20 11 1 0 101 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 Особенности реализации SAT -обмена в CAD -системах Не все системы, основанные на ACIS, могут импортировать все его объекты: например, AutoCAD R 14, 2000 и Autodesk Mechanical Desktop – кривые читаются как тела, поэтому сплайны требуется разбивать; Autodesk Inventor читает только солиды; SolidWorks 99 – только поверхности и солиды и т.д. Во всех вариантах узловые точки кривых и поверхностей фиксируются, замкнутые кривые рассекаются.

Изображение слайда
44

Слайд 44: Стандартные форматы

● Формат обмена DXF ( Drawing eXchange Format ) Формат DXF разработан компанией Autodesk для системы AutoCAD, специально как формат обмена, в том числе между разными версиями системы, в отличие от внутреннего формата представления данных DWG. Использовался также в прикладных программах проектирования для документирования результатов. Официальным стандартом до последнего времени не является, но давно признан «стандартом де-факто». Первоначально включал только 2 D объекты, но с переходом на ядро ACIS (с версии AutoCAD R 14) дополнен объектами 3 D -геометрии. ● Формат IGES – Initial Graphics Exchange Specification Первая версия разработана в 1980 г., утверждена в качестве национального стандарта США (ANSI) в 1981 г. как предполагаемая основа CALS-технологии (военная программа Mil-D-28000A).  Особенности реализации IGES -обмена в CAD -системах Несмотря на стандартизацию структуры и общих правил описания объектов, каждая система имеет свои особенности импорта и экспорта файлов IGES. Для большинства объектов существует не единственная возможность описания, поэтому главное различие между реализациями формата - способы представления формы объектов. Поэтому наиболее развитые моделлеры содержат средства настройки модулей импорта/экспорта на конкретную реализацию формата. Описание этих средств обычно приведено в разделе « Импорт/Экспорт » руководства или файла справки. AutoCAD R 13, R 14 : дополнительная программа IGESTRAN поддерживает только точки, кривые и поверхности. SolidWorks 2001 : Импорт IGES – настраивается реакция системы на ошибки чтения (невозможность импорта, дефекты на поверхности и др.), например - «сшить в твердое тело», «создать справочные поверхности» и др. Экспорт IGES – не экспортируются объекты типов Граничная поверхность, Линейчатая поверхность, Поверхность параметрического сплайна и др.; настраивается способ представления поверхностей (как отсеченные поверхности, или как B -сплайны, или как параметрические сплайны), экспорт объектов эскиза, сохранение всех компонентов сборки в одном файле. Пример: фрагмент файла формата IGES SolidWorks IGES FILE using analytic representation for surfaces S 1 1H,,1H;,6Hdetal1,25HC:\ Проект \IGES\detal1.IGS,39HSolidWorks 99 by SolidWG 1 orks Corporation,11HVersion 3.0,32,308,15,308,15,6Hdetal1,1.,2,2HMM,50, G 2 0.125,14H1000425.041337,1E-008,500.,6H Андрей,,10,0,; G 3 314 1 0 0 0 00010200D 1 314 0 0 1 0 0 D 2 128 2 0 0 0 01010000 D 3 128 0 0 12 0 0D 4 Код 128 - Rational B - Spline Surface, 2 - номер 1-й строки записи раздела параметров, 3 - обратная ссылка из записи раздела параметров. 126 14 0 0 0 01010500D 5 126 0 0 2 0 0D 6 ............ 142 1981 0 0 0 00010500D 1091 142 0 0 1 0 0D 1092 144 1982 0 0 0 00000000D 1093 144 0 -1065 1 0 0D 1094 314,75.2941176470588,75.2941176470588,75.2941176470588,; 1 P 1 128,3,3,3,3,0,0,0,0,0,0.,0.,0.,0.,1.,1.,1.,1.,0.,0.,0.,0.,1., 3 P 2 1.,1.,1.,1.,0.804737854124365,0.804737854124365,1., 3 P 3 0.804737854124363,0.647603013860686,0.647603013860686, 3 P 4 0.804737854124363,0.804737854124363,0.647603013860686, 3 P 5 0.647603013860686,0.804737854124363,1.,0.804737854124365, 3 P 6 0.804737854124365,1.,-50.,-10.,0.,-61.715728753,-10.,0.,-70., 3 P 7 -18.284271247,0.,-70.,-30.,0.,-50.,-10.,29.289321881, 3 P 8 -61.715728753,-10.,36.152236891,-70.,-18.284271247, 3 P 9 41.005050634,-70.,-30.,41.005050634,-29.289321881,-10.,50., 3 P 10 -36.152236891,-10.,61.715728753,-41.005050634,-18.284271247, 3 P 11 70.,-41.005050634,-30.,70.,0.,-10.,50.,0.,-10.,61.715728753,0., 3 P 12 -18.284271247,70.,0.,-30.,70.,0.,1.,0.,1.; 3 P 13 3 - номер 1-й строки записи раздела вхождений, описывающей данный объект, 2 - номер 1-й строки записи раздела параметров для данного объекта. 126,1,1,1,0,1,0,0.,0.,1.,1.,1.,1.,1.,0.,0.,1.,1.,0.,0.,1.,0., 5 P 14 0.,1.; 5 P 15 ... 142,1,1071,1087,1089,1; 1091 P 1981 144,1071,1,0,1091; 1093 P 1982 S 1 G 3 D 1094 P 1982 T 1 Популярность формата DWG, первоначально считавшегося сугубо внутренним для продуктов Autodesk и старательно оберегаемого компанией, привела к тому, что и он становится одной из популярных форм обмена проектными данными. Силами ряда софтверных компаний, объединившихся в альянс Open DWG Alliance (ныне Open Design Alliance ), формат был расшифрован и стал доступен членам альянса в виде библиотеки стандартных процедур.

Изображение слайда
45

Слайд 45: Стандартные форматы

● Формат STL ( Stereolitography ) Формат предназначен для передачи геометрических моделей в системы быстрого прототипирования, однако может восприниматься некоторыми CAE / CAD / CAM -системами. В частности, достаточно широко используется в системах моделирования процессов обработки материалов (литья, штамповки, формообразования полимеров). Статуса официального стандарта не имеет. Поверхности модели аппроксимируются сеткой из треугольников ( facet ) с заданной точностью, в файле сохраняются координаты вершин вместе с ориентацией внешней нормали к каждой из треугольных граней. Файл может быть представлен в 2 формах – текстовой и двоичной. Основные недостатки такого представления – утрата структурных связей между элементами формы и большой объем файлов. ● Формат STEP – Standard for Exchange of Product model data Комплекс стандартов STEP ( Standard for Exchange of Product model data, ISO 10303) разрабатывается с целью дать нейтральный механизм описания данных о продукте (изделии) на всех стадиях его ЖЦ, не зависящий от конкретной информационной системы. Некоторые стандарты комплекса STEP будут рассмотрены позже. Область, охватываемая стандартами STEP, выходит далеко за рамки обмена геометрическими данными, однако существующие CAE / CAD / CAM -системы используют преимущественно геометрическое подмножество стандарта. Поэтому эту его часть имеет смысл рассмотреть вместе с другими стандартами обмена проектными данными. Для обеспечения возможности единообразного описания изделий в различных прикладных областях предполагается, что информационные модели (в терминах стандарта «прикладные протоколы») создаются на базе типовых блоков («интегрированных ресурсов»). Это общие для различных приложений компоненты ( building blocks ), используемые в моделях приложений. Например, описания геометрических объектов в виде поверхностей Безье или B -сплайнов могут использоваться в разных приложениях, поэтому такие описания отнесены к интегрированным ресурсам. Прикладные протоколы содержат ссылки на объекты, определенные стандартами этой группы. Одним из таких блоков служат средства описания геометрии технических объектов. Основная часть их описана в 42-м томе стандарта – ISO 10303, part 42: Geometric and topological representation (Представление геометрии и топологии).  Особенности реализации STL -обмена SolidWorks 99 : Импорт STL – не предусмотрен. Экспорт STL – возможен для отдельных деталей и сборок; настраиваются тип файла ( ASCII / Bin ), необходимость проверки интерфренции для сборок, сохранение всех компонентов в одном файле, качество (точность). Пример: фрагмент файла формата STL solid ascii facet normal 0.766047 -0.642784 2.00811e-008 outer loop vertex -120.661 -24.3159 -64.719 vertex -120.661 -24.3159 -79.719 vertex -119.545 -22.9857 -79.719 endloop endfacet facet normal... ... endfacet end solid

Изображение слайда
46

Слайд 46: Конверторы

● Встроенные и интегрируемые конверторы. Для большинства систем разработаны дополнительные трансляторы, которые могут быть использованы наряду со штатными или вместо них. AutoCAD : дополнительные модули IGESTRAN и AutoCAD STEP. SolidWorks (СГ 2-2003) : Штатный транслятор – XchangeWorks. Опциональные трансляторы : CAD porter (CATIA, Pro/Engineer, I-DEAS). PolyTrans (DXF, IGES, STL, 3ds, DirectX,...) – встроенная версия автономного транслятора фирмы Okino Computer Graphics. CADfix – встроенная версия автономного транслятора с возможностями «лечения» моделей (восстановления сбойной геометрии). FormatWorks – трансляция и «лечение» моделей. ● Автономные конверторы. Конверторы 2 D геометрии: Пример – CAMCAD. Предназначен преимущественно для обмена между САПР электроники, но поддерживает и некоторые форматы общетехнического назначения. Имеются функции редактирования геометрии ( Edit ), добавления слоев, элементов, примитивов ( Add ), смены шрифта и начала координат ( Settings ) и др. Конверторы 3 D моделей : примерами могут служить трансляторы PolyTrans, Interchange ( SAT, IGES, 3 ds, Softimage, Lightwave, …), 3 DVision ( IGES, VDA - FS, STL, STEP, CATIA, Unigraphics, CADDS 5, Parasolid ) и др. Проблема «лечения» геометрических моделей остается достаточно острой. Различия между системами в способах внутреннего представления геометрических данных часто становятся причиной их существенного искажения при передаче. Общие для большинства трансляторов ограничения – трудности в передаче сложной геометрии, в частности, сплайновой – например, аэродинамических форм. Вследствие разнообразия используемых систем проектирования в практике широко используются специальные программные средства, предназначенные для преобразования форм представления графических и геометрических данных.

Изображение слайда
47

Слайд 47: Лекция № 6. Управление жизненным циклом продукции

В условиях единого информационного пространства роли автоматизированных систем распределяются следующим образом : cPDM обеспечивает единое информационное пространство; CAE/CAD/CAM автоматизируют проектирование и подготовку производства; MRP планирует ресурсы и управляет производством; ERP управляет всей деятельностью предприятия; CRM управляет взаимоотношениями с заказчиками; SCM управляет цепочками поставок; cPC ( Collaborative Product Commerce ) управляет ведением совместного бизнеса. Системы управления имеют свою историю развития и свои поколения. С 1990 г. сменились несколько концепций: MRP  MRP II  ERP  ERP II.

Изображение слайда
48

Слайд 48: САПР и БД

CAD -системы нуждаются в таблицах размеров нормализованных деталей и сборочных единиц, включая возможность создания собственных библиотек элементов конструкции (из-за ограничений в передаче параметризованной геометрии требуется подключение БД к CAD -системе до трансляции моделей); CAE -системы нуждаются в данных о физических свойствах конструкционных материалов и рабочих сред; Возможности обмена негеометрическими данными в современных системах проектирования весьма ограничены и представлены интерфейсами с реляционными БД общего назначения. Например, AutoCAD 2000 может взаимодействовать БД MS Access, dBase, Paradox, Oracle ; SolidWorks может импортировать данные формата *. XLS ; Unigraphics v.17 допускает импорт/экспорт файлов Excel, Lotus и др. Поэтому более сложные задачи взаимодействия с базами данных обычно и возлагаются на системы PDM (см. выше). Не менее важна совместимость САПР с существующими базами данных нормативно-справочного характера: CAPP - и CAM -системы требуют использования таблиц характеристик оборудования, инструментов и приспособлений, технологических режимов, припусков; кроме того, необходимо использование ряда характеристик объекта производства, зачастую отсутствующих в модели CAD -системы – сведений о местной термообработке, покрытиях, особых указаниях («детали … обработать совместно»). Для управления производством необходима следующая информация Конструкторская спецификация деталей и узлов; карты заимствованных, стандартизованных и унифицированных деталей и узлов (покупных комплектующих изделий); комплектовочные карты; спецификация тары. Технологические процессы изготовления деталей и узлов, маршруты их прохождения по цехам и участкам с указанием выполняемых операций. Состав оборудования и степень его загрузки при выполнении отдельных операций. Режимы обработки : при обработке резанием – скорость резания, подача, глубина резания; при обработке давлением – частота ходов пресса и т.д. Спецификация инструмента и оснастки, нормы их расхода на единицу изделия. Нормы расхода материалов и покупных полуфабрикатов (пооперационные, подетальные, на единицу изделия). Ценник на материалы. Нормы затрат живого труда (нормы времени или выработки), расценки, нормативы численности вспомогательных рабочих и инженерного персонала. Нормы расхода рабочих тел и энергоносителей (электроэнергии, топлива, сжатого воздуха, пара). План-график предупредительных ремонтов оборудования. Методы контроля качества деталей, узлов, изделий.

Изображение слайда
49

Слайд 49

Содержание этапа Инструментальные средства Содержание предметных БД Обслуживаемые среды Проектирование Управление разработкой PDM, CASE (САПР баз данных) Структура БД предметной области, маршруты проектиро-вания Конструкторские и технологические подразделения Проектирование и инженерный анализ CAE, CAD Алгоритмы функционирования изделий, физические и геометрические параметры компонентов, спецификация Конструкторско-технологическая подготовка производства CAE, CAD, CAPP, CAM Электронный макет изделия, техпроцессы, управляющие программы Производство Изготовление ERP, MRP, информационные модели производства Заказы, маршруты производства Службы управления Испытания и доработки CAE, информационные технологии (ИТ) испытаний Электронный макет изделия, интерактивное электронное техническое руководство (ИЭТР) Службы испытаний, представи-тели заказчика Эксплуатация Ведение истории объекта СУБД, возможно совместно с PDM Спецификация Архивные службы пользова-теля Регламентные работы СУБД, модели и методы анализа надежности БД ЗИП и контрольно-измерительного оборудования, ИЭТР Сервисные службы Учебное или боевое применение СУБД, имитационные модели внешних сред Электронный макет изделия, ИЭТР, модель внешней среды Боевые расчеты, службы эксплуатации Снабжение СУБД Перечень комплектующих, оборудования и поставщиков Службы снабжения Модернизация CAE, CAD, CAPP, CAM Электронный макет изделия, ИЭТР Заводские бригады, службы ремонта Утилизация ИТ утилизации и экологического мониторинга Спецификация деталей, техпроцессы утилизации Службы утилизации, экологический надзор

Изображение слайда
50

Слайд 50: Взаимо- действие САПР с АСУП

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

Изображение слайда
51

Слайд 51: ERP

Эффективность этих систем в значительной мере зависит от масштаба предприятия. П редприятиям с оборотом менее 10 млн. долл. в год не следует ожидать повышения эффективности производства от внедрения систем класса SAP R /3 (см. график ). Характер этой зависимости объясняется влиянием следующих факторов: – внедрение систем такого уровня требует крупных инвестиций на начальных этапах (3.5 – 5 млн. долл.); – на эксплуатацию и развитие ERP -системы компания не может расходовать более 5-7% от своего годового оборота; – полное использование возможностей систем требует приобретения дополнительных программных продуктов ( CAD / CAM, SCADA и др.). Современные системы управления предприятиями ERP ( Enterprise Resource Planning ), в отличие от систем MRP, предназначены для интеграции всех, а не только производственных, процессов предприятия (включая его материально-техническое и финансовое обеспечение, планирование, регулирование и т.п.). Наиболее мощные зарубежные системы ( SAP R /3, BAAN ) отличаются рядом особенностей, существенно снижающих их эффективность в условиях российской и украинской промышленности: – любой подвергаемый обработке объект от материала до готовой продукции (а также средства технологического оснащения) рассматривается как самостоятельное изделие; это затрудняет структурирование информации и требует ввода больших объемов данных о фиктивных изделиях; – при заполнении технологических маршрутов требуется указание конкретного номера станка, который технологу неизвестен, т.к. технолог не занимается распределением деталей по рабочим местам; – отсутствует деление работ по разрядам, что не позволяет дифференцировать расценки на операции по сложности работ (такой документ, как наряд, на Западе неизвестен); – недостаточно полно реализованы функции управления на уровне цеха.

Изображение слайда
52

Слайд 52: Лекция № 7. Модели жизненного цикла

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

Изображение слайда
53

Слайд 53: Каскадная модель

Это первая моделью, которая получила широкую известность и позволила действительно структурировать процесс разработки. Каскадная или водопадная модель была создана после прошедшей в 1968 г. конференции NATO по вопросам науки и техники, где рассматривались подобные вопросы, и разделяет процесс создания ПО на последовательные этапы (рис. 1). Каскадная модель подразумевает, что переход от одной фазы разработки к другой происходит только после полного и успешного завершения предыдущей фазы, и что переходов назад либо вперёд или перекрытия фаз – не происходит. Каскадный модель используется при разработке ПО, для которого можно полно и четко сформулировать все требования. Учитывая современные реалии, фактически каскадная модель не используется при разработке ПО, по крайней мере, в чистом виде. Каскадная модель (модель «Водопад») – модель жизненного цикла ПО, в которой процесс разработки выглядит как поток, последовательно проходящий стадии анализа требований, проектирования, реализации, тестирования, сопровождения (внедрения и эксплуатации). Рисунок 1 – Стадии жизненного цикла в каскадной модели – проста для понимания; – полная и согласованная документация на каждой стадии; – может кардинально снизить риски проекта по разработке ПО; – легко определить сроки и затраты на проект – требует четкой формулировки начальных требований; – повышенные сроки разработки из-за невозможности перейти к следующей стадии не закончив предыдущую; – увеличенная стоимость разработки; – недостаточная гибкость модели; – не соответствует реальным условиям разработки ПО; – результаты работ доступны заказчику только по завершении проекта

Изображение слайда
54

Слайд 54: Модифицированная каскадная модель

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

Изображение слайда
55

Слайд 55: V-образная модель

Была предложена именно для того, чтобы устранить недостатки каскадной модели, а название – V-образная, или шарнирная – появилось из-за ее специфического графического представления (рис. 2 ). V-образная модель дала возможность значительно повысить качество ПО за счет своей ориентации на тестирование, а также во многом разрешила проблему соответствия созданного продукта выдвигаемым требованиям благодаря процедурам верификации и аттестации на ранних стадиях разработки. Однако в целом V-образная модель является всего лишь модификацией каскадной и обладает многими ее недостатками. В частности, и та и другая слабо приспособлены к возможным изменениям требований заказчика. Если процесс разработки занимает продолжительное время (иногда до нескольких лет), то полученный в результате продукт может оказаться фактически ненужным заказчику, поскольку его потребности существенно изменились. V-Model – вариация каскадной модели жизненного цикла ПО, в которой задачи разработки идут сверху вниз по левой стороне буквы V, а задачи тестирования — вверх по правой стороне буквы V. Dual Vee Model – вариация V -модели жизненного цикла ПО, которая используется для проектирования нескольких взаимосвязанных систем (рис 2.1). Рис. 2.1. Dual Vee Model

Изображение слайда
56

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

Предложенная Барри Боэмом в 1988 г., она стала существенным прорывом в понимании природы разработки ПО, хотя, по большому счету, является объединением двух моделей: каскадной и на основе создания прототипов (см. прим). Спиральная модель – это модель жизненного цикла ПО, сочетающая в себе как проектирование, так и постадийное прототипирование, делающая упор на начальные этапы жизненного цикла: анализ (особое внимание уделяется рискам) и проектирование. – наиболее реально (в виде эволюции) отображает разработку ПО; – хорошая документация процесса разработки; – гибкость – имеется возможность изменения требований к проекту ПО в процессе разработки; – улучшенный анализ рисков; – позволяет явно учитывать риск на каждом витке эволюции разработки; – раннее создание рабочих прототипов; – использует прототипирование для уменьшения риска и совершенствования ПО; – позволяет обеспечить стабильность архитектуры ПО, удовлетворяющей высоким требованиям по нагрузке и устойчивости – трудности контроля и управления временем разработки из-за отсутствия четкой регламентации стадий; – может быть достаточно дорогой в использовании; – управление рисками требует привлечения высококлассных специалистов; – успех процесса в большой степени зависит от стадии анализа рисков; – не подходит для небольших проектов Примечание: иногда также отдельно выделяют модель на основе прототипов, которая используется на ранних стадиях жизненного цикла ПО для того, чтобы прояснить не ясные требования (прототип UI); выбрать одно из ряда концептуальных решений (реализация сценариев); проанализировать осуществимость проекта. Мы не будем рассматривать ее отдельно так как она не охватывает весь жизненный цикл ПО и используется только в связке с какой-либо другой моделью. Поскольку спиральная модель в основном охватывает именно проектирование, то в первоначальном виде она не получила широкого распространения в качестве метода управления всем жизненным циклом создания ПО. Однако главная ее идея, заключающаяся в том, что процесс работы над проектом может состоять из циклов, проходящих одни и те же этапы, послужила исходным пунктом для дальнейших исследований и стала основой большинства современных моделей процесса разработки ПО.

Изображение слайда
57

Слайд 57

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

Изображение слайда
58

Слайд 58: Итеративная модель

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

Изображение слайда
59

Слайд 59: Итеративная модель

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

Изображение слайда
60

Слайд 60: Модель CMM

Была разработана SEI ( Software Engineering Institute ), который финансируется за счет Министерства обороны США и является структурной единицей Университета Карнеги- Меллона. Первая официальная версия стандарта вышла в 1993 г., хотя работы над ним начались гораздо раньше – основные его положения были опубликованы еще в 1986 г. Успех CMM предопределило несколько факторов. Этот стандарт был одним из первых, изначально учитывающих специфику создания ПО. Он оказался достаточно прост и прозрачен как для понимания, так и для использования, и регламентировал, "что", а не "как" делать, а потому подходил для различных моделей жизненного цикла, методологий разработки и не накладывал каких-либо ограничений на стандарты документирования, инструментарий, среду и языки, применяемые в проектах. И, пожалуй, основным фактором, предопределившим популярность CMM, явилось сотрудничество SEI с Министерством обороны США, что де-факто означало использование стандарта при реализации проектов по заказу этого ведомства. Модель CMM (табл. 1) предусматривает пять уровней зрелости, каждому из которых соответствуют определенные ключевые области процессов ( Key Process Areas, KPA). Capability Maturity Model (CMM) – модель оценки уровня зрелости процессов разработки вместе с его производными. Название уровня Ключевые области процесса 1 – Начальный Если организация находится на этом уровне, то ключевых областей процессов для нее не предусмотрено 2 – Повторяющийся Управление программными конфигурациями. Обеспечение качества программных продуктов. Управление контрактами подрядчиков. Контроль за ходом проектов. Планирование программных проектов. Управление требованиями 3 – Определенный Экспертные оценки. Координация взаимодействий проектных групп. Инженерия программного продукта. Комплексный менеджмент ПО. Программа обучения персонала. Определение организационного процесса. Область действия организационного процесса 4 – Управляемый Менеджмент качества ПО. Управление процессом на основе количественных методов 5 – Оптимизируемый Управление изменением процесса. Управление технологическими изменениями. Предотвращение дефектов

Изображение слайда
61

Слайд 61: Модель CMM I

Разрешить большинство проблем CMM призван новый стандарт SEI – Capability Maturity Model Integrated (CMMI) – Интегрированная модель оценки уровня зрелости процессов разработки. Стандарт CMMI изначально создавался таким образом, чтобы объединить существующие варианты CMM и исключить какие-либо противоречия при его практическом применении в различных сферах деятельности высокотехнологичных компаний. Для того чтобы устранить необходимость "выравнивания" процессов организации и быть более приспособленным к ее бизнес-потребностям, а не наоборот, стандарт CMMI имеет две формы представления – классическую, многоуровневую, соответствующую CMM, и новую, непрерывную. Непрерывная форма представления рассматривает не уровни зрелости ( Maturity Levels ), а уровни возможностей ( Capability Levels ), которые оцениваются для отдельных областей процессов ( Process Areas, PA ). В табл. 2 дано соответствие уровней зрелости стандарта CMM, а также уровней зрелости многоуровневого представления CMMI и уровней возможностей непрерывного представления CMMI. Уровень зрелости CMM Уровень зрелости многоуровневого представления CMMI Уровень возможностей непрерывного представления CMMI 0 – Незавершенный – – 1 – Начальный Начальный Выполнимый 2 – Повторяющийся Управляемый Управляемый 3 – Определенный Определенный Определенный 4 – Управляемый Управляемый количественно Управляемый количественно 5 – Оптимизируемый Оптимизируемый Оптимизируемый SEI отказывается от CMM и взамен активно продвигает CMMI, обещая ужесточить контроль за процессом сертификации, сократить затраты на него и сделать его более привлекательным для небольших организаций; обеспечивая совместимость со стандартами ISO. Однако факт остается фактом: в современных условиях наличие сертификата определенного уровня CMM/CMMI не является таким значимым фактором, как несколько лет назад, и принимается без дополнительных вопросов разве что в проектах, выполняемых по государственному заказу. Стандарт ISO/IEC 15504 предназначен для оценки процесса разработки информационных систем, в частности, ПО. Он изначально был спроектирован таким образом, чтобы в значительной степени соответствовать существующим в отрасли стандартам оценки процесса создания ПО. Именно это требование определило схожесть стандарта с основными принципами CMM/CMMI. Его текущая версия, датированная 2004 г., предусматривает шесть уровней возможностей (от нулевого до пятого), которые соответствуют уровням возможностей непрерывного представления стандарта CMMI.

Изображение слайда
62

Слайд 62: Лекция № 8. МЕТОДОЛОГИИ РАЗРАБОТКИ ПО

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

Изображение слайда
63

Слайд 63: Классификация методологий разработки ПО

Методологии представляют собой ядро теории управления разработкой ПО. К существующей классификации в зависимости от используемой в ней модели жизненного цикла (см. выше) добавилась более общая классификация на прогнозируемы и адаптивные методологии. Прогнозируемые (предикативные) методологии фокусируются на детальном планировании будущего. Известны запланированные задачи и ресурсы на весь срок проекта. Команда с трудом реагирует на возможные изменения. План оптимизирован исходя из состава работ и существующих требований. Изменение требований может привести к существенному изменению плана, а также дизайна проекта. Часто создается специальный комитет по "управлению изменениями" ( change control board ) чтобы в проекте учитывались только самые важные требования (ГОСТ 19, 32). Адаптивные методологии или, как их чаще называют, гибкие методологии разработки (англ. Agile software development, agile -методы) – серия подходов к разработке ПО, ориентированных на использование интерактивной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля. Эти методологии нацелены на преодоление ожидаемой неполноты требований и их постоянного изменения. Когда меняются требования, команда разработчиков тоже меняется. Команда, участвующая в адаптивной разработке, с трудом может предсказать будущее проекта. Существует точный план лишь на ближайшее время. Более удаленные во времени планы существуют лишь как декларации о целях проекта, ожидаемых затратах и результатах. Существует несколько методик, относящихся к классу гибких методологий разработки, в частности: Scrum, Crystal, Extreme Programming, Adaptive Software Development, DSDM, Feature Driven Development, Lean software development. Применяется как эффективная практика организации труда небольших групп (которые делают однородную творческую работу) в объединении с их управлением комбинированным (либеральным и демократическим) методом. Большинство гибких методологий нацелены на минимизацию рисков путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся две-три недели. Agile -методы делают упор на непосредственное общение лицом к лицу. Большинство agile -команд расположены в одном офисе. Основной метрикой agile -методов является рабочий продукт. Отдавая предпочтение непосредственному общению, agile -методы уменьшают объём письменной документации по сравнению с другими методами.

Изображение слайда
64

Слайд 64: SCRUM

SCRUM – гибкая методология разработки ПО (основанная на итеративной модели), которая предполагает деление проекта на итерации (спринты) и проведение ежедневных совещаний (scrum), результатом которых является определение функции системы, реализованных за предыдущий день, возникшие сложности и план на следующий день. Product Backlog – приоритезированный список имеющихся на данный момент требований к ПО. Product Backlog постоянно пересматривается и дополняется – в него включаются новые требования, удаляются ненужные, пересматриваются приоритеты. 0. Разработка Product Baclog. Требования к ПО разрабатывает Product Owner (представитель интересов конечного пользователя). 1. Планирование спринта (4-8 часов). Перед каждой итерацией (обычно продолжительностью – 1 месяц) выбирается список функций системы, которые планируется реализовать в течение следующего спринта (на каждую функцию не более 12 часов / суток). 2. Ежедневное совещание ( scrum ( скрам ), 15-20 минут). В течение совещания каждый член команды (размер команды: 3-9 человек) отвечает на 3 вопроса: – что я сделал с момента прошлой встречи для того, чтобы достигнуть Цели Спринта? – что я сделаю сегодня для того, чтобы достичь Цели Спринта? – вижу ли я препятствия, которые могли бы затруднить достижение Цели Спринта? 3.  Скрам над скрамом. Проводиться после скрама в случае распределенной разработки продукта. Объединенное совещание нескольких групп разработчиков сфокусированное на общих областях и взаимной интеграции. Вопросы те же, что и на скраме (с заменой «я» на «наша команда»), плюс еще один вопрос: – нужно ли другой команде сделать что-то из задач вашей команды? 4. Обзор итогов спринта (до 4 часов). Проводится в конце спринта. Команда демонстрирует прирост функциональности продукта всем заинтересованным лицам. 5. Ретроспективное совещание (1-3 часа). Проводится в конце спринта. Члены команды высказывают своё мнение о прошедшем спринте и отвечают на два основных вопроса: – что было сделано хорошо в прошедшем спринте? – что надо улучшить в следующем?

Изображение слайда
65

Слайд 65: SCRUM

Изображение слайда
66

Слайд 66: Экстремальное программирование

Экстремальное программирование (англ. Extreme Programming, XP) – гибкая методология разработки ПО в условиях неясных или быстро меняющихся требований для небольших и средних по размеру команд разработчиков.

Изображение слайда
67

Слайд 67: Экстремальное программирование

Экстремальное программирование (англ. Extreme Programming, XP) – гибкая методология разработки ПО в условиях неясных или быстро меняющихся требований для небольших и средних по размеру команд разработчиков. Двенадцать основных приёмов экстремального программирования (по первому изданию книги  Extreme programming explained ) могут быть объединены в четыре группы: Короткий цикл обратной связи ( Fine-scale feedback) Разработка через тестирование ( Test-driven development) Игра в планирование ( Planning game) Заказчик всегда рядом ( Whole team, Onsite customer) Парное программирование ( Pair programming) Непрерывный, а не пакетный процесс Непрерывная интеграция ( Continuous integration) Рефакторинг ( Design improvement, Refactoring) Частые небольшие релизы ( Small releases) Понимание, разделяемое всеми Простота ( Simple design) Метафора системы ( System metaphor) Коллективное владение кодом ( Collective code ownership) или выбранными шаблонами проектирования ( Collective patterns ownership) Стандарт кодирования ( Coding standard or Coding conventions) Социальная защищённость программиста ( Programmer welfare): 40- часовая рабочая неделя ( Sustainable pace, Forty-hour week)

Изображение слайда
68

Слайд 68: KANBAN

KANBAN (Канбан) – гибкая методология разработки ПО, ориентированная на задачи. В KANBAN, по сравнению со SCRUM, важнее решить качественно задачу, чем уложиться в сроки. Весь Канбан можно описать следующими правилами: 1.   Визуализируйте разработку: – разделите проект на задачи, каждую задачу напишите на карточке и поместите на стену или доску; – используйте специальные отметки, чтобы показать положение задачи в разработке. 2.   Ограничивайте количество параллельных процессов. 3. Опирайтесь на уже существующие методы разработки. 4. Поощряйте небольшие и эволюционные изменения, критично относитесь к революционным. 5. Уважайте существующий порядок, роли и обязанности. 6. Приветствуйте проявление инициативы. Попробуем приблизительно описать, как же Канбан применяется на практике. Представьте себе коллектив программистов, перед которыми стоит задача разработки некоторого проекта ПО. В этой задаче выделятся подзадачи, их записывают на листочках (обычно разноцветных) и вывешивают на доску. Каждый желающий может подойти к доске и приклеить стикер со своим именем, который будет обозначать, что он взялся выполнять эту работу. По мере выполнения листики будут перемещаться с левого на правый край доски.

Изображение слайда
69

Слайд 69: Dynamic System Development Method

DSDM появился в 1994 году. Он фокусируется на проектах информационных систем, характеризующихся сжатыми сроками и бюджетами, при этом особый упор делается на высоком качестве работы и адаптируемости к изменениям в требованиях. Базовые принципы, на которых строится DSDM, это активное взаимодействие с пользователями, частые выпуски версий, самостоятельность разработчиков в принятии решений и тестирование в течение всего цикла работ. Как и большинство других гибких методологий, DSDM использует короткие итерации, продолжительностью от двух до шести недель каждая. Метод разработки динамических систем ( Dynamic Systems Development Method, DSDM) – гибкая методология разработки ПО, основанная на концепции быстрой разработки приложений ( Rapid Application Development, RAD), использует итеративную модель.

Изображение слайда
70

Слайд 70: Microsoft Solutions Framework

MSF опирается на практический опыт Microsoft и описывает управление людьми и рабочими процессами в процессе разработки решения. Базовые концепции и принципы модели процессов MSF: –   единое видение проекта – все заинтересованные лица и просто участники проекта должны чётко представлять конечный результат, всем должна быть понятна цель проекта; –   управление компромиссами – поиск компромиссов между ресурсами проекта, календарным графиком и реализуемыми возможностями; –   гибкость – готовность к изменяющимся проектным условиям; –   концентрация на бизнес-приоритетах – сосредоточенность на той отдаче и выгоде, которую ожидает получить потребитель решения; –   поощрение свободного общения внутри проекта; –   создание базовых версии – фиксация состояния любого проектного артефакта, в том числе программного кода, плана проекта, руководства пользователя, настройки серверов и последующее эффективное управление изменениями, аналитика проекта. MSF предлагает проверенные методики для планирования, проектирования, разработки и внедрения успешных IT-решений. Благодаря своей гибкости, масштабируемости и отсутствию жестких инструкций MSF способен удовлетворить нужды организации или проектной группы любого размера. Методология MSF состоит из принципов, моделей и дисциплин по управлению персоналом, процессами, технологическими элементами и связанными со всеми этими факторами вопросами, характерными для большинства проектов. Microsoft Solutions Framework ( MSF ) – методология разработки ПО, предложенная корпорацией Microsoft.

Изображение слайда
71

Слайд 71: Rational Unified Process

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

Изображение слайда
72

Слайд 72: Rational Unified Process

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

Изображение слайда
73

Слайд 73: Лекция № 9. UML

UML ( Unified Modeling Language – унифицированный язык моделирования) – язык графического описания для объектного моделирования в области разработки ПО. CASE -средств а с поддержкой UML : –  Sybase Power Designer –  MS Visio –  Dia –  SmartDraw –  Enterprise Architect –  Umbrello –  ArgoUML –  UModel –  Rational Rose –  Visual Paradigm –  QReal Существует достаточно большой объем CASE -средств, позволяющих разрабатывать ПО, используя диаграммы UML.

Изображение слайда
74

Слайд 74: Диаграмма сценариев использования

Эта диаграмма должна демонстрировать, кто и каким образом работает с системой. Связи между актерами и вариантами отображаются с использованием отношений четырех видов: –   ассоциаций – обозначает взаимодействие актера с вариантом использования; –   обобщения – показывает возможность обобщения одной сущности (актер, вариант использования) к другой; –   включения – указывает, что один вариант использования обязательно включается в качестве составного компонента в другой варианта использования; –   расширения – указывает, что один вариант использования может включаться в качестве составного компонента в другой варианта использования. Актер (в UML ) – любой объект, субъект или система, взаимодействующая с моделируемой системой извне. Это может быть человек, техническое устройство или другая система, которая может служить источником воздействия на моделируемую систему Например, чтобы использовать элементы такой UML -диаграммы в MS Visio следует выбрать: Дополнительные фигуры → Программы и базы данных → Программное обеспечение → Сценарий выполнения UML.

Изображение слайда
75

Слайд 75: Диаграмма сценариев использования

Изображение на диаграмме Описание Актер (в UML ) – любой объект, субъект или система, взаимодействующая с моделируемой системой извне; это может быть человек, техническое устройство или другая система Ассоциация – обозначает взаимодействие актера с вариантом использования Обобщение – показывает возможность обобщения одной сущности (актер, вариант использования) к другой <<include>> Включение – указывает, что один вариант использования обязательно включается в   качестве составного компонента в другой варианта использования; <<extend>> Расширения – указывает, что один вариант использования может включаться в   качестве составного компонента в другой варианта использования Админ Пользователь

Изображение слайда
76

Слайд 76: Диаграмма сценариев использования

Изображение слайда
77

Слайд 77: Диаграмма сценариев использования

Изображение слайда
78

Слайд 78: Диаграмма состояний

После создания одной или нескольких диаграмм вариантов использования системный аналитик с заказчиком определяют приоритетность проработки вариантов использования и детализируют их. Главная цель данной процедуры – поиск ответа на вопрос: «В процессе какого поведения система обеспечит необходимую функциональность?». В UML имеется несколько видов диаграмм, позволяющих детализировать варианты использования, – это диаграммы поведения. Первой из них мы рассмотрим диаграмму состояний. Диаграмма состояний ( State Machine diagram, диаграмма конечного автомата) – диаграмма, которая используются для описания поведения, реализуемого в рамках варианта использования. Начальное и конечное состояния: а – начальное состояние; б – конечное состояние

Изображение слайда
79

Слайд 79: Диаграмма состояний

Переход ( Transition ) – это отношение между состояниями, показывающее возможный путь изменения состояния. Состояние ( State ) – это ситуация в жизни объекта, на протяжении которой он удовлетворяет некоторому условию, осуществляет определенную деятельность или ожидает какого-то события. В UML определены два специальных псевдосостояния: начальное и конечное. Характеристика состояния может содержать описание выполняемых операций, перед которыми указывается одна из стандартных меток: – entry (вход) – действие при входе, выполняемое вне зависимости от того, по какому переходу был выполнен вход в состояние (например, создать соединение с базой данных: entry / createConnect()); – exit (выход) – действие при выходе, выполняемое вне зависимости от того, по какому переходу был выполнен выход из состояния (например, закрыть соединение с базой данных: exit / closeConnect()); – do (выполнять) – деятельность в состоянии: объект может бездействовать и ждать наступления некоторого события, а может выполнять длительную операцию (например, проводить расчет: do / calculate()); – newTarget (новое задание) – внутренний переход, предписывающий обработку новых событий, не покидая текущего состояния; при выполнении внутреннего перехода повторно не выполняются действия при входе или выходе из состояния (например, временная остановка (прерывание) расчета: newTarget / pauseCalculate()); – defer (отложить) – отложенное событие, обработка которого предписывается в другом состоянии, но после того, как все операции в текущем будут завершены (например, отображение на экране сообщения об ошибках в исходных данных defer / showDataError()).

Изображение слайда
80

Слайд 80: Диаграмма последовательности

Диаграмма последовательности ( Sequence diagram ) – диаграмма, на которой изображено упорядоченное во времени взаимодействие объектов

Изображение слайда
81

Слайд 81: Диаграмма последовательности

Изображение на диаграмме Описание Фокус управления – показывает, что объект находиться в активном состоянии непосредственно выполняя определенные действия, или в состоянии пассивного ожидания сообщений от других объектов. Уничтожение объекта – показывается в конце линии жизни, если объект выполнил свою роль в системе, он уничтожается, чтобы освободить занимаемые ими ресурсы. Синхронное сообщение – подразумевает ожидание ответа от объекта получателя и передачу фокуса управления Асинхронное сообщение – подразумевает, что объект может продолжать работу, не ожидая ответа, фокус управления не передается Возвращаемое сообщение – ответное сообщение от объекта (показывается на диаграмме по мере необходимости) Рефлексивное сообщение – сообщение объекта самому себе Диаграмма последовательности является одной из диаграмм взаимодействия, она используется для представления временных особенностей передачи и приема сообщений между объектами. Графически каждый объект изображается прямоугольником и располагается в верхней части. Крайним слева на диаграмме изображается объект, который является инициатором взаимодействия. Линия жизни объекта (изображается пунктирной вертикальной линией) служит для обозначения периода времени, в течение которого объект существует в системе и, следовательно, может потенциально участвовать во всех ее взаимодействиях. MS Visio: Дополнительные фигуры → Программы и базы данных → Программное обеспечение → Последовательности UML.

Изображение слайда
82

Слайд 82: Диаграмма деятельности

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

Изображение слайда
83

Слайд 83: Диаграмма классов

Диаграмма классов ( Class diagram ) – диаграмма, описывающая структуру системы, демонстрирующая классы системы, их атрибуты, методы и зависимости между классами. Изображение на диаграмме Описание Обобщение ( генерализация, наследование) показывает, что один из двух связанных классов (подтип), является более частной формой другого ( супертип ), который называется обобщением первого. Например, каждый программист является человеком, но не каждый человек – программист. Графически генерализация представляется линией с пустым треугольником у супертипа Ассоциация Агрегация – случай ассоциации, применяемый, когда один класс должен быть контейнером других классов. Причем время существования содержащихся классов никак не зависит от времени существования класса контейнера. Например, если некий ВУЗ расформируют – это вовсе не означает, что мы должны будем потерять информацию о студентах, которые в нем учились – их вполне могут перевести в другие ВУЗы. Графически агрегация представляется пустым ромбиком на блоке класса и линией, идущей от этого ромбика к содержащемуся классу Композиция – случай ассоциации, но более строгий. В отличии от агрегации, композиция имеет жёсткую зависимость времени существования экземпляров класса контейнера и экземпляров содержащихся классов. Если контейнер будет уничтожен, то всё его содержимое будет уничтожено также. Например, при удалении ВУЗа будут удалены все его структурные подразделения Графически представляется, как и агрегация, но с закрашенным ромбиком

Изображение слайда
84

Слайд 84: Лекция № 10. CASE и подходы к проектированию

CASE ( Computer-Aided Software Engineering ) — набор инструментов и методов программной инженерии для проектирования программного обеспечения, который помогает обеспечить высокое качество программ, отсутствие ошибок и простоту в обслуживании программных продуктов. Также под CASE понимают совокупность методов и средств проектирования информационных систем с использованием CASE-инструментов. Средства автоматизации разработки программ (CASE-средства) — инструменты автоматизации процессов проектирования и разработки программного обеспечения для системного аналитика, разработчика ПО и программиста. Первоначально под CASE-средствами понимались только инструменты для упрощения наиболее трудоёмких процессов анализа и проектирования, но с приходом стандарта ISO/IEC 14102 CASE-средства стали определять как программные средства для поддержки процессов жизненного цикла ПО.

Изображение слайда
85

Слайд 85: CASE

Основной целью CASE-технологии является разграничение процесса проектирования программных продуктов от процесса кодирования и последующих этапов разработки, максимально автоматизировать процесс разработки. Для выполнения поставленной цели CASE-технологии используют два принципиально разных подхода к проектированию: структурный и объектно-ориентированный. Структурный подход предполагает декомпозицию (разделение) поставленной задачи на функции, которые необходимо автоматизировать. В свою очередь, функции также разбиваются на подфункции, задачи, процедуры. В результате получается упорядоченная иерархия функций и передаваемой информацией между функциями. Структурный подход подразумевает использование определенных общепринятых методологий при моделировании различных информационных систем: SADT (Structured Analysis and Design Technique); DFD (Data Flow Diagrams); ERD (Entity-Relationship Diagrams). Существует три основных типа моделей, используемых при структурном подходе: функциональные, информационные и структурные. Основным инструментом объектно-ориентированного подхода является язык UML — унифицированный язык моделирования, который предназначен для визуализации и документирования объектно-ориентированных систем с ориентацией их на разработку программного обеспечения. Данный язык включает в себя систему различных диаграмм, на основании которых может быть построено представление о проектируемой системе.

Изображение слайда
86

Слайд 86: SADT

SADT (акроним Structured Analysis and Design Technique ) — методология структурного анализа и проектирования, интегрирующая процесс моделирования, управление конфигурацией проекта, использование дополнительных языковых средств и руководство проектом со своим графическим языком. В основе методологии SADT лежат два основных принципа: 1. SA-блоки, на основе которых создается иерархическая многоуровневая модульная систе м а, каждый уровень которой представляет собой законченную систему (блок), поддерживаемую и контролируемую системой (блоком), находящейся над ней. 2. Декомпозиция. Использование этой концепции позволяет разделить каждый блок, понимаемый как единое целое, на свои составляющие, описываемые на более детальной диаграмме. Процесс декомпозиции проводится до достижения нужного уровня подробности описания. Диаграмма ограничивается 3-6 блоками для того, чтобы детализация осуществлялась постепенно. Вместо одной громоздкой модели используется несколько небольших взаимосвязанных моделей, значения которых взаимно дополняют друг друга, делая понятной структуризацию сложного объекта. Применение SADT методологии основано на формализованном процессе создания системы, при разбиении его на следующие фазы: анализ - определение того, что система будет делать; проектирование - определение подсистем и их взаимодействие; реализация - разработка подсистем по отдельности; объединение - соединение подсистем в единое целое; тестирование - проверка работы системы; установка - введение системы в действие; функционирование - использование системы. SADT = IDEFX

Изображение слайда
87

Слайд 87: IDEF0

IDEF0 — методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов. В IDEF0 различают 4 типа дуг: 1) вход ( Input ) – материал или информация, которые используются или преобразуются блоком для получения результата (выхода). Блок может не иметь ни одной входной дуги. Данный вид дуги поступает на левую сторону блока. 2) управление ( Сontrol ) – условия, правила, стратегии, стандарты, которые влияют на выполнение функции. Каждый блок должен иметь хотя бы одну дугу управления. Данный вид дуг поступает на верхнюю сторону блока. 3) выход ( Output ) – результат выполнения функции (материал или информация). Каждая функция должна иметь хотя бы одну выходную дугу. Данный вид дуг выходит из правой стороны блока. 4) механизм ( Mechanism ) – ресурсы, с помощью которых выполняется работа. Это могут быть, например, денежные средства, персонал предприятия, станки. Данный вид дуг поступает на нижнюю сторону блока. Отличительной особенностью IDEF0 является её акцент на соподчинённость объектов. В IDEF0 рассматриваются логические отношения между работами, а не их временная последовательность.

Изображение слайда
88

Слайд 88: IDEF 1, IDEF1X

IDEF1 ( Information Modeling ) — одна из методологий семейства IDEF. Применяется для построения информационной модели, которая представляет структуру информации, необходимой для поддержки функций производственной системы или среды. Применяется для построения информационной модели, которая представляет структуру информации, необходимой для поддержки функций производственной системы или среды. Метод IDEF1, разработанный Т. Рэмей (T. Ramey ), также основан на подходе П. Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме. В настоящее время на основе совершенствования методологии IDEF1 создана ее новая версия — методология IDEF1X. IDEF1X разработана с учетом таких требований, как простота изучения и возможность автоматизации. IDEF1X-диаграммы используются рядом распространённых CASE-средств (в частности, ERwin, Design /IDEF).

Изображение слайда
89

Слайд 89: IDEF 3

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

Изображение слайда
90

Слайд 90: DFD

DFD (Data Flow Diagrams) — диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ. Диаграмма потоков данных (DFD ) — один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML. Несмотря на имеющее место в современных условиях смещение акцентов от структурного к объектно-ориентированному подходу к анализу и проектированию систем, «старинные» структурные нотации по-прежнему широко и эффективно используются как в бизнес-анализе, так и в анализе информационных систем. Исторически сложилось так, что для описания диаграмм DFD используются две нотации — Йордана (Yourdon) и Гейна-Сарсона (Gane-Sarson), отличающиеся синтаксисом.

Изображение слайда
91

Слайд 91: ER- модель

Модель сущность-связь (ER-модель) ( entity-relationship model, ERM) — модель данных, позволяющая описывать концептуальные схемы предметной области. ER-модель используется при высокоуровневом (концептуальном) проектировании баз данных. С её помощью можно выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями. Во время проектирования баз данных происходит преобразование ER-модели в конкретную схему базы данных на основе выбранной модели данных (реляционной, объектной, сетевой или др.). ER-модель представляет собой формальную конструкцию, которая сама по себе не предписывает никаких графических средств её визуализации. В качестве стандартной графической нотации, с помощью которой можно визуализировать ER-модель, была предложена диаграмма сущность-связь (ER-диаграмма) (entity-relationship diagram, ERD). Понятия ER-модель и ER-диаграмма часто ошибочно не различают, хотя для визуализации ER-моделей предложены и другие графические нотации.

Изображение слайда
92

Слайд 92: Основные понятия ER- диаграмм

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

Изображение слайда
93

Последний слайд презентации: Технологии информационной поддержки жизненного цикла объектов аэрокосмической: Виды обеспечения

Изображение слайда