Программный комплекс оптимизации направлений прогрессивного развития объектов

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

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

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

ФГБОУ ВПО Самарский государственный архитектурно-строительный университет

Факультет информационных систем и технологий

Кафедра прикладной математики и вычислительной техники

Программный комплекс оптимизации направлений прогрессивного развития объектов

РУКОВОДИТЕЛЬ РАЗРАБОТКИ:

Ст. пр.кафедры ПМиВТ Агафонова Н.С.

РАЗРАБОТЧИК: студент группы ГИП-110 Рыжков Д.А.

Самара 2015 г.

А.1 ОБЩИЕ СВЕДЕНИЯ О ПРОГРАММЕ

А1.1 Область применения

Разработанный программный комплекс оптимизации направлений прогрессивного развития объектов «ОНПРО» позволяет рассчитывать вектора прогрессивности для любых объектов с любыми критериями. Данные добавляются посредством «парсинга» excel файла определенного формата. Расчёты сохраняются в БД, что позволяет просматривать раннее решённые задачи.

А1.2 Краткое описание возможностей

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

А.2 СТРУКТУРА ПРОГРАММЫ

Структура программы состоит из нескольких модулей:

1. ParetoResolver - класс для расчёта Парето оптимальности объектов;

2. AlternativeController - класс, обрабатывающий запросы к альтернативам;

3. CriteriaController - класс, обрабатывающий запросы к критериям;

4. HibernateUtils - класс-хелпер, для работы с фреймворком Hibernate;

5. TaskController - класс, для работы с задачами;

6. Alternative - DAO класс альтернатив;

7. Criteria - DAO класс критериев;

8. Task - DAO класс задач;

9. ExcelParser - класс, для парсинга excel файла;

10. ProgressiveResolver - класс для нахождения векторов прогрессивности;

Для полного функционирования ПК также требуются сторонние библиотеки:

- Spring MVC 4.0;

- Apache POI 3.7;

- Framework Hibernate 3.6;

- Spring Security 3.2;

А.3 НАСТРОЙКА ПРОГРАММЫ

Программный комплекс предоставляется на компакт-диске или на электронном носителе. Для функционирования необходимо установить на персональный компьютер СУБД Microsoft Access не раньше 2003 версии. В качестве операционной системы необходима ОС семейства Windows (XP/Vista/Seven).

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

Так же рекомендуется использовать IDE Intellij Idea 14.1.

А.4 ПРОВЕРКА РАБОТОСПОСОБНОСТИ ПРОГРАМЫ

A4.1 Порядок проверки работоспособности

1. Запустить сервер приложений Tomcat;

2. Собрать проект с помощью IDE Intellij Idea;

3. Открыть браузер (рекомендуется использовать Google Chrome) и перейти по адресу http://localhost:8080/

4. Появится главное меню ПК

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

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

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

В рамках методов шкалирования и одноступенчатых методов каждому объекту в каждой зоне его использования по нескольким (не более 5-7) экспертно выбираемым критериям дается порядковая (ранговая) или балльная оценка. Далее методами Парето (оптимизации и суммарной балльной оценки) производится комплексная оценка объектов.

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

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

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

Значительные исследования в области поддержки принятия решений принадлежат:

Проф., д.т.н. О. И. Ларичев [1], [3-4], [7], Мошкович Е.М. [3],[7], академик РАН Емельянов СВ.[4], д.т.н. Петровский А. Б., к.ф.-м.н. Дмитриади Г. Г.[5], Кочин Д. Ю., к.т.н. Асанов А. А.[6], д.т.н. Пиявский С.А.[7]

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

1.2 Основные цели

Целью создания программного комплекса является помощь ЛПР в определении оптимального вектора прогрессивности для объекта.

Для наглядного представления общих и частных целей создания программного комплекса составим дерево целей, которое представляет собой структурированный иерархический перечень целей, в котором цели низкого уровня подчинены и служат для достижения целей более высокого уровня (Рисунок 1.1), а также измеряемы параметры достижения цели (Таблица 1.1), дерево задач (Рисунок 1.2) и функций (Рисунок 1.3)

Рисунок 1.1 - Дерево целей

Таблица 2.1 - Измеряемые параметры для дерева целей ПК «ОНПРО»

