Подсистема "Налогообложение" интегрированной информационной системы Департамента управления имуществом городского округа Самара

Размещено на http://www.allbest.ru/

Министерство образования и науки РФ

ФГБОУ ВПО «Самарский государственный архитектурно-строительный университет»

Факультет информационных систем и технологий

Кафедра прикладной математики и вычислительной техники

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

на тему: Подсистема «Налогообложение» интегрированной информационной системы Департамента управления имуществом городского округа Самара

СТУДЕНТА

ХОБОТОВА А.А.

Самара 2013 г

РЕФЕРАТ

Дипломный проект.

Пояснительная записка: 142 страниц, 26 рисунков, 7 таблиц, 28 источников, 3 приложения.

Графическая часть: 8л, А4

ДОКУМЕНТООБОРОТ, ИНФОРМАЦИОННАЯ СИСТЕМА, ДОКУМЕНТ, СЭД.

В результате работы спроектирована и реализована система, в которой есть возможность ведения базы данных налоговых записей и получения отчётов по различным параметрам, а также возможность ведения справочников в режиме доступном обычному пользователю. Также возможен импорт реестров физических и юридических лиц в базу данных ИС. Произведен выбор и обоснование комплекса технических и программных средств на основе ресурсных расчетов по исходным данным. UML-проект системы создан с использованием case-средства SoftwareIdeasModeler. Система реализована на языке программированияC#/Silverlight в среде VisualStudio 2010Premium. Проект находится на стадии внедрения, что доказывает акт внедерения. Проводится тестирование в пробный период; два первых квартала 2013 года.

СОДЕРЖАНИЕ

1. СИСТЕМОТЕХНИЧЕСКАЯ ЧАСТЬ

1.1 Описание и анализ предметной области

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

1.3 Разработка модели анализа проектируемой системы

1.4 Разработка логической модели базы данных

1.5 Оценка требуемых параметров комплекса технических средств

2. КОНСТРУКТОРСКО-ТЕХНОЛОГИЧЕСКАЯ ЧАСТЬ

2.1 Выбор и обоснование архитектуры системы

2.2 Выбор и обоснование средств комплекса программно-технических средств

2.3 Диаграммы поведения

2.4 Разработка физической модели базы данных

2.5 Описание реализации системы

2.6 Диаграмма компонентов (Components Diagram)

2.7 Диаграмма развертывания (Deployment Diagram)

2.8 Описание интерфейсных решений

2.9 Разработка программы и методики испытаний

2.10 Описание контрольного примера

2.11 Разработка руководства пользователя

3. ТЕХНИКО-ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ РАЗРАБОТКИ ИНФОРМАЦИОННОЙ СИСТЕМЫ

3.1 Краткая характеристика работы и ее назначение

3.2 Расчет затрат на разработку информационной системы

3.3 Расчет минимальной цены разработки ИС

3.4 Расчет единовременных затрат на внедрение ИС

3.5 Расчет текущих затрат на функционирование ИС

3.6 Расчёт экономического эффекта от внедрения подсистемы «Налогообложения» интегрированной информационной системы ДУИ

4. РАЗРАБОТКА МЕРОПРИЯТИЙ ПО БЕЗОПАСНЫМ УСЛОВИЯМ ТРУДА

4.1 Общие положения

4.2 Требования к производственным помещениям для работы с ПЭМВ

4.3 Требования к освещению рабочих мест

4.4 Оптимальные параметры микроклимата

4.5 Требования к уровням шума и вибрации

4.6 Требования к уровням электромагнитных полей, создаваемых ПЭВМ на рабочих местах

4.7 Общие требования к организации рабочих мест пользователя

ЗАКЛЮЧЕНИЕ

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

ПРИЛОЖЕНИЕ

ВВЕДЕНИЕ

На сегодняшний день необходимость автоматизировать работу всех государственных учреждений и обслуживающих население комитетов ни у кого не вызывает сомнений. Канули в Лету времена, когда для получения сведений о собственности, её собственниках и обременениях, хватало одного звонка или предоставления одного документа или справки. Разделение правительственных ведомств по множественным департаментам усложнило процесс обмена и работы с общими данными. Теперь одни ведомственные комитеты вынуждены запрашивать данные для работы у других комитетов и ждать от них ответов, в виде почтовых или электронных отправлений, трудно обрабатываемых вручную.

Для поддержания быстрых связных пунктов, в России в 1997 году появилась первая система электронного документооборота «OPTIMA-WorkFlow». Все ресурсы для совместного использования согласно архитектуре располагались на шине серверов баз данныхи раскладывались в разные таблицы в зависимости от категорий (количество категорий равно количеству таблиц). Такая картотека была доступная клиентским компьютерам, объединённым в сеть, где использовалась операторами для формирования документации, включающей данные разных ведомств.

Теоретически система «OPTIMA-WorkFlow» казалась идеальной, но ее практическое исполнение оставляло желать лучшего. Нередко действовал так называемый человеческий фактор - операторы ошибались в процессе формирования документов или зачастую пренебрегали целостностью данных.

В то же время правила формирования документов усложнялись, к ним стали предъявлять все более жесткие требования. Просто предоставляющая информацию система постепенно изжила себя, тогда на смену ей пришли первые интегрированные системы документооборота, которые абсолютно и однозначно связывали данные разных ведомств.

По настоящий момент такие системы активно развиваются, появляются новые программные комплексы. Однако все подобные системы действуют в соответствии с государственным регламентом и довольно ограничены функционально, а мощные узкоспециализированные системы внедрять дорого. Цель дипломного проекта в создании надежной подсистемы, обеспечивающей взаимодействие узкого профиля и реализующей дружественный пользователю интерфейс.

1. СИСТЕМОТЕХНИЧЕСКАЯ ЧАСТЬ

1.1 Описание и анализ предметной области

