Материал: Разработка программного комплекса для анализа состояния системы хранения данных EMC Centera

package client.controller;class TaskController implements ConnectionUpdateHandler {CachedTaskRepository taskCache;TaskMonitor taskMonitor;TaskUpdater taskUpdater;TaskController()TaskFactory getTaskFactory()Task getTask(int id)void registerTaskUpdateHandler(int id, TaskUpdateHandler handler)void unregisterTaskUpdateHandler(int id, TaskUpdateHandler handler)

@Overridevoid handle(ConnectionContext context)

}

Интерфейс фабрики задач. Создаёт весь поддерживаемый спектр задач для выполнения на серверном компоненте.

package client.controller;interface TaskFactory {SearchInLogTask createSearchInLogTask(Date from, Date to, Set<String> nodes, Set<String> logTypes, boolean isPatternRegExp, String pattern);CustomLoggingTask createCustomLoggingTask(Date startDate, Set<String> nodes, Log.Level level, Set<String> loggers, Collection<Log.Filter> filters);TcpDumpingTask createTcpDumpingTask(Date startDate, Set<String> nodes, Nic nic, String filter);AbortTask createAbortTask(int abortedTaskId);QueryDataTask createQueryDataTask (Set<String> nodes, Set<String> dataTypes, boolean queryForeignSessions);DownloadTask createDownloadTask(Map<String, Collection<String>> paths);SmartPacketDecodeTask createSmartPacketDecodeTask(String encodedPacketContent);StopServerTask createStopServerTask();

}

