Красина Ф.А. Автоматизированная обработка налоговой информации

Подождите немного. Документ загружается.

Например, последовательность проектных процедур при использо-

вании методологии объектно-ориентированного анализа Шлеера/Меллора

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

1. Разбиение предметной области на домены – совокупности объек-

тов в одной предметной области и установление взаимодействия между

ними. Если домен содержит много объектов, то он разбивается на более

мелкие совокупности объектов – подсистемы. Каждый домен или подсис-

тема анализируется в три этапа:

• информационное моделирование;

• моделирование состояний;

• моделирование процессов.

2. Построение информационной модели каждого домена или подсис-

темы. Строится модель «сущность–связь» (ЕН-модель). В результате мо-

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

и связей между ними.

3. Исследование поведения объектов и связей между ними во време-

ни. Строятся модели состояний каждого объекта, модель взаимодействия

объектов, список событий, таблица процессов состояний.

4. Создание для каждого состояния каждой модели состояний от-

дельной диаграммы потоков данных действий (ДПДД). В диаграмме

ДПДД каждое действие определяется в терминах процессов и архивов

данных объектов, где процесс является фундаментальной операцией, а ар-

хив данных объекта соответствует атрибутам объекта информационной

модели.

5. Создание модели доступа к объектам, описывающей межобъект-

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

сы действий должны иметь доступ как к данным объекта, в модель которо-

го они входят, так и к данным других объектов.

6. Создание отдельного описания процесса для каждого сложного

процесса действий.

Результатом проведения анализа по методологии Шлеера/Меллора

являются спецификации требований, которые содержат абстрактные объ-

екты (классы), их представителей (объекты реального мира), внутреннюю

структуру объектов, операции над объектами и их взаимодействия.

При разработке таких сложных и уникальных проектов, как АИС на-

логовой службы, необходимо использовать методологии обоих классов,

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

ке происходящих событий, а объектная декомпозиция придает особое зна-

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

ми приложения этих действий.

В качестве базового подхода для разработки АИС налоговой службы

следует выбрать объектно-ориентированный подход. Это позволит, во-

первых, лучше спроектировать архитектуру АИС, во-вторых, даст возмож-

ность создать прикладные системы меньшего размера путем использова-

ния общих механизмов, что существенно снижает издержки на разработку

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

нем механизмам уменьшает риск создания сверхсложных прикладных сис-

тем и предполагает эволюционный путь развития информационной систе-

мы на базе небольших подсистем.

Объекту присущи три основных свойства (механизма):

• инкапсуляция – объекты наделяются некоторой структурой и обла-

дают определенным набором операций, т.е. поведением. Операции, при-

надлежащие данному объекту, образуют его методы. Внутренняя структу-

ра объекта скрыта от пользователя; манипуляция объектом, изменение его

состояния возможны лишь посредством его методов. Таким образом, бла-

годаря инкапсуляции объекты можно рассматривать как самостоятельные

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

некоторое действие, ему необходимо извне послать сообщение, которое

инициирует выполнение нужного метода;

• наследование – возможность создавать из объектов новые объекты,

которые унаследуют структуру и поведение своих предшественников, до-

бавляя им черты, отражающие их собственную индивидуальность;

• полиморфизм – различные объекты могут получать одинаковые со-

общения, но реагировать на них по-разному в соответствии с тем, как реа-

лизованы у них методы, реагирующие на сообщения.

3.2 САSЕ-средства

Для автоматизированной поддержки всех этапов разработки АИС

используются CASE-средства (CASE-Computer Aided System / Software

Engineering). Целесообразность применения САSЕ-средств определяется

возможностью концентрации сложности на начальных этапах разработки

при относительно невысокой сложности и трудоемкости последующих

этапов. Это достигается более точным учетом требований к создаваемой

АИС, значительным снижением уровня системных ошибок в проекте до

начала реализации и тем самым снижением общей трудоемкости разработ-

ки.

Применение CASE-средств при разработке ИС дает следующие пре-

имущества:

• сокращение сроков и затрат за счет автоматизации операций проек-

тирования и кодирования, сведения к минимуму перепроектирования;

• улучшение качества проекта в результате применения современных

методов проектирования, формализации проекта, его автоматизированной

верификации;

• обеспечение согласованности и полноты документации проекта;

• возможность повторного использования проекта для новых ИС.

