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

• Содержание
• Введение
• 1. Обзор аналогов
• 1.1 Разработка изделий
• 1.2 Управление изменениями
• 1.3 Интеграция приложений
• 1.4 Пакет решений в области управления конструкторской и технологической документацией (КТД)
• 2. Программная документация
• 2.1 Техническое задание
• 2.1.1 Общие сведения
• 2.1.2 Назначение разработки
• 2.1.3 Описание технологии задачи
• 2.1.4 Обеспечение прав доступа
• 2.1.5 Технические требования к программному продукту
• 2.1.6 Стадии и этапы разработки
• 2.1.7 Порядок контроля
• 2.2 Пояснительная записка
• 2.2.1 Назначение разработки и область применения
• 2.2.2 Технические характеристики
• 2.2.3 Состав программных средств
• 2.2.4 Ожидаемые технико-экономические показатели
• 2.3 Описание программы
• 2.3.1 Общие сведения
• 2.3.2 Функциональное назначение
• 2.3.3 Описание логической структуры
• 2.3.4 Используемые технические средства
• 2.3.5 Вызов и загрузка
• 2.3.6 Входные данные
• 2.3.7 Выходные данные
• 2.4 Программа и методика испытаний
• 2.4.1 Объект и цель испытаний
• 2.4.2 Требования к программе
• 2.4.3 Средства и порядок испытаний
• 2.4.4 Методика испытаний
• 3. Руководство оператора
• 3.1 Описание рабочего процесса
• 3.1.1 Работа с главным меню
• 3.1.2 Работа с окнами — общие сведения
• 3.1.3 Работа с окном «Менеджер классов»
• 3.1.4 Работа с окном системы «Пользователи и группы»
• 3.1.5 Работа с окном для генерации созданных классов
• 3.1.6 Работа со справочниками «Типы атрибутов», «Правила вычисления эффективной версии», «Этапы жизненного цикла»
• 3.1.7 Работа со справочником «Функции»
• 3.1.8 Работа со справочником «Программы обработки файлов»
• 3.1.9 Справочник «Виды вычисления эффективной версии»
• 3.1.10 Поиск в экранных таблицах, применение фильтров
• 3.2 Описание ролей пользователей
• 4. Акт испытаний
• 4.1 Объект и цель испытаний
• 4.2 Требования к программе
• 4.3 Средства и порядок испытаний
• 4.3.1 Инфраструктура тестирования
• 4.3.2 Процедуры тестирования
• 5. Экономическая часть
• 5.1 Определение потребительского сегмента рынка разрабатываемого продукта
• 5.2 Сравнение с аналогами
• 5.3 Важнейшие показатели спроса
• 5.4 Расчет себестоимости программного продукта
• 5.5 Определение цены разработчика
• 5.6 Определение эффекта производства и применения программного продукта, его конкурентоспособности
• 6. Материалы по охране труда
• 6.1 Организация рабочего места программиста
• 6.2 Оптимальные условия труда программиста
• 6.2.1 Анализ зрительной деятельности
• 6.2.2 Анализ электробезопасности
• 6.2.3 Анализ пожарной опасности
• 6.2.4 Анализ опасных и вредных излучений
• 6.2.5 Параметры микроклимата на рабочем месте
• 6.2.6 Нормирование шума
• 6.2.7 Вибрации
• 6.2.8 Анализ психофизиологических факторов
• Заключение
• Список используемой литературы
• Приложение А
• Приложение Б
• Приложение В

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

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

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

2. Внедрение на одном предприятии ряда различных систем (программы описания, расчета, хранилища) нередко определяет и различные представления одних и тех же данных. Этот факт усложняет взаимодействие систем и требует значительных затрат времени на преобразование данных из одной системы в вид, доступный другой системе.

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

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

