Case-технлогии

командами (делится функциональная модель). Результатом данной фазы должны

быть:

общая информационная модель системы;

функциональные модели системы в целом и подсистем, реализуемых отдельными

командами разработчиков;

точно определенные с помощью CASE-средства интерфейсы между автономно

разрабатываемыми подсистемами;

построенные прототипы экранов, отчетов, диалогов.

Все модели и прототипы должны быть получены с применением тех CASE-средств,

которые будут использоваться в дальнейшем при построении системы. Данное

требование вызвано тем, что в традиционном подходе при передаче информации

о проекте с этапа на этап может произойти фактически неконтролируемое

искажение данных. Применение единой среды хранения информации о проекте

позволяет избежать этой опасности.

В отличие от традиционного подхода, при котором использовались

специфические средства прототипирования, не предназначенные для построения

реальных приложений, а прототипы выбрасывались после того, как выполняли

задачу устранения неясностей в проекте, в подходе RAD каждый прототип

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

передается более полная и полезная информация.

На фазе построения выполняется непосредственно сама быстрая разработка

приложения. На данной фазе разработчики производят итеративное построение

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

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

формируется при помощи автоматических генераторов, получающих информацию

непосредственно из репозитория CASE-средств. Конечные пользователи на этой

фазе оценивают получаемые результаты и вносят коррективы, если в процессе

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

Тестирование системы осуществляется непосредственно в процессе разработки.

После окончания работ каждой отдельной команды разработчиков производится

постепенная интеграция данной части системы с остальными, формируется

полный программный код, выполняется тестирование совместной работы данной

части приложения с остальными, а затем тестирование системы в целом.

Завершается физическое проектирование системы:

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

производится анализ использования данных;

производится физическое проектирование базы данных;

определяются требования к аппаратным ресурсам;

определяются способы увеличения производительности;

завершается разработка документации проекта.

Результатом фазы является готовая система, удовлетворяющая всем

согласованным требованиям.

На фазе внедрения производится обучение пользователей, организационные

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

существующей системой (до полного внедрения новой). Так как фаза построения

достаточно непродолжительна, планирование и подготовка к внедрению должны

начинаться заранее, как правило, на этапе проектирования системы.

Приведенная схема разработки ИС не является абсолютной. Возможны различные

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

разработка: разрабатывается совершенно новая система; уже было проведено

обследование предприятия и существует модель его деятельности; на

предприятии уже существует некоторая ИС, которая может быть использована в

качестве начального прототипа или должна быть интегрирована с

разрабатываемой.

Следует, однако, отметить, что методология RAD, как и любая другая, не

может претендовать на универсальность, она хороша в первую очередь для

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

Если же разрабатывается типовая система, которая не является законченным

продуктом, а представляет собой комплекс типовых компонент, централизованно

сопровождаемых, адаптируемых к программно-техническим платформам, СУБД,

средствам телекоммуникации, организационно-экономическим особенностям

объектов внедрения и интегрируемых с существующими разработками, на первый

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

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

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

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

интерфейсам, что снижает скорость разработки.

Методология RAD неприменима для построения сложных расчетных программ,

операционных систем или программ управления космическими кораблями, т.е.

программ, требующих написания большого объема (сотни тысяч строк)

уникального кода.

Не подходят для разработки по методологии RAD приложения, в которых

отсутствует ярко выраженная интерфейсная часть, наглядно определяющая

логику работы системы (например, приложения реального времени) и

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

самолетом или атомной электростанцией), так как итеративный подход

предполагает, что первые несколько версий наверняка не будут полностью

работоспособны, что в данном случае исключается.

Оценка размера приложений производится на основе так называемых

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

метрика не зависит от языка программирования, на котором ведется

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

RAD, для хорошо отлаженной среды разработки ИС с максимальным повторным

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

|< 1000 функциональных |один человек |

|элементов | |

|1000-4000 функциональных |одна команда разработчиков |

|элементов | |

|> 4000 функциональных |4000 функциональных элементов на одну |

|элементов |команду разработчиков |

В качестве итога перечислим основные принципы методологии RAD:

