Тема 5 методология dfd

Описание потоков данных (процессов)

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

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

Data Flow Diagrams – диаграммы потоков данных

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

Важные компоненты:

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

Сущности

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

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

Процессы

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

Хранилища данных

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

Потоки данных

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

Нотации диаграмм DFD

Как и в IDEF0, основу методологии DFD составляет графический язык описания процессов. Наиболее распространенной является нотация Гейна-Сарсона, которая включает в себя различные символы и правила построения диаграмм.

Правила создания DFD-диаграммы

• Каждый процесс должен иметь хотя бы один вход и один выход.
• Процесс обработки должен иметь внешнюю входящую стрелку (данные от внешней сущности).

Диаграмма потоков данных (DFD) в системном анализе

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

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

Примеры вариантов использования DFD

Пример 1: Система обработки заказа клиента

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

Пример 2: Выдача наличных в кассе банка

Пример 3: Предоставление контента

Пример 4: Графический редактор

• Контекстная диаграмма
• Декомпозиция
  • Декомпозиция блока А2 (второй уровень)
  • Декомпозиция блока А3 (второй уровень)

Пример 5: Нотация Гейна-Сарсона

• Нотация Гейна-Сарсона и Йордана-Де Марко
• Нотация Йордана-Де Марко

Пример 6: Нотация Йордана-Де Марко или нотация

Общие принципы DFD

• Хранилище данных должно быть связано хотя бы с
• Внешний объект должен быть связан хотя бы с одним
• Поток данных не должен существовать между двумя внешними объектами без прохождения процесса.
• Процесс с входом, но без выхода считается процессом
• Метки процессов должны быть глагольными фразами; хранилища данных представлены существительными.
• DFD недетерминированы — нумерация не обязательно указывает порядок и полезна для идентификации процессов при обсуждении с пользователями.
• Хранилище данных не должно быть подключено к внешнему объекту, в противном случае это означает, что вы предоставляете внешнему объекту прямой доступ к вашему файлу данных.

Сравнение методологий IDEF0 и DFD

Являются ли IDEF0 и DFD при построении функциональной модели системы альтернативными методологиями? Основу методологии составляет DFD удобный инструмент при построении модели потоков данных TO-BE, так как выявляет сущности, процессы, хранилища. Строится контекстная диаграмма, где отображаются связи системы с внешним окружением. В дальнейшем выполняется декомпозиция основных процессов и подсистем с построением иерархии диаграмм. Модель системы представляет собой совокупность иерархически упорядоченных и Основные принципы CASE-технологии

## CASE-технология: основные принципы и применение

Аббревиатура CASE (Computer-Aided Software/System Engineering) означает проектирование программного обеспечения или системы на основе компьютерной поддержки. Такое проектирование называется CASE-технологией проектирования.

## Применение CASE-технологий

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

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

## Принципы CASE-технологии

Существует несколько принципов CASE-технологии:
1. Принцип всесторонней компьютерной поддержки проектирования.
2. Принцип модельного подхода.
3. Иерархическое представление модели предметной области.

## Иерархические модели

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

## Графические средства и нотации

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

## Четырехуровневая парадигма проектирования

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

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

Процесс создания информационной системы на основе CASE-технологии

Последовательность стадий и этапов создания информационной системы на основе CASE-технологии представлена на рис. 4.1.

CASE-технология может быть распространена на все стадии жизненного цикла информационной системы (рис. 4.1).

Особенности CASE-технологии:

1. Перенесение трудоемкости разработки в большей степени на анализ и проектирование.
2. Отделение стадий проектирования от средств реализации и программирования.
3. Возможность прямого и обратного проектирования.

Рассмотрим назначение компонентов CASE-средства:

Репозиторий

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

Графический редактор диаграмм

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

Средства контроля и сбора статистики

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

Генератор документов

Формирует выходные документы, содержащие диаграммы проекта.

Администратор

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

Браузер

Позволяет просматривать проект, переключаться между диаграммами и др.

Генератор кодов программ

Создает код программы на основе моделей проекта, хранящихся в репозитории.

Факторы эффективности CASE-технологии:

Эффективность применения CASE-технологии проектирования ИС проявляется в повышении качества создаваемого проекта, сокращении стоимостных и временных затрат на всех стадиях жизненного цикла ИС.

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

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

Наличие формализованной модели системы создает возможность для многовариантного анализа с прототипированием и ориентировочной оценкой эффективности вариантов. CASE-модели позволяют осуществлять функционально-стоимостной анализ (Activity-Based Costing – ABC) для выявления и исследования стоимости выполнения той или иной функции. Анализ прототипа системы позволяет скорректировать будущую систему до того, как она будет реализована в окончательном виде. Этот подход ускоряет и удешевляет создание системы.

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

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

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

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

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

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

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

