Размещено на http://www.allbest.ru/

Выпускная квалификационная работа

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

Студент:

Беззубенко Е.А.

Москва 2019



Аннотация

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

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

This coursework presents the basic principles of the editing systems of technological and operational documentation, as well as an overview, analysis and comparison of existing software solutions designed to work with documentation. The methods of working with documentation, the principles of its creation and editing are investigated. Identified problems of working with different types of documents. An analysis of existing software tools that provide similar capabilities with the developed system. Methods for developing the main components of the program, necessary for the full implementation of the system, are proposed.

As a result of the above works, information obtained during the research was collected and processed. A system that implements the basic functions necessary for the creation and full-fledged work with technological and operational documentation has been developed.



Оглавление

Введение

1. Обзор предметной области

1.1 Анализ нормативных документов создания документации

1.2 Обзор существующих аналогов

2. Разработка программы

2.1 Выбор программных средств

2.2 Структура проектов на языке программирования Delphi

2.3 Описание проекта

2.4 Описание функций программы

2.5 Описание базы данных

Заключение

Список использованных источников

Приложение



Введение

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

Как написание простого текста не представляется возможным без качественного текстового редактора, так и создание сложной технической документации крайне затруднительно без вспомогательных инструментов. В связи с этим разработка технической документации представляется затруднительной задачей для разработчиков. Процесс её формирования представляет собой кропотливую и монотонную работу. Для составления инструкций по эксплуатации зачастую требуется подробное описание функций с множеством пояснений и аннотаций. В зарубежных странах профессиональные инструменты для создания технической документации распространены достаточно широко и пользуются популярностью у любого типа компаний. В то же время, имеющееся в настоящий момент на рынке России и СНГ программное обеспечение не покрывает всех потребностей технических писателей по автоматизации их работы. [6]

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

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

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

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

2. Ознакомиться и изучить существующие системы для разработки конструкторской документации;

3. Провести анализ и сравнение систем для разработки конструкторской документации;

4. Провести проектирование и нормализацию базы данных;

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

6. Разработать основное приложение и пользовательского интерфейса;

7. Протестировать и проанализировать полученные результаты.

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

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

1. Обзор предметной области

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

В составе технической документации выделяют:

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

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

3. программные документы, сопровождающие программы для электронно-вычислительных машин (программные средства).

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

Рис. 1. Процесс разработки технической документации

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

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

1.1 Анализ нормативных документов создания документации

Единая система конструкторской документации

В 1928 году конструкторская документация стала объектом государственной стандартизации. Зачастую возникали проблемы с использованием документов при их передаче из одного места в другое, обусловленные отсутствием единой системы и правил разработки и оформления документов. Данное положение вызывало необходимость внедрения изменений. Результатом работы стало создание организованного набора правил разработки и оформления документации и чертежей - Единой системы конструкторской документации, утвержденной в 1968 г. Данная система функционирует и в настоящее время, продолжая модифицироваться и развиваться. [5]

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

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

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

В Единой системе конструкторской документации также определяются стадии и этапы разработки конструкторской документации.

По государственным стандартам набор правил ЕСКД разделен на следующие группы:

1. стандарты группы 0 - «Общие положения ЕСКД»



Рис. 2. Примеры организации данных в электронных конструкторских документах

К данной группе относятся стандарты, в которых устанавливается область документов, на которые распространяется ЕСКД, а также назначение и состав данного комплекса;

2. Стандарты первой группы

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

3. Стандарты второй группы

Во второй группе определяются различные типы и классы конструкторской документации, порядок её маркировки и обозначения;

4. Стандарты третьей группы

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

5. Стандарты четвертой группы

6. Стандарты пятой группы

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

7. Стандарты шестой группы

Стандарты данной группы уточняют вышеописанные общие положения и требования к эксплуатационной и ремонтной документации;

8. Стандарты седьмой группы

9. Стандарты восьмой группы

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

10. Стандарты девятой группы

В данную группу включают все стандарты, не вошедшие в стандарты других групп.

Единая система технологической документации

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

Единая система технологической документации (ЕСТД) - комплекс межгосударственных стандартов и рекомендаций, устанавливающих взаимосвязанные правила и положения по порядку разработки, комплектации, оформления и обращения технологической документации, применяемой при изготовлении, контроле, приемке и ремонте (модернизации) изделий (включая сбор и сдачу технологических отходов).[8] Первый комплекс стандартов ЕСТД был введен в действие в 1974 г. Данный комплекс предназначен для следующих целей:

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

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