ЦЕЛЬ	ПАРАМЕТРЫ
Повышение качества принятия решения за счет поддержки ЛПР	1) % решенных задач, в которых ЛПР с учетом рекомендаций программного комплекса изменил первоначально предлагавшиеся решение (0-100%) 2) % решенных задач, в которых ЛПР по рекомендациям программного комплекса изменил первоначальную постановку задачи или внес дополнительную информацию (0-100%)
Оперативный ввод и изменение данных в системе	Возможность вводить данные представителями(Экспертная оценка по пятибалльной шкале)
Эргономичность и удобство работы с «ОНПРО»	Оценивается ЛПР в шкале от 1 до 5 после процедуры принятия решений

Рисунок 1.2 - Дерево задач ПК «ОНПРО»

Рисунок 1.3 - Дерево функций ПК «ОНПРО»

1.3 Модель анализа UML

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

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

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

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

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

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

1.3.2 Сценарии вариантов использования.

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

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

Актант: Аналитик.

Предусловия. Выполнен вариант использования «Авторизация в системе» в режиме Аналитик. На экране - главная форма приложения.

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

Аналитик щёлкает левой кнопкой мыши по пункту меню «Ввод и редактирование задачи»

Система выводит на экран форму «Новая задача» с полями «Название задачи», «Альтернативы», «Критерии»

Аналитик заполняет поля «Название задачи», «Альтернативы», «Критерии» соответствующими данными и нажимает кнопку «Далее».

Система проверяет правильность введенных данных и добавляет запись в БД. Система формирует и выводит на экран форму ввода оценок введенных альтернатив по критериям с таблицей и кнопками «Далее» и «Назад».

А1: Не заполнены поля или заполнены неправильно, и нажата кнопка «Далее».

Аналитик заполняет таблицу оценками и нажимает кнопку «Далее».

А2: Нажата кнопка «Назад».

А3: Не заполнены поля или заполнены неправильно, и нажата кнопка «Далее».

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

Аналитик выбирает альтернативу и нажимает кнопку “Рассчитать вектор прогрессивности”.

А4: Нажата кнопка «Назад».

Система производит расчет и выводит форму с результатом расчета (вектор) и кнопкой «ОК».

Аналитик просматривает результаты расчета и нажимает кнопку «ОК».

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

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

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

А1: Не заполнены поля или заполнены неправильно, и нажата кнопка «Далее».

А1.1: Аналитик заполняет поля неверными данными, или оставляет их пустыми, после чего нажимает кнопку «Далее».

А1.2: Система выдает сообщение об ошибке ввода с кнопкой «Ок».

А1.3: Аналитик просматривает сообщение и нажимает кнопку «Ок».

А1.4: Система закрывает сообщение и устанавливает курсор в первое неправильно заполненное поле.

А1.5: Выполняется п.2 основной последовательности.

А2: Нажата кнопка «Назад».

А2.1: Аналитик нажимает кнопку «Назад».

А2.2: Система закрывает форму ввода оценок альтернатив и выводит форму аналитика.

А2.3: Выполняется п.3 основной последовательности.

А3: Не заполнены поля или заполнены неправильно, и нажата кнопка «Далее».

А3.1: Аналитик заполняет поля неверными данными, или оставляет их пустыми, после чего нажимает кнопку «Далее».

А3.2: Система выдает сообщение об ошибке ввода с кнопкой «Ок».

А3.3: Аналитик просматривает сообщение и нажимает кнопку «Ок».

А3.4: Система закрывает сообщение и устанавливает курсор в первое неправильно заполненное поле.

А3.5: Выполняется п.3 основной последовательности.

А4: Нажата кнопка «Назад».

А4.1: Аналитик нажимает кнопку «Назад».

А4.2: Система закрывает форму оптимизации вектора прогрессивности и выводит форму ввода оценок альтернатив.

А4.3: Выполняется п.4 основной последовательности.

Вариант использования: Формирование отчёта о результате оптимизации.

Краткое описание: Позволяет аналитику сформировать отчёт по результатам оптимизаций (альтернативы, критерии и оценки альтернатив по критериям).

Актант: Аналитик.

Предусловия. Выполнен вариант использования «Авторизация в системе» в режиме Аналитик. На экране - главная форма приложения.

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

Аналитик щёлкает левой кнопкой мыши по пункту меню «Сформировать отчёт»

Система выводит на экран форму «Отчёт» с полями «Дата начала оптимизации», «Дата окончания оптимизации».

