Содержание к диссертации
Введение
ГЛАВА 1. Тиражируемые программные системы 7
1.1. Современные тиражируемые системы 9
1.2. Определение области исследования 19
1.3. Средства создания слабо тиражируемых систем 24
1.3.1. Традиционные средства программирования 24
1.3.2. Средства проектирования 26
1.3.3. Визуальное программирование 31
1.4. Типы информационных приложений 32
1.5. Выводы по главе 34
ГЛАВА 2. Математическая модель слабо тиражируемых систем 36
2.1. Терминология и формализм 36
2.2. Модель оценивания тиражируемости в случае легкой разработки 49
2.3. Математическое моделирование процессов жизненного цикла слабо тиражируемых систем 53
2.4. Использование математического моделирования процессов создания и сопровождения систем 55
2.5. Выводы по ГЛАВЕ 56
ГЛАВА 3. Создание и сопровождение слабо тиражируемых систем 57
3.1. Общие проблемы слабо тиражируемых систем 58
3.2. Концептуальные принципы слабо тиражируемых систем 59
3.3. Структура слабо тиражируемых систем 63
3.4. Реализация системного словаря 65
3.4.1. Словарь данных системы 65
3.4.2. Словарь пользователей системы 71
3.4.3. Словарь последних изменений 72
3.4.4. Словарь ошибок системы 72
3.4.5. Словарь консолидирующего модуля 73
3.4.6. Словарь контроля данных 74
3.4.7. Словарь настроек системы 75
3.4.8. Словарь функций системы 75
3.4.9. Словарь пользовательских функций 76
3.5. Словарь унифицированных терминов 76
3.6. Организация процесса сопровождения слабо тиражируемых систем 76
Заключение 80
Литература 80
- Определение области исследования
- Модель оценивания тиражируемости в случае легкой разработки
- Концептуальные принципы слабо тиражируемых систем
- Организация процесса сопровождения слабо тиражируемых систем
Введение к работе
Цель диссертационной работы - анализ, разработка и обоснование методов построения и поддержки программных систем., относящихся к классу слабо тиражируемых, которые позволяют уменьшить расходы разработчика и потребителя программного продукта.
Как производство любой продукции, разработка прикладных программных систем требует определенных средств. Чтобы производство было рентабельным, необходимо, чтобы издержки покрывались выручкой от продажи или поставки продукции заказчику. В отличие от обычного материального производства, выручку можно существенно увеличить за счет относительно дешевого тиражирования. Это позволяет также снизить цену продукта, что весьма актуально сейчас ввиду обострения конкуренции среди разработчиков. Однако, практика показывает, что затраты на тиражирование, включающие в себя адаптацию и настройку системы, обучение пользователей и специалистов по сопровождению, а также последующее сопровождение программных продуктов сравнимы, а нередко и превышают затраты на их создание. В результате разработчики либо ограничивают количество тиражных копий своей системы, либо вынужденно передают процесс сопровождения потребителю их продукции, при этом раскрывая всю проектную документацию от формализованного описания технологии до исходного программного кода. Это не всегда выгодно и потребителю: он финансирует процесс сопровождения, включая адаптацию, смену версий и замену морально устаревшего программного обеспечения из своего бюджета. Кроме того, стоимость полной документации по системе бывает весьма велика.
Проблема тиражирования тесно связана с проблемой сопровождения программной системы. Организации процесса сопровождения уделяют недостаточно внимания, несмотря на то, что этот вопрос стоит очень давно [10]. Иногда производителю программных продуктов бывает выгодно оставить эту проблему нерешенной, т.к. это служит дополнительным доходов от непосредственных заказчиков и пользователей, а также источником получения части прибыли от фирм, занимающихся внедрением и сопровождением чужих программных продуктов. Однако в условиях жесткой конкуренции такие производители постепенно вытесняются с рынка. Бывают исключения, когда производителем поддерживается актуализация системы в условиях динамично развивающейся предметной области, что является хорошим фактором конкурентоспособности программного обеспечения. Примером могут служить системы
4 «1С». Несмотря на то, что адаптация и сопровождение этих программных продуктов требует определенных знаний и навыков, которыми конечный пользователь не обладает, для него остается привлекательным тот факт, что фирма-производитель поддерживает актуализацию системы в соответствии с динамично меняющимся законодательством. Кроме того, система предполагает внесение изменений в некоторые формы, отчеты и запросы, что дает возможность модифицировать ее под требования конечного пользователя. Спрос на актуализированную бухгалтерскую систему высок в связи с развитием мелкого, среднего и даже крупного бизнеса, что позволяет развиваться фирмам, специализирующимся на внедрении и сопровождении данного программного продукта.
Все программные продукты можно условно разбить на три типа по степени и возможности их тиражирования. Будем считать систему Уникальной, если совокупные затраты на изготовление и адаптацию тиражной копии сравнимы с разработкой новой системы. Систему, совокупные затраты на тиражирование которой малы по сравнению с созданием новой, назовем Высоко Тиражируемой. Остальные системы назовем Слабо Тиражируемыми (СТС).
Для фирм, занимающихся производством Высоко Тиражируемых программных средств, механизмы адаптации и сопровождения не столь важны, так как продается обычно только программный продукт, а не услуги разработчиков. Поэтому требования к адаптации подобных продуктов ограничиваются возможностью общей настройки интерфейса и настройки представлений данных. Примером высоко тиражируемых программных средств могут служить любые продукты, распространяемые «коробочным» способом: текстовые редакторы, электронные таблицы и т.п. Нередко подобные программные продукты объединены в группы и продаются пакетами, например известный пакет Microsoft Office.
Для производителей уникальных программных комплексов, коллектив разработчиков которых обычно сопровождает свой продукт на протяжении всего жизненного цикла, вопросы, связанные с автоматизацией сопровождения, носят узкоспециализированную направленность, механизмы тиражирования в этом случае не рассматриваются.
Для фирм, специализирующихся на производстве слабо тиражируемых систем, проблемы, связанные с процессом тиражирования и с растущими трудозатратами на обслуживание каждой тиражной копии, становятся исключительно актуальными. В последнее время наблюдается тенденция роста доли подобных систем на рынке программного обеспечения, уникальные программные комплексы постепенно вытесняются. Во многом это связанно со стоимостной разницей. Уникальный
5 программный комплекс, со всеми затратами, в том числе и временными, относящимися к созданию, внедрению и сопровождению, содержанию соответствующих специалистов, могут позволить себе либо крупные корпорации, либо структуры, деятельность которых сама по себе уникальна, такие, например, как военно-промышленные или высокотехнологичные производства и научные комплексы.
На волне автоматизации меняются практически все технологии промышленного производства и управления, короче становится жизненный цикл [15, 43, 44] программных продуктов: большинство из них быстро устаревают как морально, так и технологически и оказываются неспособными к модификации при адаптации к технологическим изменениям производства. Потребитель системы в какой-то степени может смириться с тем, что система морально устаревает, до тех пор, пока сохраняется ее адекватность используемым технологиям. Если же система не соответствует существенным производственным процессам, она заменяется новой. За последнее время средняя продолжительность жизненного цикла систем сократилась с 6-8 до 2-5 лет. В данном случае влияет и фактор морального устаревания системы, когда на фоне изменений программно-технических средств система, разработанная с помощью «устаревших» средств, кажется устаревшей, хотя по показателям производительности и реализованным в системе технологиям она полностью адекватна. Основные причины замены системы следующие: несоответствие требуемым показателям производительности или изменениям технологии; моральное устаревание системы; смена руководства или политики организации; удорожание или затруднение процесса сопровождения системы. В связи с сокращением жизненного цикла систем и, следовательно, увеличением затрат на замену и модернизацию программно-технических средств, наблюдается заметное удорожание процесса автоматизации, несмотря на повышение производительности труда программистов,
Слабо тиражируемые системы различаются по областям применения, степени сложности связей, качественным и стоимостным характеристикам, методам их создания и технологиям реализации. Общее для них - наличие механизмов адаптации и сопровождения: системных и пользовательских настроек, возможности внесения изменения в программное обеспечение и в структуру данных, допустимость встраиваемых пользовательских функций и т.п.
Кроме встроенных программных средств, в качестве механизмов адаптации используются специализированные внешние программные инструменты (CASE-средства) [26]. У большинства из них есть существенный недостаток: сложно, а подчас невозможно использовать их на этапе сопровождения системы. Кроме того, стоимость их порой выше стоимости самого программного продукта, а для их использования нужна серьезная подготовка специалистов.
Исследования существующих технологий создания и сопровождения программных систем показывают необходимость развития новых методологий в этой области, направленных на снижение затрат за счет увеличения жизненного цикла и уменьшения трудоемкости адаптации и сопровождения. Интерес к данному вопросу в периодических публикациях [1, 14, 16, 34, 40 - 42, 52, 62, 74] и отсутствие единого подхода к решению проблемы подчеркивает актуальность выбранной темы. В диссертационной работе предлагается метод реализации систем, позволяющий устранить ряд подобных проблем.
В первой главе приводится обзор существующих тиражируемых систем и проводится анализ подходов к реализации механизмов адаптации и сопровождения.
Во второй главе приводится построение математической модели процесса создания слабо тиражируемых систем.
В третьей главе приводится вариант методологии построения слабо тиражируемых систем на основе предложенной математической модели.
Определение области исследования
В работе рассматриваются вопросы реализации слабо тиражируемых систем, решение которых должно привести к снижению совокупных затрат как разработчиков, так и заказчиков системы. Как отмечалось в разделе 1.1, самый дорогой и трудоемкий этап жизненного цикла - сопровождение. Кроме сопровождения, в рассмотрение в той или иной степени включаются этапы проектирования, разработки и тестирования.
Стоимость сопровождения складывается из множества факторов [10], важнейшими из которых можно считать качество разработки и квалификацию сопровождающего персонала. Если на квалификацию персонала разработчик практически влиять не может (максимум - провести обучение, что тоже важно), то необходимое качество разработки он обеспечить может и должен. Качество разработки оценивается по-разному. С точки зрения пользователя, оно определяется количеством и частотой ошибок, обнаруженных в системе во время эксплуатации, потерями от них, временем их исправления и устранения их последствий. С точки зрения заказчика - это цена потерь от ошибок и цена сопровождения. С точки зрения сопровождающего персонала - это качество программного кода, то есть минимум ошибок при максимально понятном коде, когда документация соответствует состоянию системы и способствует быстрой и надежной локализации ошибки. Мы видим, что все участники эксплуатации (сопровождения) системы в той или иной степени заинтересованы в минимизации ошибок, исключая случай, когда ошибки служат дополнительным источником заработка сопровождающего персонала. Однако трактовка термина «ошибка» в представлении различных участников различна, что порождает конфликты. Кроме того, хотя и реже, возникают дискуссии и по факту наличия ошибок. Крайние мнения: в системе есть хотя бы одна ошибка - значит, она никуда не годится (начинающий заказчик), в системе нет ошибок, потому что так задумано (начинающий разработчик). Уточним понятие ошибки. Согласно [51], в программе есть ошибка, если она не выполняет того, что разумно ожидать от нее пользователю. Будем считать, что разумные ожидания отражены во внешней спецификации (техническом задании). Тогда система содержит ошибку, если процесс или результат ее функционирования отличается от определенного в техническом задании. Но ввиду того, что этот документ неформален, точную идентификацию ошибки провести невозможно. Реально существует негласная договоренность между участниками, что считать ошибкой. И обычно все сводится к формулировке Конфуция: «Лишь та ошибка -что не исправляется» (цитата из [17]).
Утверждение 1.2.1. Любая отлаженная программная система содержит ошибку. Корректность этого утверждения объясняется в [17] тем, что неформальное задание спецификации не дает возможности провести формальное доказательство правильности программы. Таким образом, можно сформулировать следующие подцели для создания надежных слабо тиражируемых систем: минимизировать ошибки на любом этапе проектирования, создания и эксплуатации системы; минимизировать сроки и трудозатраты на исправление ошибок. Сроки исправления и затраты на исправление ошибок могут оказаться существенными для жизненного цикла системы, если, например, это критично для автоматизируемого технологического процесса. Характерный пример - решение проблемы 2000 года. Некоторые системы из-за невозможности ее решения или высокой совокупной стоимости ее решения заменялись аналогичными системами, в которых данная проблема была решена. Считаем, что возможность исправления ошибки существует тогда и только тогда, когда ее можно исправить в некритичный для жизненного цикла срок. Для слабо тиражируемых систем сформулируем следующее утверждение. Утверждение 1.2.2. Ошибку любого рода возможно исправить. Данное утверждение предъявляет жесткие требования к организации системы на этапах проектирования и разработки. В ней должен быть реализован механизм, позволяющий в разумные сроки исправить ошибку любого рода, в том числе ошибки анализа и проектирования. Подобные ошибки нередко возникают при тиражировании СТС, т.к. зачастую этими этапами пренебрегают, Основное количество ошибок проектирования выявляется на этапе опытной эксплуатации при работе пользователя с системой. В этом случае разработчик вынужден проводить инициированный пользователем системный анализ конкретного производства, относящегося к данной предметной области, в ходе которого много времени тратится на сбор и обработку информации, формализацию подзадачи (например, из-за разницы в терминологии), разработку, внедрение, тестирование результата. Стремление к снижению трудозатрат высококвалифицированных специалистов приводит к необходимости автоматизации рутинных операций, с одной стороны, и широкого вовлечения в создание программного обеспечения пользователя — с другой. И если первая задача решается достаточно успешно, со второй практически ничего не получается. В частности, в [48] поясняется ее неконструктивность в том виде, как она преподносится, например, в [4].
В последние годы развиваются современные программные средства разработки приложений, которые призваны решать проблемы пользователя самим пользователем. Кроме того, разработаны методики создания адаптируемых систем, которые «повернуты лицом» к пользователю. Современное направление - CASE-технологии (Computer Aided Software/System Engineering) [7, 22, 25] - призвано дать возможность проектирования программных систем без участия профессиональных разработчиков, хотя, скорее, это попытка облегчить участь профессионалов. Тем не менее, не видно, чтобы заметный слой пользователей влился в ряды создателей прикладных систем, хотя некоторые из них способны решать часть своих проблем самостоятельно. Это, как правило, лишь небольшие локальные задачи, по крайней мере, автору практически не известны какие-нибудь существенные программные проекты, реализованные пользователями. По-видимому, проблемы профессионального программирования, связанные с проектированием системы и квалифицированной ее реализацией, стоят вне сферы понятий, которыми оперирует пользователь. Профессиональный программист видит задачу шире и глубже, чем это доступно пользователю, который работает в конкретной предметной области. Разработчик программного обеспечения, в отличие от пользователя, работает с моделью предметной области, его стиль мышления при работе над проблемой существенно более абстрактный. Разный стиль мышления влечет разные подходы к проблемам программирования и подразумевает различную стратегию создания программного обеспечения. В сочетании с профессиональными знаниями и умениями это приводит к принципиальному отличию продуктов, созданных пользователем и профессиональным программистом.
Модель оценивания тиражируемости в случае легкой разработки
Вернемся к обсуждению проблемы ошибок, то есть к минимизации tE. Рассматривают ошибки разработки, ошибки проектирования и ошибки эксплуатации. Под ошибками эксплуатации будем понимать действия, производимые в системе пользователем, которые ему кажутся интуитивно логичными, например, из предыдущего опыта работы, однако не приводящие к требуемому результату. Достаточно обычна ситуация, когда для выполнения некоторого процесса дополнительно требуется выполнить предварительные действия, а система не содержит прямого указания на них. Нередко встречается ситуация, когда пользователь заявляет о несуществующей ошибке. На самом деле, с точки зрения интуитивно понятного интерфейса, это ошибка разработчика. Таким образом, на практике полностью избежать ошибок в более или менее сложной системе нельзя, можно минимизировать их количество и, что наиболее важно, минимизировать время их исправления, однако сам по себе факт наличия ошибок не свидетельствует о низком качестве разработки.
Назовем критичной ошибкой такую, без исправления которой пользователь не может выполнять требуемые технологией действия. Пусть система, соответствующая модели М, содержит и ошибок, pi - вероятность наличия в системе /-й критичной ошибки, Г( - время реакции разработчика на проявление /-й ошибки. Тогда систему назовем устойчивой, если тах(Т$ Cj(M) и устойчивой в среднем, если математическое ожидание потери времени на исправление ошибок mj= jpiTl Сг(Щ- Здесь С/(М) и Сг(М) величины, определяемые условиями среды функционирования. Первую можно назвать уровнем терпения клиента, вторую - уровнем терпения заказчика. Нарушение устойчивости приводит к чрезмерным простоям пользователя, нарушение устойчивости в среднем - к недовольству заказчика, регулярно теряющего время из-за ошибок системы.
Устойчивость системы в среднем обеспечивается минимизацией pt и Tt . Первая величина не может быть достаточно малой в силу особенностей легких методологий разработки. Следовательно, необходимо минимизировать ТІ , что приводит к удорожанию и усложнению сопровождения системы (например, к организации «горячей линии»).
Рассмотрим проблемы, возникающие при частых сменах версий системы, характерных для СТС. Пусть P=P(t) - целочисленная функция, отражающая количество учитываемых в производственной среде элементов - свойств и процессов - в момент времени t. Если P(ti) P(tz), ti ti - производственная среда развивается экстенсивно. Участок P(ti) — P(tj) — участок стабильности, который может быть двух типов; либо ничего не меняется, либо процесс модифицируется (часть свойств или процессов заменяется другими или изменяется). Во втором случае это участок интенсивного развития. Наконец, P(ti) P(t соответствует участку деградации. Это либо свертывание производства, либо его упрощение в результате перепланирования (реинжиниринга).
P(t) поставим в соответствие функцию S(t), которая отражает количество элементов модели (D[ и ]F) в момент времени t. S(t) - ступенчатая функция, S(t) P(i). Вариант S(t) P(t) мы не рассматриваем, хотя он может существовать, он обозначает, что система избыточна по сравнению с производственной средой. Дефектом версии в момент времени t будем называть величину dsp(t) = P(t) - S(t). Дефект версии тем меньше, чем больше система соответствует потребности пользователя. В идеале классические методологии разработки на момент сдачи системы to обеспечивают dsp(h) = 0, что нельзя сказать о легких методологиях. В этом случае можно говорить лишь о dsp(t) - 0 на период сопровождения системы. Ситуация усугубляется при экстенсивном развитии производственной среды. Тогда для обеспечения приемлемых эксплуатационных характеристик необходимо, чтобы S(t) возрастала быстрее P(t). Ликвидация дефекта версии технологически подобна исправлению ошибок, она так же производится за счет сопровождения.
Обеспечение устойчивости и ликвидация дефекта версии требует определенных трудозатрат. Трудозатраты могут быть определены с некоторой точностью по одной из существующих методик [61, 75]. Они вычисляются в зависимости от размера программного модуля, его сложности, связей и т.п. Единица измерения трудозатрат — человеко-месяц. T(F) - количество человеко-месяцев, необходимых для реализации функции предметной области F. Для упрощения вычислений будем считать, что общие трудозатраты на систему равны сумме трудозатрат на каждую ее функцию.
T(D) — трудоемкость разработки элемента данных D, которая тоже рассчитывается по известным методикам, ориентированным, например, на функциональные показатели, В них рассматриваются такие элементы данных, как база данных, внешний файл, логический файл. Целям нашего расчета более отвечает логический файл как представление, наиболее близкое к концептуальному.
Трудоемкость изменения рассчитать более сложно, чем трудоемкость разработки. Она существенно зависит от трудоемкости обнаружения места воздействия на код и понимания последствий изменения. Это, в свою очередь, определяется качеством кода и уровнем документируем ости.
Концептуальные принципы слабо тиражируемых систем
Качество программного обеспечения — ключевая его характеристика. Критерии качества в разное время и для разных задач были и остаются различными. Так, для управляющих систем важно время отклика, а для информационных оно не ведущая характеристика, важнее эргономичность интерфейса, несущественная для систем реального времени. Слабо тиражируемые системы объединяют множество разнородных приложений, обладающих, тем не менее, рядом схожих характеристик, не несущих черты предметной области, а относящихся к особенностям «роста и размножения». Сформулируем критерии (принципы), которым должна удовлетворять прикладная система, относящаяся к слабо тиражируемым.
Интегрируемость. Способность к интеграции в существующую для данной предметной области прикладную программную систему, а также способность включать в себя автономные прикладные системы.
Систему, в которую интегрируется данная, назовем внешней по отношению к ней. Наиболее просто данный принцип реализуется созданием единого информационного пространства для прикладных систем, участвующих в технологическом процессе. Данные, получаемые в результате работы внешних приложений, доступные для восприятия рассматриваемой системой, назовем внешними данными. Для них должен быть определен механизм обновления и проверки целостности. Процесс преобразования данных внешних систем во внешние данные желательно автоматизировать и проводить его с помощью отдельного модуля. В СТС, при необходимости, должен быть реализован механизм обмена данными с внешними системами.
Настра иваемость. Возможность реализации различных технологических вариантов предметной области без корректировки программного кода.
Настраиваемость в многофункциональной СТС реализуется на основе технологии реализации многоуровневых или объектных констант системы, возможности выбора алгоритмов обработки данных. Однако пользователю сложно работать с системой перегруженной большим количеством настроек. Поэтому, при реализации данной концепции, рекомендуется придерживаться принципа минимизации и линеаризации настроек каждого модуля. Максимально возможную часть настроек рекомендуется реализовать в консолидирующем модуле. Кроме того, рекомендуется визуализировать настройки в зависимости от уровней и прав доступа, а так же ролей пользователей в системе.
Расширяемость, Возможность корректировки программного кода системы и структуры данных в соответствии с изменениями в технологии. Расширяемость в значительной степени может быть обеспечена средствами визуального программирования, позволяющими локализовать изменяемый код, а в ряде случаев, например, при изменении интерфейса или выходных форм, вообще не затрагивать программные модули. В некоторых случаях полезно реализовать «построитель выражений», позволяющий пользователю менять обработку данных без изменения кода. Высокая степень настраиваемости предполагает интерпретацию настроечных данных в процессе работы системы. С точки зрения производительности это не всегда желательно. В этом случае лучше использовать методы генерации программного кода. Безусловно, возможно использование внешних модулей, встраиваемых в систему. Вообще, желательно реализовать любые возможные методы «быстрой расширяемости».
Актуальность, Возможность актуального отображения в системе различных изменений в технологии.
Актуальность обеспечивается механизмом замены (обновления) версий. Для слабо тиражируемых систем удобная технология замены версий чрезвычайно важна, так как она должна производиться во многих точках и преимущественно силами пользователя (сопровождающего программиста). Проведение данных работ разработчиком приводит к значительной затрате ресурсов. Наиболее ответственный этап замены версий -обновление структуры данных. Обновление программных модулей и настроек обычно достаточно простая процедура.
Данные о различных изменениях в системе хранятся в Системном Словаре Последних Изменений (ССПИ). Изменения могут вступать в силу по желанию пользователя, если ему, например, необходимо поработать со старой конфигурацией.
Для передачи изменений удобно пользоваться возможностями Интернета, размещая патчсеты на сайте. Все изменения строго датируются и сопровождаются правилами обновления, например, изменения, передаваемые патчсетом «Пд» невозможно сделать без предварительного выполнения патчсета «П».
Дружественность. Обеспечение пользователю прозрачности и интуитивной ясности реализуемого системой технологического процесса.
Дружественность обычно обеспечивается удобством пользовательского интерфейса. Вопросу его организации уделяют огромное внимание, т.к. основная причина отторжения и неприятия системы пользователем является именно некорректно организованный интерфейс. С другой стороны, в погоне за эргономикой интерфейса, нельзя забывать о том, что отдельные АРМы требуют определенной перегруженности интерфейса, оптимизация которого может негативно сказаться на производительности обработки данных и, что более важно, на корректности реализации требуемой технологии.
Надежность. Способность системы работать без критичных для автоматизируемой технологии сбоев, требующих вмешательства разработчика.
Существуют разные способы достижения надежности системы: выбор надежных СУБД, специальная обработка ошибок, защита системы от внешних угроз, организация автоматического восстановления после сбоев, реализация жестких требований к аппаратному обеспечению. Для обычной реализации лучше использовать обработку системных ошибок с накоплением данных о них и с последующим созданием процедур их автоматического исправления. Подобная информация накапливаются в Словаре Ошибок Системы (см. разд. 3.3). Пользовательские ошибки локализовать сложнее, тем не менее, в наиболее сложных и часто используемых интерфейсах используют метод «лекала», когда в специальном словаре формы описываются возможные состояния интерфейсов. Управление возможно при возникновении «знакомого» интерфейса. На практике часто применяют другой метод - метод состояний, когда «лекало» описывается в теле процедуры, реализующей данную функциональность. В этом случае, при возникновении проблем, изменении технологии ввода данных, приходится вносить изменения в программный код.
Организация процесса сопровождения слабо тиражируемых систем
Если слабо тиражируемая система организована как распределенная, следует реализовать словарь консолидирующего модуля, позволяющий управлять процессом обмена данными между функциональными модулями (АРМами) системы.
СКМ для осуществления операций по обновлению использует информацию СДС. При необходимости можно объединить эти словари в один, реализовав дополнительно журнал учета и отката обновлений и добавив в СДС соответствующие атрибуты (дата/время запроса, процедура обновления данных) для хранилищ. Если речь идет о централизованном управлении обменом информации, необходимо хранить данные о выполнения обновлений и об их откатах.
Для надежности выполнения операций следует ввести режим принятия обновлений. Для этого в СДС для обновляемых объектов добавляется статус пользователя, который может принять или откатить обновления. Если статус пользователя недостаточен для ввода или модификации данных, система будет их игнорировать. Система также игнорирует данные обновления, если принятие обновлений не подтверждено. Для реализации системы отката обновлений в соответствующие хранилища добавляются атрибут «дата/время обновления».
Проводить централизованные обновления данных не всегда удобно, и данная функция используется локально при загрузке того или иного АРМа. Тем не менее, даже в этом случае, полезно вести локальный журнал обновлений, данные которого следует передавать тем или иным способом в системный модуль. Это повышает надежность при централизованном управлении и администрировании системы. Поддерживается целостность и локализуются ошибки связанные с потерей данных. Кроме того, это позволяет делать временные срезы БД даже при локальных обновлениях функциональных модулей (АРМов).
Основная цель словаря — обеспечить полноту, целостность и сохранность данных системы [66]. Для объектов СДС вводится атрибуты, характеризующие режим архивации (оптимальный период архивации, полноту архивации, степень критичности архивации). Реализуется дополнительный журнал, который содержит сведения о процедурах архивации и успешности завершения этих процедур для каждого из хранилищ. При загрузке системного модуля администратор получает отчет о выполнении процедур архивации.
При восстановлении данных после сбоя из архива данный модуль проверяет качество архива (полноту данных). Для обеспечения корретности данных производится откат обновлений данных до соответствующей временной точки.
Для более полного контроля данных бывает полезно реализовать дополнительную проверку целостности данных. Предполагается проводить эту проверку при выполнении архивации данных для получения полноценного архива. При этом используются контрольные логические выражения, реализованные в виде дополнительного атрибута для каждого из хранилищ, описываемых в СДС. Кроме того, проводится контроль структуры данных хранилищ, в соответствии с описанием структуры. В случае успешного выполнения проверки данных, производится архивирование.
Выбор стиля контроля для модуля СКД осуществляется из соображений целесообразности и выполнимости всех процедур в определенный регламентный период. В случае невозможности проведения всех процедур в отведенный период, организуется поэтапная система архивации функциональных модулей. В этом случае, восстановление данных после сбоя из архива, как правило, проводится до минимальной даты архивного файла этапа.
Данный словарь рекомендуется реализовать для уменьшения избыточности интерфейса пользователя. В вырожденном случае словарь содержит описания масок стандартных настроек функциональных модулей. Однако, если функциональный модуль подразумевает автоматическую реакцию на события, СНС может содержать управляющую информацию, характерную для того или иного пользователя. Один и тот же функциональный модуль для разных пользователей может содержать разные режимы выполнения событий или реализовать различную реакцию на одинаковые события в зависимости от пользовательских настроек.
Централизованный словарь, содержащий пользовательские настройки, будет полезен при дальнейшей разработке и модификации СТС. На основе анализа этой информации можно получить сведения об избыточности или недостаточности пользовательского интерфейса, необходимых или избыточных сервисах. Кроме того, если в СНС хранить информацию о частоте использования того или иного элемента интерфейса или сервиса, можно проводить анализ эргономики системы.
Данный словарь несет как справочно-информативную нагрузку, так служит контролирующим модулем в части корректности изменений функционального наполнения системы. Основой словаря являются сведения о функциях системы с описанием входных и выходных параметров. Список функций для пользователей представляется в виде каталога. При реализации СФС в полном объеме описание процедур и функций системы отображаются в СДС в виде дуг А-графа хранилищ. Соответственно этому графу входные и выходные параметры для каждой функции определяются атрибутами хранилищ. Для открытой системы в случае добавления или изменения функций с помощью внешних средств потребуется их зарегистрировать в СФС.
Содержит информацию о расширении функциональности системы, относительно базовой. Предоставляет возможность обмена информацией с СФС (изменение статуса пользовательских функций и модулей на базовые),
Еще одна проблема, которая возникает при автоматизации практически любой предметной области - отсутствие взаимопонимания пользователя и разработчика, источником которого является использование различных терминов для обозначения одного и того же объекта. Кроме того, разработчик, как правило, не владеет профессиональной терминологией пользователя.
Эту проблему можно решить, модифицировав СДС. Объекты СДС расширяются за счет введения дополнительных атрибутов, отображающих профессиональное и жаргонное название объектов словаря, вплоть до атрибутов хранилищ и названий процессов.
Обеспечивается заполнение данного словаря в процессе проектирования системы и уточнения терминологии. Таким образом, пользователь может участвовать в процессе разработки и модификации системы, используя привычные термины, а разработчик получает профессиональное толкование терминов предметной области,