3. Установление общих для всех типов документов требований и правил по оформлению в зависимости от степени детализации разбора и описания этапов технологического проектирования;

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

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

6. Обеспечение взаимосвязи комплекса стандартов с уже существующими общетехническими и организационно-методическими стандартами.

Комплекс стандартов ЕСТД аналогично системе ЕСКД подразделяется на 10 групп с номерами от 0 до 9. Система стандартов устанавливает общие правила, требования и нормы по созданию, оформлению и редактированию технологической документации, а также её корректному документообороту.

1.1.1. Единая система программной документации

Единая система программной документации (ЕСПД) - комплекс государственных стандартов, устанавливающих взаимоувязанные правила разработки, оформления и обращения программ и программной документации.[9]

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

1.2 Обзор существующих аналогов

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

Основными критериями оценки программного продукта будут являться:

- поддержка различных форматов документов

- наличие возможности импорта готовых шаблонов

- возможность контроля доступа пользователя к базе данных шаблонов

- возможность интеграции в другие платформы

- возможность бесплатного использования

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

Doxygen

Doxygen является стандартным инструментом для создания документации из аннотированных источников на C++, но также поддерживает другие популярные языки программирования, такие как C, Objective-C, C#, PHP, Java, Python, IDL (Corba, Microsoft, и UNO/OpenOffice), Fortran, VHDL, Tcl. [1]

Doxygen обладает возможностью генерации онлайн документации в формате HTML, а также автономное справочное руководство в формате LaTeX из набора документированных исходных файлов. Также поддерживается генерация вывода в файлы формата RTF, PostScript, гиперссылках DPF, сжатых HTML и справочных страницах Unix. Основным недостатком платформы является его частичная кроссплатформенность. Продукт ориентирован на операционные системы Mac OS X и Linux, некоторые функции на ОС Windows, которая является первоочередной операционной системой в требованиях к работе, не поддерживаются. Как сказано выше, данная программа ориентирована на создание документации для исходного кода программ, хоть и имеет функции для создания обычной технической документации, но данный комплект функций крайне ограничен и не доступен обычному пользователю в связи с иной специализацией системы. Кроме того, документация, созданная в Doxygen, плохо переносится на другие платформы, так как исходные файлы программы имеют собственное форматирование.

MadCap Flare

MadCap Flare - это программное приложение, используемое для создания, управления и публикации технической документации. Основные функции включают запатентованный редактор XML, многоканальную публикацию, единый источник и интегрированное облачное редактирование, публикацию, управление проектами и контентом. [2] Интерфейс программы представлен на рисунке ниже (Рис. 3):



Рис. 3. Интерфейс MadCap Flare

Особенностями данного продукта являются:

- усовершенствованный XML-авторинг из одного источника;

- поддержка многоканальной публикации;

- поддержка редактирования документов формата DOC, EXCEL, CHM, HTML, XML, а также индивидуальных файлов различных форматов

- редактор таблицы стилей

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

Несмотря на все достоинства и особенности MadCap Flare, основным недостатком данного продукта является ценовая политика разработчиков. Цена месячной лицензии составляет 249 долларов, что является слишком высокой ценой на рынке редакторов технической документации.

Oracle UPK

Oracle UPK представляет собой среду для совместной разработки для создания системных ресурсов, которые используются на протяжении всего жизненного цикла проекта. Благодаря возможности создания нескольких выходных данных за один сеанс записи, Oracle UPK сокращает время и стоимость разработки контента. Также позволяет быстро создавать материалы для всех этапов жизненного цикла программного обеспечения - от сценариев тестирования, документов о системных процессах и интерактивных симуляций до рабочих пособий, руководств для инструкторов и поддержки производительности в приложении. [3]

Особенностями данного программного комплекса являются:

- поддержка 22 языков

- возможность интеграции с основными ERP системами

- наличие подробной документации пользователя

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

SAP Enable Now

SAP - немецкая компания, являющаяся лидером на рынке прикладного программного обеспечения для предприятий, помогая компаниям всех размеров и во всех отраслях работать наилучшим образом: 77% мирового дохода от транзакций касается системы SAP. Система SAP Enable Now помогает повысить степень адаптации пользователей и эффективность программных продуктов на предприятиях, создавая мощный контент для электронного обучения сотрудников. [4]