Ключевыми характеристиками САЗЕ являются:

1. Сквозная поддержка всех этапов разработки АИС. Разработка ИС

с помощью CASE-средств – это полуавтоматизированное преобразование

начальных моделей системы к ее реализации.

2. Поддержка визуальных методов разработки. В основе CASE-

средств лежат методологии, которые дают строгое и наглядное описание

системы, начиная с первых шагов ее проектирования. Различные группы

специалистов (аналитиков, проектировщиков, программистов и т.п.) полу-

чают единый язык для описания системы – строгий и наглядный. Широко

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

держиваемые детальными текстовыми материалами, которые в большин-

стве являются ссылками, а не основной частью спецификаций. Обеспечи-

вается адекватная и согласованная структуризация АИС. Отдельные части

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

3. Автоматизация кодирования. Значительная доля затрат при раз-

работке ИС связана с кодированием, т.е. с написанием текстов программ,

компиляцией и отладкой. Если считать, что все принципиальные вопросы

решены при проектировании до написания программ, то большая часть

кодирования связана с рутинными операциями. CASE-технология преду-

сматривает автоматизацию такого рутинного кодирования (автоматическая

кодогенерация) на базе спецификаций и проектных описаний будущей

системы, также получаемых с помощью CASE-средств. В результате авто-

матической кодогенерации получают скелетные коды, содержащие описа-

ния данных и основную логику обработки, схемы баз данных, файлы-

описания интерфейсов и др. Такие коды получают в виде текстов исход-

ного языка, требующих уточнений, связанных, как правило, с особенно-

стями среды реализации, либо в виде модулей, готовых к комплексирова-

нию и исполнению. В некоторых случаях автоматическая кодогенерация

дает до 90% кодов.

4. Поддержка единой базы проекта-репозитария. Вся информация о

разрабатываемой АИС автоматически помещается в единую базу данных

проекта в процессе интерактивного взаимодействия разработчиков с

CASE-системой, которая поддерживает согласованность, непротиворечи-

вость, полноту и минимальную избыточность проекта, а также коррект-

ность операций его редактирования. База данных проекта находится всегда

в актуальном состоянии. Обеспечивается минимальная избыточность – из-

менения пользовательских требований могут быть учтены внесением из-

менений только в одном месте.

5. Поддержка одновременной работы группы разработчиков. CASE-

система обеспечивает разные группы специалистов адекватным инстру-

ментарием, а также согласованное и корректное внесение изменений в

проект специалистами в реальном времени.

6. Информационное обеспечение разработчиков. Все специалисты

получают (санкционированный) доступ ко всему проекту в реальном вре-

мени и могут непосредственно использовать информацию, хранящуюся в

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

вующих решений. CASE-система выдает специалистам разнообразные от-

четы по проекту в виде экранных или печатных форм.

7. Документирование проекта. Документация перестает быть един-

ственным хранилищем информации о проекте. CASE-система генерирует

непротиворечивую документацию, в большей степени готовую к исполь-

зованию.

CASE-средства делятся на два класса:

• отдельные инструментальные средства предназначены для автома-

тизации разработки АИС на разных этапах: CASE верхнего уровня под-

держивают этапы анализа и проектирования, CASE нижнего уровня – эта-

пы кодирования и тестирования;

• интегрированные системы поддерживают разработку АИС на всех

этапах.

Выбор того или иного CASE-средства зависит от множества причин

и предпочтений, однако в конечном счете он определяется уровнем проек-

тируемых информационных систем. Для разработки АИС налоговой служ-

бы требуются адекватные ее сложности CASE-средства. Однако при всем

многообразии существующих CASE-средств часто бывает трудно найти

такой программный продукт, который в полной мере удовлетворял бы

всем необходимым требованиям. В этом случае хорошим решением может

быть использование продуманной комбинации CASE-средств разного

уровня и назначения с возможностью взаимного экспорта/импорта проек-

тов.

Глава 4. ОСНОВНЫЕ ТЕХНИЧЕСКИЕ РЕШЕНИЯ

ПО ПОСТРОЕНИЮ АИС

4.1 Общие принципы построения АИС

Налоговая система (на районном, региональном и федеральном

уровнях) представляет собой многопрофильную распределенную структу-

ру с частично децентрализованным управлением.

Для описания таких систем используется представление АИС как

