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

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

ВВЕДЕНИЕ

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

Для этого нужны исключительно гениальные люди, а, как известно, их крайне мало и рождаются они не часто. Задачей же Г.С. Альтшуллера было упростить метод поиска новой идеи, нового решения той или иной задачи. Исследовав более 40 тысяч патентов, Генрих Альтшуллер вывел определенные закономерности, на основании которых разработал теорию решения изобретательских задач, сокращенно ТРИЗ, знамением которой стал призыв превратить искусство изобретательства в точную науку [1]. Введя свои термины и обозначения, постоянно расширяя и дополняя свои теории, тем самым привлекая на свою сторону все больше и больше сторонников, Г.С. Альтшуллер сделал процесс разрешения технических противоречий для того или иного специалиста более понятным и точным, логичным, открыл доступ к созданию нового, не дожидаясь идей индивидуальных изобретателей. По факту, любой, способный к обучению и заинтересованный человек, мог бы придумывать новые методы и системы или же усовершенствовать уже имеющиеся. Данные труды получили широкую известность не только на территории бывших стран СССР, но и во многих других странах Европы и Азии, где они и по сей день успешно используются.



1. ПРЕДПРОЕКТНЫЙ АНАЛИЗ

1.1 Описание и анализ ТРИЗ

ТРИЗ -- теория решения изобретательских задач -- область знаний, исследующая механизмы развития технических систем с целью создания практических методов решения изобретательских задач. Цель ТРИЗ: выявление и использование законов, закономерностей и тенденций развития технических систем [2].

Автор ТРИЗ -- Генрих Саулович Альтшуллер.

Работа над ТРИЗ была начата Г. С. Альтшуллером и его коллегами в 1946 году. Первая публикация -- в 1956 году -- это технология творчества, основанная на идее о том, что «изобретательское творчество связано с изменением техники, развивающейся по определённым законам» и что «создание новых средств труда должно, независимо от субъективного к этому отношения, подчиняться объективным закономерностям». Появление ТРИЗ было вызвано потребностью ускорить изобретательский процесс, убрав все элементы случайности: внезапное и непредвиденное озарение, слепой перебор и отбрасывание вариантов, зависимость от настроения и т. п. Кроме того, целью ТРИЗ является улучшение качества и увеличение уровня изобретений за счёт снятия психологической инерции и усиления творческого воображения.

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

Перечислим основные функции ТРИЗ:

1. Решение творческих и изобретательских задач любой сложности и направленности без перебора вариантов.

2. Прогнозирование развития технических систем (ТС) и получение перспективных решений (в том числе и принципиально новых).

3. Развитие качеств творческой личности.

4. Решение научных и исследовательских задач.

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

6. Выявление причин брака и аварийных ситуаций.

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

8. Объективная оценка решений.

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

10. Развитие творческого воображения и мышления.

11. Развитие творческих коллективов.

ТРИЗ не является строгой научной теорией. ТРИЗ представляет собой обобщённый опыт изобретательства и изучения законов развития науки и техники [3-4].

В результате своего расширения ТРИЗ вышла за рамки решения изобретательских задач в технической области, и сегодня используется также в нетехнических областях (бизнес, искусство, литература, педагогика, политика и др.).

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

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



1.2 Обзор аналогов и прототипа TRIZ GB

TRIZ GB (рисунок 1) -- Это простая справочная программа для Android и iOS по системе изобретательских приемов. Пользователи могут дополнять систему своими примерами и обмениваться ими через электронную почту. Это приложение показало себя очень эффективным при освоении основ [5].

Рисунок 1 - Главное окно приложения TRIZ GB

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

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

Новатор

Новатор (рисунок 2) -- Это многофункциональная программа, предлагающая помощь при постановке задачи, построении модели ситуации, описания концепций и эффектов, математические формулы и определения терминов [7].

Рисунок 2- Работа аналога «Новатор»

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

Оптимизация работы с матрицей Альтшуллера

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

Рисунок 3 - Работа аналога, выбор параметров противоречий

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



Таблица 1 - Сравнительная таблица аналогов

Название аналогов	Количество пользователей	Взаимодействие с БД	Легкость в освоении	Выбор нескольких пар параметров противоречий	Хранение истории решения задач	Свободное распространение
TRIZ GB	1	-	+	-	-	-
Новатор	1	+	-	+	+	-
Оптимизация работы с матрицей Альтшуллера	1	-	+	-	-	+
ИС поддержки генерирования новых идей на основе энерго-информационного подхода	100	+	+	+	+	+

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