Документооборот -- движение документов в организации с момента их создания или получения до завершения исполнения или отправления; комплекс работ с документами: приём, регистрация, рассылка, контроль исполнения, формирование дел, хранение и повторное использование документации, справочная работа [2].

Электронный документооборот (ЭДО) -- единый механизм по работе с документами, представленными в электронном виде, с реализацией концепции «безбумажного делопроизводства» [2].

Электронный документ (ЭД) -- документ, созданный с помощью средств компьютерной обработки информации, который может быть подписан электронной подписью (ЭП) и сохранён на машинном носителе в виде файла соответствующего формата [2].

Системы электронного документооборота (СЭД) - технические информационные системы и программные комплексы, призванные автоматизировать процесс обмена бумажными документами как внутри одной организации, так и между несколькими организациями, осуществляющими взаимодействие с бумажными документами [3].

Основные принципы электронного документооборота:

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

Возможность параллельного выполнения операций, позволяющая сократить время движения документов и повышения оперативности их исполнения

Непрерывность движения документа, позволяющая идентифицировать ответственного за исполнение документа (задачи) в каждый момент времени жизни документа (процесса).

Единая (или согласованная распределённая) база документной информации, позволяющая исключить возможность дублирования документов.

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

Развитая система отчётности по различным статусам и атрибутам документов, позволяющая контролировать движение документов по процессам документооборота и принимать управленческие решения, основываясь на данных из отчётов.

Классификация систем электронного документооборота:

Универсальные «коробочные» СЭДО:

· стандартный набор функций;

· невозможность полного соответствия потребностям конкретной организации;

· низкие временные затраты на приобретение и установку;

· относительно низкая стоимость;

· необходимость приобретения лицензии на каждое внедряемое рабочее место.

Индивидуально разрабатываемые СЭДО:

· максимально персонифицированная система;

· большие временные затраты;

· высокая стоимость разработки;

· сопутствующие расходы: затраты на обучение сотрудников, покупку нового оборудования и программного обеспечения.

Комбинированные СЭДО:

· базовая платформа, к которой разрабатываются необходимые дополнительные модули;

· полное соответствие нуждам предприятия;

· небольшие временные затраты на разработку и внедрение;

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

· передача заказчику прав на продукт;

· простота освоения и использования;

· полная локализация;

· удобный интерфейс;

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

Отрасль СЭД существует уже довольно давно. В начале 90-х годов крупные холдинги и корпорации начали разрабатывать и внедрять СЭД на свои собственные средства, так как нуждались в скорейшей обработке бумажных документов, отчётов, приказов и т.д.

Первые системы электронного документооборота предназначались просто для совместного доступа к документам в защищённом хранилище. В хранилище действовало разграничение прав на доступ к тем или иным разделам хранилища, например по отделам или по должности. С годами эти функции стала предоставлять операционная система и возможности сети. Поэтому необходимость в СЭД временно спала. Но не надолго, так как всё быстрее нарастали темп и объём бумажных документов. А с развитием языков программирования в системы электронного документооборота можно было включить функции создания, редактирования и удаления документов прямо в окне системы. Это и стало следующей ступенью развития СЭД. СЭД такие, какие мы их знаем, причисляются к третьей ступени их развития. То есть третья ступень развития СЭД - это обеспечение всего жизненного цикла документа. Плюс к этому сегодня в системы электронного документооборота включают самые различные функции.

В России системы электронного документооборота появились в самом начале века. В Самарских административных учреждениях уже 6 лет практикуется создание и внедрение СЭД. И системы электронного документооборота в Самаре весьма хорошо функционируют. Самые известные из них это:

· система обращений граждан;

· система картографии и кадастра по Самарской области;

· электронная приёмная губернатора;

· электронная приёмная мэра.

Замена бумажных документов электронными -- задача на ИТ-рынке хорошо известная. Однако при более внимательном ознакомлении с положением дел становится очевидным, что уровень проникновения подобных технологий в реальную жизнь организаций еще очень далек от 100%.

Проблема тут во многом заключается в том, что, несмотря на расширяющееся использование электронных методов работы с информацией, объем применяемых бумажных документов в абсолютном выражении на практике не только не уменьшается, но и возрастает. Причем происходит это вследствие роста объемов обрабатываемых данных.

Именно с такой проблемой, как и многие другие российские административные учреждения, несколько лет назад столкнулась Самарская Администрация. С тех пор год за годом производятся попытки создания электронного документооборота между государственными подразделениями и учреждениями. Объем обработки бумажных документов быстро повышался с явной тенденцией к дальнейшему росту. Именно поэтому в Департаменте управления имуществом было решено начать разрабатывать свою систему для решения этой задачи путем автоматизации трудоемкого процесса бумажного документирования и обмена сведениями.

После тщательного изучения технологии и сравнения систем электронного документооборота. Было выявлено, что ни одна из систем не подходит для решения задач ДУИ. Поэтому было предложено разработать свою ИС, адаптированную на решение конкретных задач департамента.

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

К настоящему времени разработана СЭД Directum.

На рисунке 1 представлен интерфейс системы Directum [4].

Рисунок 1 - Интерфейс системы Directum

Основные достоинства системы:

1. Ориентация на повышение эффективности работы в целом.

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

3. Возможность создания и управления в единой системе хранилищами документов практически неограниченного объёма для разного вида контента на протяжении всего жизненного цикла документов.

4. Соответствие российским стандартам и нормам делопроизводства и управления (ГСДОУ).

5. Развитое управление контентом с полноценной поддержкой жизненного цикла, вводом документов из различных источников, преобразованием и хранением документов в различных форматах.

Недостатки системы:

1. Если при внедрении требуется изменение разработки на системном уровне, то потребуются дополнительные временные и трудозатраты при обновлении до новой версии.

