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

Для поиска оптимального развития научных способностей использую метод квантов необходимо задать коэффициенты Д_min, отражающей минимальное гарантированное время, выделяемое для каждой функции, и K, отражающее количество свободных единиц, затрачиваемое на функции. Основываясь на этих коэффициентах, метод будет задавать каждому коэффициенту ??, отражающей долю времени которое личность тратит на изучение той или иной функции исследовательской деятельности, значение равное значению Д_min. Затем метод будет перебирать все возможные комбинации оптимизируемых функций. Дальше модуль будет подбирать количество квант на каждую выбранную функцию. Сумма квант на выбранных функциях не должно превышать значение K. Найдя свободное пространство, где модуль задаст каждой выбранной функции значение, рассчитанное по формуле:

. (10)

Тогда .

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

Пример распределения времени при оптимальной стратегии личности, найденной при помощи метода квантов при T = 3, где T - время моделирования (семестры) и K = 2 представлен на рисунке 1.

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

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

Рисунок 1 - Пример поиска оптимальной стратегии формирования исследовательских способностей с использованием метода квантов

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

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

3. РЕАЛИЗАЦИЯ МОДЕЛИ

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

Диаграмма прецедентов (диаграмма деятельностей, диаграмма вариантов использования) в UML -- диаграмма, отражающая отношения между актёрами и прецедентами и являющаяся составной частью модели прецедентов, позволяющей описать систему на концептуальном уровне.

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

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

При моделировании системы с помощью диаграммы прецедентов системный аналитик стремится:

- чётко отделить систему от её окружения;

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

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

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

Для отражения модели прецедентов на диаграмме используются [32]:

1) рамки системы (англ. system boundary) -- прямоугольник с названием в верхней части и эллипсами (прецедентами) внутри. Часто может быть опущен без потери полезной информации;

2) актёр (англ. actor) -- стилизованный человечек, обозначающий набор ролей пользователя (понимается в широком смысле: человек, внешняя сущность, класс, другая система), взаимодействующего с некоторой сущностью (системой, подсистемой, классом). Актёры не могут быть связаны друг с другом (за исключением отношений обобщения/наследования);

3) прецедент -- эллипс с надписью, обозначающий выполняемые системой действия (могут включать возможные варианты), приводящие к наблюдаемым актёрами результатам. Надпись может быть именем или описанием (с точки зрения актёров) того, «что» делает система (а не «как»). Имя прецедента связано с непрерываемым (атомарным) сценарием -- конкретной последовательностью действий, иллюстрирующей поведение. В ходе сценария актёры обмениваются с системой сообщениями. Сценарий может быть приведён на диаграмме прецедентов в виде UML-комментария. С одним прецедентом может быть связано несколько различных сценариев.

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

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

3.2 Сценарий основного варианта использования

Сценарий использования, вариант использования, прецедент использования (англ. Use Case) -- в разработке программного обеспечения и системном проектировании это описание поведения системы, когда она взаимодействует с кем-то (или чем-то) из внешней среды. Система может отвечать на внешние запросы Актора (англ. Actor)(может применяться термин Актант), может сама выступать инициатором взаимодействия. Другими словами, сценарий использования описывает, «кто» и «что» может сделать с рассматриваемой системой, или что система может сделать с «кем» или «чем». Методика сценариев использования применяется для выявления требований к поведению системы, известных также как функциональные требования.

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

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

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

Диаграмма классов (англ. Static Structure diagram) -- диаграмма, демонстрирующая классы системы, их атрибуты, методы и взаимосвязи между ними.

Существует два вида:

1. Статический вид диаграммы рассматривает логические взаимосвязи классов между собой.

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

Существуют разные точки зрения на построение диаграмм классов в зависимости от целей их применения [34]:

1) Концептуальная точка зрения -- диаграмма классов описывает модель предметной области, в ней присутствуют только классы прикладных объектов;

2) Точка зрения спецификации -- диаграмма классов применяется при проектировании информационных систем;

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

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

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

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

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

3.4 Схема алгоритма

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

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

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