1.3 Цели создания системы и решаемые задачи

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

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

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

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

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



2. ПРОЕКТИРОВАНИЕ

2.1 Диаграмма вариантов использования

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

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

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

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

В диаграмму вариантов использования входят актанты (actors), варианты использования (use case) и ассоциации (association).

Диаграмма вариантов использования разработанной системы представлена на рисунке 4.

Система поддерживает авторизацию пользователя, а так же система содержит трех актантов: Изобретатель, Эксперт, Администратор.

Изобретатель и эксперт имеют доступ к работе с задачами. А администратору доступно ведение справочника пользователей.

Рисунок 4 - Диаграмма вариантов использования

2.2 Сценарий изменения приемов устранения технических противоречий

Вариант использования: Изменение приемов устранения технических противоречий.

Краткое описание: Позволяет Эксперту выбрать приём технического противоречия, а также изменить и сохранить измененную информацию о нем.

Актант: Эксперт.

Предусловия.

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

Основной поток событий:

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

А1:Работа с задачами по устранению ТП.

А2: Справка.

А3: Выход.

A4: Отчет о частоте использования параметров.

А5: Отчет о средней оценке приемов.

2. Система выводит на экран форму «Редактирование матрицы Альтшуллера», на которой отображены кнопки: «Работать с параметрами ТП», «Работать с приемами», «Работать с приемами устранения ТП».

3. Эксперт нажимает кнопку «Работать с приемами».

4. А6: Работать с параметрами ТП

5. А7: Работать с приемами устранения ТП.

6. Система выводит на экран форму «Работа с приемами», на которой размещен список приемов, редактируемое поле для описания приема, а также кнопки «Сохранить описание», «Добавить прием», «Удалить выбранный».

7. Эксперт выбирает необходимый прием, щелкает на него.

8. В редактируемое поле для описания система выводит описание данного приема.

9. Эксперт вносит необходимые ему изменения в описание приема. После чего нажимает кнопку «Сохранить описание».

А8: Добавить прием

А9: Удалить выбранный

10. Система сохраняет описание выбранного приема. Вариант использования завершается успешно.

Альтернативы

А1:Работа с задачами по устранению ТП.

А1.2:Эксперт нажимает кнопку «Работа с задачами по устранению ТП» расположенную в главном окне приложения.

А1.3: Выполняется вариант использования «Работа с задачами по устранению ТП».

А2: Справка

А2.1: Эксперт нажимает кнопку «Справка» расположенную в главном окне приложения.

А 2.2: Выполняется вариант использования «Справка».

А3: Выход

А3.1.: Эксперт нажимает кнопку «Выход».

А3.2.:Система завершает работу приложения, закрывает главное окно приложения и выводит на экран рабочий стол ОС.

А4: Отчет о частоте использования параметров.

А4.1:Эксперт нажимает кнопку «Отчет о частоте использования параметров» расположенную в главном окне приложения.

А4.2: Выполняется вариант использования «Формировать отчет о частоте использования параметров».

А5: Отчет о средней оценке приемов.

А5.1:Эксперт нажимает кнопку «Отчет о средней оценке приемов» расположенную в главном окне приложения.

А5.2: Выполняется вариант использования «Формировать отчет о средней оценке приемов».

А6: Работать с параметрами ТП.

А6.1.: Эксперт нажимает кнопку «Работать с параметрами ТП» расположенную на окне «Редактирование матрицы Альтшуллера».

А6.2.: Выполняется вариант использования «Работать с параметрами ТП».

A7: Работать с приемами устранения ТП.

А7.1.:Эксперт нажимает кнопку «Работать с параметрами устранения ТП» расположенную на окне «Редактирование матрицы Альтшуллера».

А7.2.: Выполняется вариант использования «Работать с параметрами устранения ТП».

A8: Добавить прием.

А8.1.: Эксперт нажимает кнопку «Добавить прием», расположенную на окне «Работа с приемами».

А8.2.:Система выводит на экран окно для ввода названия приема. После чего эксперт вводит название приема в редактируемое поле ввода и нажимает кнопку «Ок».

А 8.3: Система сохраняет введенный прием и добавляет его в конец списка расположенного на окне «Работа с приемами».

