Принципы проектирования информационных систем

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

В настоящее время в эксплуатации на крупных предприятиях находятся комплексные ИС управления предприятиями (КИС, корпоративные системы, ERP-системы), такие как R/3 фирмы SAP, Oracle E-Business Suite, BaanERP. Среди российских разработок приближаются по функциональности к системам класса ERP " Галактика ", " Флагман ", " Парус ".

По данным аналитической компании IDC за 2004 г., объем российского рынка интегрированных систем управления предприятием (ИСУП) вырос на 52,8% и достиг 195 млн. долл. Уже третий год подряд темпы его роста превышают аналогичный показатель ИТ отрасли в целом (1.1).

Таблица 1.1. Объем российского рынка интегрированных систем управления предприятием в 2004-2006 г.
Название компании	Доля (%)
SAP	40,6
Oracle	22,8
Microsoft	10,9
Galaktika	8,2
1C	4,6
Epicor-Scala	3,7
BAAN	2,4
Остальное	6,8
ВСЕГО	195,15 млн. долл.

Многие ERP-системы могут устанавливаться и функционировать на различных операционных системах и серверах баз данных (многоплатформенные системы). База данных подобных систем состоит из нескольких тысяч таблиц (BaanERP 5.0с - более 2500 таблиц информации по одному предприятию).

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

На рис. 1.2 показан полный состав системы BaanERP версии 5.0с (меню администратора системы) и состав модулей подсистемы " Производство ".

На рис. 1.3 приведена схема подсистем и модулей КИС "Флагман".

Рис. 1.3. Схема подсистем и модулей КИС "Флагман"

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

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

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

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

Исторически сложилось так, что некоторые системы разрабатывались по методу " снизу вверх ": вначале создавались отдельные автоматизированные рабочие места (АРМы), затем предпринимались попытки объединения их в единую информационную систему. Подобные разработки для крупных систем не могут быть успешны.

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

1. объекты информационной системы (сущности в концептуальной модели);

3. взаимодействие объектов (связи) и информационные потоки внутри и между ними.

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

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

Схема формирования информационной модели представлена на рис.1.4.

Рис. 1.4. Схема формирования информационной модели

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

Физическая модель - отражает все свойства (атрибуты) информационных объектов базы и связи между ними с учетом способа их хранения - используемой СУБД.

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

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

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

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

Рис. 1.5. Каскадная схема жизненного цикла ИС

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

По принятым сегодня нормам, над любым проектом ИС работают:

· бизнес-аналитики, изучающие и моделирующие бизнес-процессы предметной области;

· системные аналитики и архитекторы, проектирующие архитектуру решения, приложений и данных;

· специалисты по тестированию и оценке качества;

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

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

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

К таким стандартам относятся методологии семейства IDEF (Icam DEFinition, ICAM - Integrated Computer-Aided Manufacturing - первоначально разработанная в конце 70-х гг. программа ВВС США интегрированной компьютерной поддержки производства). С их помощью можно эффективно проектировать, отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. В настоящий момент к семейству IDEF относятся следующие стандарты:

· IDEF0 - Function Modeling - методология функционального моделирования сложных систем. С помощью наглядного графического языка IDEF0 изучаемая система предстает перед разработчиками и аналитиками в виде набора взаимосвязанных функциональных блоков. Основана на разработанной компанией SofTech, Inc. в конце 60-х гг. технологии SADT - структурированного анализа и разработки (Structured Analysis and Design Technique). Как правило, моделирование средствами IDEF0 является первым этапом изучения любой системы;

· IDEF1 - Information Modeling - методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи;

· IDEF1X (IDEF1 Extended) - Data Modeling - методология проектирования реляционных баз данных. Заключается в построении моделей данных типа "сущность-связь" (ERD - Entity-Relationship Diagram) в нотации этого стандарта;

· IDEF2 - Simulation Model Design - методология динамического моделирования систем. В настоящее время существуют алгоритмы и их компьютерные реализации, которые позволяют превращать набор статических диаграмм IDEF0 в динамические модели, построенные на базе "раскрашенных сетей Петри" (CPN - Color Petri Nets);

· IDEF3 - Process Description Capture - методология документирования процессов, происходящих в системе, которая используется, например, при исследовании технологических процессов на предприятиях. С помощью IDEF3 описываются сценарий и последовательность операций для каждого процесса. IDEF3 имеет прямую взаимосвязь с методологией IDEF0 - каждая функция (функциональный блок) может быть представлена в виде отдельного процесса средствами IDEF3;