- ГОСТ 19.701-90. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения. Для программной документации (устарели, заменяются ГОСТ 19.701-90):

- ГОСТ 19.002-80. Схемы алгоритмов и программ. Правила выполнения.

- ГОСТ 19.003-80. Схемы алгоритмов и программ. Обозначения условные графические.

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

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

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

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

Постоянные данные в среде базы данных включают в себя схему и базу данных. Система управления базами данных (далее - СУБД) использует определения данных в схеме для обеспечения доступа и управления доступом к данным в базе данных.

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

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

Основными объектами графического представления схемы являются таблицы и связи, определяемые внешними ключами [36].

Уровни схемы базы данных:

- Концептуальная схема -- карта концепций и их связей.

- Логическая схема -- карта сущностей и их атрибутов и связей.

- Физическая схема -- частичная реализация логической схемы.

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

Рисунок 5 - Логическая схема базы данных

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

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

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

o бизнес-требования;

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

o функциональные требования.

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

- бизнес-правила -- определяют ограничения, проистекающие из предметной области и свойств автоматизируемого объекта (предприятия);

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

o ограничения на программные интерфейсы, в том числе к внешним системам;

o требования к атрибутам качества;

o требования к применяемому оборудованию и ПО.

- требования к документированию;

- требования к дизайну и удобности интерфейсов;

- требования к безопасности и надёжности;

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

o требования к эксплуатации и персоналу;

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

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

Трехуровневая архитектура (трёхзвенная архитектура, англ. three-tier) -- архитектурная модель программного комплекса, предполагающая наличие в нём трёх компонентов:

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

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

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

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

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

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

Рисунок 6 - Схема трехзвенной архитектуры

3.7 Требования к программному обеспечению

Здесь формируются требования к разрабатываемой информационной системе.

Информационная система должна:

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

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

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

- допускать гибкую настройку параметров, характеризующих образовательную среду в моделируемой сфере науки и техники;

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

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

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

- вести учет пользователей системы;

- иметь возможность наделять пользователей сооьветствующими правами;

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

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

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

- бизнес-требования;

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

- функциональные требования.

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

- бизнес-правила -- определяют ограничения, проистекающие из предметной области и свойств автоматизируемого объекта (предприятия);

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

- ограничения на программные интерфейсы, в том числе к внешним системам;

- требования к атрибутам качества;

- требования к применяемому оборудованию и ПО.

- требования к документированию;

- требования к дизайну и удобности интерфейсов;

- требования к безопасности и надёжности;

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

- требования к эксплуатации и персоналу;

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

3.8 Описание структуры программного обеспечения

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

MVC (Model-view-controller, «модель-представление-контроллер», «модель-вид-контроллер») -- схема использования нескольких шаблонов проектирования, с помощью которых модель приложения, пользовательский интерфейс и взаимодействие с пользователем разделены на три отдельных компонента таким образом, чтобы модификация одного из компонентов оказывала минимальное воздействие на остальные. Данная схема проектирования часто используется для построения архитектурного каркаса, когда переходят от теории к реализации в конкретной предметной области.

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

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

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

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

Концепция MVC позволяет разделить данные, представление и обработку действий пользователя на три отдельных компонента:

- Модель (англ. Model). Модель предоставляет знания: данные и методы работы с этими данными, реагирует на запросы, изменяя своё состояние. Не содержит информации, как эти знания можно визуализировать.

- Представление, вид (англ. View). Отвечает за отображение информации (визуализацию). Часто в качестве представления выступает форма (окно) с графическими элементами.

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

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

Для реализации схемы Model-View-Controller используется достаточно большое число шаблонов проектирования (в зависимости от сложности архитектурного решения), основные из которых «наблюдатель», «стратегия», «компоновщик».

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

Общая схема MVC представлена на рисунке 7.

Рисунок 7 - Общая схема MVC

3.9 Описание используемых классов и методов

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

Таблица 4 - Основные используемые классы

Листинг класса MainController приведен в приложении В.

