Требования к математическому обеспечению не предъявляются.

Разрабатываемая система должна быть открыта для смежных систем и необходима поддержка импорта и экспорта данных со смежными системами.

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

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

Разрабатываемая ИС должна быть совместима с любой версией Windows, применяемой на АВТОВАЗ (Microsoft Windows 95/98/NT4.0 ).

К обеспечению качества подсистем предъявляются следующие требования [7]:

функциональность должна обеспечиваться выполнением подсистемами всех их функций.

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

легкость применения должна обеспечиваться за счет интуитивно понятного интерфейса и наличия «горячих» клавиш;

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

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

Сервер хранилища данных должен быть развернут на централизованном сервере в ДИС ОАО «АВТОВАЗ».

Требования к метрологическому обеспечению не предъявляются.

Основными пользователями модернизируемой ИС «Техническая подготовка производства» являются группа инженеров-технологов в отделе технологического оборудования и планирования станкостроения (ОТОиПС) в НТЦ ОАО «АВТОВАЗ».

Требования к методическому обеспечению не предъявляются.

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

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

получаемая в электронном виде инормация неструктурированна;

ввод данных вручную продолжителен и требует проверки внесенной информации в массив заказываемого оборудования в ИС «Техническая подготовка производства»;

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

При поиске путей решения поставленной проблемы решено, что система «Техническая подготовка производства» будет дорабатываться до требуемого функционала, путем её расширения.

1.3 Обоснование технологии модернизации ИС «Техническая подготовка производства»

Технология проектирования (технология разработки ПО) - способ организации процесса создания программы, совокупность приемов и способов выполнения определенных видов деятельности. [4]

.3.1 Выбор технологии проектирования модернизированной ИС «Техническая подготовка производства»

На разных уровнях формализации разработки и для разных критериев разработки (время, ресурсы, стоимость) выделяют пересекающиеся модели проектирования [4],[13]:

1.       RAD (Rapid Application Development) - быстрая разработка приложений.

2.      RUP (Rational Unified Process) - унифицированный процесс.

.        XP (eXtreme Programming) - экстремальное программирование.

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

.        FDD (Feature Driven Development) - функционально-ориентированная разработка.

.        MSF (Microsoft Solutions Framework) - методология разработки программного обеспечения, предложенная корпорацией Microsoft.

Таблица 2 - Сравнение технологий проектирования

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

1.     Использование в технологии итеративного подхода.

0 - критерий не удовлетворяет требованию

- критерий удовлетворяет требованию

2.     Формализованность процесса разработки.

0..5 - степень выполнения критерия

3.     Создание документации в ходе разработки.

0..5 - степень выполнения критерия

4.     Контроль рисков.

0..10 - степень выполнения критерия.

- риски непредсказуемы

- риски отсутствуют

5.     Минимальное время разработки - 10 баллов

0..10 - степень выполнения критерия.

- разработка очень длительная

- разработка максимально быстрая

На основе сформированных критериев произведён выбор технологии. В таблице 2 представлена оценка каждой технологии.

На основе оценки [13] всех выбранных для сравнения технологий определено, что для разработки данного проекта наиболее приемлемая технология RAD.

Этапы RAD-технологии

1.      Моделирование функционального поведения системы. Такую модель можно определить с помощью диаграммы вариантов использования UML.

2.      Моделирование данных - моделирование объектов, которые требуются для поддержки бизнес-процессов. Модель можно отобразить с помощью диаграммы классов UML.

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

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

.        Объединение и тестирование.

Таким образом, определено, что для проектирования используется модель RAD (быстрая разработка приложений). Проектирование системы будет произведено по этапам данной технологии.

.3.2 Сравнительный анализ и выбор CASE-средств

На основе списка средств UML-моделирования, представленного в источнике [14], и информационного поиска по каждому средству моделирования выделены следующие основные средства для проектирования с помощью UML:

¾    Visual Paradigm[15];

¾      Rational Rose [20];

¾      Borland Together [21];

¾      ArgoUML [16];

¾      Netbeans UML Plugin [17];

¾      Eclipse Omondo Plugin [18];

¾      Enterprise Architect [19].

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

1.     Возможность генерации программного кода.

2.      Возможность производить реверс кода.

.        Поддержка ОС Windows.

.        Стоимость приобретения.

.        Опыт успешного использования (отзывы).

.        Простота освоения и использования.

Все критерии кроме стоимостного оценивается следующими балами:

- не удовлетворят требованию

- частично удовлетворяет требованию

- полностью удовлетворяет требованию

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

- высокая стоимость;

- средняя стоимость;

- бесплатно.

Выбор CASE-средства представлен в таблице 3.

В данном подразделе определено, что для модернизации ИС «Техническая подготовка производства» будет использоваться модель RAD (быстрая разработка приложений). Проектирование будет производиться в CASE-средстве Visual Paradigm.

Таблица 3 - Исходные данные для выбора CASE-средства

.4 Разработка модели системы

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

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

