Отчет о научно-исследовательской и опытно-конструкторской работе (стр. 15 )

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Oracle Database – 10.2.0.4, Oracle WebLogic Server 11gR1 (10.3.2) на HP ProLiant DL380 G5 2xXeon 3 GHz (2x2 Core)/ 8Gb RAM/ 2x72 Gb HDD (RAID1); IntelliJ IDEA платформы J2EE, с применением основных библиотек:

Hibernate;

Spring Framwork;

Apache Commons;

Wicket;

log4j;

POI.

Реализация и тестирование

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

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

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

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

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

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

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

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

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

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

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

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

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

Итерационность процессов наложила специфические особенности и на процесс тестирования.

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

Основные принципы организации тестирования, использованные при выполнении работы: