3.3 Обновление публикаций 3.3.1 Взаимодействие с сервером обновлений Для каждой публикации характерен свой определенный набор атрибутов. Например, могут присутствовать: companyName – имя компании; iconName – путь до иконки публикации; publicationName – название публикации; language – язык публикации; connection - URL до сервера обновлений; serverKey – идентификатор файла; version – номер версии публикации; free – признак бесплатности и т.п. В общем случае, взаимодействие мобильного телефона и сервера проще всего отобразить диаграммой взаимодействия (рис. ). Рис. – Диаграмма взаимодействия телефона и сервера обновлений Для обновления существующих в базе публикаций необходимо, прежде всего, проверить наличие обновлений для данных публикаций на сервере. Для этого перебираем файлы публикаций, для каждого из них берем следующие параметры из имеющихся у них атрибутов: serverkey – хранит уникальный идентификатор файла; connection – хранит URL до сервера. Процесс взаимодействия с сервером лучше всего демонстрируют диаграммы последовательностей (рис. 3.23). Сам процесс проверки на наличие новой версии существующей публикации таков: 1. берем URL из атрибута connection с адресом сервера обновлений и отправляем на него POST-запрос с параметрами: fileID – значение serverkey; deviceID – IMEI устройства; requestSignature – хэш по алгоритму MD5 от fileID, deviceID и некоторой числовой константы. Рис. – Диаграмма последовательностей проверки наличия обновлений 2. в ответ на запрос сервер обновлений проверит корректность предоставленного запроса и доступность пакетов обновлений, в итоге ответит строкой в виде: resultCode – код ответа; clientId – идентификатор клиента публикации; latestVersion – строка доступных версий обновлений в виде, например, [1.1,1.2,1.3]; publicationId – идентификатор публикации. Возможные значения кодов ответа приведены в таблице: Таблица – Коды ответов при проверке новых версий публикаций Код ответа Расшифровка значения 0 Все нормально 1 Недостаточно параметров 2 Некорректный fileID 3 Неправильная цифровая подпись 10 Внутренняя ошибка Следующим шагом является загрузка обновлений (при соответствующем наличии) (рис. ): Рис. – Диаграмма последовательностей загрузки пакета обновлений 1. аналогично предыдущему берем URL до сервера обновлений из атрибута connection и отправляем на него POST-запрос с параметрами: publicationID – полученный из ответа проверки на наличие обновлений идентификатор публикации; clientID – полученный из ответа проверки на наличие обновлений идентификатор клиента публикации; publicationVersion – версия публикации для обновления; deviceID – IMEI устройства; requestSignature – хэш по алгоритму MD5 от вышеперечисленных параметров и некоторой числовой константы. 2. в ответ на запрос сервер обновлений ответит строкой кода ответа resultCode или потоком с файлом. Возможные значения кодов ответа приведены в таблице Таблица – Коды ответов при загрузке пакетов обновлений Код ответа Расшифровка значения 1 Недостаточно параметров 3 Неправильная цифровая подпись 5 Неправильный формат файла 6 Пустой путь к файлу 10 Внутренняя ошибка Реализацию взаимодействия с сервером демонстрирует диаграмма классов (рис). Рис. – Диаграмма классов взаимодействия с сервером После загрузки пакета обновлений в память телефона, происходит установка обновления, приводящая к изменению в объектной модели. 3.3.2 Изменения в объектной модели Обновление публикаций инкрементальное, т.е. нельзя обновить существующую публикацию с версией 1.0 пакетом обновлений 1.2. Необходима следующая последовательность: сначала установить публикацию с версией 1.0, обновить ее до версии 1.1, а затем уже установить обновления версии 1.2. В общем случае, обновление происходит так, как показано на рисунке (рис.). Ей соответствует диаграмма классов (рис. ). Рис. – Процесс обновления публикации из пакета обновлений //страница 61 Рис. – Классы, участвующие в процессе обновления 3.4.1 Алгоритм поиска Поиск позволяет пользователям быстро найти информацию в публикациях. Для него имеются различные опции, которые пользователь может настроить под себя (рис. ). Это поиск по публикации, поиск по заголовкам и подзаголовкам (если включена эта опция, то поиск будет осуществлен также по таблицам и диаграммам), поиск по содержимому публикации, а также ограничение по числу результатов поиска (отобразятся на экране только наиболее отвечающие запросу результаты). Работа пользователя с поиском представлена на рисунке (рис. ). Рассмотрим программную реализацию в виде диаграмм классов (рис). Алгоритм работы поиска достаточно прост. Сначала загружаем список ключевых слов keywords, а затем ищем линейным перебором все совпадения. Первоначально для ускорения поиска по полному совпадению использовался бинарный поиск над отсортированной последовательностью ключевых слов. Однако он работал некорректно при сужении диапазона поиска, так как лексикографическое сравнение строк в разных языках может быть реализовано по-разному. Пользователь вводит поисковый запрос Приложение ищет совпадения в списке KeyWords Совпадения найдены? да Приложение показывает узлы с найденными ключевыми словами Показываем результаты поиска нет нет Приложение ищет совпадения в списке SpellCheck Приложение запускает проверку орфографии над введенным запросом Совпадения найдены? Прогресс бар на экране, приложение пытается найти корректировки да Приложение возвращается к к экране поиска с пустым результатом без альтернатив проверки орфографии Исправления показываются на экране Экран настройки поиска Уведомление пользователя Рис. – Работа пользователя с поиском Рис. – Диаграмма классов для поиска и проверки орфографии 3.4.2 Алгоритм проверки орфографии При вводе поискового запроса пользователь может ввести некорректные данные (например, запрос «ааа» вряд ли выдаст корректные результаты), то программа предложит ему варианты предположения запроса. Максимальное количество отображаемых предложений – два. Алгоритм работы с проверкой орфографии: 1. пользователь вводит строку запроса; 2. программа проверяет орфографическую корректность поискового запроса; 3. если найдены неточности в запросе: 4. на экране поиска показываются предположения запроса; 5. пользователь выбирает одно из них; 6. происходит поиск; 7. выдается список результатов. Алгоритм проверки орфографии основывается на расстоянии Левенштейна (также называется редакционное расстояние или дистанция редактирования) – в теории информации и компьютерной лингвистике — это мера разницы двух последовательностей символов (строк) относительно минимального количества операций вставки, удаления и замены, необходимых для перевода одной строки в другую [25]. Введём теперь понятие редакционного предписания – последовательности действий, необходимых для получения из первой строки второй кратчайшим образом. Обычно действия обозначаются так: D (англ. delete) – удалить, I (англ. insert) – вставить, R (англ. replace) – заменить, M (англ. match) – совпадение. Функция Левенштейна играет роль фильтра, заведомо отбрасывающего неприемлемые варианты (у которых значение функции больше некоторой заданной константы). Например, для двух строк «CONNECT» и «CONEHEAD» можно построить следующую таблицу преобразований: M M M R R R R C O N N E C T C O N E H E A Расстояние Левенштейна I D определяется посредством операций для преобразования исходного слова x в слово y: трех замещение (substitution) одного символа из x символом из y; удаление (deletion) символа из x; вставка (insertion) символа в y. Каждая операция имеет определенный вес, и полное расстояние определяется минимальной суммой весов для преобразования слова x в слово y. Интуитивно понятно, что алгоритм, основанный на таких операциях, будет хорошо работать с исправлением орфографических ошибок, опечаток, так как приведенные операции интерпретируются как манипуляции по исправлению ошибок. Например, при вводе слова wromg (вместо wrong) возникает ошибка замещения, для слова wromng – ошибка удаления, а для слова wrog – ошибка вставки. Для определения расстояния Левенштейна используется вес для вставки и удаления равный 1. Вес замещения равен 1, если символы различны, в противном случае равен 0. Для запуска алгоритма, необходимо заполнить первую строку матрицы, соответствующую пустому исходному слову, весами от 0, 1, ..., j для вставки символа. Аналогично заполняется и первый столбец для пустого результирующего слова с весами для удаления символа. Затем рассчитываются значения весов для ячеек по следующей схеме для трех соседей (сверху, слева и сверху слева по диагонали): Diagonal Above Left Min( Diagonal + вес замещения, Above + вес удаления, Left + вес вставки ) Итоговое расстояние будет найдено в самом нижнем правом углу. Пример расчета расстояния Левенштейна для преобразования puzzle в pzzel (расстояние равно 3) представлен на таблице. Таблица – Пример нахождения расстояния Левенштейна Таким P U Z Z L E 0 1 2 3 4 5 6 P 1 0 1 2 3 4 5 Z 2 1 1 1 2 3 4 Z 3 2 2 1 1 2 3 E 4 3 3 2 2 2 2 L 5 4 4 3 3 2 3 образом, алгоритм проверки орфографии можно представить в виде рисунка (рис.) [27]. С точки зрения приложений определение расстояния между словами или текстовыми полями по Левенштейну обладает следующими недостатками: При перестановке местами слов или частей слов получаются сравнительно большие расстояния Расстояния между абсолютно разными короткими словами оказываются небольшими, в то время как расстояние между сильно похожими длинными словами оказываются значительными Приложение определяет длину поискового запроса Приложение загружает 3 наиболее близких по длине слова SpellCheck словари - с уменьшенной на 1, с увеличенной на 1 и с такой же длиной слова, что и запрос, в один список Для каждого слова в составленном списке рассчитываются редакционные расстояния между данным словом и запросом 2 результата с наименьшим расстоянием показываются на форме поиска Рис. – Алгоритм проверки орфографии Таким образом, в случае неудачного поиска, можно выделить следующие шаги проверки орфографии: 1. Определить длину length поискового запроса 2. Составить список ключевых слов длиной length+1 и length-1 3. Рассчитать расстояние Левенштейна между запросом и текущим вариантом 4. Выдать два найденных первых варианта