Аналитик заполняет поля «Дата начала оптимизации», «Дата окончания оптимизации», соответствующими данными и нажимает кнопку «Сформировать отчёт».

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

А1: Не заполнены поля или заполнены неправильно, и нажата кнопка «Далее».

Аналитик просматривает отчёт и нажимает кнопку «Закрыть отчёт».

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

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

А1: Не заполнены поля или заполнены неправильно, и нажата кнопка «Далее».

А1.1: Аналитик заполняет поля неверными данными, или оставляет их пустыми, после чего нажимает кнопку «Далее».

А1.2: Система выдает сообщение об ошибке ввода с кнопкой «Ок».

А1.3: Аналитик просматривает сообщение и нажимает кнопку «Ок».

А1.4: Система закрывает сообщение и устанавливает курсор в первое неправильно заполненное поле.

А1.5: Выполняется п.3 основной последовательности.

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

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

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

На Рисунке 4 видно, что в системе реализовано 5 классов: Аналитик, Задача, Альтернатива, Критерий, Решение. Класс Аналитик имеет атрибуты: id_аналитика - уникальный цифровой идентификатор, и атрибут фамилия - текстовый идентификатор пользователя.

Класс Задача также имеет уникальный идентификатор - id_задачи и название - текстовое содержание для идентификации задачи. Между ними существует связь 1-*, это означает что один Аналитик имеет доступ к целому ряду задач. Задача в свою очередь имеет тоже много решений, что показано связями 1-*.

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

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

Сущности в диаграмме соответствуют основным интерфейсам программного комплекса

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

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

Вкладка с решением задачи - позволяет аналитику просмотреть результаты расчётов.

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

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

Класс «Менеджер приложений» - отражает основные функции для организации работы приложения и клиент-серверного взаимодействия.

Класс «Менеджер СУБД» - представляет собой функции для обработки запросов к базам данных.

Класс «Менеджер печати» - представляет собой функции для организации печати данных.

Класс «Браузер» - предоставляет функции для реализации графического представления и клиент-серверного взаимодействия.

1.3.6 Схема сложного алгоритма

Логику работы модуля оптимизации объектов составляют 2 основные подпрограммы для расчета оптимизированного вектора прогрессивности. Основные подпрограммы модуля расчета вектора:

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

Рисунок 7 - блок-схема алгоритма расчета оптимизированного вектора прогрессивности.

Расчёт оптимизированного вектора прогрессивности для выбранной альтернативы x - рассчитывает оптимизированный вектор прогрессивности, основываясь на Парето-оптимальные альтернативы.

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

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

ER - модель данных соответствует диаграмме сущностных классов. Назначение всех сущностей описано в разделе диаграммы сущностных классов.

программный оптимизация прогрессивность критерий

Рисунок 7 - ER модель базы данных.

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

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

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

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

Выбор архитектуры производился из трёх основных типов:

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

- клиент-серверная трехзвенная (частный случай multi-tier) - этот тип характеризуется наличием трех звеньев приложения: клиентских станций, сервера приложений и сервера базы данных;

- локальная - при использовании этой архитектуры все компоненты системы находятся на одном компьютере. [6]

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

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

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

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

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

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

3) поддерживать модульность и структурность программы.

К этой группе относится огромное количество языков, например Fortran, Algol, PL/1, Cobol, C, Pascal.

Другой подход, появившийся в 80-ых годах, называется объектно-ориентированным. Основной структурной единицей при таком подходе является объект (агрегат из данных и функций, работающих с этими данными). Примеры таких языков - Delphi, C++, Java, Ada, Simula и другие.

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

Язык программирования Java[8]

Java -- объектно-ориентированный язык программирования, разрабатываемый компанией Sun Microsystems с 1991 года и официально выпущенный 23 мая 1995 года. Изначально новый язык программирования назывался Oak (James Gosling) и разрабатывался для бытовой электроники, но впоследствии был переименован в Java и стал использоваться для написания апплетов, приложений и серверного программного обеспечения.

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

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

Язык Java потребовался для создания интерактивных продуктов для сети Internet. Фактически, большинство архитектурных решений, принятых при создании Java, было продиктовано желанием предоставить синтаксис, сходный с C и C++. В Java используются практически идентичные соглашения для объявления переменных, передачи параметров, операторов и для управления потоком выполнением кода. В Java добавлены все хорошие черты C++.

Три ключевых элемента объединились в технологии языка Java

