Управление данными

Федеральное государственное автономное образовательное учреждение высшего профессионального образования Национальный исследовательский ядерный университет «МИФИ» Волгодонский инженерно-технический институт – филиал НИЯУ МИФИ КРАТКИЙ КОНСПЕКТ ЛЕКЦИЙ по дисциплине «Управление данными» 8 семестр для студентов заочной формы обучения по направлению (специальности) 230201.65 «Информационные системы и технологии» Составитель: к.т.н., Виниченко М.Ю. Волгодонск 2012 Оглавление 1 МЕТОДОЛОГИИ И ТЕХНОЛОГИИ ПРОЕКТИРОВАНИЯ баз данных 3 1.1 Структурный подход к проектированию БД 3 1.2 Методология функционального моделирования SADT 4 1.3 Моделирование потоков данных (процессов) 4 1.4 Моделирование данных: Case-метод Баркера 12 1.5 Объектно-ориентированный подход в проектировании ИС 18 1.6 Унифицированный язык моделирования UML 19 1.7 Сопоставление и взаимосвязь структурного и объектно-ориентированного подходов 28 2 ТЕХНОЛОГИЯ ПРОЕКТИРОВАНИЯ ИС НА ОСНОВЕ ФАКТОГРАФИЧЕСКОЙ МОДЕЛИ ДАННЫХ 32 2.1 Фактографическая модель данных 32 2.2 Обзор проектирования ИС на основе фактографической модели данных 36 2.3 Элементы фактографической модели ИС 39 2.4 Реализация системы по ее фактографической модели 44 2.5 Подготовка организационного обеспечения 49 ПРИЛОЖЕНИЕ А 51 ПРИЛОЖЕНИЕ Б 53 ПРИЛОЖЕНИЕ В 56 1 МЕТОДОЛОГИИ И ТЕХНОЛОГИИ ПРОЕКТИРОВАНИЯ баз данных 1.1 Структурный подход к проектированию БД Сущность структурного подхода/3, 4/ к разработке БД заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы «снизу-вверх» от отдельных задач ко всей системе целостность теряется, возникают проблемы при информационной стыковке отдельных компонентов. Все наиболее распространенные методологии структурного подхода базируются на ряде общих принципов/2/. В качестве двух базовых принципов используются следующие: • принцип «разделяй и властвуй»– принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения; • принцип иерархического упорядочивания – принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне. Выделение двух базовых принципов не означает, что остальные принципы являются второстепенными, поскольку игнорирование любого из них может привести к непредсказуемым последствиям (в том числе и к провалу всего проекта). Основными из этих принципов являются следующие: • принцип абстрагирования – заключается в выделении существенных аспектов системы и отвлечения от несущественных; • принцип формализации – заключается в необходимости строгого методического подхода к решению проблемы; • принцип непротиворечивости – заключается в обоснованности и согласованности элементов; • принцип структурирования данных – заключается в том, что данные должны быть структурированы и иерархически организованы. В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди которых являются следующие: • SADT (StructuredAnalysisandDesignTechnique) модели и соответствующие функциональные диаграммы; • DFD (DataFlowDiagrams) диаграммы потоков данных; • ERD (Entity-Relationship Diagrams) диаграммы«сущность-связь». На стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения, то есть архитектуру ПО, структурные схемы программ и диаграммы экранных форм. Перечисленные модели в совокупности дают полное описание ИС независимо от того, является ли она существующей или вновь разрабатываемой. Состав диаграмм в каждом конкретном случае зависит от необходимой полноты описания системы. 1.2 Методология функционального моделирования SADT Методология SADT /5/представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Основные элементы этой методологии основываются на следующих концепциях: 1) графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описываются посредством интерфейсных дуг, выражающих «ограничения», которые в свою очередь определяют, когда и каким образом функции выполняются и управляются; 2) строгость и точность. Выполнение правил SADT требует достаточной строгости и точности, не накладывая в то же время чрезмерных ограничений на действия аналитика. Правила SADT включают: a) ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков); b) связность диаграмм (номера блоков); c) уникальность меток и наименований (отсутствие повторяющихся имен); d) синтаксические правила для графики (блоков и дуг); e) разделение входов и управлений (правило определения роли данных); f) отделение организации от функции, т.е. исключение влияния организационной структуры на функциональную модель. Состав функциональной модели Результатом применения методологии SADT (IDEF0) является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы – главные компоненты модели, все функции ИС и интерфейсы на них представлены как блоки и дуги. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как информация, которая подвергается обработке, показана с левой стороны блока, а результаты выхода показаны с правой стороны. Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу (рисунок 1.1). Одной из наиболее важных особенностей методологии SADT является постепенное введение все больших уровней детализации по мере создания диаграмм, отображающих модель. Рисунок 1.1 – Функциональныйблок и интерфейсные дуги На рисунке 1.2, где приведены четыре диаграммы и их взаимосвязи, показана структура SADT-модели. Каждый компонент модели может быть декомпозирован на другой диаграмме. Каждая диаграмма иллюстрирует «внутреннее строение» блока на родительской диаграмме. Иерархия диаграмм Построение SADT-модели начинается с представления всей системы в виде простейшей компоненты – одного блока и дуг, изображающих интерфейсы с функциями вне системы. Поскольку единственный блок представляет всю систему как единое целое, имя, указанное в блоке, является общим. Это верно и для интерфейсных дуг – они также представляют полный набор внешних интерфейсов системы в целом. Затем блок, который представляет систему в качестве единого модуля, детализируется на другой диаграмме с помощью нескольких блоков, соединенных интерфейсными дугами. Эти блоки представляют основные подфункции исходной функции. Данная декомпозиция выявляет полный набор подфункций, каждая из которых представлена как блок, границы которого определены интерфейсными дугами. Каждая из этих подфункций может быть декомпозирована подобным образом для более детального представления. Во всех случаях каждая подфункция может содержать только те элементы, которые входят в исходную функцию. Кроме того, модель не может опустить какие-либо элементы, т.е., как уже отмечалось, родительский блок и его интерфейсы обеспечивают контекст. К нему нельзя ничего добавить, и из него не может быть ничего удалено. Модель SADT представляет собой серию диаграмм с сопроводительной документацией, разбивающих сложный объект на составные части, которые представлены в виде блоков. Детали каждого из основных блоков показаны в виде блоков на других диаграммах. Каждая детальная диаграмма является декомпозицией блока из более общей диаграммы. На каждом шаге декомпозиции более общая диаграмма называется родительской для более детальной диаграммы. Дуги, входящие в блок и выходящие из него на диаграмме верхнего уровня, являются точно теми же самыми, что и дуги, входящие в диаграмму нижнего уровня и выходящие из нее, потому что блок и диаграмма представляют одну и ту же часть системы. Рисунок 1.2 – Структура SADT-модели. Декомпозиция диаграмм На рисунках 1.3 и 1.4 представлены различные варианты выполнения функций и соединения дуг с блоками. Рисунок1.3 – Одновременное выполнение Некоторые дуги присоединены к блокам диаграммы обоими концами, у других же один конец остается неприсоединенным. Неприсоединенные дуги соответствуют входам, управлениям и выходам родительского блока. Источник или получатель этих пограничных дуг может быть обнаружен только на родительской диаграмме. Неприсоединенные концы должны соответствовать дугам на исходной диаграмме. Все граничные дуги должны продолжаться на родительской диаграмме, чтобы она была полной и непротиворечивой. На SADT-диаграммах не указаны явно ни последовательность, ни время. Обратные связи, итерации, продолжающиеся процессы и перекрывающиеся (по времени) функции могут быть изображены с помощью дуг. Обратные связи могут выступать в виде комментариев, замечаний, исправлений и т.д. (рисунок 1.4). Рисунок 1.4 – Пример обратной связи Как было отмечено, механизмы (дуги с нижней стороны) показывают средства, с помощью которых осуществляется выполнение функций. Механизм может быть человеком, компьютером или любым другим устройством, которое помогает выполнять данную функцию (рисунок 1.5). Рисунок 1.5 – Пример механизма Каждый блок на диаграмме имеет свой номер. Блок любой диаграммы может быть далее описан диаграммой нижнего уровня, которая, в свою очередь, может быть далее детализирована с помощью необходимого числа диаграмм. Таким образом, формируется иерархия диаграмм. Для того, чтобы указать положение любой диаграммы или блока в иерархии, используются номера диаграмм. Например, А21 является диаграммой, которая детализирует блок 1 на диаграмме А2. Аналогично, А2 детализирует блок 2 на диаграмме А0, которая является самой верхней диаграммой модели. На рисунке 1.6 показано типичное дерево диаграмм. Рисунок 1.6 – Иерархия диаграмм На рисунке 1.7представлена SADT-модель деятельности предприятия, основанная на принципе «изготовление на заказ». Методология SADT может использоваться для моделирования широкого круга систем и определения требований и функций, а затем для разработки системы, которая удовлетворяет этим требованиям и реализует эти функции. Для уже существующих систем SADT может быть использована для анализа функций, выполняемых системой, а также для указания механизмов, посредством которых они осуществляются. Т.к. SADT создавалось – как средство моделирования систем, то согласование SADT-модели с ERD практически невозмож­но или носит искусственный характер. 1.3 Моделирование потоков данных (процессов) Диаграммы потоков данных(DataFlowDiagrams– DFD) /6/ представляют собой иерархию функциональных процессов, связанных потоками данных. Цель такого представления – продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами. В основе данной методологии лежит построение модели анализируемой ИС – проектируемой или реально существующей. В соответствии с методологией модель системы определяется как иерархия диаграмм потоков данных (DFD), описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи пользователю. Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы ИС с внешними входами и выходами. Они детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока не будет достигнут такой уровень декомпозиции, на котором процесс становятся элементарными и детализировать их далее невозможно. Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те в свою очередь преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям – потребителям информации. Таким образом, основными компонентами диаграмм потоков данных являются: • внешние сущности; • системы/подсистемы; • процессы; • накопители данных; • потоки данных. Внешние сущности Внешняя сущность представляет собой материальный предмет или физическое лицо, представляющее собой источник или приемник информации, например, заказчики, персонал, поставщики, клиенты, склад. Определение некоторого объекта или системы в качестве внешней сущности указывает на то, что она находится за пределами границ анализируемой ИС. В процессе анализа некоторые внешние сущности могут быть перенесены внутрь диаграммы анализируемой ИС, если это необходимо, или, наоборот, часть процессов ИС может быть вынесена за пределы диаграммы и представлена как внешняя сущность. Внешняя сущность обозначается квадратом (рисунок 1.8), расположенным как бы «над» диаграммой и бросающим на нее тень, для того, чтобы можно было выделить этот символ среди других обозначений: Рисунок 1.8 – Внешняя сущность Системы и подсистемы При построении модели сложной ИС она может быть представлена в самом общем виде на так называемой контекстной диаграмме в виде одной системы как единого целого, либо может быть декомпозирована на ряд подсистем. Подсистема (или система) на контекстной диаграмме изображается следующим образом (рисунок 1.9). Рисунок 1.9 – Подсистема Номер подсистемы служит для ее идентификации. В поле имени вводится наименование подсистемы в виде предложения с подлежащим и соответствующими определениями и дополнениями. Процессы Процесс представляет собой преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом. Физически процесс может быть реализован различными способами: это может быть подразделение организации (отдел), выполняющее обработку входных документов и выпуск отчетов, программа, аппаратно реализованное логическое устройство и т.д. Процесс на диаграмме потоков данных изображается, как показано на рисунке 1.10. Рис. 1.10 – Процесс Номер процесса служит для его идентификации. В поле имени вводится наименование процесса в виде предложения с активным недвусмысленным глаголом в неопределенной форме (вычислить, рассчитать, проверить, определить, создать, получить), за которым следуют существительные в винительном падеже, например: • «Ввести сведения о клиентах»; • «Выдать информацию о текущих расходах»; • «Проверить кредитоспособность клиента». Использование таких глаголов, как «обработать», «модернизировать» или «отредактировать» означает, как правило, недостаточно глубокое понимание данного процесса и требует дальнейшего анализа. Информация в поле физической реализации показывает, какое подразделение организации, программа или аппаратное устройство выполняет данный процесс. Накопители данных Накопитель данных представляет собой абстрактное устройство для хранения информации, которую можно в любой момент поместить в накопитель и через некоторое время извлечь, причем способы помещения и извлечения могут быть любыми. Накопитель данных может быть реализован физически в виде микрофиши, ящика в картотеке, таблицы в оперативной памяти, файла на магнитном носителе и т.д. Накопитель данных на диаграмме потоков данных изображается, как показано на рисунке 1.11. Рисунок 1.11 – Накопитель данных Накопитель данных идентифицируется буквой «D» и произвольным числом. Имя накопителя выбирается из соображения наибольшей информативности для проектировщика. Накопитель данных в общем случае является прообразом будущей базы данных и описание хранящихся в нем данных должно быть увязано с информационной моделью. Потоки данных Поток данных определяет информацию, передаваемую через некоторое соединение от источника к приемнику. Реальный поток данных может быть информацией, передаваемой по кабелю между двумя устройствами, пересылаемыми по почте письмами, магнитными лентами или дискетами, переносимыми с одного компьютера на другой и т.д. Поток данных на диаграмме изображается линией, оканчивающейся стрелкой, которая показывает направление потока (рисунок 1.12). Каждый поток данных имеет имя, отражающее его содержание. Рисунок 1.12 – Поток данных Построение иерархии диаграмм потоков данных Первым шагом при построении иерархии DFD является построение контекстных диаграмм. Обычно при проектировании относительно простых ИС строится единственная контекстная диаграмма со звездообразной топологией, в центре которой находится так называемый главный процесс, соединенный с приемниками и источниками информации, посредством которых с системой взаимодействуют пользователи и другие внешние системы. Если же для сложной системы ограничиться единственной контекстной диаграммой, то она будет содержать слишком большое количество источников и приемников информации, которые трудно расположить на листе бумаги нормального формата, и кроме того, единственный главный процесс не раскрывает структуры распределенной системы. Признаками сложности (в смысле контекста) могут быть: • наличие большого количества внешних сущностей (десять и более); • распределенная природа системы; • многофункциональность системы с уже сложившейся или выявленной группировкой функций в отдельные подсистемы. Для сложных ИС строится иерархия контекстных диаграмм. При этом контекстная диаграмма верхнего уровня содержит не единственный главный процесс, а набор подсистем, соединенных потоками данных. Контекстные диаграммы следующего уровня детализируют контекст и структуру подсистем. Иерархия контекстных диаграмм определяет взаимодействие основных функциональных подсистем проектируемой ИС как между собой, так и с внешними входными и выходными потоками данных и внешними объектами (источниками и приемниками информации), с которыми взаимодействует ИС. Разработка контекстных диаграмм решает проблему строгого определения функциональной структуры ИС на самой ранней стадии ее проектирования, что особенно важно для сложных многофункциональных систем, в разработке которых участвуют разные организации и коллективы разработчиков. После построения контекстных диаграмм полученную модель следует проверить на полноту исходных данных об объектах системы и изолированность объектов (отсутствие информационных связей с другими объектами). Для каждой подсистемы, присутствующей на контекстных диаграммах, выполняется ее детализация при помощи DFD. Каждый процесс на DFD, в свою очередь, может быть детализирован при помощи DFDили миниспецификации. При детализации должны выполняться следующие правила: • правило балансировки – означает, что при детализации подсистемы или процесса детализирующая диаграмма в качестве внешних источников/приемников данных может иметь только те компоненты (подсистемы, процессы, внешние сущности, накопители данных), с которыми имеет информационную связь детализируемая подсистема или процесс на родительской диаграмме; • правило нумерации – означает, что при детализации процессов должна поддерживаться их иерархическая нумерация. Например, процессы, детализирующие процесс с номером 12, получают номера 12.1, 12.2, 12.3 и т.д. Миниспецификация (описание логики процесса) должна формулировать его основные функции таким образом, чтобы в дальнейшем специалист, выполняющий реализацию проекта, смог выполнить их или разработать соответствующую программу. Миниспецификация является конечной вершиной иерархии DFD. Решение о завершении детализации процесса и использовании миниспецификации принимается аналитиком исходя из следующих критериев: • наличия у процесса относительно небольшого количества входных и выходных потоков данных (2–3 потока); • возможности описания преобразования данных процессом в виде последовательного алгоритма; • выполнения процессом единственной логической функции преобразования входной информации в выходную; • возможности описания логики процесса при помощи миниспецификации небольшого объема (не более 20–30 строк). При построении иерархии DFD переходить к детализации процессов следует только после определения содержания всех потоков и накопителей данных, которое описывается при помощи структур данных. Структуры данных конструируются из элементов данных и могут содержать альтернативы, условные вхождения и итерации. Условное вхождение означает, что данный компонент может отсутствовать в структуре. Альтернатива означает, что в структуру может входить один из перечисленных элементов. Итерация означает вхождение любого числа элементов в указанном диапазоне. Для каждого элемента данных может указываться его тип (непрерывные или дискретные данные). Для непрерывных данных может указываться единица измерения (кг, см и т.п.), диапазон значений, точность представления и форма физического кодирования. Для дискретных данных может указываться таблица допустимых значений. После построения законченной модели системы ее необходимо верифицировать (проверить на полноту и согласованность). В полной модели все ее объекты (подсистемы, процессы, потоки данных) должны быть подробно описаны и детализированы. Выявленные недетализированные объекты следует детализировать, вернувшись на предыдущие шаги разработки. В согласованной модели для всех потоков данных и накопителей данных должно выполняться правило сохранения информации: все поступающие куда-либо данные должны быть считаны, а все считываемые данные должны быть записаны. На рисунке 1.13изображена DFD-диаграмма предприятия, изготавливающего продукцию на заказ. Эта диаграмма представляет самый верхний уровень функциональной модели. Естественно, это весьма грубое описание предметной области. Уточнение модели производится путем детализации необходимых функций на DFD-диаграмме следующего уровня. Так мы можем разбить функцию «Определение потребностей и обеспечение материалами» на подфункции «Определение потребностей», «Поиск поставщиков», «Заключение и анализ договоров на поставку», «Контроль платежей», «Контроль поставок», связанные собственными потоками данных, которые будут представлены на отдельной диаграмме. Детализация модели должна производится до тех пор, пока она не будет содержать всю информацию, необходимую для построения информационной системы. Рисунок 1.13– Пример DFD-диаграммы Практически любой класс систем успешно моде­лируется при помощи DFD-ориентированных методов. Но хотя, в отличие от SADT, DFD и ERD взаимно дополняют друг друга и являются согласованными, посколь­ку в DFD присутствует описание структур данных, непосредственно используемое для построения ERD, DFD дает только слабо структурированную модель БД. 1.4 Моделирование данных: Case-метод Баркера Цель моделирования данных состоит в обеспечении разработчика ИС концептуальной схемой базы данных в форме одной модели или нескольких локальных моделей, которые относительно легко могут быть отображены в любую систему баз данных. Наиболее распространенным средством проектирования данных являются диаграммы «сущность-связь» (ERD)/7, 8/, которые предназначены для разработки моделей данных и отношений между ними. Нотация ERD была впервые введена П. Ченом (Chen) и получила дальнейшее развитие в работах Баркера. ER-модель – это отражение реального мира в виде сущностей (Entity) и связей между ними (Relationship). Фактически с помощью ERD осуществляется детализация хранилищ данных проектируемой системы, а также документируются сущности системы и способы их взаимодействия, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их отношений с другими объектами (связей). Сущность (Entity)– реальный либо воображаемый объект, имеющий существенное значение для рассматриваемой предметной области, информация о котором подлежит хранению (рисунок 1.14). Рисунок 1.14 – Графическое изображение сущности Сущность представляет собой множество экземпляров реальных или абстрактных объектов (людей, событий, состояний, идей, предметов и т.п.), обладающих общими атрибутами или характеристиками. Любой объект может быть представлен только одной сущностью, которая должна быть уникально унифицирована. При этом имя сущности должно отражать тип или класс объекта, а не его конкретный экземпляр (например, АЭРОПОРТ, а не ВНУКОВО). Каждая сущность должна обладать уникальным идентификатором. Каждый экземпляр сущности должен однозначно идентифицироваться и отличаться от всех других экземпляров данного типа сущности. Каждая сущность должна обладать некоторыми свойствами: • каждая сущность должна иметь уникальное имя, и к одному и тому же имени должна всегда применяться одна и та же интерпретация. Одна и та же интерпретация не может применяться к различным именам, если только они не являются псевдонимами; • сущность обладает одним или несколькими атрибутами, которые либо принадлежат сущности, либо наследуются через связь; • сущность обладает одним или несколькими атрибутами, которые однозначно идентифицируют каждый экземпляр сущности; • каждая сущность может обладать любым количеством связей с другими сущностями модели. Для идентификации требований, в соответствии с которыми сущности вовлекаются в отношения, используются связи. Связь (Relationship) – поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области. Связь – это ассоциация между сущностями, при которой, как правило, каждый экземпляр одной сущности, называемой родительской сущностью, ассоциирован с произвольным (в том числе нулевым) количеством экземпляров второй сущности, называемой сущностью-потомком, а каждый экземпляр сущности-потомка ассоциирован в точности с одним экземпляром сущности-родителя. Таким образом, экземпляр сущности-потомка может существовать только при существовании сущности родителя. Связи может даваться имя, выражаемое грамматическим оборотом глагола и помещаемое возле линии связи. Имя каждой связи между двумя данными сущностями должно быть уникальным, но имена связей в модели не обязаны быть уникальными. Имя связи всегда формируется с точки зрения родителя, так что предложение может быть образовано соединением имени сущности-родителя, имени связи, выражения степени и имени сущности-потомка. Для большинства приложений достаточно использовать следующие типы отношений: 1) Связь 1:1 (один-к-одному) предполагает, что в каждый момент времени одному экземпляру информационного объекта А соответствует не более одного экземпляра информационного объекта В и наоборот. Отношения данного типа используются, как правило, на верхних уровнях иерархии модели данных, а на нижних уровнях встречаются сравнительно редко. 2) При связи 1:n (один-ко-многим) одному экземпляру информационного объекта А соответствует любое количество экземпляров объекта В, но каждый экземпляр объекта В связан не более, чем с одним экземпляром объекта А. Отношения данного типа являются наиболее часто используемыми. 3) Связь n:m (многие-ко-многим) предполагает, что в каждый момент времени одному экземпляру информационного объекта А соответствует любое количество экземпляров объекта В и наоборот. Отношения данного типа обычно используются на ранних этапах проектирования с целью прояснения ситуации. В дальнейшем каждое из таких отношений должно быть преобразовано в комбинацию отношений типов 1 и 2 (возможно, с добавлением вспомогательных ассоциативных сущностей и с введением новых отношений). Например, связь продавца с контрактом может быть выражена следующим образом: • продавец может получить вознаграждение за 1 или более контрактов; • контракт должен быть инициирован ровно одним продавцом. Степень связи и обязательность графически изображаются согласно рисунку1.15. Рисунок 1.15 – Степень и обязательность связи Таким образом, два предложения, описывающие связь продавца с контрактом, графически будут выражены как показано на рисунке1.16. Рисунок 1.16– Пример обязательности и степени связи Описав также связи остальных сущностей, получим схему, представленную на рисунке1.17. Рисунок 1.17 – Пример ER-диаграммы Последним шагом моделирования является идентификация атрибутов. Атрибут– любая характеристика сущности, значимая для рассматриваемой предметной области и предназначенная для квалификации, идентификации, классификации, количественной характеристики или выражения состояния сущности. Атрибут представляет тип характеристик или свойств, ассоциированных со множеством реальных или абстрактных объектов (людей, мест, событий, состояний, идей, пар предметов и т.д.). Экземпляр атрибута – это определенная характеристика отдельного элемента множества. Экземпляр атрибута определяется типом характеристики и ее значением, называемым значением атрибута. В ER-модели атрибуты ассоциируются с конкретными сущностями. Таким образом, экземпляр сущности должен обладать единственным определенным значением для ассоциированного атрибута. Атрибут может быть либо обязательным, либо необязательным (рисунок 1.18). Обязательность означает, что атрибут не может принимать неопределенных значений (nullvalues). Атрибут может быть либо описательным (т.е. обычным дескриптором сущности), либо входить в состав уникального идентификатора (первичного ключа). Уникальный идентификатор– это атрибут или совокупность атрибутов и/или связей, предназначенная для уникальной идентификации каждого экземпляра данного типа сущности. В случае полной идентификации каждый экземпляр данного типа сущности полностью идентифицируется своими собственными ключевыми атрибутами, в противном случае в его идентификации участвуют также атрибуты другой сущности-родителя (рисунок 1.19). Рисунок 1.18 – Атрибут сущности Рисунок 1.19 – Идентификация сущности Каждый атрибут идентифицируется уникальным именем, выражаемым грамматическим оборотом существительного, описывающим представляемую атрибутом характеристику. Атрибуты изображаются в виде списка имен внутри блока ассоциированной сущности, причем каждый атрибут занимает отдельную строку. Атрибуты, определяющие первичный ключ, размещаются наверху списка и выделяются знаком «#». Каждая сущность должна обладать хотя бы одним возможным ключом. Возможный ключ сущности – это один или несколько атрибутов, чьи значения однозначно определяют каждый экземпляр сущности. При существовании нескольких возможных ключей один из них обозначается в качестве первичного ключа, а остальные – как альтернативные ключи. С учетом имеющейся информации построенная ранее диаграмма на рисунке 1.17 преобразуется в диаграмму на рисунке1.20. Помимо перечисленных основных конструкций модель данных может содержать ряд дополнительных. Подтипы и супертипы: одна сущность является обобщающим понятием для группы подобных сущностей (рисунок 1.21). Взаимно исключающие связи: каждый экземпляр сущности участвует только в одной связи из группы взаимно исключающих связей (рисунок 1.22). Рисунок 1.20 – Пример ER-диаграммы с ключами Рисунок 1.21 – Подтипы и супертипы Рисунок 1.22 – Взаимно исключающие связи Рекурсивная связь: сущность может быть связана сама с собой (рисунок 1.23). Неперемещаемые (non-transferrable) связи: экземпляр сущности не может быть перенесен из одного экземпляра связи в другой (рисунок 1.24). Рисунок 1.23 – Рекурсивная связь Рисунок 1.24 – Неперемещаемаясвязь Сегодня ER-моделирование является самым распространенным методом построения моделей ИС. Многие из методик ER-моделирования легли в основу современных автоматизированных систем проектирования баз данных либо используются при неавтоматизированной разработке. Однако практика реального проектирования показывает, что для понимания (и, тем более, составления) ER-диаграмм требуется довольно высокий уровень подготовки. 1.5 Объектно-ориентированный подход в проектировании ИС Объектно-ориентированный подход/1/ использует объектную декомпозицию, при этом статическая структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами. Каждый объект системы обладает своим собственным поведением, моделирующим поведение объекта реального мира. Концептуальной основой объектно-ориентированного подхода является объектная модель. Основными ее элементами являются: абстрагирование; инкапсуляция; модульность. Существуют также и другие элементы, такие как иерархия, типизация, параллелизм, устойчивость. Определение объектов и классов является основной задачей объектно-ориентированного подхода. Объект определяется как осязаемая реальность (tangibleentity) – предмет или явление, имеющий четко определяемое поведение. Объект обладает состоянием, поведением и индивидуальностью. Структура и поведение схожих объектов определяют общий для них класс. Состояние объекта характеризуется перечнем всех возможных (статических) свойств данного объекта и текущими значениями (динамическими) каждого из этих свойств. Поведение характеризует воздействие объекта на другие объекты и наоборот относительно изменения состояния: этих объектов и передачи сообщений. Иначе говоря, поведение объекта полностью определяется его действиями. Индивидуальность – это свойства объекта, отличающие его от всех других объектов. Класс – это множество объектов, связанных общностью структуры и поведения. Любой объект является экземпляром класса. Определение классов и объектов – одна из самых сложных задач объектно-ориентированного проектирования. Важным качеством объектного подхода является согласованность моделей проектируемой системы от стадии формирования требований до стадии реализации. Требование согласованности моделей выполняется благодаря возможности применения абстрагирования, модульности, полиморфизма на всех стадиях разработки. 1.6 Унифицированный язык моделирования UML В быстроразвивающейся сфере разработки объектно-ориентированных приложений становится все труднее и труднее создавать и поддерживать приложения, обладающим высоким качеством, укладываясь при этом в разумные временные рамки. Унифицированный язык моделирования (UnifiedModelingLanguage, UML) /9, 10, 11/появился как ответ на потребность в универсальном языке объектного моделирования, который могла бы использовать любая компания. Большинство существующих методов объектно-ориентированного анализа и проектирования (ООАП) включают как язык моделирования, так и описание процесса моделирования. Язык моделирования – это нотация (в основном графическая), которая используется методом для описания проектов. Нотация представляет собор совокупность графических объектов, которые используются в моделях; она является синтаксисом языка моделирования. Унифицированный язык моделирования UML (UnifiedModelingLanguage) – является прямым объединением и унификацией объектно-ориентированных методов Буча, Рамбо и Якобсона, и дополняет их новыми возможностями. Главными в разработке UML были следующие цели: • предоставить пользователям готовый к использованию выразительный язык визуального моделирования, позволяющий разрабатывать осмысленные модели и обмениваться ими; • предусмотреть механизмы расширяемости и специализации для расширения базовых концепций; • обеспечить независимость от конкретных языков программирования и процессов разработки; • обеспечить формальную основу для понимания этого языка моделирования (язык должен быть одновременно точным и доступным для понимания, без лишнего формализма); • стимулировать рост рынка объектно-ориентированных инструментальных средств. Унифицированный язык моделирования UML (UnifiedModelingLanguage) представляет собой язык для определения, представления, проектирования и документирования программных систем, организационно-экономических систем, технических систем и других систем различной природы. UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов. Большинство современных методов ООАП основаны на использовании языка UML. UML находится в процессе стандартизации, проводимом OMG (ObjectManagementGroup) – организацией по стандартизации в области объектно-ориентированных методов и технологий, в настоящее время принят в качестве стандартного языка моделирования и получил широкую поддержку в индустрии ПО. UML принят на вооружение практически всеми крупнейшими компаниями – производителями ПО (Microsoft,Oracle, IBM,Hewlett-Packard,Sybase и др.). Кроме того, практически все мировые производители CASE-средств, помимо IBMRationalSoftware, поддерживают UML в своих продуктах (OracleDesigner,TogetherControlCenter (Borland),AllFusionComponentModeler(ComputerAssociates),MicrosoftVisualModeler и др.). Стандарт UML версии 1.1, принятый OMG в 1997 г., содержит следующий набор диаграмм: Структурные (structural) модели: • диаграммы классов (classdiagrams) – для моделирования статической структуры классов системы и связей между ними; • диаграммы компонентов (componentdiagrams) – для моделирования иерархии компонентов (подсистем) системы; • диаграммы размещения (deploymentdiagrams) – для моделирования физической архитектуры системы. Модели поведения (behavioral): • диаграммы вариантов использования (usecasediagrams) – для моделирования функциональных требований к системе (в виде сценариев взаимодействия пользователей с системой); • диаграммы взаимодействия (interaction diagrams); • диаграммы последовательности (sequencediagrams) и кооперативные диаграммы (collaborationdiagrams) – для моделирования процесса обмена сообщениями между объектами; • диаграммы состояний (statechartdiagrams) – для моделирования поведения объектов системы при переходе из одного состояния в другое; • диаграммы деятельности (activitydiagrams) – для моделирования поведения системы в рамках различных вариантов использования, или потоков управления. Диаграммы вариантов использования показывают взаимодействия между вариантами использования и действующими лицами, отражая функциональные требования к системе с точки зрения пользователя. Цель построения диаграмм вариантов использования – это документирование функциональных требований в самом общем виде, поэтому они должны быть предельно простыми. Вариант использования представляет собой последовательность действий (транзакций), выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом (действующим лицом). Вариант использования описывает типичное взаимодействие между пользователем и системой и отражает представление о поведении системы с точки зрения пользователя. В простейшем случае вариант использования определяется в процессе обсуждения с пользователем тех функций, которые он хотел бы реализовать, или целей, которые он преследует по отношению к разрабатываемой системе. Действующие лица не обязаны быть людьми. Действующее лицо может также быть внешней системой, которой необходима некоторая информация от нашей системы. На рисунке 1.25 можно наблюдать такое действие, как обновление счетов для Системы учета. Рисунок 1.25 – Диаграмма варрантов использования Диаграмма вариантов использования является самым общим представлением функциональных требований к системе. Для последующего проектирования системы требуются более конкретные детали, которые описываются в документе, называемом «сценарием варианта использования» или «потоком событий». Сценарий подробно документирует процесс взаимодействия действующего лица с системой, реализуемого в рамках варианта использования. Основной поток событий описывает нормальный ход событий (при отсутствии ошибок). Альтернативные потоки описывают отклонения от нормального хода событий (ошибочные ситуации) и их обработку. Достоинства модели вариантов использования заключаются в том, что она: • определяет пользователей и границы системы; • определяет системный интерфейс; • удобна для общения пользователей с разработчиками; • используется для написания тестов; • является основой для написания пользовательской документации; • хорошо вписывается в любые методы проектирования (как объектно-ориентированные, так и структурные). Диаграммы взаимодействия описывают поведение взаимодействующих групп объектов (в рамках варианта использования или некоторой операции класса). Как правило, диаграмма взаимодействия охватывает поведение объектов в рамках только одного потока событий варианта использования. На такой диаграмме отображается ряд объектов и те сообщения, которыми они обмениваются между собой. Существует два вида диаграмм взаимодействия: диаграммы последовательности и кооперативные диаграммы. Диаграммы последовательности отражают временную последовательность событий, происходящих в рамках варианта использования, а кооперативные диаграммы концентрируют внимание на связях между объектами. Диаграмма классов определяет типы классов системы и различного рода статические связи, которые существуют между ними. На диаграммах классов изображаются также атрибуты классов, операции классов и ограничения, которые накладываются на связи между классами. Вид и интерпретация диаграммы классов существенно зависит от точки зрения (уровня абстракции): классы могут представлять сущности предметной области (в процессе анализа) или элементы программной системы (в процессах проектирования и реализации). На рисунке 1.26 изображена типичная диаграмма классов. Рисунок 1.26 – Диаграмма классов Диаграммы состояний определяют все возможные состояния, в которых может находиться конкретный объект, а также процесс смены состояний объекта в результате наступления некоторых событий. Диаграммы состояний не надо создавать для каждого класса, они применяются только в сложных случаях. Если объект класса может существовать в нескольких состояниях и в каждом из них ведет себя по-разному, для него может потребоваться такая диаграмма. На рисунке 1.27 показана диаграмма состояний UML, отражающая поведение заказа в системе обработки заказов. На диаграмме изображены различные состояния, в которых может находиться заказ. Рисунок 1.27 – Диаграмма состояний Диаграммы деятельности, в отличие от большинства других средств UML, заимствуют идеи из нескольких различных методов, в частности, метода моделирования состояний SDL и сетей Петри. Эти диаграммы особенно полезны в описании поведения, включающего большое количество параллельных процессов. Диаграммы деятельности являются также полезными при параллельном программировании, поскольку можно графически изобразить все ветви и определить, когда их необходимо синхронизировать. Диаграммы деятельности можно применять для описания потоков событий в вариантах использования. С помощью текстового описания можно достаточно подробно рассказать о потоке событий, но в сложных и запутанных потоках с множеством альтернативных ветвей будет трудно понять логику событий. Диаграммы деятельности предоставляют ту же информацию, что и текстовое описание потока событий, но в наглядной графической форме. Диаграммы компонентов моделируют физический уровень системы. На них изображаются компоненты ПО и связи между ними. На такой диаграмме обычно выделяют два типа компонентов: исполняемые компоненты и библиотеки кода. Каждый класс модели (или подсистема) преобразуется в компонент исходного кода. Между отдельными компонентами изображают зависимости, соответствующие зависимостям на этапе компиляции или выполнения программы. Диаграммы компонентов применяются теми участниками проекта, кто отвечает за компиляцию и сборку системы. Они нужны там, где начинается генерация кода. Диаграмма размещения отражает физические взаимосвязи между программными и аппаратными компонентами системы. Она является хорошим средством для того, чтобы показать размещение объектов и компонентов в распределенной системе. Диаграмма размещения показывает физическое расположение сети и местонахождение в ней различных компонентов. Ее основными элементами являются узел (вычислительный ресурс) и соединение – канал взаимодействия узлов (сеть). Диаграмма размещения используется менеджером проекта, пользователями, архитектором системы и эксплуатационным персоналом, чтобы понять физическое размещение системы и расположение ее отдельных подсистем. UML обладает механизмами расширения, предназначенными для того, чтобы разработчики могли адаптировать язык моделирования к своим конкретным нуждам, не меняя при этом его метамодель. Наличие механизмов расширения принципиально отличает UML от таких средств моделирования, как IDEF0, IDEF1X, IDEF3, DFD и ERM. Перечисленные языки моделирования можно определить как сильно типизированные (по аналогии с языками программирования), поскольку они не допускают произвольной интерпретации семантики элементов моделей. UML, допуская такую интерпретацию (в основном за счет стереотипов), является слабо типизированным языком. К его механизмам расширения относятся: • стереотипы; • тегированные (именованные) значения; • ограничения. Стереотип – это новый тип элемента модели, который определяется на основе уже существующего элемента. Стереотипы расширяют нотацию модели и могут применяться к любым элементам модели. Стереотипы классов – это механизм, позволяющий разделять классы на категории. Разработчики ПО могут создавать свои собственные наборы стереотипов, формируя тем самым специализированные подмножества UML (например, для описания бизнес-процессов, Web-приложений, баз данных и т.д.). Такие подмножества (наборы стереотипов) в стандарте языка UML носят название профилей языка. Именованное значение – это пара строк «тег = значение», или «имя = содержимое», в которых хранится дополнительная информация о каком-либо элементе системы, например, время создания, статус разработки или тестирования, время окончания работы над ним и т.п. Ограничение – это семантическое ограничение, имеющее вид текстового выражения на естественном или формальном языке (OCL–ObjectConstraintLanguage), которое невозможно выразить с помощью нотации UML. 1.7 Сопоставление и взаимосвязь структурного и объектно-ориентированного подходов ГрадиБуч сформулировал главное достоинство объектно-ориентированного подхода (ООП) следующим образом: объектно-ориентированные системы более открыты и легче поддаются внесению изменений, поскольку их конструкция базируется на устойчивых формах. Это дает возможность системе развиваться постепенно и не приводит к полной ее переработке даже в случае существенных изменений исходных требований. Буч отметил также ряд следующих преимуществ ООП: • объектная декомпозиция дает возможность создавать программные системы меньшего размера путем использования общих механизмов, обеспечивающих необходимую экономию выразительных средств. Использование ООП существенно повышает уровень унификации разработки и пригодность для повторного использования не только ПО, но и проектов, что в конце концов ведет к сборочному созданию ПО. Системы зачастую получаются более компактными, чем их не объектно-ориентированные эквиваленты, что означает не только уменьшение объема программного кода, но и удешевление проекта за счет использования предыдущих разработок; • объектная декомпозиция уменьшает риск создания сложных систем ПО, так как она предполагает эволюционный путь развития системы на базе относительно небольших подсистем. Процесс интеграции системы растягивается на все время разработки, а не превращается в единовременное событие; • объектная модель вполне естественна, поскольку в первую очередь ориентирована на человеческое восприятие мира, а не на компьютерную реализацию; • объектная модель позволяет в полной мере использовать выразительные возможности объектных и объектно-ориентированных языков программирования. К недостаткам ООП относятся некоторое снижение производительности функционирования ПО (которое, однако, по мере роста производительности компьютеров становится все менее заметным) и высокие начальные затраты. Объектная декомпозиция существенно отличается от функциональной, поэтому переход на новую технологию связан как с преодолением психологических трудностей, так и дополнительными финансовыми затратами. При переходе от структурного подхода к объектному, как при всякой смене технологии, необходимо вкладывать деньги в приобретение новых инструментальных средств. Здесь следует учесть расходы на обучение методу, инструментальным средствам и языку программирования. Для некоторых организаций эти обстоятельства могут стать серьезными препятствиями. Объектно-ориентированный подход не дает немедленной отдачи. Эффект от его применения начинает сказываться после разработки двух–трех проектов и накопления повторно используемых компонентов, отражающих типовые проектные решения в данной области. Переход организации на объектно-ориентированную технологию – это смена мировоззрения, а не просто изучение новых CASE-средств и языков программирования. Таким образом, структурный подход по-прежнему сохраняет свою значимость и достаточно широко используется на практике. На примере языка UML хорошо видно, что его авторы заимствовали то рациональное, что можно было взять из структурного подхода: элементы функциональной декомпозиции в диаграммах вариантов использования, диаграммы состояний, диаграммы деятельности и др. Очевидно, что в конкретном проекте сложной системы невозможно обойтись только одним способом декомпозиции. Можно начать декомпозицию каким-либо одним способом, а затем, используя полученные результаты, попытаться рассмотреть систему с другой точки зрения. Основой взаимосвязи междуструктурным и объектно-ориентированным подходами является общность ряда категорий и понятий обоих подходов (процесс и вариант использования, сущность и класс и др.). Эта взаимосвязь может проявляться в различных формах. Так, одним из возможных вариантов является использование структурного анализа как основы для объектно-ориентированного проектирования. При этом структурный анализ следует прекращать, как только структурные модели начнут отражать не только деятельность организации (бизнес-процессы), а и систему ПО. После выполнения структурного анализа можно различными способами приступить к определению классов и объектов. Так, если взять какую-либо отдельную диаграмму потоков данных, то кандидатами в классы могут быть элементы структур данных. Другой формой проявления взаимосвязи можно считать интеграцию объектной и реляционной технологий. Реляционные СУБД являются на сегодняшний день основным средством реализации крупномасштабных баз данных и хранилищ данных. Причины этого достаточно очевидны: реляционная технология используется достаточно долго, освоена огромным количеством пользователей и разработчиков, стала промышленным стандартом, в нее вложены значительные средства и создано множество корпоративных БД в самых различных отраслях, реляционная модель проста и имеет строгое математическое основание; существует большое разнообразие промышленных средств проектирования, реализации и эксплуатации реляционных БД. Вследствие этого реляционные БД в основном используются для хранения и поиска объектов в так называемых объектно-реляционных системах. 2 ТЕХНОЛОГИЯ ПРОЕКТИРОВАНИЯ ИС НА ОСНОВЕ ФАКТОГРАФИЧЕСКОЙ МОДЕЛИ ДАННЫХ 2.1 Фактографическая модель данных Основная цель ИС – обработкаинформации. Результат – тоже информация. Единственное, что может получить пользователь от ИС – нужная ему информация. Поэтому определение ИС надо начинать с выходной информации. Модель ИС для заказчика – это «собеседник», умеющий сообщать полезную информацию. Основной элемент модели таким образом– информация. Наиболее понятное для заказчика ее представление – текстна естественном языке. Фактографическая модель данных /14/ пользует для проектирования ИС естественно-языковое описание, что позволяет формулировку технических требований к информационной системе экспертом в прикладной области. Будем считать, что общение пользователя с ИС ограничено применением некоторого подмножества сообщений, структура которых не может быть произвольной, а зафиксирована разработчиком. Одно такое сообщение называется «фактом». «Факт» – фраза (высказывание) на естественном языке, обязательно содержащая подчеркнутые слова или их группы. Позицию во фразе, содержащую подчеркнутые общей чертой слова, назовем «параметром» факта, а сами подчеркнутые слова – «значением параметра». Естественный язык, на котором записаны факты, будем считать фиксированным и называть «базовым языком» фактографической модели данных. Факты А и В «имеют одинаковую структуру», если они отличаются только значениями параметров. «Структура фактографической модели данных» («структура ФМД») – множество фактов, имеющих попарно различную структуру. Факты, образующие структуру ФМД, будем называть «примерами фактов». «Состояние ФМД, соответствующее данной структуре Х» – неупорядоченное множество фактов, каждый из которых имеет одинаковую структуру с каким-либо фактом из Х и является допустимым по семантическим ограничениям, налагаемым базовым языком. Заметим, что учет семантических ограничений базового языка означает, что использование ФМД требует понимания его семантики и, следовательно, ФМД – абстрактная модель, рассчитанная на использование человеком, а не на автоматическую обработку. «Фактографическая модель данных» – пара, состоящая из структуры ФМД и множества всех возможных состояний ФМД, соответствующих этой структуре. «Домен» параметра факта из структуры Х данной ФМД – множество значений, которые могут заменять этот параметр в фактах такой же структуры в каком-либо из состояний, соответствующих Х. Определенная таким образом факто­графи­ческая модель обладает свойством «самоописываемости» (selfdescription), поскольку семантика факта, как элемента формальной модели, определяется его смыслом как естественноязыковой фразы. Фактографическая модель данных (ФМД) эквивалентна реляционной модели. Любой ФМД можно поставить в соответствие некоторую модель РБД по следующим правилам: • каждому факту из структуры ФМД, имеющему n параметров поставим в соответствие отношение РБД степени n; • каждому состоянию ФМД поставим в соответствие состояние РБД, причем каждому факту должен соответствовать кортеж, составленный из нормализованных значений параметра факта; • каждому домену D параметра факта поставим в соответствие домен параметра отношения РБД, состоящий из нормализованных значений из D. Под нормализацией значений здесь понимается приведение их в нейтральную синтаксическую форму (для русского языка – именительный падеж единственного числа). Если же для произвольно взятой модели РБД зафиксирована ее семантика, то ей можно поставить в соответствие модель ФМД, причем каждому кортежу РБД ставится в соответствие факт – фраза базового языка, выражающая семантику этого кортежа. Эта фраза, очевидно, должна включать значения элементов кортежа в нужной синтаксической форме, которые и являются параметрами факта. Структура ФМД получается подстановкой произвольных допустимых семантикой базового языка значений в качестве параметров каждого отношения и выражения семантики полученного кортежа в виде фразы базового языка. Описанное соответствие между реляционной и фактографической моделями будет взаимно однозначным с точностью, с одной стороны, до обозначений отношений РБД и до семантически эквивалентных фраз базового языка и значений параметров структуры ФМД – с другой. Оно индуцирует на ФМД алгебру операций, соответствующую реляционной алгебре для РБД (с учетом замены операции «равенство» на «равенство с точностью до синтаксической формы»). Приведенное выше построение показывает, что реляционная и фактографическая (с индуцированной алгеброй операций) модели имеют равные выразительные возможности. Благодаря свойству «самоописываемости» описание модели ФМД может быть прочитано и понято любым экспертом в предметной области без предварительной подготовки. Формулировка такого описания требует знания нескольких правил, но, поскольку составление технических требований на информационную систему всегда ведется в диалоге разработчика (системного аналитика, постановщика задачи, проектировщика) и эксперта-прикладника, соблюдение этих правил может обеспечить разработчик. Таким образом, участие в формулировке требований к базе данных также не потребует от эксперта-прикладника специальной подготовки. Правила составления примеров фактов – структуры ФМД. 1) Каждый приведенный в списке пример факта означает, что в базе данных будет храниться множество фактов одинаковой с приведенным примером структуры. Если во всех состояниях ФМД примеру факта будет соотвествовать единственный факт, то пример факта надо отбросить (единичные факты в базе данных не хранятся, а реализуются на программном или организационном уровне). 2) Пример факта должен содержать конкретные (хотя и гипотетические) данные. Нельзя использовать фразы «некоторый клиент», «определенный материал». Использование обобщенных наименований «клиент», «материал» для замены реальных данных вызывает путаницу в ситуациях, когда эти наименования могут быть значениями параметров в реальном состоянии ФМД. Например, параметр «тип абонента» может иметь значения «клиент» или «диспетчер», параметр «вид ресурса» – «материал» или «оборудование». Согласно многолетнему опыту почт и сберегательных касс в образцах заполнения бланков лучше писать произвольные, гипотетические фамилии и другие данные, а не слова «фамилия», «сумма» и т.п. 3) Количество параметров факта фиксировано и не будет меняться при работе системы. 4) Каждый параметр факта содержит ровно одно данное и не может содержать списков или перечислений. 5) Перечисление в факте обязательно оформляется в виде нумерованного списка. Элементы списка должны иметь одинаковую структуру. Правила 3 и 4 обеспечивают возможность преобразования ФМД в РБД и соответствуют первой нормальной форме РБД. Приведем фрагмент описания информационной системы, использующий правильно составленные примеры фактов. При расчете заработной платы система создает и печатает в виде документа «ведомость» факты вида: 1) В июне 2003 г Иванов Иван Иванович заработал 500 р 00 коп. Для создания этого факта ИС учитывала, что: 2) Иванов Иван Иванович имеет табельный номер 243 3) 20.06.03 работник с табельным номером 243 выполнил работу «изготовление стула» в объеме 5шт. 4) Тариф на выполнение 1 шт работы «изготовление стула» равен 100 р. Примеры ошибочных фактов: • 20.06.03 работник с табельным номером 243 выполнил работы «изготовление стула» и «ремонт рамы». Этот факт в другой ситуации потребует другого количества указываемых работ. Нарушено правило «фиксированное количество параметров». • 20.06.03 отсутствовали работники Иванов, Сидоров, Гречаник. Нарушено правило «один параметр содержит ровно одно данное». • Директор подписывает все документы. Факт должен иметь параметры. • Расчетный счет нашей организации – 0174600057. Ошибка в том, что это – единичный факт. Если подчеркнуть и слова «расчетный счет нашей организации», то полученный (правильный) факт будет соответствовать стандартному программному решению – таблице настроечных параметров системы. Другие факты из этой таблицы: «фамилия главного бухгалтера – Иванов», «количество номеров в гостинице – 278». • Иванов Иван Иванович получил 43кгцемента. Здесь ошибка – семантическая, а не формальная. Поскольку ФМД – неупорядоченное множество фактов, то, когда фактов с приведенной структурой будет много, невозможно будет определить, когда материал получен, по какому документу и т.п. 2.2 Обзор проектирования ИС на основе фактографической модели данных Любой проект ИС состоит из следующих компонентов: ◦ данные (информация) – что знает система; ◦ программа – что и когда делает система; ◦ интерфейс – что, когда и как делает пользователь. При фактографическом подходе проект ИС – это ее фактографическая модель, состоящая из двух компонент: набора фактов и набора ситуаций использования системы. В литературе /10, 12/ в качестве синонима термина «ситуация использования системы» встречаются «UseCase» и «вариант использования». Набор фактов соответствует данным, хранимым системой и используемым ею, а описания ситуаций (дающие ответ на вопрос: «что, кем и когда делается?») на этапе реализации соответствуют интерфейсу и программе. Целью создания системы является получение пользователем информации. Поэтому проектирование системы начинается с составления списка выдаваемых фактов (документов). Для нахождения всего множества фактов необходимо провести фактографический анализ, т.е. добавить к выдаваемым фактам справочные и минимальные. Далее все множество фактов, используемых ИС, необходимо разделитьна хранимые и не хранимые. Для каждого факта необходимо указать, в каких ситуациях он создается, читается, корректируется, удаляется и выдается (печатается). Каждая ситуация, в свою очередь, описывается списком фактов, которые в этой ситуации читаются, создаются, корректируются, удаляются и выдаются (печатаются). Формальная корректность фактографической модели ИС состоит в том, что эти списки соответствуют друг другу. Кроме того, все значения, используемые в формулах для параметров создаваемых и корректируемых фактов или в условиях, должны быть значениями параметров читаемых фактов, либо сообщены пользователем. На более поздних этапах проектирования хранимые факты представляются в виде ER-модели – традиционного средства описания структуры БД. Превращение ФМД в ER-модель делается путем вставки в нее каждого хранимого факта по формальному алгоритму, описанному вп. 2.4. Полученная ER-модель является неоптимальной, поэтому далее проводится ее анализ и оптимизация (см п.2.4). Этап перевода готовой ER-модели в базу данных в настоящее время является отработанным и имеются множество программных продуктов, реализующих его автоматически. Следующий этап – проектирование пользовательского интерфейса и реализация программной части системы. Это делается на основе описания ситуаций. Список пунктов меню системы, как правило, совпадает со списком названий ситуаций. Для каждой ситуации разрабатывается набор запросов, реализующих действия по манипуляции данными и диалоговых форм, обеспечивающий ввод пользователем информации, необходимой для работы системы, и показ ему выходных фактов, не требующих выдачи в виде печатного документа. Факты, читаемые, создаваемые, корректируемые и удаляемые системой без участия пользователя в определенной ситуации, превращаются в запросы на выборку, добавление, модификацию и удаление, а факты, читаемые (корректируемые и т.д.) пользователем, – в диалоговые формы. Выдаваемые на печать факты становятся отчетами. После визуального проектирования пользовательского интерфейса необходимо выделить события, связанные с его элементами, которые требуют особых, не предусмотренных СУБД действий. Эти действия записываются в виде программ на подходящем языке программирования и оформляются как обработчики соответствующих событий. Таким образом, можно сделать вывод, что структура программной части современной информационной системы сильно отличается от таковой для традиционных программ. Многие части (прежде всего – интерфейс пользователя и запросы на выборку и манипуляцию данными) описываются не в виде текстов программ, а в визуальной форме. Собственно программирование в традиционном стиле необходимо только для обработчиков событий, которые, как правило, представляют собой небольшие и обозримые модули. Графически соответствие компонентов проекта ИС компонентам фактографической модели этой системы, представлено в приложении А. Рассмотрим элементы фактографической модели информационной системы подробнее. 2.3 Элементы фактографической модели ИС Фактографическая модель ИС состоит из следующих элементов: ◦ список видов деятельности; ◦ список выходных документов; ◦ категории пользователей, пользующихся системой; ◦ факты, используемые ИС; ◦ ситуации использования системы. Список видов деятельности Автоматизируемые виды деятельности – это то, что раньше делалось вручную, а теперь будет делаться автоматически с помощью проектируемой системы. Для каждого автоматизируемого вида деятельности можно указать движение информации (DFD-диаграмма), участвующей в его автоматизации: откуда берется, когда, как и кем (пользователями и ИС) изменяется и кому выдается. В нем надо отметить границы ситуаций (сеансов связи) и дать им названия. Н диаграмме ситуация показывается как процесс, пользователь(-ли) – как внешняя сущность(-ти), хранимые данные – как хранилища, передача данных – стрелки. На каждый вид деятельности рисуется одна диаграмма. Во всех диаграммах одна и та же ситуация называется одинаково. Диаграммы затем сливаются. Комбинированная диаграмма показывает полные требования к каждой ситуации (что делать в ситуации). Список выходных документы Программная система может только обрабатывать, хранить и выдавать информацию. Поэтому единственный результат, который может получить пользователь от внедрения программной системы – получение определенной информации. Чтобы показать, за что платит заказчик, покупая программную систему, разработчик должен перечислить эту выдаваемую информацию, т.е. выходные документы системы. Для сокращения набора терминов в фактографическом методе «документом» называют даже данные, выдаваемые только на экран. Описание каждого выходного документа включает: 1) бланк, т.е. образец документа (обязательно заполненный); 2) виды деятельности, к автоматизации которых документ имеет отношение; 3) содержание документа в виде перечня фактов. Каждый факт – это гиперссылка в список фактов; 4) ситуации, в которых документ выдается. Категории пользователей, пользующихся системой Для каждого категории пользователей указывается название категории и ситуации, в которых пользователь обращается к системе. Факты, используемые в ИС Основные цели этого раздела: показать, откуда берется каждый факт, используемый системой, собрать список хранимых фактов (чтобы спроектировать базу данных системы), собрать список ситуаций использования системы и действий, которые должны быть проделаны с информацией в каждой из этих ситуаций (ввод, автоматическое создание, ручная или автоматическая корректировка, выдача, удаление). Описание каждого факта пишется в виде перечня пунктов, которые могут писаться многократно (например, если этот факт выдается нескольким пользователям или создается в нескольких ситуациях и т.п.) или пропускаться, если не нужны. Пункты, которые используются в описании фактов: 1) примеры факта (с названиями параметров факта); 2) хранимый факт или нет; 3) ситуации, в которых факт печатается в виде документа; 4) ситуации, в которых факт вносится в систему (создается); 5) ситуации, в которых факт читается системой; 6) ситуации, в которых факт корректируется; 7) сохраняется ли предыдущая версия факта при корректировке (в этом случае факт должен иметь пометку времени: дату, последовательный номер); 8) ситуации, в которых факт удаляется из системы. Бывает, что два примера фактов отличаются друг от друга не только значением параметра, но и какой-то частью фразы и не удается переформулировать их так, чтобы они звучали одинаково. Например, если в различающихся частях разное количество параметров, либо эти параметры имеют существенно разный смысл, т.е. принимают значения из различных списков. Такие два факта можно объединить в один, указав различающиеся части фразы на отдельных строчках через слово или. При внесении такого факта в ER-модель общая часть факта превращается в сущность А, различающиеся части фразы превращаются также в отдельные сущности, связанные с сущностью А наследованием, причем сущность А является родительской. Фактографический анализ Фактографический анализ позволяет найти все множество фактов, необходимых для работы системы исходя (первоначально) из только выдаваемых фактов (документов). При этом выявляются и добавляются к списку следующие виды фактов: 1) Минимальные факты, т.е. те, которые позволяют понять смысл отдельных параметров анализируемого факта. Называются минимальными, т.к. содержат только необходимые для понимания параметры исходного (анализируемого).В список вносятся только такие минимальные факты, которые важны для работы системы. С одним параметром может оказаться связано несколько таких фактов. Например, из факта • Животное медведьВася поселено в клетку № 27 можно выделить следующие минимальные факты, связанные с параметром клетка: • медведь может жить в клетке • Клетка № 27 подходит медведю 2) Необходимые для вычисления значений при добавлении или корректировке фактов. Так для факта • на 01.01.05 материала цемент осталось 30кг для вычисления количества стульев требуются следующие факты: • на 01.12.04 материала цемент осталось 50кг, • 13.12.04 материал цемент в количестве20кгпередан, • 15.12.04 материал цемент в количестве10кгполучен. На основании этих фактов параметр «количество» вычисляется по формуле 30=50–20+10. 3) Необходимые для отбора фактов в ситуациях (например, для отбора удаляемых, или тех, на основе которых ведется расчет...). Например, если данные об уволенных работниках хранятся в течение пяти лет, то для того чтобы в мае 2005 года удалить факт • Иванов – работник предприятия «Аврора» в связи с увольнением данного работника 5 лет назад, необходимы факты: • Иванов уволен 19.04.2000 г. • данные об уволенных хранятся 5 лет. Тогда на основании условия 1.05.2005 – 19.04.2000 г.>5 лет факт • Иванов – работник предприятия «Аврора» может быть удален из системы. 4) Необходимые для контроля вводимых пользователем значений или для ограничения (фильтрации) списков выбора. При создании факта • Операция № 15 (токарная) для заказа № 3 выполнена токаремИвановым при выборе пользователем работника для выполнения данной работы для ограничения списка должны быть учтены факты • Для выполнения токарной операции требуется токарь не менее 3-го разряда. и • ТокарьИванов имеет 4-ый разряд Факты, добавленные в ФМД согласно пунктам 2–4, будем называть справочными. Ситуации использования системы (UseCase) Ситуация использования системы описывает поведение системы при ее ответах на запрос одного из участников. Ситуации использования представлены в текстовой форме. Часто они служат средством связи между лицами, не имеющими специальной подготовки. Поэтому текст является наилучшим выбором. Ситуации использования популярны, прежде всего, потому, что связно рассказывают о поведении системы при ее использовании. Пользователи системы могут увидеть, что это будет за система. Они получают возможность на ранней стадии влиять на точную настройку. В этом состоит значимость ситуаций использования для проекта. Каждая ситуация – это один сеанс связи пользователя (не обязательно человека) с информационной системой. Ей дается информативное название. Обычно ей соответствует форма ввода и соответствующий пункт главного меню. В ситуации может участвовать несколько пользователей. События, происходящие в ситуации, описываются неформально (в виде «сценария»). Обязательно указывается, кто или что (какое событие, какой пользователь) инициирует ситуацию (кто обращается к системе или она автоматически запускается по времени и т.п.). Описание ситуации состоит из четырех списков фактов: читаемых, создаваемых, корректируемых и удаляемых. Для создаваемых и корректируемых фактов указывается формула для вычисления параметров, для читаемых – условие чтения из БД. 2.4 Реализация системы по ее фактографической модели После составления фактографической модели можно перейти от набора хранимых фактов к ER-модели по следующим правилам: 1) Для представления в ER-модели факта Х в ER-модель добавляется сущность Х без осмысленного названия. Название дается, когда набор связей и атрибутов будет определен. 2) Если в факте есть списки, то в ER-модель добавляются сущности Xi, представляющие элементы списков, по однойна каждый список, а не элемент. 3) СущностиXi соединяются связью 1-много в соответствие со вложенностью: списки верхнего уровня с самой сущностью Х, подсписки со списками, их содержащими. Единичный конец должен быть направлен от элемента списка. Кардинальность противоположного конца должна быть проверена по правилам чтения кардинальности. 4) Множество параметров факта разделяется на выбираемые и невыбираемые. Параметр А факта называется выбираемым, если его значение должно выбираться пользователем или системой из списка значений, или требуется хранить список разрешенных значений для него, или если его значение придется писать многократно, в нескольких фактах одинаковой структуры. Если выбор или контроль необходим не для значения одного параметра, а согласованно для значений группы параметров, считаем эту группу единым «составным» параметром. Например, в факте «Согласно платежному поручению №7 от 21.09.04 организации ООО «ХХХ» уплачено 10000 р. по договору №17». Если выбрать номер договора и название организации независимо, то может получиться, что указан номер договора, который с данной организацией еще не заключался. Здесь обязательно надо выбирать пару значений согласованно из договоров. 5) Все невыбираемые параметры представляются в виде атрибутов сущности Х. 6) Выбираемый параметр А превращается в связь сущности Х с сущностью А', содержащей список возможных значений параметра. Если еще не было подходящей сущности, то она создается и ей придается атрибут А. Конец связи Х – всегда единичный, кардинальность конца А' необходимо определить по «правилам чтения кардинальности» приведенным ниже. 7) Если значение параметра В повторяется вместе со значением выбираемого параметра А, т.е. выбор А должен однозначно определять В, то они считаются одним выбираемым параметром. . Параметр В (в виде атрибута или связи)переносится в сущность А' (если его там еще не было). Будемговорить, чтопараметр Ввыбираетсячерез А. Пример: • В заказе N3 клиента Ивановой указана услуга «Завивка». Если заказ содержит несколько услуг, то N заказа будет повторяться для каждой услуги, а вместе с ним будет повторяться фамилия. Другими словами, в заказе обязательно указана фамилия и, следовательно, ее выбор однозначно определяется при выборе заказа. Параметры «номер» и «фамилия» следует считать одним выбираемым параметром. 8) Если результат – сущность без атрибутов и имеет ровно две однозначные связи, то сущность Х превращается в связь между соответствующими сущностями-списками в соответствие с рисунком 2.1. Кардинальности обоих концов определяются по правилам чтения кардинальности. ИСКЛЮЧЕНИЕ: если эта сущность потребуется для указания (выбора) пары значений, то преобразовывать не надо. Рисунок 2.1 – Пустая сущность с двумя связями Пример вставки факта показан в приложении В. После добавления каждого факта в ER-модель необходимо провести действия и проверки, перечисленные ниже. 1) Проверить кардинальность связи по правилам чтения кардинальности. Правило 1: если сущности А и В соединены связью, выбирается та из следующих двух фраз, которая соответствует ее смыслу: «каждому экземпляру А может соответствовать много экземпляров В» или «каждому экземпляру А может соответствовать не более одного экземпляра В». В первом случае конец В – множественный, во втором – единичный. Иногда удобно использовать вариант «контрольных» фраз, где используются факты и параметры, а не сущности: «каждое А может упоминаться во многих фактах вида В» и «каждое А упоминается не более чем в одном факте вида В». Слово «каждый» в контрольной фразе всегда относится к сущности на противоположном от проверяемого конце. Правило 2: если сущности А и В соединены связью, выбирается та из следующих двух фраз, которая соответствует смыслу связи: «каждому экземпляру А должно соответствовать не менее одного экземпляра В» или «каждому экземпляру А может не соответствовать ни одного экземпляра В» (или из аналогичных для фактов: «каждое А может упоминаться хотя бы в одном факте вида В» и «каждое А может и не упоминаться ни в одном факте вида В»). В первом случае конец В – обязательный (поперечная черта), во втором – нет (нолик). 2) Сущности, соединенные обязательными связями «один-к-одному», объединяются. Списки атрибутов и связей этих сущностей сливаются как показано на рисунке 2.2. Рисунок 2.2 – Обязательная связь «один-к-одному» 3) Необязательная связь «один-к-одному» превращается в наследование в соответствие с рисунком 2.3. Сущность на обязательном конце – родительская. Рисунок 2.3 – Необязательная связь «один-к-одному» 4) Циклические связи проверяются – они могут означать избыточность. Связь один-много воспринимается как «стрелка» от множественного к единичному концу. В цикле надо найти «начала» (места откуда ведут две стрелки) «концы» (места куда ведут две стрелки) Если в цикле больше 1 начала или конца – он не содержит избыточности. Если там 1 ровно вход и 1 выход, причем есть прямая связь входа с выходом, то надо проверить наличие избыточности «по смыслу». А именно: если экземпляр сущностиС, находимый при движении по «окольному» пути от сущности В к С будет всегда совпадать с экземпляром, находимым при движении по «прямому» пути, то прямую связь надо убрать, как показана на рисунке 2.4. Рисунок 2.4 – Циклическая связь 5) Связи «много-ко-многим» проверяются – они могут означать недостающие данные. Проверить, действительно ли факт в формулировке, соответствующей связи, может быть использован системой. Если это не так – превратить связь в сущность и добавить недостающие данные. 6) Обязательных с обоих концов связей не бывает – такую пару сущностей невозможно ввести в базу данных: А раньше В, но В раньше А (решите, что вводится раньше). 7) Сущность А, имеющая только ключевые связи и атрибуты и одну обязательную связь с сущностью С, объединяется с С (списки атрибутов и связей этих сущностей сливаются) согласно рисунку 2.5. Рисунок 2.5 – Сущность, имеющая только ключевые связи и атрибуты Таким образом, фактографическая модель данных, эквивалентная реляционной модели. 2.5 Подготовка организационного обеспечения Организационное обеспечение – это совокупность средств и методов организации производства и управления им в условиях внедрения ИС. Целью организационного обеспечения является: • выбор и постановка задач управления; • анализ системы управления и путей ее совершенствования; • разработка решений по организации взаимодействия ИС и персонала; • внедрение задач управления. Организационное обеспечение включает в себя методики проведения работ, требования к оформлению документов, должностные инструкции и т.д. В рамках фактографического метода подготовка организационного обеспечения проводится по описаниям ситуаций: из этих описаний выбираются действия пользователей и записываются в виде инструкций по использованию системы. ПРИЛОЖЕНИЕ А (обязательное) Рисунок А.1 – Мнемокарта «Методика проектирования ИС на основе фактографической модели» ПРИЛОЖЕНИЕ Б (обязательное) Рисунок Б.1 – Мнемокарта «Вставка факта в ER-модель» Рисунок Б.2 – Мнемокарта «Оптимизация ER-модели» ПРИЛОЖЕНИЕ В (обязательное) Рисунок В.1 – ER-модель