Все вышеперечисленные проблемы в рассмотрении определили комплекс решений, названный PDM — Product Data Management (Управление производственными данными). Данный комплекс решений предлагает создание универсальной системы хранения данных о производственном изделии. Следует отметить разнородность данных в этом случае. Сюда относятся любые данные, относящиеся к производимой или разрабатываемой продукции, такие как файлы систем CAD/CAM/CAE, спецификации, структуры изделия, конструкторско-технологическая документация, конфигурационная информация, и т. д. Технология PDM позволяет структурировать их как единую систему, где для каждого конкретного изделия не только определяется совокупность централизованно хранящихся данных по его описанию, но и выделен перечень этапов жизненного цикла.

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

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

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

1. Обзор аналогов

Еще одной PDM-системой, наиболее широко распространенной на данный момент является комплекс решений, предлагаемых Teamcenter Engineering, реализуемый фирмой EDS Corporation, США. Он включает в себя основные направления по управлению жизненным циклом изделия. Эти решения охватывают все службы предприятия и позволяют обеспечить информацией различные категории сотрудников.

1.1 Разработка изделий

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

Teamcenter Engineering обеспечивает оптимальное управление всеми процессами разработки изделия, решая задачи в таких основных областях как управление составом изделия, управление проектированием и управление изменениями. Teamcenter Engineering имеет полный набор модулей для решения этих задач:

— управление данными САПР (интерфейсы к системам Unigraphics, AutoCAD, SolidEdge, CATIA, Pro/Engineer, SolidWorks);

— классификаторы (in-CLASS);

— управление бизнес-процессами (Workflow);

— управление структурой изделия (PSE).

1.2 Управление изменениями

Модуль Teamcenter Engineering по управлению инженерными изменениями позволяет пользователям контролировать структурные взаимосвязи как внутри изделия, так и между изделием и такими процессами, как производство, или процессы управления. Он полностью интегрирован в модули управления бизнес-процессами и структурой изделия. Электронная почта своевременно уведомит пользователей о готовящемся или совершившемся изменении через Lotus Notes или Microsoft Outlook. Предусмотрены возможности по просмотру «генеалогии» (дерева) изменений и управлению принятием решений.

1.3 Интеграция приложений

Teamcenter Engineering позволяет построить любые IT-решения, которые соединят воедино все базы данных внутри и вне компании, решая проблемы несовместимых форматов, различных приложений и удаленных инсталляций. Для этого Teamcenter Engineering имеет полный набор средств для интеграции, который включает в себя приложения по управлению данными об изделии, интегрированные приложения третьесторонних компаний, стандартный механизм разработки пользовательских приложений (API), и полный комплект решений по сопровождению и дополнительным услугам.

1.4 Пакет решений в области управления конструкторской и технологической документацией (КТД)

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

Система решает следующие основные задачи:

— ведение единой централизованной базы данных по электронной конструкторской документации.

— интеграция с системами трехмерного и двумерного проектирования (Unigraphics, SolidEdge,

— SolidWorks, AutoCAD, CATIA, Pro/Engineer, и др.).

— создание и ведение электронных конструкторских спецификаций и извещений.

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

— возможность групповой работы конструкторов над проектом.

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

— ведение заказных комплектаций изделия.

— исключение дублирования информации в базе данных.

— обеспечение надежного и безопасного хранения проектных данных.

С помощью этой системы конструкторы и технологи имеют возможность вносить данные в базу, пользуясь специальными карточками изделия, осуществлять управление ревизиями изделий, автоматически импортировать сборки из систем САПР, привязывать любые электронные документы к конструкторским элементам с возможностью их дальнейшего редактирования в среде Teamcenter Engineering. Система обеспечивает ассоциативную связь между атрибутами детали в базе данных и элементами основной надписи электронного чертежа. В систему также входят возможности по созданию электронных справочников на базе модуля классификации in-Class, включая стандартные справочники по материалам и стандартным изделиям.

Таким образом, комплекс решений Teamcenter Engineering представляет собой полный функциональный набор PDM-системы. Это мощное и гибкое приложение.

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

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

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

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

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

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

— приложение не предъявляет особых требований как к операционной системе, так и к программному обеспечению, расположенному на машине;

— приложение не требует предварительной настройки оператором, что делает ее хорошо защищенной от сбоев и зависаний;

