Лабораторная работа "Проектирование предметной области"

Лабораторная работа 2. Проектирование предметной области

Цель работы

1.  Приобретение навыков в разработке DFD и ERD-модели.

2.  Приобретение навыков в построении инфологической модели базы данных.

Требования к программному обеспечению:

Logic Works BPWin версия 3.51 или выше (например, Computer Associates BPWin 4.0)

Теоретические сведения:

1. Введение.

Для анализа и проектирования деятельности предприятия используются различные методологии структурного анализа и проектирования.

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

В настоящее время широко используются методологии:

-          SADT (Structured Analysis and Design)

-          структурного системного анализа Гейна-Сарсона

-          структурного анализа и проектирования Йодана/де Марко,

-          развития систем Джексона

и т.д.

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

В дальнейшем, диаграммы, отражающие спецификации поведения, структуры данных для блоков программного обеспечения, транслируются в шаблоны программного кода. Это достигается использованием для проектирования так называемых средств быстрого прототипирования, известных также под названием CASE (Computer-Aided Software/System Engineering)–систем.

2. SADT - технология структурного анализа и проектирования.

SADT – одна из самых известных методологий анализа и проектирования систем, введенная в 1973 года Россом. Используется повсеместно.

Модель, по SADT, может быть одного из двух типов:

-          модель активностей системы (другие названия – бизнес-функции, работы)– основывается на функциях системы/блока

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

Рисунок 1 - Первая диаграмма в иерархии - контекстная - изображает функционирование системы в целом.

Основным элементом в модели по SADT является диаграмма. Модель может объединять несколько диаграмм в одну иерархию. Чем глубже диаграмма находится в иерархии, тем более она детализована, т.е. тем более подробно отображает данные или активности системы или блока.

Пример диаграммы самого высокого уровня показан на рис. 1. Такие диаграммы называются контекстными. В контекст входит описание цели моделирования, области (описания того, что будет рассматриваться как компонент системы, а что как внешнее воздействие) и точки зрения (позиции, с которой будет строиться модель). Обычно в качестве точки зрения выбирается точка зрения лица или объекта, ответственного за работу моделируемой системы в целом.

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

На рис. 2 изображена диаграмма, раскрывающая содержание контекстной диаграммы из рис.1.

Рисунок 2 - Пример диаграммы декомпозиции

Блоки на диаграмме размещаются по «ступенчатой» схеме в соответствии с их доминированием – влиянием, которое один блок оказывает на другие. Часто блоки еще и нумеруют, также в соответствии с доминированием.

Построение DFD-диаграмм

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

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

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

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

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

Поле имени

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

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

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

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

                                                                                              Передача договора

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

Для создания модели процесса необходимо:

1.  Определить внешние объекты, процессы, потоки данных и накопители

2.  Выяснить взаимодействие компонентов друг с другом

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

Внешним объектом является клиент – потенциальный арендатор, с которым должен быть заключен договор. Первый процесс – это «прием заявки». Если клиент обратился в агентство впервые, данные о нем сохраняются в накопителе «tenant». После этого данные о требуемой недвижимости передаются в процесс «Выбор подходящего объекта для аренды» и производится анализ существующих в базе (накопитель Realty) объектов для аренды. После подбора объекта,  обсуждения, осмотра объектов данные передаются в процесс «Заключение договора». Этот процесс также включает этап оформления соответствующей документации (с занесением данных в накопитель «lease») и выдачи договора со всеми данными клиенту.

Часть диаграммы для данного примера будет иметь следующий вид.

                                                                  Ввод информации о клиенте

данные о требуемой недвижимости

                                                                   Информация об объектах

                                                                   Данные договора

                                                                Выдача договора

Рис.3  DFD-диаграмма системы

Разработка ERD-модели. Построение реляционной схемы БД

Модель «сущность-связь» (ER-модель) представляет собой набор концепций, которые описывают структуру базы данных  и связанные с ней транзакции обновления и извлечения данных. Основная цель разработки высокоуровневой модели заключается в создании модели пользовательского восприятия данных и согласовании большого количества технических аспектов. Концептуальная модель данных не зависит от аппаратной платформы, которая используется для реализации БД. Основные концепции модели «сущность-связь» включают типы сущностей, связей и атрибуты.

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

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

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

В данной модели сущностями являются  Арендаторы, Владельцы, Виды недвижимости, Договора и др.

Отдельные свойства сущностей называются атрибутами, они также указываются на диаграмме. Например, сущность Арендаторы описывается уникальным кодом (id_tenant), ФИО, адресом, телефоном, дополнительным комментарием. Атрибуты сущности содержат значения, описывающие каждую сущность. Каждый атрибут связан с набором значений, который называется доменом. Домен определяет все потенциальные значения, которые могут быть присвоены атрибуту. Различные атрибуты могут совместно использовать один и тот же домен. Кроме атрибутов, описывающих сущность, существует понятие ключа. Под ключом подразумевается элемент данных, который позволяет уникально идентифицировать отдельные экземпляры некоторого типа сущности. Первичный ключ – это один или несколько атрибутов, значения которых уникальным образом идентифицируют каждый экземпляр сущности данного типа. Например, код договора является потенциальным ключом типа сущности Договор, поскольку он содержит разные значения для каждого отдельного договора. Выбор первичного ключа осуществляется из соображений наличия гарантий уникальности его значений в текущий момент времени и будущем. Проанализируем существующие между сущностями связи. В данной модели они будут следующими

