Дополнительные обозначения языка UML для бизнес-моделирования.

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

Бизнес-актер (business actor) – индивидуум, группа, организация, компания или система, которые взаимодействуют с моделируемой бизнес-системой, но не входят в нее, т.е. не являются частью моделируемой системы.

Графическое изображение бизнес-актера приводится на рис. 10 а. Примерами бизнес-актеров являются клиенты, покупатели, поставщики, партнеры. Общее свойство бизнес-актеров состоит в том, что они являются инициаторами или клиентами бизнес-процессов моделируемой системы.

Сотрудник(business worker) – индивидуум, который действует внутри моделируемой бизнес-системы, взаимодействует с другими сотрудниками и является участником бизнес-процесса моделируемой системы.

Графическое изображение сотрудника приводится на рис. 10 б. Примерами сотрудников являются менеджеры, администраторы, кассиры, инженеры. Общее свойство сотрудников заключается в том то, что они являются субъектами и входят в состав моделируемой системы.

Бизнес-вариант использования (business use case) – вариант использования, определяющий последовательность действий моделируемой системы, направленных на выполнение отдельного бизнес-процесса.

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

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

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

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

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

Дальнейшая детализация данной модели может быть выполнена на основе установления дополнительных отношений, в частности отношения "обобщение-специализация" для уже имеющихся компонентов диаграммы вариантов использования. Так, в рамках рассматриваемой системы продажи товаров может иметь самостоятельное значение и специфические особенности отдельная категория товаров — телевизоры. В этом случае диаграмма дополняется вариантом использования "Оформление заказа на покупку телевизора", который связан с сервисом "Оформление заказа на покупку товара" отношением обобщения.

Полученная в результате диаграмма вариантов использования будет содержать 5 бизнес-вариантов использования, одного бизнес-актера и одного сотрудника, между которыми установлены соответствующие отношения включения, расширения и обобщения. Эта диаграмма, изображенная в общих обозначениях нотации языка UML, представлена на рис. 11.

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

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

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

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

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

Прецеденты полезны и для прямого, и для обратного проектирования. При прямом проектировании мы, по сути, осуществляем "перевод" с UML на некий язык программирования. И тестировать созданное приложение следует, основываясь именно на потоках событий, описываемых прецедентами. Обратное проектирование предполагает перевод с языка программирования на язык UML-диаграмм. Такими вещами приходится заниматься в силу ряда причин:

·С целью поиска ошибок и чтобы убедиться в адекватности дизайна:

отличная идея после первого перевода с UML на язык программирования сделать обратный перевод и сравнить исходные и восстановленные UML-модели (желательно, чтобы эти переводы выполнялись разными командами). Это позволит убедиться в том, что дизайн системы соответствует модели, никакая информация в ходе перевода не была утеряна, да и попросту выловить некоторые "баги". Такой подход называется обратной семантической трассировкой (или RST - Reverse Semantic Traceability) и разрабатывается компанией INTSPEI (http://www.intspei.com) как одна из базовых техник методологии INTSPEI P-Modeling Framework.

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

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

Лекция 8

ТЕМА: UML. Спецификация требований и написание эффективных вариантов использования.

Литература: 1. Леоненков А. В. Самоучитель UML. - 2-е изд.

2. Бабич А. Введение в UML. //курс НОУ «ИНТУИТ».

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

Требование - это когда заказчик описывает нам, чего же именно он хочет. Это могут быть фразы типа "хотелось бы, чтобы проверка обновлений проводилась автоматически, как в антивирусах", "хочу большую зеленую кнопку в центре окна, которая начинает процесс", "программа должна позволять просматривать и печатать отчеты", "и чтоб красивенько все было, с полупрозрачностями, как в Висте", "при выходе должно выводиться подтверждение" и т. д. и т. п. Конечно, как настоящие разработчики, мы понимаем и то, что заказчик никогда не знает, что именно ему нужно, а если понимает, то объяснить не может. Но ведь фразы-то всегда, по сути, одинаковы! Они описывают, как заказчик представляет себе систему, чего заказчик хочет от системы, функциональность, которой он от нее ожидает, требования, которые к ней предъявляет.

Определение 1. Требование (requirement) - желательное свойство, характеристика или условие, которым должна удовлетворять система в процессе своей эксплуатации.

Именно со сбора требований начинается процесс разработки ПО.

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

·функциональные требования (Functionality)

·требования удобства использования (Usability)

·требования надежности (Reliability)

·требования производительности (Performance)

·требования возможности сопровождения (Supportability)

При этом символом "+" обозначены дополнительные условия, к которым относятся:

·проектные ограничения

·требования управления системой

·требования к графическому интерфейсу пользователя

·физические требования

·юридические требования

Требования к создаваемой системе раньше описывались в техническом задании. Документ это был большой, многостраничный, с четкой структурой, определяемой ГОСТами (государственными отраслевыми стандартами). Но время шло, менялись стандарты, нотации, способы описания требований. И вот постепенно техническое задание уступило место набору артефактов, состоящему из документов двух видов:

·диаграммы прецедентов;

·нефункциональные требования.

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

Нефункциональные требования - это описание таких свойств системы, как особенности среды и реализации, производительность, расширяемость, надежность и т. д. Часто нефункциональные требования не привязаны к конкретному варианту использования и потому выносятся в отдельный список дополнительных требований к системе.

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

·четко разграничить систему и ее окружение;

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

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

Подобный вид деятельности обычно выполняется в такой последовательности:

1. Определение действующих лиц.

2. Определение прецедентов.

3. Составление описания каждого прецедента.

4. Описание модели прецедентов в целом (этот этап включает в себя создание словаря предметной области).

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

Определение 2. Сценарий (scenario) - определенная последовательность действий, которая описывает действия актеров и поведение моделируемой системы в форме обычного текста.

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

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

Вот пример простого (неформализованного) текстового описания сценария регистрации пользователя на некотором сайте:

Пользователь вводит логин, пароль, адрес электронной почты и нажимает кнопку "Далее". Система запрашивает ввод проверочного кода. Пользователь вводит код и нажимает кнопку "Далее". Система проверяет соответствие кода изображенному на картинке.

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

А вот тот же сценарий в табличном представлении (табл.1):

Таблица 1.

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

Одним из вариантов написания сценариев может быть использование шаблона, представленного в таблице 2.

Таблица 2. Шаблон для написания сценария отдельного варианта использования

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

(а) (б)

Рис. 1. Размещение сценариев на диаграмме прецедентов.

Рассмотрим, как связаны понятия сценария и прецедента. Прецеденты, как мы уже говорили, рождаются из требований к системе. Но говорят они о том, что делает система. Как система это делает, говорят сценарии. Таким образом, сценарии специфицируют прецеденты. Взаимосвязь между требованиями, прецедентами и сценариями можно изобразить такой "псевдодиаграммой" (рис. 2).

Рис. 2.

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

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

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

Примечание. Спецификация требований к проектируемой системе в форме диаграммы вариантов использования и дополнительных сценариев может представлять собой самостоятельную модель, которая в языке UML получила название модели вариантов использования и имеет свое специальное стандартное имя или стереотип <<useCaseModel>>. Все заданные в этой модели требования допустимо представить в виде общей модели системы, которая может быть оформлена как отдельный пакет Система. Этот пакет в свою очередь может представлять собой иерархию пакетов, на самом верхнем уровне которых содержится множество классов, реализующих базовые варианты использования проектируемой системы. При этом пакет системы самого верхнего уровня может быть дополнительно помечен стереотипом <<topLevelPackage>>.

Рекомендации по разработке диаграмм вариантов использования.

Как было отмечено ранее, одно из главных назначений диаграммы вариантов использования заключается в формализации функциональных требований к системе. Диаграмма вариантов использования может служить основой для согласования с заказчиком функциональных требований к системе на ранней стадии проектирования. Любой из базовых вариантов использования в последующем может быть подвергнут декомпозиции на частные варианты использования. При этом рекомендуется, чтобы общее количество актеров в модели не превышало 20, а вариантов использования - 50. В противном случае модель теряет свою наглядность и, возможно, заменяет собой одну из некоторых других диаграмм.

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

·Определить главные или первичные и второстепенные актеры.

·Определить цели главных актеров по отношению к системе.

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

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

·Рассмотреть все базовые варианты использования в порядке убывания их степени риска.

·Выделить участников, интересы, предусловия и постусловия выполнения выбранного варианта использования.

·Написать успешный сценарий реализации выбранного варианта использования.

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

·Написать сценарии для всех исключений.

·Выделить общие варианты использования и изобразить их взаимосвязи с базовыми со стереотипом <<include>>.

·Выделить варианты использования для исключений и изобразить их взаимосвязи с базовыми со стереотипом <<extend>>.

·Проверить диаграмму на отсутствие дублирования вариантов использования и актеров.

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

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

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

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

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

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

Рис. 3. Диаграмма вариантов использования для модели банкомата.

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

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

Таблица 3. Главный раздел сценария выполнения варианта использования "Снятие наличных по кредитной карточке".

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

Таблица 4. Раздел «Типичный ход событий» сценария выполнения варианта использования "Снятие наличных по кредитной карточке".

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

Таблица 5. Раздел «Исключения» сценария выполнения варианта использования "Снятие наличных по кредитной карточке".

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

Лекция 9

ТЕМА: UML. Построение диаграммы классов.

Литература: 1. Леоненков А. В. Самоучитель UML. - 2-е изд.

2. Бабич А. Введение в UML. //курс НОУ «ИНТУИТ».

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

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

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

Определение 1. Класс (class) - абстрактное описание множества однородных объектов, имеющих одинаковые атрибуты, операции и отношения с объектами других классов.

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

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

Рис. 1. Варианты графического изображения класса на диаграмме классов.

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

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

Имя класса.

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

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

Если необходимо явно указать, к какому пакету относится тот или иной класс, то используется специальный символ-разделитель – двойное двоеточие. Синтаксис строки имени класса в этом случае будет следующий: <Имя пакета>::< Имя класса >. Например, если определен пакет с именем Банк, то класс Счет в этом банке может быть записан в виде: Банк::Счет (рис. 3).

Рис. 3. Составное имя класса.

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

Класс может иметь или не иметь экземпляров или объектов. В зависимости от этого в языке UML различают конкретные и абстрактные классы.

Определение 2. Конкретный класс (concrete class) - класс, на основе которого могут быть непосредственно созданы экземпляры или объекты.

Рассмотренные выше обозначения относятся к конкретным классам.

Определение 3. Абстрактный класс (abstract class) - класс, который не имеет экземпляров или объектов.

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

Атрибуты класса.

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

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

В языке UML принята определенная стандартизация записи атрибутов класса, которая подчиняется некоторым синтаксическим правилам. Каждому атрибуту класса соответствует отдельная строка текста, которая состоит из:

· квантора видимости атрибута;

· имени атрибута;

· его кратности;

· типа значений атрибута;

· возможно, его исходного значения.

Общий формат записи отдельного атрибута класса следующий:

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

Примеры:

фамилия – указано только имя атрибута;

+фамилия – имя и видимость;

фамилия : String – имя и тип значений атрибута;

товаровВКорзине [0..*] : Integer – имя, кратность и тип;

-ID [1] : String {=frozen} – видимость, имя, кратность, тип и свойство;

товаровВКорзине : Integer = 0 – имя и начальное значение.

Опишем спецификации атрибутов подробно.

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

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

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

·Символ "+" – обозначает атрибут с областью видимости типа общедоступный (public). Атрибут с этой областью видимости доступен или виден из любого другого класса пакета, в котором определена диаграмма.

·Символ "#" – обозначает атрибут с областью видимости типа защищенный (protected). Атрибут с этой областью видимости недоступен или не виден для всех классов, за исключением подклассов (потомков) данного класса.

·Символ "-" – обозначает атрибут с областью видимости типа закрытый (private). Атрибут с этой областью видимости недоступен или не виден для всех классов без исключения.

·Символ "~" - обозначает атрибут с областью видимости типа пакетный (package). Атрибут с этой областью видимости недоступен или не виден для всех классов за пределами пакета, в котором определен класс-владелец данного атрибута.

Квантор видимости может быть опущен. Его отсутствие означает, что видимость атрибута не указывается. Эта ситуация отличается от принятых по умолчанию соглашений в традиционных языках программирования, когда отсутствие квантора видимости трактуется как public или private. Однако вместо условных графических обозначений можно записывать соответствующее ключевое слово: public, protected, private, package.

Определение 6. Кратность (multiplicity) - спецификация области значений допустимой мощности, которой могут обладать соответствующие множества.

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

Значение кратности записывается в квадратных скобках, в которых указывается возможный диапазон кратности атрибута: [нижняя граница .. верхняя граница], где нижняя и верхняя границы положительные целые числа. В качестве верхней границы может использоваться специальный символ «*» (звездочка), который означает произвольное положительное целое число, т.е. неограниченное сверху значение кратности соответствующего атрибута.

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

Если в качестве кратности указывается единственное число, то кратность атрибута принимается равной данному числу.

Примеры записи кратности атрибута:

0..1 - ноль или один;

1 или 1..1 - ровно один;

2..* - два или больше;

2..5 - 2,3,4 или 5;

1..3,5,8..10 - 1,2,3,5,8,9или 10;

* - любое положительное число или ноль.

В языке UML кратность широко используется также для задания ролей ассоциаций, составных объектов и значений атрибутов. Если кратность атрибута не указана, то по умолчанию в языке UML принимается ее значение равное [1..1], т.е. в точности 1.

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

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

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

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

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

Знак " / " перед именем атрибута указывает на то, что данный атрибут является производным от некоторого другого атрибута этого же класса.

Определение 7. Производный атрибут (derived element) - атрибут класса, значение которого для отдельных объектов может быть вычислено посредством значений других атрибутов этого же объекта.

Операции класса.

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

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

· квантора видимости операции;

· имени операции;

· выражения типа возвращаемого операцией значения;

· возможно, строки-свойства данной операции.

Общий формат записи отдельной операции класса следующий:

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

Примеры:

отобразить() – указано только имя операции;

+отобразить() – имя и видимость;

+добавитьТоварВКорзину(inout t:Товар) – видимость, имя, параметр, тип параметра и его направление;

удалитьТоварИзКорзины(q:ТоварВКорзине) – указаны имя и параметр;

изменитьКоличествоТовара(q:ТоварВКорзине, inout n: Integer): Integer – имя операции, параметры, направление параметра и тип возвращаемого значения.

Раскроем смысл спецификаций операций.

Имяоперации совместно с ее параметрами называют сигнатурой операции. Имя операции – это строка текста, которая используется в качестве идентификатора соответствующей операции и поэтому должна быть уникальной в пределах данного класса. В качестве имени обычно используют глагол или короткое глагольное выражение. Если оно состоит из нескольких слов, то все слова, кроме первого, пишутся с большой буквы и записываются без пробелов: добавить или добавитьТоварВКорзину.

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

· Символ "+" обозначает операцию с областью видимости типа общедоступный (public).

· Символ "#" обозначает операцию с областью видимости типа защищенный (protected).

· Символ "-" используется для обозначения операции с областью видимости типа закрытый (private).

· Символ "~" используется для обозначения операции с областью видимости типа пакетный (package).

Квантор видимости для операции может быть опущен. В этом случае его отсутствие просто означает, что видимость операции не указывается. Вместо условных графических обозначений также можно записывать соответствующее ключевое слово: public, protected, private, package.

Определение 9. Параметр (parameter) - спецификация переменной операции, которая может быть изменена, передана или возвращена.

Параметр может включать имя, тип, направление и значение по умолчанию.

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

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

Направление параметра может принимать одно из нижеследующих значений:

· in – входящий параметр, который не может быть изменен;

· out – выходящий параметр, который может быть изменен, чтобы передать информацию вызвавшей процедуре;

· inout – входящий параметр, который может быть изменен.

По умолчанию, если направление параметра не указано, принимается значение in.

Выражение типа является спецификацией типа данных для допустимых значений соответствующего формального параметра. Тип данных параметра может быть стандартным типом UML, либо, если в качестве входного параметра операция использует целый класс, то параметр имеет типом этот класс. В StarUML допускаются четыре стандартных типа UML: String, Integer, Float, Boolean. Параметр может также быть типом класса, который используется в данной операции. Тип параметра записывается с большой буквы (рис. 4).

Рис. 4. Параметр операции типа Order.

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

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

Выражение типа возвращаемого значения еще называют возвращаемым классом операции. Для определения возвращаемого класса можно использовать встроенные типы (String, Float, Integer, Boolean) или типы, определенные в вашей модели

Пример. Для того чтобы класс Order (Заказ) мог найти товары и добавить их в заказ, определим для него операцию findItem(). Результатом выполнения этой операции может быть элемент типа Item (рис. 5).

Рис. 5. Возвращаемое значение типа Item.

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

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