— интуитивно ясный интерфейс доступен не только программисту, но и пользователю ЭВМ;

— это изначально русское приложение, учитывающее российские стандарты и не требующее смены кодировок и услуг переводчиков;

— территориальные барьеры с разработчиками несравнимо меньше.

2. Программная документация

2.1 Техническое задание

2.1.1 Общие сведения

Полное наименование приложения — «Объектно-ориентированный менеджер структуры универсальной системы хранения данных». Краткое обозначение — «Менеджер классов».

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

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

Сокращения и термины:

БД — база данных;

СУБД — система управления базой данных;

ПО — программное обеспечение;

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

Несистемные (пользовательские) атрибуты — атрибуты, значения которых устанавливаются пользователями системы. Такие атрибуты доступны для чтения и изменения;

Версия — некоторое фиксированное состояние объекта в определенный момент времени характеризуемое набором атрибутов;

Эффективная версия — конкретное состояние объекта в заданный момент времени.

2.1.2 Назначение разработки

Менеджер классов предназначен для реализации следующих основных задач:

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

— обеспечение централизованного доступа к данному хранилищу информации.

Эти цели должны достигаться:

— посредством создания и поддержки базы данных, работа с которой должна быть возможна из любого подключения к корпоративной вычислительной сети предприятия-заказчика;

— посредством создания API-функций для работы с объектами хранилища.

2.1.3 Описание технологии задачи

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

Классы подразделяются на два вида — классы объектов и классы связей. Соответственно, классы объектов описывают объекты, а классы связей — различные связи между ними.

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

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

Каждый мастер-объект и версия обязательно имеют идентификаторы, которые называются <�Код мастер-объекта> и <�Номер версии> соответственно. Таким образом, идентификатор объекта в определенный момент времени задается как <�Код мастер-объекта>.<�Номер версии>.

Обязательные атрибуты класса объектов:

— наименование (NAME) — уникальное отображаемое имя класса (например, «Спецификация», «Узел», «Деталь» и т. п.);

— признак «замороженности» класса (IS_FROZEN) — указывает, можно ли изменять описание класса или удалить его.

Основные операции над классами объектов:

— Создание нового класса. Создается запись о новом классе, пользовательские атрибуты не определены;

— Удаление класса. Удаляется запись о классе и всех его пользовательских атрибутах. Удаление класса возможно, если он не заморожен и нет ни одного объекта данного класса;

— Добавление, изменение описания и удаление атрибутов класса;

— Добавление и удаление этапов жизненного цикла из перечня этапов;

— Добавление и удаление правил вычисления эффективной версии из перечня правил;

— Заморозить класс — изменения и удаление класса запрещено;

— Разморозить класс — изменения и удаление класса возможны.

Обязательные атрибуты мастер-объекта:

— код мастер-объекта (OBJ_CODE) — уникальный идентификатор мастер-объекта в следующем формате MMMM. NNNN, где

a) «MMMM» — общая часть наименования таблицы БД, где находится данный мастер-объект;

b) «NNNN» — уникальный идентификатор записи о данном мастер-объекте в таблице БД (ID записи);

— признак «замороженности» мастер-объекта (IS_FROZEN) — указывает, можно ли изменять мастер-объект или удалить его;

— по крайней мере, одно правило вычисления эффективной версии;

— поля для управления доступом к объекту (см. 2.1.4).

Версия — некоторое фиксированное состояние объекта в определенный момент времени.

Обязательные атрибуты версии:

— ссылка на мастер-объект (ID_MASTER_OBJ) — уникальный код мастер-объекта (ID записи), к которому относится данная версия;

— номер версии (VERSION) — порядковый номер версии для данного мастер-объекта, представляет собой целое число, нумерация начинается с 1;

— признак замороженности версии (IS_FROZEN) — указывает, можно ли изменять версию или удалить ее;

— признак check-in/check-out (IS_CHECK) — указывает на то, что версия заблокирована пользователем (взята на редактирование);

— ссылка на текущий статус версии (ID_LC_STAGE) — уникальный код этапа жизненного цикла объекта.