SAP Enable Now обладает следующими особенностями:

- локальное или облачное развертывание

- настраиваемый обучающий контент

- помощь в приложении и поддержка производительности

- возможность тренировочной симуляции

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

В результате анализа существующих аналогов системы, а именно: Doxygen, MadCap Flare, Oracle UPK и SAP Enable Now, - была составлена сравнительная таблица (Таблица 1).

Таблица 1. Сравнение существующих аналогов

	Doxygen	MadCap Flare	Oracle UPK	SAP Enable Now
Поддержка различных форматов	+	+	+	+
Импорт шаблонов	-	+	+	+
Поддержка ОС Windows	+-	+	+	+
Контроль доступа пользователя	-	-	+	+
Интеграция в другие платформы	-	+	+	+
Бесплатное использование	+	-	+	-
Постоянная техническая поддержка разработчика	+	+	-	+

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



2. Разработка программы

2.1 Выбор программных средств

В качестве среды для разработки была выбрана Embarcadero RAD Studio версии 10.2. Данная среда поддерживает программирование на языке Delphi, а также является наиболее стабильной. Кроме того, Embarcadero RAD Studio поддерживает множество различных плагинов и позволяет устанавливать дополнительные библиотеки, что повышает удобство при работе в ней.

Основными достоинствами Embarcadero RAD Studio являются:

Высокий уровень поддержки Windows 10. В среде присутствует поддержка компонентов Windows 10 и «родных» API и компонентов WinRT/UWP, элементов интерфейса Windows 10 VCL. Также обновлена поддержка Windows 10 FMX.

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

Стабильность, качество и эффективная документация.

Для создания базы данных была выбрана СУБД MS SQL. Данная СУБД хорошо поддерживает Embarcadero RAD Studio, что позволяет без дополнительных настроек подключить существующую базу данных в проект.

2.2 Структура проектов на языке программирования Delphi

Полное исполняемое приложение Delphi состоит из нескольких модульных модулей, связанных между собой одним модулем исходного кода, который называется файлом проекта. В традиционном программировании на Паскале весь исходный код, включая основную программу, хранится в файлах .pas. Инструменты Embarcadero используют расширение файла .dpr для обозначения основного исходного кода программы, тогда как большинство других исходных кодов находятся в файлах модулей, имеющих традиционное расширение .pas. Для построения проекта компилятору требуется исходный файл проекта и либо исходный файл, либо файл скомпилированного модуля для каждого модуля. Строго говоря, не нужно явно использовать какие-либо модули в проекте, однако все программы автоматически используют модуль System и модуль SysInit.

Файл исходного кода для исполняемого приложения Delphi содержит:

– заголовок программы,

– импортируемые классы (uses) (необязательно)

– блок объявлений и исполняемых операторов.

Компилятор и, следовательно, IDE ожидают найти эти три элемента в одном файле проекта (.dpr). Файл DPR содержит каталоги для создания приложения. Обычно это набор простых процедур, которые открывают основную форму и любые другие формы, которые должны открываться автоматически. Затем он запускает программу, вызывая методы Initialize, CreateForm и Run глобального объекта Application.

Глобальная переменная Application типа TApplication есть в каждом приложении Delphi для Windows. Приложение инкапсулирует программу, а также предоставляет множество функций, которые происходят в фоновом режиме программного обеспечения.

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

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

Блок состоит из простого или структурированного оператора, который выполняется при запуске программы. В большинстве программных файлов блок состоит из составного оператора, заключенного в скобки между зарезервированными словами begin и end, чьи операторы-компоненты являются просто вызовами методов для объекта Application проекта. Большинство проектов имеют глобальную переменную Application, которая содержит экземпляр класса Vcl.Forms.TApplication, Web.WebBroker.TWebApplication или Vcl.SvcMgr.TServiceApplication. Блок также может содержать объявления констант, типов, переменных, процедур и функций; эти объявления должны предшествовать части инструкции блока.

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

Файл модуля начинается с заголовка модуля, за которым следует ключевое слово interface. Вслед за ключевым словом interface, условие uses указывает список зависимостей модуля. Далее идет раздел implementation, за которым следуют необязательные разделы initialization и finalization. Исходный файл скелетного модуля выглядит так:

