Глава 19. Основные принципы разработки АИС налоговой службы
Для успешного проведения работ по разработке и совершенствованию АИС налоговой службы необходимо выработать общие принципы по:
• выбору архитектуры АИС;
• выбору методологии разработки;
• применению CASE-средств.
19.1. Выбор архитектуры АИС
АИС налоговой службы можно представить в виде совокупности программных подсистем, решающих определенный круг задач. Подсистемы состоят из взаимодействующих компонентов (рис. 19.1).

Рис. 19.1. Архитектура АИС
Архитектурой АИС называется распределение функций по ее подсистемам и компонентам, точное определение границ этих подсистем и их взаимодействия по управлению и данным, а также распределение хранения и исполнения этих подсистем и компонентов по различным ЭВМ, объединенных в локальную или глобальную вычислительную сеть.
Опыт показывает, что только изменение архитектуры АИС при прочих равных условиях может изменять в сотни раз суммарные затраты на разработку. Поэтому правильный выбор архитектуры АИС — наиболее эффективный способ снижения стоимости разработки и эксплуатации всей системы в целом.
С целью эффективного управления информационно-вычислительными ресурсами в распределенной системе в основу архитектуры АИС налоговой службы положена трехуровневая модель "клиент — сервер", известная как модель сервера приложений (Application Server — AS)(рис. 19.2).

Рис. 19.2. Модель "клиент — сервер"
Здесь компонент представления (клиент третьего уровня) обеспечивает функции ввода и отображения данных; прикладной компонент (сервер второго уровня) — прикладные функции, характерные для налоговой службы; компонент доступа к ресурсам (сервер первого уровня) — фундаментальные функции хранения и управления данными (базами данных, файловыми системами и т.п.).
Основная цель выбора такой модели — отделение компонентов, реализующих прикладные функции, которые определяются нормативно-законодательными документами по налогообложению. В случае изменения налогового законодательства корректируются только отдельные компоненты, а не вся система в целом. Это существенно позволит экономить ресурсы на модификацию АИС.
В качестве серверов используются мини-ЭВМ или "мейнфрейм", а клиентов — ПЭВМ или терминалы на рабочих местах конечных пользователей. Такая архитектура базируется на вычислительных сетях с неоднородным техническим и программным обеспечением, что предполагает соответствующую сетевую операционную систему, позволяющую осуществлять взаимодействие между операционными системами и прикладным программным обеспечением различных технических средств.
Архитектура таких распределенных интероперабельных информационных систем базируется на концепции промежуточного слоя (middleware),содержащего службы и средства поддержки глобального пространства объектов (программных компонент).
Спецификации ОМА (Object Management Architecture)— фактических международных стандартов для построения распределенных объектных систем в гетерогенных средах разработаны консорциумом Object Management Group (OMG).
ОМА состоит из четырех основных компонентов, представляющих собой спецификации различных уровней поддержки приложений:
• архитектура брокера запросов объектов (CORBA-Common Object Request Broker Architecture)устанавливает базовые механизмы взаимодействия объектов в гетерогенной сети,
• сервисы объектов (Object services)являются основными системными службами, используемыми разработчиками для создания приложений;
• универсальные средства (Common Facilities)ориентированы на поддержку пользовательских приложений, таких, как электронная почта, средства печати и т.п..
• объекты приложений (Application Objects) предназначены для решения конкретных прикладных задач.
Спецификация CORBAопределяет механизм, обеспечивающий взаимодействие приложений в распределенной среде. Концептуально CORBA относится к уровням приложений и представлений семиуровневой модели сетевого взаимодействия. Она обеспечивает возможность построения распределенных систем и приложений на самом высоком уровне абстракции в рамках международных стандартов. С ее помощью возможно изолировать клиентские программы от низкоуровневых и гетерогенных характеристик информационных систем.
Главные компоненты стандарта CORBA (рис. 19.3):
• обработчик объектных заявок (Object Request Broker);