Java предоставляет для широкого использования свои апплеты (applets) -- небольшие, надежные, динамичные, не зависящие от платформы активные сетевые приложения, встраиваемые в страницы Web. Апплеты Java могут настраиваться и распространяться потребителям с такой же легкостью, как любые документы HTML

Java высвобождает мощь объектно-ориентированной разработки приложений, сочетая простой и знакомый синтаксис с надежной и удобной в работе средой разработки. Это позволяет широкому кругу программистов быстро создавать новые программы и новые апплеты

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

СУБД

Microsoft Office Access или просто Microsoft Access -- реляционная СУБД корпорации Microsoft. Имеет широкий спектр функций, включая связанные запросы, связь с внешними таблицами и базами данных.

Встроенные средства взаимодействия MS Access со внешними СУБД с использованием интерфейса ODBC снимают ограничения, присущие Microsoft Jet Database Engine. Инструменты MS Access, которые позволяют реализовать такое взаимодействие, называются «связанные таблицы» (связь с таблицей СУБД) и «запросы к серверу» (запрос на диалекте SQL, который «понимает» СУБД).

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

Корпорация Microsoft распространяет полнофункциональную версию Access как отдельно, так и совместно с другими приложениями (Word, Excel и др.) в составе пакетов Microsoft Office Professional, Microsoft Office Professional Plus и Microsoft Office Enterprise. [9]

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

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

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

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

Вторым измерением диаграммы последовательности является вертикальная временная ось, направленная сверху вниз. Начальному моменту времени соответствует самая верхняя часть диаграммы. Взаимодействия объектов реализуются посредством сообщений, которые посылаются одними объектами другим. Сообщения изображаются в виде горизонтальных стрелок с именем сообщения, а их порядок определяется временем возникновения. То есть, сообщения, расположенные на диаграмме последовательности выше, инициируются раньше тех, которые расположены ниже. Масштаб на оси времени не указывается, поскольку диаграмма последовательности моделирует лишь временную упорядоченность взаимодействий типа «раньше-позже». [5]

Диаграмма последовательности для ПК оптимизации направлений прогрессивного развития объектов приведена на рисунке 2.1.

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

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

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

1. Все простые сущности превращаются в отношения, имя сущности становится именем отношением;

2. Каждый атрибут становится возможным столбцом с тем же именем. Столбцы, соответствующие необязательным атрибутам, могут содержать NULL - значения;

3. Компоненты уникального идентификатора сущности превращаются в первичный ключ отношения;

4. Связи «многие к одному» становятся внешними ключами;

5. В таблицах, построенных на основе ассоциаций, внешние ключи

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



Рисунок 4.1 - Диаграмма последовательности добавления новой задачи.

6. Разрешение проблемы наличия подтипов;

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

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

Таблица 2.1 - Соответствие имен на физическом и логическом уровнях

На физическом уровне	На логическом уровне	Поле	Тип данных
Alternatives	Альтернативы	ID	Integer
		Name	String
		TaskId	Integer
Criterias	Критерии	ID	Integer
		Name	String
		Value	Double
		AlterId	Integer
Tasks	Задачи	ID	String
		UserId	Integer
		Name	Integer
Users	Пользователи	ID	Integer
		UserName	String
		Login	String
		Password	String
		Role	String

Рисунок 2.2 - Физическая модель базы данных

2.4 Расчет комплекса технических средств

2.4.1 Расчет необходимого объема внешней памяти

Для расчета внешней памяти воспользуемся формулой (2.1):

, Мбайт (2.1)

- общий объём внешней памяти;

- объём внешней памяти, требуемый для хранения файлов операционной системы и её нормальной работы;

- объём внешней памяти, требуемый для хранения файлов СУБД;

- объём внешней памяти, требуемый для хранения записей БД и результатов выполнения функций;

- объём внешней памяти, необходимый для хранения информации.

Система работает под управлением операционной системы Windows 7 (x32) с использованием Access.

= 16 000 Мбайт; = 10 Мбайт.

Срок хранения информации составляет пять лет, рассчитаем необходимое количество внешней памяти.

Данные расчетов сведены в таблицу 2.2.

Таблица 2.2 - Расчет объёма данных

Таблица БД	Размер записи, байт	Max количество записей	Размер индекса, байт	Итого, байт
Alternatives	420	10 000	101	4 200 101
Criterias	510	50	65	25 065
Tasks	350	20	65	7 500
Users	150	10 000	14	1 500 014
Итого:	18 207 704