2. Стоимость автоматизации складывается не только из стоимости программного обеспечения, но и из услуг по внедрению. Стоимость услуг по внедрению определяется в зависимости от потребности Заказчика и может быть как равна нулю (приобретение коробочного решения), так и достигать значительных сумм при автоматизации нетиповых задач

СЭД OPTIMA-WorkFlow имеет следующие основные достоинства:

1. Развитый инструментарий для формирования отчетности.

2. Отсутствие ограничений по совместимости с офисным и прикладным программным обеспечением.

3. Использование встроенных средств сканирования и распознавания документов, индексирования, морфологического анализа и контекстного поиска.

4. Документированный объектно-ориентированный API и открытая модель хранения данных.

5. Поддержка исполнения программных сценариев, разработанных на скриптовых языках Microsoft Visual Basic и Java Script.

6. Поддержка средств создания и обработки документов, соответствующих стандартам ОLE (в частности, Microsoft Office).

7. Функциональные блоки для встраивания в Web-порталы (в частности, Microsoft SharePoint).

На рисунке 2 представлен интерфейс системы OPTIMA-WorkFlow.

Рисунок 2 - Интерфейс системы OPTIMA-WorkFlow

Основу решения «1С: Документооборот» [6] составляет платформа «1С:Предприятие 8». Платформа содержит средства автоматизации документооборота:

­ работа с документами;

­ учет и хранение документов.

Дополнительные возможности:

­ безопасность;

­ контроль исполнительской дисциплины;

­ разные версии ПК:

· КОРП - больше подходит для средних и крупных коммерческих предприятий и бюджетных учреждений со сложной структурой или документооборотом.

На рисунке 3 изображён интерфейс этой версии.

Рисунок 3 - Интерфейс 1С: Документооборот 8 КОРП

· ПРОФ - способна обеспечить потребности организаций с небольшой структурой и несложным документооборотом.

На рисунке 4 изображён интерфейс этой версии. Если приглядеться, то версия ПРОФ окажется более простой. В ней отсутствует возможность коллективной работы над документами. В остальном версии практически идентичны и имеет схожие положительные и отрицательные стороны.

Рисунок 4 - Интерфейс 1С: Документооборот 8 ПРОФ

Недостатки:

­ сложности настройки прав доступа;

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

­ отсутствие мультиязычного пакета.

Постановка задачи проектирования

На протяжении года в Департаменте управления имуществом городского округа Самара разрабатывается проект «Интегрированной информационной системы ДУИ». Проект предполагает поэтапное развитие программного комплекса путём разработки и объединения различных модулей (подсистем). Проект состоит из 4 этапов и охватывает практически всю сферу имущественных отношений в Поволжском регионе. Основным результатом будет являться создание системы, способной быстро обрабатывать большой объём сложноструктурированной информации.

В рамках проекта разрабатывается и внедряется подсистема «Налогообложение», целью которой является учёт, хранение и работа с налоговыми данными.

Вывод: Рассмотренные СЭД являются достаточно мощными средствами, но они ориентированы общим образом и не пригодны для внедрения в административных органах Поволжского региона. Они имеют относительно большую стоимость, что ограничивает возможность их использования. Из итоговой таблицы (Таблица 1) сравнения видно, что в существующих системах электронного документооборота нет возможности создавать и вести необходимые на конкретном месте справочники, а в некоторых данные хранятся в виде файлов, что не обеспечивает их сохранности.

Интегрированная информационная система ДУИ является долгосрочным проектом, и его разработка займёт ни один год. По плану первой должна быть внедрена подсистема «Налогообложение».

В связи с этим актуален вопрос о создании подсистемы «Налогообложение» интегрированной информационной системы Департамента управления имуществом городского округа Самара. Система должна быть способна решать задачи департамента быстро и качественно, невзирая на их объём и сложность.

Управление, а также использование информационной подсистемой должно быть максимально простым, чтобы не вызывать трудностей у работников департамента мало знакомых с ЭВМ.

Таблица 1 - Сравнительная итоговая таблица

СЭД	Высокая стоимость	Сложность администрирования и управления	Адаптация в конкретной области	Расширяемость	Хороший набор функций	Способ хранения документов и вложений	Высокие системные требования	Необходимо наличие специальных знаний и умений
Directum	+	+	-	-	+	+	+	+
OPTIMA-WorkFlow	-	+	+	-	-	-	-	-
1C: Документооборот	+	+	-	-	+	+	+	+
ИИС ДУИ	-	-	-	+	+	+	-	-

1.3 Разработка модели анализа проектируемой системы

Язык проектирования UML

Язык UML[7, 22, 23, 24] представляет собой общецелевой язык визуального моделирования, который разработан для спецификации, визуализации, проектирования и документирования компонентов программного обеспечения, бизнес-процессов и других систем. Язык UML одновременно является простым и мощным средством моделирования, который может быть эффективно использован для построения концептуальных, логических и графических моделей сложных систем самого различного целевого назначения. Этот язык вобрал в себя наилучшие качества методов программной инженерии, которые с успехом использовались на протяжении последних лет.

В рамках языка UML все представления о модели сложной системы фиксируются в виде специальных графических конструкций, получивших название диаграмм. В терминах языка UML определены следующие виды диаграмм:

­ диаграмма вариантов использования (usecasediagram);

­ диаграмма классов (classdiagram):

· диаграмма сущностных классов (entityclassdiagram);

· диаграмма граничных классов (boundaryclassdiagram);

· диаграмма управляющих классов (controlclassdiagram);

· классы бизнес-логики (businesslogicclass);

­ диаграммы поведения (behaviordiagrams):

· диаграмма состояний (statechartdiagram);

· диаграмма деятельности (activitydiagram);

­ диаграммы взаимодействия (interactiondiagrams):

· диаграмма последовательности (sequencediagram);

· диаграмма кооперации (collaborationdiagram);

­ диаграммы реализации (realization diagram):

· диаграмма компонентов (componentdiagram);

· диаграмма развертывания (deploymentdiagram).