2.      Диаграммы классов и диаграммы компонентов. Они отражают объекты, которые требуются для поддержки бизнес-процессов.

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

1.4.1 Моделирование функционального поведения системы

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

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

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

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

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

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

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

Из представленной модели видно, что инженер ОТОиПС вместо того чтобы повторно производить ввод информации из РВ в ИС «Техническая подготовка производства» может подтвердить корректность этой информации, заполненной инженером-технологом. Так же он может проводить работы с уже заполненным массивом данных ИС «Техническая подготовка производства». Функционал соответствует требованиям к функциям, выполняемым системой, описанным в пункте 1.2.4.

.4.2 Моделирование данных

Диаграмма классов служит для представления статической структуры модели системы [14]. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру и типы отношений. Диаграмма классов является дальнейшим развитием концептуальной модели проектируемой системы. Существует расширение языка UML для построения моделей программного обеспечения, которое позволяет ввести в рассмотрение дополнительные графические обозначения, ориентированные для решения задач из определенной предметной области. В рамках данного расширения предложено три специальных графических примитива:

¾    граничный класс - класс, который располагается на границе системы с внешней средой и непосредственно взаимодействует с актерами, но является составной частью системы;

¾      класс-сущность - класс, отображающий классы, которые являются хранилищами данных;

¾      управляющий класс - класс, отвечающий за координацию действий других классов.

Граничным классом является форма отображения данных, хранящихся в объектах класса «Формы и окна программы».

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

Управляющим классом является класс «Пользователь».

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

Класс Task хранит информацию о задачах

Класс User хранит информацию о пользователях

Класс Equipment хранит информацию об оборудовании

Класс Phase_List хранит информацию о фазах технической подготовки

Класс dic_detail хранит справочную информацию о деталях

Класс dic_equipment_phase хранит справочную информацию о фазах заказа

Класс dic_equip_type хранит справочную информацию о типах оборудования

Класс frmContract содержит информацию об объекте формы контрактов

Класс frmEquipment содержит информацию об объекте формы оборудования

Класс frmMontag содержит информацию об объекте формы монтажа

Класс frmStructGraph содержит информацию об объекте формы графиков

1.4.3 Разработка архитектуры модернизации ИС «Техническая подготовка производства»

Архитектура информационной системы - концепция, определяющая модель, структуру, выполняемые функции и взаимосвязь компонентов ИС. [3]

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

простота создания (влияет на срок разработки и внедрения ИС);

эффективное управление данными (влияет на сложность эксплуатации ИС);

одновременная работа нескольких пользователейвозможность одновременной работы нескольких пользователей(до 30 человек);

Следующие критерии не будут существенно влиять на выбор архитектуры:

стоимость серверного оборудования (на ОАО «АВТОВАЗ» уже закуплены сервера, способные решать поставленные задачи с установленной на них лицензионной СУБД Oracle);

отказоустойчивость компонентов архитектуры (отказоустойчивость компонентов обеспечивается соответствующими службами АВТОВАЗ);

Таблица 4 - Критическая оценка архитектур для ИС

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

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

1.4.4 Моделирование обработки данных, обеспечивающих функционирование системы

Основу работы с ИС «Техническая подготовка производства» составляет диалоговый режим работы инженера и ИС, в которой он выполняет операции по просмотру, изменению данных по заказываемому технологическому оборудованию. А так же составлению отчетов и план-графиков.

Инженер ОТОиПС работая с ИС «Техническая подготовка производства», выполняя может:

получать информацию из системы;

изменять информацию в системе;

вносить новую информацию;

составлять отчеты.

Рисунок 10 - Диаграмма последовательности работы инженера ОТОиПС с ИС «Техническая подготовка производства»

Задачи могут решать в любом порядке и в любых сочетаниях, как это требуется инженеру. На рисунке 10 представлена диаграмма последовательности при работе с ИС «Техническая подготовка производства» при выполнении последовательных операций по изменению уже внесенной информации и составлению отчета.

1.4.5 Проектирование моделей данных

На основе моделирования предметной области были выявлены основные сущности проектируемой ИС. Под сущностью понимается объект или объекты, имеющие уникальные параметры и атрибуты, по которым их можно идентифицировать [4]. Все сущности взаимодействуют друг с другом по определенным отношениям, образуя тем самым некую целостную систему. Под отношениями понимаются связи между сущностями, по которым между ними происходит обмен информацией, знаниями и т.д.

Каждая сущность в дальнейшем будет определена собственным классом, имеющим собственный набор параметров, и методов. Методы в свою очередь являются реализацией отношений, т. е. связующим каналом обмена данными. Каждая сущность связана с другими отношения, причем они могут быть как множественные (многое ко многим), так и единичные (один к одному). Все это надо схематически отобразить, для чего удобнее всего использовать нотацию Чена [4].

Приведем нотацию Чена на следующем рисунке.

Рисунок 11 - Общая инфологическая модель разрабатываемой системы

Ключевой сущностью проектируемой ИС является «Задача». С данной сущностью работают все остальные, а именно:

