Учебное пособие 1438
.pdf2. Иерархическое упорядочивание по уровням детализации.
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
|
Детализирующая DFD |
|||
|
Поток |
|
Управляю- |
|
|
данных |
|
||
Процесс |
Хранилище |
щий про- |
||
|
|
|
цесс |
|
Специфика- |
Сло- |
ERD |
STD |
|
варь |
||||
ция процес- |
|
|
||
данных |
|
|||
са |
|
|||
|
|
|
||
|
Рис. 5. Компоненты логической модели |
Каждый информационный объект в репозиторий описывается перечислением его свойств: идентификатор, именасинонимы, тип, текстовое описание, компоненты, область значений. Кроме этого, хранятся все отношения с другими объектами, правила формирования и редактирования объекта, а также контрольная информация о времени создания объекта, времени его последнего обновления, номере версии, возможности обновления и т.п.
Репозиторий является базой для стандартизации документации по проекту и контроля проектных спецификаций. Все отчеты строятся автоматически по содержимому репозитория.
Важные функции управления и контроля проекта также реализуются на основе репозитория. В частности, посредством
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
смысл. Ориентация стрелки показывает направление информации от источника к стоку. Сток может быть и двунаправленным, тогда линия помечается двумя стрелками.
|
|
Таблица 2 |
|
Элемент |
Yourdon |
Gane-Sarson |
|
диаграммы |
|
|
|
Поток данных |
Имя |
Имя |
|
|
|
|
|
|
Имя |
Номер |
|
|
|
|
Процесс
Имя
Номер
Хранилище |
Имя |
Имя |
|
Внешняя |
Имя |
|
Имя |
сущность |
|
|
|
|
|
|
|
Процесс преобразует выходной поток из входного. Название процесса обозначают глаголом в неопределенной форме с последующим дополнением («Вычислить процент» и т.п.). Любой процесс имеет свой уникальный номер в диаграмме. Этот номер используется для любых ссылок на процесс.
59
Если связать номер диаграммы и номер процесса, то получится уникальный номер процесса для всей модели.
Хранилище определяет данные, которые сохраняются в памяти между процессами. Это «срезы» потоков данных во времени. Информация из хранилища может выбираться в любое время в любом порядке. Имя хранилища – существительное, отражающее смысл его. Если структура потока данных соответствует хранилищу, из которого входит/выходит поток данных, то хранилище имеет то же имя, что и поток в диаграмме.
Внешняя сущность (терминатор) – объект вне контек-
ста системы, являющийся источником или приемником данных. Имя внешней сущности – имя существительное («Cклад товаров», «Поставщик»). Внешняя сущность не должна участвовать ни в какой обработке данных.
Вмодели всегда присутствует контекстная диаграмма
–специальный вид DFD. Она отражает интерфейс системы с внешним миром, т.е. информационные потоки между системой и внешними сущностями. Каждый проект имеет только одну контекстную диаграмму. Если детализировать DFD в виде дерева, то контекстная диаграмма находится в корне дерева. Из контекстной диаграммы детализируется DFD первого уровня. Эта диаграмма имеет множество процессов, которые декомпозируются в DFD нижнего уровня.
Декомпозиция продолжается до тех пор, пока процессы могут быть эффективно описаны с помощью спецификаций (миниспецификаций обработки данных, приемлемых для программирования). Номера процессов при декомпозиции струк-
турируются: 2.1, 2.1.1, 2.1.2 и т.п.
Часто декомпозиция потоков используется при переходе от одной диаграммы к другой. Потоки данных имеет смысл группировать. Например, «Яблоки», «Бананы», «Апельсины» формально можно определить через поток «Фрукты». Опреде-
60
ление формального потока задается в словаре с помощью формы Бэкуса – Наура (БНФ), а на диаграмме изображается с помощью группового узла. Обратная операция (расщепление потока) представляется также с помощью группового узла и описывается в словаре данных.
Таблица 3
Элемент диаграммы |
Обозначение |
Групповой узел
Узел - предок
Неиспользуемый узел
NU
Узел изменения имени |
Имя 1 |
Имя 2 |
N
Групповой узел расщепляет и объединяет потоки.
U1 |
U3 |
U2 |
|
U1 |
|
U2 |
|
U3 |
|
|
61
Узел–предок расщепляет и объединяет потоки. Неиспользуемый узел показывает, что происходит декомпозиция не всех элементов входящего в узел потока. Узел изменения имени предназначен для неоднозначного именования потока. Комментирующий текст пишется без формата, в любом месте диаграммы.
5.1.3. Рекомендации для построения модели
При построении моделей рекомендуется применять простейшие диаграммные техники, например DFD [6].
Для составления диаграмм используются формальные правила и методики. На любой диаграмме представляют 3-7 процессов, т.к. одновременно больше 7 процессов человеку трудно воспринимать, а менее 3 процессов представлять на диаграмме нецелесообразно. Хотя для сложных систем, например, связанных с управлением банковской деятельностью, приходится показывать на одной диаграмме и более 7 процессов, т.к. меньшее их число не сможет смоделировать реальную обработку данных.
Не следует загромождать DFD несущественными на данном уровне деталями. Декомпозиция потоков проводится одновременно с детализацией процессов. Имена потоков и процессов должны быть ясными, отражающими их суть, желательно не использовать аббревиатуру.
Функционально идентичные процессы необходимо однократно определить на самом верхнем уровне, на нижних уровнях – только ссылаться на них.
Управляющие потоки и процессы необходимо отделять от обрабатывающих потоков и процессов.
Формально построение модели можно представить следующими шагами.
62