Автоматизированная информационная система программирования логики промышленных роботов для ООО "ВМЗ"

Дипломная работа - Компьютеры, программирование

Другие дипломы по предмету Компьютеры, программирование

?зводить реверс кода.

.Поддержка ОС 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 - степень удо