Принципы и приемы оперирования требованиями (продолжение)

Прием 9. Моделирование требований

Моделирование — прием, применимый во многих случаях познавательной и конструкторской деятельности. Есть много случаев и в программистской проектной деятельности, которые естественно трактовать как применение моделирования. Ниже рассматривается лишь один из аспектов моделирования, который непосредственно связан с проблемами оперирования требованиями: задача моделирования области определения системы. Ее можно рассматривать как подчиненную приему 6, специально посвященному управлению области применимости. Но целесообразна более широкая позиция, включающая в себя деятельности этапов конструирования архитектуры и далее программирования и внедрения. Именно в этих двух качествах предлагаются средства поддержки моделирования в развитых CASE-системах.

Применение моделирования в начале проекта и при разработке последующих итераций различается существенно, поскольку в первом случае модель создается "с нуля", а во втором — расширяет сложившуюся модель, а потому поле возможных решений сужается. Мы сначала рассмотрим начальное моделирование, а задачу расширения моделей обсудим при сопоставлении.

Совокупность всех требований в их исходном представлении указывает на определенный аспект реального мира, в рамках которого будет разрабатываться система поддержки деятельности пользователей. В этом смысле данная совокупность может рассматриваться как первичная модель прикладной области. Анализ осуществимости, который включает в себя построение унифицированных представлений требований и типизацию требований, сужает обозначенную прикладную область, делает ее более определенной. С его помощью в первичной модели ликвидируются явные противоречия. Этот процесс можно назвать построением уточненной первичной модели прикладной области.

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

Главной целью моделей уровня анализа является достижение понимания предметной области, для которой строится программная система. В этой связи считается, что эти модели адекватны прикладной области, если они согласованы с инициаторами работ. Способы проведения такого согласования рассматривалась выше. С точки зрения согласования понимается и полнота моделей, которая определяется как отражение в них максимального числа требований, фиксированных (согласованных с инициаторами работ) в унифицированном и типизированном представлениях.

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

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

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

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

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

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

Рис. 14.1. Схема процесса моделирования требований

Приоритетной задачей моделирования как приема оперирования требованиями является обеспечение максимально простого расширения моделей. Трудность здесь заключается в том, что разработчик зачастую стоит перед альтернативой: строить ли новую, дополнительную модель или же модернизировать существующую. Общих рецептов по этому поводу дать невозможно, однако следует указать на то, что система моделей должна оставаться понятной. Для ситуаций использования это утверждение означает, что нет нужды перегружать действиями субъекты, если эти действия разнородны и их совместное представление ничего не поясняет. Нет необходимости объединять разнородные сценарии даже в тех случаях, когда расширение связывает новый фрагмент действий с существующим сценарием. Напротив, при расширении уточняющего характера новые модели вводить не стоит. Особое место в расширяющих построениях занимают объекты, которые выявляются при моделировании. Здесь могут возникнуть проблемы введения новых объектов и классов, абстрактных обобщений, а также использования шаблонов проектирования. Критерий, который чаще всего выставляют как для начального моделирования, так и для расширения, — добиваться возможности независимой реализации различных аспектов системы. Именно он дает возможность максимально простого расширения моделей и, что еще более важно, повторного использования реализации средств любого уровня в конструируемых системах.

Легко заметить, что схема процесса моделирования требований имеет не просто аналогии, но и глубокие параллели с диаграммой трансформации требований (см. рис. 12.1). Это совсем неудивительно, ведь в обоих случаях речь идет об оперировании требованиями, рассматриваемыми как материал весьма похожих деятельностей. Разумно рассматривать моделирование требований в качестве инструмента трассировки.

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

Несколько слов о нотации, применяемой при построении модельных представлений требований. В принципе в проекте можно использовать любые формы таких представлений, если они дают возможность обеспечивать взаимопонимание и однозначное выражение требований. И для локальных проектов, сведения о которых не распространяются далее коллектива разработчиков, такое положение вполне оправданно — нет необходимости осваивать что-то новое, когда старое всех устраивает. Однако ограниченность такого пути очевидна. Он препятствует использованию чужих разработок, не следующих принятым для данного проекта соглашениям, затрудняет последующее распространение рабочих продуктов проекта и их переиспользование в последующих проектах, выходящих за рамки данного коллектива. Затрудняется обучение привлекаемого персонала. Предпочтительнее задействовать стандартные общепринятые представления требований и отработанные методы их трансформации, которые поддерживаются инструментально в рамках интегрированных средств поддержки разработки программного обеспечения CASE-систем (см., например, [50]).

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

Результатом моделирования как приема оперирования требованиями является система моделей области применения программной системы на том уровне, на котором этот прием использован. Эта система удовлетворяет соответствующим условиям корректности моделей.