комбинации подсистем прикладной функциональности, реализующих ре-

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

турных подсистем, обеспечивающих функционирование прикладных задач

путем выделения необходимых ресурсов, сервисов и служебных подсис-

тем, связывающих прикладные и инфраструктурные подсистемы для при-

дания им определенных свойств (рис. 4.1).

Рис. 4.1 − Архитектура информационной системы

Каждая группа подсистем имеет ряд общих свойств. Так, приклад-

ные подсистемы сильно зависят от специфики задач организации и ее це-

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

ганизации. Требования к прикладным подсистемам выдвигаются специа-

листами из различных прикладных областей и могут быть противоречи-

выми. В то же время инфраструктурные подсистемы являются основой для

интеграции прикладных подсистем, определяя основные свойства, необхо-

димые для успешной эксплуатации АИС. Требования к инфраструктурным

подсистемам едины и стандартизованы, методы построения в значитель-

ной степени универсальны.

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

структурные, в силу своей зависимости от организационно-управлен-

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

зе. В отличие от нее, инфраструктура как существенно более дорогостоя-

щая часть АИС должна создаваться с максимально возможным сохранени-

ем уже сделанных инвестиций.

Одним из основных принципов создания АИС является преемствен-

ность уже имеющихся систем. Прежде всего это относится к весьма раз-

нородным и многочисленным информационным системам всех уровней

налоговой службы, одним из путей реализации упомянутого принципа яв-

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

ного обмена. Создание такой инфраструктуры позволит адаптировать вы-

ходную информацию уже имеющихся информационных систем, а значит,

и откроет пути к их интеграции в АИС.

Использование универсальной инфраструктуры информационного

обмена позволяет избежать неэффективного использования либо дублиро-

вания ресурсов, организовать единую модель доступа к ресурсам, распре-

деленное управление системой и мониторинг ее компонентов, своевремен-

ную диагностику возникающих проблем.

4.2 Архитектура прикладных решений

При проектировании прикладных решений целесообразно использо-

вать концепцию прикладных сервисов. Под прикладным сервисом подра-

зумевается замкнутый набор взаимосвязанных функций, в совокупности

реализующих какую-либо прикладную подзадачу.

Архитектура прикладных решений (автоматизации предметной дея-

тельности в АИС инспекции) предусматривает в общем пять подсистем

прикладного программного обеспечения:

• учета и контроля;

• аналитическая;

• информационно-справочная;

• технологическая (проводит проверку поступившей информации и

обновляет внутреннюю базу данных АИС инспекции);

• генерации рабочих мест. Предназначена для создания новых АРМ

путем настройки ППО и конфигурации интерфейсов пользователей к

ППО.

Для обеспечения работоспособности перечисленных подсистем ис-

пользуются следующие информационные ресурсы:

• информационные массивы, поступающие из внешних источников

(в том числе и из районных органов);

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

ции, поступающей из различных источников;

• внутренняя база данных АИС инспекции.

4.3 Системно-техническая инфраструктура

Системно-техническая инфраструктура обеспечивает работу прило-

жений, предоставляя необходимые основные и служебные сервисы. С сис-

темно-технической точки зрения инфраструктура строится на нескольких

взаимосвязанных уровнях:

• инженерная инфраструктура (структурированные сети, система

бесперебойного питания),

• подсистема телекоммуникаций, локальные сети,

• серверные платформы и общесистемное ПО, ПО промежуточного

слоя,

• подсистема клиентских мест и автоматизированных рабочих мест

(АРМ), система приложений.

Каждый из перечисленных уровней реализуется в соответствии с ор-

ганизационной структурой инспекции. Структуры одного уровня иерархии

образуют раздельные информационные сегменты, которые взаимодейст-

вуют с корпоративными службами инспекции.

Потоки между информационными сегментами локализуются и могут

обрабатываться средствами защиты информации и управления. Сегменти-

рование также позволяет оптимизировать информационные потоки и на-

грузку на корпоративные службы.

Архитектура системно-технических компонентов на разных уровнях

должна удовлетворять следующим требованиям:

• достижение максимальной индивидуальной и корпоративной про-

изводительности обработки информации;

• управляемость системно-технической структуры, причем управле-

ние информационными ресурсами должно быть централизованным и мак-

симально автоматизированным;

• использование минимального числа протоколов процессами ин-