Второй вид классов — классы связей. Это структуры данных, описывающие отношения между объектами в системе. Используются два вида связей:

— <�Мастер-объект> - <�версия данного мастер-объекта>. Связи данного вида называются иерархическими связями и не обладают атрибутами. Они создаются автоматически при создании версии объекта.

— <�Версия объекта> - <�другой мастер-объект>. Связи данного вида называются логическими и создаются пользователями системы. Такие связи имеют атрибуты.

Обязательные атрибуты класса связей:

— прямое наименование (DIRECT_VERB) — наименование, используемое в описании отношения родительского объекта к подчиненному объекту. Например, в предложении «Узел состоит из Детали1 и Детали2» фраза «состоит из» — это прямое наименование;

— обратное наименование (INVERSE_VERB) — наименование, используемое в описании отношения подчиненного объекта к родительскому объекту. Например, в предложении «Деталь1 входит в Узел» фраза «входит в» — это обратное наименование;

— признак замороженности связи (IS_FROZEN) — указывает, можно ли изменять описание класса или удалить его.

Основные операции над классами связей:

— создание нового класса. Создается запись о новом классе, присоединяемые атрибуты не определены;

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

— добавление, изменение описания и удаление атрибутов класса;

— заморозить класс — изменения и удаление класса запрещено;

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

Обязательные атрибуты логической связи:

— код мастер-объекта, от которого идет связь (PARENT_OBJ_CODE);

— уникальный идентификатор записи (ID записи) о версии, от которой идет связь (ID_VERSION);

— код мастер-объекта, к которому идет связь (CHILD_OBJ_CODE)

— признак check-in/check-out (IS_CHECK) — указывает на то, что связь заблокирована пользователем (взята на редактирование).

Допустимые операции над логическими связями:

— Установление или изменение привязки логической связи;

— Редактирование несистемных атрибутов логической связи;

— Чтение атрибутов связи.

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

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

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

Допустимые операции над правилом выбора эффективной версии:

— модификация;

— чтение.

Атрибут — элемент данных, описывающий одну характеристику класса. Типы атрибутов, поддерживаемые системой:

— Char — одиночный символ

— String [N] - строка символов длиной N символов (максимальная длина соответствует ограничению используемой СУБД)

— Integer — целое число

— Real [N.D] - действительное число, где D — дробная часть.

— Date — дата (включая год, месяц, число, час, минуты, секунды)

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

— SFunction — статическая функция. Значение атрибута данного типа генерируется в момент создания объекта путем вызова определенной функции, хранимой в БД системы. При всех дальнейших операциях чтения объекта значение атрибута не изменяется. Обязательно указание имени функции и всех необходимых параметров.

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

— ItemReference — атрибут данного типа описывает ссылку на объект (экземпляр) другого класса. Обязательно указание идентификатора объекта в формате <�Код мастер-объекта>.<�Номер версии>.

— File — атрибут данного типа описывает ссылку на внешний файл, хранимый в файловой системе. Обязательно указание программы обработки файла путем выбора из справочника системы.

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

Для каждого класса, связи, мастер-объекта и версии обязательно существуют следующие системные атрибуты:

— Дата создания (Date);

— Кто создал (String);

— Дата последнего изменения (Date);

— Кто изменил (String);

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

Допустимые операции над всеми несистемными атрибутами:

— модификация (кроме типов SFunction и DFunction);

— чтение.

Приведенное выше описание будет реализовано в БД следующим образом:

Структура БД условно разделяется на две части: постоянную и переменную (генерируемую). Постоянная часть содержит следующие объекты БД (таблицы, представления, индексы и т. д.):

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

— справочники этапов жизненного цикла и правил вычисления эффективной версии;

— справочники для описания прав доступа;

— таблицы для хранения зарегистрированных пользователей и групп пользователей;

— описание классов объектов и связей с их атрибутами.

Объекты постоянной части имеют постоянные имена в БД, установленные разработчиками системы УСХД. Структура объектов постоянной части представлена в приложении А.