· IDEF4 - Object-Oriented Design - методология построения объектно-ориентированных систем. Средства IDEF4 позволяют наглядно отображать структуру объектов и заложенные принципы их взаимодействия, тем самым позволяя анализировать и оптимизировать сложные объектно-ориентированные системы;

· IDEF5 - Ontology Description Capture - методология онтологического исследования сложных систем. В методологии IDEF5 онтология системы может быть описана при помощи определенного словаря терминов и правил, на основании которых могут быть сформированы достоверные утверждения о состоянии рассматриваемой системы в некоторый момент времени. На основе этих утверждений формируются выводы о дальнейшем развитии системы, и производится ее оптимизация;

· IDEF6 - Design Rationale Capture - методология использования рационального опыта проектирования, назначение: сохранение рационального опыта проектирования информационных систем для предотвращения структурных ошибок при новом проектировании;

· IDEF7 - Information System Auditing - методология аудита информационной системы;

· IDEF8 - User Interface Modeling - методология проектирования интерфейса пользователя;

· IDEF9 - Scenario-Driven IS Design - методология анализа имеющихся условий и ограничений, в том числе физических, юридических, политических, и их влияния на принимаемые решения в процессе реинжиниринга;

· IDEF10 - Implementation Architecture Modeling - моделирование архитектуры выполнения;

· IDEF11 - Information Artifact Modeling - информационное моделирование артефактов;

· IDEF12 - Organization Modeling - организационное моделирование;

· IDEF13 - Three Schema Mapping Design - трехсхемный дизайн карт;

· IDEF14 - Network Design - методология моделирования компьютерных сетей. Позволяет выполнять представление и анализ данных при проектировании вычислительных сетей на графическом языке с описанием конфигураций, очередей, сетевых компонентов, требований к надежности и т.п.

Описание стандартов IDEF0 - IDEF5, IDEF9 можно найти на сайтах http://www.idef.ru, http://www.idef.com или в интернет-библиотеке Верникова http://www.vpg.ru/main.mhtml?PubID=6

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

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

· верхняя сторона имеет значение "Управление" (Control);

· правая сторона имеет значение "Выход" (Output);

· нижняя сторона имеет значение "Механизм" (Mechanism).

Рис. 1.6. Функциональный блок по стандарту IDEF0

Принципы изображения функциональных моделей стандарта IDEF0 используют инструментальные средства моделирования (CASE -средства - Computer-Aided Software System Engineering), такие как BPwin фирмы Computer Associates и др.

В стандарте IDEF1 сущности и связи концептуальной модели изображаются, как показано на рис. 1.7.

Рис. 1.7. Изображение сущностей и связей концептуальной модели по IDEF1

Метод IDEF1, являясь методом анализа, описывает:

· как информация собирается, хранится и обрабатывается на предприятии;

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

Другие методологии, используемые при моделировании сложных систем:

· DFD-технология анализа "потока данных" (Data Flow Diagrams);

Важное место в моделировании информационных систем занимает методология и системы, использующие UML - унифицированный язык моделирования (Unified Modeling Language).

UML - язык для спецификации, визуализации, конструирования и документирования сложных информационно-насыщенных объектных систем. В настоящее время зарегистрирован как международный стандарт ISO/IEC 19501:2005 "Information technology - Open Distributed Processing - Unified Modeling Language (UML)".

UML-модель может включать в себя следующие аспекты;

1. Структурный аспект: Use-Case-диаграммы, идентифицирующие бизнес-процессы и бизнес-транзакции, их взаимосвязь, соподчиненность и взаимодействие; Package-диаграммы, описывающие структуру предметной области и иерархическую структуру организации.

2. Динамический аспект: Behavior-диаграммы (Activity, Statechart, Collaboration, Sequence), описывающие поведение (жизненный цикл) бизнес-процесcов в их взаимодействии во времени и в пространстве с привязкой к используемым ресурсам и получаемым результатам.

3. Статический аспект: Class-диаграммы, отражающие совокупность взаимосвязанных объектов, т.е. рассматривающие логическую структуру предметной области, ее внутренние концепции, иерархию объектов и статические связи между ними, структуры данных и объектов; Deployment-диаграммы, отражающие технологические ресурсы организации.

