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

Диаграммы классов.

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

Разработку спецификаций программного обеспечения начинают с ана­лиза требований к функциональности, указанных в техническом задании. В процессе анализа выявляют внешних пользователей разрабатываемого про­граммного обеспечения и перечень отдельных аспектов его поведения в про­цессе взаимодействия с конкретными пользователями. Аспекты поведения программного обеспечения были названы «вариантами использования» или «прецедентами» (use cases).

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

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

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

В зависимости от цели выполнения конкретной процедуры различают следующие варианты использования:

• основные - обеспечивают требуемую функциональность разрабатыва­емого программного обеспечения;

• вспомогательные - обеспечивают выполнение необходимых настроек системы и ее обслуживание (например, архивирование информации и т_. п.);

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

Вариант использования можно описать кратко или подробно. Краткая форма описания содержит: название варианта использования, его цель, дей­ствующих Лиц, тип варианта использования (основная, второстепенная или дополнительная) и его краткое описание.

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

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

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

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

Связь - взаимодействие действующих лиц и соответствующих вариан­тов использования.

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

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

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

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

Пример 6.1. Построить диаграмму вариантов использования для систе­мы решения комбинаторно-оптимизационных задач.

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

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

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

Пример 6.2. Построить диаграмму вариантов использования для систе­мы учета успеваемости студентов.

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

Анализ вариантов использования показывает, что вариант получения сводки успеваемости по факультету «использует» вариант получения сводки по курсу, что и представлено на диаграмме.

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

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

Естественно, все варианты использования определить, как правило, не удается: новые варианты фиксируют постоянно, даже в процессе эксплуата­ции. Но, чем больше вариантов выявлено в процессе уточнения специфика­ций, тем лучше, так как при этом получают более точную модель предмет­ной области, что уменьшает вероятность ее пересмотра при добавлении функций.

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

• концептуальный уровень, на котором диаграммы классов, называемые в этом случае контекстными, демонстрируют связи между основными поня­тиями предметной области;

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

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

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

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

• концептуальную модель - на этапе анализа;

• диаграммы классов уровня спецификации - на этапе проектирования;

• диаграммы классов уровня реализации - на этапе реализации.

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

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

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

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

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

Отношение ассоциации означает наличие связи между экземплярами классов или объектами, например, класс Студент ассоциирован с классом Институт.

Ассоциация может иметь имя, например, Обучается. Рядом с именем ассоциации обычно ставят стрелку, указывающую направление чтения имени («Студент обучается в институте», а не наоборот).

Связь между экземплярами клас­сов подразумевает некоторые роли, ко­торые соответствующие объекты игра­ют по отношению друг к другу. Роль связана с направлением ассоциации. Так по отношению к студентам институт - организация, осуществляющая их обучение, т. е. роль института мож­но назвать Место учебы. Студент для института - объект обучающей дея­тельности института, т. е. Обучаемый. Если роль собственного имени не
имеет, то можно считать, что, ее имя совпадает с именем класса, по отноше­нию к которому определяется эта роль. Для рассматриваемого примера это соответственно роли Студент и Институт (рис. 6.7, а), но роль можно указать и явно (рис. 6.7б).

Роль также обладает характеристикой множественности, которая пока­зывает, сколько объектов может участвовать, в одной связи с каждой стороны.
Допускается указывать множественность:.

*-от 0 до бесконечности;

<целое>.. *- от заданного числа до бесконечности;

<целое> - точно определенное количество объектов;

<целое1>, <целое2> - несколько вариантов точного количества объектов;

<целое1>..<целое2> — диапазон объектов.

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

Чтобы избежать излишних нагромождений рекомендуется следовать простому правилу[37]; если некоторый объект X в реальном мире не явля­ется числом или текстом, то это скорее всего понятие. В противном слу­чае — это атрибут.

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

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

• формируют множество понятий-кандидатов из существительных, ха­рактеризующих предметную область в описании вариантов использования;

• исключают понятия, не существенные для данного варианта использо­вания, например, в предыдущем примере, «информация», «ввод» и т. п.

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

Для построения диаграммы последовательностей системы необходимо:

• представить систему как «черный ящик» и изобразить для нее линию жизни - вертикальную пунктирную линию, подходящую к блоку снизу;

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

• из описания варианта использования определить множество систем­ных событий и их последовательность;

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

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

Множество всех системных операций определяют, идентифицируя сис­темные события всех вариантов использования. Для наглядности системные операции изображают в виде операций абстрактного класса (типа) System. Если необходимо разделить множество операций на подмножества, иниции­руемые разными пользователями, то используют несколько абстрактных классов: Systeml, System2 и т. д.

Каждую системную операцию необходимо описать. Обычно описание системной операции содержит:

• имя операции и ее параметры;

• описание обязанности;

• указание типа;

• названия вариантов использования, в которых она используется;

• примечания для разработчиков алгоритмов и т. д.;

• описание обработки возможных исключений;

• описание вывода неинтерфейсных сообщений;

• предположение о состоянии системы до выполнения операции (предусловие);

• описание изменения состояния системы после выполнения операций
(постусловие).

Для примера опишем операцию Инициировать решение ():

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