Учебное пособие 1438

2. Иерархическое упорядочивание по уровням детализации.

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

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

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

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

Формализация – строгий методический подход к решению проблемы.

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

Концептуальная общность – единая философия на всем ЖЦ (структурный анализ структурное проектирование структурное программирование структурное тестирование).

Полнота – контроль на присутствие лишних компонен-

тов.

Непротиворечивость – обоснованность и согласованность элементов.

Логическая независимость – концентрация на логиче-

ском, а не физическом проектировании.

Независимость данных и структурирование данных –

иерархическая организация и структурность данных.

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

53

5.1.1.Средства структурного анализа

Влюбой ПС присутствуют следующие составляющие

еечасти:

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

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

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

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

Для моделирования системы выявляются 3 основные типа ее характеристик [6, 13]:

1)функции, которые выполняет система;

2)отношения между данными;

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

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

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

ERD (Entity – Relationship Diagrams) - диаграммы «сущ-

ность – связь»;

STD (State Transition Diagrams) - диаграммы перехода состояний.

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

54

Интегрированное CASE-средство (комплекс средств, поддерживающих полный ЖЦ ПО) содержит следующие компоненты:

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

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

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

4GL (Fourth Generation Language - язык 4-го поколения) и

генераторы'кодов; средства тестирования;

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

средства реверсного инжиниринга ПО и баз дан-

ных;

средства управления требованиями; средства управления конфигурацией ПО; средства документирования.

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

55

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

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

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

56

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

Графические средства (диаграммеры) обеспечивают:

создание иерархически связанных диаграмм, в которых сочетаются графические и текстовые объекты;

создание и редактирование объектов в любом месте диаграммы;

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

сохранение связей между объектами при их перемещении и изменении размеров;

автоматический контроль ошибок и др. Важность контроля ошибок на стадиях формирования

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

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

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

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

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

57

структурами данных и спецификациями процессов. Так, при балансировании DFD-ERD контролируется соответствие каждого хранилища данных на DFD сущности или отношению на

ERD.

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

Словарь данных определяет структуру и компоненты потоков данных, дает подробное представление о необходимых для кодировщиков характеристиках данных. Хранилище (накопитель) данных определяют словарем, модель хранилища данных определяется через ERD. Для моделирования поведения системы в реальном времени используют STD, раскрывающие DFD во времени.

5.1.2. Диаграммы потоков данных (DFD)

Изображают DFD, используя 2 нотации (формы записи): Йодана (Yourdon) и Гейна-Сарсона (Gane-Sarson) [6, 12, 13]. Ниже в табл. 2 представлены обозначения элементов диаграмм потоков данных в двух нотациях.

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

58

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

Процесс

Имя

Номер

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

59

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

Хранилище определяет данные, которые сохраняются в памяти между процессами. Это «срезы» потоков данных во времени. Информация из хранилища может выбираться в любое время в любом порядке. Имя хранилища – существительное, отражающее смысл его. Если структура потока данных соответствует хранилищу, из которого входит/выходит поток данных, то хранилище имеет то же имя, что и поток в диаграмме.

Внешняя сущность (терминатор) – объект вне контек-

ста системы, являющийся источником или приемником данных. Имя внешней сущности – имя существительное («Cклад товаров», «Поставщик»). Внешняя сущность не должна участвовать ни в какой обработке данных.

Вмодели всегда присутствует контекстная диаграмма

–специальный вид DFD. Она отражает интерфейс системы с внешним миром, т.е. информационные потоки между системой и внешними сущностями. Каждый проект имеет только одну контекстную диаграмму. Если детализировать DFD в виде дерева, то контекстная диаграмма находится в корне дерева. Из контекстной диаграммы детализируется DFD первого уровня. Эта диаграмма имеет множество процессов, которые декомпозируются в DFD нижнего уровня.

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

турируются: 2.1, 2.1.1, 2.1.2 и т.п.

Часто декомпозиция потоков используется при переходе от одной диаграммы к другой. Потоки данных имеет смысл группировать. Например, «Яблоки», «Бананы», «Апельсины» формально можно определить через поток «Фрукты». Опреде-

60

ление формального потока задается в словаре с помощью формы Бэкуса – Наура (БНФ), а на диаграмме изображается с помощью группового узла. Обратная операция (расщепление потока) представляется также с помощью группового узла и описывается в словаре данных.

Таблица 3

Групповой узел

Узел - предок

Неиспользуемый узел

NU

N

Групповой узел расщепляет и объединяет потоки.

61

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

5.1.3. Рекомендации для построения модели

При построении моделей рекомендуется применять простейшие диаграммные техники, например DFD [6].

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

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

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

Управляющие потоки и процессы необходимо отделять от обрабатывающих потоков и процессов.

Формально построение модели можно представить следующими шагами.

62