Каждая из этих диаграмм детализирует и конкретизирует различные представления о модели сложной системы в терминах языка UML.

Диаграмма вариантов использования (UseCaseDiagram)

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

Разработка диаграммы вариантов использования преследует следующие цели:

­ определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы;

­ сформулировать общие требования к функциональному поведению проектируемой системы;

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

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

Диаграмма вариантов использования разрабатываемой системы представлена на рисунке 5. Система содержит 2 актанта: оператор и администратор. Каждый может войти в систему. У оператора есть возможность работать с налоговыми записями. Кроме того, ему доступно формирование отчетов. Администратор обладает правами вести справочную информацию: добавлять, редактировать и удалять сведения справочников.

Рисунок 5 - Диаграмма вариантов использования ИС

Сценарии использования

Каждый вариант использования должен быть документирован как некий сценарий работы с системой.

Сценарий варианта использования «Вести справочник физических лиц(Physical)»

Вариант использования. Вести справочник Вести справочник физических лиц (Physical).

Краткое описание. Позволяет администратору добавлять, редактировать и удалять физические лица.

Актант. Администратор.

Предусловия. Вход в систему выполнен успешно в режиме администратора. На экране - главное окно системы, настроенное на права администратора. Администратор выбирает пункт меню «Работа со справочниками». Открывается дерево справочников.

Основной поток событий.

1.Администратор выбирает из узла «Реестры» пункт «Физические лица».

2.Система выводит в окно детализации системы таблицу с данными. Данные содержат: имя, фамилия, ИНН, документ удостоверяющий личность. На форме также имеются кнопки «Добавить», «Удалить», «Редактировать» и «Обновить».

3.Администратор просматривает таблицу физ. лиц и закрывает окно детализации.

А1: Администратор нажимает кнопку «Добавить».

A2: Администратор нажимает кнопку «Удалить».

A3: Администратор нажимает кнопку «Редактировать».

A4: Администратор выбирает запись и нажимает кнопку «Удалить».

A5: Администратор выбирает запись и нажимает кнопку «Редактировать».

А6: Администратор нажимает кнопку «Обновить».

4.Система закрывает окно с таблицей пользователей. На экране - главное меню системы. Вариант использования завершается успешно.

Альтернативы

А1: Администратор нажимает кнопку «Добавить».

А1.1 Система открывает форму для добавления физ. лица с полями для ввода: «Имя», «Фамилия», «ИНН», поля для выбора из списка «Типа документа удостоверяющего личность», поля выбора даты «Дата выдачи документа» и «Дата смерти»(если физ. лицо считается умершим). На форме также имеются кнопки «Сохранить» и «Отмена».

A1.2 Администратор вводит данные и нажимает кнопку «Сохранить».

A1.2A1: Администратор нажимает кнопку «Отмена».

A1.2A1.1: Система закрывает форму для добавления пользователя. Осуществляется переход к пункту 2 основной последовательности.

A1.3 Система проверяет целостность и правильность введенных данных и добавляет запись в БД. Осуществляется переход к пункту 2 основной последовательности.

A1.3A1: Система не добавляет запись в БД по причине того, что нарушена целостность данных или данные неправильны, и выводит соответствующее сообщение.

A1.3A1.1: Администратор нажимает кнопку «Закрыть».

A1.3A1.2: Система закрывает форму с сообщением. Осуществляется переход к пункту 2 основной последовательности.

A2: Администратор нажимает кнопку «Удалить».

A2.1 Система не реагирует на это действие, так как требуется выбрать запись для осуществления данного действия. Осуществляется переход к пункту 2 основной последовательности.

A3: Администратор нажимает кнопку «Редактировать».

A3.1 Система не реагирует на это действие, так как требуется выбрать запись для осуществления данного действия. Осуществляется переход к пункту 2 основной последовательности.

A4: Администратор выбирает запись и нажимает кнопку «Удалить».

A4.1 Система удаляет запись из БД. Осуществляется переход к пункту 2 основной последовательности.

A5: Администратор выбирает запись и нажимает кнопку «Редактировать».

A5.1 Система открывает форму для редактирования данных с полями для ввода: «Имя», «Фамилия», «ИНН», поля для выбора из списка «Типа документа удостоверяющего личность», поля выбора даты «Дата выдачи документа» и «Дата смерти»(если физ. лицо считается умершим). На форме также имеются кнопки «Сохранить» и «Отмена».

A5.2 Администратор редактирует данные и нажимает кнопку «Сохранить».

A5.2A1: Администратор нажимает кнопку «Отмена».

A5.2A1.1: Система закрывает форму для редактирования данных, и осуществляется переход к пункту 2 основной последовательности.

A5.3 Система проверяет целостность и правильность отредактированных данных и редактирует запись в БД. Осуществляется переход к пункту 2 основной последовательности.

A5.3A1: Система не редактирует запись в БД по причине того, что нарушена целостность данных или данные неправильны, и выводит соответствующее сообщение.

A5.3A1.1: Администратор исправляет совершённые ошибки и повторно жмёт кнопку «Сохранить».

A5.3A1.2: Система закрывает форму с сообщением. Осуществляется переход к пункту 2 основной последовательности.

Постусловия. На экране - главная форма приложения с меню, настроенным на права администратора.

Сценарий варианта использования «Edittaxes»

Вариант использования. Edittaxes

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

Актант. Оператор.

Предусловия. Вход в систему выполнен успешно в режиме оператора, и интерфейс системы настроен на данный режим. На экране - главное меню системы, настроенное на права оператора.

Основной поток событий

1.Оператор выбирает пункт меню «Налогообложение».

2.Система открывает вкладку «Налогообложение» в главном окне системы и выводит дерево разделов в левой части экрана для работы в этом пункте меню.

Имеются разделы для поиска объекта недвижимости - далее ОН по различным параметрам и раздел позволяющий просмотреть дерево кадастровых кварталов.

