Основные теоретические сведения

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

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

Классы характеризуются атрибутами (свойствами) и операциями, определяющими поведение класса. Реализация операции класса называется в UML методом класса.

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

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

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

Наследование - принцип, в соответствии с которым родительский класс (предок) передает все свои наборы свойств и поведение дочерним классам (потомкам). Дочерние классы называются производными классами (рис.1), они добавляют к наследуемым свои специфические свойства и операции.

Рис.1. Иерархия классов, полученная операцией обобщения

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

Использование объектов заранее подготовленных библиотечных классов с определёнными свойствами и методами позволило решить многие кризисные вопросы создания программного и информационного обеспечения сложных АС.

Процесс создания системы носит итеративный и инкрементный характер. Это же подчеркивают авторы UML, определяя понятие унифицированного процесса разработки программного и информационного обеспечения [ ]. Хотя на первой стадии формируется набор требований к АС в целом, на самом деле он всегда в начале неполон и уточняется на последующих стадиях. Приходится делать итерации, то есть повторять отдельные этапы и стадии, либо целиком, либо частично. Кроме того, реальная система многофункциональна и сложна, поэтому обычно ее разбивают на подсистемы и отдельные комплексы задач, выделяя в них подсистемы и задачи первой очереди, второй и т.д. Система создается инкрементно, путем постепенных приращений функциональности с заменой предварительных проектных решений на более проработанные и лучше отвечающие требованиям пользователей. Это снижает финансовые риски и экономит время и расход ресурсов на последних стадиях создания.

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

· модель вариантов использования;

· модель анализа ;

· модель проектирования;

· модель реализации;

· модель развертывания;

· модель тестирования.

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

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

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

Модель реализации описывает, как реализуются в виде компонентов классы проектирования. Соответственно она включает диаграммы компонентов, трассировки (реализации) классов, описание архитектуры системы.

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

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

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

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

В языке имеется 4 вида графических конструкций:

· значки (пиктограммы);

· графические символы на плоскости;

· пути (линии);

· строки текста.

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

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

· определить общие границы и контекст моделируемой предметной области;

· сформировать общие требования к функциональному поведению и интерфейсу системы;

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

Точка зрения модели: внешний пользователь системы. В диаграмму вариантов использования входят актанты (actors), варианты использования (use case) и ассоциации (association).

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

Каждая роль требует для себя вполне определенного сервиса (обслуживания).

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

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

1. Символ класса (прямоугольник) с внутренним указанием стереотипа

	<actor> Заказчик

2. Более стандартно: “человек” с надписью (символ человека)

Актант находится вне системы и его внутренняя структура не определяется. Он является источником/приемником сообщений.

Заказчик

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

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

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

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

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

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

1) эллипсом, внутри ставится имя

2) прямоугольником - как и любой класс

	<use case> Принять заказ

Ассоциация показывается линией:

Заказчик

Датчик

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

Клиент банка

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

Имя ассоциации, если оно есть, должно быть уникальным.

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

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

Направление стрелки имеет смысл: вариант “Запросить каталог” знает, в какие точки расширения варианта “Принять заказ” он включается (он может включаться неоднократно). Для правильного определения направления стрелки следует задать вопрос по данному варианту: «Расширяет что?». Каждая точка расширения имеет уникальное имя в рамках варианта “Принять заказ”. Имена точек расширения можно указать в специальном разделе в обозначении варианта использования.