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

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

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 08.10.2018
Размер файла 2,5 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

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

РЕФЕРАТ

Дипломный проект.

Пояснительная записка: 105 с., 31 рис., 11 источников, 3 приложения.

Графическая документация: 9 л. А4.

ИНФОРМАЦИОННАЯ СИСТЕМА, ИЗОБРЕТАТЕЛЬСКАЯ ДЕЯТЕЛЬНОСТЬ, ПАТЕНТЫ, ФИЗИЧЕСКИЕ ЭФФЕКТЫ

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

Цель работы - создание системы для помощи изобретателю в выборе идеи использования физического эффекта.

Разработано информационное и программное обеспечение системы по методологии UML. Сформирована информация по привязке физических эффектов, действий и идей к патентам.

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

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

1. СИСТЕМОТЕХНИЧЕСКАЯ ЧАСТЬ

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

1.2 Описание аналогичных систем

1.3 Постановка задачи

1.4 Разработка логического проекта системы

1.5 Выбор КТС и расчет быстродействия системы

2. КОНСТРУКТОРСКО-ТЕХНОЛОГИЧЕСКАЯ ЧАСТЬ

2.1 Выбор и обоснование архитектуры системы

2.2 Выбор средств реализации программной системы

2.3 Диаграммы поведения

2.4 Разработка физической модели базы данных

2.5 Разработка программного обеспечения

2.6 Диаграмма компонентов и развертывания

2.7 Описание интерфейсных решений

2.8 Разработка программы и методики испытания

2.9 Описание контрольного примера

2.10 Разработка руководства пользователя

3. ТЕХНИКО-ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ СИСТЕМЫ

3.1 Краткая характеристика работы и ее назначение

3.2 Расчет затрат на разработку информационной системы (ИС)

3.3 Расчет-прогноз минимальной цены разработки ИС

3.4 Расчет единовременных затрат на внедрение ИС

3.5 Расчет текущих затрат на функционирование ИС

3.6 Оценка безубыточности и расчет целесообразного объема продаж

3.7 Расчет экономической эффективности инвестиционных затрат

4. РАБОТКА МЕРОПРИЯТИЙ ПО БЕЗОПАСНЫМ УСЛОВИЯМ ТРУДА

4.1 Общие положения

4.2 Требования к производственным помещениям для работы с ПЭМВ

4.3 Требования к освещению рабочих мест

4.4 Оптимальные параметры микроклимата

4.5 Требования к уровням шума и вибрации

4.6 Требования к уровням электромагнитных полей, создаваемых ПЭВМ на рабочих местах

4.7 Общие требования к организации рабочих мест пользователя

ЗАКЛЮЧЕНИЕ

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

ПРИЛОЖЕНИЕ

ВВЕДЕНИЕ

Издавна перед человеком вставало множество задач, требующих нестандартного, творческого подхода. И так же издавна люди решали их методом проб и ошибок, последовательно перебирая множество вариантов и выбирая среди них тот, который оказывался наиболее работоспособным. При этом сам акт творчества рассматривался как нечто почти мистическое и необъяснимое. Попытки контролировать и управлять этим процессом приводили лишь к психологическим советам (часто довольно абсурдным) от "ищите ассоциативную связь вашей задачи с каким-нибудь случайным предметом" до "обливайтесь холодной водой, как Бетховен". Подобные советы и до сих пор пользуются популярностью благодаря своей простоте и кажущейся доступности - так заманчиво стать творческим человеком, всего лишь поиграв в слова или выпив чашечку кофе для активизации мыслительных процессов. Однако в сороковых-пятидесятых годах в СССР появилась новая наука - теория решения изобретательских задач (ТРИЗ), которая стала первой наукой, действительно сумевшей адекватно описать процесс творчества [1].

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

В этой работе будут рассмотрены основы ТРИЗ, а также ее усовершенствование с помощью метода принятия решений.

1. СИСТЕМОТЕХНИЧЕСКАЯ ЧАСТЬ

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

Введение в ТРИЗ

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

Основные функции и области применения ТРИЗ:

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

2. прогнозирование развития технических систем;

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

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

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

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

Изобретательская ситуация и изобретательская задача

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

Поэтому первый шаг на пути к изобретению - переформулировать ситуацию таким образом, чтобы сама формулировка отсекала бесперспективные и неэффективные пути решения. При этом возникает вопрос, какие решения эффективны, а какие - нет [3]?