3.Оператор выбирает раздел «Просмотр кварталов».

А1: Неверный выбор раздела

4.Дерево разворачивается, и отображаются номера кадастровых кварталов, также свёрнутые в деревья.

5.Оператор выбирает из списка нужный кадастровый квартал.

А2: Неверный выбор кад.квартала.

6.Система создаёт окно детализации и в нём вкладку с номером кадастрового квартала. Внутри окна детализации создаётся область общей информации о данном кад.квартале, в ней отображаются ОН, входящие в состав выбранного кадастрового квартала.

7. Оператор выбирает нужный ему ОН из списка.

8. Система подсвечивает выбранный ОН.

9. Пользователь нажимает на кнопку просмотра ОН.

10. Система выводит в окно детализации информацию об ОН, а также создаёт вкладку «Налогообложение» для вывода налоговых записей привязанных к данному ОН. Записи сгруппированы по годам и по налогоплательщикам.

11. Пользователь выбирает нужную ему запись из списка.

12. Система подсвечивает выбранную запись.

А3: Неверный выбор записи.

13. Пользователь нажимает кнопку «Редактировать».

14. Система открывает форму редактирования параметров записи с уже введёнными данными.

15. Пользователь вводит данные и жмёт «Сохранить».

А4: Отмена операции редактирования.

16. Система обновляет список налоговых записей.

На экране - список записей о налоговых начислениях, настроенное под права оператора. Вариант использования завершается успешно.

Альтернативы

А1: Неверный выбор раздела

А1.1 Оператор повторно нажимает на узел дерева.

А1.2 Узел дерева сворачивается.

А1.3 Возвращение к пункту 3 основной последовательности.

А2: Неверный выбор кад.квартала.

А2.1 Оператор нажимает кнопку "Закрыть" на создавшейся вкладке.

А2.2 Возвращение к пункту 5 основной последовательности.

A3: Неверный выбор записи.

А3.1 Оператор выбирает другую запись.

А3.2 Система снимает выделение с неверно выбранной записи и подсвечивает вновь выбранную.

А3.3 Возвращение к пункту 12 основной последовательности.

A4: Отмена операции редактирования.

А4.1 Оператор нажимает кнопку «Отмена»

А4.2 Система закрывает окно ввода параметров записи.

А4.3 Вариант использования завершается успешно.

Постусловия. На экране - список записей о налоговых начислениях, настроенное под права оператора. Вариант использования завершается успешно.

Диаграмма классов (ClassDiagram)

Класс - описание множества объектов, обладающих общими атрибутами, операциями, отношениями и поведением. Класс является результатом операции обобщения. Поэтому класс - всегда абстрактное понятие. Задание конкретных значений атрибутов и определяет экземпляр класса - объект, обладающий конкретным поведением. Объект может появляться во всех отношениях класса и всех его предков.

Класс имеет имя, списки атрибутов, операций или методов.

Операция - спецификация (описание) результата преобразования или запроса, которые должен выполнить вызываемый объект. Имеет имя и список параметров.

Метод - процедура, непосредственно реализующая операцию; у нее есть алгоритм и описание процедуры. Обычно метод задаётся на физическом уровне представления класса в модели проектирования, когда уже выбран алгоритм и способ его реализации.

Атрибуты класса - свойства или характеристики данного класса, которые могут принимать только одно значение из некоторого множества значений определенного типа. Классы могут находиться между собой в различных отношениях (связях). Базовыми отношениями являются:

- отношения зависимости;

- отношения ассоциации;

- отношения обобщения;

- отношения реализации.

Диаграмма граничных классов

Граничный класс (boundaryclass) - класс, который располагается на границе системы с внешней средой и непосредственно взаимодействует с актантами, но является составной частью системы. Диаграмма граничных классов представлена на рисунке 6.

На диаграмме граничных классов изображена зависимость экранных форм друг от друга, а также иерархия их вызова. Можно легко определить, что раз проектируемая подсистема имеет разграничение доступа и защиту от несанкционированного использования, то форма авторизации открывается первой при запуске системы. При вводе корректных данных открывается главное окно системы, в противном случае появляется сообщение об ошибочных данных. С главной формы приложения можно перейти на форму справочников или на формы отчётов. Интерес вызывает форма добавления/редактирования записей, так как является универсальным компонентом с возможностью динамического контента.



Рисунок 6 - Диаграмма граничных классов

Диаграмма управляющих классов

Классы управления (controlclass) - объекты этих классов являются активными, берущими на себя управление и организацию вычислительных процессов; чаще всего это стандартные компоненты операционных систем и систем управления базами данных (СУБД), таймеры, координаторы и т.п. Диаграмма классов управления представлена на рисунке 7.

Рисунок 7 - Диаграмма управленческих классов

Диаграмма сущностных классов

Класс-сущность (entityclass) - пассивный класс, информация о котором должна храниться постоянно и не уничтожаться с выключением системы. Класс-сущность содержит информацию, которая должна храниться постоянно и не уничтожается с уничтожением объектов данного класса или прекращением работы моделируемой системы, связанные с выключением системы или завершением программы.

По сути, диаграмма сущностных классов является наглядным представлением основных таблиц базы данных. В каждом классе есть атрибуты, которые являются набором полей таблицы. В классах не указываются атрибуты внешних ключей, но связи между таблицами указывают на их наличие.

Диаграмма сущностных классов представлена на рисунке 8.

1.4 Разработка логической модели базы данных

В процессе анализа предметной области, формирования требований к системе и построения информационно-логического проекта системы по методологии UML были выделены основные сущности системы. Они были представлены диаграммой сущностных классов (рисунок 8). Следующим этапом проектирования системы является построение логического проекта базы данных. Наиболее известными моделями данных являются следующие: иерархическая, сетевая, реляционная, постреляционная, объектно-ориентированная. Для разработки логического проекта базы данных была выбрана реляционная модель данных. Реляционная модель - структура данных, представленная в виде совокупности взаимосвязанных упорядоченных наборов элементов. Множество наборов элементов называется отношением между элементами. Полная атрибутивная логическая модель базы данных проектируемой системы, построенная с помощью программного средства проектирования баз данных ERWin DataModeler7.3, представлена на рисунке 9.