формационного обмена;

• минимальные требования к приложениям, обеспечивающим при-

кладную функциональность системы;

• поддержание возможности контроля работы приложений как в

процессе разработки, так и в процессе эксплуатации;

• использование единой модели доступа к ресурсам.

Чтобы приведенные требования были реализованы, архитектура сис-

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

ми принципами:

• локализация нагрузок в распределенной информационной системе

вблизи пользователей,

• децентрализация обработки информации при максимальной цен-

трализации управления информационными ресурсами и контроля техноло-

гических процессов,

• разграничение функциональности серверов, их максимальная спе-

циализация,

• применение стандартов открытых систем для интеграции разно-

родного оборудования и программного обеспечения,

• организация разграничения доступа как на основе информации о

пользователях и процессах, так и на основе информации о ресурсах,

• однородность и масштабируемость применяемых решений, апро-

бированность их.

Создание системно-технической инфраструктуры предполагает реа-

лизацию указанных принципов на основе архитектуры клиент–сервер с не-

сколькими промежуточными уровнями.

4.4 Архитектура служебных подсистем

Служебные подсистемы функционируют на компонентах АИС и

обеспечивают заданные свойства всей системы. Такими свойствами явля-

ются управляемость и защищенность, в соответствии с чем формируется

подсистема управления и подсистема безопасности АИС налоговой ин-

спекции.

Особенность служебных подсистем – их обязательная согласован-

ность с управленческими решениями, принятыми в налоговой службе (по-

литика управления и политика безопасности). Это в свою очередь требует

проработки не только программно-технических решений, но и организаци-

онно-процедурных мер.

При создании подсистем управления и безопасности необходимо

следовать ряду требований:

• невозможность отключения служебных подсистем в результате

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

• невозможность перехода АИС и ее компонентов в неконтролируе-

мое состояние;

• разделение обязанностей всех пользователей АИС, минимизация

их привилегий в системе;

• наличие нескольких рубежей защиты и точек контроля системы;

• разнообразие применяемых средств в зависимости от значимости

ресурсов и уровня системно-технической инфраструктуры;

• простота работы служебных подсистем.

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

ны на модели менеджер/агент, описанной в стандартах сетевого управле-

ния Международной Организации по Стандартам (ISO). В рамках этой мо-

дели имеются приложения–агенты, размещенные в ключевых точках

управляемого распределенного объекта. Агенты образуют нижний уровень

иерархической подсистемы управления или безопасности. Агент следит за

состоянием информационного ресурса и формирует мгновенное и/или ис-

торическое количественное представление состояния ресурса. Пользовате-

лями этой информации являются приложения-менеджеры, взаимодейст-

вующие с агентами. Данная модель является частной реализацией системы

типа «клиент-сервер», в которой агент выполняет, как правило, роль сер-

вера, а менеджер – роль клиента.

Служебные приложения не только управляют ресурсами, но и ис-

пользуют их. Следовательно, важно учитывать, насколько компоненты

служебных подсистем управления эффективно используют сетевые ресур-

сы, память, дисковое пространство управляемых объектов и т.п. Архитек-

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

решение, поскольку предлагает уровни управления, включая коммуника-

ции типа менеджер–менеджер и/или интеллектуальных агентов, которые

позволяют делегировать функции управления на уровень управляемого ре-

сурса.

4.5 Подсистемы автоматизации предметной деятельности

Подсистемы автоматизации предметной деятельности, как правило,

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

• ввод (ввод данных в подсистему, рис. 4.3). При вводе информации

в любую из перечисленных подсистем происходят процесс идентификации

и начальная обработка данных;

• хранение данных (в базе данных подсистем). После ввода инфор-

мации в подсистему происходит сохранение полученных данных в инфор-

мационных хранилищах (базах данных, рис. 4.2);

• поиск (поиск информации в базе данных подсистемы по критерию,

сформированному пользователем);

• отчеты (получение отчетов на основании отобранных данных и по

заранее заданному шаблону, рис. 4.4);

• справка (получение справочной информации, рис. 4.4);

• настройка (адаптация работы подсистемы в связи с изменяющи-

мися условиями эксплуатации). Настройка подсистем производится сред-

ствами подсистемы генерации автоматизированных рабочих мест.

Рис. 4.3 − Входные потоки данных для ППО АИС региональной инспекции