Файл: ТРПО-лекции.pdf

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения 33

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

Входное действие (Entry action) – непрерываемое действие, которое выполняется при переходе объекта в данное состояние. Например, при переходе в состояние За-

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

Деятельность (Activity) – реализуемое объектом действие, когда он находится в данном состоянии.

Выходное действие (Exit action) – осуществляется как составная часть процесса выхода объекта из данного состояния.

От одного состояния объекта к последующему состоянию проводится переход. Переход (Transition) – это перемещение из одного состояния в другое.

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

При переходе из первого состояния во второе объект выполняет некоторое дейст-

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

Событие (Event) – это то, что вызывает переход из одного состояния в другое.

Действие (Action) – это атомарное вычисление, которое приводит к смене состояния или возврату значения.

Ограждающее условие (Guard conditions) определяет, когда переход может быть выполнен, а когда нет.

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

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

1.Отсутствие конфликтующих переходов. Элемент не может одновременно пе-

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

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

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

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения 34

цифицировано явным образом (исключением являются начальное и конечное состояния).

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

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

1.2. Общие механизмы UML

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

−Спецификации.

−Способы представления.

−Дополнения.

−Расширения.

1.2.1. Спецификации

Спецификация (Specification, Definition) – декларативное описание того, чем является или для чего служит некоторая сущность.

Составление спецификации обязательно для каждого элемента (сущностей, отношений, диаграмм) модели. Набор спецификаций формирует семантический задний план (semantic backplane) модели, который наполняет еѐ смыслом. Модель считается полной и полезной только в том случае, когда семантика присутствует в спецификациях. Спецификации используются для составления документации к проекту и программной системе, потому что содержат для этого все необходимые сведения. Инструментальные средства UML-моделирования поддерживают доступ, просмотр и изменение спецификации любого элемента модели.

1.2.2. Способы представления

В UML существует два способа представления: классификатор – экземпляр и интерфейс – реализация.

Классификатор (classifier) – дискретная концепция UML-модели, которая представляет собой абстракцию, и находится в определѐнных отношениях с другими элементами модели. Основными видами классификаторов являются: классы, интерфейсы и типы данных.

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

Основная идея понятия интерфейс – реализация заключается в отделении действий (интерфейс) от того, как они выполняются (реализация).

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения 35

Интерфейс (interface) – именованное множество открытых операций, которые описывают поведение класса или компонента и определяют контракт для конкретных реализаций. В целом, интерфейс соответствует абстрактному классу, где определены только абстрактные операции.

Реализация (realization) – это указание на то, что программная реализация элемента модели наследует определѐнный интерфейс. Реализующий элемент должен поддерживать все имеющиеся в интерфейсе операции. На рис. 1-35 показан пример графического представления понятия интерфейс – реализация.

Рис. 1-35. Пример представления понятия интерфейс –

реализация

1.2.3. Дополнения

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

На рис. 1-36 показан один и тот же класс COrder без дополнений и с дополнениями.

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Рис. 1-36. Класс без допол-

полнений и с дополнениями

1.2.4. Расширения

Расширения предназначены для использования в процессе создания программного обеспечения, чтобы удовлетворить новые требования разработчиков к представлению моделей. К расширениям относятся: ограничения, стереотипы и именованные значения.

Ограничение (constraint) – это текстовое указание на семантическое ограничение для элемента модели, которое должно оставаться истинным. На рис. 1-37 показан пример графического изображения ограничения.

Рис. 1-37. Пример ограничения

Стереотип (stereotype) представляет категорию элемента модели. В UML определены некоторые стандартные стереотипы. Например, стандартными стереотипами для классов являются: <<boundary>> (пограничный класс), <<control>> (класс

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения 37

управления), <<entity>> (класс сущностей). Стандартные стереотипы поддерживаются специальными графическими обозначениями (рис. 1-38). UML позволяет создавать собственные стереотипы для проектируемой системы. В таком случае следует определить семантику новых стереотипов, используя примечания (notes).

Рис. 1-38. Графическое изображение стан-

Пограничные классы расположены на границе системы. К ним относятся экранные формы, отчѐты, интерфейсы с аппаратурой (с принтерами, сканерами, датчиками) и с другими системами. Чтобы выявить пограничные классы, необходимо исследовать диаграмму прецедентов. Для каждого взаимодействия между актѐром и прецедентом должен существовать хотя бы один пограничный класс. Необязательно создавать уникальные пограничные классы для каждой пары актѐр – прецедент. Если актѐры инициируют один и тот же use case, то они могут применять общий класс.

Классы управления отвечают за координацию действий других классов. Этот класс

не несѐт в себе никакой функциональности, он делегирует ответственность дру-

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

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

Именованное значение (tagged values) представляет собой ключевое слово, к которому прикреплено значение. Именованные значения позволяют добавлять собственные свойства к элементу модели.

1.3. Архитектура

Архитектура описывает высокоуровневую структуру системы. Унифицированный процесс RUP (Rational Unified Process) использует модель представления архитек-

туры "4 + 1" (рис. 1-39).

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Рис. 1-39.

Архитектура системы в RUP

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

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

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

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

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

Архитектура – это описание структуры программного средства.

При проектировании архитектуры определяют подсистемы, а также управление подсистемами и их взаимодействие. Для создания архитектуры выполняются следующие шаги:

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения

1.Структурирование системы. ПС структурируется в виде совокупности39 сительно независимых подсистем и определяется их взаимодействие. Обмен данными между подсистемами можно организовать двумя способами:

−Все совместно используемые данные хранятся в центральной базе данных, доступной всем подсистемам. Эту модель называют моделью репозитория.

−Каждая подсистема может иметь собственную базу данных. Взаимообмен данными происходит посредством передачи сообщений.

2.Моделирование управления. Разрабатывается базовая модель управления взаимоотношениями между частями системы. Можно выделить два основных типа управления программных систем:

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

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

−Управление, основанное на событиях. Здесь на внешние события может отве-

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

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

Чѐткого различия между подсистемами и модулями нет. Как правило, модуль никогда не рассматривается как независимая компонента. Приняты такие определения:

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

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011