Рисунок 8 - Диаграмма сущностных классов

Рисунок 9 - Логическая модель базы данных систем

1.5 Оценка требуемых параметров комплекса технических средств

Расчет объема ВЗУ

Для расчета объема внешней памяти необходимой для функционирования системы воспользуемся формулой:



где - объем внешней памяти, занимаемый операционной системой, Мб;

VСУБД- объем внешней памяти, занимаемый СУБД, Мб;

- объем внешней памяти, занимаемый данными, необходимыми для работы системы, Мб;

- объем внешней памяти, занимаемый программными модулями, Мб;

В качестве ОС сервера используется ОС Windows Server 2008 R2.

= 4,52 Гб = 4628,48 Мб ? 4630 Мб.

К качестве СУБД используется Oracle 10gExpress.

VСУБД= 150 Мб.

Определим объем внешней памяти, необходимый для хранения программ. Он определяется объемом памяти, который занимают файлы системы и объемом памяти, необходимым для хранения файлов сопутствующих программ. Для хранения файлов системы необходимо 24,5 Мб. Для хранения дополнительных модулей потребуется 50 Мб. Таким образом, получаем, что:

=24,5 Мб + 50Мб=74,5Мб

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

Vданных = 24,61 Гб ? 25 Гб

= 260 Мб.

Таким образом, общий объем внешней памяти составляет:

Таблица 2 - Расчет объема данных

Название таблицы	Размер записи, байт	Максимальное количество записей	Итого, байт
PhysLic	109	10000000	10900000
JurLic	109	10000000	10900000
regions	109	150	16350
EstateObject	226	10000000	226000000
Doc_Type	105	100	10500
Measures	105	500	52500
Doc_Issuer	105	10000	1050000
REnd_use	105	10	1050
Land_category	105	30	3150
InventoryObject	226	5000000	113000000
Estate_object_status	105	20	2100
Tax_status	105	20	2100
address	258	10000000	258000000
taxes	258	1000000000	25800000000
Inventory_object_type	105	100	10500
user	211	102	21522
Итого:			26419969772

Расчет емкости ОЗУ

Для расчета ОЗУ воспользуемся формулой:

где - объем ОЗУ, необходимый для работы операционной системой, Мб;

- объем ОЗУ, необходимый для работы СУБД, Мб;

- объем ОЗУ, необходимый данным системы, Мб;

- объем ОЗУ, необходимый для работы программы, Мб;

Для работы ОС Windows Server 2008 R2 необходимо не менее 1024 Мб оперативной памяти. Следовательно, = 1024 Мб.

= 201 Мб.

= 36 Мб.

= 9 Мб

= 114 Мб.

Суммарный объем ОЗУ, необходимый для функционирования системы:

Расчет быстродействия

Время реакции системы - это время от момента начала запроса на выполнение функции от внешнего источника до момента окончания формирования результатов по данной функции. Для расчета быстродействия необходимого для функционирования системы воспользуемся формулой:

tреакции=tввода+tсчитывания+tвычислений+tвывода

В этой формуле:

tввода - время на ввод входных данных запроса;

tсчитывания - время, затрачиваемое на считывание физических блоков при работе с накопителем;

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

tвывода - время на вывод результата на устройство вывода или отображения, для принтера оценивается отдельно. Для дисплея можно принять 0,5 с.

Основным объектом исследования является работа с налоговыми данными, при этом основными процессами этого исследования являются заполнениеналоговой карточки. Оценим время реакции системы при заполнении карточки.

Ввод данных для заполнения налоговой карточки занимает около30 с, то есть

Так как, не имеется обращений к сторонним накопителям, буфер не используется, загрузка заполненной налоговой карточки в систему при среднем времени доступа типичного жёсткого диска приблизительно равно 8,5 миллисекунд, займет:

Для оценки времени вычислений возьмем случай сохранения новой налоговой карточки. Для записи одногополя карточкивна место в базе данных требуется время на получение от используемой ORM-технологии SQL-запроса (1 мс) и время на запись подставленных параметров в базу (1.5 мс). Учитывая время обработки и переиндексации данных в БД около (3.5с) получим:

Таким образом, при тактовой частоте процессора равной 1.5 ГГц для записи новой карточки, требуется время около 35с. Таким образом, можно сделать вывод, что наблюдается хороший уровень быстродействия.

Окончательный комплекс технических средств

Для корректной работы приложения, а также других программных средств и дополнительных модулей требуется следующий окончательный состав технических средств:

· Частота процессора 1,5 ГГц;

· Оперативная память 2 ГБ;

· Объём жёсткого диска 40 ГБ;

· Принтер;

· Монитор.

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

2. КОНСТРУКТОРСКО-ТЕХНОЛОГИЧЕСКАЯ ЧАСТЬ

2.1 Выбор и обоснование архитектуры системы

Для реализации проекта была выбрана двухуровневая архитектура клиент-сервер [8].Получила распространение с начала 1990-х годов на фоне роста рынка персональных компьютеров. Технология "клиент-сервер" разделяет информационную систему на два уровня: представления и хранения данных.

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

Второй уровень - сервер с размещенной на нем базой данных.

Благодаря двухуровневой архитектуре снижается нагрузка на информационную сеть, поскольку передаются только запросы и ответы на них. Другой важнейший принцип клиент-серверной архитектуры: информация вводится в систему только один раз. Благодаря этому отпадает необходимость дублирования одних и тех же данных работниками различных подразделениях предприятия, что резко снижает риск ошибок в информационной системе. Архитектура представлена на рисунке 10.

