41
Экспорт в векторном формате для издательской системы. В данном слу-
чае подразумевается формат позволяющий, без потери качества, загру-
жать подготовленный материал в издательскую систему. Спорный во-
прос остается по EMF (Enhanced Metafile Format) формату, так как по
сути это формат Microsoft Windows и предназначен для передачи изоб-
ражения на печать
4
. Но, издательские системы не всегда корректно его
загружают, в частности Adobe InDesign загружает его как изображение
и вообще компания Adobe рекомендует его избегать
5
.
Возможность подготовки сетки любой конфигурации. Здесь имеется
ввиду возможность указания пользователем размещения фотографий и
пустого пространства в сетке.
Возможность настройки стиля издания. В данном случае экспорт мате-
риала должен настраиваться в соответствии со стилем издания, вид
сетки, толщины линий, размеры ячеек и вид стрелок должны соответ-
ствовать этому стилю.
Поддержка. Наличие документации, сайта программы и связи с разра-
ботчиком.
Данный перечень параметров не окончательный, но его будет достаточно для
сравнения программного обеспечения. В сравнение взяты наиболее встречающиеся
в интернете программы:
КроссМастер;
EasyCross;
FineCrosser;
Крестословица.
Практически все они на текущий момент устарели, но функции свои все равно
выполняют. К сожалению, посмотреть удалось только демонстрационные версии.
В конечном итоге все они однопользовательские, настройки внешнего вида голово-
ломок и варианты экспорта сильно ограничены. Только некоторые из этих про-
4
Больше о формате EMF можно узнать перейдя по ссылке https://msdn.microsoft.com/en-
us/library/windows/desktop/dd162600(v=vs.85).aspx
5
Загружаемые форматы в Adobe InDesign https://helpx.adobe.com/indesign/using/importing-files-applica-
tions.html
42
грамм поддерживают экспорт в CorelDraw, а в основном экспорт только в графиче-
ские форматы и EMF. Ниже представлена таблица со сравнительными характери-
стиками «Таблица 11. Сравнительные характеристики существующего программ-
ного обеспечения».
Таблица 11. Сравнительные характеристики существующего программного
обеспечения
Арагаст
КроссМастер
EasyCross
FineCrosser
Крестословица
1. Возможность многопользователь-
ской работы
Да
2. Контроль повторения слов и опреде-
лений
Да
Да
3. Экспорт в векторном формате для
издательской системы
Да
Да
Да
4. Возможность подготовки сетки лю-
бой конфигурации
Да
Да
Да
Да
5. Возможность настройки стиля изда-
ния
Да
6. Поддержка
Да*
Да
Да
Да
Да
*Условно можно связаться с разработчиком
Из таблицы можно увидеть, что только «Арагаст», при всех своих недостат-
ках, обладает минимальным набором необходимых параметров. Но, в данной ситу-
ации его использование невозможно из-за запрета разработчика. Точнее, данный
программный продукт для разработчика является основным средством производ-
ства, и его передача другим лицам практически повлечет за собой потерю рынка
сбыта и возможно потерю самого бизнеса.
В конечном итоге при наличии разнообразных программ готовить голово-
ломки оказалось не на чем. Возникла острая необходимость иметь собственный
полноценный инструментарий, который снял бы все недостатки присущие выше-
указанным программам.
Параметр
43
1.3.2. Выбор и обоснование стратегии автоматизации задачи
На текущий момент на предприятии состояние автоматизации говорит о при-
менении до этого хаотичной стратегии. Существует целый ряд программных про-
дуктов, совершенно не согласованных между собой. Для дизайна используются
Adobe Illustrator и Adobe Photoshop, для верстки Adobe InDesign. Эти программные
продукты за время эксплуатации обросли большим набором скриптов собственного
производства, предназначенных для сугубо внутренних задач издательства. Напри-
мер, таких как пакетная обработка фотографий, подготовка номера в системе
верстки и т.п.
Помимо этого, существует отдельная задача, обрабатывающая базу данных
киноанонсов, загрузку телепрограмм, ротацию анекдотов и крылатых фраз. Услож-
няется все еще тем, что телепрограммы от телеканалов поступают в форматах не-
пригодных для программной обработки. Например, в виде произвольного текста в
документе Microsoft Word. В редакции содержится специальный сотрудник, выпол-
няющий сборку телепрограммы в пригодный для верстки вид. Также нужно учесть,
что существуют региональные телепрограммы, что еще больше увеличивает слож-
ность подготовки. Т.е. готовится несколько телепрограмм, своя для каждого реги-
она. Программа обработки анонсов, телепрограмм, анекдотов и крылатых фраз раз-
работана в Borland Delphi 6. В качестве серверной части используется база данных
FireBird.
Для отдела сбыта разработана собственная программа учета, проданного
и/или возвращенного количества тиража. Программа очень специфична и ориенти-
рована сугубо для издательского дела. Как бы то ни было она успешно эксплуати-
руется с 2003 года. Она также разработана в Borland Delphi 6. В качестве серверной
части используется база данных FireBird.
В бухгалтерии используется, соответственно, «1С – Бухгалтерия». Нужно от-
метить, что программное обеспечение отдела сбыта имеет одностороннюю связь с
«1С – Бухгалтерия». Версия «1С – Бухгалтерия» не сетевая, точнее версия не ис-
пользует сервера базы данных, а работает с единой базой на файл-сервере.
И, конечно же, специализированное программное обеспечение для издатель-
ства по изготовлению головоломок «Арагаст». Данное программное обеспечение
44
разработано в Microsoft Visual Studio с использованием .NET Framework. В каче-
стве базы данных используется Microsoft SQL Server.
Отдельно разработан веб-сайт одного из изданий, для журнала «Телегид» с
использованием CMS Wordpress.
Также используется офисное программное обеспечение такое как Microsoft
Office, The Bat!, WinRar и т.п.
Все это на текущий момент имеет некоторые шлюзы для экспорта данных, как
правило односторонние, и довольно успешно функционирует.
А так как задача большой автоматизации не ставилась и, если быть более точ-
ным, полная автоматизации отвергается руководством редакции полностью, а
единственным слабым участком оказалось именно создание головоломок то, соот-
ветственно, задача прозвучала довольно четкая — автоматизировать именно созда-
ние головоломок.
Исходя из поставленной задачи естественным образом определяется автома-
тизация по участкам, с перспективой развития в автоматизацию по направлениям.
В данном случае важно предусмотреть возможность использования про-
граммы в других подразделениях. Например, руководством для контроля выполне-
ния задачи или дизайнерами (верстальщиками) для обратной связи с создателем го-
ловоломок. Возможно разделение функциональности внутри кроссвордной редак-
ции для улучшения производительности.
1.3.3. Выбор и обоснование способа приобретения ИС для автоматиза-
ции задачи
Все предоставленные программы, которые были найдены в сети интернет и
предлагаются для коммерческого использования были протестированы с участием
специалистов издательства. Этот процесс проходил несколько дней, на каждый
предложенный вариант был получен устный отзыв. В действительности все пред-
ложенные программы были отвергнуты с основной практической формулировкой
«Нет экспорта в EPS или InDesign». Каждая программа была подвергнута критике
начиная от формулировок «нет документации», «слабая документация» и заканчи-
вая «нет возможности сделать то, что нужно».
45
Постоянно поднималась тема удобства пользования, простоты и хорошей до-
кументации. В частности, все сходились во мнении, что вся функциональность
должна находиться под одной оболочкой. Это скорее влияние программ от
Microsoft и Adobe, так как все сотрудники редакции пользуются такими програм-
мами и поэтому они не видят пользы в делении программного обеспечения на ра-
бочие места. Тем более пример программы «Арагаст» только усугубляет данное
мнение, где все модули используются одним сотрудником и вызывают только раз-
дражение от необходимости работы в разных приложениях, причем, когда дей-
ствия в одном приложении невозможно совершить без подготовки данных в дру-
гом. Иногда для обновления данных приложение приходится перезапускать, что
еще больше приводит к отторжению данного подхода.
В конечном итоге, даже еще до исследования существующих программ все
сотрудники издательства сошлись на мнении, что необходимо собственное про-
граммное обеспечение, причем разработанное прямо в издательстве. Соответ-
ственно, чтобы они могли влиять на разработку и, в конечном итоге, получить
именно то, что нужно.
Аргументы в виде довольно высокой стоимости и длительности разработки
были восприняты руководством очень спокойно. Стало понятно, что данное реше-
ние принято уже давно, и уже разработан план переходного периода. Данный план
предусматривал продолжение передачи создания головоломок субподрядчику и
проведение разработки в строгой секретности, чтобы избежать конфликта интере-
сов и вероятности срыва производства. Данное решение было принято после рез-
кого повышения расценок субподрядчиком.
Как видно из вышесказанного приобретение программы, в том числе и с дора-
боткой практически исключено. Также все программы имеют закрытый исходный
код, и никто не собирается им делится, что однозначно приводит к решению о соб-
ственной разработке.
46
1.4. Обоснование проектных решений
1.4.1. Обоснование проектных решений по информационному обеспече-
нию
Изначально рассматривался проект, в котором макет головоломки играл клю-
чевую функцию и редактирование предполагалось только его наполнения, а сам
макет имеет заранее предопределенный вид. В общем, так построено все программ-
ное обеспечение по созданию головоломок. Но, сотрудники издательства, привык-
шие работать с программами от Adobe и Microsoft однозначно заявили, что они хо-
тят видеть, то что они получат. Это предопределило другой подход в подготовке
головоломок по принципу WYSIWYG (“what you see is what you get” - «Что вы ви-
дите то вы и получите»). Соответственно это изменило подход, а от макета при-
шлось отказаться и перейти в документно-ориентированную архитектуру. Такая
архитектура позволяет размещать головоломку в документе визуально, что дает
пользователю представление как все будет выглядеть на бумаге.
В конечном итоге с появлением документа появилась возможность размещать
в нем несколько головоломок и готовить целую страницу. Это ломает стереотип
подготовки головоломок и предполагает другой технологический процесс их под-
готовки. Это обозначает, что в документ можно добавить любую головоломку, но
какую, готовую или только прообраз? Если добавлять готовую головоломку тогда
ее нужно где-то подготовить, а так как разделение задач пользователем не позволи-
тельно тогда остается решение добавлять прообраз и готовить ее в самом доку-
менте. С точки зрения документно-ориентированных программ в этом нет ничего
предосудительного. Во всех таких программах сначала добавляется объект, а затем
производиться изменение его свойств.
На примере сканворда можно пройти процедуру создания головоломки в до-
кументно-ориентированной архитектуре по стандартному заданию, чтобы убе-
диться, что такая архитектура жизнеспособна «Таблица 12. Соотнесение пунктов
задания на составление головоломки типа «Сканворд» с действиями в документно-
ориентированной программе».
47
Таблица 12. Соотнесение пунктов задания на составление головоломки типа
«Сканворд» с действиями в документно-ориентированной программе
№
Заказ
Действие
1.
Название головоломки «Скан-
ворд».
Добавление в документ объекта типа «Скан-
ворд».
2.
Размер сканворда 20х15.
Установка размера 20х15 или загрузка гото-
вой сетки с нужными характеристиками.
3.
Размер ячеек 12х12 миллимет-
ров.
Установка размера ячеек 12х12 мм.
4.
Толщина рамки 1 пункт.
Установить толщину рамки 1 пункт.
5.
Толщина линий 0.5 пункта.
Установить толщину линий 0.5 пункт.
6.
Язык слов и определений рус-
ский.
Установить язык заполнения «Русский» и за-
пустить процесс заполнения сканворда сло-
вами.
7.
Результат передать в издатель-
скую систему Adobe InDesign/
Экспортировать заполненный сканворд в из-
дательскую систему Adobe InDesign
Как видно из таблицы, с точки зрения входящего задания на изготовление го-
ловоломки, никаких противоречий не возникает. Все достаточно знакомо, просто и
логично — существуют свойства головоломки, процесс заполнения и экспорта.
Несколько иначе обстоят дела с ведением базы данных слов и определений. В
документно-ориентированной архитектуре работа с базой данных остается за пре-
делами документа. Но, нужно сказать, есть немало хороших примеров где подоб-
ная архитектура совмещена с ведением базы данных. Одним из таких примеров яв-
ляется Microsoft Visual Studio. В данной оболочке совмещено много различных ви-
дов интерактивных документов и, в частности, таблицы для редактирования баз
данных. Не обязательно редактирование должно быть только в таблице, можно ис-
пользовать и формы, но, на практике, специализированные формы гораздо более
сложны для восприятия пользователем. В противоположность формам работа с
таблицами пользователю привычнее и реже вызывает непонимание в процессе ре-
дактирования. Заданный порядок полей в таблице предопределяет порядок ввода
данных, а хорошо продуманные элементы редактирования значительно упрощают
ввод данных.
С точки зрения универсализации таблица гораздо легче ей поддается для
отображения данных из любой базы, вплоть до отображения любой таблицы, ис-
пользуя динамическое связывание. В данном проекте такая универсализация явля-
ется излишней, но выбор таблицы как основного элемента ведения базы данных
слов и определений вполне оправдана. Для проверки данного утверждения доста-
точно показать, что в таблице возможно добавление, изменение и удаление слов и
определений. Помимо этого, возможна фильтрация по значению и сортировка по
48
любой колонке, что может дать великолепные возможности для поиска значений и
даже получение некоторой статистики по данным.
В итоге табличная форма представления данных со строкой фильтрации и
сортировкой является приемлемой и достаточной для ведения базы данных слов и
определений.
Для возможности использования программного обеспечения в многопользова-
тельском режиме для хранения базы данных слов и определений предполагается
сервер управления базой данных. Помимо хранения самих слов и определений
стоит задача хранения изображений и сеток головоломок. На текущий момент
изображения хранятся в отдельных файлах, а в базе данных существует только
ссылка на них, но эта практика является, по меньшей мере, ошибочной. Все изобра-
жения должны хранится в базе данных. Тем более, что уже давно во многих из них
предусмотрены для этого определенные типы полей. Благодаря этому сохранится
целостность базы данных и соответственно информация будет более защищена.
Еще одним интересным моментом является способ хранения сеток головоло-
мок. На текущий момент, например, в «Арагаст», сетки хранятся в базе данных в
виде полноценных сущностей. Но, в некоторых программах сетки хранятся отдель-
ными файлами, например, в «EasyCross». Отдельные файлы хороши тем, что дают
возможность переноса сеток на файловом носителе. Основная проблема в том, что
сетки несут в себе ряд параметров, таких как шрифты, толщины линий, рамок, рас-
положение блоков изображений и т.п. Возникает вопрос как хранить сетки в базе
данных? Для этого можно разработать некую универсальную структуру, но нет га-
рантии, что этой структуры окажется достаточно в будущем. Гораздо проще поме-
нять формат файла, чем обновлять структуру базы данных, особенно удаленно.
Можно конечно предусмотреть версионность базы данных, чтобы программа пони-
мала, что структура не соответствует версии, но подобные проверки придется де-
лать при каждом запуске программы. В конечном итоге раз уж изображения будут
хранится полостью в базе, то почему бы и сетки не хранить в базе данных как
файлы. Это решает такие вопросы как более простая модернизация формата хране-
ния, одинаковость алгоритма загрузки как из файла, так и из базы данных, более
простой алгоритм переноса сеток из файловой системы в базу данных и обратно.
49
К сожалению в этом варианте присутствуют и недостатки, основной из кото-
рых — это медленный алгоритм поиска одинаковых сеток, так как для сравнения
придется вычитывать из базы весь файл сетки. Именно для оптимизации данной за-
дачи в сущность для хранения сеток, назовем их модели, можно внести поля с ос-
новными реквизитами сеток, это тип головоломки, размер в ячейках и количество
блоков для фото. Данные реквизиты могут заполняться автоматически и главное их
присутствие снимет вопрос с поиском.
Также следует отметить, что хранение сеток в виде файлов значительно сокра-
щает работы по проектированию таблиц, в частности можно обойтись без справоч-
ника шрифтов. Также это сокращает и работу для пользователя, которому не нужно
будет вводить эти данные в базу.
Как вывод — преимущества превышают недостатки, по сути сетку проще хра-
нить в базе данных как файл.
Исходя из вышесказанного понятно, что придется разрабатывать механизм
чтения и записи файлов в базу данных. И раз уж такой алгоритм будет присутство-
вать возникает логичный вопрос, а почему бы и сам документ не хранить в базе?
Это даст возможность систематизировать документы, а главное, хранение будет
централизованным и доступ к документам будет только у тех, кто работает с базой
данных.
В общем, в базе данных будет хранится все, и исходные данные, и результат
работы, кроме экспортируемых данных.
После того как определено хранение части данных можно определить требуе-
мые классификаторы и справочники для технологического процесса. Частично тех-
нологический процесс уже представлен в таблице «Таблица 12. Соотнесение пунк-
тов задания на составление головоломки типа «Сканворд» с действиями в
документно-ориентированной программе». Для полного технологического про-
цесса необходимо добавить действия, которые возникают в процессе выполнения
всех требований к новому программному обеспечению.
Перед этим можно определить состав классификаторов и справочников.
50
В новой программе требуется ведение базы данных слов и определений на не-
скольких языках. Данное требование предопределяет наличие классификатора язы-
ков. В данном случае будет частично использоваться классификатор, разработан-
ный компанией Microsoft
6
(приложение «B-1 Классификатор языков»).
Для поддержки нескольких изданий определяется справочник изданий (пуб-
ликаций).
Наличие групп сложности слов и определений соответственно требуют спра-
вочники групп слов и групп определений.
Для автоматизации экспорта понадобятся справочники «Тип экспорта» и «Оп-
ции экспорта».
Для определения типа головоломки понадобится соответственно справочник
«Типы головоломок».
Описание сформулированных справочников отражено в таблице «Таблица 13.
Перечень определенных справочников и классификаторов».
Таблица 13. Перечень определенных справочников и классификаторов
№
Наименование
Описание
1.
Классификатор
языков
Перечень мнемоник и кодов языков для операционной си-
стемы Microsoft Windows.
2.
Справочник
«Публикации»
Данный справочник содержит информацию об издании, пери-
одичности выхода, глубине проверки повторения слов, кон-
тактные данные заказчика и формат экспорта.
3.
Справочник
«Группы слов»
Данный справочник содержит наименования и коды групп
для объединения слов в группы.
4.
Справочник
«Группы опреде-
лений»
Данный справочник содержит наименования и коды групп
для объединения определений в группы.
5.
Справочник «Тип
экспорта»
Данный справочник содержит типы экспорта, в который
необходимо экспортировать документ для определенного из-
дания. Например PDF.
6.
Справочник «Оп-
ции экспорта»
Данный справочник содержит данные о пути экспортирован-
ного документа. Например адрес электронной почты куда
следует отправить экспортированный файл(ы).
7.
Справочник
«Типы головоло-
мок»
Содержит коды и наименования типов головоломок для при-
вязки моделей (сеток) к типу головоломки. Например, клас-
сический кроссворд или сканворд.
Теперь можно более полно описать технологический процесс создания голо-
воломки. Точнее создание документа, который будет содержать головоломку «Таб-
лица 14. Технологический процесс создания головоломки».
6
Константы для национальных языков https://msdn.microsoft.com/en-
us/library/windows/desktop/dd318693(v=vs.85).aspx