Г. Альтшуллер предположил, что самое эффективное решение проблемы -- такое, которое достигается «само по себе», только за счёт уже имеющихся ресурсов. Таким образом, он пришёл к формулировке идеального конечного результата (ИКР): «Некий элемент (X-элемент) системы или окружающей среды сам устраняет вредное воздействие, сохраняя способность выполнять полезное воздействие».

На практике идеальный конечный результат редко достижим полностью, однако он служит ориентиром для изобретательской мысли. Чем ближе решение к ИКР, тем оно лучше.

Получив инструмент отсечения неэффективных решений, можно переформулировать изобретательскую ситуацию в стандартную мини-задачу: «согласно ИКР, всё должно остаться так, как было, но либо должно исчезнуть вредное, ненужное качество, либо появиться новое, полезное качество». Основная идея мини-задачи в том, чтобы избегать существенных (и дорогих) изменений и рассматривать в первую очередь простейшие решения[3].

Формулировка мини-задачи способствует более точному описанию задачи:

- Из каких частей состоит система, как они взаимодействуют?

- Какие связи являются вредными, мешающими, какие - нейтральными, и какие - полезными?

- Какие части и связи можно изменять, и какие -- нельзя?

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

Противоречия как прием ТРИЗ

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

ТРИЗ выделяет 3 вида противоречий (в порядке возрастания сложности разрешения):

- административное противоречие: «надо улучшить систему, но я не знаю как (не умею, не имею права) сделать это». Это противоречие является самым слабым и может быть снято либо изучением дополнительных материалов, либо принятием/снятием административных решений;

- техническое противоречие: «улучшение одного параметра системы приводит к ухудшению другого параметра». Техническое противоречие -- это и есть постановка изобретательской задачи. Переход от административного противоречия к техническому резко понижает размерность задачи, сужает поле поиска решений и позволяет перейти от метода проб и ошибок к алгоритму решения изобретательской задачи, который либо предлагает применить один или несколько стандартных технических приёмов, либо (в случае сложных задач) указывает на одно или несколько физических противоречий;

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

Виды эффектов

Известны следующие виды эффектов:

- Технологический эффект -- это преобразование одних технологических воздействий в другие. Могут требовать привлечения других эффектов -- физических, химических и т. п.;

- Физические эффекты. Известно около пяти тысяч физических эффектов и явлений. В разных областях техники могут применяться различные группы физических эффектов, но есть и общеупотребительные. Их примерно 300--500;

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

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

- Математические эффекты. Среди математических эффектов наиболее разработанными являются геометрические.

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

1.2 Описание аналогичных систем

КТТТ

КТТТ - компьютерная технология технического творчества базирующаяся на ТРИЗ. Программа разработана для решения творческих задач и создания проекта изобретения представлена на рисунке 1.1.

Рисунок 1.1 - КТТТ

Ноу-хау

Ноу-хау - это web-приложение, в котором организован поиск оригинальных идей для изобретений (рисунок 1.2). Также имеется возможность размещения своих идей для создания изобретения [4].

Рисунок 1.2 - Ноу-хау

Для наглядности ниже приведена таблица 1.1, в которой наглядно представлены характеристики описанных аналогов.

Таблица 1.1 - Сравнение аналогов

Свойства

КТТТ

Ноу-хау

FIdea

Формулирование направлений поиска

+

+

+

Оценка эффективности идей

+

-

+

Подбор и описание близких патентов

-

-

+

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

1.3 Постановка задачи

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

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

2. Расчет эффективности идеи использования по критериям;

3. Формирование и выдача отчетов.

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

1.4 Разработка логического проекта системы

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

Конструктивное использование языка UML основывается на применении общих принципов объектно-ориентированного проектирования:

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

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

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

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

- Вариантов использования;

- Классов;

- Поведения:

- Состояний;

- Деятельности;

- Взаимодействия:

- Последовательности;

- Кооперации;

- Реализации:

- Компонентов;

- Развертывания.

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

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

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

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

Разработка сценариев вариантов использования

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

Сценарий варианта использования «Вести справочник физических эффектов».

Вариант использования: Вести справочник физических эффектов.

Краткое описание: Дает возможность Администратору БД добавлять, редактировать и удалять записи о физических эффектах и сохранять изменения в БД. Является расширением варианта использования «Вести справочники».

Актант: Администратор БД.

