16.2. Методы и средства структурного анализа
Все методологии структурного анализа базируются на некоторых общих принципах.
Базовыми можно считать принцип «разделяй и властвуй» и принцип иерархического упорядочения. В соответствии с этими принципами трудные проблемы решаются путем последовательного разбиения их на множество меньших, относительно независимых задач, легких для понимания и решения; причем «понимаемость» проблемы повышается при организации ее частей в виде древовидных иерархических структур. То есть исследуемая система может быть понята и построена по уровням, каждый из которых добавляет новые детали.
Следует выделить также принципы
– абстрагирования (выделение существенных для решения задачи свойств системы и отвлечение от несущественных);
– «упрятывания» (скрывается несущественная для данного этапа и задачи информация);
– формализации (использование строгих методических подходов к решению);
– концептуальной общности (следование единой методологии на всех этапах разработки системы);
– полноты (контроль на присутствие «лишних» элементов);
– непротиворечивости (контроль за обоснованностью и согласованностью элементов);
– структурирования данных (данные должны быть структурированы и иерархически организованы);
– независимости данных (модели данных должны быть проанализированы и спроектированы независимо от процессов их логической обработки и от их физической структуры и распределения);
– доступа конечного пользователя (пользователь должен иметь средства доступа к данным, которые он может использовать непосредственно, без программирования).
Этими принципами следует руководствоваться при использовании любой методологии разработки информационной системы.
Для моделирования и структурного анализа используются различные средства, которые можно разбить на три группы, описывающие:
– функции, которые система должна выполнять;
– отношения между данными;
– зависящее от времени поведение системы.
Для решения этих задач наиболее часто используются следующие средства:
– диаграммы потоков данных (DFD – Data Flow Diagrams) совместно со словарями данных и спецификациями процессов;
– диаграммы «сущность–связь» (ERD – Entity–Relationship Diagrams);
– диаграммы переходов состояний (STD – State Transition Diagrams).
Все эти диаграммы дают возможность точно определить компоненты модели и связи между ними.
DF-диаграммы показывают внешние по отношению к системе, протекающим в ней процессам источники и стоки (т.е. адресатов) данных, определяют процессы (функции, выполняемые в системе) и группы элементов данных, связывающие один процесс с другим (потоки данных), а также идентифицируют хранилища данных, к которым осуществляется доступ. Каждый процесс может быть детализирован с помощью DFD следующего уровня.
Модель хранилища раскрывается с помощью ER-диаграммы. Содержимое каждого хранилища описывается также в словаре данных.
Если поведение системы зависит от времени, DF-диаграммы дополняются ST-диаграммами, показывающими, как меняется состояние системы во времени.
Потоки данных в DFD – это механизмы моделирования передачи информации в системе. Они обычно изображаются стрелками, показывающими направление передачи.
Назначение процесса в DF-диаграмме – продуцирование выходных потоков из входных при выполнении некоторого действия, задаваемого именем процесса.
Хранилища данных здесь – это накопители данных. Они позволяют определить данные, которые должны сохраняться между процессами. Это «срезы» потоков данных во времени.
На рис. 3.13 показана диаграмма банковской задачи обслуживания клиентов, имеющих кредитные карты (процесс «Обслужить»).
Для начала обслуживания клиент должен предоставить свою кредитную карту, с которой может быть считана информация (пароль, лимит денег и пр.), а также сообщить свои ключевые данные (пароль и запрос на обслуживание).
Процесс банковского обслуживания включает следующие шаги: передача сообщения, приглашающего клиента ввести ключевые данные; выдача денег и выписки по проведенному обслуживанию.
В процессе обслуживания происходит обмен данными с банковским компьютером (передаются данные по счету клиента в банке и протокол обслуживания).
DF-диаграммы являются удобным средством описания функционирования компонентов системы. Если поведение системы зависит от времени, определяется реакцией на определенные события, то для моделирования и документирования этих аспектов поведения системы используются диаграммы переходов (STD).
ST-диаграммы состоят из объектов, представляющих состояния и переходы. С помощью этих диаграмм можно моделировать последующее поведение системы на основе ее предыдущего поведения и текущего состояния. Моделируемая система в каждый момент времени находится ровно в одном состоянии. Возможные изменения состояния показываются переходами.
Начальное состояние – это узел, являющийся стартовой точкой для начального системного перехода. Для каждого состояния должна быть информация, позволяющая определить состояния, в которые система может перейти в зависимости от происходящих событий. Событие (или события) определяют условие, вызывающее переход. Кроме условия с переходом может быть связано действие (операция, которая выполняется при выполнении перехода, например, активизация указанного процесса).
Состояния в диаграмме представляются узлами, а переходы – дугами. Условия привязаны к дугам, а действия записываются под соответствующим условием. Упрощенная ST-диаграмма банковской задачи показана на рис. 3.14.
Таким образом описывается последовательность действий в процессе обслуживания клиента.
DF-диаграммы являются удобным средством описания функционирования компонентов системы и связей между ними, но они не содержат знаний о том, какая информация преобразуется процессами.
Словарь данных представляет собой определенным образом организованный список всех элементов данных системы с их точными определениями. Словарь гарантирует общее понимание всех входных и выходных потоков и компонентов хранилищ всеми категориями пользователей и разработчиков информационной системы (от системных аналитиков до программистов).
Для разработки моделей данных предназначены диаграммы ERD («сущность–связь»). ER-диаграммы обеспечивают стандартный способ определения данных и отношений между ними. С помощью этих диаграмм осуществляется детализация хранилищ данных проектируемой информационной системы, а также документируются объекты системы и способы их взаимодействия (важные для предметной области свойства объектов, их отношения с другими объектами).
ER-диаграммы включают несколько типов элементов.
Сущность – множество экземпляров реальных или абстрактных объектов (людей, событий, состояний и т.п.), обладающих общими атрибутами (характеристиками). Любой объект представляется только одной сущностью, которая должна быть уникальным образом идентифицирована (имя отражает класс объекта).
Отношение – это связь между двумя и более сущностями (например, имеет, определяет и т.п.).
Для обозначения этих элементов в ER-диаграмме используются специальные символы (символы ERD приведены в нотации Чена):
– независимая сущность, представляющая независимые данные, которые всегда присутствуют в системе. Отношения с другими сущностями могут отсутствовать;
– зависимая сущность, представляющая данные, зависящие от других сущностей в системе, поэтому она всегда должна иметь отношения с другими сущностями;
– ассоциированная сущность, представляющая данные, которые ассоциируются с отношениями между двумя и более сущностями;
– неограниченное (обязательное) отношение, которое существует всегда, пока существуют связанные им сущности;
– ограниченное (необязательное) отношение, представляющее собой условное отношение между сущностями;
– существенно-ограниченное отношение, используемое, когда соответствующие сущности взаимозависимы в системе.
Связи определяют требования, в соответствии с которыми сущности вовлекаются в отношения, т.е. связь соединяет сущность и отношение. Значение связи характеризует ее тип (выбирается, как правило, из следующего множества: «0 или 1», «0 или более», «1 или более», «p:q» (диапазон)). Пара значений связей, принадлежащих одному и тому же отношению, определяет его тип («один–к–одному», «один–ко–многим», «многие–ко–многим»).
На рис. 3.15 представлена упрощенная ER-диаграмма, демонстрирующая отношения между объектами банковской системы.
Каждая сущность обладает одним или несколькими атрибутами. Диаграммы атрибутов детализируют сущности, раскрывая ассоциированные с ними атрибуты.
Кратко описанные выше средства структурного системного анализа позволяют построить модель требований системы, которая состоит из множества взаимосвязанных диаграмм, словаря данных и текстов. Модель требований описывает, что должна делать проектируемая система без указаний того, как это должно быть реализовано.
На этапе проектирования строится модель реализации, описывающая, как система будет удовлетворять предъявленные к ней требования. Для построения этой модели разработчиками ПО используются различные средства структурного проектирования. На этом этапе уточняется построенная модель (подробно разрабатывается логика каждого процесса), проектируется физическая база данных, строится иерархия функций модулей, подлежащих программированию, оцениваются затраты на реализацию. Построенная модель в дальнейшем используется при программировании.
Существуют различные методологии анализа и проектирования, которые основаны на различных принципах, имеют определенные особенности. Различные методологии структурного анализа и проектирования могут использовать различные техники структурных диаграмм, таблицы, деревья решений, матрицы состояний и переходов, контекстные графы и т.п. и их комбинации. Например, для проектирования систем реального времени используются специальные типы структурных диаграмм, но многие из них являются вариациями (диалектами) описанных выше структурных диаграмм, используемых при проектировании информационных систем.
Одной из самых известных методологий анализа и проектирования информационных систем является методология SADT (Structured Analysis and Design Technique), введенная еще в 1973 г. Россом. SADT успешно использовалась в военных, промышленных и коммерческих организациях для решения различных классов задач (долгосрочное и стратегическое планирование, управление финансами и материально-техническим снабжением и др.).
Другой пример – DSSD (Data-Structured Systems Development) – методология, ориентированная на разработку систем со структурными данными.
Еще один пример известной методологии – методология Мартина предоставляет общую стратегию разработки информационных систем, фокусирующую внимание на стратегическом планировании и бизнес-процессах. Это инженерный подход к разработке информационных систем, обеспечивающий нисходящую пошаговую процедуру построения ИС, позволяющую работать с иерархическими структурами данных.
Выбор конкретной методологии анализа и проектирования зависит от типа разрабатываемой системы, области ее применения, используемых инструментальных средств. Но все они позволяют четко формализовать описание разрабатываемой системы, что делает следующие этапы разработки менее трудоемкими, поддающимися автоматизации.