В целях расширяемости и дальнейшего развития было принято реализовать систему с применением модульной архитектуры. Библиотеки, используемые в реализации, являются стандартными и находятся в свободном доступе. Эти библиотеки реализуют стандартные методы и средства. Другая составная часть системы -- пользовательский интерфейс клиента, использующего классы и методы библиотек визуализации. Эти библиотеки называются TelerikRadControls [9]. Они делают интерфейс более «гладким» и приятным при долговременной работе. Также выделен отдельный модуль для взаимодействия с базой данных.



Рисунок 10 - Архитектура двухуровнего клиент-сервера

2.2 Выбор и обоснование средств комплекса программно-технических средств

Выбор операционной системы

Для нормального функционирования системы должна стоять операционная система Windows[10]. Последние 10 лет Windows -- самая популярная операционная система на рынке персональных компьютеров. Системы Windows работают на платформах x86, AMD64, IA-64. В настоящее время Microsoft Windows установлена более чем на 90% всех персональных компьютеров и рабочих станций. В России до начала 2000-х годов почти все персональные компьютеры продавались с предустановленной системой Windows. Операционная система Windows предоставляет удобные механизмы для управления работой приложений, а также предоставляет интуитивно-понятный интерфейс для пользователя.

Выбор языка программирования и среды разработки

В качестве языка программирования был выбранC# [11] с применением технологии Silverlight [12] при разработке в среде MSVisualStudio 2010 Premium[13].

Создатели языка C# постарались воплотить в своем "детище" все лучшие, по их мнению, идеи объектно-ориентированных языков программирования. За основу был взят C++, масса полезных идей была заимствована из Objective C[14] и SmallTalk [15], кое-что - из других языков.

Перечень свойств языка C#, которыми особенно гордятся его создатели это простота. Описание языка занимает всего 60 страниц, его вполне можно прочитать за один вечер. Тем, кто знает C++ [16], изучить этот язык будет особенно просто. Ещё одно преимущество - это объектная ориентированность. Концепция объектно-ориентированного программирования реализована в C# весьма строго: в нем нет данных, не являющихся объектами, нет и функций, не являющихся методами какого-либо объекта. Сетевая работа - это ещё одно преимущество. Средства работы в сети.C# хорошо приспособлен для работы в сетях, использующих протокол TCP/IP. Интерпретируемость. Надежность. Язык строго типизирован, стало быть, значительная часть ошибок может быть выявлена на стадии компиляции. Безопасность. Поскольку C# изначально планировался для создания коммерческих приложений, которые не только могут распространяться по сетям, но и сами способны работать с сетями, разработчики языка постарались уделить безопасности максимум внимания.

Динамичность языка вполне обосновывает его выбор. Язык C# динамичен, он открыт для новаций, обновлений. По умолчанию все классы являются расширяемыми, а методы виртуальными, хотя при желании можно запретить дальнейшую модификацию класса или метода.

Переносимость и нейтральность относительно архитектуры. В C# можно учесть, что система будет работать под разными архитектурами, а соответственно написать код, который будет оптимизирован как для всех архитектур, так и для отдельных.

Многопоточность - это безусловное преимущество для каждого языка, им обладает и C#.

Автоматическая сборка мусора. Сборщик мусора встроен в виртуальную машину. Он работает в фоновом режиме, осуществляя поиск потерянных объектов и освобождая занятую ими память.

Работа с исключениями. Язык содержит все необходимые средства для корректной работы со всеми объектами и ресурсами в случае возникновения исключительных ситуаций. Высокая производительность. По скорости работы С#-приложения вполне соизмеримы с приложениями, разработанными на языках C и C++, оказываясь иногда производительнее последних.

Обоснование выбора среды MSVisualStudio 2010 Premium:

· малый объем;

· простота в использовании;

· авто-завершение текста в некоторых случаях;

· поддержка TFS;

· полезные функции;

· полностью настраиваемый интерфейс.

Для обновления не требуется скачивать всю программу заново, достаточно лишь принять обновления, когда VS попросит вас это сделать.

Выбор СУБД

В качестве системы управления базами данных (СУБД) был выбран Oracle 10gExpress[17].

Эта версия СУБД является решением для малых и средних приложений. Обычно Oracle используется в качестве сервера, к которому обращаются локальные или удалённые клиенты, однако в дистрибутив входит библиотека внутреннего сервера, позволяющая включать Oracle в автономные программы.

Гибкость СУБД Oracle обеспечивается поддержкой большого количества типов таблиц: пользователи могут выбрать как таблицы обычного типа, или индексные таблицы. Использовать можно также временные или кластерные таблицы. Благодаря тому, что Oracle часто используется при проектировании и реализации ИС, в СУБД постоянно появляются новые типы таблиц.

2.3 Диаграммы поведения

Диаграмма состояний (StatechartDiagram)

Главное предназначение этой диаграммы - описать возможные последовательности состояний и переходов, которые в совокупности характеризуют поведение элемента модели в течение его жизненного цикла. Диаграмма состояний представляет динамическое поведение сущностей, на основе спецификации их реакции на восприятие некоторых конкретных событий.

Диаграмма состояний по существу является графом специального вида, который представляет некоторый автомат. Вершинами этого графа являются состояния (или псевдосостояния). Дуги графа служат для обозначения переходов из состояния в состояние. Диаграммы состояния могут быть вложены друг в друга, образуя вложенные диаграммы более детального представления отдельных элементов модели [23].

После начала работы система находится в состоянии «Ожидание действий пользователя». Оператор может перевести систему в одно из основных состояний: «Работа со справочниками», «Работа с налоговыми записями», «Завершение работы», «Импорт реестров».

Диаграмма состояний системы в целом представлена на рисунке 11.

Диаграмма последовательности (Sequence Diagram)