Предусловия: Выполняется вариант использования «Вести справочники» до точки расширения «Справочник физических эффектов». На экране - главная форма приложения, с меню, настроенным на права Администратора БД.

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

1) В главном меню Администратор БД щелкает пункт “Справочники” и далее подпункт «Физические эффекты».

2) Система открывает форму ведения справочника физических эффектов с таблицей, содержащей столбцы «Название физического эффекта» и «Описание физического эффекта». Таблица заполнена записями о физ. эффектах, имеющихся в БД. На форме имеются кнопки «Добавить запись», «Удалить запись».

3) Администратор БД выбирает нужное поле для редактирования и дважды по нему щелкает для изменения записи.

А1: Добавление записи.

А2: Удаление записи.

4) Система дает возможность редактирования выбранной записи с полями: «Название физического эффекта» и «Описание физического эффекта», заполненные текущими данными БД.

5) Администратор БД щелчками выбирает нужное поле для редактирования и производит изменение текста, после чего нажимает кнопку «Enter»на клавиатуре для сохранения записи.

6) Система сохраняет измененные данные в БД. На экране - главная форма ведения справочника физ. эффектов.

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

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

А1: Добавление записи.

А1.1) Система создает новое поле в таблице для добавления записи с полями: «Название физического эффекта» и «Описание физического эффекта».

А2.2) Администратор БД щелкает на поле «Название физического эффекта» и вводит название физического эффекта. Аналогичным образом происходит процесс заполнения поля «Описание физического эффекта». После введения данных Администратор БД нажимает кнопку «Enter» на клавиатуре для сохранения записи.

А2.3) Система сохраняет измененные данные в БД. На экране - главная форма ведения справочника физ. эффектов.

А2.4 А1: Нажата кнопка «Отмена».

А2.4 А1.1) Система закрывает форму, изменения не сохраняются. Выполняется пункт 2 основной последовательности.

А3: Удаление записи.

А3.1) Администратор БД курсором выбирает ненужную запись в списке и щелкает кнопку «Удалить».

А3.2) Система выводит диалоговое окно с надписью: «Подтвердите удаление» с кнопками «Подтвердить» и «Отмена».

А3.3) Администратор БД щелкает кнопку «Подтвердить».

А3.3 А1: Нажата кнопка «Отмена».

А3.3 А1.1) Система закрывает диалоговое окно, не удаляя запись.

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

А3.4) Система удаляет выбранную запись из справочника и закрывает диалоговое окно.

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

Сценарий варианта использования «Подбор идеи использования физического эффекта»

Вариант использования: Подбор идей использования физического эффекта.

Краткое описание: Дает возможность Изобретателю подобрать идею использования физического эффекта.

Актант: Изобретатель.

Предусловия: На экране - главная форма приложения, с меню, настроенным на права Изобретателя.

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

1) В главном меню Изобретатель щелкает пункт “Подбор идей использования физ.эффектов”.

2) Система открывает форму подбора идей со списком критериев: «Тип энергии», «Выполняемое действие». На форме имеются кнопки «Подбор» и «Отмена».

3) Изобретатель последовательно заполняет поля, выбирая нужное значение из выпадающего списка, после чего щелкает на кнопку «Подбор».

А1: Нажата кнопка «Отмена».

4) Система выдает результат в виде списка идей использования с описанием использования данного физ.эффекта в различных патентах.

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

А1: Нажата кнопка «Отмена».

А1.1) Система закрывает форму подбора идей использования физ.эффекта и открывает главное меню, настроенное на права Изобретателя.

Выполняется пункт 1 основной последовательности.

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

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

Класс имеет имя, списки атрибутов, операций или методов.

Операция - спецификация (описание) результата преобразования или запроса, которые должен выполнить вызываемый объект. Имеет имя и список параметров.

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

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

Классы могут находиться между собой в различных отношениях (связях). Базовыми отношениями являются:

- отношения зависимости;

- отношения ассоциации;

- отношения обобщения;

- отношения реализации.

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

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

Диаграмма сущностных классов представлена на рисунке 1.4.

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

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

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

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

Сущность Патент - сущность, содержащая информацию о патенте, в том числе его название, номер и дату регистрации.

Сущность Тип энергии - отвечает за хранение типов энергии, описывающих физический эффект.

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

Сущность Идея использования - отвечает за хранение идей, использующихся в патентах.

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

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