A9: Удалить выбранный.

А9.1:Эксперт выбирает необходимый для удаления прием из списка приемов, расположенных на окне «Работа с приемами».

А9.2.:Выбрав нужный прием, эксперт нажимает кнопку «Удалить выбранный», расположенную на окне «Работа с приемами».

А9.3:Система удаляет данный прием из списка приемов.

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

2.3 Диаграммы классов

2.3.1 Диаграмма сущностных классов

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

Главными сущностями разработанного программного комплекса являются: «Пользователь», «Список задач», «Параметры из списка задач», «Оценки», «Приемы», «Примеры из списка задач», «Параметр улучшен», «Параметр ухудшен», «Альтшуллер».

Рисунок 5 - Диаграмма сущностных классов

2.3.2 Диаграмма граничных классов

Объекты граничных классов реализуют интерфейсы системы с внешней средой и различными пользователями. На рисунке 3 представлена диаграмма граничных классов. Для того чтобы попасть в главное окно приложения, нужно пройти авторизацию, ввести логин и пароль. Для добавления, редактирования и удаления информации в справочниках имеют доступ эксперт и администратор. Если система не понятна для пользователя, он может активировать справку о системе. Все классы данной диаграммы представлены стереотипом «boundary». Класс «Форма авторизации» связан с классами «Главное окно приложения», «Сообщение об ошибке» посредством отношения «зависимость». Класс «Главное окно приложения» связан с классами «Окно справочника пользователей», «Окно работы с задачами по устранению ТП», «Окно справочников», «Окно справки» посредством отношения зависимость.

Рисунок 6 - Диаграмма граничных классов

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

2.3.3 Диаграмма классов управления

На рисунке 7 представлена диаграмма класса управления, объекты этих классов являются активными, берущими на себя управление и организацию вычислительных процессов; чаще всего это стандартные компоненты операционных систем и систем управления базами данных (СУБД), таймеры, координаторы и т.п.

На рисунке 7 изображена диаграмма классов управления. Все классы данной диаграммы имеют стереотип «control». Класс «Менеджер приложения» связан с классами «Менеджер СУБД» и «Менеджер ОС» посредством отношения «зависимость».

Рисунок 7 - Диаграмма классов управления



2.4 Схема алгоритма изменения приемов устранения технических противоречий

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

Рисунок 8 - Схема алгоритма изменения приемов устранения ТП

2.5 Логическая структура БД

Логический уровень - это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире, например «Автор», «Издательство» или «Авторский гонорар». Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами (подробнее о сущностях и атрибутах будет рассказано ниже). Логическая модель данных может быть построена на основе другой логической модели, например на основе модели процессов. Логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД [9].

На рисунке 9 изображена разработанная логическая модель базы данных. триз альтшуллер логический матрица

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

задач, для функционирования ИС было выделено девять сущностей: «Пользователь», «Список задач», «Параметры из списка задач», «Приемы из списка задач», «Оценки», «Параметр улучшен», «Параметр ухудшен», «Альтшуллер», «Приемы».

1. Пользователь - предназначена для хранения логинов и паролей пользователей и прохождения ими авторизации.

Атрибуты: id пользователя (PK), логин, пароль, права

2. Список задач - предназначена для хранения списка задач для определенных пользователей.

Атрибуты: id задачи, имя задачи, id пользователя.

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

Атрибуты: id задачи, id параметров ухудшенных, id параметров улучшенных.

4. Приемы из списка задач - предназначена для хранения для каждой задачи список приемов с их оценками за выбранную задачу.

Атрибуты: id задачи, id приема, id оценки.

5. Оценки - предназначена для хранения названия и веса оценок приемов.

Атрибуты: id оценки, имя оценки, значение оценки.

6. Параметр ухудшен - предназначена для хранения списка всех параметров, которые ухудшаются.

Атрибуты: id параметра, имя параметра.

7. Параметр улучшен - предназначена для хранения списка всех параметров, которые улучшаются.

Атрибуты: id параметра, имя параметра.

8. Альтшуллер - предназначена для хранения матрицы Г.С. Альтшуллера.

Атрибуты: id параметров ухудшенных, id параметров улучшенных, id приема.

9. Приемы - предназначена для хранения списка всех приемов и пути к файлу с их описанием.

Атрибуты: id приема, имя приема, путь к приему.

