Ю. А. Григорьев, Г. И. Ревунков - Банки данных

p. Проблемы проектирования систем распределенной обработки данных

Декомпозиция системы на подсистемы

Подсистема 1

Рис. 9.2. Спиральная параллельная модель разработки информационной системы

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

Контрольные вопросы

1.Назовите основные этапы проектирования распределенных систем и охарак­ теризуйте их.

2.Какие задачи решаются на этапе разработки архитектуры СРОД?

3.Какие правила должны соблюдаться при проектировании с использованием CASE-продуктов?

180

10. ВЫЯВЛЕНИЕ ИНФОРМАЦИОННЫХ ПОТРЕБНОСТЕЙ КОНЕЧНЫХ ПОЛЬЗОВАТЕЛЕЙ

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

10.1. Диаграммы потоков данных

Анализ требований разрабатываемой системы является важнейшим среди всех этапов жизненного цикла (ЖЦ). Он оказывает существенное влияние на все последующие этапы, являясь в то же время наименее изученным и понят­ ным. На этом этапе, во-первых, необходимо понять, что предполагается сделать,

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

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

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

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

•заказчик, в свою очередь, без CASE-средств не имеет достаточной информации о проблеме обработки данных, чтобы судить, что является вы­ полнимым, а что — нет;

•аналитик сталкивается с чрезмерным количеством подробных све­ дений о ПО и новой системе;

•спецификация системы из-за объема и технических терминов часто непонятна для заказчика.

Конечные пользователи наиболее часто применяют следующие CASE-средства:

•для описания диаграмм потоков данных совместно со словарями данных и спецификациями процессов или миниспецификациями (Data Flow Diagrams — DFD);

•для описания диаграмм «сущность—связь» (Entity-Relationship Dia­ grams — ERD).

181

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

DFD

Процесс 1 — > Процесс 2

/\ X

Детализация DFD для процесса 3