-       технолог;

-       заказываемое оборудование;

-       инженер ОТОиПС;

-       фаза заказа.

Связь сущностей «Инженер ОТОиПС - Задача» описывает функцию длительности проекта, стоимости проекта, а также наименования задачи для отчётности.

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

Связь сущностей «Заказываемое оборудование - Задача» описывает функцию прямого взаимодействия этих сущностей, так как заказываемое оборудование это часть определённой задачи.

На сегодняшний день существует большое число разных видов моделей данных, обрабатываемых в информационной системе. В соответствии с источником [7], основными моделями данных являются:

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

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

-       реляционная модель - состоит из отношений и элементов отношений (кортеж);

-       объектная модель - состоит из данных, оформленных в виде моделей объектов произвольного типа.

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

-       простота физической реализации;

-       личный опыт работы с моделью;

-       «понятность» для пользователя.

Сведем сравнительный анализ моделей данных в таблицу.

Таблица 5 -Критическая оценка моделей данных разрабатываемой ИС

В ходе проведенного сравнительного анализа была выбрана реляционная модель представления данных.

Для построения данной модели будет использоваться ERwin Data Modeler. Данное CASE-средство удовлетворяет следующим требованиям:

-       возможность генерирования физической модели БД на основе имеющейся логической модели;

-       бесплатное распространение программного продукта;

-       личный опыт работы с программным продуктом.

Определив тип модели данных, а также CASE-средство, с помощью которого данная модель будет реализовываться, можно приступить к построению модели БД.

Рисунок 12 - Логическая модель информационной системы

Связь является логическим соотношением между сущностями. В Erwin на логическом уровне можно установить идентифицирующую связь «один ко многим», связь «многие ко многим» и неидентифицирующую связь «один ко многим».

Связь сущностей «детали из конструкторской спецификации - заказываемое оборудование» один ко многим описывает привязку заказываемого оборудования и и деталью которую это оборудование будет выпускать.

Связь сущностей «заказываемое оборудование - работы по ТО» многое ко многим описывает привязку между заказываемым оборудованием и процессом заказа, а также процессом его монтажа.

Связь сущностей «работы по ТО - справочник валют» один ко многим описывает привязку между работами по ТО и их стоимостью.

Связь сущностей «работы по ТО - список фаз по ТО» один ко многим описывает разбиение работы по ТО на фазы.

Связь сущностей «заказываемое оборудование - тип обьекта» один ко многим описывает привязку обобщённой сущности заказываемого оборудования к конкретному типу оборудования.

Связь сущностей «наименование задачи - заказываемое оборудование» многое ко многим описывает привязку между задачей и информацией по заказываемому оборудованию.

Связь сущностей «наименование задачи - задача» многое ко многим описывает привязку между обобщённой сущностью наименование задачи и конкретной информацией по одной задаче.

1.5 Постановка задачи на модернизацию ИС «Техническая подготовка производства»

Требуется расширить ИС «Техническая подготовка производства», обеспечив следующие возможности:

¾    определять в графическом интерфейсе параметры программы;

¾      позволить просматривать данные по оборудованию, контрактам, инвестициям, строительно-монтажным работам, графику внедрения, предмонатжу внутри проекта;

¾      позволить выполнять операции с данными;

¾      формировать отчеты (табуляграмма заказа оборудования, график заказа оборудования, отчет по узлам, отчет по контрактам и др.);

¾      позволить создавать отчеты в формате DOC и PDF;

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

Система предназначена для инженеров отдела технологического оборудования и планирования станкостроения (ОТОиПС) НТЦ ОАО «АВТОВАЗ».

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

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

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

Разрабатываемая ИС должна быть совместима с любой версией Windows, применяемой на АВТОВАЗ (Microsoft Windows 95/98/NT4.0).

Для модернизации ИС должна использоваться технология RAD, для проектирования CASE-средство - Visual Paradigm .

В данном разделе описана организационная структура управления планирования и координации подготовки производства (УПиКПП) НТЦ ОАО «АВТОВАЗ» и отдела технологического оборудования и планирования станкостроения (ОТОиПС). Выявлены проблемы при заказе технологического оборудования: применяемая система частично автоматизирует работы по процессу заказа технологического оборудования внутри самого отдела, но отсутствует сетевое взаимодействие между отделом и другими технологическими управлениями, таким образом, отсутствовала возможность создать единую область данных. При поиске путей решения поставленной проблемы решено, что требуется дописать имеющуюся систему «Техническая подготовка производства» до требуемого функционала, путем её расширения. Для разработки ИС «Техническая подготовка производства» будет использоваться модель RAD (быстрая разработка приложений). Проектирование будет производиться в Visual Paradigm .

При моделировании ИС выделены следующие варианты использования: создание программы и модификация программы (анализ). Работа по заказу и размещению технологического оборудования включает этапы:

¾    работа с данными по проектам;

¾      изменение данных/групповое изменение данных;

¾      формирование отчетов;