Рисунок 9 - Логическая структура базы данных

3. ПРОЕКТИРОВАНИЕ

3.1 Диаграмма вариантов использования

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

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

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

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

В диаграмму вариантов использования входят актанты (actors), варианты использования (use case) и ассоциации (association).

Диаграмма вариантов использования разработанной системы представлена на рисунке 4.

Система поддерживает авторизацию пользователя, а так же система содержит трех актантов: Изобретатель, Эксперт, Администратор.

Изобретатель и эксперт имеют доступ к работе с задачами. А администратору доступно ведение справочника пользователей.

Рисунок 4 - Диаграмма вариантов использования

3.2 Сценарий изменения приемов устранения технических противоречий

Вариант использования: Изменение приемов устранения технических противоречий.

Краткое описание: Позволяет Эксперту выбрать приём технического противоречия, а также изменить и сохранить измененную информацию о нем.

Актант: Эксперт.

Предусловия.

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

Основной поток событий:

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

А1:Работа с задачами по устранению ТП.

А2: Справка.

А3: Выход.

A4: Отчет о частоте использования параметров.

А5: Отчет о средней оценке приемов.

12. Система выводит на экран форму «Редактирование матрицы Альтшуллера», на которой отображены кнопки: «Работать с параметрами ТП», «Работать с приемами», «Работать с приемами устранения ТП».

13. Эксперт нажимает кнопку «Работать с приемами».

14. А6: Работать с параметрами ТП

15. А7: Работать с приемами устранения ТП.

16. Система выводит на экран форму «Работа с приемами», на которой размещен список приемов, редактируемое поле для описания приема, а также кнопки «Сохранить описание», «Добавить прием», «Удалить выбранный».

17. Эксперт выбирает необходимый прием, щелкает на него.

18. В редактируемое поле для описания система выводит описание данного приема.

19. Эксперт вносит необходимые ему изменения в описание приема. После чего нажимает кнопку «Сохранить описание».

А8: Добавить прием

А9: Удалить выбранный

20. Система сохраняет описание выбранного приема. Вариант использования завершается успешно.

Альтернативы

А1:Работа с задачами по устранению ТП.

А1.2:Эксперт нажимает кнопку «Работа с задачами по устранению ТП» расположенную в главном окне приложения.

А1.3: Выполняется вариант использования «Работа с задачами по устранению ТП».

А2: Справка

А2.1: Эксперт нажимает кнопку «Справка» расположенную в главном окне приложения.

А 2.2: Выполняется вариант использования «Справка».

А3: Выход

А3.1.: Эксперт нажимает кнопку «Выход».

А3.2.:Система завершает работу приложения, закрывает главное окно приложения и выводит на экран рабочий стол ОС.

А4: Отчет о частоте использования параметров.

А4.1:Эксперт нажимает кнопку «Отчет о частоте использования параметров» расположенную в главном окне приложения.

А4.2: Выполняется вариант использования «Формировать отчет о частоте использования параметров».

А5: Отчет о средней оценке приемов.

А5.1:Эксперт нажимает кнопку «Отчет о средней оценке приемов» расположенную в главном окне приложения.

А5.2: Выполняется вариант использования «Формировать отчет о средней оценке приемов».

А6: Работать с параметрами ТП.

А6.1.: Эксперт нажимает кнопку «Работать с параметрами ТП» расположенную на окне «Редактирование матрицы Альтшуллера».

А6.2.: Выполняется вариант использования «Работать с параметрами ТП».

A7: Работать с приемами устранения ТП.

А7.1.:Эксперт нажимает кнопку «Работать с параметрами устранения ТП» расположенную на окне «Редактирование матрицы Альтшуллера».

А7.2.: Выполняется вариант использования «Работать с параметрами устранения ТП».

A8: Добавить прием.

А8.1.: Эксперт нажимает кнопку «Добавить прием», расположенную на окне «Работа с приемами».

А8.2.:Система выводит на экран окно для ввода названия приема. После чего эксперт вводит название приема в редактируемое поле ввода и нажимает кнопку «Ок».

А 8.3: Система сохраняет введенный прием и добавляет его в конец списка расположенного на окне «Работа с приемами».

A9: Удалить выбранный.

А9.1:Эксперт выбирает необходимый для удаления прием из списка приемов, расположенных на окне «Работа с приемами».