разработка приложений итерациями;

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

цикла;

обязательное вовлечение пользователей в процесс разработки ИС;

необходимое применение CASE-средств, обеспечивающих целостность проекта;

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

в проект и сопровождение готовой системы;

необходимое использование генераторов кода;

использование прототипирования, позволяющее полнее выяснить и удовлетворить

потребности конечного пользователя;

тестирование и развитие проекта, осуществляемые одновременно с разработкой;

ведение разработки немногочисленной хорошо управляемой командой

профессионалов;

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

выполнения работ.

2. Структурный подход к проектированию ИС

2.1. Сущность структурного подхода

Сущность структурного подхода к разработке ИС заключается в ее декомпозиции

(разбиении) на автоматизируемые функции: система разбивается на

функциональные подсистемы, которые в свою очередь делятся на подфункции,

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

до конкретных процедур. При этом автоматизируемая система сохраняет

целостное представление, в котором все составляющие компоненты

взаимоувязаны. При разработке системы "снизу-вверх" от отдельных задач ко

всей системе целостность теряется, возникают проблемы при информационной

стыковке отдельных компонентов.

Все наиболее распространенные методологии структурного подхода [9,11,12,13]

базируются на ряде общих принципов [3]. В качестве двух базовых принципов

используются следующие:

принцип "разделяй и властвуй" - принцип решения сложных проблем путем их

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

решения;

принцип иерархического упорядочивания - принцип организации составных

частей проблемы в иерархические древовидные структуры с добавлением новых

деталей на каждом уровне.

Выделение двух базовых принципов не означает, что остальные принципы

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

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

проекта). Основными из этих принципов являются следующие:

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

системы и отвлечения от несущественных;

принцип формализации - заключается в необходимости строгого методического

подхода к решению проблемы;

принцип непротиворечивости - заключается в обоснованности и согласованности

элементов;

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

структурированы и иерархически организованы.

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

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

Каждой группе средств соответствуют определенные виды моделей (диаграмм),

наиболее распространенными среди которых являются следующие:

SADT (Structured Analysis and Design Technique) модели и соответствующие

функциональные диаграммы (подраздел 2.2);

DFD (Data Flow Diagrams) диаграммы потоков данных (подраздел 2.3);

ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь" (подраздел

2.4).

На стадии проектирования ИС модели расширяются, уточняются и дополняются

диаграммами, отражающими структуру программного обеспечения: архитектуру

ПО, структурные схемы программ и диаграммы экранных форм.

Перечисленные модели в совокупности дают полное описание ИС независимо от

того, является ли она существующей или вновь разрабатываемой. Состав

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

системы.

2.2. Методология функционального моделирования SADT

Методология SADT разработана Дугласом Россом и получила дальнейшее развитие

в работе [4]. На ее основе разработана, в частности, известная методология

IDEF0 (Icam DEFinition), которая является основной частью программы ICAM

(Интеграция компьютерных и промышленных технологий), проводимой по

инициативе ВВС США.

Методология SADT представляет собой совокупность методов, правил и

процедур, предназначенных для построения функциональной модели объекта

какой-либо предметной области. Функциональная модель SADT отображает

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

между этими действиями. Основные элементы этой методологии основываются на

следующих концепциях:

графическое представление блочного моделирования. Графика блоков и дуг SADT-

диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода

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

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

интерфейсных дуг, выражающих "ограничения", которые в свою очередь

определяют, когда и каким образом функции выполняются и управляются;

строгость и точность. Выполнение правил SADT требует достаточной строгости

и точности, не накладывая в то же время чрезмерных ограничений на действия

аналитика. Правила SADT включают:

ограничение количества блоков на каждом уровне декомпозиции (правило 3-6

блоков);

связность диаграмм (номера блоков);

уникальность меток и наименований (отсутствие повторяющихся имен);

синтаксические правила для графики (блоков и дуг);

разделение входов и управлений (правило определения роли данных).

отделение организации от функции, т.е. исключение влияния организационной

структуры на функциональную модель.

Методология SADT может использоваться для моделирования широкого круга

систем и определения требований и функций, а затем для разработки системы,

