Тема 4. Информационное моделирование профессиональной деятельности.

Основные понятия

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

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

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

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

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

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

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

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

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

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

Зависимая сущность (зависимая от идентификатора) - если однозначная идентификация экземпляра сущности зависит от его отношения с другой сущностью.

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

Ключ - поле (атрибут) обеспечения связи между сущностями.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Наиболее распространенным средством моделирования данных являются диаграммы “сущность-связь”, впервые введенные П. Ченом (Entity-relationship diagram (ERD) – диаграма «Сущность-связь»). ER-диаграмы хорошо вписываются в методологию структурного анализа и проектирования информационных систем. Такие методологии обеспечивают строгое и наглядное описание проектируемой системы, которое начинается с ее общего обзора и затем уточняется, давая возможность получить различную степень детализации объекта с различным числом уровней.

Максимально формализованное описание задачи состоит из следующих компонентов:

- Наименование задачи.

- Цель работы.

- Функции задачи.

- Бизнес-правила.

- Требования к программе.

- Перечень вводимой информации.

- Перечень печатных отчетов.

- Требования к оснащению офиса фирмы компьютерной техникой.

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

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

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

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

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

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

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

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

- тип связи (идентифицирующая, не идентифицирующая, полная/неполная категория, неспецифическая связь);

- родительская сущность;

- дочерняя (зависимая) сущность;

- мощность связи;

- допустимость пустых значений.

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

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

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

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

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

3 Внешний ключ - существует только для дочерней сущности и является ссылкой на значение ключа родительской сущности. При создании связей (отношений) между сущностями в дочернюю сущность передаются атрибуты, составляющие первичный ключ родительской сущности. Эти атрибуты и составляют внешний ключ.

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

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

Диаграммы "сущность-связь" лежат в основе проектирования баз данных (БД).

Основные модели, используемые при разработке БД

Реляционная модель

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

Атрибуты строк-кортежей (и таблиц-отношений) – это значения из заданных наравне с таблицами областей определения ("доменов"). Разные столбцы в одной и той же или в разных таблицах могут иметь одну и ту же область определения, а могут – разные.

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

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

базовые операции:

- ограничение - исключение из таблицы некоторых строк;

- проекция - исключение из таблицы некоторых столбцов;

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

- объединение - объединение множеств строк двух таблиц;

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

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

производные операции:

- группа операций соединения;

- пересечение - пересечение множеств строк двух таблиц;

- деление;

- разбиение;

- расширение - добавление новых столбцов в таблицу;

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

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

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

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

Е. Кодд, автор реляционного подхода, в конце 70-х гг. предложил правила соответствия произвольной СУБД реляционной модели, дополнив основные понятия реляционных баз данных определениями, важными для практики:

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

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

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

3 Правило наличия значения (missing information). В полностью реляционной СУБД должны иметься специальные индикаторы (отличные от пустой символьной строки или строки из одних пробелов и отличные от нуля или какого-то другого числового значения) для выражения (на логическом уровне, систематично и независимо от типа данных) того факта, что значение отсутствует по меньшей мере по двум различным причинам: его действительно нет либо оно неприменимо к данной позиции. СУБД должна не только отражать этот факт, но и распространять на такие индикаторы свои функции манипулирования данными не зависимо от типа данных.

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

5 Правило полноты языка работы с данными. Сколько бы много в СУБД ни поддерживалось языков и режимов работы с данными, должен иметься по крайней мере один язык, выражаемый в виде командных строк в некотором удобном синтаксисе, который бы позволял формулировать:

- определение данных,

- определение правил целостности,

- манипулирование данными (в диалоге и из программы),

- определение выводимых таблиц (в том числе возможности их модификации),

- определение правил авторизации,

- границы транзакций.

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

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

8 Правило физической независимости. Диалоговые операторы и прикладные программы на логическом уровне не должны страдать от каких-либо изменений во внутреннем хранении данных или в методах доступа СУБД.

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

