Talablarni kengaytirilgan tahlili. Modellashtirish

Диаграмма состояний
Диаграмма состояний в анализе требований используется, когда требуется исследовать поведение системы, как конечного автомата. Это представление пришло в UML из теории систем.
В общем случае диаграмма состояний описывает, как система себя ведет в более, чем одном варианте использования. Синтаксис диаграмм состояний во многом совпадает с синтаксисом диаграмм действий.
Основные компоненты описания системы: Простые состояния, Составные состояния, Символы "старт" и "стоп", Переходы, Линейки синхронизации объекта.

Рис. 9.5.


Рис. 9.6.
Переход системы из состояния в состояние осуществляется при наступлении событий. При этом говорится, что переход срабатывает. Переход может быть безальтернативным, либо содержать альтернативы. Во втором случае переход обусловлен наступлением сторожевых условий. Наконец, событие может сопровождаться выражением действия, которое происходит в случае, если срабатывает переход. Полный синтаксис описания перехода (надписи на стрелке) следующий:
Событие [сторожевое условие] / выражение действия
Иногда бывает полезным объединить часть состояний в одно мета-состояние. Графически это выглядит, как символ состояния (прямоугольник со скругленными углами), содержащий внутри себя несколько символов состояний. При этом возможны переходы между подчиненными состояниями, переходы между подчиненным и внешним состояниями и переходы между составным и внешним состоянием.
Диаграммы UML, поясняющие внутреннее устройство системы
Некоторые авторы [9.3] рекомендуют использовать при описании требований диаграммы UML, описывающие создаваемую систему через ее компоненты (классы, объекты), отношения и взаимодействия между ними. Данный подход имеет свои ограничения (см. Принцип 2).
Диаграмма классов
Для создания диаграммы классов необходимо:

1. 
   Осуществить поиск классов (ключевых компонент проблемной области).
   
2. 
   Для каждого найденного класса определить его имя, основные атрибуты, операции и (или) ответственности.
   
3. 
   Исследовать отношения найденных классов.
   

Классы на диаграмме представляются в виде прямоугольников, отношения - в виде линий, связывающих прямоугольники. Линии разного типа графически отличаются различной штриховкой и стрелками.
Принято выделять [9.1] 3 уровня абстракции классов:

• 
  концептуальный уровень,
  
• 
  уровень спецификации,
  
• 
  уровень реализации.
  

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

Рис. 9.7.

Диаграмма классов показывает статическую структуру проблемной области. Для анализа взаимодействия объектов - экземпляров класса в ходе реализации варианта использования в UML предусмотрены две диаграммы взаимодействия: диаграмма кооперации и диаграмма последовательности.

По мнению автора, если диаграмма классов в ряде случаев и может рассматриваться, как артефакт, поясняющий структуру проблемной области, то диаграммы взаимодействия вряд ли стоит рассматривать в качестве выразительного языкового средства, иллюстрирующего требования к системе в диалоге "Заказчик-Исполнитель". Тем не менее, в соответствии с Принципом 3 свободы выбора языковых средств, аналитик, решивший использовать данные диаграммы, может ознакомиться с ними в специальной литературе [9.1-9.2].