которая удовлетворяет этим требованиям и реализует эти функции. Для уже

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

выполняемых системой, а также для указания механизмов, посредством которых

они осуществляются.

2.2.1. Состав функциональной модели

Результатом применения методологии SADT является модель, которая состоит из

диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга.

Диаграммы - главные компоненты модели, все функции ИС и интерфейсы на них

представлены как блоки и дуги. Место соединения дуги с блоком определяет

тип интерфейса. Управляющая информация входит в блок сверху, в то время как

информация, которая подвергается обработке, показана с левой стороны блока,

а результаты выхода показаны с правой стороны. Механизм (человек или

автоматизированная система), который осуществляет операцию, представляется

дугой, входящей в блок снизу (рисунок 2.1).

Одной из наиболее важных особенностей методологии SADT является постепенное

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

отображающих модель.

Рис. 2.1. Функциональный блок и интерфейсные дуги

На рисунке 2.2, где приведены четыре диаграммы и их взаимосвязи, показана

структура SADT-модели. Каждый компонент модели может быть декомпозирован на

другой диаграмме. Каждая диаграмма иллюстрирует "внутреннее строение" блока

на родительской диаграмме.

2.2.2. Иерархия диаграмм

Построение SADT-модели начинается с представления всей системы в виде

простейшей компоненты - одного блока и дуг, изображающих интерфейсы с

функциями вне системы. Поскольку единственный блок представляет всю систему

как единое целое, имя, указанное в блоке, является общим. Это верно и для

интерфейсных дуг - они также представляют полный набор внешних интерфейсов

системы в целом.

Затем блок, который представляет систему в качестве единого модуля,

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

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

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

которых представлена как блок, границы которого определены интерфейсными

дугами. Каждая из этих подфункций может быть декомпозирована подобным

образом для более детального представления.

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

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

какие-либо элементы, т.е., как уже отмечалось, родительский блок и его

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

не может быть ничего удалено.

Модель SADT представляет собой серию диаграмм с сопроводительной

документацией, разбивающих сложный объект на составные части, которые

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

виде блоков на других диаграммах. Каждая детальная диаграмма является

декомпозицией блока из более общей диаграммы. На каждом шаге декомпозиции

более общая диаграмма называется родительской для более детальной

диаграммы.

Дуги, входящие в блок и выходящие из него на диаграмме верхнего уровня,

являются точно теми же самыми, что и дуги, входящие в диаграмму нижнего

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

ту же часть системы.

Рис. 2.2. Структура SADT-модели. Декомпозиция диаграмм

На рисунках 2.3 - 2.5 представлены различные варианты выполнения функций и

соединения дуг с блоками.

Рис. 2.3. Одновременное выполнение

Рис. 2.4. Соответствие должно быть полным и непротиворечивым

Некоторые дуги присоединены к блокам диаграммы обоими концами, у других же

один конец остается неприсоединенным. Неприсоединенные дуги соответствуют

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

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

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

Все граничные дуги должны продолжаться на родительской диаграмме, чтобы она

была полной и непротиворечивой.

На SADT-диаграммах не указаны явно ни последовательность, ни время.