10 Правило сохранения целостности. Диалоговые операторы и прикладные программы не должны изменяться при изменении правил целостности в БД (задаваемых языком работы с данными и хранимых в системном каталоге).

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

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

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

Объектно-ориентированная модель

Основные понятия объектно-ориентированной модели данных:

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

- классы, являющиеся по сути типами объектов;

- операции над объектами одного или разных типов, называемые "методами";

- инкапсуляция структурного и функционального описания объектов, позволяющая разделять внутреннее и внешнее описания (в терминологии предшествовавшего объектному модульного программирования - "модульность" объектов);

- наследуемость внешних свойств объектов на основе соотношения "класс-подкласс".

К достоинствам объектно-ориентированной модели относятся следующие:

- возможность для пользователя системы определять свои сложные типы данных (используя имеющийся синтаксис и свойства наследуемости и инкапсуляции);

- наличие наследуемости свойств объектов;

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

К недостаткам объектно-ориентированной модели можно отнести:

- отсутствие строгих определений; разное понимание терминов и различия в терминологии;

- модель не исследована столь тщательно математически, как реляционная;

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

Модель "объектов-ролей"

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

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

Физическая модель данных

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

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

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

Функций, которые обеспечивают современные СУБД:

- поддержка логической модели данных (определение данных, оперирование данными);

- восстановление данных (транзакции, журнализация, контрольные точки);

- управление одновременным доступом;

- безопасность данных (права доступа);

- самостоятельная оптимизация выполнения операций;

- сервисные функции (администрирование, статистика, распределение данных) и т.д.

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

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

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

В основе деятельности по созданию и использованию ИС лежит понятие жизненного цикла. Условно можно выделить следующие основные этапы жизненного цикла:

- анализ – определение того, что должна делать система;

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

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

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

- внедрение – установка и ввод системы в действие;

- сопровождение – обеспечение штатного процесса эксплуатации системы на предприятии заказчика.

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

Наибольшее распространение получили три следующие модели жизненного цикла системы:

1 Каскадная модель – предполагает переход на следующий этап после полного завершения работ предыдущего этапа.

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

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

В соответствии с общей технологией и архитектурой систем выделяются следующие основные этапы процесса разработки информационной системы:

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

- построение и анализ информационной модели предметной области;

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

- проектирование функциональной структуры новой системы;

- проектирование процессов обработки данных;

- проектирование и реализация приложений.

Моделирование и анализ функционирования существующей системы

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

Анализ является первым этапом создания ИС, на котором требования заказчика уточняются, формализуются и документируются. Фактически на этом этапе дается ответ на вопрос: “Что должна делать будущая система?”. Целью анализа является преобразование общих, расплывчатых знаний об исходной предметной области в точные определения и спецификации, а также генерация функционального описания системы. На этом этапе определяются:

- внешние условия работы системы;

- функциональная структура системы;

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

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

- условия эксплуатации.

Построение и анализ информационной модели предметной области

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

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

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

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

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

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

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

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

2 Принцип полноты заключается в контроле на присутствие лишних элементов.

3 Принцип непротиворечивости заключается в обоснованности и согласованности элементов системы.

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

5 Принцип логической независимости заключается в концентрации внимания на логическом описании системы, обеспечении независимости от ее физической реализации.

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

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

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

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

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

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

Проектирование функциональной структуры новой системы

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

Проектирование процессов обработки данных новой системы

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

Проектирование и реализация приложений

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

Контрольные вопросы

1 Дайте определение сущности, связи, атрибута.

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

3 Поясните назначение модели "сущность-связь". Приведите примеры.

4 С какой целью используются первичные ключи, альтернативные ключи, внешние ключи в модели "сущность-связь".

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

6 Дайте определение жизненного цикла информационной системы, раскройте содержание основных этапов жизненного цикла.

7 Какие типы моделей жизненного цикла используются в процессе создания информационной системы?

8 В чем специфика проведения структурного анализа предметной области? Назовите основные процедуры анализа и базовые принципы.

9 Назначение логической модели информационной системы.