Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Proektirovanie_IS_GOS.docx
Скачиваний:
62
Добавлен:
09.04.2015
Размер:
3.72 Mб
Скачать

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

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

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

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

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

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

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

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

  • ERD (Entity Relationship Diagram) - ER-модель данных предметной области (информационно-логические модели "сущность-связь");

  • SSD (System Structure Diagram) - диаграмма структуры программного приложения.

_________________________________________________________________________

Business Function Diagram (BFD) – диаграммы функциональных спецификаций. Позволяют представить общую структуру исследуемого объекта, отражающую взаимосвязь различных задач в процессе получения требуемых результатов. Основные элементы BFD – это функции (некоторые действия, необходимые для решения поставленных задач) и декомпозиции функций (разбиение функции на множество подфункций). На практике диаграмма функционал. спецификаций, используется, например, для верификации диаграмм сущность-связь при проектировании базы данных ИС.

________________________________________________________________________

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

Состав диаграмм потоков данных. Основные компоненты диаграмм потоков данных:

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

• системы и подсистемы - отражаются только на контекстной диаграмме при наличии нескольких подсистем;

• процессы - функция аналогичная диаграмме IDEF0. В имени функции указ. глагол в неопределенной форме;

• накопители данных - представляет собой абстрактное устройство для хранения данных (например, инфа о клиентах). Детализация до таблиц БД не производится;

• потоки данных - имеет наименование и направление. Опред. и. передаваемую от источника к приемнику..

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

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

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

ERD (Entity-Relationship Diagrams) - диаграммы "сущность-связь" - способ определения данных и отношений между ними, обеспечивающий детализацию хранилищ данных проектируемой системы включая идентификацию объектов (сущностей), свойств этих объектов (атрибутов) и их отношений с другими объектами (связей). Предназначена для разработки концептуальной схемы БД.

ERD состоит из:

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

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

3. Атрибут - любая характеристика сущности просматриваемая в предметной области. Может быть обязательным или необязательным. Обязательный атрибут не может принимать неопределенные значения.

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

Диаграммы изменения состояний STD.

Жизненный цикл сущности относится к классу STD-диаграмм (рис. 14).

Рис. 14. Пример диаграммы жизненного цикла

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

16. Соответствие между понятиями (названиями элементов) инфологической и даталогической моделей.

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

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

Остальные модели (рис. 1.3), являются компьютеро-ориентированными. С их помощью СУБД дает возможность программам и пользователям осуществлять доступ к хранимым данным лишь по их именам, не заботясь о физическом расположении этих данных. Нужные данные отыскиваются СУБД на внешних запоминающих устройствах по физической модели данных.

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]