Диаграмма классов управления комплекса представлена на рисунке1.5.

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

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

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

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

Диаграмма состояний

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

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

Рисунок 1.7 - Диаграмма состояний. Работа с приложением

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

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

Выделены следующие сущности:

? Физический эффект (id физ эффекта, название физ эффекта, описание физ эффекта)

? Вид энергии (id вида энергии, название вида энергии)

? Патент (id патента, дата, текст патента, название патента)

? Выполняемое действие (id выполн действия, описание выполн действия)

? Результат выполняемого действия (id результата, название результата)

? Идея использования (id идеи использования, описание идеи)

? Пользователь (id пользователя, логин, пароль)

Рисунок 1.8 - Логическая структура БД

1.5 Выбор КТС и расчет быстродействия системы

Расчет объема ВЗУ

Подведем расчет необходимой внешней памяти:

,

где - объем внешней памяти, занимаемый операционной системой, Мб;

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

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

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

В качестве ОС используется ОС Windows 7 SP1.

= 4 Гб.

В качестве СУБД используется MS Access.

= 10 Мб.

Рассчитаем максимальный объем хранимых данных системы за пять лет.

Таблица 1.2 - Расчет размера таблиц базы данных

Название таблицы

Размер записи, байт

Максимальное количество записей

Итого, байт

Пользователь

512

1000

512000

Роль

120

5

600

Физический эффект

256

100

25600

Выполняемое действие

128

1000

128000

Патент

700

1000

700000

Вид энергии

128

100

12800

Идея использования

256

1000

256000

Итого:

1635000

VПрограммы = 15Мб

= 1,6 Мб.

VВП = 4096 + 10 + 15 + 1,6 = 4122,6 Мб

Расчет необходимого объема ОЗУ

Для расчета ОЗУ воспользуемся формулой:

,

где - объем ОЗУ, необходимый для работы операционной системой, Мб;

- объем ОЗУ, необходимый для работы СУБД, Мб;

- объем ОЗУ, необходимый данным системы, Мб;

- объем ОЗУ, необходимый для работы программы, Мб;

VОС = 512 Мб.

= 15 Мб.

= 15 Мб.

= 9 Мб.

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

Расчет времени реакции системы

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

Общее время реакции системы на выполнение запроса рассчитывается по формуле (1.3):

,

,

,

,

.

- время на ввод входных данных запроса;

- коэффициент ошибок при вводе, для расчетов можно принять равным 1,5;

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

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

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

- количество считываемых физических блоков, зависит от количества обрабатываемых таблиц (файлов) и объема таблиц (файлов);

=0,006 сек - время позиционирования головок дискового накопителя;

=0,001 сек - время считывания физического блока в дисковом накопителе;

- время, затрачиваемое процессором на обработку информации с учетом выполнения циклов;

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

- среднее количество тактов машинных команд на одну операцию, для большинства случаев можно принять = 60;

= 1600*106 - тактовая частота процессора, Гц;

= средний объем таблицы, байт;

= 5 - количество таблиц, обрабатываемых в запросе;

= 512 байт - объем физического блока носителя, байт;

- время на вывод результата на устройство вывода или отображения, для принтера оценивается отдельно. Для дисплея можно принять 0,5с. (зависит от видеокарты и дисплея).

Результаты расчета времени реакции системы приведены в таблице 4.

Таблица 1.3- Расчет времени реакции системы

Параметр

Значение

Vтабл=

2048

Nбл=

1600

tввода= (секунд)

23

tсчитыв= (секунд)

0,035

tвычисл= (секунд)

0,0000375

tреакции=(секунд)

23,03

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

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

Согласно проведенным расчетам можно сделать вывод о технических требованиях к клиенту (специфических требований к клиенту нет, поэтому за основу взяты требования ОС Windows XP):

- процессор класса Pentium с тактовой частотой 1,4 ГГц и выше;

- рекомендуемый объем оперативного запоминающего устройства (ОЗУ) 512 Мбайт;

- жесткий диск емкостью не менее 40 Гбайт;

- видеокарта может быть любой, т.к. нет требований к производительности видеосистемы.

2. КОНСТРУКТОРСКО-ТЕХНОЛОГИЧЕСКАЯ ЧАСТЬ

2.1 Выбор и обоснование архитектуры системы

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

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

Рисунок 2.1 - Обобщенная схема работы с данными