¾      вывод справок;

¾      работа со справочниками.

2 Конструкторско-технологическая часть

.1 Требования к модернизируемой ИС, предъявляемые заказчиком

В рамках решения поставленной задачи, заказчиком в лице службы вице-президента по техническому развитию ОАО «АВТОВАЗ» было принято решение вести разработку ИС «Техническая подготовка производства» на основе следующих решений.

1.      В рамках подхода к созданию сетевой ИС «Техническая подготовка производства» будет применяться объектно-ориентированный подход, что позволит:

локализовать код и данные (т.е. их сосредоточение в отдельных частях программы);

обрабатывать разнородные структуры данных;

поддерживать политику Дирекции по информационным систем ОАО «АВТОВАЗ»;

обеспечить высокую скорость разработки приложения;

снизить стоимость разработки системы;

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

2.      При разработке ИС «Техническая подготовка производства» будет применяться среда разработки IDE DELPHI на следующих основаниях:

Разработка в рамках задачи для толстого клиента велась изначально в IDE DELPHI

ОАО «АВТОВАЗ» приобрел лицензию на данный продукт;

ОАО «АВТОВАЗ» были проведены обучающие курсы по программированию в среде Delphi;

Данная среда отвечает всем современным требованиям по скорости разработки и переносимости ПО и является объектно-ориентированным языком программирования.

3.      При выборе СУБД основным вариантом для разработки базы данных была СУБД Oracle в силу следующих причин:

На ОАО «АВТОВАЗ» основной БД является СУБД Oracle;

Закуплены мощные кластер-сервера фирмы HP с установленной на них данной СУБД;

Ранее разработанное программное обеспечение использует СУБД Oracle.

Для обеспечения функционирования системы, с учетом защиты данных, ранее разработанного программного обеспечения и политики Дирекции информационных систем на ОАО «АВТОВАЗ» было решение:

реализовать систему по вводу данных, при большой трудоемкости переработки кода, разработку вести на Object Pascal в IDE DELPHI 7.0;

применять технологию «клиент-сервер»;

базу данных реализовать в СУБД ORACLE.

.2 Проектирование физической модели базы данных

Логическая модель БД была показана в пункте 1.4.6 данного дипломного проекта. Атрибуты сущностей модели данных разрабатываемой автоматизированной системы представлены в приложении Б данного дипломного проекта При приведении логической модели к физической необходимо выполнить преобразование типов. Преобразование типов записей в базе данных представлено в следующей таблице:

Таблица 6 - Преобразование типов из логической модели в физическую модель базы данных

На основе логической модели составим соответствующую ей физическую модель. Физическая модель приведена на рисунке 13.

Рисунок 13 - Физическая модель информационной системы

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

Интерфейс пользователя должен состоять из:

-       главного меню, в котором осуществляется навигация программы

-        форм ввода данных

         форм просмотра данных

         модуля формирования отчетов

При разработке интерфейса учитывалось что пользователи работают в Windows с приложениями Word, Excel, поэтому решение о виде программного обеспечения было принято исходя из этих условий. Стандартное приложение в Windows это два вида интерфейса MDI - Multiple Dialog Interface и SDI - Single Dialog Interface. В MDI приложениях одно окно главное, остальные дочерние и всегда находиться внутри главного окна. В SDI приложениях все окна самостоятельные. Был выбран интерфейс MDI , как более подходящий для работы по данной теме.

Основной стиль интерфейса показан на рисунке 14.

Рисунок 14 - Основной стиль интерфейса.

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

Программный интерфейс должен быть снабжен быстрыми подсказками (hint). Повторяющие операции для быстрого доступа должны быть дублированы в виде кнопок быстрого доступа (toolbar). В формах вывода информации пользователям должны быть предоставлены возможности настраивать отображение информации. Модуль формирования отчетов должно позволять экспортировать в XLS и PDF формат.

Для просмотра информации о заказываемом оборудовании была создана отдельная форма, вызываемая при выборе пункта «Оборудование» в меню «Данные», пример формы показан на рисунке 15

Рисунок 15 - Окно просмотра оборудования.

Список оборудования можно просматривать в режиме «Просмотр» (по умолчанию) и в режиме «Таблица», показанном на рисунке 16.

Рисунок 16 - Окно просмотра оборудования в режиме «Таблица»

Для ввода данных вызывается форма следующего вида

Рисунок 17 - Окно ввода данных по ТО

Рисунок 18 - Окно ввода данных по договорам (контрактам)

Остальные элементы интерфейса отражены в приложении А данного дипломного проекта, где показано руководство пользователя.

Далее приведем пример работы ИС «Техническая подготовка производства».

2.4 Разработка алгоритмов ИС «Техническая подготовка производства»

Опишем действия кнопки «Изменить» или пункт меню «ОПЕРАЦИИ»-«Изменить» или короткий вызов клавиши CTRL+E.

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

В таблице 7 показано возможное состояние окна программы:

Таблица 7 - Возможные состояния основного окна программы