Сначала администратор структуры — пользователь менеджера классов — создает описание прикладной системы посредством создания необходимых классов и других вспомогательных данных. Затем «замораживает» созданные классы и выполняет генерацию объектов переменной части БД. Данные действия выполняются посредством вызова специальных API-функций.

После этого БД новой прикладной системы готова для работы с ней конечных пользователей.

2.1.4 Обеспечение прав доступа

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

Работа с классами будет возможна только под ролью «Администратор структуры».

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

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

Также, для каждого пользователя назначается главная группа (PRIMARY GROUP) — группа пользователей, определяющая его основные права доступа.

При создании мастер-объекта для него сохраняется создавший его пользователь. Он становится владельцем объекта.

Также, доступ к определенному объекту хранилища определяется разрешениями, которые хранятся для каждого мастер-объекта.

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

Выполнение какой-либо операции над объектами возможно, если пользователь имеет разрешения на ее выполнение.

Для обеспечения системы доступа для мастер-объектов добавляются следующие обязательные поля:

— ссылка на владельца объекта (ID_OWNER) — уникальный код пользователя-владельца объекта;

— разрешение «Чтение» владельца (PERM_READ_OWNER);

— разрешение «Изменение» владельца (PERM_WRITE_OWNER);

— разрешение «Изменение статуса» владельца (PERM_CHSTATUS_OWNER);

— разрешение «Чтение» главной группы (PERM_READ_PG);

— разрешение «Изменение» главной группы (PERM_WRITE_PG);

— разрешение «Изменение статуса» главной группы (PERM_CHSTATUS_PG);

— разрешение «Чтение» других групп (PERM_READ_OG);

— разрешение «Изменение» других групп (PERM_WRITE_OG);

— разрешение «Изменение статуса» других групп (PERM_CHSTATUS_OG).

2.1.5 Технические требования к программному продукту

Требования к функциональным характеристикам

Менеджер классов должен обеспечивать:

- поддержку типов атрибутов, указанных в 2.1.3;

— ввод, хранение и изменение описаний классов объектов и связей с набором необходимых атрибутов;

— ввод, хранение и изменение допустимых связей для классов объектов;

— поддержку этапов жизненного цикла объектов;

— поддержку двух правил выбора эффективной версии:

a) эффективной является версия с максимальным номером — данное правило по умолчанию присваивается всем мастер-объектам;

b) эффективной является версия на заданную дату — использование данного правила подразумевает, что для версии установлен интервал ее эффективности;

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

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

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

Требования к надежности

— некорректное завершение программы не должно сказываться на целостности и правильности хранимой в базе данных информации;

— необходимо своевременное копирование резервных данных;

— длительность восстановления системы не должна превышать 10 минут, поскольку данная система является системой коллективного пользования;

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

Условия эксплуатации

— необходимо наличие должностных инструкций для каждого рабочего места;

— предполагается, что каждое рабочее место подключено к общей корпоративной сети предприятия-заказчика.

Требования к составу и параметрам аппаратных средств

К серверу (конфигурация: процессор семейства х86 с тактовой частотой не менее 2400 Гц, оперативная память не менее 1 Гб, жесткий диск емкостью не менее 120 Гб, сетевая карта 100 Мбит/сек) подключены автоматизированные рабочие места (АРМ) и удаленные рабочие места (УРМ) следующей конфигурации: процессор семейства х86 с тактовой частотой не менее 1700 Гц, оперативная память не менее 256 Мб, жесткий диск емкостью не менее 20 Гб, сетевая карта 100 Мбит/сек.

Требования к информационной и программной совместимости

— требования к серверу: операционная система компьютера Windows 2003 Server: используемая СУБД — Oracle Server 9i;

— требования к рабочим местам: операционная система Windows 9x/2000/XP.

Специальные требования

Необходимо сообщать о нелегальном копировании данного программного продукта.

2.1.6 Стадии и этапы разработки

Стадии и приблизительные сроки разработки документации:

— техническое задание — 20.03.06

— пояснительная записка — 20.04.06