А9.2.:Выбрав нужный прием, эксперт нажимает кнопку «Удалить выбранный», расположенную на окне «Работа с приемами».

А9.3:Система удаляет данный прием из списка приемов.

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

3.3 Диаграммы классов

3.3.1 Диаграмма сущностных классов

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

Главными сущностями разработанного программного комплекса являются: «Пользователь», «Список задач», «Параметры из списка задач», «Оценки», «Приемы», «Примеры из списка задач», «Параметр улучшен», «Параметр ухудшен», «Альтшуллер».

Рисунок 5 - Диаграмма сущностных классов

3.3.2 Диаграмма граничных классов

Объекты граничных классов реализуют интерфейсы системы с внешней средой и различными пользователями. На рисунке 3 представлена диаграмма граничных классов. Для того чтобы попасть в главное окно приложения, нужно пройти авторизацию, ввести логин и пароль. Для добавления, редактирования и удаления информации в справочниках имеют доступ эксперт и администратор. Если система не понятна для пользователя, он может активировать справку о системе. Все классы данной диаграммы представлены стереотипом «boundary». Класс «Форма авторизации» связан с классами «Главное окно приложения», «Сообщение об ошибке» посредством отношения «зависимость». Класс «Главное окно приложения» связан с классами «Окно справочника пользователей», «Окно работы с задачами по устранению ТП», «Окно справочников», «Окно справки» посредством отношения зависимость.

Рисунок 6 - Диаграмма граничных классов

3.3.3 Диаграмма классов управления

На рисунке 7 представлена диаграмма класса управления, объекты этих классов являются активными, берущими на себя управление и организацию вычислительных процессов; чаще всего это стандартные компоненты операционных систем и систем управления базами данных (СУБД), таймеры, координаторы и т.п.

На рисунке 7 изображена диаграмма классов управления. Все классы данной диаграммы имеют стереотип «control». Класс «Менеджер приложения» связан с классами «Менеджер СУБД» и «Менеджер ОС» посредством отношения «зависимость».

Рисунок 7 - Диаграмма классов управления



3.4 Схема алгоритма изменения приемов устранения технических противоречий

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

Рисунок 8 - Схема алгоритма изменения приемов устранения ТП

3.5 Логическая структура БД

Логический уровень - это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире, например «Автор», «Издательство» или «Авторский гонорар». Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами (подробнее о сущностях и атрибутах будет рассказано ниже). Логическая модель данных может быть построена на основе другой логической модели, например на основе модели процессов. Логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД [9].

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

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

задач, для функционирования ИС было выделено девять сущностей: «Пользователь», «Список задач», «Параметры из списка задач», «Приемы из списка задач», «Оценки», «Параметр улучшен», «Параметр ухудшен», «Альтшуллер», «Приемы».

10. Пользователь - предназначена для хранения логинов и паролей пользователей и прохождения ими авторизации.

Атрибуты: id пользователя (PK), логин, пароль, права

11. Список задач - предназначена для хранения списка задач для определенных пользователей.

Атрибуты: id задачи, имя задачи, id пользователя.

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

Атрибуты: id задачи, id параметров ухудшенных, id параметров улучшенных.

13. Приемы из списка задач - предназначена для хранения для каждой задачи список приемов с их оценками за выбранную задачу.

Атрибуты: id задачи, id приема, id оценки.

14. Оценки - предназначена для хранения названия и веса оценок приемов.

Атрибуты: id оценки, имя оценки, значение оценки.

15. Параметр ухудшен - предназначена для хранения списка всех параметров, которые ухудшаются.

Атрибуты: id параметра, имя параметра.

16. Параметр улучшен - предназначена для хранения списка всех параметров, которые улучшаются.

Атрибуты: id параметра, имя параметра.

17. Альтшуллер - предназначена для хранения матрицы Г.С. Альтшуллера.

Атрибуты: id параметров ухудшенных, id параметров улучшенных, id приема.

18. Приемы - предназначена для хранения списка всех приемов и пути к файлу с их описанием.

Атрибуты: id приема, имя приема, путь к приему.

Рисунок 9 - Логическая структура базы данных

4. РЕАЛИЗАЦИЯ ПРОЕКТА

4.1 Архитектура и платформа реализации

4.1.1 Описание архитектуры

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

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

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

4.1.2 Библиотека Qt 5.5.1