= 18,21 Мбайт;

= 1 000 Мбайт;

Сложив данные, получим:

= 16 000+10+18,21+1 000= 17 028.21 Мбайт.

Таким образом, для сервера нам потребуется жесткий диск объемом 18 Гб.

2.4.2 Расчет необходимого объема оперативной памяти

Формула, используемая для расчета требуемой оперативной памяти, аналогична формуле (2.1). Результаты расчета объема кэша для хранения данных в оперативной памяти приведены в таблице 2.3.

Таблица 2.3 - Расчет объема буферизации

Таблица БД	Размер записи, байт	Max количество записей	Размер индекса, байт	Итого, байт
Alternatives	420	10 000	101	4 200 101
Criterias	510	50	65	25 065
Tasks	350	20	65	7 500
Users	150	1	14	1 500 014
Итого:	18 207 398

= 50 Мбайт.

= 18,21 Мбайт;

= 256+10+50+18.21=334.21 Мбайт.

Поскольку оперативная память комплектуется модулями стандартного размера от 128 Мбайт до 4 Гбайт, мы выбираем один модуль на 512 Мбайт для сервера.

Расчеты характеристик для клиента:

= 0 Мбайт;

= 18,21Мбайт;

= 256+10+0+18,21=284.21 Мбайт.

Поскольку оперативная память комплектуется модулями стандартного размера от 128 Мбайт до 4 Гбайт, мы выбираем один модуль на 512 Мбайт для клиента.

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

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

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

(2.2)

,

,

,

,

.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Параметр	Значение
Vтабл=	2048
Nбл=	1600
tввода= (секунд)	5
tсчитыв= (секунд)	5,7
tвычисл= (секунд)	0,002667
tреакции=(секунд)	10,7

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

2.4.4 Скорость передачи данных

7п= Vд / Vпр,

где 7п - скорость передачи данных;

Vд - объем данных;

Vпр - пропускная способность;

Vпр = 56 Кбит/с (как наихудшее соединение);

Vд = 30 символов*2 бита=60бит = 0,06 Кбит;

7п = 0,06 Кбит / 56 Кбит/с = 0,001071 c.

0,001071 c. - скорость передачи данных при наихудшем соединении.

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

Сервер:

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

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

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

Клиент:

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

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

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

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

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

Проектирование интерфейсов - задача, основанная на требованиях к читаемости и эргономичности проекта.

Проектирование интерфейсов --задача, требующая декомпозиции ее на этапы:

1. Исследование;

2. Моделирование пользователей;

3. Выработка требований;

4. Детализация требований,

5. Разработка интерфейсов.

В этом разделе приведены основные интерфейсы ПК ОНПРО, отображенные в браузере Google Chrome

Интерфейсы ПК ОНПРО можно поделить на функциональные группы

1. Задачи - интерфейсы этой группы отражают список всех задач.

Рисунок 2.3 - Задачи.

2. Альтернативы - интерфейсы предназначены для ввода, редактирования и расчета вектора прогрессивности.

Рисунок 2.4 - Альтернативы.

Структура программы состоит из нескольких модулей:

11. ParetoResolver - класс для расчёта Парето оптимальности объектов;

12. AlternativeController - класс, обрабатывающий запросы к альтернативам;

13. CriteriaController - класс, обрабатывающий запросы к критериям;

14. HibernateUtils - класс-хелпер, для работы с фреймворком Hibernate;

15. TaskController - класс, для работы с задачами;

16. Alternative - DAO класс альтернатив;

17. Criteria - DAO класс критериев;

18. Task - DAO класс задач;

19. ExcelParser - класс, для парсинга excel файла;

20. ProgressiveResolver - класс для нахождения векторов прогрессивности;

Для полного функционирования ПК также требуются сторонние библиотеки:

- Spring MVC 4.0;

- Apache POI 3.7;

- Framework Hibernate 3.6;

- Spring Security 3.2;

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

Полный проект программной системы представляет собой совокупность моделей логического и физического уровней, которые должны быть согласованы между собой. В языке UML для физического представления моделей систем используются диаграммы реализации (implementation diagrams), которые включают в себя диаграмму компонентов и диаграмму развертывания.

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

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

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

2. спецификации исполняемого варианта программной системы;

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

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

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

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