unit Unit1;

interface

uses // Список зависимостей модуля

// Секция interface

implementation

uses // Список зависимостей модуля

// Имплементация методов, процедур и функций класса

initialization

// Инициализация модуля

finalization

// Финализация модуля

end.

2.3 Описание проекта

Проект редактора технологической и эксплуатационной документации состоит из следующих файлов:

1. Project1.dpr: файл исходных кодов, ассоциирующийся с проектом, иначе говоря, файл проекта.

2. Unit1.pas: файл исходного кода, отвечающих за авторизацию пользователя.

3. Unit1.pas: файл ресурсов, содержащий форму авторизации.

4. Unit2.pas и Unit2.dfm: модуль данных, содержащий необходимую информацию для работы с базой данных.

5. Unit3.pas и Unit3.dfm: файлы исходного кода, отвечающие за изменение настроек подключения к базе данных.

6. Unit4.pas: файл исходного кода, отвечающий за главную форму проекта, unit-файл

7. Unit4.dfm: файл ресурсов, содержащий информацию о главной форме, form-файл

8. Actions.pas: файл исходного кода, содержащий информацию о подключенном модуле данных

9. Actions.dfm: файл ресурсов.

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

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

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

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

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

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

2.4 Описание функций программы

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

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

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

Рисунок 4. Окно авторизации пользователя



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

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

– HostName - название сервера, на котором хранится база данных;

– Database - название базы данных;

– Username - имя пользователя, под которым можно авторизоваться в базе данных;

– Password - пароль пользователя;

– Port - TCP/IP порт, на котором функционирует СУБД.

Изначально программа получает следующие данные:

1. HostName: localhost

2. Database: templateprofiles

3. Username: root

4. Password: 12345

5. Port: 3306

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

Функция LoginCheckSQL проверяет правильность введенного пароля. Для этого выполняется запрос в базу данных по полю p_password, находящемуся в таблице Профиль. При совпадении введенного пароля с хранящимся в базе данных осуществляется вход пользователя в систему. Кроме того, на данном этапе загружаются шаблоны документов, доступные авторизованному пользователю. Происходит это следующим образом:



Рисунок 5. Загрузка шаблонов пользователя

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

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

1. Механизм доступа к данным

Наборы данных FireDAC созданы на основе мощного механизма доступа к данным. Этот легкий, эффективный и гибкий механизм может использоваться непосредственно в приложениях и служит мощной основой для API наборов данных.

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

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

3. Поддержка исходного драйвера

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

Схема связи библиотеки FireDAC с остальными компонентами представлена ниже:

Рисунок 6. Схема взаимодействия с библиотекой FireDAC

Данный модуль содержит объекты следующих классов:

1. TFDConnection - класс, отвечающий за установление соединения с СУБД.

2. TFDPhysMSSQLDriverLink можно использовать для указания:

– ODBCDriver - имя драйвера ODBC для SQL Server.

– ODBCAdvanced - параметр соединения для драйвера ODBC сервера SQL. Этот параметр является общим для всех соединений.

– VendorLib - менеджер драйверов ODBC. По умолчанию это odbc32.dll и должно оставаться неизменным в большинстве случаев.

3. TFDGUIxWaitCursor

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

В процессе подключения к базе данных в объект класса TFDConnection добавляются все данные, необходимые для успешного установления соединения, а именно: имя драйвера системы управления базами данных, имя сервера, названия базы данный, пользователь и пароль, а так же порт, на котором функционирует выбранная СУБД, в данном случае Microsoft SQL Server. Код функции представлен ниже:

Рисунок 7. Функция ConnectMSSQL

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

Рисунок 8. Изменения параметров подключения к БД



После указания измененных данных в объект класса TFDConnection вносятся изменения, после чего система будет осуществлять вход в БД по обновленным параметрам.

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

Рисунок 9. Интерфейс главного окна программы

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

TRichView представляет собой пакет компонентов Delphi/C++Builder (VCL) и Lazarus (LCL) для работы с гипертекстовыми документами. Компоненты поддерживают различные атрибуты для оформления текста, такие как: стили, шрифты, верхние и нижние регистры, цвет фона и текста. Также поддерживается работа с рисунками и таблицами, включая анимации и любые визуальные компоненты Delphi. Кроме того присутствует возможность создания маркированных и нумерованных списков абзацев и выравнивание абзацев документов с настраиваемыми полями и отступами.