Рассмотрим основные существующие архитектуры:
1. Файл-серверная - их иногда называют ПО с локальной БД. Характеризуются тем, что все три блока (1-2-3) выполняются в одной программе:

1.1.однопользовательская.

1.2.многопользовательская.

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

2.1. Простая - более точное название «2-х звенная»:

2.1.1. Клиент: 1-2; сервер: 3.

2.1.2. Клиент: 1; сервер: 2-3.

2.1.3. Клиент: 1-2; сервер: 2-3 (логика работы с данными распределяется между сервером и клиентом).

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

2.2.1. Клиент: 1; сервер: 3; СП: 2.

2.2.2. Клиент: 1-2; сервер: 3; СП: 2.

2.2.3. Клиент: 1; сервер: 2-3; СП: 2.

2.2.4. Клиент: 1-2; сервер: 3-2; СП: 2.

Цифрами показаны функции какого блока выполняет программа.

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

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

Развитием ПО в данной сфере в сторону поддержки многопользовательского использования и является файл-серверная многопользовательская архитектура. Сюда можно отнести такие известные программы как MS Word, MS Excell, а также аналоги других мощных офисных пакетов. Сюда же относятся СУБД: MS Access, FoxPro, SQLite и другие им подобные.

Плюсы:

? «Все в одном» - отсутствие в необходимости отдельных «серверов» и другого ПО (и соответственно необходимости покупки лицензий на дополнительное ПО).

? Применение стандартных форматов файлов дает широкий выбор альтернативного ПО (как платного, так и бесплатного).

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

Минусы:

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

? Большая нагрузка на сетевые ресурсы при удаленном размещении файлов данных.

? Высокая нагрузка на аппаратное обеспечение клиентской машины.

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

2.2 Выбор средств реализации программной системы

При выборе средств разработки системы необходимо выбрать такие средства, которые были бы эффективными и базировались на современных информационных технологиях. В качестве такой платформы была выбрана Microsoft .NET Framework [7].

Платформа .NET Framework -- это технология, которая поддерживает создание и выполнение нового поколения приложений.

.NET Framework состоит из общеязыковой среды выполнения (CLR) и библиотеки классов .NET Framework. Основой платформы .NET Framework является среда CLR.. Среда выполнения управляет кодом во время его выполнения и предоставляет основные службы, такие как управление памятью, управление потоками и удаленное взаимодействие, при этом контролирует проверку точности кода, гарантируя, тем самым, безопасность и стабильность приложений. Фактически основной задачей среды выполнения является управление кодом.

Библиотека классов является полным объектно-ориентированным набором типов, которые применяются для разработки приложений, начиная от обычных приложений, запускаемых из командной строки и заканчивая новейшими приложениями, такие как Web Forms и веб-службы XML.

Для реализации моей программной системы в качестве среды разработки была выбрана Microsoft VisualStudio 2010.

2.2.1 Microsoft VisualStudio 2010

Microsoft VisualStudio 2010 [8] олицетворяет собой представление корпорации Майкрософт об интеллектуальных клиентских приложениях и позволяет разработчикам быстро создавать подключаемые к базам данных приложения, способные обеспечить широчайшие возможности для работы пользователей.

VisualStudio 2010 представляет важные усовершенствования для разработчиков на основе трех главных идей.

- Быстрая разработка приложений;

- Эффективная совместная работа в группе;

- Новый пользовательский интерфейс.

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

В VisualStudio 2010 разработчики могут ориентироваться на различные версии .NET Framework в одной и той же среде разработки. Можно создавать приложения для .NET Framework 2.0, 3.0, 3.5или 4.0, то есть поддерживать множество проектов в одной среде.

Вместе VisualStudio и .NET Framework снижают надобность в написании общего связующего кода, сокращая время разработки и позволяя сосредоточить усилия на решении бизнес-задач.

Visual C#

Язык C# [9] - это простой, но в то же время мощный, строго типизированный и объектно-ориентированный язык, позволяющий программистам создавать разнообразные приложения. Вкупе с платформой .NET Framework, Visual C# позволяет создавать приложения Windows, веб-службы, средства баз данных, компоненты, элементы управления и многое другое.

Причины возникновения языка C#:

- Изначальная ориентация на платформу .NET;

- Максимальная степень скрытия деталей от разработчика (упаковка/распаковка типов, инициализация, сборка мусора и т.п.);

- Мощность C++ и простота VisualBasic;