Продолжение таблицы 7

При нажатии кнопки «Изменить» будет работать алгоритм, схема которого представлена на рисунке 19.

Рисунок 19 - Алгоритм работы кнопки «Изменить»

Листинг алгоритма работы кнопки «Изменить»:

TfrmMain.actEditExecute(Sender: TObject);:Integer;

:String;

//Если нет открытых оконничего не делаемMDIChildCount=0 Then Exit;

//если активное окно редактирование структуры графика внедренияActiveMDIChild is TfrmStructGraph Then

//Указываем что рассматриваем активное окно как форма графика внедренияActiveMDIChild as TfrmStructGraph do

//Если это таблица отображения главных пунктов графика внедренияTObject(Tag)=dbgStructMain Then

//создаем диалоговое окно реадктированияTfrmEditStructMain.Create(ActiveMDIChild) Do

//Выводим диалоговое окно;

//Если нажали сохранитьModalResult=mrOK Then

//сохранаяем данные.Commit;;;

ActiveMDIChild is TfrmEquipRemake ThenTfrmEditRemake.Create(self) Do.Open;.Edit;;ModalResult=mrOK Then.OraSession.ApplyUpdates([qryEditRemake,DBMain.qryPhaseEdit],True);.OraSession.Commit;;;;

ActiveMDIChild is TfrmEquip ThenTfrmEquipEdit.Create(self) Do.qryEquipEdit.Open;.qryEquipEdit.Edit;;ModalResult=mrOK Then.OraSession.ApplyUpdates([DBMain.qryPhaseEdit],True);.OraSession.ApplyUpdates([DBMain.qryBudget],True);;;

//Если это форма контрактов ActiveMDIChild is TfrmContract ThenActiveMDIChild as TfrmContract Do

//Анализируем активный элемент TControl(dsContract.Tag).Tag Of

//Если это - Отображение контракта

:With TfrmEdtContract.Create(self) Do.Edit;;ModalResult=mrOK Then.OraSession.CommitUpdates([qryContract,DBMain.qryGetFirm,DBMain.qryGetCountry]);;;

//Платежи

:With TfrmEdtPay.Create(Self) Do.Edit;;Modalresult=mrOK Then.OraSession.ApplyUpdates([qryPay],true);;;;;

Рисунок 20 Алгоритм работы кнопки «Поиск»

Листинг алгоритма работы кнопки «Поиск»:

TfrmSrchFltr.btSrchFltrClick(Sender: TObject);: Integer ;

: String ;:=Nil;:='';

//Ищем среди активных форм, окно отображения

//массива заказываемого оборудованияI:=0 to frmMain.MDIChildCount-1 DofrmMain.MDIChildren[i].Name='frmEquip' Then frmEquip:=TfrmEquip(frmMain.MDIChildren[i]);

//Если его нет создаемNot Assigned(frmEquip) Then:=TfrmEquip.Create(frmMain);.Free;;frmEquip Do

//Запрещяем изменение всех визуальных компонент

// связанных с источником данных.DisableControls;.Close;.DeleteVariables;

//Очищяем SQL запрос для построения нового.SQL.Clear;

//Загружаем неизменяемую часть запроса .SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('Select'));:='';

//Анализируем какие условия поиска

// выстаил пользовательtrim(lcTask.Text)<>'' Then

//Добавляем в условие where фильтр по проекту:=lcTask.LookupSource.DataSet.FieldByName('TASK_NUM').AsString; qryViewEquip.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_TaskNum'));;

//Добавляем в условие where фильтр по зоне поставке:=Trim(cbZoneSupply.Text);pZone<>'' Then.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_ZoneSupply'));

//Добавляем в условие where фильтр по отделуTrim(edtDeptPrj.Text)<>'' Then.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_DeptPrj'));

//Добавляем в условие where фильтр по виду объекта(оборудование,оснащение)Trim(lcEquipTypeID.Text)<>'' Then.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_EquipTypeID'));

//Добавляем в условие where фильтр по цехуTrim(edtShop.Text)<>'' Then.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_ShopNum'));Trim(lcBuild.Text)<>'' Then.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_Build'));Trim(cbFacility.Text)<>'' Then.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_Facility'));Trim(edtSets.Text)<>'' Then.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_Sets'));(Trim(edtGroupEquip.text)<>'') Or

(Trim(edtEquipNum.Text)<>'') Or

(Trim(edtEquipShop.Text)<>'') Or

(Trim(edtPrj.Text)<>'')qryViewEquip.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_EquipNum'));Trim(edtRigNum.Text)<>'' Then.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_RigNum'));Trim(edtRigName.Text)<>'' Then.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_RigName'));

Trim(edtTurnBay.Text)<>'' Then.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_TurnBay'));Trim(edtDetail.Text)<>'' Then.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_DetailNum'));Trim(edtModel.Text)<>'' Then.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_ModelBench'));Trim(edtNodes.Text)<>'' Then.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_Nodes'));Trim(edtPerform.Text)<>'' Then.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_Perform'));Trim(edtEquipName.Text)<>'' Then.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_EquipName'));Trim(edtPrjLot.Text)<>'' Then.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_PrjLot'));