— описание программного продукта — 20.04.06.

Стадии разработки самого программного продукта:

1) Стадия разработки технического задания:

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

— определение методики решения задачи — составление алгоритма реализации проекта;

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

— определение технических требований к системе;

— составление технического задания.

2) Стадия уточнения:

— уточнение функционального набора приложения;

— подготовка предварительной документации.

3) Стадия конструирования:

— кодирование программного продукта;

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

— разработка плана тестирования программного продукта;

— непосредственное тестирование программного продукта.

4) Стадия внедрения:

— подготовка программного продукта к вводу в действие;

— подготовка персонала;

— строительно-монтажные и пуско-наладочные работы;

— проведение предварительных испытаний;

— введение в опытную эксплуатацию;

— проведение приемочных испытаний.

5) Стадия сопровождения:

— выполнение работ в соответствии с гарантийным обслуживанием;

— послегарантийное обслуживание.

2.1.7 Порядок контроля

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

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

2.2 Пояснительная записка

программа меню оператор справочник

Полное наименование приложения — «Объектно-ориентированный менеджер структуры универсальной системы хранения данных». Краткое обозначение — «Менеджер классов».

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

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

2.2.1 Назначение разработки и область применения

Менеджер классов предназначен для реализации следующих основных задач:

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

— обеспечение централизованного доступа к данному хранилищу информации.

Эти цели должны достигаться:

— посредством создания и поддержки базы данных, работа с которой должна быть возможна из любого подключения к корпоративной вычислительной сети предприятия-заказчика;

— посредством создания API-функций для работы с объектами хранилища.

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

2.2.2 Технические характеристики

Постановка задачи на разработку программы

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

— описание структуры объектов в виде классов, содержащих метаданные, описывающие объект.

— реализация двух видов классов, позволяющих получать иерархические структуры данных:

a) класс объектов данных, обеспечивающий описание структуры объектов данных;

b) класс объектов связи, который обеспечивает описание объектов, определяющих отношения между объектами данных;

— в программе должен быть реализован контроль прав доступа к объектам.

— функциональность по манипулированию объектами и доступом к ним должна быть реализована в виде API-функций на хранимых процедурах Oracle.

— программа должна использовать в качестве хранилища СУБД Oracle.

Метод организации данных

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

API SQL

Рисунок 2.1 — Трехзвенная модель взаимодействия клиента и сервера.

На компьютере клиенте выполняется только компонент представления, т. е. реализуется интерфейс с пользователем. Клиент обращается за выполнением услуг к прикладному компоненту, играя роль клиента приложений — AC. Обращение к прикладному компоненту происходит на языке прикладного интерфейса API. Прикладной компонент реализован как группа процессов, выполняющая прикладные функции. Прикладной компонент играет роль сервера приложений — AS. Со своей стороны он получает доступ к ресурсам у сервера базы данных DB, на котором сосредоточен компонент доступа к ресурсам, т. е. по отношению к этому серверу, сервер AS играет роль клиента. Таким образом, в этой схеме сервер приложений как в роли сервера, так и в роли клиента [2,3].

Перенося данную модель на платформу Oracle [4,5], выбирают следующую схему взаимодействия приложения и базы данных. Это псевдо трехзвенная архитектура (см. рисунок 2.2).

Рисунок 2.2 — Трехзвенная модель Oracle

При запуске приложения на локальной машине выполняются следующие действия:

шаг 1. запускается Runtime-клиент (файл Ora8/Bin/ifrun60.exe);

шаг 2. осуществляется запрос нужного приложения (fmx-файла) с сервера приложений;

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

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

2.2.3 Состав программных средств

Менеджер классов можно логически разделить на три логические части — базу данных, набор API-функций и непосредственно клиентское приложение. Эти части могут реализовываться независимо друг от друга. Так для разработки структуры базы данных и пакетов API-функций использовалась среда SQL Navigator 4.1 [6], а для разработки клиентского ПО — инструментарий Oracle Forms 6i.

SQL Navigator 4.1