Рассмотрим теперь структурные ограничения, которые могут накладываться на сущности.

Наиболее распространенными являются связи «один к одному», «один ко многим», «многие ко многим». Виды связей определяются, прежде всего, производственными правилами, установленными на предприятии. Эти правила называются бизнес-правилами организации. Ниже приведена часть ER-модели данной системы.

                                               М                                                           М

    М

         1

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

Шаг 1. Каждая простая сущность превращается в таблицу. Имя сущности становится именем таблицы.

Шаг 2. Каждый атрибут  становится возможным столбцом с тем же именем; может выбираться более точный формат.

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

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

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

3. Нотация IDEF0

Нотация IDEF0 (Integration Definition for Function Modeling) была разработана на основе методологии структурного анализа и проектирования SADT, утверждена в качестве стандарта США и успешно эксплуатируется во многих проектах, связанных с описанием деятельности предприятий.

IDEF0 может быть использована для моделирования широкого класса систем.

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

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

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

В таблице 1 приведены основные «строительные блоки» для диаграмм IDEF0.

Таблица 1.

Все работы и стрелки должны быть именованы.

4. Нотация IDEF3

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

Наличие в диаграммах DFD элементов для описания источников, приемников и хранилищ данных позволяет точно описать процесс документооборота. Однако для описания логики взаимодействия информационных потоков модель дополняют диаграммами еще одной методологии – IDEF3, также называемой workflow diagramming. Методология моделирования IDEF3 позволяет графически описать и задокументировать процессы, фокусируя внимание на течении этих процессов и на отношениях процессов и важных объектов, являющихся частями этих процессов.

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

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

В таблице 2 приведены основные «строительные блоки» для диаграмм IDEF3.

Таблица 2.

На рис. 3 показан пример диаграммы в нотации IDEF3.

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

Как видно, на диаграмме есть два перекрестка ветвления, перекресток с ветвлением по логическому исключающему «ИЛИ», и перекресток с ветвлением по «И», означающим выполнение двух работ параллельно.

Рисунок 3 – Пример диаграммы в нотации IDEF3.

5. Нотация DFD (Data Flow Diagramming)

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

Элементы DFD диаграмм показаны в таблице 3.

Таблица 3.

На рис.4 представлена DFD диаграмма для внешнего объекта «Заказы клиентов».

Рисунок 4 - Пример диаграммы DFD.

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

6. BPWin

BPwin поддерживает три методологии: IDEF0, DFD и IDEF3, позволяющие анализировать деятельность предприятия с трех ключевых точек зрения:

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

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

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

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

BPwin обладает удобным инструментом для навигации по уровням декомпозиции модели. Это Model Explorer (см. рис. 5), который по организации очень похож на привычный всем проводник Windows.

Работы IDEF0 показываются в Model Explorer зеленым цветом, DFD – желтым и IDEF3 – синим. Щелкая мышкой по любой из работ, представленных в проводнике, пользователь может переходить на диаграмму, содержащую выбранную работу.

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

Содержание отчета

1.  Исходные данные и постановка задачи.

2.  Для заданной ER-диаграммы выделить: сущности, атрибуты, связи и их типы, уникальные поля (ключи).

3.  Описание последовательности действий при построении диаграммы.

4.  Результаты построения DFD-диаграммы в BPWin.

Варианты заданий

Вариант 1. Информация о публикациях по ряду выбранных тем.

Вариант 2. Внутренняя система  обучения  в  большой  промышленной компании.

Вариант 3. Информация о пациентах клиники.

Вариант 4. Анкетные данные служащих конторы.

Вариант 5. Информация о торговых фирмах.

Вариант 6. Каталог работ.

Вариант 7. Информация о служащих.

Вариант 8. Деканат

 Вариант 9.  Учебные заведения, абитуриенты и экзамены

Вариант 10. Расписание поездов.

Вариант 11. Результаты экзаменов по каждой кафедре:

Вариант 12. Картотека осужденных лиц:

Вариант 13. Футбольные клубы

Вариант 14. Информация о концертах

Вариант 15. Картотека фирм

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

Вариант 17. Бронирование мест в гостинице для командированных

 Вариант 18. Лечение различных заболеваний:

Вариант 19. Вычислительные центры города

Вариант 20. Политические партии

Вопросы к защите:

1.      SADT - технология структурного анализа и проектирования

2.      Построение DFD-диаграмм

3.      Разработка ERD-модели. Построение реляционной схемы БД

4.      Нотация IDEF0, нотация IDEF3, нотация DFD (Data Flow Diagramming)

5.      Работа в BPWin

6.      Скачано с www.znanio.ru