//Добавляем условие по примечаниямNot cbIsSelf.Checked ThenTrim(edtOtherCheck.Text)<>'' Then.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_OtherCheck'));Trim(edtOtherCheck1.Text)<>'' Then.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_OtherCheck_1'));Trim(edtOtherCheck2.Text)<>'' Then.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_OtherCheck_2'));Trim(edtOtherCheck3.Text)<>'' Then.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_OtherCheck_3'));Trim(edtOtherCheck4.Text)<>'' Then.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_OtherCheck_4'));Trim(edtPrgKti.Text)<>'' Then.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_Prg_num_KTI'));Trim(edtOtherCheck5.Text)<>'' Then.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_OtherCheck_5'));qryViewEquip.SQL.AddStrings(mSelfIf.Lines);

Trim(edtNote.Text)<>'' Then.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_Note'));Trim(edtTZ.Text)<>'' Then.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_TZ'));Trim(edtPhaseList.Text)<>'' Then.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_PhaseList'));Trim(edtLeadDoc.Text)<>'' Then.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_LeadingDoc'));Trim(edtInvestItem.Text)<>'' Then.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_Invest'));Trim(edtStartComplex.Text)<>'' Then.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_StartComplex'));Trim(TypeEquip.Text)<>'' Then.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_EquipType'));

:=False;:=False;

//Анализируем надо ли сравнивать данные из РВ и ЗиРТО, если надо

//то какого типа сравнения

//По этим сравнениям дальше цветом будут выдели записи или поля с отличиемrgRV.ItemIndex Of

:qryViewEquip.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_CopyFromRV'));

:begin:=True;.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_NoCopyFromRV')); ;

:Begin

// Включаем режим сравнения в отображение цветом в dbgeViewEquip:=True;:=qryViewEquip.SQL.Text;

//Если режим сравнения включен то

//встраиваем в SQL запрос услоия связи между таблицами

//ЗиРТО и РВ.tag:=pos('/* #S8# */',sSQL);.Tag:=pos('/* #_S8# */',sSQL)+length('/* #_S8# */');:=Copy(sSQL,1,Self.tag-1)+#13#10+.SQLlist.Trees.TreeByName('ViewEquip').TextByName('f_rv')+#13#10+(sSQL,rgRV.Tag+1,Length(sSQL)-rgRV.Tag);.SQL.Text:=sSQL;:=qryViewEquip.SQL.Text;.tag:=Pos('/* FROM_RV */',sSQL);.SQL.Text:=Copy(sSQL,1,Self.Tag-1)+.SQLlist.Trees.TreeByName('ViewEquip').TextByName('s_rv')+(sSQL,Self.Tag,Length(sSQL)-Self.Tag);.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_DataRV<>DataEQS'));; 3:qryViewEquip.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_DataRV=DataEQS'));;.actReSync.Enabled:=DivDataRVForEQS;.actReSyncToRV.Enabled:=HandsEnterForEQS;Trim(edtPhase.Text)<>'' Then:=qryViewEquip.SQL.Text;.tag:=Pos('/* FROM_PHASE_LIST */',sSQL);.SQL.Text:=Copy(sSQL,1,Self.Tag-1)+ DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('s_PhaseList')+(sSQL,Self.Tag,Length(sSQL)-Self.Tag);.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_Phase'));;

//Если требуется фильтрация по контрактам

//Добавляем условия связ и между талицами ЗиРТО и Контракт(edtContract.Text<>'') andcbIsSubContract.Checked:=qryViewEquip.SQL.Text;.tag:=Pos('/* FROMCONTRACT */',sSQL);.SQL.Text:=Copy(sSQL,1,Self.Tag-1)+.SQLlist.Trees.TreeByName('ViewEquip').TextByName('s_Contract')+(sSQL,Self.Tag,Length(sSQL)-Self.Tag); qryViewEquip.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_Contract_All'));edtContract.Text<>'' Then.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_Contract'));;(edtContract.Text<>'') and.Checked or

(edtManuf.Text<>'') or

(edtCountry.text<>''):=qryViewEquip.SQL.Text;.tag:=Pos('/* FROMCONTRACT */',sSQL);.SQL.Text:=Copy(sSQL,1,Self.Tag-1)+.SQLlist.Trees.TreeByName('ViewEquip').TextByName('s_SubContract')+(sSQL,Self.Tag,Length(sSQL)-Self.Tag);.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_SubContract_All'));edtContract.Text<>'' Then.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_SubContract'));edtManuf.Text<>'' Then.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_Manuf'));edtCountry.Text<>'' Then.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_Country'));;Trim(edtBudget.Text)<>'' Then:=qryViewEquip.SQL.Text;.tag:=Pos('/* #_S7# */',sSQL);.SQL.Text:=Copy(sSQL,1,Self.Tag-1)+.SQLlist.Trees.TreeByName('ViewEquip').TextByName('s_Budget')+(sSQL,Self.Tag,Length(sSQL)-Self.Tag); qryViewEquip.SQL.Add(DBMain.SQLlist.Trees.TreeByName('ViewEquip').TextByName('w_Budget'));;