В данном модуле используются следующие классы:

1. TPopupMenu - класс, определяющий всплывающее меню, которое появляется, когда пользователь нажимает на элемент управления правой кнопкой мыши.

2. TMainMenu - данный класс инкапсулирует строку меню и соответствующие раскрывающиеся меню для формы.

3. TRVAControlPanel - класс, позволяющий изменять настройки различных функций TRichViewActions.

4. TRVPrint - компонент, позволяющий осуществлять печать из содержимого классов TRichView, TRichViewEdit, TDBRichView или TDBRichViewEdit.

5. TRVRuler - компонент, отвечающий за вертикальную либо горизонтальную линейку для редактирования документа.

6. TRVStyle - компонент, отвечающий за визуальную настройку класса RichView, а также классов, наследуемых от него.

7. TCoolBar - это класс-оболочка для для верхней панели управления приложения Windows, более известный как CoolBar. CoolBar содержит дочерние элементы управления, которые независимо можно перемещать и изменять размер. Каждый элемент управления находится в отдельном диапазоне, представленном объектом TCoolBand, указанным в свойстве Bands. Пользователь размещает элементы управления, перетаскивая калибровочную ручку слева от каждой полосы.

8. TRichViewEdit - это элемент управления для редактирования документов с изображениями, таблицами, элементами управления Delphi и гиперссылками. Стоит отметить, что RichViewEdit не отображает и не редактирует свое содержимое, если оно не связано с компонентом RVStyle через свойство Style.

Для выбора шаблона документа необходимо выбрать в выпадающем меню необходимое название документа и нажать кнопку “Load File”. После этого происходит формирование запроса к БД. Результат выполнения запроса записывается в поток при помощи функции CreateBlobStream. Данная функция предназначена для получения потока для чтения и записи значения поля, указанного параметром Field. Параметр Mode указывает, будет ли поток использоваться для чтения значения поля (bmRead), записи значения поля (bmWrite) или изменения значения поля (bmReadWrite). Потоки BLOB-объектов создаются в определенном режиме для определенного поля в определенной записи. Приложения создают новый поток больших двоичных объектов каждый раз, когда изменяется запись в наборе данных, поэтому не рекомендуется использовать повторно существующий поток BLOB объектов. Полный код функции представлен на рисунке ниже:

Рисунок 10. Функция загрузки шаблона документа

Actions - модуль данных, содержащий в себе реализацию всех доступных функций по работе с документом. Данный модуль содержит в себе объекты следующих классов:

TActionList - класс, использующийся для централизации ответа на пользовательские команды (действия). Компоненты списка действий поддерживают список действий, которые доступны клиентским элементам управления в приложении.

TImageList - cписки изображений используются для эффективного управления большими наборами значков или растровых изображений. Все изображения в списке изображений содержатся в одном широком растровом изображении в формате экрана устройства. Список изображений может также включать монохромное растровое изображение, которое содержит маски, используемые для прозрачного рисования изображений (стиль значков). Список изображений может содержать большое количество изображений одинакового размера и извлекать их по индексу в диапазоне от 0 до n - 1. В списке изображений также есть методы, облегчающие хранение, поиск и рисование сохраненных изображений. Изображения в списке могут быть растровыми изображениями, значками, изображениями в формате PNG, GIF и JPEG: любые типы изображений, которые поддерживает TImage. Списки изображений также поддерживают 32-битный формат, поэтому альфа-смешанные растровые изображения и файлы PNG работают правильно.

2.5 Описание базы данных

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

В соответствии с предметной областью система строится с учетом следующих особенностей:

- каждый пользователь принадлежит к одной группе;

- каждая группа может иметь несколько доступных шаблонов;

Для создания базы данных были выделены следующие сущности предметной области:

1) Пользователь. Атрибуты: логин, фамилия, имя, отчество, e-mail, пароль, группа

2) Группа. Атрибуты: название группы

3) Шаблон. Атрибуты: документ шаблона, описание шаблона.

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

Схема связи атрибутов и отношений в базе данных показана на рисунке ниже:

Рисунок 11. Схема базы данных