В качестве языка программирования был выбран язык программирования Java.

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

К современным базам данных, а следовательно, и к СУБД, на которых они строятся, предъявляются следующие основные требования:

1. Высокое быстродействие (малое время отклика на запрос).

2. Время отклика - промежуток времени от момента запроса к БД до фактического получения данных.

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

4. Простота обновления данных.

5. Независимость данных.

6. Совместное использование данных многими пользователями.

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

8. Стандартизация построения и эксплуатации БД (фактически СУБД).

9. Адекватность отображения данных соответствующей предметной области.

10. Дружелюбный интерфейс пользователя.

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

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

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

Безопасность данных включает их целостность и защиту.

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

Она предполагает:

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

- защиту от ошибок при обновлении БД;

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

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

- сохранность данных при сбоях техники (восстановление данных).

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

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

- получением разрешений от администратора базы данных (АБД);

- запретом от АБД на доступ к данным;

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

Три последние процедуры легко выполняются в рамках языка структуризованных запросов Structured Query Language - SQL, часто называемого SQL2.

Стандартизация обеспечивает преемственность поколений СУБД, упрощает взаимодействие БД одного поколения СУБД с одинаковыми и различными моделями данных. Стандартизация (ANSI/SPARC) осуществлена в значительной степени в части интерфейса пользователя СУБД и языка SQL. Это позволило успешно решить задачу взаимодействия различных реляционных СУБД как с помощью языка SQL, так и с применением приложения ODBC. При этом может быть осуществлен как локальный, так и удаленный доступ к данным (технология клиент/сервер или сетевой вариант) [40].

Исходя из предъявленных выше требований к СУБД, в качестве основной СУБД при реализации информацонной системы была выбрана СУБД PostgreSQL.

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

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

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

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

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

Рисунок 9 - Диаграмма состояний

3.12 Диаграмма активности

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

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

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

Рисунок 10 - Диаграмма деятельности

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

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

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

На данной диаграмме объекты располагаются слева направо [43].

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

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

3.14 Диаграмма коммуникации

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

В UML есть четыре типа диаграмм взаимодействия:

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

- Диаграмма коммуникации.

- Диаграмма обзора взаимодействия.

- Диаграмма синхронизации.

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

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

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

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

Рисунок 12 - Диаграмма коммуникации

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

В данном разделе приводятся исходные данные, использованные при проектировании технического обеспечения ИС [45].

Формула расчета требуемых ресурсов внешней памяти:

где:

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

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

V_данных - объем хранимых данных,

V_{программы} - объем внешней памяти разрабатываемой информационной системы.

Ниже перечислены минимальные данные для расчета внешней памяти:

V_ОС = 5 Гб;

V_СУБД =128 Мб;

V_данных = 512 Мб;

V_{программы} = 128 Мб.

Получается, что для успешного функционирования информационной системы требуется минимум 6 Гб свободной внешней памяти.

Формула расчета требуемых ресурсов оперативной памяти:

Ниже перечислены минимальные данные для расчета оперативной памяти:

V_ОС = 512 Мб;

V_СУБД =512 Мб;

V_данных = 512 Мб;

V_{программы} = 128 Мб.

Получается, что для успешного функционирования информационной системы требуется минимум 2 Гб свободной оперативной памяти.

Формула расчета времени реакции системы

где:

k_вв - коэффициент ошибок (от 1.1 до 2.0, в среднем 1.5);

L_симв - количество символов при вводе;

t_симв - время ввода символа (при ручном вводе в среднем 2 с);

;

V_табл - средний объём таблицы, Кбайт;

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

V_блока - объём физического блока носителя (кластера),

Время позиционирования головок дискового накопителя t_поз, в среднем 0.006 с.

Время считывания физического блока t_сч.бл , в среднем 0.001 с.

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

N_{опер.ц.i} - то же внутри i-го цикла;

p_imax - максимальное число итераций i-го цикла;

k₁ - количество тактов машинных команд на 1 операцию, в среднем k₁ = 80;

f - тактовая частота процессора, Гц.