//Окончание SQL запроса добавляем изначальную сортировку данных.SQL.Add('Order by e.equip_num,e.equip_sets');

//У запроса очищяем страрые условия поиска.DeleteVariables;

//Анализируем полученных запрос и создаем переменные-параметры(qryViewEquip);

//Если есть фильтр по отделу, присваиваем значения

// для фильтраqryViewEquip.VariableIndex('DEPT_NUM')<>-1qryViewEquip.SetVariable('DEPT_NUM',Trim(edtDeptPrj.Text));qryViewEquip.VariableIndex('EQUIP_TYPE_NAME')<>-1qryViewEquip.SetVariable('EQUIP_TYPE_NAME',Trim(lcEquipTypeID.Text));qryViewEquip.VariableIndex('BUILD_MANUF')<>-1qryViewEquip.SetVariable('BUILD_MANUF',Trim(lcBuild.Text));qryViewEquip.VariableIndex('DEPT_OWNER_NUM')<>-1qryViewEquip.SetVariable('DEPT_OWNER_NUM',Trim(edtShop.Text));

//При указание диапазона К\К используется тип поля SubDeptNameqryViewEquip.VariableIndex('SUB_DEPT_NAME')<>-1qryViewEquip.SetVariable('SUB_DEPT_NAME',Trim(edtSets.Text));qryViewEquip.VariableIndex('PRJ_LOT')<>-1qryViewEquip.SetVariable('PRJ_LOT',Trim(edtPrjLot.Text));qryViewEquip.VariableIndex('RV_FACILITY')<>-1qryViewEquip.SetVariable('RV_FACILITY',cbFacility.itemIndex);qryViewEquip.VariableIndex('PHASE_LIST')<>-1qryViewEquip.SetVariable('PHASE_LIST',Trim(edtPhaseList.Text));qryViewEquip.VariableIndex('EQUIP_NUM')<>-1qryViewEquip.SetVariable('EQUIP_NUM',(edtGroupEquip.Text)+Trim(edtEquipNum.Text)+Trim(edtEquipShop.Text)+Trim(edtPrj.Text)+'%');

qryViewEquip.VariableIndex('TURN_BAY')<>-1qryViewEquip.SetVariable('TURN_BAY',Trim(edtTurnBay.Text));qryViewEquip.VariableIndex('PHASE_NUM')<>-1qryViewEquip.SetVariable('PHASE_NUM',Trim(edtPhase.Text));

qryViewEquip.VariableIndex('DETAIL_NUM')<>-1qryViewEquip.SetVariable('DETAIL_NUM',Trim(edtDetail.Text));qryViewEquip.VariableIndex('MODEL_BENCH')<>-1qryViewEquip.SetVariable('MODEL_BENCH',Trim(edtModel.Text));qryViewEquip.VariableIndex('NODE_ID')<>-1qryViewEquip.SetVariable('NODE_ID',Trim(edtNodes.Text));qryViewEquip.VariableIndex('PERFORM_ID')<>-1qryViewEquip.SetVariable('PERFORM_ID',Trim(edtPerform.Text));qryViewEquip.VariableIndex('EQUIP_NAME')<>-1qryViewEquip.SetVariable('EQUIP_NAME',Trim(edtEquipName.Text));qryViewEquip.VariableIndex('OTHER_CHECK')<>-1qryViewEquip.SetVariable('OTHER_CHECK',Trim(edtOtherCheck.Text));qryViewEquip.VariableIndex('OTHER_CHECK_1')<>-1qryViewEquip.SetVariable('OTHER_CHECK_1',Trim(edtOtherCheck1.Text));qryViewEquip.VariableIndex('OTHER_CHECK_2')<>-1qryViewEquip.SetVariable('OTHER_CHECK_2',Trim(edtOtherCheck2.Text));qryViewEquip.VariableIndex('OTHER_CHECK_3')<>-1qryViewEquip.SetVariable('OTHER_CHECK_3',Trim(edtOtherCheck3.Text));qryViewEquip.VariableIndex('OTHER_CHECK_4')<>-1qryViewEquip.SetVariable('OTHER_CHECK_4',Trim(edtOtherCheck4.Text));qryViewEquip.VariableIndex('OTHER_CHECK_5')<>-1qryViewEquip.SetVariable('OT_CHECK_5',Trim(edtOtherCheck5.Text));

qryViewEquip.VariableIndex('PRG_NUM_KTI')<>-1qryViewEquip.SetVariable('PRG_NUM_KTI',Trim(edtPrgKti.Text));

qryViewEquip.VariableIndex('NOTE')<>-1qryViewEquip.SetVariable('NOTE',Trim(edtNote.Text));