• Процесс 1 • ^ Процесс 2 [

Рис. 10.1. Компоненты логической модели предметной области

Логическая DFD показывает внешние по отношению к системе источ­ ники и стоки (адресаты) данных, идентифицирует логические функции (процессы) и группы элементов данных, связывающие одну функцию с дру­ гой (потоки), а также определяет хранилища (накопители) данных, к кото­ рым осуществляется доступ. Структуры потоков данных и описания их компонентов хранятся и анализируются в СД. Каждая логическая функция (процесс) может быть детализирована с помощью DFD нижнего уровня. Когда дальнейшая детализация не имеет смысла, переходят к выражению логики функции при помощи спецификации процесса (миниспецификации). Содержимое каждого хранилища также хранится в СД. Модель данных хранилища раскрывается с помощью ERD. Компоненты логической модели ЙО показаны на рис. 10.1.

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

182

10.1. Диаграммы потоков данных

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

Для изображения DFD традиционно используют две различные нота­ ции (нотация — язык описания): Йордана (Yourdon) и Гейна-Сарсона (GaneSarson). Рассмотрим основные символы DFD (табл. 10.1).

Таблица 10.1. Основные символы диаграммы потоков данных

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

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

Храншище (накопитель) данных или БД позволяет на определенных участках найти данные, которые будут сохраняться в памяти между процес-

183

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

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

Внешняя сущность (терминатор) представляет сущность вне контек­ ста системы, являющуюся источником или приемником системных данных. Ее имя должно содержать существительное, например: СКЛАД ТОВАРОВ. Предполагается, что объекты, прдставленные такими узлами, не должны участвовать ни в какой обработке.

10.2.Инструментальные средства описания диаграмм

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

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

184

10.3.Пример разработки диаграммы потоков данных

10.3.Пример разработки диаграммы потоков данных

Диаграммы потоков данных строятся по одной схеме. Рассмотрим пример разработки диаграммы на примере CASE*Designer (Oracle). Следует отметить, что этот продукт является составной частью семейства продуктов ORACLE*CASE.

Перед использованием любого продукта ORACLE*CASE необходимо выполнить определенные действия:

пользователь должен быть зарегистрирован в Oracle и иметь доступ к БД, где хранятся данные CASE*Dictionary;

администратор CASE*Dictionary должен задать имя нового приложе­ ния и предоставить пользователю CASE-средства к таблицам и представле­ ниям CASE*Dictionary, а также его приложениям.

После запуска CASE*Designer появляется новое окно — первое окно CASE*Designer.

Построение диаграммы функций.

1. Выберите пункт меню Techniques/Function Diagrammer. При этом выводится новое окно Function Hierarchy Diagrammer.

2.Создайте начальную или корневую деловую функцию (бизнесфункцию). Выберите кнопку Function и щелкните мышью где-нибудь в цент­ ре окна. CASE*Designer добавляет новую функцию и ждет от вас ввода имени деловой функции. Вы можете набрать метку SECURITES (ценные бумаги) и нажать клавишу TTF для перемещения в поле описания деловой функции. Здесь клавиши идентифицируются не по обозначению на клавиа­ туре, а по их функциям. Это связано с тем, что продукты Oracle работают на различных типах компьютеров. Вы можете ввести описание: «Операции с ценными бумагами». Следующим шагом является добавление дочерних (более детальных) функций. Чтобы добавить новую функцию к родитель­ ской функции, выберите инструментальное средство Function, затем отбук­ сируйте указатель мыши от родительской функции в точку диаграммы, рас­ положенную ниже ее. CASE*Designer запрашивает метку новой функции. Так можно описать все бизнес-функции (рис. 10.2).

3.Для переупорядочивания иерархии функций можно использовать пункт меню Preferences окна Function Hierarchy Diagrammer. Это позволяет представить функции и диаграммы в том формате, который вам подходит: в горизонтальном, вертикальном или гибридном — горизонтальном и верти­ кальном (см. рис. 10.2).

4.Если диаграмма содержит много функций различных уровней, то с помощью пунктов Diagram/Reopen Up и Diagram/Reopen Down вы можете открывать и закрывать нижние уровни родительских функций.

5.При проектировании диаграммы функций возможны ошибки. От­ редактировать метку функции или описания можно простым ее выбором и командой Edit/Edit. Если вы считаете, что добавили новую функцию по

185

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

Рис. 10.2. Законченный эскиз диаграммы иерархии деловых функций

ошибке, то можете удалить ее с помощью пункта меню Edit/Delete. Инстру­ ментальные средства Маке Parent и Маке Root позволяют переместить функцию из одного места иерархической диаграммы в другое.

186

10.3.Пример разработки диаграммы потоков данных

6.Для завершения работы с Function Hierarchy Diagrammer выберите пункт меню Diagram/Quit.

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

1.Выберите пункт Techniques/Dataflow Diagrammer. После запуска Dataflow Diagrammer выберите пункт Diagram/New, чтобы создать новую диаграмму потоков данных. CASE*Designer предложит ввести имя корне­ вой функции (SECURITES). После этого CASE*Designer запросит задать для диаграммы размер страницы и ее расположение в окне Dataflow Dia­ grammer. В результате в диаграмму включается корневая деловая функция.

2.Теперь можно загрузить для корневой функции внутренние функ­ ции, показав прохождение потоков данных через эту часть системы. Da­ taflow Diagrammer в CASE*Designer позволяет легко загрузить определен­ ные ранее деловые функции. Когда вы выберите пункт меню Edit/Copy in Function, выведется диалоговое окно с дочерними функциями корневой функции диаграммы. В этом диалоге выберите дочернюю функцию и по­ местите ее в диаграмме. Повторите этот процесс для каждой дочерней функции. С помощью инструментального средства Function вы можете до­ бавить новую дочернюю функцию.

Далее с помощью инструментальных средств можно уточнить описа­ ние корневой функции (рис. 10.3).

Средством External можно добавить внешние сущности (Субъект рынка ЦБ и Банк-респондент ценных бумаг). Средство Datastore позволяет описать БД, с которыми работает эта задача, а инструмент Dataflow — описать связи между функциями, базами и внешними сущностями (линии со стрелками).

Выбрав какую-либо функцию, ее можно детализировать также, как и корневую.

3. Чтобы сохранить диаграмму потоков данных и выйти из Dataflow Diagrammer, выберите пункты меню Diagram/Save и Diagram/Quit.

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

Семейство ORACLE*CASE помимо CASE*Designer включает и дру­ гие компоненты:

CASE*Method — структурная методология проектирования систем, охватывающая полностью все этапы жизненного цикла ИС. В соответствии с этой методологией на этапе планирования определяются цели создания системы, приоритеты и ограничения, разрабатывается системная архитекту­ ра и план разработки ИС.

При анализе требований строится диаграмма функциональной иерар­ хии (на основе функциональной декомпозиции ИС), диаграмма потоков данных, концептуальная схема БД (диаграмма «сущность—связь»), матрица перекрестных ссылок.

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

187

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

Рис. 10.3. Уточнение функции SECURITES

188

10.3. пример разработки диаграммы потоков данных

На этапе реализации создается БД, строятся прикладные системы, вы­ полняется их тестирование, проверка качества и соответствия требованиям пользователей. Создается системная документация, материалы для обучения и руководство пользователя.

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

•CASE*Designer обеспечивает графический интерфейс при разработ­ ке различных моделей (диаграмм) ПО. В процессе построения моделей ин­ формация о них заносится в словарь (CASE*Dictionary). Среда функциони­ рования Unix, OS/2.

•CASE*Dictionary — словарная система, представляющая собой хранилище всех проектных данных. CASE*Dictionary может работать в многопользовательском режиме, обеспечивая параллельное обновление информации несколькими разработчиками. В процессе проектирования автоматически поддерживаются перекрестные ссылки между объектами словаря и могут генерироваться более 70 стандартных отчетов о моде­ лируемой ПО. Среда функционирования — Unix, VAX/VMS, OS/2, MS DOS, MS Wincbws.

•CASE*Generator для ORACLE*Forms обеспечивает генерацию интерактивных приложений, которые затем могут выполняться в среде ORACLE*Forms. Генерируемые приложения содержат различные экранные формы, средства контроля данных, проверки ограничений целостности и автоматические подсказки.

•CASE*Exchange обеспечивает интерфейс с некоторыми другими CASEсистемами, независимыми от СУБД Oracle (KnowledgeWare, ICL-DDS и др.).

•Designer/2000 содержит компоненты, реализующие следующие функции:

-Repository Administrator — обслуживание репозитория;

-Process Modeller — средство анализа и моделирования информаци­ онных потоков, основывающееся на концепциях теории моделирования бизнес-процессов (BPR — Business Process Reengineering);

-System Modeller — построение диаграммы функциональных иерар­ хий, диаграммы потоков данных, диаграммы «сущность—связь», матрицы перекрестных ссылок;

-Data Diagrammer — разработка реляционной модели;

-Module Data Diagrammer, Module Structure Diagrammer и Module

Logic Navigator — построение иерархии, структуры и логики приложения;

- Systems Designer — средство модификации автоматически генери­ руемых описаний приложений, учитывающее конкретные особенности их аппаратной и программной реализации;

189