Какие модели использовать
Вербальные описания вариантов использования системы, рассмотренные в предыдущей лекции, на сегодня являются стандартом де-факто для формулировки соглашения между Заказчиком и Исполнителем. Если обе стороны готовы выделить достаточное количество времени на внимательный и всесторонний анализ требований к системе и на начальной фазе ее создания сформулировали 80% всех возможных сценариев использования системы на понятном сторонами языке - значит, ключевые риски создания системы - риск различного понимания проблемы и риск размытия границ во многом преодолены.
Однако, далеко не всякий Заказчик готов скрупулезно обсуждать скучные тома описания вариантов использования, которые даже для систем среднего размера могут достигать сотни страниц.
Чтобы облегчить процесс формулировки и понимания требований для Заказчика, существует ряд приемов. Во-первых, требования можно формулировать на разных уровнях абстракции. Так, уровень описания требований, поддерживаемый в документе "Видение", является достаточно сбалансированным. То же можно сказать и про краткие (в один абзац) описания ключевой функциональности системы. Действуя таким образом, мы, очевидно, решим проблему вовлечения Заказчика в анализ задач, однако указанные выше риски будут снижены недостаточно: концептуальные описания функциональности оставляют много свободы для толкования в ту или иную сторону.
Хорошим подспорьем в решении задачи является применение визуальных средств описания требований. Как известно, у большинства людей правополушарное (образное) мышление позволяет воспринимать информацию в разы и порядки более ускоренном темпе, чем левополушарное (вербальное).
На сегодня в арсенале аналитика существуют десятки методик, языков, визуальных представлений, позволяющих моделировать требования к системе. При создании информационных систем стандартом де-факто является универсальный язык моделирования, UML [лекции 5.
Как уже отмечалось в лекции, посвященной анализу контекста АТ, процесс анализа требований тесно связан, с одной стороны, с анализом проблемной области, с другой - с архитектурным анализом и проектированием. Часто на практике бывает трудно вычленить границы компетенций этих потоков работ. Так, модель анализа потоков данных, широко используемая в анализе проблемной области, упоминается многими авторами, как модель, полезная в анализе требований. Ряд исследователей считает целесообразным иллюстрировать описания требований диаграммами классов, хотя, строго говоря, выделение классов относится не к анализу требований, а к архитектурному анализу.
Как определить целесообразность использования тех или иных приемов, методик, языков моделирования при анализе требований? Здесь можно предложить три практические рекомендации.
Во-первых, анализ требований призван изучать взаимодействия автоматизированной информационной системы и ее среды, т.е. пользователей, сетевых и системных компонент, находящихся вне системы. Следовательно, бизнес-модели, описывающие взаимодействия между компонентами организационной системы, строго говоря, можно рассматривать лишь как "сырье" для извлечения требований, но не как модели, описывающие требования.
Во-вторых, анализ требований должен находить ответ на то, ЧТО делает система, абстрагируясь от деталей реализации, т.е. того, КАК она это делает. Поэтому, допустим, диаграмму взаимодействия объектов, реализующих тот или иной вариант использования, можно рассматривать скорее, как иллюстрацию внутреннего устройства системы, полезную для программиста, чем модель для заказчика.
Однако, наиболее важным является третье соображение, в чем-то "оппозиционное" по отношению к первым двум. Для моделирования анализа требований следует применять модели, наиболее адекватно проясняющие функциональность системы и особенности ее использования. Однако, аналитик волен выбирать те языки и методики, которые позволят добиться целевой функции: снижения рисков непонимания между Исполнителем и Заказчиком и размытия границ. Поэтому, иллюстрируя варианты использования, начинайте с "канонических" способов, которые будут рассмотрены чуть ниже, но, если посчитаете целесообразным отклониться от них - экспериментируйте смело.
Модели UML, поясняющие функциональность системы
Диаграмма вариантов использования
Диаграмма вариантов использования UML, Use case Diagram - одно из самых простых представлений системы. Ее базовые "строительные элементы" - акторы и варианты использования. Диаграмма задумана так, чтобы дать наиболее общее представление о функциональности системы (ее компоненты), не вдаваясь в детали взаимосвязей функций. Поэтому основной вид отношения, используемый в диаграмме - ассоциация между актором и вариантом использования.
(рис 9.1)
Другие виды отношений - отношение включения (include), расширения (extend) и обобщения/генерализации.
Включение служит для обозначения подчиненных вариантов использования (когда один или более вариантов использования содержат вызовы одной и той же функциональности).
(рис 9.2)
Расширение в точности соответствует точке расширения, используемой при описании варианта использования, см. лекцию 8.
(рис 9.3)
Отношение обобщения может применяться как к акторам, так и к вариантам использования, с целью указания специализации одних относительно других.
(рис 9.4)
Диаграмма действий
Если диаграмма вариантов использования дает "вид сверху" на функциональность системы, диаграмма действий UML, напротив, позволяет подробно иллюстрировать отдельный вариант использования и его сценарии.
Основные компоненты описания системы:
Функции (действия),
Символы "старт" и "стоп",
Потоки управления,
Разветвители,
Линейки синхронизации.
(рис 9.5)
Диаграмма действий позволяет проиллюстрировать вариант использования с требуемой степенью подробности. Линейный вариант использования приводит к диаграмме действий с линейным потоком управления между действиями. Действия варианта использования с альтернативными сценариями реализуется через разветвители. Линейки синхронизации позволяют описывать такие сложные конструкции, как синхронизацию начала (окончания) параллельных во времени процессов.
Помимо стандартного формата описания, UML предлагает вариант с "плавательными дорожками". Этот формат удобен для описания случая, когда в варианте использования участвуют несколько акторов.
Диаграмма состояний
Диаграмма состояний в анализе требований используется, когда требуется исследовать поведение системы, как конечного автомата. Это представление пришло в UML из теории систем.
В общем случае диаграмма состояний описывает, как система себя ведет в более, чем одном варианте использования. Синтаксис диаграмм состояний во многом совпадает с синтаксисом диаграмм действий.
Основные компоненты описания системы:
Простые состояния,
Составные состояния,
Символы "старт" и "стоп",
Переходы,
Линейки синхронизации.
В языке UML под состоянием понимается абстрактный метакласс, используемый для моделирования отдельной ситуации, в течение которой имеет место выполнение некоторого условия [9.2]. Состояние может быть задано в виде набора конкретных значений атрибутов класса или объекта, при этом изменение их отдельных значений будет отражать изменение состояния моделируемого класса или объекта.
(рис 9.6)
Переход системы из состояния в состояние осуществляется при наступлении событий. При этом говорится, что переход срабатывает. Переход может быть безальтернативным, либо содержать альтернативы. Во втором случае переход обусловлен наступлением сторожевых условий. Наконец, событие может сопровождаться выражением действия, которое происходит в случае, если срабатывает переход. Полный синтаксис описания перехода (надписи на стрелке) следующий:
Событие [сторожевое условие] / выражение действия
Иногда бывает полезным объединить часть состояний в одно мета-состояние. Графически это выглядит, как символ состояния (прямоугольник со скругленными углами), содержащий внутри себя несколько символов состояний. При этом возможны переходы между подчиненными состояниями, переходы между подчиненным и внешним состояниями и переходы между составным и внешним состоянием.
Диаграммы UML, поясняющие внутреннее устройство системы
Некоторые авторы [9.3] рекомендуют использовать при описании требований диаграммы UML, описывающие создаваемую систему через ее компоненты (классы, объекты), отношения и взаимодействия между ними. Данный подход имеет свои ограничения (см. Принцип 2).
Диаграмма классов
Для создания диаграммы классов необходимо:
Осуществить поиск классов (ключевых компонент проблемной области).
Для каждого найденного класса определить его имя, основные атрибуты, операции и (или) ответственности.
Исследовать отношения найденных классов.
Классы на диаграмме представляются в виде прямоугольников, отношения - в виде линий, связывающих прямоугольники. Линии разного типа графически отличаются различной штриховкой и стрелками.
Принято выделять [9.1] 3 уровня абстракции классов:
концептуальный уровень,
уровень спецификации,
уровень реализации.
Анализ требований разумно сопровождать диаграммами, отражающими концептуальный уровень. На данном уровне при описании классов целесообразно указать их наименования и ответственности. Атрибуты и операции можно не указывать, либо ввести только самые основные, отложив их исследование на более поздние стадии детализации.
Отношения, подлежащие анализу на концептуальном уровне - это:
(рис 9.7)
Диаграмма классов показывает статическую структуру проблемной области. Для анализа взаимодействия объектов - экземпляров класса в ходе реализации варианта использования в UML предусмотрены две диаграммы взаимодействия: диаграмма кооперации и диаграмма последовательности.
По мнению автора, если диаграмма классов в ряде случаев и может рассматриваться, как артефакт, поясняющий структуру проблемной области, то диаграммы взаимодействия вряд ли стоит рассматривать в качестве выразительного языкового средства, иллюстрирующего требования к системе в диалоге "Заказчик-Исполнитель". Тем не менее, в соответствии с Принципом 3 свободы выбора языковых средств, аналитик, решивший использовать данные диаграммы, может ознакомиться с ними в специальной литературе [9.1-9.2].
Альтернативные языки моделирования
Диаграмма потоков данных
Диаграмма потоков данных (data flow diagram, DFD) - один из основных инструментов структурного анализа и проектирования информационных систем, существовавших в "доюмээльную" эпоху. Несмотря на имеющее место в современных условиях смещение акцентов от структурного к объектно-ориентированному подходу к анализу и проектированию систем, "старинные" структурные нотации по-прежнему широко и эффективно используются как в бизнес-анализе, так и в анализе информационных систем.
DFD (Data Flow Diagram) – диаграмма потоков данных [41]. Методология графического структурного анализа, описывающая взаимосвязи функций системы с потоками и хранилищами данных, а также с внешними по отношению к системе источниками, к которым осуществляется доступ. Диаграмма DFD – один из основных инструментов структурного анализа и проектирования информационных систем. Авторы SWEBOK 3.0 http://www.computer.org/portal/web/swebok/swebokv3 отмечают полезность DFD при анализе безопасности информационных систем, поскольку в нем удобно проводить идентификацию возможных путей атак и раскрытия конфиденциальной информации.
Исторически сложилось так, что для описания диаграмм DFD используются две нотации - Йодана (Yourdon) и Гейна-Сарсона (Gane-Sarson), отличающиеся синтаксисом. На приведенной ниже иллюстрации использована нотация Гейна-Сарсона.
(рис 9.8)
Информационная система принимает извне потоки данных. Для обозначения элементов среды функционирования системы используется понятие внешней сущности. Внутри системы существуют процессы преобразования информации, порождающие новые потоки данных. Потоки данных могут поступать на вход к другим процессам, помещаться (и извлекаться) в накопители данных, передаваться к внешним сущностям.
Модель DFD, как и большинство других структурных моделей - иерархическая модель. Каждый процесс может быть подвергнут декомпозиции, т.е. разбиению на структурные составляющие, отношения между которыми в той же нотации могут быть показаны на отдельной диаграмме. Когда достигнута требуемая глубина декомпозиции - процесс нижнего уровня сопровождается мини-спецификацией (текстовым описанием).
Кроме того, нотация DFD поддерживает понятие подсистемы - структурной компоненты разрабатываемой системы.
Нотация DFD - удобное средство для формирования контекстной диаграммы, т.е. диаграммы, показывающей разрабатываемую АИС в коммуникации с внешней средой. Это - диаграмма верхнего уровня в иерархии диаграмм DFD. Ее назначение - ограничить рамки системы, определить, где заканчивается разрабатываемая система и начинается среда. Другие нотации, часто используемые при формировании контекстной диаграммы - диаграмма SADT Марка Д.А. Методология структурного анализа и проектирования. - С.-Пб.: Питер, 1995. - 235 с., диаграмма Диаграмма вариантов использования.
Другие виды моделей
Среди многообразия моделей, использующихся в анализе систем, хочется особо отметить еще две нотации, позволяющие описать сложные многоальтернативные взаимодействия компонент информационной системы - нотацию IDEF3 [9.4] и eEPC-диаграмму ARIS [9.6].
EPC Event-Driven Process Chain - цепочка функций, направляемая событиями [24]. Событийно-ориентированная графическая диаграмма функций; используется в методологии ARIS. Позволяет строить сложные комбинации вызовов функций на основе генерируемых ими событий с использованием логических операторов. Содержит широкие иллюстративные возможности для описания контекста каждой функции (например – источники данных, оргтехника, пользователи и т.д.).
Для моделирования требований к системам с разветвленной логикой К.Вигерс рекомендует использовать таблицы и деревья решений [Вигерс]. Часто на практике бывают полезны диаграммы сущность-связь и SADT-диаграммы [Маклаков].
1. Визуальное моделирование является необходимым дополнением к текстовым описаниям требований, так как решает проблему восприятия больших объемов информации заказчиком.
2. Универсальный язык моделирования (UML) предлагает набор диаграмм, покрывающих разные потребности: от общего обзора системы (Use Case) до детального описания алгоритмов (Activity) и поведения (State).
3. Ключевая задача аналитика — не просто нарисовать диаграмму по стандарту, а выбрать такой способ визуализации, который максимально снизит неопределенность и риск неверного толкования требований.
4. При моделировании требований важно сохранять фокус на внешнем поведении системы и ее взаимодействии с пользователями, не подменяя этот процесс ранним проектированием внутренней архитектуры (диаграммами классов высокого уровня детализации или диаграммами последовательности).
5. Помимо объектно-ориентированного подхода (UML), в анализе требований остаются востребованными классические структурные нотации, такие как DFD, особенно для определения контекста системы и моделирования потоков данных.
1. В чем заключается основная проблема использования только текстовых описаний вариантов использования (Use Case) для средних и крупных проектов?
2. Назовите три практические рекомендации (принципа), которыми следует руководствоваться аналитику при выборе языка или методики моделирования требований.
3. Какие два основных типа отношений (помимо простой ассоциации) используются на диаграмме вариантов использования (Use Case Diagram) и для чего они предназначены?
4. Чем отличается диаграмма действий (Activity Diagram) от диаграммы состояний (State Diagram) в контексте анализа требований?
5. Почему использование диаграммы классов (Class Diagram) на этапе анализа требований должно ограничиваться концептуальным уровнем?
6. Для каких целей в анализе требований используется диаграмма потоков данных (DFD) и что такое "контекстная диаграмма"?
