Автоматизированная информационная система программирования логики промышленных роботов для ООО "ВМЗ"
Дипломная работа - Компьютеры, программирование
Другие дипломы по предмету Компьютеры, программирование
?зводить реверс кода.
.Поддержка ОС Windows.
.Стоимость приобретения.
.Опыт успешного использования (отзывы).
.Простота освоения и использования.
Все критерии кроме стоимостного оценивается следующими балами:
- не удовлетворят требованию
- частично удовлетворяет требованию
- полностью удовлетворяет требованию
При разработке проекта важно разработать требуемую систему с наименьшими затратами. Использование недорогих или свободно распространяемых программных средств позволяет снизить затраты на разработку. Поэтому стоимостной критерий является наиболее важным и его баллы при выборе программных средств для разработки выше.
- высокая стоимость;
- средняя стоимость;
- бесплатно.
Выбор CASE-средства представлен в таблице 3.
Таблица 3 - Исходные данные для выбора CASE-средства
Visual ParadigmRational RoseBorland Together ArgoUML Netbeans UML Plugin Eclipse Omondo Plugin Enterprise Architect Возможность генерации программного кода 1000105010Возможность производить реверс кода10001001010Поддержка ОС Windows1010100101010Стоимость приобретения2001020201010Опыт успешного использования (отзывы)101010100510Простота освоения и использования.105101010510ИТОГ:70254060454060
Анализ показал, что наиболее подходящее для проектирования CASE-средство это Visual Paradigm.
В донном подразделе определено, что для разработки автоматизированной информационной системы программирования логики промышленных роботов будет использоваться модель RAD (быстрая разработка приложений). Проектирование будет производиться в CASE-средстве Visual Paradigm.
1.4 Разработка архитектуры автоматизированной системы программирования логики промышленных роботов
Автоматизированная информационная система программирования логики промышленных роботов генерирует сборку файлов программ для промышленных роботов. В процессе внедрения и отладки программ файлы сборки модифицируются. Также файлы могут меняться при проведении запланированной модернизации на уже запущенном и отлаженном комплексе. В результате подобных изменений появляются версии сборок программ. Для их структуризации и упорядочения предлагается внедрить систему управления версий. Система управления версиями (от англ. Version Control System, VCS или Revision Control System) - программное обеспечение для облегчения работы с изменяющейся информацией. Система управления версиями позволяет хранить несколько версий одного и того же документа, при необходимости возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение, и многое другое[15]. Система будет внедрена на сервере, где будет располагаться центральное хранилище файлов. АИС будет работать с системой управления версий локальную сеть. В настоящее время имеется достаточное количество систем управления версиями. На основе информационного поиска из списка систем управления версиями, представленного в источнике [16], выделены самые используемые системы управления версиями:
1.Subversion [17].
2.Arch [18].
.Monotone [18].
.OpenCM [18].
.Aegis [18].
.Darcs [19].
.Git [20].
Для формирования критериев и их оценки необходимо определиться с архитектурой репозитариев и методом хранения изменений.
Репозитарии бывают централизованные и рассредоточенные. Централизованная архитектура изображается как центральный репозиторий ресурсов и множество разработчиков работающих с ним. Разработчик выгружает код из центрального репозитория на локальную машину (check out), и после внесения изменений, фиксирует их и загружает обратно в центральный репозиторий (commit), таким образом, и другие разработчики имеют доступ к его изменениям.
Рассредоточенный подход позволяет разработчикам работать со своими изолированными репозиториями, а не с локальными машинами. Они могут делать изменения, вносить их в свои локальные репозитории и синхронизировать изменения с другими разработчиками, не трогая главную ветку. Затем разработчики могут сделать набор изменений, доступный своим "вышестоящим" коллегам.[21]
Программированием и модернизацией сборки программ для робота занимается один программист, следовательно, нет надобности использовать распределённую архитектуру репозиториев.
Модели хранения версий бывают: модель "моментальных снимков" (snapshot model) и модели "набора изменений" (changeset model). В модели "моментальных снимков" хранятся файлы целиком для каждой версии (с оптимизацией размера дерева). В модели "набора изменений", хранится только разница в версиях, создавая компактный репозиторий. [21] В процессе настройки производственной ячейки возможен возврат к любой другой версии сборки программы или использование какой-либо версии сборки для другой ячейки. Это требование определяет, что наиболее подходящей моделью хранения версий является модель "моментальных снимков".
Критерии выбора системы управления версиями:
1.Перемещение и переименование файлов и директорий.
2.Копирование файлов и директорий.
.Подробная история построчных изменений.
.Возможность получения отдельной директории из репозитория.
.Контроль изменений в рабочей копии, до commitа в репозиторий.
Критерии с 1 по 5 оцениваются следующими баллами:
- система не удовлетворяет критерию;
- система удовлетворяет критерию.
6.Задание отдельного текста комментария для отдельного файла при commitе.
Этот критерий является важным для работы со сборками программ, поэтому баллы его оценки выше.
..5 - степень удовлетворения критерия.
7.Простота установки.
0..3 - степень удо