Функционально-ориентированный подход в проектировании

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

К числу известных методов функционально-ориентированного проектирования относятся: метод функционального моделирования IDEFO, известный также как метод структурного анализа и разработки (Structured Analysis and Design Technique – SADT), метод описания бизнес-процессов IDEF 3 и метод построения диаграмм потоков данных (DFD). Все эти методы входят в семейство стандартов IDEF (Integrated Definition).

Функционально-ориентированный подход в проектировании рассмотрим на примере метода построения диаграмм потоков данных.

Построение CASE-модели системы предусматривает декомпозицию системы и иерархическое упорядочивание декомпозированных подсистем.

Модель системы должна включать:

– функциональную часть системы (функциональную модель);

– отношения между данными (информационную модель);

– переходы состояния системы при работе в реальном времени.

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

1). диаграммы потоков данных – DFD (Data Flow Diagrams). Они используются совместно со словарями данных и спецификациями процессов;

2). диаграммы «сущность-связь» – ERD (Entity Relationship Diagrams), показывающие отношения между данными;

3). диаграммы переходов состояний – STD (State Transiting Diagrams) для отражения зависящего от времени поведения системы (в режиме реального времени).

Ведущая роль в моделировании принадлежит DFD.

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

Как видно из обозначений DFD, эти диаграммы идентифицируют основные компоненты CASE-модели.

Графическое представление диаграммы потоков данных на экране дисплея обеспечивает наглядность моделирования и удобство корректировки основных компонентов модели в интерактивном режиме.

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

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

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

– текстовое описание;

– естественный структурированный язык;

– таблицы решений;

– деревья решений;

– визуальные языки;

– языки программирования.

Языки программирования (C, Cobol и др.) вызывают затруднения в описании алгоритмов применительно к DFD, поскольку требуют использования, помимо потоков данных, словарей данных, и требуют синхронной корректировки спецификаций процессов при корректировке DFD. Структурированный естественный язык легко понимается не только проектировщиками и программистами, но и конечными пользователями. В этом его достоинство. Однако он не обеспечивает автоматической кодогенерации из-за наличия неоднозначностей.

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

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

Содержимое каждого хранилища данных, представленного на диаграмме потока данных, описывается словарем данных и моделью данных ERD. В случае работы системы в реальном времени DFD дополняется STD. Иерархическая структура CASE-модели представлена на рис. 4.4.

Построение иерархической диаграммы потоков данных начинается с контекстных диаграмм.

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

Таким образом, контекстная диаграмма имеет форму звезды.

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

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

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

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

Такое описание процесса на нижнем уровне детализации называется мини-спецификацией.

Признаками завершения детализации обычно являются:

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

– наличие единой функции, то есть одной задачи, которую решает процесс;

– возможность лаконичного описания процесса на одной странице (мини-спецификация должна содержать до 30 строк).

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

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

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

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

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

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

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

1). инкапсуляция, что означает скрытие информации. Смысл этого свойства в том, что состав и структура атрибутов объекта не зависит от сообщений, поступающих извне;

2). наследование – это свойство, связанное с выделением иерархических классов объектов, то есть существуют родительские и дочерние классы. Оно проявляется в том, что методы реагирования объекта, предусмотренные родительским классом, автоматически присваивают объектам дочерних классов, то есть родительские классы имеют общие методы, а дочерние – как общие, так и частные;

3). полиморфизм – возможность выбора объектом в ответ на получаемые им сообщения какого-либо метода из множества методов в зависимости от того, какое пришло сообщение.

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

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

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

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

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

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

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

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

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

RAD-технология прототипного создания приложений

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

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

Основа этой технологии – спиральная модель создания ИС (рис. 4.11).

Как видно на рис. 4.11, разработка идет по спирали, проходя неоднократно все 4 стадии разработки информационной системы.

В спиральной модели выделяют следующие стадии:

Анализ – стадия, на которой исследуется предметная область.

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

Программирование – стадия, на которой пишется машинный код и выпускается очередной «прототип» заказанной системы с полной документацией.

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

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

Классификация, примеры CASE-средств и их характеристика

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

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

2). малые интегрированные CASE-средства, используемые для создания небольших интегрированных ИС и поддерживающие несколько типов моделей и методов. В эту категорию попадают: AllFusion Erwin Data Modeler (прежнее название Erwin), AllFusion Model Manager (прежнее название Bpwin), Silverrun;

3). средние интегрированные CASE-средства, поддерживающие от 4 до 10–15 типов моделей и методов. К данному типу следует отнести: Rational Rose, Designer/2000;

4). крупные интегрированные CASE-средства, поддерживающие более 15 типов моделей и методов. В эту разновидность входит семейство программных продуктов ARIS.

Помимо приведенной выше классификации, возможны и другие классификации, например, по следующим признакам:

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

