Содержание курса

• ВВЕДЕНИЕ

• Введение в процесс формирования требований

• Инфраструктура (ландшафт) для организации проектной деятельности

• Управление целями заинтересованных лиц

• Формализация потребностей заказчика

• Выявление функции системы. 1.Теория систем Часть 1

• Выявление функции системы. 2. Моделирование сервисов

• Инжиниринг бизнес-процессов заказчика. 1. Применение UML Activity

• Инжиниринг бизнес-процессов заказчика. 2. Применение BPMN. Предварительный расчет ресурсоемкости проекта.

• Разработка логической структуры данных. 1. Применение UML Class diagram. Приемы и подходы проектирования

• Разработка логической структуры данных. 2. Паттерны проектирования применительно к структуре данных.

• Моделирование поведения целевой системы. 1. Теория систем Часть 2

• Моделирование поведения целевой системы. 2. Поведенческие диаграммы UML

• Моделирование поведения целевой системы. 3. Моделирование процессов управления

• Формирование спецификаций требований на создание целевой ИС

• Управление изменениями требований и организация эффективного взаимодействия в команде производства ИТ продукта

• Организация процессов проектирования в производстве ИТ-продукта

2.    Моделирование поведения

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

Основные виды моделирования поведения:

1)  Диаграммы поведения в UML

• Диаграмма активности (activity diagram). Отражает последовательность действий, условий и ветвлений. Мы этот тип диаграмм рассматривали на этапе описания бизнес-процессов.

• Диаграмма состояний (state diagram) Показывает, как система или объект переходит из одного состояния в другое в ответ на события.

• Диаграмма последовательности (sequence diagram). Иллюстрирует взаимодействие объектов по времени (кто кому и когда что отправляет).

2)  Имитационное моделирование

• Поведение системы симулируется во времени с учетом случайных факторов (например, нагрузка на сервер, движение транспорта). Используются инструменты: AnyLogic, Arena, Simulink, MATLAB и др.

3)  Агентное моделирование

• Поведение описывается через взаимодействие агентов (например, пользователей, машин, роботов). Каждый агент действует по собственным правилам — в совокупности формируется общее поведение системы.

4)  Системная динамика

• Отражает поведение систем с обратными связями и накоплением ресурсов. Используются диаграммы потоков и накопителей (stock & flow diagrams).

3.    Диаграмма состояний (UML)

Для реализации требований событийно управляемых систем, необходимо определять и управлять состояниями объектов (совокупностью свойств в конкретный момент времени), при возникновении некоторых событий. В этом случае на помощь приходит паттерн «Состояние», который мы рассматривали при проектировании хранилищ.

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

Введем определения, которыми будем оперировать в ходе рассмотрения данного раздела

Диаграммы состояний в UML являются реализацией идеи использования представления конечных автоматов (State machine view), как средства описания алгоритмов и, тем самым, моделирования поведения.

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

На диаграммах используются следующие элементы:

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

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

    Событие перехода — это тот входной стимул, который вкупе с текущим состоянием автомата определяет следующее состояние.

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

На одной диаграмме используется только один класс, каждое состояние которого и отображается в виде прямоугольника.

На одной диаграмме используется только один класс, каждое состояние которого и отображается в виде прямоугольника.

В свою очередь Переходы бывают простые и составные, и каждый переход содержит от двух до пяти составляющих:

• Исходное состояние (source),

• Событие перехода (trigger event),

• Сторожевое условие (guard),

• Действие на переходе (effect),

• Целевое состояние (target).

Рисунок выше отображает пример перехода состояния. Исходное состояние - «На рассмотрении». «Рассмотрена» - событие перехода, означает выполнение действия перехода (экземпляр Заявки был рассмотрен). «[Есть экземпляр в наличие]» - сторожевое условие, определяющее условие, при котором событие приведет к следующему (целевому) состоянию. «Отправить сообщение заявителю» - действие на переходе, выполняется во время перехода из состояния в состояние. «Отказана» - целевое состояние, в которое выполнен переход.

Например, после создания новой Заявки, она находится в состоянии «Черновик». Смотри Рисунок ниже. При выполнении операции отправки заявки на рассмотрение, ее состояние меняется на «На рассмотрении». Это может означать, что в этом состоянии заявка доступна только пользователю с ролью Библиотекарь, при этом она появляется в его АРМ в списках заявок, которые необходимо рассмотреть и тому подобное.

При рассмотрении заявки Библиотекарь может определить есть экземпляр книги для выдачи на руки читателю или нет. Поэтому из состояния «На рассмотрении» есть два перехода отмеченные сторожевым условие «Нет экземпляра в наличие» или «Есть экземпляра в наличие». В зависимости от этого происходит переход к следующему состоянию «Предложена» или «Отказана». При этом переход в состояние «Отказана» сопровождается Действием при переходе «Отправить сообщение заявителю».

Таким образом на диаграмме отображаются все возможные состояния жизненного цикла объекта Заявка и соответствующие переходы между ними.