Для моделирования взаимодействия объектов в языке UML используются соответствующие диаграммы взаимодействия. Так, взаимодействия объектов можно рассматривать во времени, и тогда для представления временных особенностей передачи и приема сообщений между объектами используется диаграмма последовательности.

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

Рисунок 11 - Диаграмма состояний ИС. Работа с приложением

Диаграмма последовательности ведения справочника кодов бюджетной классификации приведена на рисунке 12.

Основными объектами на этой диаграмме выступают:

Администратор БД - активный объект, инициирующий запросы и получающий результаты их обработки. Считается, что его линия жизни непрерывная на протяжении всего процесса работы с информационной системой.

Класс Главная форма приложения - главная форма приложения.

Класс Дерево справочников- форма, позволяющая администратору выбрать справочник необходимый ему работы.

Класс Окно детализации - окно позволяющее работать с записями справочника.

Менеджер СУБД - формирует запросы к БД.

Сущность Коды бюджетной классификации - представляет таблицу с соответствующим именем.

На диграмме присутствует так называемый фрейм. В данном конкретном случае он представляет альтернативный набор действий при сторожевом условии. Это означает, что последовательность выполняется в одинаковом режиме, но в какой-то момент происходит ветвление и последовательность продолжается по одному из двух сценариев. Сторожевое условие необходимо для проверки, по какому сценарию продолжить последовательность.

Рисунок 12 - Диаграмма последовательности работы со справочником кодов бюджетной классификации

Диаграмма кооперации (Collaboration Diagram)

Диаграмма кооперации - это динамическая модель системы обмена сообщений между объектами.

Кооперация - описание общего расположения объектов и связей, которые взаимодействуют для обеспечения некоторого поведения (например, такого, как вариант использования или операция).

Кооперация имеет статическую и динамическую части. В статической описываются роли, которые могут играть объекты и их связи в экземпляре данной кооперации. Динамическая состоит из одного или более взаимодействий, характеризующихся потоками сообщений, которыми обмениваются между собой участники коопераций.

Диаграмма кооперации «Отчёт о ЗУ, поставленных на особый налоговый контроль» представлена на рисунке 13.

Рисунок 13 - Диаграмма кооперации «Отчёт о ЗУ, поставленных на особый налоговый контроль»

По сути, диаграмма коопераций показывает то же, что и диаграмма последовательности. Но на диаграмме коопераций стиль отображения обмена сообщениями в системе и действий пользователя проще. Сообщения пронумерованы, что облегчает чтение цепочки сообщений.

2.4 Разработка физической модели базы данных

Основными компонентами физической базы данных являются физические блоки, хранимые записи, указатели, данные переполнения и промежутки между блоками. Взаимосвязи между хранимыми записями, возникающие в результате их группирования или использования индексных структур, могут также рассматриваться как часть физической структуры.

Результатом физического проектирования является полностью готовая к внедрению структура БД. Физическая модель данных ориентирована на конкретную СУБД.

Логический уровень позволяет давать объектам имена более понятные специалистам предметной области. На физическом уровне объекты БД необходимо называть так, как того требуют ограничения СУБД (например, словами, состоящими из латинских букв, без использования специальных символов).

Переход на физический уровень достигается определением названий таблиц, соответствующих сущностям, а также названия и типы данных для полей, представляющих атрибуты сущностей. С точки зрения реляционной БД таблица (сущность) состоит из набора строк (кортежей) и столбцов (атрибутов). Каждый столбец таблицы предназначен для хранения данных определенного типа.

Для реализации базы данных системы выбрана СУБД Oracle 10gExpress. База данных Oracle 10gExpressсостоит из совокупности таблиц, в которых хранятся некоторые наборы структурированных данных. Корректность данных таблиц обеспечивается различными управляющими объектами (ограничениями, правилами, триггерами, значениями по умолчанию и специализированными пользовательскими типами данных), которые также являются составной частью базы данных Oracle 10gExpress.

Соответствие названий таблиц базы данных названиям отношений приведено в таблице 3.

Таблица 3 - Соответствие между отношениями и таблицами базы данных

Название отношения (логический уровень)	Название таблицы (физический уровень)
Единица_измерения	Dir_Measure
Категория_земли	Dir_LandCategory
Тип_ОН	Dir_EOType
Категория_ОН	Dir_EOCategory
Вид_конечн.исп	Dir_REndUseType
Ставка_налога	TaxRate
Налоговая_запись	Taxes
Кад.квартал	InventoryObject
Объект_недвижимости	EstateObject
Пользователь	User
Продолжение таблицы 3
Регион	Dir_Region
Адрес	Address
Налогоплательщик	Taxpaymentman
Физ.лицо	OwnerPhys
Юр.лицо	OwnerJur
Статус_налогообложения	Dir_TaxStatus
Вид_кон.исп-ОН	EO_To_REndUse_Link
ОН-статус_налога	EO_To_TaxStatus_Link
ОН-налогоплательщик	EO_To_Taxpaymentman_Link
Код_бюд.классиф	Dir_KBK
Тип_документа	Dir_OwnerDocType
Орган_выдачи_документа	Dir_OwnerDocIssuer
Импорт_записи	ImportLog
Тип_импорта	Dir_ImportType
Статус_импорта	Dir_ImportStatus
Статус_ОН	Dir_EOStatus

Физическая модель базы данных системы представлена на рисунке 14. Стоит добавить, что при переходе на физический уровень проектирования базы данных очень важно определиться с типами всех столбцов таблиц. Каждый тип имеет особую специфику и по-своему представляет данные. Есть текстовые типы, числовые, которые в свою очередь делятся на целочисленные, с плавающей точкой и т.д. Типы имеют ограничения по длинне и значениям. Следует внимательно изучить каждый тип перед генерацией базы данных. Но на физической модели типы не отображены, так как ранее я уже представлял их в диаграмме сущностных классов в UMLпроекте (рисунок 8).

...