SQL Navigator создан компанией Quest Software. Это среда разработки с графическим интерфейсом пользователя, предлагающая следующие средства:

— Автоформатирование операторов PL/SQL и SQL;

— Отладчик PL/SQL;

— Средство просмотра баз данных (браузер).

Операторы SQL и PL/SQL выполняются из окна редактора SQL. Это окно может выполнить либо один оператор, либо целый сценарий. Блоки PL/SQL, содержащиеся в сценарии, должны заканчиваться знаком /. Можно выполнять отдельный оператор в сценарии или часть сценария. Имеется окно выходных данных, котрое будет содержать результаты каждого оператора (в случае запроса будут выведены данные), и в дополнение в нем могут быть показаны команды SQL или PL/SQL.

Дополнительные средства SQL Navigator:

Навигатор базы данных. Позволяет просматривать объекты в базе данных. DB Navigator имеет различные фильтры, которые можно использовать для ограничения показываемых объектов (текущим пользователем, например). Двойной щелчок мыши на объекте будет вызывать его для редактирования.

Отдельные окна редактирования. Предлагаются отдельные типы окон редактирования для таких объектов базы данных, как таблицы, представления, сценарии SQL, блоки PL/SQL, хранимые процедуры, триггеры и роли. Эти окна предоставляют графический интерфейс, который автоматически создает правильные команды SQL на основе ввода пользователя.

Построитель запросов. Позволяет графически выбирать таблицы и столбцы для запроса, а также вводить WHERE и другие предложения оператора SELECT. Утилита построения запросов может также использоваться для автоматического создания инструкций DML.

Ошибки PL/SQL. Если отправленный блок PL/SQL содержит ошибки компиляции, они будут показаны при компиляции объектов в редакторе хранимых программ. По щелчку мыши на ошибке будет выделена строка исходного кода, а по двойному щелчку будет вызвано окно с указанием причины и действий, предлагаемых в документации Oracle.

Шаблоны кода. Утилита Code Assistant, доступная в меню Tools, предоставляет библиотеку наиболее часто используемых конструкций PL/SQL и SQL. Выделение определенной конструкции вызывает описание в информационном окне Code Assistant, а двойной щелчок мыши копирует конструкцию в доступное окно редактирования, где ее можно изменить в соответствии с потребностями.

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

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

Oracle Forms 6i

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

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

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

Oracle Forms и другие инструменты Oracle Developer оптимизированы под Oracle Server.

Компоненты Oracle Forms

При построении программ с помощью Oracle Forms используются три компонента:

— Oracle Forms Designer;

— Oracle Forms Compiler;

— Oracle Forms Runtime.

Designer — это среда для разработки прикладных программ, в которой вы работаете с тремя типами модулей Oracle Forms — формами, меню и библиотеками. Designer включает набор визуальных инструментов, позволяющих создавать объекты, устанавливать их свойства и писать программные модули для прикладных программ.

Компонент Generate используется для генерации файлов прикладных программ. При этом компилируются все программные объекты модуля и создается исполняемый файл.

Компонент Runform — это среда исполнения, в которой выполняются модули прикладной программы.

Модули Oracle Forms

Прикладные программы Oracle Forms включают три типа модулей, представленных в таблице 2.1:

Таблица 2.1 — Типы модулей

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

Прикладная программа Oracle Forms может также включать модули от других инструментов Oracle Developer, таких как Oracle Reports и Oracle Graphics. Например, кнопка в форме может вызывать отчет, построенный с помощью Oracle Reports. Или в форму может быть вставлен вывод диаграммы, сгенерированной с помощью Oracle Graphics. Такой модульный подход предоставляет максимальную гибкость при проектировании и разработке новых прикладных программ, а также для поддержки и улучшения существующих.

Основные моменты

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

— запрос, вставка, обновление и удаление записей;

— определение запросов;

— координацию главных и подчиненных записей;

— управление навигацией;

— вывод объектов на экран.

Многие свойства объектов можно устанавливать как во время выполнения программы (в состоянии RunTime), а также во время проектирования (состояние DesignTime).