Реализация фабрики задач.client.controller;class TaskFactoryImpl implements TaskFactory {

...

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

package client.controller;class CachedTaskRepository implements TaskRepository {CachedTaskRepository(TaskRepository taskRepository)

...

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

package client.controller;class TaskMonitor implements Runnable {TaskUpdater taskUpdater;

@Overridevoid run()void checkTasksStates()

}

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

package client.controller;class TaskUpdater {Map<Integer, TaskUpdateHandler> handlers;void update(Task task)void compareAndNotify(Task previous, Task actual)void registerTaskUpdateHandler(int id, TaskUpdateHandler handler)void unregisterTaskUpdateHandler(int id, TaskUpdateHandler handler)

}

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

package client.controller;interface TaskUpdateHandler {enum UpdateType { State, Result };

void handle(UpdateType type, Task task);

}

.4 Реализация слоя «Вид» клиентского компонента

Слой «Вид» реализован с помощью классов библиотеки Java Swing, в качестве дополнения к ней использована компонент библиотеки дизайна графического интерфейса JGoodies - модуль, отвечающий за организацию взаимного размещения компонентов окна.

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

Окно «Main window»

Основное окно является подписчиком на обновления о состоянии соединения с серверным компонентои и отображает текущий статус в строке состояния внизу окна. Вид окна представлен на рис. 4.1.

Рисунок 4.1 Вид окна «Main window»

Окно «Choose connection» приведено на рис. 4.2, для манипуляций с параметрами соединения использует соответствующий класс из слоя «Модель»

Окно «Edit cluster connection» приведено на рис. 4.3

Окно «Enter password» приведено на рис. 4.4

Окно «Exit» приведено на рис. 4.5

 Рисунок 4.2 Вид окна «Choose connection»

Рисунок 4.3 Вид окна «Edit cluster connection»

 Рисунок 4.4 Вид окна «Enter password»

Окно «Sessions» приведено на рис. 4.6, информация о сессиях запрашивается у клиентской библиотеки.

Рисунок 4.6 Вид окна «Sessions»

Окно «Search in logs» приведено на рис. 4.7.

Рисунок 4.7 Вид окна «Search in logs»

Окно «Select nodes» приведено на рис. 4.8

Рисунок 4.8 Вид окна «Select nodes»

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

Рисунок 4.9 Вид окна «Log»

Окно «Custom logging» приведено на рис. 4.10

Рисунок 4.10 Вид окна «Custom logging»

Окно «Create new custom log» приведено на рис. 4.11

Рисунок 4.11 Вид окна «Create new custom log»

Окно «TCP dumping» приведено на рис. 4.12

Рисунок 4.12 Вид окна «TCP dumping»

Окно «Create new TCP dump» приведено на рис. 4.13

Рисунок 4.13 Вид окна «Create new TCP dump»

Окно «Download» приведено на рис. 4.14, в списке «Existing data» отображается результат выполнения задачи поиска файлов с заданными параметрами.

Рисунок 4.14 Вид окна «Download»

Окно «Download progress» приведено на рис. 4.15, окно является подписчиком на обновления задачи копирования файлов.

Рисунок 4.15 Вид окна «Download progress»

Окно «Base64 encode/decode» приведено на рис. 4.16

Рисунок 4.16 Вид окна «Base64 encode/decode»

Окно «SmartPacket decode» приведено на рис. 4.17

Рисунок 4.17 Вид окна «SmartPacket decode»

Окно «ZLIB compress/decompress» приведено на рис. 4.18

Рисунок 4.18 Вид окна «ZLIB compress/decompress»

5. ТЕСТИРОВАНИЕ ПРОГРАММНОГО КОМПЛЕКСА

.1 Выбор методик тестирования

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

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

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

.2 Компонентное тестирование

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

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

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

Серверный компонент - 90%

Слой «Модель» клиентского компонента - 90%

Слой «Контроллер» клиентского компонента - 75%

Слой «Вид» клиентского компонента (классы, не реализующие оконные элекменты) - 50%

Общий модуль клиентского и серверного компонентов - 90%

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

При реализации серверного компонента и общего модуля протокола использовалась методика «Разработка через тестирование» (Test-driven development) [10], когда изначально для класса пишется набор тестов, описывающих все варианты исходных данных, которые могут возникать в процессе работы класса, а также конечные результаты; затем пишется минимальная реализация класса, обеспечивающая стопроцентное прохождение теста. В результате такого подхода к реализации в исходном коде практически нет неиспользуемых фрагментов кода, которые только занимают системные ресурсы и никоим образом не влияют на результат работы программы.

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

Для анализа покрытия исходного кода тестами использовался модуль для ИСР Eclipse под названием EclEmma версии 1.5.3 [12].

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

Компонентные тесты выполняются в объёме 100%

Анализ степени покрытия по указанным структурным единицам программного комплекса: серверный компонент - 93%; слой «Модель» клиентского компонента - 84%; слой «Контроллер» клиентского компонента - 77%; слой «Вид» клиентского компонента (классы, не реализующие оконные элекменты) - 67%; общий модуль клиентского и серверного компонентов - 92%.

.3 Системное тестирование

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

5.4 Анализ результатов тестирования

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

ЗАКЛЮЧЕНИЕ

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

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

Анализ выборки в результате дал базис требований и ограничений, используя который можно создать программное средство, автоматизирующее данные сервисные действия, направленные на анализ состояния СХД Cenetera. Учитывая параметры распределённости анализируемых исходных данных, а также свойства соединения с СХД Centera, было рекомендовано использование клиент-серверной архитектуры для реализации описанного программного средства в виде программного комплекса.

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

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

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

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

EMC Corporation, «Demo: Centera complete» (на английском языке), <http://www.emc.com/collateral/demos/microsites/hardware/centera-complete/index.htm>, 2008

EMC Corporation. «Security in EMC CentraStar 4.1 A Detailed Review» (на английском языке), <http://russia.emc.com/collateral/hardware/white-papers/h4495-security-emc-centrastar-wp.pdf>, 2009Jacobson, Craig Leres and Steven McCanne. «Manual page. PCAP-FILTER(7)» (на английском языке), <http://www.unix.com/man-page/FreeBSD/7/pcap-filter/>, 2008.

Internet Engineering Task Force (IETF), Network Working Group. «Request for Comments 4648: The Base16, Base32, and Base64 Data Encodings» (на английском языке), <http://tools.ietf.org/html/rfc4648>, 2006Engineering Task Force (IETF), Network Working Group. «Request for Comments 1950: ZLIB Compressed Data Format Specification version 3.3» (на английском языке), <http://tools.ietf.org/html/rfc1950>, 1996Engineering Task Force (IETF), Network Working Group. «Request for Comments 4250:The Secure Shell (SSH) Protocol Assigned Numbers» (на английском языке), <http://tools.ietf.org/html/rfc4250>, 2006Wide Web Consortium (W3C). «Extensible Markup Language (XML)» (на английском языке), <http://www.w3.org/XML/>, 2011. «Java Platform, Standard Edition 6. API Specification. Package org.w3c.dom» (на английском языке), <http://download.oracle.com/javase/6/docs/api/org/w3c/dom/package-summary.html>, 2011

«Junit. Getting started» (на английском языке), <http://junit.sourceforge.net/>, 2011Koskela. «Test Driven: TDD and Acceptance TDD for Java Developers» (на английском языке), Manning Publications, 2007Freese, Henri Tremblay. «EasyMock 3.0 Readme» (на английском языке), <http://easymock.org/EasyMock3_0_Documentation.html>, 2010GmbH & Co. KG. «Java Code Coverage for Eclipse. User Guide» (на английском языке) <http://www.eclemma.org/userdoc/index.html>, 2011

Oracle. «Lesson:Using Swing components» (на английском языке), <http://download.oracle.com/javase/tutorial/uiswing/components/index.html>, 2010Gosling, Bill Joy, Guy Steele, Gilad Bracha «The Java Language Specification» (на английском языке), третье издание, Addison Wesley, 2005

ПРИЛОЖЕНИЕ 1