2). по поддерживаемым графическим нотациям построения диаграмм: с фиксированной нотацией, с отдельными нотациями и наиболее распространенными нотациями;

3). по режиму коллективной разработки проекта: не поддерживающие коллективную разработку, ориентированные на режим реального времени коллективной разработки проекта, ориентированные на режим объединения подпроектов;

4). по типу операционной системы (ОС): работающие под управлением WINDOWS; работающие под управлением UNIX и т.д.

Рассмотрим примеры наиболее распространенных CASE-средств.

К числу крупных интегрированных CASE-средств относится среда описания и анализа бизнес-процессов ARIS, включающая в себя методологическую основу ARIS (Architecture of Integrated Information Systems) и ее программную реализацию в виде семейства продуктов ARIS, разработанных компанией IDS Scheer AG.

Методология профессора Шеера рассматривает предприятие как совокупность четырех взглядов (views):

– на организационную структуру системы;

– на функции и цели системы;

– на структуру данных;

– на структуру бизнес-процессов, протекающих в системе.

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

– анализ и разработка требований;

– формирование спецификаций;

– реализация разработки.

Сочетание четырех взглядов по методологии профессора Шеера и трех фаз модели разработки системы иллюстрируется домиком профессора Шеера (рис. 4.12).

Процессы, Функции, Данные и Организация являются «комнатами» домика профессора Шеера. Главной комнатой являются Процессы, отражающие процессный подход в управлении и моделировании.

Таким образом, ARIS предлагает рассматривать организацию с позиции 12 аспектов, отображающих разные взгляды на предприятие, а также разную глубину этих взглядов. Для описания бизнес-процессов предлагается использовать 85 типов моделей.

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

EPC (Event-Driven Process Chain) – метод описания процессов;

ERM (Entity Relationship Model) – модель сущностей-связей для описания структуры данных;

UML (Unified Modeling Language) – объектно-ориентированный язык моделирования.

К числу средних интегрированных CASE-средств можно отнести Rational Rose – семейство объектно-ориентированных CASE-средств фирмы Rational Sofware Corporation, предназначенное для автоматизации процессов анализа и проектирования, генерации кодов на различных языках и выпуска проектной документации в виде диаграмм и спецификаций. Работа этого средства основана на языке моделирования UML.

В составе Rational Rose можно выделить семь основных структурных компонентов.

Моделирование проводится как «поуровневый спуск» от концептуальной модели к логической, а затем к физической модели программной системы. Концептуальная модель выражается в виде «диаграмм прецедентов» (Use Case Diagram). Логическая позволяет определять два различных взгляда на системы: статический и динамический. Статическая модель выражается диаграммами классов (Class Diagram). Динамические модели задаются двумя типами диаграмм: диаграммами взаимодействия объектов (Collaboration Diagram) и диаграммами последовательности взаимодействий (Sequence Diagram). Физическая модель задается компонентной диаграммой (Component Diagram), описывающей распределение классов по модулям, и диаграммой развертывания (Deployment Diagram).

К числу малых интегрированных CASE-средств относится программный продукт Silverrun американской фирмы Silverrun_Technologies,_Inc.

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

Имеется возможность настройки на разные нотации.

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

Модуль построения моделей бизнес-процессов в форме диаграмм потоков данных (BPM – Business Process Modeler) позволяет моделировать существующую или создаваемую информационную систему (ее функциональную часть).

Модуль концептуального моделирования данных (ERX – Entity-Relationship eXpert) обеспечивает построение моделей данных «сущность-связь», не привязанных к конкретной реализации. ERX имеет встроенную экспертную систему, позволяющую создать модель данных по средствам ответов на вопросы о взаимосвязи данных. так создается модель первичной структуры данных (PDS – Primary Data Structure). Концептуальная модель не требует нормализации данных, а представляет их в таком виде, в каком они существуют на предприятии. Концептуальная модель передается в модуль RDM.

Модуль реляционного моделирования (RDM – Relational Data Modeler) позволяет создавать реляционные модели данных для конкретных СУБД. Для автоматической генерации схем баз данных используются мосты для работы с наиболее распространенными СУБД, в том числе с: ORACLE, SQLBase и др. Для передачи данных средств разработки приложений имеются мосты к языкам 4 поколения (4GL): Delphi, SQLWindows и др.

Модуь репозитория рабочей группы (WRM – Workgroup Repository Manager) предназначен для хранения общей для всех разработчиков информации проекта и интеграции всех модулей Silverrun в единую систему.

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

К числу локальных CASE-средств можно отнести программный продукт Design/IDEF (Meta Software). Наиболее эффективно применение пакета при описании и анализе деятельности предприятия.

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