Qt -- кросс платформенный инструментарий разработки ПО на языке программирования C++. Qt позволяет запускать написанное с его помощью ПО в большинстве современных операционных систем путем простой компиляции программы для каждой ОС без изменения исходного кода. Включает в себя все основные классы, которые могут потребоваться при разработке прикладного программного обеспечения, начиная от элементов графического интерфейса и заканчивая классами для работы с сетью, базами данных и XML. Qt является полностью объектно-ориентированным, легко расширяемым и поддерживающим технику компонентного программирования [10].

4.1.3 СУБД Microsoft Office Access 2007

MSAccess--реляционная СУБД корпорации Microsoft входящий в пакет программ MSOffice. Access включает связанные запросы, связь с внешними таблицами и базами данных. Благодаря встроенному языку VBA, в самом Access можно писать приложения, работающие с базами данных.

4.1.4 Язык программирования C++

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

Стандартная библиотека включает, в том числе, общеупотребительные контейнеры и алгоритмы. C++ сочетает свойства как высокоуровневых, так и низкоуровневых языков. В сравнении с его предшественником -- языком C,-- наибольшее внимание уделено поддержке объектно-ориентированного и обобщённого программирования. C++ широко используется для разработки программного обеспечения, являясь одним из самых популярных языков программирования. Область его применения включает создание операционных систем, разнообразных прикладных программ, драйверов устройств, приложений для встраиваемых систем, высокопроизводительных серверов, а также развлекательных приложений (игр). Существует множество реализаций языка C++, как бесплатных, так и коммерческих и для различных платформ. Например, на платформе x86 это GCC, Visual C++, Intel C++ Compiler, Embarcadero (Borland) C++ Builder и другие. C++ оказал огромное влияние на другие языки программирования, в первую очередь на Java и C#. Синтаксис C++ унаследован от языка C. Одним из принципов разработки было сохранение совместимости с C. Тем не менее, C++ не является в строгом смысле надмножеством C; множество программ, которые могут одинаково успешно транслироваться как компиляторами C, так и компиляторами C++, довольно велико, но не включает все возможные программы на C [11].

4.1.5 Инструмент моделирования StarUML

StarUML - это UML инструмент, программное приложение , которое поддерживает некоторые или все нотации и семантику, связанную с унифицированного языка моделирования (УЯМ), который является отраслевым стандартом общего назначения моделирование язык для разработки программного обеспечения.

4.2 Физическая структура БД

Физическая модель данных зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация обо всех объектах БД. Поскольку стандартов на объекты БД не существует (например, нет стандарта на типы данных), физическая модель зависит от конкретной реализации СУБД. Следовательно, одной и той же логической модели могут соответствовать несколько разных физических моделей. Если в логической модели не имеет значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах - таблицах, колонках, индексах, процедурах и т. д. На рисунке 10 изображена разработанная физическая структура базы данных.

Рисунок 10 - Физическая структура базы данных

4.3 Расчет комплекса технических средств (КТС)

4.3.1 Расчёт требуемых ресурсов внешней памяти

По формуле (1) был проведен расчёт ресурсов внешней памяти.

, Гбайт, (1)

где V_ВП - общий объем внешней памяти, Гбайт;

V_ОС - объем внешней памяти, занимаемый операционной системой, Гбайт;

V_СУБД - объем внешней памяти, требуемый занимаемый СУБД, Гбайт;

V_данных - объем внешней памяти занимаемый программными модулями, Гбайт;

V_{программы} - объем внешней памяти, занимаемый программными модулями, Гбайт;

V_ОС - объем внешней памяти, по паспорту для операционной системы windows 7 x64 - 20 гб;

V_СУБД - объем внешней памяти, требуемый для хранения файлов СУБД по паспорту для MS access 2007 - 2 гб;

В таблице 2 показан расчёт максимального объема базы данных.

Таблица 2 - Расчет объёма БД

Таблица БД	Размер записи, байт	Макс. кол-во записей	Размер индекса, байт	Всего, байт
Altshuller	24	10000	36000	276000
Parametres_left	263	100	3945	30245
Parametres_right	263	100	3945	30245
Priems	518	150	11655	89355
Rates	271	15	610	4675
Task_inside_parametres	24	12000	43200	331200
Task_inside_priems	24	12000	43200	331200
Task_list	271	8000	325200	2493200
Users	158	100	2370	18170
	3604290