Обратные связи, итерации, продолжающиеся процессы и перекрывающиеся (по

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

выступать в виде комментариев, замечаний, исправлений и т.д. (рисунок 2.5).

Рис. 2.5. Пример обратной связи

Как было отмечено, механизмы (дуги с нижней стороны) показывают средства, с

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

человеком, компьютером или любым другим устройством, которое помогает

выполнять данную функцию (рисунок 2.6).

Рис. 2.6. Пример механизма

Каждый блок на диаграмме имеет свой номер. Блок любой диаграммы может быть

далее описан диаграммой нижнего уровня, которая, в свою очередь, может быть

далее детализирована с помощью необходимого числа диаграмм. Таким образом,

формируется иерархия диаграмм.

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

используются номера диаграмм. Например, А21 является диаграммой, которая

детализирует блок 1 на диаграмме А2. Аналогично, А2 детализирует блок 2 на

диаграмме А0, которая является самой верхней диаграммой модели. На рисунке

2.7 показано типичное дерево диаграмм.

Рис. 2.7. Иерархия диаграмм

2.2.3. Типы связей между функциями

Одним из важных моментов при проектировании ИС с помощью методологии SADT

является точная согласованность типов связей между функциями. Различают по

крайней мере семь типов связывания:

|Тип связи |Относительная значимость |

|Случайная |0 |

|Логическая |1 |

|Временная |2 |

|Процедурная |3 |

|Коммуникационная |4 |

|Последовательная |5 |

|Функциональная |6 |

Ниже каждый тип связи кратко определен и проиллюстрирован с помощью

типичного примера из SADT.

(0) Тип случайной связности: наименее желательный.

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

или полностью отсутствует. Это относится к ситуации, когда имена данных на

SADT-дугах в одной диаграмме имеют малую связь друг с другом. Крайний

вариант этого случая показан на рисунке 2.8.

Рис. 2.8. Случайная связность

(1) Тип логической связности. Логическое связывание происходит тогда, когда

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

общий класс или набор элементов, но необходимых функциональных отношений

между ними не обнаруживается.

(2) Тип временной связности. Связанные по времени элементы возникают

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

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

последовательно.

(3) Тип процедурной связности. Процедурно-связанные элементы появляются

сгруппированными вместе вследствие того, что они выполняются в течение

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

диаграммы приведен на рисунке 2.9.

Рис. 2.9. Процедурная связность

(4) Тип коммуникационной связности. Диаграммы демонстрируют

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

используют одни и те же входные данные и/или производят одни и те же

выходные данные (рисунок 2.10).

(5) Тип последовательной связности. На диаграммах, имеющих последовательные

связи, выход одной функции служит входными данными для следующей функции.

Связь между элементами на диаграмме является более тесной, чем на

рассмотренных выше уровнях связок, поскольку моделируются причинно-

следственные зависимости (рисунок 2.11).

(6) Тип функциональной связности. Диаграмма отражает полную функциональную

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

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

элементов, относящихся к последовательному или более слабому типу

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

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

показано на рисунке 2.12.

Рис. 2.10. Коммуникационная связность

Рис. 2.11. Последовательная связность

В математических терминах необходимое условие для простейшего типа

функциональной связности, показанной на рисунке 2.12, имеет следующий вид:

C = g(B) = g(f(A))

Ниже в таблице представлены все типы связей, рассмотренные выше. Важно

отметить, что уровни 4-6 устанавливают типы связностей, которые

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

Рис. 2.12. Функциональная связность

|Зна|Тип |Для функций |Для данных |

|чим|связно| | |

|ост|сти | | |

|ь | | | |

| |ная | | |

| |ая | | |

2.3. Моделирование потоков данных (процессов)

В основе данной методологии (методологии Gane/Sarson [11]) лежит построение

модели анализируемой ИС - проектируемой или реально существующей. В

соответствии с методологией модель системы определяется как иерархия

диаграмм потоков данных (ДПД или DFD), описывающих асинхронный процесс

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

Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют

основные процессы или подсистемы ИС с внешними входами и выходами. Они

детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция

продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока

не будет достигнут такой уровень декомпозиции, на котором процесс

становятся элементарными и детализировать их далее невозможно.

Источники информации (внешние сущности) порождают информационные потоки

(потоки данных), переносящие информацию к подсистемам или процессам. Те в

свою очередь преобразуют информацию и порождают новые потоки, которые

переносят информацию к другим процессам или подсистемам, накопителям данных

или внешним сущностям - потребителям информации. Таким образом, основными

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

внешние сущности;

системы/подсистемы;

процессы;

накопители данных;

потоки данных.

2.3.1. Внешние сущности

Внешняя сущность представляет собой материальный предмет или физическое

лицо, представляющее собой источник или приемник информации, например,

заказчики, персонал, поставщики, клиенты, склад. Определение некоторого

объекта или системы в качестве внешней сущности указывает на то, что она

находится за пределами границ анализируемой ИС. В процессе анализа

некоторые внешние сущности могут быть перенесены внутрь диаграммы

анализируемой ИС, если это необходимо, или, наоборот, часть процессов ИС

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

сущность.

Внешняя сущность обозначается квадратом (рисунок 2.13), расположенным как

бы "над" диаграммой и бросающим на нее тень, для того, чтобы можно было

выделить этот символ среди других обозначений:

Рис. 2.13. Внешняя сущность

2.3.2. Системы и подсистемы

При построении модели сложной ИС она может быть представлена в самом общем

виде на так называемой контекстной диаграмме в виде одной системы как

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

Подсистема (или система) на контекстной диаграмме изображается следующим

образом (рисунок 2.14).

Рис. 2.14. Подсистема

Номер подсистемы служит для ее идентификации. В поле имени вводится

наименование подсистемы в виде предложения с подлежащим и соответствующими

определениями и дополнениями.

2.3.3. Процессы

Процесс представляет собой преобразование входных потоков данных в выходные

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

реализован различными способами: это может быть подразделение организации

(отдел), выполняющее обработку входных документов и выпуск отчетов,

программа, аппаратно реализованное логическое устройство и т.д.

Процесс на диаграмме потоков данных изображается, как показано на рисунке

2.15.

Рис. 2.15. Процесс

Номер процесса служит для его идентификации. В поле имени вводится

наименование процесса в виде предложения с активным недвусмысленным

глаголом в неопределенной форме (вычислить, рассчитать, проверить,

определить, создать, получить), за которым следуют существительные в

винительном падеже, например:

"Ввести сведения о клиентах";

"Выдать информацию о текущих расходах";

"Проверить кредитоспособность клиента".

Использование таких глаголов, как "обработать", "модернизировать" или

"отредактировать" означает, как правило, недостаточно глубокое понимание

данного процесса и требует дальнейшего анализа.

Информация в поле физической реализации показывает, какое подразделение

организации, программа или аппаратное устройство выполняет данный процесс.

2.3.4. Накопители данных

Накопитель данных представляет собой абстрактное устройство для хранения

информации, которую можно в любой момент поместить в накопитель и через

некоторое время извлечь, причем способы помещения и извлечения могут быть

любыми.

Накопитель данных может быть реализован физически в виде микрофиши, ящика в

картотеке, таблицы в оперативной памяти, файла на магнитном носителе и т.д.

Накопитель данных на диаграмме потоков данных изображается, как показано на

рисунке 2.16.

Рис. 2.16. Накопитель данных

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

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

проектировщика.

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

описание хранящихся в нем данных должно быть увязано с информационной

моделью.

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

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

от источника к приемнику. Реальный поток данных может быть информацией,

передаваемой по кабелю между двумя устройствами, пересылаемыми по почте

письмами, магнитными лентами или дискетами, переносимыми с одного

компьютера на другой и т.д.

Поток данных на диаграмме изображается линией, оканчивающейся стрелкой,

которая показывает направление потока (рисунок 2.17). Каждый поток данных

имеет имя, отражающее его содержание.

Рис. 2.17. Поток данных

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

Первым шагом при построении иерархии ДПД является построение контекстных

диаграмм. Обычно при проектировании относительно простых ИС строится

единственная контекстная диаграмма со звездообразной топологией, в центре

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

и источниками информации, посредством которых с системой взаимодействуют

пользователи и другие внешние системы.

Если же для сложной системы ограничиться единственной контекстной

диаграммой, то она будет содержать слишком большое количество источников и

приемников информации, которые трудно расположить на листе бумаги

нормального формата, и кроме того, единственный главный процесс не

раскрывает структуры распределенной системы. Признаками сложности (в смысле

контекста) могут быть:

наличие большого количества внешних сущностей (десять и более);

распределенная природа системы;

многофункциональность системы с уже сложившейся или выявленной группировкой

функций в отдельные подсистемы.

Для сложных ИС строится иерархия контекстных диаграмм. При этом контекстная

диаграмма верхнего уровня содержит не единственный главный процесс, а набор

подсистем, соединенных потоками данных. Контекстные диаграммы следующего

уровня детализируют контекст и структуру подсистем.

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

функциональных подсистем проектируемой ИС как между собой, так и с внешними

входными и выходными потоками данных и внешними объектами (источниками и

приемниками информации), с которыми взаимодействует ИС.

Разработка контекстных диаграмм решает проблему строгого определения

функциональной структуры ИС на самой ранней стадии ее проектирования, что

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

участвуют разные организации и коллективы разработчиков.

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

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

(отсутствие информационных связей с другими объектами).

Для каждой подсистемы, присутствующей на контекстных диаграммах,

выполняется ее детализация при помощи ДПД. Каждый процесс на ДПД, в свою

очередь, может быть детализирован при помощи ДПД или миниспецификации. При

детализации должны выполняться следующие правила:

правило балансировки - означает, что при детализации подсистемы или

процесса детализирующая диаграмма в качестве внешних источников/приемников

данных может иметь только те компоненты (подсистемы, процессы, внешние

сущности, накопители данных), с которыми имеет информационную связь

детализируемая подсистема или процесс на родительской диаграмме;

правило нумерации - означает, что при детализации процессов должна

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

детализирующие процесс с номером 12, получают номера 12.1, 12.2, 12.3 и

т.д.

Миниспецификация (описание логики процесса) должна формулировать его

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

реализацию проекта, смог выполнить их или разработать соответствующую

программу.

Миниспецификация является конечной вершиной иерархии ДПД. Решение о

завершении детализации процесса и использовании миниспецификации

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

наличия у процесса относительно небольшого количества входных и выходных

потоков данных (2-3 потока);

возможности описания преобразования данных процессом в виде

последовательного алгоритма;

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

информации в выходную;

возможности описания логики процесса при помощи миниспецификации небольшого

объема (не более 20-30 строк).

При построении иерархии ДПД переходить к детализации процессов следует

только после определения содержания всех потоков и накопителей данных,

которое описывается при помощи структур данных. Структуры данных

конструируются из элементов данных и могут содержать альтернативы, условные

вхождения и итерации. Условное вхождение означает, что данный компонент

может отсутствовать в структуре. Альтернатива означает, что в структуру

может входить один из перечисленных элементов. Итерация означает вхождение

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

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

непрерывных данных может указываться единица измерения (кг, см и т.п.),

диапазон значений, точность представления и форма физического кодирования.

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

После построения законченной модели системы ее необходимо верифицировать

(проверить на полноту и согласованность). В полной модели все ее объекты

(подсистемы, процессы, потоки данных) должны быть подробно описаны и

детализированы. Выявленные недетализированные объекты следует

детализировать, вернувшись на предыдущие шаги разработки. В согласованной

модели для всех потоков данных и накопителей данных должно выполняться

правило сохранения информации: все поступающие куда-либо данные должны быть

считаны, а все считываемые данные должны быть записаны.

2.4. Моделирование данных

2.4.1. Case-метод Баркера

Цель моделирования данных состоит в обеспечении разработчика ИС

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

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

систему баз данных.

Наиболее распространенным средством моделирования данных являются диаграммы

"сущность-связь" (ERD). С их помощью определяются важные для предметной

области объекты (сущности), их свойства (атрибуты) и отношения друг с

другом (связи). ERD непосредственно используются для проектирования

реляционных баз данных.

Нотация ERD была впервые введена П. Ченом (Chen) и получила дальнейшее

развитие в работах Баркера [8]. Метод Баркера будет излагаться на примере

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

приведены выдержки из интервью, проведенного с персоналом компании.

Главный менеджер: одна из основных обязанностей - содержание автомобильного

имущества. Он должен знать, сколько заплачено за машины и каковы накладные

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

которую мог бы продать данный экземпляр. Кроме того, он несет

ответственность за продавцов и ему нужно знать, кто что продает и сколько

машин продал каждый из них.

Продавец: ему нужно знать, какую цену запрашивать и какова нижняя цена, за

которую можно совершить сделку. Кроме того, ему нужна основная информация о

машинах: год выпуска, марка, модель и т.п.

Администратор: его задача сводится к составлению контрактов, для чего нужна

Страницы: 1, 2, 3, 4

Рефераты

Case-технлогии