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

Модуль очереди запросов ставит задачу в очередь модуля очереди задач и переходит к следующей итерации

Модуль очереди задач работает циклически, где каждая итерация выглядит следующим образом:

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

Модуль очереди задач запускает выполнение задачи

Задача выполняется, периодически производя сериализацию своего содержимого, используя полученный маршаллер и интерфейс модуля ФС (для получения нового временного потока вывода, который после закрытия будет преобразован в готовый файл со статусом задачи)

После завершения выполнения задачи управление передаётся модулю очереди задач, который добавляет задачу в список выполненных задач

Модуль очереди задач анализирует список выполненных задач и выбирает те, у результатов которых истёк срок хранения и удаляет их из своего списка

Модуль очереди задач передаёт список задач с истёкшим сроком хранения модулю ФС, который их удаляет из директории результатов

Модуль очереди задач переходит к следующей итерации

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

Рисунок 3.5 Схема структуры серверного компонента

3.4 Реализация серверного компонента

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

Интегрированная среда разработки Eclipse (версия Helios Service Release 2), как отвечающая всем требованиям по разработке программного продукта на языке Java Standard Edition, имеющая множество вспомогательных средств для обеспечения удобного процесса разработки;

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

Рабочие станции программиста, имеющие характеристики не ниже следующего уровня: процессор частотой 2ГГц, объём оперативной памяти 1Гб, объём доступного дискового пространства 1Гб, размер дисплея 17 дюймов, разрешение экрана 1024*768 пикселей;

Операционная система Windows XP SP2 или SP3.

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

Модуль контроллера представлен следующими классами:

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

package server.controller