Рис. 18.З. Структура интерфейсов
• язык определения интерфейсов (Interface Definition Language),с помощью которого могут быть определены операции для обращения клиентов к серверным объектам;
• объектный адаптер (Object adapter),который предоставляет доступ к сервисам объектного обработчика и обеспечивает все низкоуровневые средства для связи объекта с его клиентами;
• репозиторий интерфейсов (Interface Repository),представляющий собой средство для хранения и обработки информации, необходимой для описания интерфейсов CORBA-объектов.
Характерные особенности разработки приложений по технологии CORBAзаключаются в следующем:
• язык описания интерфейсов OMG IDLпозволяетопределить интерфейс, не зависимый от языка программирования, используемого для реализации;
• высокий уровень абстракции CORBA в семиуровневой модели OSIпозволяет программисту не работать с низкоуровневыми протоколами;
• программисту не требуется информация о реальном месте расположения сервера и способе его активации;
• разработка клиентской программы не зависит от серверной операционной системы и аппаратной платформы;
• после модификации возможно использовать ранее разработанные приложения.
19.2. Методология разработки
Для упорядочения и регламентации процесса разработки сложных АИС ис пользуют модель жизненного цикла (МЖЦ) программного обеспечения, которая представляет собой логически связанную последовательность основных этапов развития АИС — от появления обоснованной необходимости (предложений) ее создания до отказа от ее использования или коренной реконструкции в соответствии с новыми возможностями технических и программных средств или требованиями времени.
Каждый этап МЖЦ определяется характерными для нее решаемыми задачами, исходными и результирующими спецификациями, применяемыми методами решения поставленных задач. На каждом этапе в соответствии с решаемыми задачами применяются определенная методология и инструментальные средства. Наиболее общие этапы МЖЦ АИС с характерными решаемыми задачами — анализ, проектирование, кодирование, тестирование и отладка, эксплуатация и сопровождение, устаревание.
Основные особенности МЖЦ АИС — отсутствие четко деюрминированных границ между соседними состояниями системы и ее статичность. Первая особенность означает, что начало и конец каждого этапа жизненного цикла накладываются один на другой и не могут быть точно определены во времени. Вторая связана с тем, что МЖЦ представляет собой некое "застывшее" отображение реального процесса, задающее в явном виде только перечень и логическую последовательность состояний АИС.
Последнее состояние в процессе разработки АИС представляет собой готовую систему. Любой способ перевода проекта в новое состояние реализуется посредством выполнения определенного множества проектных процедур.
Методология составляет основу для проектирования и разработки прикладных систем. Она задает определенную последовательность проектных процедур. И если тщательно соблюдать ее, то с большой вероятностью в итоге получится хорошо работающее приложение. Методологии разработки благодаря ясному общему представлению помогают охватить все важные шаги или элементы, которые необходимо надлежащим образом учитывать.
Главное достоинство использования методологий разработки заключается в том, что они обеспечивают предсказуемость результатов и контроль и позволяют разработчикам координировать свои действия.
Методология представляет собой тесно связанные, предписанные конкретные последовательности шагов; конкретные данные, подлежащие накоплению на каждой стадии; критерии завершения работ в контрольных точках; решения, которые нужно принять перед выбором между альтернативами проектирования; конкретные поименованные стандарты и другие детали, которые могут появится при построении приложений.
Методологии можно разделить на два класса по заложенному в них принципу декомпозиции — деления сложной системы на менее сложные подсистемы:
1. Структурные методологии. Реализуют принцип алгоритмической декомпозиции: АИС делится на модули, каждый из которых реализует некоторую часть общего технологического процесса. Наиболее известны и распространены:
• методология структурного анализа и проектирования Росса (SADT (Structured Analysis and design Technique), Ross);
• методологии, использующие в качестве центрального метода моделирование потоков данных: Гейн/Сарсон (Gane/Sarson),ДеМарко (DeMarco), Йордон (Yourdon);
•методологии моделирования данных: Варнье/Орр (Warnier/Orr), ER-моделирование Чена (Chen).
2. Объектно-ориентированные методологии. Реализуют принципы объектной декомпозиции: АИС представляет собой совокупность взаимодействующих объектов, которые соответствуют словарю предметной области. Наиболее известны и распространены объектные методологии следующих авторов:
• Буч (Booch);
• Рамбо (Rumbaugh, OMT);
• Шлеер/Меллор (ShIaer/Mellor);
• Код/Иордон (Coad/Yourdon);
• Универсальный язык моделирования (Unified Modeling Language — UML).
Последний получает все большее распространение и становится фактически международным стандартом.
Результатом использования этих методологий на каждом этапе является построение набора моделей — графических спецификаций, которые содержат наглядные описания различных аспектов разрабатываемых прикладных систем. Фрагменты моделей приведены в приложениях 2.1—2.4.
Например, последовательность проектных процедур при использовании методологии объектно-ориентированного анализа Шлеера/Меллора выглядит следующим образом:
1. Разбиение предметной области на домены — совокупности объектов в одной предметной области и установление взаимодействия между ними. Если домен содержит много объектов, то он разбивается на более мелкие совокупности объектов — подсистемы. Каждый домен или подсистема анализируется в три этапа:
• информационное моделирование;
• моделирование состояний;
• моделирование процессов.
2. Построение информационной модели каждого домена или подсистемы. Строится модель “сущность — связь” (ER-модель), В результате моделирования получают описание объектов домена, их атрибутов (свойств) и связей между ними.
3. Исследование поведения объектов и связей между ними во времени. Строятся модели состояний каждого объекта, модель взаимодействия объектов, список событий, таблица процессов состояний.
4. Создание для каждого состояния каждой модели состояний отдельной диаграммы потоков данных действий (ДПДД). В диаграмме ДПДД каждое действие определяется в терминах процессов и архивов данных объектов, где процесс является фундаментальной операцией, а архив данных объекта соответствует атрибутам объекта информационной модели.
5. Создание модели доступа к объектам, описывающей межобъектный доступ к данным. Модель разрабатывается в том случае, если процессы действий должны иметь доступ как к данным объекта, в модель которого они входят, так и к данным других объектов.
6. Создание отдельного описания процесса для каждого сложного процесса действий.
Результатом проведения анализа по методологии Шлеера/Меллора являются спецификации требований, которые содержат абстрактные объекты (классы), их представителей (объекты реального мира), внутреннюю структуру объектов, операции над объектами и их взаимодействия.
При разработке таких сложных и уникальных проектов, как АИС налоговой службы, необходимо использовать методологии обоих классов, так как алгоритмическая декомпозиция концентрирует внимание на порядке происходящих событий, а объектная декомпозиция придает особое значение факторам, либо вызывающим действия, либо являющимся объектами приложения этих действий.
В качестве базового подхода для разработки АИС налоговой службы следует выбрать объектно-ориентированный подход. Это позволит, во-первых, лучше спроектировать архитектуру АИС, во-вторых, даст возможность создать прикладные системы меньшего размера путем использования общих механизмов, что существенно снижает издержки на разработку и сопровождение. Кроме того, объектный подход благодаря заложенным в нем механизмам уменьшает риск создания сверхсложных прикладных систем и предполагает эволюционный путь развития информационной системы на базе небольших подсистем.
Объекту присущи три основных свойства (механизма):
• инкапсуляция — объекты наделяются некоторой структурой и обладают определенным набором операций, т. е. поведением. Операции, принадлежащие данному объекту, образуют его методы. Внутренняя структура объекта скрыта от пользователя; манипуляция объектом, изменение его состояния возможны лишь посредством его методов. Таким образом,
благодаря инкапсуляции объекты можно рассматривать как самостоятельные сущности, отделенные от внешнего мира. Для того чтобы объект произвел некоторое действие, ему необходимо извне послать сообщение, которое инициирует выполнение нужного метода;
•наследование — возможность создавать из объектов новые объекты, которые унаследуют структуру и поведение своих предшественников, добавляя им черты, отражающие их собственную индивидуальность;
• полиморфизм — различные объекты могут получать одинаковые сообщения, но реагировать на них по-разному, в соответствии с тем, как реализованы у них методы, реагирующие на сообщения.
19.3. CASE-средства
Для автоматизированной поддержки всех этапов разработки АИС используются CASE-средства (CASE — Computer Aided System/Software Engineering). Целесообразность применения CASE-средств определяется возможностью концентрации сложности на начальных этапах разработки при относительно невысокой сложности и трудоемкости последующих этапов. Это достигается за счет более точного учета требований к создаваемой АИС, значительным снижением уровня системных ошибок в проекте до начала реализации и тем самым снижением общей трудоемкости разработки.
Применение CASE-средств при разработке ИС дает следующие преимущества:
• сокращение сроков и затрат за счет автоматизации операций проектирования и кодирования, сведения к минимуму перепроектирования;
• улучшение качества проекта в результате применения современных методов проектирования, формализации проекта, его автоматизированной
верификации;
• обеспечение согласованности и полноты документации проекта;
• возможность повторного использования проекта для новых ИС.
Ключевыми характеристиками CASEявляются:
1. Сквозная поддержка всех этапов разработки АИС. Разработка ИС с помощью CASE-средств — это полуавтоматизированное преобразование начальных моделей системы к ее реализации.
2. Поддержка визуальных методов разработки. В основе CASE-средств лежат методологии, которые дают строгое и наглядное описание системы, начиная с первых шагов ее проектирования. Различные группы специалистов (аналитиков, проектировщиков, программистов и т.п.) получают единый язык для описания системы — строгий и наглядный. Широко используется графика — исчерпывающие и согласованные диаграммы, поддерживаемые детальными текстовыми материалами, которые в большинстве являются ссылками, а не основной частью спецификаций. Обеспечивается адекватная и согласованная структуризация АИС. Отдельные части спецификаций могут получаться независимо от других частей.
3. Автоматизация кодирования. Значительная доля затрат при разработке ИС связана с кодированием, т. е. с написанием текстов программ, компиляцией и отладкой. Если считать, что все принципиальные вопросы решены при проектировании до написания программ, то большая часть кодирования связана с рутинными операциями. CASE-технология предусматривает автоматизацию такого рутинного кодирования (автоматическая кодогенерация) на базе спецификаций и проектных описаний будущей системы, также получаемых с помощью CASE-средств. В результате автоматической кодогенерации получают скелетные коды, содержащие описания данных и основную логику обработки, схемы баз данных, файлы-описания интерфейсов и др. Такие коды получают в виде текстов исходного языка, требующих уточнений, связанных, как правило, с особенностями среды реализации, либо в виде модулей, готовых к комплексированию и исполнению. В некоторых случаях автоматическая кодогенерация дает до 90% кодов.
4. Поддержка единой базы проекта — репозитария. Вся информация о разрабатываемой АИС автоматически помещается в единую базу данных проекта в процессе интерактивного взаимодействия разработчиков с CASE-системой, которая поддерживает согласованность, непротиворечивость, полноту, и минимальную избыточность проекта, а также корректность операций его редактирования. База данных проекта находится всегда в актуальном состоянии. Обеспечивается минимальная избыточность — изменения пользовательских требовании могут быть учтены путем внесения изменений только в одном месте.
5. Поддержка одновременной работы группы разработчиков. CASE-система обеспечивает разные группы специалистов адекватным инструментарием, а также согласованное и корректное внесение изменений в проект специалистами в реальном времени.
6. Информационное обеспечение разработчиков. Все специалисты получают (санкционированный) доступ ко всему проекту в реальном времени и могут непосредственно использовать информацию, хранящуюся в базе данных проекта, для порождения новых или модификации существующих решений. CASE-система выдает специалистам разнообразные отчеты по проекту в виде экранных или печатных форм.
7. Документирование проекта. Документация перестает быть единственным хранилищем информации о проекте. CASE-система генерирует непротиворечивую документацию, в большей степени готовую к использованию.
CASE-средства делятся на два класса:
• отдельные инструментальные средства предназначены для автоматизации разработки АИС на отдельных этапах: CASEверхнего уровня поддерживают этапы анализа и проектирования, CASEнижнего уровня — этапы кодирования и тестирования;
• интегрированные системы поддерживают разработку АИС на всех этапах.
Выбор того или иного CASE-средства зависит от множества причин и предпочтений, однако в конечном счете он определяется уровнем проектируемых информационных систем. Для разработки АИС налоговой службы требуются адекватные ее сложности CASE-средства. Однако при всем многообразии существующих CASE-средств часто бывает трудно найти такой программный продукт, который в полной мере удовлетворял бы всем необходимым требованиям. В этом случае хорошим решением может быть использование продуманной комбинации CASE-средств разного уровня и назначения с возможностью взаимного экспорта/импорта проектов.