В диаграмме компонентов ПК ОНПРО отражены все конечные компоненты, которые составляют программный комплекс:

1. исполняемые файлы (*.java) - скрипты, предназначенные для формирования динамического контента и расчета значений, исполняемый файл сервера приложений;

2. JSP-страницы (*.jsp) - формы для представления данных;

3. Таблица стилей CSS (bootstrap.css) - визуальное оформление форм,

Так как в диаграмме не отражены другие компоненты, стереотипы в диаграмме решили не указывать. Однако при представлении компонентной модели программного комплекса следует учитывать, что для нормального функционирования приложений требуются некоторые другие компоненты, такие как динамические библиотеки, файлы конфигураций и пр. [5] Полный состав компонентов определяется в процессе реализации ПК ОНПРО. Ниже приведена диаграмма компонентов комплекса.



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

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

Диаграмма развёртывания, Deployment diagram в UML моделирует физическое развертывание артефактов на узлах. Узлы представляются как прямоугольные параллелепипеды с артефактами, расположенными в них, изображенными в виде прямоугольников. Узлы могут иметь подузлы, которые представляются как вложенные прямоугольные параллелепипеды. Один узел диаграммы развертывания может концептуально представлять множество физических узлов, таких как кластер серверов баз данных.

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

В ПК ОНПРО существует два основных типов узлов:

1. Web - сервер (одно устройство на комплекс),

2. Клиентские станции (неограниченное число).

Узлы содержат компоненты, приведённые на диаграмме компонентов. Важно понимать, что ПК - WEB-приложение, и, следовательно, клиентские станции на самом деле не содержат компонентов, относящихся к комплексу (исключения составляют лишь данные пользовательского рейтинга). Для доступа к ПК клиентская станция должна иметь WEB-браузер, который должен запрашивать компоненты у сервера приложений Tomcat, находящегося на WEB-сервере по протоколу HTTP. Диаграмма развертывания ПК отражена на рисунке 2.6.

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

2.8 Контрольный пример

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

Объект испытаний - ПК оптимизации направлений прогрессивного развития объектов, а именно - сервер приложений Tomcat, приложения ПК, клиентские компоненты (см рисунок 2.6).

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

Цель испытаний - проверка функционирования ПК:

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

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

- Проверка применения изменений базы данных.

- Проверка счета рейтинга объектов.

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

1. Требования к структуре и функционированию.

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

- HTTP-сервер с возможностью аутентификации

- Программный комплекс с возможностью расчета на стороне сервера.

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

2. К назначению.

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

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

3. К защищености.

- Защита информации от несанкционированного доступа заключается в запрете изменений БД неавторизованными пользователями. Авторизация пользователей должна проходить по Basic- либо Digest- методам стандарта HTTP.

- БД не должна быть интернет-общедоступна.

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

Документация ПК:

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

- Руководство оператора;

- Руководство программиста.

Состав и порядок испытаний

Технические средства, необходимые для испытаний, должны удовлетворять системным требованиям, приведённым в пункте 2.4.5 данной пояснительной записки. Между клиентскими станциями и сервером должно быть установлено функциональное соединение TCP/IP.

Программные средства, необходимые для испытаний:

Для сервера

- ОС - Windows 7x32 или Windows 7x64,

- СУБД - MS Access 2003 или старше.

Для клиента:

- Современный интернет - браузер (рекомендуется Google Chrome).

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

1. Проверка структуры и функционирования.

1.1 Установить сервер приложений Tomcat и компоненты ПК ОНПРО.

1.2 Запустить сервер приложений (Подробнее см. руководство программиста).

1.3 Перейти на главную страницу проекта (Подробнее см. руководство оператора).

1.4 Пересчитать вектор прогрессивности для любого объекта (Подробнее см. руководство оператора).

Успешное выполнение всех пунктов означат корректное взаимодействие основных модулей системы.

2. Проверка назначения системы.

2.1 Перейти на главную страницу ПК ОНПРО

2.2 Проверить соответствие страницы рисунку 2.3:

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

2.3 Проверить работоспособность меню навигации: ссылки должны быть нажимаемы

2.4 Перейти в пункт «Редактировать альтернативу»

2.5 Изменить состояние формы, пользуясь руководством оператора

2.6 Обновить страницу - состояние формы должно сохранится

2.7 Перейти в пункт «Новая задача»

2.8 Выбрать новую задачу и добавить данные, пользуясь руководством оператора

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