Для струйного принтера среднее время печати одной страницы формата А4 0.4 мин. t_{вывода(экран)} в среднем 0.5 с.

Ниже перечислены результаты расчета времени реакции системы:

t_ввода = 60 с;

N_ввода = 4000;

t_{считывания} = 28 с;

t_{вычислений} = 3 с.

Итого t_{реакции} = 1,5 мин.

В состав комплекса технических средств входят следующие технические средства:

- Серверы БД;

- Серверы приложений;

- Веб сервер.

Таким образом, минимальные рекомендуемые технические характеристики серверов БД:

- Процессор - не менее двух процессоров Intel Xeon 3 ГГц;

- Объем оперативной памяти - не менее 2 Гб;

- Дисковая подсистема - не менее 6 Гб;

- Устройство чтения компакт-дисков (DVD-ROM);

- Сетевой адаптер - FastEthernet 100;

- Адаптер Fibre Channel;

- Видеосистема - разрешающая способность не ниже 1024x860 точек;

- Координатно-указательное устройство - манипулятор типа «мышь»;

- Клавиатура - не менее 104 клавиш (русифицированная);

- Монитор - диагональ не менее 15.

Минимальные рекомендуемые технические характеристики системы хранения данных:

- Процессор - не менее двух процессоров Intel Xeon 3 ГГц;

- Объем оперативной памяти - не менее 2 Гб;

- Дисковая подсистема - не менее 6 Гб;

- Устройство чтения компакт-дисков (DVD-ROM);

- Сетевой адаптер - FastEthernet 100;

- Адаптер Fibre Channel;

- Видеосистема - разрешающая способность не ниже 1024x860 точек;

- Координатно-указательное устройство - манипулятор типа «мышь»;

- Клавиатура - не менее 104 клавиш (русифицированная);

- Монитор - диагональ не менее 15.

Минимальные рекомендуемые технические характеристики сервера приложений:

- Процессор - не менее двух процессоров Intel Xeon 3 ГГц;

- Объем оперативной памяти - не менее 2 Гб;

- Дисковая подсистема - не менее 6 Гб;

- Устройство чтения компакт-дисков (DVD-ROM);

- Сетевой адаптер - FastEthernet 100;

- Адаптер Fibre Channel;

- Видеосистема - разрешающая способность не ниже 1024x860 точек;

- Координатно-указательное устройство - манипулятор типа «мышь»;

- Клавиатура - не менее 104 клавиш (русифицированная);

- Монитор - диагональ не менее 15.

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

В качестве основных интерфейсных решений в разрабатываемой информационной системы легла библиотека Twitter Bootstrap 3-ий версии и ее форки: bootstrap-select и bootstrap-toggle.

Twitter Bootstrap -- свободный набор инструментов для создания сайтов и веб-приложений. Включает в себя HTML и CSS шаблоны оформления для типографики, веб-форм, кнопок, меток, блоков навигации и прочих компонентов веб-интерфейсов, включая JavaScript расширения.

Bootstrap использует самые современные наработки в области CSS и HTML, поэтому необходимо быть внимательным при поддержке старых браузеров [46].

Основные преимущества Twitter Bootstrap 3:

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

- Высокая скорость -- динамичные макеты Bootstrap масштабируются на разные устройства и разрешения экрана без каких-либо изменений в разметке;

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

- Простота в использовании -- платформа проста в использовании, пользователь с базовыми знаниями HTML и CSS может начать разработку с Twitter Bootstrap;

- Совместимость с браузерами -- Twitter Bootstrap совместим с Mozilla Firefox, Yandex Browser, Google Chrome, Safari, Internet Explorer и Opera;

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

Основные инструменты Bootstrap:

- Сетки -- заранее заданные размеры колонок, которые можно сразу же использовать, например ширина колонки 140px относится к классу .span2 (.col-md-2 в третьей версии фреймворка), который можно использовать в CSS описании документа.

- Шаблоны -- Фиксированный или резиновый шаблон документа.