qryViewEquip.VariableIndex('ADDON_DOC_NUM')<>-1qryViewEquip.SetVariable('ADDON_DOC_NUM',Trim(edtTZ.Text));

qryViewEquip.VariableIndex('EQUIP_TYPE')<>-1qryViewEquip.SetVariable('EQUIP_TYPE',dsEquipType.DataSet.FieldByName('TYPE_EQUIPMENT').AsString);qryViewEquip.VariableIndex('BUDGET_YEAR')<>-1:=Trim(edtBudget.Text);.actYearBudget.Caption:=cYearBudget+'- '+pYearBudget;.SetVariable('BUDGET_YEAR',Trim(edtBudget.Text));;qryViewEquip.VariableIndex('LEADING_DOCUMENT')<>-1qryViewEquip.SetVariable('LEADING_DOCUMENT',Trim(edtLeadDoc.Text));

qryViewEquip.VariableIndex('INVEST_ITEM')<>-1qryViewEquip.SetVariable('INVEST_ITEM',Trim(edtInvestItem.Text));

qryViewEquip.VariableIndex('CONTRACT_NUM')<>-1qryViewEquip.SetVariable('CONTRACT_NUM',Trim(edtContract.Text));

qryViewEquip.VariableIndex('SUB_CONTRACT_NUM')<>-1qryViewEquip.SetVariable('SUB_CONTRACT_NUM',Trim(edtContract.Text));

qryViewEquip.VariableIndex('MANUF')<>-1qryViewEquip.SetVariable('MANUF',Trim(edtManuf.Text));

qryViewEquip.VariableIndex('COUNTRY')<>-1qryViewEquip.SetVariable('COUNTRY',Trim(edtCountry.Text));

qryViewEquip.VariableIndex('START_COMPLEX')<>-1qryViewEquip.SetVariable('START_COMPLEX',Trim(edtStartComplex.Text));

//меняем системный курсор на вид SQLWait.Cursor:=crSQLWait;

//Сохраняем SQL запрос на диск для анализа

// для отладки программы.SQL.SaveToFile('fltr.sql');

//Выполняем запрос.Open;E:Exception do(E.Message);;.SelectedRows.Clear;

//Удаляем из сессионной таблице(временной работает только на сессию)

//ID записей попавших в предыдущий фильтр.qryExecute.SQL.Clear;.qryExecute.DeleteVariables; .qryExecute.SQL.Add(DBMain.SQLlist.Trees.TextByName('DeleteFiltered'));.qryExecute.ExecSQL;

//Добавляем ID записей попавших в текущий фильтр

//ID запсией используются в других запросах

//для быстрой работыDBMain.qryInsertFiltered Do.Clear;.Add(DBMain.SQLlist.Trees.TextByName('InsertFiltered'));.Add(Copy(qryViewEquip.SQL.Text,1,pos(Filtr_From,qryViewEquip.SQL.Text)-1)); SQL.Add(Copy(qryViewEquip.SQL.Text,pos(Filtr_To,qryViewEquip.SQL.Text)+Length(Filtr_to),(qryViewEquip.SQL.Text)-pos(Filtr_To,qryViewEquip.SQL.Text)+Length(Filtr_to)));

// SQL.SaveToFile('FileterdSes.SQL');;.Assign(qryViewEquip.Variables);('DATE_CUR');;E:Exception Do(E.Message);;

//Разрешаем изменние отображения визульных компонентов.EnableControls;.WriteString(rgSQLFiltr,mSelfIf.Lines.CommaText);.Cursor:=crDefault;.Sbar.Panels[3].Text:=pZone;:=DBMain.qryGetTask.FieldByName('NOTE').AsString;.Sbar.Panels[2].Text:=vTask;

// qryViewEquip.SQL.SaveToFile('ERRfltr.sql');;.Cursor:=crDefault;;;

2.5 Тестирование разрабатываемой системы

Тестирование программного обеспечения - процесс исследования программного обеспечения (ПО) с целью получения информации о качестве продукта [22].

1.       Функциональное тестирование (functional testing) - это тестирование ПО в целях проверки реализуемости функциональных требований, то есть способности ПО в определённых условиях решать задачи, нужные пользователям. Функциональные требования определяют, что именно делает ПО, какие задачи оно решает.

2.      Тестирование производительности (performance testing) - тестирование, которое проводится с целью определения, как быстро работает система или её часть под определённой нагрузкой.

.        Юзабилити-тестирование (usability testing) - исследование, выполняемое с целью определения, удобен ли некоторый искусственный объект для его предполагаемого применения (Проверка эргономичности).

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

.        Тестирование безопасности (security testing) - оценка уязвимости программного обеспечения к различным атакам.

Для тестирования систем ИС «Техническая подготовка производства» необходимо провести функциональное тестирование и тестирование производительности.

2.5.1 Функциональное тестирование ИС «Техническая подготовка производства»

Реализация проверки работы основных функций системы и функций форм:

Таблица 8 -Тестирование ИС «Техническая подготовка производства»