Представление анализа: разные способы
Использование спецификаций, представленных на языке, подобном языку программирования, проиллюстрированное на примере телепрограмм, ставит очевидный вопрос практичности в обычных условиях.
Источником некоторого скептицизма могут быть неудобства восприятия такой нотации для людей, знакомящихся с результатами анализа. Анализ в большей степени, чем любой другой этап разработки, невозможен без сотрудничества с экспертами в данной области, будущими пользователями, менеджерами, руководителями проектов. Можно ли ожидать, что они будут читать спецификацию, которая на первый взгляд напоминает программный текст (хотя это - чистая модель)?
Неожиданно часто ответ - да. Понимание той части нотации, которая служит для анализа, не требует глубоких знаний в программировании, достаточно понимания элементов логики и способа рассуждений, характерных для любой дисциплины. Автор может засвидетельствовать, что успешно использовал такие спецификации с людьми, имеющими различный уровень опыта и образования.
Но это - не конец истории. Приходится сотрудничать с людьми, нерасположенными к формализму. И даже те, кто ценит мощь формализма, нуждаются в других представлениях, в частности, графических. Сражения между графикой и формализмом, формализмом и естественным языком не имеют смысла. На практике для описания нетривиальной системы могут использоваться дополняющие друг друга способы представления:
- Формальный текст, как в предыдущем примере.
- Графическое представление, отображающее системные структуры в виде диаграмм с помощью "пузырьков и стрелок". Графические образы представляют классы, кластеры, объекты и отношения клиентские и наследования.
- Документ с требованиями на естественном языке.
- Таблица, например, в представлении метода BON далее в этой лекции.
Каждый вариант имеет уникальные преимущества для достижения одних целей анализа и ограничения по отношению к другим целям. В частности:
- Документы на естественном языке незаменимы для передачи основных идей и объяснения тонких нюансов.
Их недостатком является склонность к неточности и двусмысленности. - Таблицы полезны при выделении набора связанных свойств, таких как основные характеристики класса - его родители, компоненты, инварианты.
- Графические представления превосходны для описания структурных свойства проблемы или системы, показывая компоненты и их отношения. Этим объясняется успех "пузырьков-и-стрелок", продвигаемых "структурным анализом". Их ограниченность проявляется, когда наступает время строгого описания семантических свойств. Например, графическое описание является не лучшим местом для ответа на вопрос, какова максимальная длительность рекламной паузы.
- Формальные текстовые представления, являются лучшим инструментом для ответов на такие конкретные вопросы, но не могут конкурировать с графикой, когда нужно быстро понять, как организована система.
Обычный аргумент в пользу графических представлений - шаблонная фраза "изображение стоит тысячи слов". Здесь есть доля правды. Блок-схемы действительно непревзойденно передают впечатление о структуре. Однако это высказывание игнорирует тот факт, что с помощью слов можно передать любые подробности, а неточности рисунка могут приводить к ошибкам. Когда диаграмма предлагается в качестве окончательной спецификации каких-либо тонких особенностей системы, самое время вспомнить загадки типа "найдите все различия" на двух обманчиво похожих рисунках. |
Возникает проблема синхронизации всех представлений. Для этого одно из представлений выбирается в качестве образца (ссылки), а согласованное внесение добавлений и изменений во все остальные представления выполняется специальным программным инструментарием. Лучшим кандидатом на роль образца (фактически единственным) является формальный текст, поскольку только он строго определен и способен охватить и семантику, и структурные свойства.
При таком подходе формальные описания не являются единственным средством анализа. Это дает возможность использовать все разнообразие инструментальных средств, приспособленных к различным уровням квалификации и личным вкусам участников анализа (программисты, менеджеры, конечные пользователи). Поддержка формальных текстов и дополнительных средств анализа может быть встроена в среду программирования. Графическая нотации может использовать CASE-средства, пригодные для создания структурных диаграмм. Тексты на естественном языке могут поддерживаться системой обработки и управления документами. Можно обеспечить аналогичные средства поддержки таблиц. Различные инструментальные средства могут быть как автономными, так и интегрированными в единую среду разработки или анализа.
Изменения в графическом или табличном способе представления должны немедленно отражаться в формальном представлении и наоборот. Например, если на графике класс C показан как потомок класса A (рис. 9.3), то при перемещении указателя на класс B соответствующие средства автоматически внесут необходимые изменения в формальный текст и табличное представление. Наоборот, изменения формального описания сопровождаются модификацией графического и табличного представлений.
Рис. 9.3. Наследственная Связь
Гораздо труднее с помощью инструментальных средств вносить изменения в описание, сделанное на естественном языке. Но если система предусматривает использование структурированных системных описаний с лекциями, разделами и абзацами, то поддержание связей между формальным текстом и документом на естественном языке возможно. Например, можно указать, что некоторый класс или его компонент связан с определенным абзацем требований. Это особенно полезно, когда инструментарий позволяет при внесении любых изменений в исходные требования вывести список всех зависимых элементов формального описания.
Интересно и другое направление - создание из формальных описаний текстов на естественных языках. Идея заключается в восстановлении из формального системного описания обычного текста, выражающего ту же самую информацию в форме, которая не испугает читателей, нерасположенных к формализму.
Не составит труда представить себе инструмент, который на основе нашего эскиза анализа сфабриковал бы следующий текст:
- Системные понятия
Основные понятия системы: SCHEDULE, SEGMENT, COMMERCIAL, PROGRAM ... SCHEDULE обсуждается в пункте 2; SEGMENT обсуждается в пункте 3; [и т.д.] - Понятие SCHEDULE
... - ...
- Понятие COMMERCIAL
- Общее описание:
Рекламные сегменты - Вводные замечания.
Понятие COMMERCIAL - это специализированный вариант понятия SEGMENT, и имеет те же свойства и операции, исключения приведены ниже. - Переименованные операции.
Свойство sponsor для SEGMENT названо advertizer для COMMERCIAL. ... - Переопределенные операции.
... - Новые операции.
Следующие операции характеризуют COMMERCIAL: primary, запрос, возвращающий связанное понятие PROGRAM Аргументы: нет [Если нужно, то здесь перечисляются аргументы] Описание: Программа, с которой связана реклама Начальные условия: ... Конечные условия: ... ...Другие операции... - Ограничения.
...Изложение смысла инвариантных свойств...
- Общее описание:
- Понятие PROGRAM
... и т. д.
Автору неизвестен инструмент, реализующий эту идею, однако цель представляется вполне достижимой. Проект создания такого инструмента гораздо более реалистичен, нежели давно предпринимаемые попытки решения обратной задачи, которые были безуспешными из-за трудностей автоматизированного анализа текстов на естественных языках. Создание текстов более простая задача, точно так же, как реализация синтеза речи гораздо проще ее распознавания.
Такая возможность существует благодаря общности формальной нотации, особенно благодаря наличию поддержки утверждений, что позволяет включить полезные семантические свойства в сгенерированные тексты на естественном языке.Без утверждений мы остались бы в состоянии неопределенности - в облаках.