- Типографика -- Описания шрифтов, определение некоторых классов для шрифтов, таких как код, цитаты и т. п.

- Медиа -- Представляет некоторое управление изображениями и Видео.

- Таблицы -- Средства оформления таблиц, вплоть до добавления функциональности сортировки.

- Формы -- Классы для оформления форм и некоторых событий происходящих с ними.

- Навигация -- Классы оформления для Табов, Вкладок, Страничности, Меню и Тулбара.

- Алерты -- Оформление диалоговых окон, Подсказок и Всплывающих окон.

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

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

Чарты работают со всеми популярными браузерами, включая Safari на iPhone.

Минимальная версия для IE составляет 6+. Также браузеры поддерживающие Canvas элемент, и в некоторых случаях SVG для графического рендеринга

Пример графика построенного с помощью библиотеки Highcharts представлен на рисунке 13.

Рисунок 13 - Пример графика Highcharts

Скриншот главного экрана информационной системы представлен на рисунке 14.

jQuery -- библиотека JavaScript, фокусирующаяся на взаимодействии JavaScript и HTML. Библиотека jQuery помогает легко получать доступ к любому элементу DOM, обращаться к атрибутам и содержимому элементов DOM, манипулировать ими. Также библиотека jQuery предоставляет удобный API для работы с AJAX. Сейчас разработка jQuery ведётся командой jQuery во главе с Джоном Резигом [49-51].

Рисунок 14 - Главный экран информационной системы

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

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

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

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

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

Делегация показывается связь внешнего контракта компонента с внутренней реализацией этого поведения внутренними компонентами.[52].

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

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

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

Диаграмма развёртывания (Deployment diagram) в UML моделирует физическое развертывание артефактов на узлах. Например, чтобы описать веб-сайт диаграмма развертывания должна показывать, какие аппаратные компоненты («узлы») существуют (например, веб-сервер, сервер базы данных, сервер приложения), какие программные компоненты («артефакты») работают на каждом узле (например, веб-приложение, база данных), и как различные части этого комплекса соединяются друг с другом (например, JDBC, REST, RMI).

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

Существует два типа узлов:

1. Узел устройства.

2. Узел среды выполнения.

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

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

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

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

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

Целью проведения испытаний является:

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

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

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

- проверка готовности Системы к проведению опытной эксплуатации.

В испытаниях принимают участие: Зав. Кафедрой и Пользователь.

До начала данных испытаний тестирования или испытания информационной системы не проводились.

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

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

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

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

Цель контрольного примера: проверить работоспособность всей информационной системы.

Испытание №1.

Цель испытания: проверить работоспособность системы управления пользователями.

Описание испытания: На странице «Авторизация» в поля «Логин» и «Пароль» ввести неправильный логин или пароль.

Ожидание: На странице «Авторизация» появится сообщение «Неверный логин или пароль».

Результат испытания: На странице «Авторизация» появилось сообщение «Неверный логин или пароль». Испытание пройдено успешно.

Испытание №2.

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

Описание испытания: На странице «Страница моделирования» заполнить поля для ввода:

- начальные значения мотивации;

- значение «a0»;

- значение «M max»;

- значение «h»;

- значение «T»;

- Альфа (всего 9 значений);

- Бетта (всего 9 значений);

- Тетта (всего 9 значений);

- Начальные значения (всего 9 значений);

- Весовые коэффициенты (всего 9 значений).

Нажать на кнопку «Рассчитать».

Ожидание: Система произведет моделирования за интервал T, с шагом h и выведет результаты в поля для вывода:

- конечные значения (всего 9 значений);

- конечные значения мотивации;

- начальный комплексный рейтинг;

- конечный комплексный рейтинг.

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

Результат испытания: Результаты получены, графики построены. Испытание пройдено успешно.

3.21 Руководство пользователя

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

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

Типичное руководство пользователя содержит:

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

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

- Страницу содержания;

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

- Глава, описывающая возможные проблемы и пути их решения

- Часто задаваемые вопросы и ответы на них;

- Где ещё найти информацию по предмету, контактная информация

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

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