Контрольный пример ПК ОНПРО объектов приведен в приложении А

2.9 Разработка руководств оператора и программиста

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

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

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

3. ТЕХНИКО-ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ ПРОГРАММНОГО КОМПЛЕКСА (БИЗНЕС - ПЛАН)

3.1 Резюме

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

3.2 Средства для осуществления проекта

Для разработки программного комплекса потребуется новейшее оборудование и технологии. Для обеспечения материально-технической базы и зарплаты сотрудникам, нам потребуется 90 тысяч рублей. Эту сумму берем под 42% в Самарском отделении № 6991 ОАО «Сбербанк России» в кредит. Это необходимо для покрытия общих операционных расходов, непредвиденных издержек и начальной зарплаты. Штат сотрудников состоит из 3 высококвалифицированных дипломированных специалистов.

3.2.1 Описание вида деятельности

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

До начала выполняемых работ необходимо выяснить:

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

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

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

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

3.2.2 Описание программного продукта

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

- высокое качество;

- безопасность;

- удобный дружелюбный интерфейс программного комплекса;

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

- соответствие стандартам;

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

3.3 Конкуренция

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

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

- качество разработки;

- низкий уровень цен;

- современный дизайн;

- исключительность товара;

- послепродажное обслуживание;

3.4 Маркетинг

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

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

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

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

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

3.5 Анализ рисков

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

- недостаточная информация о спросе на данный товар;

- недостаточный анализ рынка;

- недооценка своих конкурентов;

- падение спроса на данный товар;

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

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

3.6 Финансовый план

3.6.1 Расчет затрат на разработку программного комплекса

Затраты на разработку ПК (К_п) определяются по формуле:

К_п = К_пр + К_по + К_ио + К_о (3.1)

где К_пр - затраты на проектирование ПК, р.;

К_по - затраты на создание программных изделий, образующих программное обеспечение ПК, р.;

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

К_о - затраты на отладку ПК, р.

Укрупненный расчет затрат на разработку ИС можно выполнить по формуле:

К_п = Ф_з/п [(1+_д)(1+_с)+_н+_пр]+t_ЭВМ С_м-ч, (3.2)

где Ф_з/п - фонд основной заработной платы разработчиков и других исполнителей работ, р.;

_д - коэффициент дополнительной зарплаты, 0,10...0,15;

_с - коэффициент отчислений на социальные нужды от основной и дополнительной заработной платы, 0,26;

_н - коэффициент накладных расходов организации, разрабатывающей проект, 0,6...0,8;

_пр - коэффициент прочих расходов, 0,1...0,2;

t_ЭВМ - машинное время, затраченное для разработки программного обеспечения ПК, ч.;

С_м-ч - стоимость машино-часа работы ЭВМ, р.

Укрупненный расчет фонда основной заработной платы исполнителей работ по разработке ПК производится по формуле:

Ф_з/п = , (3.3)

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

С - тарифная ставка часовая (дневная) разработчиков и других исполнителей работ, р.

С = (З/пл в месяц) / D_раб = 15000/21 = 715 р.

Ф_з/п = 35 Ч1428 = 25 000 р.

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

Время, затраченное на отладку программного обеспечения на компьютере tэвм, устанавливается экспертным путем или по фактическим затратам машинного времени. Себестоимость машино-часа работы компьютера определяется по формуле:

С_м-ч = , (3.4)

где З_п - затраты на заработную плату обслуживающего персонала с учетом всех отчислений, р.;

А - годовая сумма амортизации, р.;

З_э - затраты на силовую электроэнергию, р.;

З_р - затраты на ремонт, обслуживание оборудования в год, р.;

З_м - затраты на материалы в год, р.;

З_н - накладные расходы, р.;

Ф_д - действительный годовой фонд времени работы комплекса средств автоматизации (КСА), ч.

Годовые амортизационные отчисления по КСА считаются по формуле:

, (3.5)

где С_КСА - стоимость компьютера и прочего оборудования, входящего в КСА, используемого при отладке ПК 22 000 р.

Н_а - норма амортизации, (25%).

А = (22 000Ч25)/100 = 5 500 р.;

Затраты на электроэнергию в год З_э определяются следующим образом:

З_э = W_уЧC_эЧT_в, (3.6)

где W_у - установленная мощность, кВт;

С_э - стоимость силовой электроэнергии, 1,3 р / кВт;

...