Таблица 3 - Расчет объема внешних текстовых файлов

Название	Размер файла, Кб	Макс. кол-во файлов	Всего, Кб
Priems	14	100	1400
1400

V_{программы} - 0.0013 + 0.006 = 0.0073 Гбайт;

V _данных - 0.0033 Гбайт;

V_ВП - V_ОС (20) + V_СУБД (2) + V_данных (0.0033) + V_{программы} (0.0073) = 22.01 Гб

4.3.2 Расчёт требуемых ресурсов оперативной памяти

Для расчета ОЗУ воспользуемся формулой , где V_ОП - общий объем оперативной памяти, Мбайт;

V_ОС - объем оперативной памяти, требуемый для установки операционной системы, Мбайт;

V_СУБД - объем оперативной памяти, требуемый для установки СУБД, Мбайт, Мбайт;

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

базы данных и результатов выполнения функций, Мбайт;

V_{программы} - объем оперативной памяти, необходимой для хранения

текстов и библиотек приложений, Мбайт.

V_ОС- по паспорту для операционной системы windows 7 x64 -2048 мб;

V_СУБД - по паспорту для СУБД MS access 2007 - 256 мб;

V _данных - 3.37 мб;

V _{программы} - 7.47 мб;

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

Таблица 4 - Расчет объема буфера оперативной памяти, необходимой для выбора необходимых приемов.

Таблица БД	Размер записи, байт	Макс. кол-во записей	Размер индекса, байт	Всего, байт
Task_inside_parametres	24	12000	43200	331200
Task_inside_priems	24	12000	43200	331200
Task_list	271	8000	325200	2493200
Итого:	3155600

Суммарный объем ОЗУ, необходимый для функционирования системы:

Vоп = VОС (2048) + VСУБД(256) + Vданных(3.37) + Vпрограммы(7.47)= 2314.84 мб.

4.4 Основные интерфейсы

После запуска приложения появляется окно авторизации (рисунок 11).

Рисунок 11 - Окно авторизации

После ввода валидных логина и пароля открывается главное окно приложения (рисунок 12).

Рисунок 12 - Главное окно приложения

Функционал, доступный только для ваших прав отделен от остального с целью упрощения работы. При нажатии кнопки «Работа с задачами по устранению ТП» откроется окно работы с задачами по устранению ТП (рисунок 13)

Рисунок 13 - Окно задач по устранению ТП

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

Рисунок 14 - Окно работы с задачами по устранению ТП

Данную задачу можно сохранить нажав на кнопку «Сохранить задачу» и введя название, при этом выставленные оценки будут учитываться для общей в последующих задачах (рисунок 15).

Рисунок 15 - Окно ввода названия задачи

4.5 Диаграмма компонентов

4.5.1 Диаграмма компонентов

Диаграмма компонентов - диаграмма, на которой изображены типы компонентов и зависимости между ними.

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

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

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

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

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

- Визуализации общей структуры исходного кода программной системы;

- Спецификации исполнимого варианта программной системы;

- Обеспечения многократного использования отдельных фрагментов программного кода;

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

В таблице 5 дано краткое описание основных компонентов системы.

Таблица 5 - Основные классы системы

Класс	Описание
basewidget.cpp	базовый класс для создания остальных классов
mainwidget.cpp	класс главного окна приложения
userseditwidget.cpp	класс окна редактирования справочника пользователей
editaltshullerwidget.cpp	класс окна редактирования справочников
workwithtask.cpp	класс окна работы с задачами по устранению ТП

Диаграмма компонентов разработанной системы приведена на

рисунке 16, она отражает компоненты системы и связи между ними.



Рисунок 16 - диаграмма компонентов

4.6 Диаграмма развертывания

Диаграмма развёртывания - это завершающая диаграмма технологии UML. Она показывает общее развертывание компонентов системы на технических узлах системы и служит для моделирования работающих узлов (аппаратных средств) и артефактов, развёрнутых на них.

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

К основным способам выполнения компонентов относятся программный, аппаратный и программно-аппаратный способы.

Диаграмма развертывания разработанной системы представлена на рисунке 17.

Рисунок 17 - Диаграмма развертывания



4.7 Программа и методика испытаний

1. Объект испытаний.

1.1. Наименование испытуемой программы.

Наименование - «Программа поддержки генерирования новых идей на основе энерго-информационного подхода».

