Разработка информационной системы объекта исследования

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

В первом подразделе обосновывается выбор в качестве средства реализации инструментальной среды СУБД ORACLE.

Во втором разделе производится моделирование предметной области разрабатываемой информационной системы.

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

1) декомпозиция всей системы на некоторое множество иерархически подчиненных функций;

2) представление всей информации в виде графической нотации.

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

• BFD (Bussiness Function Diagram) - диаграмма бизнес-функций (функциональные спецификации);

• DFD (Data Flow Diagram) - диаграмма потоков данных;

• STD (State Transition Diagram) - диаграмма переходов состояний (матрицы перекрестных ссылок);

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

• Функция - некоторое действие информационной системы, необходимое для решения экономической задачи;

• Декомпозиция функции - разбиение функции на множество подфункций.

Изображение объектов диаграммы иерархии функций пред­ставлено в таблице 1 в нотациях:

• Йодана (Yourdon);

• Гейна - Сарсона (Gane - Sarson);

• SADT (Structured Analysis and Design Technique);

• SAG (Software AG).

 

Таблица 1 Изображение объектов диаграммы иерархии функций

 

Объект	Йодана	Гейна-Сарсона	SADT	SAG
1. Функция			Имя №	Имя
2. Декомпозиция функции			Осуществляет­ся с помощью иерархически взаимосвязан­ных уровней детализации

 

В качестве примера рассмотрим диаграмму иерар­хии функций в нотации SAG (рис. 3) при разработке информационной системы для автоматизации подготовки, хранения и выдачи на печать доверенности на получение материальных ценностей.

 

 

Рис.3. Диаграмма иерар­хии функций (BFD)

 

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

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

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

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

Основными компонентами диаграмм потоков данных являются:

•    внешние сущности;

•    системы и подсистемы;

•    процессы;

•    накопители данных;

•    потоки данных.

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

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

Рис. 4. Графическое изображение внешней сущности

 

При построении модели сложной ИС она может быть представ­лена в самом общем виде на так называемой контекстной диаграмме в виде одной системы как единого целого либо может быть деком­позирована на ряд подсистем (рис. 5.).

 

Рис. 5. Подсистема по работе с физическими лицами ГНИ

 

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

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

Рис. 6. Графическое изображение процесса

 

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

Использование таких глаголов, как "обработать", "модернизи­ровать" или "отредактировать", означает недостаточно глубокое по­нимание данного процесса и требует дальнейшего анализа.

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

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

Накопитель данных может быть реализован физически в виде микрофиши, ящика в картотеке, таблицы в оперативной памяти, файла на магнитном носителе и т. д. Накопитель данных на диаг­рамме потоков данных (рис. 7) идентифицируется буквой "D" и произвольным числом. Имя накопителя выбирается из соображения наибольшей информативности для проектировщика.

Рис. 7. Графическое изображение накопителя данных

 

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

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

Поток данных на диаграмме изображается линией, оканчиваю­щейся стрелкой, которая показывает направление потока (рис. 8). Каждый поток данных имеет имя, отражающее его содержание.

Рис. 8. Поток данных

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

• размещать на каждой диаграмме от 3 до 6-7 процессов. Верхняя граница соответствует человеческим возможностям одновремен­ного восприятия и понимания структуры сложной системы с мно­жеством внутренних связей, нижняя граница выбрана по сооб­ражениям здравого смысла: нет необходимости детализировать процесс диаграммой, содержащей всего один процесс или два;

• не загромождать диаграммы не существенными на данном уров­не деталями;

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

• выбирать ясные, отражающие суть дела имена процессов и пото­ков, при этом стараться не использовать аббревиатуры.

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

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

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

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

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

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

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

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

 

Рис. 9. Начальная контекстная диаграмма

 

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

 

 

Данные о доверенностях

 

Данные о выдаче доверенностей

 

Рис.10. Полная контекстная диаграмма

 

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