Полная структура базы данных представлена на таблицах ниже.

Таблица 2. Отношение Пользователи

Атрибут	Название	Тип	Примечание
ID	p_id	Int	первичный ключ
Логин	p_login	Varchar(45)	обязательное поле
Фамилия	p_surname	Varchar(45)
Имя	p_name	Varchar(45)
Отчество	p_finalname	Varchar(45)
e-mail	p_email	Varchar(45)	обязательное поле
Пароль	p_password	Varchar(45)	обязательное поле
Группа	p_group	Int	внешний ключ (к Группы)

Таблица 3. Отношение Группы

Атрибут	Название	Тип	Примечание
ID группы	g_id	Int	первичный ключ
Название группы	g_name	Varchar(45)	обязательное уникальное поле

Таблица 4. Отношение Шаблоны

Атрибут	Название	Тип	Примечание
ID шаблона	t_id	Int	первичный ключ
Документ шаблона	t_template	BLOB	обязательное поле
Краткое описание	t_desc	Varchar(45)

Таблица 5. Отношение Группы-Шаблоны

Атрибут	Название	Тип	Примечание
ID связи	pt_id	Int	суррогатный первичный ключ
Группа	pt_group	Varchar(45)	внешний ключ (к Группы)
Шаблон	pt_template	Int	внешний ключ (к Шаблоны)

Отношение Пользователи содержит три атрибута, являющихся обязательными и необходимыми для заполнения (NOT NULL). Данные атрибуты необходимы для выполнения авторизации пользователя. Атрибут p_group является внешним ключом к отношению Группы. Само отношение содержит все необходимые данные, которые могут потребоваться для получения информации о пользователе, такие как: фамилия, имя, отчество, контактный e-mail, а также информация для аутентификации пользователя в системе.

В отношении Группы поле Название группы является уникальным, так как необходимо, чтобы названия групп не повторялись. Для удобства идентификации групп введен первичный ключ ID группы.

Отношение Шаблоны содержит три поля. Для хранения шаблонов документов используется тип BLOB. Шаблоны хранятся в атрибуте t_template. Для идентификации шаблонов введен первичный ключ ID шаблона.

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



Заключение

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

1. Изучение проблематики в области создания технической документации;

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

3. Изучение и сравнение существующих аналогов редакторов технологической и эксплуатационной документации.

4. Создание полноценного редактора документации с возможностью загрузки собственных шаблонов

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

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

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

1. Добавить возможность работы с диаграммами и её структурными элементами;

2. Добавить возможность предварительного просмотра шаблона документа, что упростит работу пользователя при их загрузке и отбросит необходимость знания названия необходимого шаблона;

3. Улучшить интерактивность интерфейса;

4. Добавить возможность поддержки различных операционных систем, отличных от ОС Windows.

Список использованных источников

1. ГОСТ 2.001-2013 Единая система конструкторской документации (ЕСКД). Общие положения. - Введ. 2014-06-01. - М: Стандартинформ, 2013. - 11 стр.

2. ГОСТ 3.1102-2011 Единая система технологической документации (ЕСТД). Стадии разработки и виды документов. Общие положения. - Введ. 2012-01-01. - М: Стандартинформ, 2001. - 8 стр.

3. ГОСТ 19.101-77 Единая система программной документации (ЕСПД). Общие положения. - Введ. 1980-01-01. - М: Стандартинформ (переиздание), 2010. - 4 стр.



Приложение

Рисунок 12. Unit1.pas



Рисунок 13. Функция ReadRegistry



Рисунок 14. Функция WriteRegistry и обработчики событий



Рисунок 15. Обработчик нажатия Login Button

Рисунок 16. Вспомогательные функции Unit1.pas



Рисунок 17. Unit1.pas

Рисунок 18. Unit2.pas



д

Рисунок 19. Функции ConnectMSSQL и OpenConnection

Рисунок 20. Unit3.pas



Рисунок 21. Unit3.pas

Рисунок 22. Unit3.pas



Рисунок 23. Функции ReadRegistry и WriteRegistry

UNIT4



Рисунок 24. Unit4.pas инициализация формы

Рисунок 25. Функции ColorPickerShow, ColoPickerHide и rvActionSaveDocumentFileChange



Рисунок 26. Функция загрузки шаблона

Размещено на Allbest.ru

...