1.2. Область применения испытуемой программы.

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

1.3. Обозначение испытуемой программы.

Наименование темы разработки - «Информационная система поддержки генерирования новых идей на основе энерго-информационного подхода».

2. Цель испытаний.

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

3. Требования к программе.

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

4. Требования к программной документации.

4.1. Состав программной документации, предъявляемой на испытания.

Состав программной документации должен включать в себя:

1. техническое задание;

2. пояснительная записка;

3. руководство пользователя.

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

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

5. СРЕДСТВА И ПОРЯДОК ИСПЫТАНИЙ

5.1. Программные средства, используемые во время испытаний.

Системные программные средства «Altshuller.exe», должны быть представлены локализованной версией операционной системы Windows 7.

5.2. Порядок проведения испытаний.

Испытания проводятся в два этапа:

1 этап - ознакомительный.

2 этап - испытания.

5.2.1. Перечень проверок проводимых на 1 этапе испытаний.

Перечень проверок, проводимых на 1 этапе испытаний, должен включать в себя:

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

б) проверку комплектности и состава технических и программных средств.

Методики проведения проверок, входящих в перечень по 1 этапу испытаний, изложены в данном программном документе, в разделе «Методы испытаний».

5.2.2. Перечень проверок проводимых на 2 этапе испытаний.

Перечень проверок, проводимых на 2 этапе испытаний, должен включать в себя:

а) проверку соответствия технических характеристик программы;

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

- авторизация в системе по логину и паролю;

- настройка прав доступа;

- вывод приемов устранения выбранных технических противоречий и их рейтинга, отсортированного в порядке убывания.

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

- формировать отчет о наиболее часто используемых параметрах;

- формировать отчет о средних оценках приемов;

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

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

- редактирование матрицы Альтшуллера путем добавления или удаления приемов для устранения конкретных пар параметров.

Методики проведения проверок, входящих в перечень по 2 этапу испытаний, изложены в данном программном документе, в разделе «Методы испытаний».

5.3. Количественные и качественные характеристики, подлежащие оценке.

5.3.1. Количественные характеристики, подлежащие оценке.

В ходе проведения приемо-сдаточных испытаний оценке подлежат количественные характеристики, такие как:

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

- комплектность состава технических и программных средств.

5.3.2. Качественные характеристики, подлежащие оценке.

В ходе проведения приемо-сдаточных испытаний оценке подлежат качественные (функциональные) характеристики программы. Проверке подлежит возможность выполнения программой перечисленных ниже функций:

- проверка работоспособности программы;

- проверка на сообщение об ошибке.

5.4. Условия проведения испытаний.

5.4.1. Климатические условия.

Испытания должны проводиться в нормальных климатических условиях по ГОСТ 22261-94. Условия проведения испытаний приведены ниже:

- температура окружающего воздуха, °С 20 ± 5;

- относительная влажность, % - от 30 до 80;

- атмосферное давление, кПа - от 84 до 106;

- частота питающей электросети, Гц - 50 ± 0,5;

- напряжение питающей сети переменного тока,

В - 220 ± 4,4.

5.4.2. Условия начала и завершения отдельных этапов испытаний.

Необходимым и достаточным условием завершения 1 этапа испытаний и начала 2 этапа испытаний является успешное завершение проверок, проводимых на 1 этапе (см. п. Перечень проверок, проводимых на 1 этапе испытаний).

Условием завершения 2 этапа испытаний является успешное завершение проверок, проводимых на 2 этапе испытаний (см. п. Перечень проверок, проводимых на 2 этапе испытаний).

5.4.3. Ограничения в условиях испытаний.

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

5.4.4. Меры, обеспечивающие безопасность и безаварийность испытаний.

При проведении испытаний должно быть обеспечено соблюдение требований безопасности, установленных ГОСТ 12.2.007.0-75 8), «Правилами техники безопасности при эксплуатации электроустановок потребителей», и «Правилами технической эксплуатации электроустановок потребителей».

6. МЕТОДЫ ИСПЫТАНИЙ.

6.1. Методика проведения проверки комплектности программной документации.

В ходе проверки сопоставляется состав и комплектность программной документации, представленной Разработчиком, с перечнем программной документации, приведенным в п. «Состав программной документации, предъявляемой на испытания» настоящего документа.

6.2. Методика проведения проверки комплектности и состава технических и программных средств.

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