- Новый язык, не связанный проблемами обратной совместимости;

- Идеальный язык для быстрой разработки приложений (RAD).

Главной особенностью языка C# является его ориентированность на платформу .NET Framework[12]- создатели C# ставили своей целью предоставление разработчикам естественных средств доступа ко всем возможностям платформы .NET. Видимо, это решение можно считать более или менее вынужденным, так как платформа .NET изначально предлагала значительно большую функциональность, чем любой из существовавших на тот момент языков программирования.

Кроме того, создатели С# хотели скрыть от разработчика как можно больше незначительных технических деталей, включая операции по упаковке/распаковке типов, инициализации переменных и сборке мусора. Благодаря этому программист, пишущий на C#, может лучше сконцентрироваться на содержательной части задачи. В процессе решения этой задачи проектировщики C# пытались учесть уроки реализации VisualBasic'а, который достаточно успешен в скрытии деталей реализации, но недостаточно эффективен для написания крупных промышленных систем: создатели C# декларируют, что новый язык обладает мощностью С++ и в то же время простотой VisualBasic'а.

Таким образом, C# представляет собой новый язык программирования, ориентированный на разработку для платформы .NET и пригодный как для быстрого прототипирования приложений, так и для разработки крупномасштабных приложений.

2.3 Диаграммы поведения

Диаграмма последовательности

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

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

Диаграмма последовательности ведения справочника физических эффектов приведена на рисунке 2.1.

Основными объектами на этой диаграмме выступают:

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

Класс Главная форма приложения - главная форма приложения.

Класс Форма выбора справочников - форма, позволяющая администратору выбрать справочник.

Класс Окно детализации - окно позволяющее работать с записями.

Менеджер СУБД - формирует запросы к БД.

Рисунок 2.2 - Диаграмма последовательности

Диаграмма кооперации

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

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

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

Диаграмма кооперации «Подбор идеи использования» представлена на рисунке 2.3.

Рисунок 2.3 - Диаграмма кооперации

2.4 Разработка физической модели базы данных

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

Для разработки проекта выберем систему управления базами данных Microsoft Access 2007.

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

Схема данных представлена на рисунке 2.4.

Рисунок 2.4 - Схема данных

2.5 Разработка программного обеспечения

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

Система состоит из двух модулей:

1. Клиентское приложение

2. Приложение администратора

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

Рассмотрим описание всех классов и методов модуля администратора (таблица 2.1).

Таблица 2.1 - Описание классов администратора

Название класса

Название параметра класса

Описание

FormMain

(главная форма модуля администратора)

BindingNavigatorSaveItem_Click(object sender, EventArgs e)

Сохранение и редактирование таблиц

Проверка имени и пароля

Form1_Load(object sender, EventArgs e)

Загрузка данных таблиц

FormMain_DockChanged(object sender, EventArgs e)

Изменение и обновление таблиц

Описание всех классов и методов клиентского модуля (таблица2.2 )

Таблица 2.2 - Описание классов клиента

Название класса

Название параметра класса

Описание

Form1: Form

(Главная форма клиента)

BindingNavigatorSaveItem_Click(object sender, EventArgs e)

Инициализация, сохранение и редактирование таблиц

Form1_Load(object sender, EventArgs e)

Загрузка данных таблиц

button1_Click(object sender, EventArgs e)

button2_Click(object sender, EventArgs e)

Формирует выборку патентов по заданным критериям

button3_Click(object sender, EventArgs e)

Построение таблицы с критериями

dataGridView1_CellContentClick(object sender, DataGridViewCellEventArgs e)

button4_Click(object sender, EventArgs e)

Производит расчет эффективности идей

2.6 Диаграмма компонентов и развертывания

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

Диаграмма компонентов системы представлена на рисунке 2.5.

Диаграмма развёртывания служит для моделирования работающих узлов (аппаратных средств) и артефактов, развёрнутых на них. В UML 2.0 на узлах разворачиваются артефакты, в то время как в UML 1.x на узлах разворачивались компоненты.

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

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

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

2.7 Описание интерфейсных решений

Интерфейс пользователя (user interface) -- разновидность интерфейсов, в котором одна сторона представлена пользователем, другая -- компьютером. Это совокупность методов и средств, которые позволяют пользователю взаимодействовать с элементами и системами устройства [].

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

Разработанная программа имеет простой и интуитивно понятный интерфейс.

