Разработка системы автоматизированной поддержки информационных решений технологических задач на основах объектно-ориентированного анализа : На примере задачи раскроя материала для мелкосерийного производства

• Автор: Болотников, Максим Юрьевич
• Шифр специальности: 05.13.06
• Научная степень: Кандидатская
• Год защиты: 2001
• Место защиты: Москва
• Количество страниц: 184 с. : ил

СОДЕРЖАНИЕ
Введение

1. Анализ состояния вопроса и постановка задачи исследования

1.1. Архитектура

1.2. Применение принципов технологии

1.3. Жизненный цикл программного изделия и его критичные этапы

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

2. Особенности построения прикладных систем в рамках i с

использованием принципа сам себе программист

2.1. Ограничения традиционных систем технологической подготовки производства ТПП

2.2. Отличия старого и нового понимания ТПП

2.3. Обоснование разработки ПО на принципах самоорганизации
2.4. Проектирование и реализация корпоративного ПО
3. Проведение анализа условий выполнения работ на производстве
3.1. Консалтинг при автоматизации технологического процесса
3.1.1. Цели и этапы разработки консалтингового проекта
3.1.2. Анализ первичных требований
3.1.3. Проведение обследования технологического процесса
3.1.4. Построение модели как есть
4. Структура и состав разрабатываемой системы автоматизированной
поддержки информационных решений САПИР при раскрое
4.1. Использование объектноориентированного анализа при
проектировании САПИР м но го ном е н к лату р но го раскроя материала
4.2. Программная структура системы автоматизированной поддержки информационных решений при раскрое
4.2.1. Режим регистрации и редактирования деталей в САПИРТПМР
4.2.2. Режим регистрации и редактирования заданий на раскрой в САПИРТПМР
4.2.3. Режим регистрации и редактирования карт раскроя в САПИРТПМР
4.2.3.1. Режим графического редактирования карт раскроя в САПИРТПМР
4.2.4. Режим регистрации и редактирования карт проходов в САПИРТПМР
4.2.4.1. Режим графического редактирования карт проходов в САПИРТПМР.
4.2.5. Режим регистрации и редактирования отчетов в САПИРТПМР
4.2.6. Режим регистрации и редактирования марок материалов в САПИРТПМР
4.2.7. Режим регистрации и редактирования листовых заготовок в САПИРТПМР
5. Методика использования САПИР раскроя в производственных
условиях при технологической подготовке производства
5.1. Регистрация деталей в базе данных деталей
5.2. Занесение деталей в задание на раскрой и регистрация задания на раскрой базе данных заданий на раскрой
5.3. Регистрация и редактирование карты раскроя в базе данных карт раскроя
5.3.1. Графическое редактирование карты раскроя
5.4. Регистрация и редактирование карты проходов в базе карт проходов
5.4.1. Графическое редактирование карты проходов
5.5. Регистрация и редактирование отчетных документов в
таблице отчетов
Общие выводы и результаты работы
Литература


Преобразования существующей структуры технологического процесса к состоянию, определенному как долгосрочная цель: архитектура должна не просто описывать текущую ситуацию — но и предлагать перспективную концепцию. Очень важно, когда она определяет ясный и оптимальный путь от текущего состояния к достижению долгосрочных целей. Текущие и перспективные задачи технологического процесса: любой проект может оказаться бесполезным, если он не учитывает как текущую ситуацию, так и перспективы развития бизнеса и производственных процессов. С другой стороны, бизнес-планы часто формируются под влиянием достижений ИТ; например, развитие доступа в Интернет заставило многие компании срочно создавать подразделения электронной коммерции. При выработке программной архитектуры разработчика подстерегают некоторые опасности, способные снизить шансы успешной реализации проекта. Отсутствие четкой формулировки целей. Без компетентного планирования и ясного видения целей развития автоматизации технологического процесса программная архитектура не поможет. Единственная возможность прогресса — это движение к четко сформулированной цели. Противоположностью прогрессу может быть регресс или хождение по кругу. Отсутствие обратной связи и коррекции курса. Создание архитектуры автоматизированной системы должно быть общим процессом, в который вовлечены пользователи автоматизированной системы, владельцы бизнеса и разработчики автоматизированной системы. Всегда наступает момент, когда планы пора претворять в жизнь, а эксплуатацией автоматизированной системы занимаются пользователи на местах. Без обратной связи с людьми, выполняющими конкретную работу, архитектура, хорошо выглядевшая на бумаге, на деле оказывается неудобной или просто не работает. Еще одна распространенная проблема: условия бизнеса и приоритеты меняются именно в то время, когда разработка архитектуры автоматизированной системы идет полным ходом. Кроме того, более новые и более мощные технологии часто вытесняют технологии, первоначально предлагавшиеся для решения проблем, перечисленных в плане. В отсутствии обратной связи и периодической корректировки курса усилия по разработке архитектуры автоматизированной системы не дают желаемого результата. Недостаток интеграции и стабильности. Даже когда отдельные решения автоматизации уже работают, они часто не интегрированы в общую производственную архитектуру. Недостаточное внимание реализации. Архитектура автоматизированной системы включает не просто проект, но и возможность его реализации. Приложение должно быть создано, а инфраструктура — развернута. Все, что определено в архитектуре, следует выполнить в разумные сроки с разумными затратами. Часто, тем не менее, архитектура оказывается оторванной от реальности. Архитектура автоматизированной системы может содержать перспективные задачи, однако приоритет должен оставаться за основополагающими вопросами и практическими способами их реализации. В последнее время ключевой технологией интеграции, которая наводит мосты между деловыми-процессами, информацией и исполнителями ролей, необходимых для их реализации, объединяет унаследованные приложения и программное обеспечение настольных систем в гибкую и хорошо адаптируемую распределенную инфраструктуру, называют workflow-системы (управление потоком работ). По определению консорциума WfMC (Workflow Management Coalition — коалиция управления потоками работ) [], управление потоком работ представляет собой "полную или частичную автоматизацию бизнес-процессов, в ходе которых документы, информация и задачи пересылаются для обработки от одного участника к другому в соответствии с определенными процедурными правилами". Соответственно при моделировании архитектуры автоматизированной системы, которая должна в будущем легко интегрироваться в комплексную систему предприятия, необходимо представить автоматизируемый технологический процесс не в виде функциональной схемы, а в виде делового-процесса. Приведенная на рис. V- . Роли ! Рис. Система автоматизации деловых процессов (система класса workflow) - программное обеспечение, служащее для описания и обеспечения выполнения бизнес-процессов предприятия.