Создание информационной системы уведомления клиентов страховой компании (стр. 7 )

Результат Проекта

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

Готовность системы к эксплуатации определяется по результатам тестирования совместно представителями Исполнителя и Заказчика. Оценка готовности утверждается Управляющим комитетом Проекта.

Проектирование баз данных в среде 1С.

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

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

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

Неслучайно, в системах 1С:Предприятие предприняты шаги в области построения схем бизнес-процессов. В рамках идеологии 1С информационная структура проектируется на уровне предусмотренных в вычислительной системе типов обрабатываемых объектов предметной области. К ним относятся справочники, документы, регистры, перечисления и другие. Некоторое представление о системе (в основном о ее составе и иерархической структуре) дает дерево конфигурации.

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

Можно моделировать строение базы данных, используя хорошо известные диаграммы «сущность-связь» ERD (Entity-Relationship Diagrams) в нотациях Чена (Chen) или Баркера (Barker). Но интерпретировать разнообразные типы объектов 1С как простые таблицы было бы ошибочным упрощением. Подобные модели (например, довольно распространенные модели в нотациях IDEF1X (Integration Definition for Information Modeling) и IE (Information Engineering)) ориентированы на проектирование реляционных баз данных, в то время как базы, разработанные на платформе 1С, вообще говоря, таковыми не являются. Более того, одним из ключевых объектов 1С является «документ», предназначенный для отражения хозяйственных событий предприятия.

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

Для моделирования документооборота (в широком смысле) удобны диаграммы потоков данных DFD (Data Flow Diagrams). Традиционно для изображения DFD используются две нотации: Йодана (Yourdon) и Гейна - Сарсона (Gane-Sarson). Однако нужно понимать, что DFD – это средство, скорее предназначенное для моделирования функциональных требований системы, которая представляется в виде сети функциональных компонент, связанных потоками данных. В нашем же случае речь идет о графическом отображении структуры данных, желательно с учетом особенностей идеологии 1С.

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

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

Связи (рисунок 3.1)

Связь 1 – один-ко-многим между независимыми объектами. Соответствующие атрибуты дочерней сущности являются величинами ссылочного типа: СправочникСсылка, ДокументСсылка, ПеречислениеСсылка. Связь 2 – между подчиненными справочниками. Связь 3 – между регистром и регистратором (документом, осуществляющим движение данного регистра) (Рис. 3.1).

Рис. 3.1 - Сущность связей

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

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

3.3 Прототипирование интерфейса

Платформа системы управления предприятием для 1С унифицирована и проектируется стандартными средствами для любой организации.

Интерфейсно, платформа спроектирована следующим образом:

При входе в систему пользователь попадает на главный экран системы. Экран представляет собой совокупность форм, объединяющих элементы интерфейса – user controls (рис. 3.2).

Рис. 3.2 Главный экран системы

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

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

Функциональные экраны спроектированы, в целом, по одним и тем же принципам, в своей работе я проиллюстрирую проектирование интерфейса на экране «Клиентский сервис».

При переходе на экран «Клиентский сервис» система отображает список возможных действий (рис. 3.3):

Рис 3.3 Экран «Клиентский сервис»

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

Т. к. в рамках проектирования ERP системы прототипировать необходимо достаточно много однотипных экранов, в этом разделе я рассмотрю наиболее типичные экраны для системы.

Экран «Клиентский сервис».

Экран позволяет получить доступ к информацие о клиентах компании (рис. 3.4):

Рис. 3.4 – Данные клиента

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

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

При необходимости работать с конкретным клиентом пользователь выбирает требуемый объект и переходит в карточку объекта (рис. 3.5):

Рис. 3.5 Карточка клиента

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

Для всех объектов раздела существуют обязательные общие вкладки. Кроме вкладки с общими данными обязательной вкладкой является вкладка «Регистрация заявок» (рис. 3.6).

Рис. 3.6 – Регистрация заявок

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

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

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

Всё это выделяет процесс проектирования и разработки на 1С среди прочих средств проектирования.

Конфигуратор позволяет оперировать всеми стандартными объектами платформы (рис. 3.7).

Рис. 3.7 Конфигуратор 1С Предприятие

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