О блоках и элементах. Во время создания интерфейса вашей прикладной программы вы работаете с двумя основными типами объектов Oracle Forms — блоками и элементами. Элементы — это такие объекты интерфейса, которые выводят на экран информацию для пользователей и позволяют им взаимодействовать с прикладной программой. Oracle Forms поддерживает стандартные элементы интерфейса, включая кнопки, переключатели, радио-группы, элементы списка, элементы неизменного текста, элементы изображения, а также OLE-контейнеры, элементы диаграмм Oracle Graphics и VBX Controls.

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

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

Блоки — это только логические группировки. Элементы в блоке формы могут выстраиваться в любом порядке и могут даже выводиться на экран в разных окнах. Форма может включать любое количество блоков, и блок может включать любое количество элементов.

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

Программы в Oracle Forms пишутся на языке PL/SQL, процедурном языковом расширении Oracle для SQL. PL/SQL объединяет возможности манипулирования данными и обработки транзакций с конструкциями, обычно встречающимися в процедурных языках программирования, такими как объявления переменных и констант, присвоения, циклы и условное ветвление.

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

О триггерах. Первый способ добавления в форму программного кода — посредством триггеров. Триггер — это блок программы PL/SQL, подсоединяемый к определенному объекту и который исполняется в ответ на определенное событие. Например, для создания командной кнопки нужно создать на форме кнопку, затем подсоединить триггер When-Button-Pressed, который исполнит нужную программный код. Как предполагает его название, триггер When-Button-Pressed исполняется, или срабатывает, всякий раз при нажатии этой кнопки.

Oracle Forms предоставляет множество событий, на которые вы можете реагировать с помощью триггеров. Вместе со стандартными интерфейсными событиями, такими как щелчок мыши в кнопке или на переключателе, Oracle Forms предоставляет доступ к множеству событий внутренней обработки. Например, триггер When-Validate-Item срабатывает тогда, когда Oracle Forms проверяет достоверность значения в элементе текста. По умолчанию проверка достоверности происходит согласно определенному набору правил событий. Поняв однажды эти правила, то есть модель событий Oracle Forms, возможно писать триггеры для управления любым аспектом поведения вашей прикладной программы.

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

В дополнение к встроенным подпрограммам Oracle Forms возможно также писать собственные процедуры, функции и пакеты. Эти объекты, собирательно именуемые как программные модули, могут определяться в модулях форм, меню или библиотек. Определив однажды процедуру или функцию, можно вызывать ее в триггерах, командах меню и других программных модулях.

О делении прикладных программ. PL/SQL — это язык, используемый как для прикладных программ Oracle Forms со стороны клиента, так и для триггеров и сохраненных процедур со стороны базы данных сервера, и двигатель PL/SQL имеется как в Oracle Forms Runform, так и в Oracle Server. Это означает, что возможно разделять программный код прикладной программы для исполнения или на клиенте (компьютере пользователя), или на сервере. Деление прикладной программы позволяет оптимизировать работу и использование ресурсов путем сохранения и исполнения процедур локально или на сервере, в зависимости от того, что наиболее выгодно для конкретной прикладной программы и конфигурации.

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

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

2.2.4 Ожидаемые технико-экономические показатели

Внедрение данной программы на предприятии позволит:

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

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

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

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

2.3 Описание программы

2.3.1 Общие сведения

Полное наименование приложения — «Объектно-ориентированный менеджер структуры универсальной системы хранения данных». Краткое обозначение — «Менеджер классов».

Для корректного функционирования приложения на автоматизированном рабочем месте (АРМ) следует дополнительно установить операционную систему семейства Windows 9х. Поскольку приложение сетевое, то предпочтительнее использовать операционные системы Windows NT либо Windows XP, имеющих рад встроенных функций, улучшающих сетевое взаимодействие. Так же тип СУБД, используемый при разработке данного программного продукта — Oracle — налагает определенные требования на дополнительное программное обеспечение. Таким образом, на АРМ необходимо установить Oracle Developer версии не ниже 6i, либо подключить пользователя приложений к пакету задач Oracle.