Разработка корпоративной информационной системы на основе объектно-ориентированного подхода (стр. 4 из 11)

Событие происходит в некоторый момент времени (нередко оно используется для определения соответствующего момента времени).

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

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

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

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

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

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

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

Диаграмма состояний связывает события и состояния. Смена состояния называется переходом.

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

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

Активностью называется операция, связанная с каким-либо состоянием объекта (она выполняется, когда объект попадает в указанное состояние); выполнение активности требует определенного времени. Активность связана с состоянием, поэтому на диаграмме состояний она обозначается через «do: имя_активности» в узле, описывающем соответствующее состояние (рис.1.9).

Рисунок 1.9 - Указание активностей и действий на диаграмме состояний

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

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

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

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

Рисунок 1.10. - Передача события из одного объекта другому

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

Синхронизация используется и в случае, когда в каком-либо состоянии требуется параллельно выполнить несколько активностей. Рассмотрим устройство вывода БМ (рисунок 1.11). Оно одновременно (параллельно) выдает наличные деньги и карточку; обе эти операции можно рассматривать как составную активность, состоящую из двух параллельно работающих активностей (пунктирная линия на диаграмме состояний делит состояние на две области, в каждой из которых выполняется одна из указанных активностей). Разделение управления на два параллельных потока схематически показано в виде стрелки, которая разделяется на две: событие «готов» вызывает переход из состояния «установка» сразу в два параллельных под состояния: состояния «выдача» и «выбросить»; переход в следующее состояние происходит по двум событиям «деньги взяты» и «карточка взята»; если какое-либо из этих событий произойдет раньше другого, перехода все равно не будет, пока не произойдет и второе событие (в этом и состоит синхронизация). Из рассмотренного примера видно, что в различных состояниях может параллельно работать разное число процессов (активностей).

Рисунок 1.11 - Синхронизация в подсистеме

Построим динамическую модель банковской сети. Начальный сценарий:

БМ просит клиента вставить карточку клиент вставляет карточку

БМ принимает карточку и читает ее номер

БМ просит ввести пароль клиент вводит "1234"

БМ передает номер и пароль в консорциум, консорциум проверяет номер и пароль, определяет код банка - "39" и сообщает БМ, что запрос принят

БМ просит клиента (с помощью меню на экране) выбрать вид проводки(снятие, вклад, перевод, запрос) клиент выбирает снятие

БМ спрашивает клиента какова требуемая сумма клиент вводит $100

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

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

БМ спрашивает, не нужно ли клиенту чего еще клиент вводит нет

БМ печатает счет, выдает карточку и просит клиента взять их клиент берет счет и карточку

БМ просит (другого) клиента ввести карточку.

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

БМ просит клиента вставить карточку, клиент вставляет карточку

БМ принимает карточку и читает ее номер

БМ просит ввести пароль, клиент вводит "9999."

БМ передает номер и пароль в консорциум; консорциум, проконсультировавшись с соответствующим банком, отвергает запрос

БМ сообщает, что пароль введен неверно, клиент вводит "1234."

БМ передает номер и пароль в консорциум, консорциум проверяет номер и пароль, определяет код банка - "39" и сообщает БМ, что запрос принят

БМ просит выбрать вид проводки, клиент выбирает снятие

БМ спрашивает, какова требуемая сумма клиент (раздумав брать деньги) набирает отмену

БМ выдает карточку и просит клиента взять ее клиент берет карточку

БМ просит (другого) клиента вставить карточку.

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

Имея трассы событий, можно построить диаграммы состояний объектов проектируемой системы. Банковская сеть есть агрегация определенного числа параллельно и независимо работающих объектов четырех классов: консорциум, банк, БМ (банкомат) и клиент; поэтому состояние банковской сети определяется как кортеж состояний составляющих ее объектов: 1 объекта класса консорциум, b объектов класса банк, a объектов класса БМ (банкомат) и c объектов класса клиент (a, b, c - количество БМ, банков и клиентов сети соответственно). Классификация объектов, используемая при объектно-ориентированном подходе, позволяет вместо a+b+1 диаграмм состояний построить всего три (диаграммы состояний клиентов строить не нужно, так как их текущее состояние ясно и так).

Построение диаграмм состояний начинается с привязки событий к объектам банковской сети (рисунок 1.13), являющимся источниками этих событий. Сначала рассматриваются нормальные события, потом исключительные события. Построение диаграммы состояний объекта (класса) может считаться законченным, когда диаграмма охватывает все рассматриваемые сценарии. Диаграммы состояний объектов классов БМ (рисунок 1.14), консорциум (рисунок 1.15) и банк (рисунок 1.16).