Словарь языка UML включает три вида строительных блоков:

Сущности в UML - это абстракции, являющиеся основными элементами модели. Отношения связывают различные сущности; диаграммы группируют представляющие интерес совокупности сущностей.

Структурные сущности - это имена существительные в моделях на языке UML. Как правило, они представляют собой статические части модели, соответствующие концептуальным или физическим элементам системы. Существует семь разновидностей структурных сущностей: Класс, Интерфейс, Кооперация, Прецедент, Активный класс, Компонент, Узел.

Поведенческие сущности являются динамическими составляющими модели UML. Это глаголы языка: они описывают поведение модели во времени и пространстве. Существует всего два основных типа поведенческих сущностей: Взаимодействие и Автомат.

Группирующие сущности являются организующими частями модели UML. Это блоки, на которые можно разложить модель. Есть только одна первичная группирующая сущность, а именно - пакет.

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

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

В языке UML определены четыре типа отношений:

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

· диаграммы последовательностей (Sequence Diagrams);

Инструментальные средства, поддерживающие методологию UML - Rational Rose (Rational Software), Paradigm Plus (CA/Platinum), ARIS (IDS Sheer AG), Together Designer (Borland) и др.

Система Rational Rose позволяет строить восемь типов диаграмм UML: диаграммы прецедентов, диаграммы классов, диаграммы последовательностей, диаграммы кооперации, диаграммы состояний, диаграммы действий, компонентные диаграммы, диаграммы развертывания. Основным типом диаграмм, своеобразным ядром моделирования в UML являются диаграммы классов. Кроме UML, предусмотрено использование и других методов (Booch, OMT).

Система Paradigm Plus ориентирована на методологию OOCL (Object Oriented Change and Learning) и компонентную технологию проектирования и разработки. Она поддерживает диаграммы различных методов (UML, CLIPP, TeamFusion, OMT, Booch, OOCL, Martin/Odell, Shlaer/Mellor, Coad/Yourdon).

Система ARIS обеспечивает четыре различных "взгляда" на моделирование и анализ: Процессы, Функции (с Целями), Данные, Организация. Для каждого "взгляда" поддерживаются три уровня анализа (требования, спецификации, внедрение). Каждый из уровней анализа состоит из своего комплекта моделей различных типов, в том числе диаграмм UML, диаграмм SAP/R3 и др. Каждый объект моделей ARIS имеет множество атрибутов, которые позволяют контролировать процесс разработки моделей, определять условия для выполнения функционально-стоимостного анализа, имитационного моделирования, взаимодействия с workflow-системами и т.д.

Система Together Designer Community Edition - средство создания диаграмм UML 2.0. Позволяет строить диаграммы прецедентов (диаграммы сценариев взаимодействия пользователя с продуктом с точки зрения пользователя); диаграммы последовательностей, описывающие порядок передачи сообщений от одних объектов к другим; диаграммы кооперации, описывающие взаимодействие объектов друг с другом, диаграммы деятельности, описывающие потоки работ и изменение состояний объектов, диаграммы развертывания. При необходимости может создаваться логическая модель данных, содержащая диаграммы "сущность-связь", на ее основе генерируется физическая модель данных для конкретной СУБД, выбранной для реализации проекта.

На этапе создания клиентского и серверного кода все современные средства UML-моделирования могут осуществлять генерацию кода на различных языках программирования.

В феврале 2006 г. Object Management Group, Inc. - международный консорциум по разработке спецификаций в компьютерной индустрии - опубликовал финальную версию языка моделирования бизнес-процессов BPML (Business Process Modeling Language).

Основные графические элементы языка показаны на рис. 1.8

Рис. 1.8. Фрагмент модели бизнес-процесса, изображенного по стандарту BPML

Одной из последних разработок в области моделирования предприятия является создание специального унифицированного языка моделирования UEML (Unified Enterprise Modeling Language). Разработка UEML - сетевой проект (IST-2001-34229), финансируемый Евросоюзом.:

· общего, визуального, базированного на шаблонах языка для коммерческих инструментальных средств моделирования предприятий и программных систем класса workflow;

· стандартизованных, независимых от инструментов механизмов передачи моделей между проектами;

Данный проект осуществляется в соответствии с международными стандартами:

· ISO 14258 Rules and Guidelines for Enterprise Models (Правила и руководящие принципы для моделей предприятия);