Основными преимуществами Design/IDEF перед другими пакетами (например, перед Bpwin) являются: малый объем программы и небольшие потребности в аппаратных ресурсах, а также доступность Design/IDEF поскольку это средство распространяется бесплатно и его можно получить через Internet.

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

СИСТЕМЫ И ПОДСИСТЕМЫ 1. При построении модели сложной системы она может быть представлена в самом общем виде на так называемой контекстной диаграмме в виде одной системы, либо в виде ряда подсистем. 2. Наименование системы/подсистемы представляется в виде словосочетания с отглагольным существительным (рассмотрение повестки дня, решение задачи, получение денег и т.п.). Нотация Йордана-Де Марко Нотация Гейна-Сарсона

ДИАГРАММЫ ПОТОКОВ ДАННЫХ (DATA FLOW DIAGRAMS – DFD) — ПРЕДСТАВЛЯЮТ СОБОЙ ИЕРАРХИЮ ФУНКЦИОНАЛЬНЫХ ПРОЦЕССОВ, СВЯЗАННЫХ ПОТОКАМИ ДАННЫХ. ЦЕЛЬ ТАКОГО ПРЕДСТАВЛЕНИЯ — ПРОДЕМОНСТРИРОВАТЬ КАК КАЖДЫЙ ПРОЦЕСС ПРЕОБРАЗУЕТ СВОИ ВХОДНЫЕ ДАННЫЕ В ВЫХОДНЫЕ, А ТАКЖЕ ВЫЯВИТЬ ОТНОШЕНИЯ МЕЖДУ ЭТИМИ ПРОЦЕССАМИ.

Спецификация является конечной вершиной иерархии DFD. Решение о завершении детализации процесса и использовании спецификации принимается исходя из следующих критериев: • наличия у процесса относительно небольшого количества входных и выходных потоков данных (2-3 потока); • возможности описания преобразования данных процессов в виде последовательного алгоритма; • выполнения процессом единственной логической функции преобразования входной информации в выходную; • возможности описания логики процесса при помощи спецификации небольшого объема (не более 20-30 строк).

Выполнила студентка гр. БПИ21-01 Сергеева С.Е Проверил: Кишкан В.В

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

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

ПРИМЕР DFD-СХЕМ В ДВУХ НОТАЦИЯ Нотация Йордана-Де Марко Нотация Гейна-Сарсона

Цель: сделать описание системы ясным и понятным на каждом уровне детализации, а также разбить описание на части с точно определенными отношениями между ними. Рекомендации к построению. 1. Размещать на каждой диаграмме от 3 до 6-7 процессов. 2. Не загромождать диаграммы несущественными на данном уровне деталями. 3. Декомпозицию потоков данных осуществлять параллельно с декомпозицией процессов. Эти две работы должны выполняться одновременно, а не одна после завершения другой. 4.Выбирать ясные, отражающие суть дела имена процессов и потоков, при этом стараться не использовать аббревиатуры.

ВНЕШНЯЯ СУЩНОСТЬ 1. Представляет собой материальный объект или физическое лицо, являющееся источником или приемником информации (например, клиент, поставщик, склад). 2. Внешняя сущность находится за пределами границ анализируемой системы. Нотация Йордана-Де Марко Нотация Гейна-Сарсона

1.Внешние сущности 2.Системы и подсистемы 3.Процесс 4.Накопитель данных 5.Поток данных

НОТАЦИИ, ИСПОЛЬЗУЕМЫЕ ДЛЯ ОПИСАНИЯ DFD ДИАГРАММ Для описания DFD диаграмм, используется две основные нотации: Нотация Йордана-Де Марко и Гейна-Сарсона. Основное отличие заключается в графическом представлении элементов диаграмм.

НАКОПИТЕЛЬ ДАННЫХ 1. Абстрактное устройство для хранения информации, которую можно в любой момент поместить в накопитель и через некоторое время извлечь из нее, причем способы извлечения будут любыми. 2. Накопитель данных в общем случае является прообразом будущей базы данных и описание хранящихся в нем данных должно быть увязано с информационной моделью. Нотация Йордана-Де Марко Нотация Гейна-Сарсона

ПОТОК ДАННЫХ 1. Определяет информацию, передаваемую через некоторое соединение от источника к приемнику. 2. Поток данных на диаграмме обозначается линией, которая показывает направление потока. Каждый поток данных имеет имя, отражающий его содержание.

ПРОЦЕСС 1. Представляет собой преобразование входных потоков данных в выходные в соответствие с определенным алгоритмом. 2. Примеры: обработка входных документов и выпуск отчетности определенным подразделением, процессы физически реализованного устройства. 3. Процесс именуется в виде словосочетания с активным глаголом в неопределенной форме, за которым следует существительное в винительном падеже. Нотация Йордана-Де Марко Нотация Гейна-Сарсона