· Возможности описания логики процесса при помощи спецификации небольшого объема (не более 20-30 строк).
Спецификации должны удовлетворять следующим требованиям:
·Для каждого процесса нижнего уровня должна существовать одна и только одна спецификация.
·Спецификация должна определять способ преобразования входных потоков в выходные.
·Нет необходимости (по крайней мере на стадии формирования требований) определять метод реализации этого преобразования.
·Спецификация должна стремиться к ограничению избыточности – не следует переопределять то, что уже было определено на диаграмме.
·Набор конструкций для построения спецификаций должен быть простым и понятным.
Фактически спецификации представляют собой описания алгоритмов задач, выполняемых процессами. Спецификации содержат:
1. Номер и/или имя процесса.
2. Списки входных и выходных данных.
3. Тело (описание процесса), являющееся спецификацией алгоритма или операции, трансформирующей входные потоки данных в выходные.
Известно большое количество методов, позволяющих описать тело процесса, соответствующие этим методам языки могут варьироваться от структурированного естественного языка или псевдокода до визуальных языков проектирования.
Структурированный естественный язык применяется для читабельного, достаточно строгого описания спецификаций процессов. Он представляет собой разумное сочетание строгости языка программирования и читабельности естественного языка и состоит из подмножества слов, организованных в определенные логические структуры, арифметических выражений и диаграмм.
В состав языка входят следующие основные символы:
·глаголы, ориентированные на действие и применяемые к объектам;
·термины, определенные на любой стадии проекта ПО (например, задачи, процедуры, символы данных и т.д.);
·предлоги и союзы, используемые в логических отношениях;
·общеупотребительные математические, физические и технические термины;
·арифметические уравнения;
·таблицы, диаграммы, графы;
·комментарии.
К управляющим структурам языка относятся последовательная конструкция, конструкция выбора, итерация (цикл).
При использовании структурированного естественного языка приняты следующие соглашения:
·логика процесса выражается в виде комбинации последовательных конструкций, конструкций выбора и итераций;
·глаголы должны быть активными, недвусмысленными и ориентированными на целевое действие (заполнить, вычислить, извлечь, а не модернизировать, обработать и т.д.);
·логика процесса должна быть выражена четко и недвусмысленно.
При построении иерархии DFD переходить к детализации процессов следует только после определения содержания всех потоков и накопителей данных, которое описывается с помощью структур данных. Для каждого потока данных формируется список всех его элементов данных, затем элементы данных объединяются в структуры данных, соответствующие более крупным объектам данных (например, строкам документов или объектам предметной области).
Каждый объект должен состоять из элементов, являющихся его атрибутами. Структуры данных могут содержать альтернативы, условные вхождения и итерации. Условное вхождение показывает, что данный компонент может отсутствовать в структуре (например, структура «данные о страховании» для объекта «служащий»). Альтернатива означает, что в структуру может входить один из перечисленных элементов. Итерацияпредусматривает вхождение любого числа элементов в указанном диапазоне (например, элемент «имя ребенка» для объекта «служащий»).
Для каждого элемента данных может указываться его тип (непрерывные и дискретные данные). Для непрерывных данных могут указываться единицы измерения (кг, см и т.п.), диапазон значений, точность представления и форма физического кодирования. Для дискретных данныхможет указываться таблица дискретных значений.
После построения законченной модели системы ее необходимо верифицировать (проверить на полноту и согласованность). В полной модели все ее объекты (подсистемы, процессы, потоки данных) должны быть подробно описаны и детализированы. Выявленные не детализированные объекты следует детализировать, вернувшись на предыдущие шаги разработки. В согласованной модели для всех потоков данных и накопителей данных должно выполняться правило сохранения информации: все поступающие куда-либо данные должны быть считаны, а все считываемые данные должны быть записаны.
Сравнительный анализ SADT-моделей и диаграмм
потоков данных
Итак, практически во всех методах структурного подхода (структурного анализа) на стадии формирования требований к ПО используются две группы средств моделирования:
· диаграммы, иллюстрирующие функции, которые система должна выполнять, и связи между этими функциями - DFD или SADT (IDEF0);
· диаграммы, моделирующие данные и их отношения (ERD).
Таким образом, наиболее существенное различие между разновидностями структурного анализа заключается в средствах функционального моделирования. С этой точки зрения все разновидности структурного анализа могут быть разбиты на две группы – использующие DFD (в различных нотациях) и использующие SADT - модели. Соотношение применения этих двух разновидностей структурного анализа в существующих CASE - средствах составляет 90% для DFD и 10% для SADT.
Сравнительный анализ этих двух разновидностей методов структурного анализа проводится по следующим параметрам:
· Адекватность средств решаемым задачам;
· Согласованность с другими средствами структурного анализа;
· Интеграция с последующими стадиями ЖЦ ПО (прежде всего со стадией проектирования).
Адекватность средств решаемым задачам. Модели SADTиспользуются для моделирования организационных систем. С другой стороны, не существует никаких принципиальных ограничений на использование DFD в качестве средства построения статистических моделей деятельности организации. Метод SADT успешно работает только при описании стандартизированных бизнес-процессов в зарубежных корпорациях, поэтому он и принят в США в качестве типового.
Если же речь идет не о системах вообще, а о ЭИС, то здесь DFD вне конкуренции. SADT - диаграммы оказываются значительно менее выразительными и удобными при моделировании ЭИС.
Согласованность с другими средствами структурного анализа. Главным достоинством любых моделей является возможность их интеграции с моделями других типов. В данном случае речь идет о согласованности функциональных моделей со средствами моделирования данных. Согласование SADT - модели с ERD практически невозможно или носит искусственный характер. В свою очередь, DFD и ERDвзаимно дополняют друг друга и являются согласованными, поскольку в DFD присутствует описание структур данных, непосредственно используемое для построения ERD.
Интеграция с последующими стадиями ЖЦ ПО. Важная характеристика модели - ее совместимость с моделями последующих стадий ЖЦ ПО (прежде всего стадии проектирования, непосредственно следующей за стадией формирования требований и опирающейся на ее результаты).
DFD могут быть легко преобразованы в модели проектируемой системы.
Одним из основных критериев выбора того или иного метода является степень владения им со стороны консультанта или аналитика, грамотность выражения своих мыслей на языке моделирования. В противном случае в моделях, построенных с использованием любого метода, будет невозможно разобраться.
Функциональные модели, используемые на стадии проектирования ПО, предназначены для описания функциональной структуры проектируемой системы. Построенные ранее DFD при этом уточняются, расширяются и дополняются новыми конструкциями.
Так, например, для DFD переход от модели бизнес - процессов организации к модели системных процессов может происходить следующим образом:
· внешние сущности на контекстной диаграмме заменяются или дополняются техническими устройствами (например, рабочими станциями, принтерами);
· для каждого потока данных определяется, посредством каких технических устройств информация передается или производится;
· процессы на диаграмме нулевого уровня заменяются соответствующими процессорами – обрабатывающими устройствами (процессорами могут быть как технические устройства – ПК конечных пользователей, рабочие станции, серверы баз данных, так и служащие - исполнители);
· определяется и изображается на диаграмме тип связи между процессорами (например, локальная сеть - LAN);
· определяются задачи для каждого процессора (приложения, необходимые для работы системы), для них строятся соответствующие диаграммы. Определяется тип связи между задачами;
· устанавливаются ссылки между задачами и процессами диаграмм потоков данных следующих уровней.
Иерархия экранных форм моделируется с помощью диаграмм последовательностей экранных форм. Совокупность таких диаграмм представляет собой абстрактную модель пользовательского интерфейса системы, отражающую последовательность появления экранных форм в приложении. Построение диаграмм последовательностей экранных форм выполняется следующим образом:
· на DFD выбираются интерактивные процессы нижнего уровня. Интерактивные процессы нуждаются в пользовательском интерфейсе, поэтому нужно определить экранную форму для каждого такого процесса;
· форма диаграммы изображается в виде прямоугольника для каждого интерактивного процесса на нижнем уровне диаграммы;
· определяется структура меню. Для этого интерактивные процессы группируются в меню (либо так же как в модели процессов, либо другим способом - по функциональным признакам или в зависимости от принадлежности к определенным объектам);