Заключение

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

• диаграмма прецедентов,

• диаграмма последовательности (и/или кооперации),

• диаграмма классов и

• диаграмма компонентов.

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

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

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

Следует отметить, что возможность создавать заготовки с готовым программным кодом системы является удобным дополнительным сервисом в среде Ration Rose, но получаемые заготовки не являются основной целью проектирования на базе языка UML. Основная цель - построить адекватную (предметной области и поставленным задачам) модель системы, которая будет понятной всем участникам процесса разработки. Использовать или не использовать кодогенерацию перед этапом реализации построенного проекта зависит от предпочтений программистов и других разработчиков.

Актёр (Actor)

некоторая сущность, которая взаимодействует с системой извне.

Актёром может быть программа, человек, другая система, но главное,

чтобы разработчик определил эту сущность как источник воздействия (влияния)

на систему.

Новые термины

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

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

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

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

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

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

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

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

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

Стереотипы

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

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

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

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

Объект - экземпляр, представитель класса.

Сообщение (message) представляет собой фрагмент информации, который отправляется одним объектом другому (направленная информация).

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