После запуска программы появляется главное окно приложения с формой авторизации (рисунок 2.6).

Рисунок 2.6 - Главное окно программы с формой авторизации

После ввода данных и нажав на кнопку «Вход», пользователь перемещается на главную форму приложения, которая представлена на рисунке 2.7.

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

Администратор БД работает в форме, представленной на рисунке 2.8.

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

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

Рисунок 2.8 - Форма администратора БД

2.8 Разработка программы и методики испытания

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

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

Целью проведения испытаний является проверка работоспособности системы.

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

- методика проведения испытания документации;

- методика тестирования информационной системы.

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

Проверка считается завершенной в случае соответствия состава и комплексности программной документации, представленной исполнителем АИС, перечню программной документации, приведенному в методических указаниях по дипломному проектированию.

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

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

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

Проверка считается завершенной в случае соответствия состава и комплексности технических и программных средств, представленных исполнителем АИС, с перечнем технических и программных средств, заявленных в Приложении к заданию на дипломный проект.

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

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

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

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

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

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

В случае успешного проведения испытаний в полном объеме исполнитель АИС передает представителю кафедры программное изделие, программную документацию и т.д.

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

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

Мелкие, несущественные недоработки могут быть устранены в рабочем порядке.

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

Информационная система должна удовлетворять следующим функциональным требованиям:

1. Авторизация пользователя.

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

3. Ведение справочника патентов.

4. Ведение справочника физических эффектов.

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

6. Ведение справочника видов энергии.

7. Ведение справочника идей использования.

8. Подбор патентов по параметрам.

9. Расчет эффективности идей использования.

Методы испытаний

1. Проверка интерфейса Пользователя.

Тест 1.1: Авторизация в системе с правами пользователя.

Выполнение: Запускаем программу. В поле «Пользователь» вводится значение «user», в поле «Пароль» значение «123». Нажимаем кнопку «Вход».

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

Тест 1.2: Подбор патентов по параметрам.

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

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

Тест 1.3: Расчет эффективности идей использования.

Выполнение: считаем, что база данных заполнена, и пользователь подобрал необходимые патенты (п.1.2). В окне ввода критериев вводим название, важность и направление. Например, введем два критерия: «оригинальность» и «экономичность». Из выпадающего списка выберем важность и зададим направление. Для первого критерия выберем важность «2» с направлением «макс», а для второго важность «4» с направлением «мин». После чего нажимаем кнопку «Задать».

Реакция системы: система сформирует таблицу с выбранными идеями и введенными нами критериями.

Выполнение: вводим в таблицу оценки по критериям и нажимаем на кнопку «Рассчитать эффективность».

Реакция системы: система выдает результат расчета эффективности идей.

2.Проверка интерфейса Администратора.

Тест 2.1: Авторизация с правами администратора.


Подобные документы

  • Выбор средств разработки. Написание сценариев PHP. Разработка базы данных MySQL. Описания организации иерархической многопользовательской модульной структуры сайта с возможностью управления содержанием. Создание средств для удаленного администрирования.

    практическая работа [4,8 M], добавлен 12.06.2013

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

    курсовая работа [297,3 K], добавлен 25.11.2010

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

    дипломная работа [3,2 M], добавлен 19.02.2013

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

    курсовая работа [1,3 M], добавлен 21.09.2015

  • Описание разрабатываемой программы с точки зрения пользователя и программиста. Поэтапная разработка программной системы. Создание базы данных в Access. Разработка структуры классов. Создание структуры для хранения данных. Проектирование интерфейса.

    курсовая работа [1,4 M], добавлен 07.08.2013

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

    курсовая работа [3,0 M], добавлен 22.12.2014

  • Создание диаграммы варианта использования для информационной системы. Моделирование взаимодействия объектов во времени в языке UML. Главная особенность диаграммы кооперации. Физическое представление программной системы, семантическая связь между классами.

    курсовая работа [3,9 M], добавлен 09.01.2014

  • Исследование основных требований к системе управления взаимоотношениями с клиентами. Разработка логической структуры базы данных. Хранимые процедуры и триггеры. Особенности их использования. Настройка репликации в СУБД Postgres. Настройка сервера LDAP.

    курсовая работа [926,8 K], добавлен 26.01.2013

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

    курсовая работа [1,6 M], добавлен 22.12.2014

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

    курсовая работа [1,4 M], добавлен 22.05.2015

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.