Файл: Применение объектно-ориентированного подхода при проектировании информационной системы.pdf

1.3 Диаграммы вариантов использования (модели прецедентов)

Поведение разрабатываемой системы (то есть функциональность, обеспечивае­мая системой) описывается с помощью функциональной модели, которая отобра­жает системные прецеденты (use cases), системное окружение (действующих лиц или актеров - actors) и связи между прецедентами и актерами (диаграммы преце­дентов - use cases diagrams). В нотации UML их чаще называют диаграммами вариантов использования. Основная задача модели прецедентов или диаграмм вариантов использования - представлять собой единое средство, дающее возможность заказчику, конечному пользователю и разработчику совместно обсуждать функциональность и поведение системы.

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

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

• только снабжать информацией систему;
• только получать информацию из системы;
• снабжать информацией и получать информацию из системы.

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

1. Кто заинтересован в определенном системном требовании?
2. Какую роль система будет выполнять в организации?
3. Кто получит преимущества от использования системы?
4. Кто будет снабжать систему информацией, использо­вать информацию и получать информацию от системы?
5. Кто будет осуществлять поддержку и обслуживание системы?
6. Использует ли система внешние ресурсы?
7. Выступает ли какой-либо участник системы в несколь­ких ролях?
8. Выступают ли различные участники в одной роли?
9. Будет ли новая система взаимодействовать со старой?

В языке UML актер изображается в виде фигуры человечка —

рис. №17 Нотация языка UML для изображения актера

---

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

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

Чтобы выделить прецеденты для системы, можно использовать следующую серию вопросов:

1. Каковы задачи каждого актера?
2. Будет ли актер создавать, хранить, изменять, удалять или получать инфор­мацию из системы?
3. Какой прецедент будет создавать, хранить, изменять, удалять или получать эту информацию?
4. Должен ли актер информировать систему о внезапных изменениях внеш­ней среды?
5. Должен ли актер быть проинформирован об изменени­ях состояния системы?
6. Какие прецеденты будут поддерживать и обслуживать систему?
7. Могут ли все функциональные требования быть реали­зованы прецедентами?

В языке UML прецедент изображается в виде овала.

Рис. №18 Нотация языка UML для прецедента

Между актером и прецедентом может существовать ассоциативное отноше­ние. Такой тип связи часто называют коммуникативной ассоциацией (communicate association), потому что она отражает связь между актером и прецедентом.

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

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

Отношение дополняет (extend relationship) применяется для отражения:

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

---

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

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

Пример отношений прецедентов показан на рис. 3.8.

рис. №19 Отношения прецедентов

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

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

Пример такой диаграммы для банковского автомата (Automated Teller Machine, ATM)

рис. №20 Пример use cases диаграммы

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

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

---

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

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

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

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

Состоянием (state) объекта называется одно из условий, в которых он может находиться. Состояние системы обычно меняется во времени и определяется набором свойств, называемых атрибутами (attribute), значений свойств и отношений между объектами. Например, объект учебный курс (CourseOffering) в системе регистрации учебных курсов может находиться в одном из двух состояний: открыт для записи или закрыт для записи. Если количество студентов, зарегистрировавшихся на курс, меньше десяти, запись на курс продолжается. После регистрации десятого студента она прекращается.

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

Индивидуальность (identity) означает, что каждый объект уникален, даже если его состояние идентично состоянию другого объекта. Например: Алгебра 101, секция 1 и Алгебра 101, секция 2 - два объекта в системе регистрации курсов. Хотя они оба являются учебными курсами, каждый из них уникален.

Класс (class) - это описание группы объектов с общими свойствами (атрибутами), поведением (операциями), отношениями с другими объектами и семантикой. Таким образом, класс представляет собой шаблон для создания объекта.

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

---

Граничные классы (boundary class) обеспечивают взаимодействие между окружающей средой и внутренними элементами системы. Такие классы предоставляют интерфейс для пользователя или другой системы (то есть для актера). Они составляют внешне зависимую часть системы и используются для моделирования интерфейсов системы. Граничные классы также используются для обеспечения связи с другими системами.

Управляющие классы (control class) служат для моделирования последователь­ного поведения одного или нескольких прецедентов и координации событий, ревизующих заложенное в них поведение. Управляющие классы можно представить, как классы, «исполняющие» прецедент и определяющие его динамику. Они обычно зависят от приложения.

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

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

рис. № 21 Диаграмма классов для варианта использования

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

Card Reader (устройство для чтения карточек). Account (счет), ATM Screen (экран ATM) и Cash Dispenser (кассовый аппарат). Каждый класс на диаграмме выглядит в виде прямоугольника, разделенного на три части. В первой содержится имя класса, во второй - его атрибуты. Атрибут - это некоторая информация, характеризующая класс. Например, у класса Account (счет) имеется три атрибута: Account Number (номер счета), PIN (идентификационный номер) и Balance (баланс). В последней части содержатся операции класса, отражающие его поведение (действия, выполняемые классом). У класса Account имеется четыре операции: Open (открыть). Withdraw Funds (снять деньги), Deduct Funds (вычесть сумму денег из счета) и Verify Funds (проверить наличие денег).

---