Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Курс лекций «Базы данных и информационные системы»
Тема 1 «Моделирование ИС. Моделирование потоков данных с применением IDF0 и DFD методологий и диаграмм вариантов использования – use case diagrams методологии RUP. Построение модели ИС на уровне классов и компонентов с использованием диаграммы классов методологии RUP»
Предметом курса является разработка информационных систем, которые сопровождают базы данных.
Информационная система - это совокупность программных и аппаратных средств, предназначенных для хранения и/или управления данными и информацией и производства вычислений.
Основой для проектирования любой сложной системы служит её концептуальная модель.
Концептуальную модель можно определить как результат абстрагирования части реального мира, которую моделируют информационной системой. Для обозначения «части реального мира, которую моделируют информационной системой» называют «предметная область».
Выделяют два типа информационных систем. Одни из них сопровождают операционные (OLTP), а другие - аналитические (OLAP) базы данных.
OLTP-базы хранят данные в реальном масштабе времени. Другими словами, мгновенно фиксируют события. Например, отгрузку товара со склада.
Рисунок 1 - Состояния OLTP-базы данных
Как видим, в рассмотренном примере (рис. 1), состояние базы данных в 8 часов 15 мин., когда мониторы по второй позиции на складе были, изменилось. Теперь, в 12 часов 20 мин., оно отражает отсутствие данного товара.
OLAP-информационные системы
OLAP хранят "историю" изменения базы данных. То есть, в них сохраняют данные OLTP базы с какой-то периодичностью. Например, раз в месяц.
Если изображать состояния OLTP базы следующего месяца не под, а за предыдущим, то получится некий куб, как показано на рис. 2.
Рисунок 2 - OLAP база данных
Теперь, если произвести некий кросс-табличный анализ, например, построить график изменения значений какой-то комплектующей по одной позиции, то можно предсказать тенденцию ее сбыта. А значит предсказать прибыль реализация данного товара в будущем или принять решение о прекращении его поставок.
Рисунок 3 - Результат кросс-табличного анализа
Из приведенного рис. 3 видно, что сбыт возрастает, значит можно надеяться на получение прибыли в ближайшем будущем.
Конечно это не единственный вариант анализа. Можно сравнивать кривые сбыта разных товаров, чтобы определить, какой из товаров дает большую прибыль, оптимизировать затраты на рекламу с целью получения максимальной прибыли от реализации товара и т. д.
Эти задачи решают с помощью систем поддержки принятия решений (Decision Support System - DSS) на основе данных OLAP баз. Как видим, этот тип информационных систем ориентирован на решение стратегических вопросов. В рассмотренном примере это было прогнозирование сбыта. Поэтому OLAP системы никогда не оперируют данными реального времени.
К системам поддержки принятия решений относят, например, знакомый многим Microsoft Excel. Многие средства разработки информационных систем содержат библиотеки классов или компонентов. Так, в Borland Delphi есть компоненты DecisionCube.
Системы поддержки принятия решений масштаба предприятия, строят на серверных OLAP-средствах. Например, таких как Oracle Express Server, Microsoft SQL Server 2000 Analysis Services, Hyperion Essbase, продуктах компаний Crystal Decisions, BusinessObjects, Cognos, SAS Institute.
В курсе мы будем рассматривать системы, которые сопровождают OLTP базы данных. Для краткости будем называть их OLTP-системы.
Кратко охарактеризовать OLTP базы данных можно так - это большие объемы структурированной информации.
Не смотря на то, что это упрощенное определение тут подчеркнуты два важных аспекта:
Второй аспект определяет область применения баз данных - относительно развитые бизнес структуры. Другими словами, автоматизация сопровождения бизнеса с небольшим оборотом и узкой номенклатурой товара не целесообразна.
В следующей теме мы перейдем к вопросу моделирования этих систем.
Для этих целей используют IDEF0 (Integrated Definition Function Modeling) и DFD (Data Flow Diagrams) методологии.
Выбор методологии проектирования зависит от степени сложности моделируемого информационной системой объекта. Если это сложный объект, например, предприятие, то в начале проектирования информационной системы желательно использовать методологию IDEF0. В настоящее время эта методология действует в качестве федерального стандарта США.
Методология IDEF0 описывает процессы движения и обработки информации звеньями моделируемого объекта с точки зрения их функционального назначения. Например, отделами предприятия.
IDEF0 — это подмножество SADT (Structured Analisys and Design Technique). Методология SADT разрабатывалась Дугласом Т. Россом в 1969—1973 годах и изначально применялась для проектирования систем общего назначения.
Поясним суть методологии IDEF0 на примере производства товара. Процесс производства условно изображен на рис. 1.
Рисунок 1 - Схема процесса производства
Здесь слева представлены ингредиенты, которые используют для производства товара, сверху — инструкции, регламентирующие процесс производства, внизу инструменты, которые используют в процессе производства, а справа — готовый товар.
В терминах IDEF0 моделируемое информационной системой производство представляется блоком и дугами, как показано на рис. 2.
Рисунок 2 - Базовые элементы IDEF0-модели
В блоке отражена главная функция моделируемого информационной системой производства, дуги — множество объектов, участвующих и являющихся результатом производства: информация или действия. Место соединения дуги с блоком определяет тип интерфейса.
Правила интерпретации модели:
С дугами связываются метки на естественном языке, описывающие данные, которые они представляют. Дуги показывают, как функции системы связаны между собой, как они обмениваются данными и осуществляют управление друг другом.Выходы одной функции могут быть входами, управлением или исполнителями другой.
Дуги могут разветвляться и соединяться. Ветвление означает множественность (идентичные копии одного объекта) или расщепление (различные части одного объекта). Соединение означает объединение или слияние объектов.
Каждый блок IDEF0-диаграммы может быть представлен несколькими блоками, соединенными интерфейсными дугами, на диаграмме следующего уровня. Эти блоки представляют подфункции (подмодули) исходной функции. Каждый из подмодулей может быть декомпозирован аналогичным образом. Число уровней не ограничивается, однако рекомендуют на одной диаграмме использовать от трех до шести блоков.
Построим, используя IDEF0 методологию концептуальную модель рассмотренного выше предприятия (рис. 3).
Рисунок 3 - IDEF0-модель производства готовой продукции
Анализ объекта на основе построения его IDEF0-модели является этапом, который должен предварять разработку информационной системы по целому ряду причин. Во-первых, при ознакомлении с объектом строят модель "КАК ЕСТЬ". Такая модель фиксирует бизнес процессы и используемые ими информационные потоки. Во-вторых, функциональная модель "КАК ЕСТЬ" позволяет увидеть информационно перегруженные бизнес процессы — "узкие" места обследуемого объекта. В-третьих, на основании модель "КАК ЕСТЬ" можно построить модель "КАК БУДЕТ". То есть предложить более совершенную структуру организации объекта. Но это уже вопросы реинжиниринга и мы их не будем касаться. Можно только отметить, что реинжиниринг подчеркивает важную роль информационных технологий в жизни общества. В-четвертых, в процессе построения модели "КАК ЕСТЬ" выявляются бизнес-правила — положения, которые регламентируют процесс функционирования моделируемого объекта. Например, представленный на рис. 2.4 фрагмент функциональной модели должен быть зафиксирован бизнес-правилом: "служба снабжения обязана определять потребности в материалах для производства готовой продукции только на основании плана выпуска".
И последнее. Очевидно, что IDEF0-модель — это лучший способ совместно с заказчиком разработать модель функционирования его фирмы. Дело в том, что такая нотация (описание с помощью прямоугольников и стрелок) понятна и заказчику и исполнителю.
После этапа моделирования исследуемого объекта наступает этап физической реализации этой модели в виде информационной системы. И тут возникает естественный вопрос об адекватности отображения. Другими словами, как представить в информационной системе, например, управляющие потоки. Хотя понятно, например, что потоки данных в информационной системе будут реализованы как хранилища данных, то есть файлы.
Тот факт, что IDEF0-модель не разделяет потоки данных на материальные, информационные и управляющие приводит разработчиков к необходимости использовать диаграммы потоков данных (Data Flow Diagrams — DFD). Это можно делать после составления IDEF0-модели, либо вместо этого в зависимости от сложности моделируемого объекта или предпочтений исполнителя.
Основы методологии построения диаграмм потоков данных DFD были описаны в 1979 году C. Gane и T. Sarson в книге "Structured Systems Analysis".
При построении DFD-диаграмм используют следующие элементы:
Внешняя сущность — это объект, который не принадлежит моделируемому и обменивается с ним потоками данных. Это, как правило, потребитель услуг моделируемого системой объекта.
В общем случае, сущность — это объект или концепция, которая в рамках конкретной предметной области существует самостоятельно.
При построении DFD-диаграмм начинают с нуль уровня ( контекстной диаграммы). Эта диаграмма содержит только один узел процессов ("нулевой процесс"), который обобщает функцию всей системы по отношению к внешним сущностям. Затем ее уточняют на более низких уровнях (рис. 1).
Рисунок 1 - Контекстная диаграмма
Строя DFD-диаграмму нуль уровня необходимо отобразить все основные хранилища данных и все внешние сущности. Диаграмма должна быть построена так, чтобы она отвечала на основные вопросы: "Как работает моделируемый объект?", "Откуда поступают эти данные?", "Какой процесс использует эти данные?" и т.д.
При построении DFD-диаграмм нижних уровней необходимо соблюдать принцип "вертикального балансирования" — ввод или вывод данных не может быть произведен, если этого не делает родитель.
Приведем пример DFD-диаграммы некоторой риелтерской конторы, которая специализируется на заключении договоров аренды жилых помещений (рис. 2).
Рисунок 2 - Контекстная диаграмма нулевого уровня
Рисунок 3 - Контекстная диаграмма первого уровня
Диаграмма построена в предположении, что круг клиентов конторы относительно стабилен.
Как видно из контекстной диаграммы первого уровня внешние сущности — это потенциальные Арендатор и Владелец. Поскольку элементами контекстной диаграммы являются одноименные хранилища: Арендатор и Владелец, то можно усомниться в правильности определения внешних сущностей. Но, так как потенциальные Арендатор и Владелец могут быть арендатором и владельцем лишь после заключения договора, то конфликтов с определением здесь нет. Другими словами, это разные сущности.
Для составления договора используют данные хранилищ Арендатор и Владелец. Эти хранилища необходимы по причине того, что круг клиентов риелтерской конторы относительно стабилен. Не подвержен значительным изменениям и перечень арендуемых объектов недвижимости, что отражает на контекстной диаграмме хранилище Недвижимость.
Наличие на диаграмме процесса "Подготовить договор аренды" — это следствие того, что "черновик" договора аренды готовит клерк, а менеджер принимает решение о заключении договора. Это повышает эффективность работы фирмы в целом.
UML позволяет получить полное представление обо всей проектируемой системе и об отдельных ее компонентах на основе следующих типов диаграмм:
Диаграмма прецедентов позволяет создать список операций, которые выполняет система. Часто этот вид диаграмм называют диаграммой функций, потому что на основе набора таких диаграмм создается список требований к системе и определяется множество выполняемых системой функций.
Каждая такая диаграмма или, как ее обычно называют, каждый Use case – это описание сценария поведения, которому следуют действующие лица (Actors).
Данный тип диаграмм используется при описании бизнес процессов автоматизируемой предметной области, определении требований к будущей программной системе. Отражает объекты, как системы, так и предметной области и задачи, выполняемые ими.
В результате анализа моделируемого информационной системой объекта на основе построения IDEF0 и DFD-диаграмм:
Например, так:
Как видим назначение концептуальной модели объекта:
Подводя итог, можно отметить, что построение концептуальной модели системы в соответствии с IDEF0- или DFD-методологией позволяет прийти к общему с заказчиком представлению о проектируемой информационной системе.
Примечание
Как будет показано дальше потоки данных — это прообразы процедур приложения, а хранилища данных — таблиц базы данных.