Диаграмма состояний. Диаграмма состояний в UML описывает все возможные состояния одного экземпляра определенного класса и возможные последовательности его переходов из одного

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

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

Жизненный цикл UML (Rational Objectory Process)

Фирма Rational Software, разработавшая язык UML (Unified Modeling Language - унифицированный язык моделиро­вания), предло­жила также и свою модель ЖЦ, которая называется Rational Objectory Process (ROP). Означенная технология прямого пере­вода не имеет, так как rational в данном случае употребляется в значении «рациональный» и как название фирмы одновременно, во-вторых, слова objectory в английском языке не существует, его лингвообразование аналогично слову repository (накопитель).

Перечислим основные свойства RОР-технологии.

Rational Objectory Process - итеративный процесс, в течение которого происходит последовательное уточнение результатов; направлен именно на создание моделей, анне на разработку каких-либо других элементов проекта(например, текстовых документов).

Действия Rational Objectory Process определяются в первую очередь блоками использования (Use case).

Rational Objectory Process разбит на циклы, каждый из которых, в свою очередь, состоит из четырех фаз:

· начальная стадия (Inception);

· разработка (Elaboration);

· конструирование (Construction);

· ввод в эксплуатацию (Transition).

Результатом работы каждого такого цикла является своя вер­сия программной системы.

Каждая стадия завершается в четко определенной контроль­ной точке (milestone). В этот момент времени должны достигать­ся важные результаты и приниматься критически важные реше­ния о дальнейшей разработке.

Начальная стадия может принимать множество разных форм. Для крупных проектов - это всестороннее изучение всех возможностей реализации на протяжении нескольких месяцев. Здесь же вырабатывается бизнес-план проекта, определяется его стоимость, примерный доход, а также ограничения ресурсов ­иными словами, выполняется некоторый начальный анализ оценки проекта.

Окончанием начального этапа могут служить следующие ре­зультаты:

· начальный проектный словарь терминов;

· общее описание системы - основные требования к проекту, его характеристики и ограничения;

· начальная модель вариантов использования;

· начальный бизнес-план;

· план проекта, отражающий стадии и итерации;

· один или несколько прототипов.

На стадии разработки выявляются более детальные требова­ния к системе, выполняется высокоуровневый анализ предмет­ной области и проектирование базовой архитектуры системы, создается план конструирования и устраняются наиболее риско­ванные элементы проекта.

Самым важным результатом стадии разработки является описание базовой архитектуры будущей системы. Эта архитекту­ра включает:

· модель предметной области, которая служит отправным пунктом для формирования основных абстракций предметной области;.

· технологическую платформу, определяющую основные элементы технологии реализации системы и их взаимодей­ствие.

Стадия разработки занимает примерно пятую часть времени создания проекта, результатом которой являются:

· оценка времени реализации каждого варианта использо­вания;

· идентификация всех наиболее серьезных рисков и возмож­ности их ликвидации.

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

При этом необходимо отметить следующее:

· итерации являются инкрементными в соответствии с вы­полняемой функцией. Каждая итерация добавляет очеред­ные конструкции к вариантам использования, реализован­ным во время предыдущих итераций;

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

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

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

· бета-тестирование, позволяющее убедиться, что новая сис­тема соответствует ожиданиям пользователей;

· параллельное функционирование с существующей (legacy) системой, которая подлежит постепенной замене;

· оптимизацию производительности;

· обучение пользователей и специалистов службы сопровож­дения.