· ISO 15704 Requirements for enterprise-reference architectures and methodologies (Требования и методологии по описанию архитектуры предприятия).

Инструментальные средства моделирования предприятий, поддерживающие язык UEML, Metis (Computas), e-MAGIM (GraiSoft), MO_zGO (IPK) и др.

В нашей стране в списке действующих ГОСТов по разработке автоматизированных систем (по данным Стандартинформ http://www.vniiki.ru/catalog_v.asp?page=1) следующие:

· ГОСТ 34.003-90 "Информационная технология. Комплекс стандартов на автоматизированные системы. Термины и определения";

· ГОСТ 34.201-89 "Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем";

· ГОСТ 34.601-90 "Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания";

· ГОСТ 34.602-89 "Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы".

На разработку программной документации действуют стандарты класса ЕСПД (ГОСТ 19.101-77 "Единая система программной документации. Общие положения" и т.д.)

Стадии и этапы создания автоматизированных систем (АС) в соответствии с ГОСТ 34.601-90 приведены в табл. 1.1

Стадии и этапы создания АС по ГОСТ 34.601-90
Стадии	Этапы работ
1. Формирование требований к АС	1.1. Обследование объекта и обоснование необходимости создания АС. 1.2. Формирование требований пользователя к АС. 1.3. Оформление отчета о выполненной работе и заявки на разработку АС (тактико-технического задания)
2. Разработка концепции АС	2.1. Изучение объекта. 2.2. Проведение необходимых научно-исследовательских работ. 2.3. Разработка вариантов концепции АС, удовлетворяющего требованиям пользователя. 2.4. Оформление отчета о выполненной работе
3. Техническое задание	3.1. Разработка и утверждение технического задания на создание АС
4. Эскизный проект	4.1. Разработка предварительных проектных решений по системе и ее частям. 4.2. Разработка документации на АС и ее части
5. Технический проект	5.1. Разработка проектных решений по системе и ее частям. 5.2. Разработка документации на АС и ее части. 5.3. Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработку. 5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации
6. Рабочая документация	6.1. Разработка рабочей документации на систему и ее части. 6.2. Разработка или адаптация программ
7. Ввод в действие	7.1. Подготовка объекта автоматизации к вводу АС в действие. 7.2. Подготовка персонала. 7.3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями). 7.4. Строительно-монтажные работы. 7.5. Пусконаладочные работы. 7.6. Проведение предварительных испытаний. 7.7. Проведение опытной эксплуатации. 7.8. Проведение приемочных испытаний
8. Сопровождение	8.1. Выполнение работ в соответствии с гарантийными обязательствами. 8.2. Послегарантийное обслуживание

Для проектирования концептуальной модели и формирования физической модели базы данных информационной системы можно использовать инструментальные CASE-средства (Computer-Aided Software System Engineering), например, Case Studio, SyBase Power Designer, ERWin Data Modeler и др. Данные системы применяются при описании модели данных стандарт IDEF1X и позволяют генерировать программный код на языках SQL, VBScript, JScript, либо работать с другими технологиями для переноса физической модели в реальные СУБД, которыми могут быть Oracle, Microsoft SQL Server, IBM DB2, Informix, Microsoft Access и др.

На рис. 1.9 приведена схема, показывающая взаимосвязь основных терминов в области проектирования баз данных и работы с ними.

Рис. 1.9. Взаимосвязь основных терминов в области проектирования баз данных и работы с ними

Выбор системы для разработки приложений, работающих с базой данных, сложное и ответственное решение. Такую возможность имеют универсальные системы программирования: Visual C++ и C#, Delphi, Visual Basic и др. Однако специализированные языки программирования в составе СУБД располагают огромным количеством процедур и функций для работы с базами данных, специальными библиотеками, механизмами для ускорения работы с большими базами данных. В связи с повсеместным распространением Интранета, Экстранета и Интернета, многие системы имеют возможность создания трехуровневой сервис-ориентированной архитектуры Web-приложений для работы с базами данных.

В качестве аппаратных средств наиболее часто используются компьютеры на базе процессоров Intel с операционной системой Microsoft Windows (NT, 2000, XP), локальная сеть обычно строится с использованием возможностей этой ОС, файловый сервер и сервер баз данных может использовать ОС Microsoft Windows NT, 2000, Server 2003 либо другую операционную систему для выделенных серверов (например, Unix или NetWare).