Компоненты

Классы и типы для диаграммы состояний

Диаграммы состояний для вариантов использования

Правила построения диаграммы состояний

При создании диаграммы состояния необходимо учитывать следующие обязательные условия:

1. Отсутствие конфликтующих переходов. Элемент не может одновременно переходить в два и более последующих состояний. Для разрешения конфликта следует пользоваться ограждающими условиями.

2. Отсутствие изолированных состояний и переходов. Каждый переход должен соединять два состояния (исключением являются начальное и конечное). Разрешаются рефлексивные переходы.

3. Конечное количество состояний. По определению диаграмма состояний представляет конечный автомат. Каждое состояние на диаграмме должно быть специфицировано явным образом (исключением являются начальное и конечное состояния).

4. Индивидуальность состояния. В каждом состоянии объект должен вести себя по-разному.

5. Определённость состояния. В каждый момент времени элемент может находиться только в единственном состоянии. Если это не так, то это или ошибка, или признак наличия параллельности поведения.

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

Кроме перечисленных условий следует помнить о двух аспектах:

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

2. Если для системы важно, какое время элемент должен или может находиться в данном состоянии, то на диаграмме можно указать это время в явном виде. Каждое состояние должно характеризоваться определённой устойчивостью во времени. Если время ничтожно, то это ошибка выделения состояния.

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

Диаграмма состояний для прецедента (use case) описывает допустимую последовательность внешних событий, которые система распознаёт и обрабатывает в рамках прецедента.

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

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

Диаграмма состояний для прецедента Покупка товара системы POST:

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

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

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

1. Управляющие классы. Объекты этих классов отвечают за последовательность обработки системных событий.

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

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

4. Окна пользовательского интерфейса. При проектировании интерфейса пользователя полезно строить диаграммы состояний как для отдельных окон, так и для общего интерфейса.

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

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

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

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

2.11 ДИАГРАММЫ КОМПОНЕНТОВ – COMPONENT DIAGRAMS

До сих пор рассматривались диаграммы, имеющие отношение к концептуальному и логическому уровню представления системы.

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

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

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

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

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

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

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

Компонент:

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

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

Материальная сущность компонентов реализации – совокупность битов.

Многие операционные системы и языки программирования непосредственно поддерживают понятие компонента. Например, объектные библиотеки, исполняемые файлы, COM++ -объекты. При помощи UML можно определять в виде компонент реляционные таблицы, документы.

У каждого компонента должно быть уникальное имя. Как правило, к имени добавляют расширения имён файлов реализации в зависимости от выбранной операционной системы и языка программирования (Например, EXE, DLL, APPLET).

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

Услуги компонента доступны только через его интерфейсы. Интерфейсы всегда присутствуют у компонентных средств операционных систем (например, COM++, CORBA, JAVA), которые используют интерфейсы для “склеивания” отдельных компонентов.

Дата добавления: 2014-01-07