При нахождении в определенном состоянии для объекта также доступны Действия (Action/Activity), определяющие, что происходит внутри состояния (например, "ожидание ответа", "обработка данных").

В рамках состояния доступны следующие основные виды действий:

• Entry / onEntry – выполняется одноразово при входе в состояние.

• Do – выполняется непрерывно, пока объект находится в состоянии (может прерваться событием).

• Exit / onExit – выполняется одноразово при выходе из состояния.

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

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

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

Такие таблицы читаются слева направо сверху вниз. В первой колонке указывается событие, которое и вызывает реакцию системы. В следующей колонке начальное (рассматриваемое) состояние, в зависимости от которого и условия перехода, указанного в следующей колонке, должен осуществляться перевод объекта в новое - целевое состояние.

4.    Диаграмма последовательностей.

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

В результате может быть получен ответ или инициированы следующие процессы. Таким образом удобно формализовать низкоуровневые функции системы.

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

Основные элементы диаграмм данного типа:

Действующее лицо (actor) — сущность, находящаяся вне моделируемой системы и непосредственно взаимодействующая с ней.

Объекты располагаются в верхней части диаграммы друг за другом. Вниз от каждого объекта тянется пунктирная линия, которую называют линией жизни объекта.

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

Линия жизни объекта — это линия, которая изображает существование объекта на протяжении некоторого промежутка времени, и чем длиннее линия, тем дольше существует объект.  Таким образом Линии жизни объектов, играют роль шкалы времени. Смотри Рисунок ниже.

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

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

В UML различают следующие виды сообщений:

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

• асинхронное сообщение: Клиент посылает сообщение серверу и, не дожидаясь ответа, продолжает выполнять следующие операции;

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

Также не часто, но использоваться: 

потерянное сообщение (lost) – сообщение, не имеющее адресата сообщения, т.е. для него существует событие передачи и отсутствует событие приема

найденное сообщение (found) – сообщение, не имеющее инициатора сообщения, т.е. для него существует событие приема и отсутствует событие передачи

Каждое сообщение должно иметь представление по одному из следующих вариантов:

1)    произвольная строка текста. Применяется на начальных стадиях проектирования или концептуальных диаграммах;

2)    указание стереотипа для некоторых стандартных действий:

• «create» (создать) – возвращающее сообщение, требующее создания объекта;

• «destroy» (уничтожить) – синхронное сообщение с требованием уничтожить соответствующий объект;

• «call» (вызвать) – синхронное сообщение, требующее выполнения операции принимающего объекта;

• «send» (послать) – асинхронное сообщение, обозначающее посылку сигнала серверу;

• «return» (возвратить) или «reply» (ответить)– возвращающее сообщение;

Указание спецификации вызываемого метода объекта-получателя в формате: [переменная =] имя([список параметров]) [:возвращаемое значение].

Где:

• Переменная - переменная или атрибут объекта-отправителя, которому будет присвоен результат вызываемого метода.

• Имя сообщения (обязательный параметр) – имя вызываемого метода объекта-получателя.

• Список аргументов – список аргументов, разделенных запятыми и передаваемых для выполнения метода.

• Возвращаемое значение – константа или имя переменной, являющиеся результатом вызываемого метода.

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

Метка Фрейма. UML может содержать следующие операнды:

• ·Alt -  Несколько альтернативных фрагментов; выполняется только тот фрагмент, условие которого истинно;

• Opt - Необязательный опциональный фрагмент; выполняется, только если условие истинно. Эквивалентно alt с одной веткой;

• Par - Параллельный; все фрагменты выполняются параллельно;

• loop - Цикл; фрагмент может выполняться несколько раз, а область обозначает тело итерации;

• ref - Ссылка; ссылается на взаимодействие, определенное на другой диаграмме. Фрейм рисуется, чтобы охватить линии жизни, вовлеченные во взаимодействие. Можно определять параметры и возвращать значение;

• Sd - Диаграмма последовательности; используется для очерчивания всей диаграммы последовательности, если это необходимо;

• region - Критическая область; фрагмент может иметь только один поток, выполняющийся за один прием, аналог транзакции;

• Neg - Отрицательный фрагмент; обозначает неверное взаимодействие.

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

Например, читатель, инициирует сигнал-сообщение на создание заявки. В качестве параметра передает Данные о книге. На основании этого сообщения в системе создается Заявка. Обратите внимание, объект Заявка на оси времени появляется только в результате реакции на сообщение. Заявка становится доступной Читателю. Он, проверив ее, может опубликовать ее черновик в системе. Опубликованный черновик заявки становится доступным для Библиотекаря. Библиотекарь в свою очередь может зарегистрировать заявку и выполнить поиск доступного экземпляра книги. Далее выполняется один из фреймов в зависимости от того есть в наличие книга или нет.

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

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

В следующей части мы рассмотрим поведенческие модели при моделировании процессов управления.