public class ServerController extends ModulesController {

public static void main(String[] args)

@Override

protected void initModules() throws ModuleException {

private void obtainServerLock() throws ModuleException

}

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

package common.controller;

public abstract class ModulesController {

private List<Module> modules = new ArrayList<Module>();

protected void execute()

protected abstract void initModules() throws ModuleException

protected boolean add(Module module)

private void startModules() throws ModuleException

private void waitForStop()

public void stop()

private void stopModules() throws ModuleException

}

Интерфейс модуля, регистрируемого в контроллере и управляемого им.

package common.controller;

public interface Module {

public void start() throws ModuleException

public void stop() throws ModuleException

}

Класс исключений, специфицирующий ошибки, произошедшие в коде контроллера.

package common.controller;

public class ModuleException extends Exception {

public ModuleException(String message)

}

Модуль серверной библиотеки представлен следующими классами:

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

package server.library;

public interface ServerLibrary {

public void initNodes();

public NodeEnvironment getNodeEnvironment(String nodeName);

public boolean decodeSmartPacket(byte[] content);

}

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

package server.library;

public interface NodeEnvironment {

public boolean searchInLogs(Date from, Date to, Collection<LogType> logTypes, String pattern, boolean isRegExp);

public boolean startCustomLog(String logName, LogLevel level, Collection<String> loggers, Collection<LogFilter> filters);

public boolean stopCustomLog(String logName);

public boolean startTcpDumping(String nic, String filters);

public boolean stopTcpDumping();

public boolean queryFiles(Collection<DataType> dataTypes, boolean allSessions);

public boolean downloadFiles(Collection<String> paths);

}

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

package server.modules;

public class ServerLibraryModule implements Module {

@Override

public void start() throws ModuleException

@Override

public void stop() throws ModuleException

public ServerLibrary getLibrary()

}

Модуль ФС представлен следующими классом:

Класс модуля управления файловой система - преимущественно методы по чтению задачи или её записиа.

package server.modules;

public class FilesystemModule implements Module {

@Override

public void start() throws ModuleException

@Override

public void stop() throws ModuleException

public Collection<String> getRequestsList()

public InputStream getRequestStream(String request)

public void removeRequest(String request)

public void persistTask(Task task) throws IOException

public void removeExpiredTasks(Collection<String> expiredTasks) throws IOException

}

Модуль очереди запросов представлен следующими классами:

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

package server.modules;

public class RequestProcessingModule implements Module, Runnable {

private FilesystemModule filesystemModule;

private JobProcessingModule jobProcessingModule;

private Thread queueProcessingThread;

private Map<String, TaskFactory> factories = new HashMap<String, TaskFactory>();

public RequestProcessingModule(FilesystemModule filesystemModule, JobProcessingModule jobProcessingModule)

@Override

public void start() throws ModuleException

@Override

public void stop() throws ModuleException

public void registerTaskFactory(String type, TaskFactory factory)

public void unregisterTaskFactory(String type, TaskFactory factory)

@Override

public void run()

}

Модуль очереди задач представлен следующими классами:

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

package server.modules;

public class JobProcessingModule implements Module, Runnable {

private FilesystemModule filesystemModule;

private Thread jobsProcessor;

private Queue<Task> jobs = new ConcurrentLinkedQueue<Task>();

public JobProcessingModule(FilesystemModule filesystemModule) {

@Override

public void start() throws ModuleException {

@Override

public void stop() throws ModuleException {

public void createJob(Task request) {

@Override

public void run() {

}

Модуль фабрик задач представлен следующими классами:

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

package server.modules;

public class FactoriesModule implements Module {

private ServerController serverController;

private ServerLibraryModule serverLibraryModule;

private FilesystemModule filesystemModule;

private RequestProcessingModule requestProcessingModule;

private Map<String, TaskFactory> factories;

public FactoriesModule(ServerController serverController, ServerLibraryModule serverLibraryModule, FilesystemModule filesystemModule, RequestProcessingModule requestProcessingModule)

@Override

public void start() throws ModuleException

private void initializeFactories()

@Override

public void stop() throws ModuleException

}

4. РАЗРАБОТКА КЛИЕНТСКОГО КОМПОНЕНТА ПРОГРАММНОГО КОМПЛЕКСА С ГРАФИЧЕСКИМ ИНТЕРФЕЙСОМ ПОЛЬЗОВАТЕЛЯ

4.1 Разработка структуры клиентского компонента

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

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

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

Слой «Модель»

Слой состоит из следующих основных модулей: модуль хранилища настроек, модуль контекста соединения с СХД Centera, модуль контекста клиент-серверной сессии. Кроме того в слое используетя общий для серверного и клиентского компонентов модуль протокола.

Модуль хранилища настроек

Выполняет функции сериализации/десериализации настроек клиентского модуля в/из файлов, находящихся в «рабочей» директории клиентского компонента. «Рабочей» называется директория, в которой находится исполняемый файл клиентской программы. Настройки легко отображаются на документ формата XML, при маршаллинге настроек используется DOM-реализация XML-документа, поставляемая вместе с пакетом Java Runtime Environment 6.0 [8].

Модуль контекста соединения с СХД Centera

Модуль представлен набором сущностей, хранящих в себе свойства соединения с кластером. В частности сущность контекста соединения содержит в себе сущность параметров текущего соединения (адрес узла СХД, название соединения, используемая при установлении соединения учётная запись), пароль для установления соединения, состояние соединения (установлено, не установлено, прервано), версию ПО СХД Centera, контекст текущей клиент-серверной сессии, список узлов СХД Centera c указанием их ролей).

Модуль контекста клиент-серверной сессии

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

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

Общий модуль протокола

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

Общий модуль типовых задач

Часть модуля протокола - содержит реализацию для всех поддерживаемых типов задач.

Слой «Контроллер»

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

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

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

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

Модуль контроллера соединения

Состоит из следующих сущностей:

контроллер соединения - предоставляет интерфейс для создания и завершения соединения, отслеживания его состояния (через подписку на уведомления об изменении состояния), получения его параметров (сущность контекст соединения); предоставляет соединение для посылки через него задач серверному компоненту и получения результатов выполнения задачи; использует клиентскую библиотеку для работы с узлом кластера; контролирует работу монитора соединения; отдельно стоящей задачей контроллера является загрузка серверного компонента на узел СХД Centera, если на узле он отсутствует или копия имеет устаревшую версию;

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

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

Модуль контроллера задач

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

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

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

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

монитор состояния задач - отслеживает изменение состояния задач в очереди задач серверного компонента (см. п. 3.3 пп 3), при обнаружении изменения нотифицирует сущность актуализатора задач об изменении состояния задачи;

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

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

Слой «Вид»

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

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

4.2 Реализация слоя «Модель» клиентского компонента

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

Модуль хранилища настроек представлен следующими классами:

Класс предоставляет статические методы для получения настроек в виде обёртки над XML-документом, а также для сохранения этих настроек в хранилище. Каждый экземпляр документа с настройками доступен по своему имени (файла).

package client.model;

public class RepositoryUtils {

private final static String REPOSITORY_PATH_ENVIRONMENT_VARIABLE = "sustaining.suite.repository.path";

private static final String REPOSITORY_SUFFIX = ".repository.xml";

private static final String REPOSITORY_TAG = "repository";

private static String sRepositoryDirectoryPath;

private static Map<String, Params> sRepositories = new HashMap<String, Params>();

public synchronized static String getRepositoryDirectoryPath()

public static Params getRepository(String repositoryName)

private static Params loadRepositoryFromFile(String repositoryName)

public static void persistRepository(String repositoryName, Params newRepositoryContent)

}

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

package client.model;

public class ClientContext {

private static final String CONNECTIONS_REPOSITORY = "clusters.connections";

private static final String CONNECTION_TAG = "connection";

private static final String CONNECTION_NAME = "name";

private static final String CONNECTION_ADDRESS = "address";

private static final String CONNECTION_LOGIN = "login";

private static Map<String, ConnectionParams> connectionsParams = null;

public static Map<String, ConnectionParams> getConnectionsParams()

public static boolean updateConnectionsParams(ConnectionParams existingConnectionParams, ConnectionParams newConnectionParams) throws ClientContextException

private static void persistConnectionsParams()

}

Исключение специфичного типа, предназначенное для обозначения ошибки при работе с контекстом клиентского компонента.

package client.model;

public class ClientContextException extends Exception {

public ClientContextException(String message)

}

Модуль контекста соединения с СХД Centera представлен следующими классами:

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

package client.model;

public class ConnectionContext {

public enum State {

Disconnected(false),

Connected(true),

Aborted(false);

private final boolean isConnected;

private State(boolean isConnected)

public boolean isConnected()

};

private ConnectionParams connectionParams;

private String password;

private State state;

private String centrastarVersion;

private SessionContext sessionContext;

private Collection<Node> nodes;

...

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

package client.model;

public class ConnectionParams {

private String connectionName;

private String address;

private String login;

public ConnectionParams(String connectionName, String clusterAddress, String login)

public String getConnectionName()

public String getAddress()

public String getLogin()

@Override

public String toString()

}

Модуль контекста клиент-серверной сессии представлен следующими классами:

Класс хранилища сессий, предоставляет интерфейс для создания новой сессии.

package client.model;

public class SessionsRepository {

public static SessionContext createSession()

}

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

package client.model;

public class SessionContext {

private Object sessionLock;

private int sessionId;

private int creationTimestamp;

private int lastUpdateTimestamp;

private long size;

private Map<Integer, Task> tasks;

...

Интерфейс хранилища задач. Предоставляет базовые методы для работы с задачами.

package client.model;

public interface TaskRepository {

public int createTask(Task task);

public Task getTask(int id);

public void removeTask(int id);

}

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

package client.model;

public class PersistedTaskRepository implements TaskRepository {

public PersistedTaskRepository(File directory)

@Override

public int createTask(Task task)

@Override

public Task getTask(int id)

@Override

public void removeTask(int id)

}

Общий модуль работы с обёрткой XML представлен следующими классами:

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

package common.params;

public interface Params {

public void setName(String name);

public String getString(String name) throws ParamsException;

public void putString(String name, String value);

public void putParams(String name, Params params);

public Params[] getAllParamsWithName(String name);

Element getXmlContent();

}

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

package common.params;

public class ParamsImpl implements Params {

private static final String PARAMETERS_ROOT = "parameters";

private static final String PARAMETER = "parameter";

private static final String PARAMETER_NAME = "name";

private static final String PARAMETER_VALUE = "value";

private Document document;

private Element root;

public ParamsImpl(Node node)

public ParamsImpl()

public ParamsImpl(Params params)

@Override

public void setName(String name)

@Override

public String getString(String name) throws ParamsException

@Override

public void putString(String name, String value)

@Override

public void putParams(String name, Params params)

@Override

public Params[] getAllParamsWithName(String name)

@Override

public final Element getXmlContent()

@Override

public String toString()

}

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

package common.params;

public class ParamsException extends Exception {

public ParamsException(String message)

}

Общий модуль протокола представлен следующими классами:

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

package common.protocol;

public interface Task {

public void setId(int id);

public int getId();

public void setType(String type);

public String getType();

public void setCreationTime(Date creationDate);

public Date getCreationTime();

public void setModificationTime(Date modificationDate);

public Date getModificationTime();

public void setExpirationPeriod(int expirationPeriod);

public int getExpirationPeriod();

public void setState(State state);

public State getState();

public void setResults(Collection<Result> results);

public Collection<Result> getResults();

public Params getParams();

public interface State {

public enum Name { Pending, Initial, Running, Complete, Aborted };

ublic void setName(Name name);

public Name getName();

public void setTotalSteps(int totalSteps);

public int getTotalSteps();

public void setCompleteSteps(int completeSteps);

public int getCompleteSteps();

public void setFailedSteps(int failedSteps);

public int getFailedSteps();

}

public interface Result {

public void setId(int id);

public int getId();

public void setNode(String node);

public String getNode();

public void setPath(String path);

public String getPath();

public void setSize(long size);

public long getSize();

public void setSuccessful(boolean isSuccessful);

public boolean isSuccessful();

}

}

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

package common.protocol;

public class TaskImpl implements Task {

private int id;

private String type;

private Date creationTime;

private Date modificationTime;

private int expirationPeriod;

private State state;

private Collection<Result> results;

private Params params;

public TaskImpl()

public TaskImpl(Params params)

...

Класс маршиллинга задач из файла (потока) с XML и обратно

package common.protocol;

public class Marshaller {

public Task unmarshal(InputStream inputStream) throws MarshallerException

public void marshal(Task task, OutputStream outputStream) throws MarshallerException

}

package common.protocol;

public class MarshallerException extends Exception {

public MarshallerException(String message)

}

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

package common.protocol.tasks;

public class SearchInLogTask extends TaskImpl {

private Date from;

private Date to;

private Set<String> nodes;

private Set<LogType> logTypes;

private boolean isPatternRegExp;

private String pattern;

public final static String TYPE = "SEARCH_IN_LOG";

...

package common.protocol.tasks;

public class CustomLoggingTask extends TaskImpl {

private Date startDate;

private Set<String> nodes;

private LogLevel level;

private Set<String> loggers;

private Collection<LogFilter> filters;

public final static String TYPE = "CUSTOM_LOGGING";

...

package common.protocol.tasks;

public class TcpDumpingTask extends TaskImpl {

private Date startDate;

private Set<String> nodes;

private Nic nic;

private String filter;

public final static String TYPE = "TCP_DUMPING";

public enum Nic { eth0, eth1, eth2 }

...

package common.protocol.tasks;

public class AbortTask extends TaskImpl {

private int abortedTaskId;

public final static String TYPE = "ABORT";

...

package common.protocol.tasks;

public class QueryDataTask extends TaskImpl {

private Set<String> nodes;

private Set<String> dataTypes;

private boolean queryForeignSessions;

public final static String TYPE = "QUERY_DATA";

...

package common.protocol.tasks;

public class DownloadTask extends TaskImpl {

private Map<String, Collection<String>> paths;

public final static String TYPE = "DOWNLOAD";

...

package common.protocol.tasks;

public class SmartPacketDecodeTask extends TaskImpl {

private String encodedPacketContent;

public final static String TYPE = "SMART_PACKET_DECODE";

...

package common.protocol.tasks;

public class StopServerTask extends TaskImpl {

public final static String TYPE = "STOP_SERVER";

...

package common.protocol.tasks;

public class Log {

public enum Level { Debug, Verbose, Status, Warning, Error };

public enum FilterType { Message };

public class Filter {

private FilterType type;

private String value;

public Filter(FilterType type, String value)

public void setType(FilterType type)

public FilterType getType()

public void setValue(String value)

public String getValue()

}

}

4.3 Реализация слоя «Контроллер» клиентского компонента

Как и в описании реализации серверного компонента для краткости изложения приведены только сигнатуры классов (интерфейсов) c константами, полный исходный текст программного комплекса приведён в приложении 2.

Модуль контроллера соединения представлен следующими классами:

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

package client.controller;

public class ClientController extends ModulesController {

public static void main(String[] args)

@Override

protected void initModules() throws ModuleException

}

Класс контроллера соединений. Предоставляет интерфейс для отслеживания состояния соединения с сервером, установки и завершения соедниения. Производит подписку на обновления статуса соединения.

package client.controller;

public class ConnectionController {

private ConnectionMonitor connectionMonitor;

public void registerHandler(ConnectionUpdateHandler handler)

public void unregisterHandler(ConnectionUpdateHandler handler)

public ConnectionContext establishConnection(ConnectionParams connectionParams)

public void disconnect(ConnectionContext connection)

}

Класс мониторинга соединения, реализует интерфейс Runnable для выполнения в параллельном потоке задачи мониторинга состояния соединения с узлом СХД Centera. При изменении состояния оповещает подписчиков (подписка происходит через контроллер соединения).

package client.controller;

public class ConnectionMonitor implements Runnable {

private Collection<ConnectionUpdateHandler> handlers;

public ConnectionMonitor()

public void registerHandler(ConnectionUpdateHandler handler)

public void unregisterHandler(ConnectionUpdateHandler handler)

@Override

public void run()

}

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

package client.controller;

public interface ConnectionUpdateHandler {

public void handle(ConnectionContext context);

}

Модуль контроллера задач представлен следующими классами:

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

package client.controller;

public class TaskController implements ConnectionUpdateHandler {

private CachedTaskRepository taskCache;

private TaskMonitor taskMonitor;

private TaskUpdater taskUpdater;

public TaskController()

public TaskFactory getTaskFactory()

public Task getTask(int id)

public void registerTaskUpdateHandler(int id, TaskUpdateHandler handler)

public void unregisterTaskUpdateHandler(int id, TaskUpdateHandler handler)

@Override

public void handle(ConnectionContext context)

}

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

package client.controller;

public interface TaskFactory {

public SearchInLogTask createSearchInLogTask(Date from, Date to, Set<String> nodes, Set<String> logTypes, boolean isPatternRegExp, String pattern);

public CustomLoggingTask createCustomLoggingTask(Date startDate, Set<String> nodes, Log.Level level, Set<String> loggers, Collection<Log.Filter> filters);

public TcpDumpingTask createTcpDumpingTask(Date startDate, Set<String> nodes, Nic nic, String filter);

public AbortTask createAbortTask(int abortedTaskId);

public QueryDataTask createQueryDataTask (Set<String> nodes, Set<String> dataTypes, boolean queryForeignSessions);

public DownloadTask createDownloadTask(Map<String, Collection<String>> paths);

public SmartPacketDecodeTask createSmartPacketDecodeTask(String encodedPacketContent);

public StopServerTask createStopServerTask();

}

Реализация фабрики задач.

package client.controller;

public class TaskFactoryImpl implements TaskFactory {

...

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

package client.controller;

public class CachedTaskRepository implements TaskRepository {

public CachedTaskRepository(TaskRepository taskRepository)

...

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

package client.controller;

public class TaskMonitor implements Runnable {

private TaskUpdater taskUpdater;

@Override

public void run()

private void checkTasksStates()

}

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

package client.controller;

public class TaskUpdater {

private Map<Integer, TaskUpdateHandler> handlers;

public void update(Task task)

private void compareAndNotify(Task previous, Task actual)

public void registerTaskUpdateHandler(int id, TaskUpdateHandler handler)

public void unregisterTaskUpdateHandler(int id, TaskUpdateHandler handler)

}

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

package client.controller;

public interface TaskUpdateHandler {

public enum UpdateType { State, Result };

public void handle(UpdateType type, Task task);

}

4.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»	Рисунок 4.5 Вид окна «Exit»

Окно «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. ТЕСТИРОВАНИЕ ПРОГРАММНОГО КОМПЛЕКСА

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

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

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

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

5.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%.

5.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, 2009

Van Jacobson, 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, 2006

Internet Engineering Task Force (IETF), Network Working Group. «Request for Comments 1950: ZLIB Compressed Data Format Specification version 3.3» (на английском языке), http://tools.ietf.org/html/rfc1950, 1996

Internet Engineering Task Force (IETF), Network Working Group. «Request for Comments 4250:The Secure Shell (SSH) Protocol Assigned Numbers» (на английском языке), http://tools.ietf.org/html/rfc4250, 2006

World Wide Web Consortium (W3C). «Extensible Markup Language (XML)» (на английском языке), http://www.w3.org/XML/, 2011

Oracle. «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/, 2011

Lasse Koskela. «Test Driven: TDD and Acceptance TDD for Java Developers» (на английском языке), Manning Publications, 2007

Tammo Freese, Henri Tremblay. «EasyMock 3.0 Readme» (на английском языке), http://easymock.org/EasyMock3_0_Documentation.html, 2010

Mountainminds GmbH & 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, 2010

James Gosling, Bill Joy, Guy Steele, Gilad Bracha «The Java Language Specification» (на английском языке), третье издание, Addison Wesley, 2005

ПРИЛОЖЕНИЕ 1

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

системы хранения данных EMC Centera

Техническое задание

Р.П.68124-01

Листов 2

2011

Аннотация

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

Основание для разработки

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

Назначение

Программный комплекс предназначен для автоматизации процессов сбора и анализа данных о состоянии системы хранения данных EMC Centera.

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

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

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

Требования к функциональным характеристикам

Программный комплекс должен предоставлять возможности по сбору информацию о состоянии СХД Centera и сохранении этой информации локально на рабочей станции пользователя:

Содержимое выбранных пользователем системных журналов

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

Текущую конфигурацию кластера

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

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

Сетевого трафика узлов СХД Centera на вхождение сетвых пакетов с заданными пользователем параметрами (сетевой интерфейс, настройки фильтрации сетевых пакетов согласно синтаксису программной библиотеки Pcap)

Содержимого сетевых пакетов типа SmartPacket проприетарного протокола сетевого взаимодействия СХД Centera

Представление содержимого указанного пользователем файла в системе исчисления с основанием 64 (Base64), а также обратное преобразование

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

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

Для использования программы требуется совместимый с IBM/PC компьютер, на котором можно использовать ОС Microsoft Windows XP Service Pack 2 или 3; а также СХД Centera с версией ПО не ниже 4.0

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

Программа предназначена для использования в операционной системе Microsoft Windows XP Service Pack 2 или 3 с установленным пакетом Java Runtime Environment версии не ниже 6.

Приложение 2

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

системы хранения данных EMC Centera

Текст программы

Р.П.68124-01.12

Листов 5

2011

Аннотация

В данном приложении приведён текст программы для анализа состояния системы хранения данных EMC Centera.

Текст программы

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

package common.params;

import java.io.StringWriter;

import javax.xml.transform.Result;

import javax.xml.transform.Source;

import javax.xml.transform.Transformer;

import javax.xml.transform.TransformerConfigurationException;

import javax.xml.transform.TransformerException;

import javax.xml.transform.TransformerFactory;

import javax.xml.transform.dom.DOMSource;

import javax.xml.transform.stream.StreamResult;

import org.w3c.dom.Document;

import org.w3c.dom.Element;

import org.w3c.dom.NamedNodeMap;

import org.w3c.dom.Node;

import org.w3c.dom.NodeList;

import com.sun.org.apache.xerces.internal.dom.DocumentImpl;

/**

* Implementation of XML-wrapping class.

* Intended for usage as parameters bucket.

*

* @author buinok

*/

public class ParamsImpl implements Params {

// default name of root tag in wrapped XML document

private static final String PARAMETERS_ROOT_DEFAULT = "parameters";

// tag name holding simple [name:value] pair

private static final String PARAMETER = "parameter";

private static final String PARAMETER_NAME = "name";

private static final String PARAMETER_VALUE = "value";

// XML document owning child tags which are wrapped by this class

private Document document;

// root element of XML document

private Element root;

/**

* Constructor creates new parameters bucket where

* its content is duplicated from XML node's content

* @param node - source of content for parameters bucket

*/

public ParamsImpl(Node node) {

document = new DocumentImpl();

if(node == null) {

root = document.createElement(PARAMETERS_ROOT_DEFAULT);

document.appendChild(root);

} else {

document.appendChild(document.importNode(node, true));

root = document.getDocumentElement();

}

}

/**

* Default constructor. Creates empty parameters bucket

* with default root tag name

*/

public ParamsImpl() {

document = new DocumentImpl();

root = document.createElement(PARAMETERS_ROOT_DEFAULT);

document.appendChild(root);

}

/**

* De-facto copy constructor. Creates new parameters bucket

* then fill it by duplicated content of @param params argument

*/

public ParamsImpl(Params params) {

document = new DocumentImpl();

if(params == null) {

root = document.createElement(PARAMETERS_ROOT_DEFAULT);

document.appendChild(root);

} else {

document.appendChild(document.importNode(params.getXmlContent(),true));

root = document.getDocumentElement();

}

}

/**

* Sets name of root tag to @param name if it's not null,

* otherwise just ignores call

*/

@Override

public void setName(String name) {

if(name != null)

document.renameNode(root, null, name);

}