Моделируемая система в текущий момент времени находится только в одном состоянии из всего множества состояний. В тече­ние времени она может изменить свое состояние и тем самым пе­рейти в следующее состояние из заданного множества состояний. Для перехода в состояние нужно какое-либо особое условие - условие перехода. Оно может быть информационным (условие появления информации) или временным. В табл. 2 представле­ны символы ДПС в различных нотациях. Определим основные объекты ДПС.

 

Таблица 2.

Объект	Гейна - Сарсона	Йодана	SAG
Состояние (processing step)	Имя состояния	Имя
Начальное состояние
Переход	Условие перехода Действие перехода	Условие перехода Действие перехода	Условие по данным       Условие по времени

 

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

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

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

Триггер - логическое выражение, написанное на макроязыке, которое показывает условие перехода в данное состояние.

Условие перехода - событие, вызывающее переход и иденти­фицируемое именем перехода.

Фрагмент диаграммы переходов состояний для задачи автоматизации подготовки, хранения и выдачи на печать доверенности в нотации SAG приведен на рис. 11.

Для моделирования структуры данных (третий подраздел) широко используются ER-диаграммы (диаграммы «сущность-связь»), которые в наглядной форме представляют связи между сущ­ностями.

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

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

 

                       Рис. 11. Диаграмма переходов состояний

 

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

· иметь уникальный идентификатор;

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

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

Любая сущность может иметь произвольное количество связей с другими сущно­стями. В диаграммах ER-модели сущность представляется в виде прямоугольника, со­держащего имя сущности (рис.12).

 

Рис. 12. Отображение сущности

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

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

 

Рис. 13. Связь между двумя сущностями

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

 

Рис. 14. Атрибуты сущности

 

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

Связи (отношения) между сущностями по признаку множественности могут быть трех типов — «один-к-одному» (например, отношение «Лицо-Пас­порт», имея в виду под «Паспортом» не атрибут объекта Лицо, а самостоятельный объект, состоящий из атрибутов «Номер», «Вид паспорта», «Владелец», «Место выдачи», «Дата выдачи» и т. д.), «один-ко-многим» (например, отношение «Подразделе­ние-Сотрудник», имея в виду, что в одном подразделении мо­жет работать много сотрудников, но каждый сотрудник работа­ет только в одном подразделении) и «многие-ко-многим» (на­пример, отношение «Лицо-Документ», имея в виду, что один человек может быть автором, или иметь какое-либо другое от­ношение ко многим документам, и, в свою очередь, один доку­мент может иметь много авторов.

На диаграммах ER-модели в зависимости от типа связи они отображается на линии в виде значков представленных на рисунке 15.

 

Рис. 15.Изображение разных типов связей на диаграмме

 

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

Рис. 16. ER-диаграммы

 

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

Для завершения моделирования базы данных необходимо либо произвести построение даталогической модели (рис. 18), либо произвести уточнение модели с использованием CASE средств. На рисунке 17 представлена физическая модель, полученная в Power Designer из модели представленной на рисунке 16 для Oracle.

 

Рис.17. Физическая модель

 

Сущность	Имя атрибута	Тип значения	Длина	Связь
Spr_fiz_lic	cod_f	NUMBER	5
	Famil	VARCHAR	20
	Imya	VARCHAR	15
	Otch	VARCHAR	20
	N_Pasport	NUMBER	11
Spr_tov	cod_s_t	NUMBER	5
	naimen	VARCHAR	50
	proizv	VARCHAR	80
d_dover	cod_d	NUMBER	5
	cod_f	NUMBER	5	Spr_fiz_lic
	ndoc	NUMBER	6
	dataV	DATE	-
	dataD	DATE	-
	fam	VARCHAR	20
	naim_org	VARCHAR	50
d_dover_sp_naimen	cod_n	NUMBER	5
	cod_d	NUMBER	5	d_dover
	cod_s_t	NUMBER	5	Spr_tov
	naim_tov	VARCHAR	80
	kolichestvo	NUMBER	5
	ed_izm	VARCHAR	8

 

Рис.18. Даталогическая модель

 

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

создание справочника «Наименований товаров»: