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

Таблица 2

Структурные типы сущностей в UML

- группирующая – элемент, используемый для некоторого смыслового объединения элементов диаграммы;

Таблица 3

Группирующие типы сущностей в UML

- поясняющая (аннотационная) – комментарий к элементу диаграммы.

Таблица 4

Поясняющие типы сущностей в UML

В некоторых источниках, в частности [3, 6], выделяют также поведенческие сущности взаимодействия и конечные автоматы, но с логической точки зрения их следует отнести к диаграммам.

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

Таблица 5

Отношения между сущностями

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

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

- * – любое количество экземпляров, в том числе и ни одного;

- целое неотрицательное число – кратность строго фиксирована и равна указанному числу (например: 1, 2 или 5);

- диапазон целых неотрицательных чисел "первое число .. второе число" (например: 1..5, 2..10 или 0..5);

- диапазон чисел от конкретного начального значения до произвольного конечного "первое число .. *" (например: 1..*, 5..* или 0..*);

- перечисление целых неотрицательных чисел и диапазонов через запятую (например: 1, 3..5, 10, 15..*).

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

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

Таблица 6

Механизмы расширения сущностей в UML

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

Рисунок 4. Обозначения класса-сущности.

3.4 Диаграммы

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

Таблица 7

Краткая характеристика диаграмм UML

Стандарт UML 2.x определяет также дополнительные, узко специализированные диаграммы: - диаграмму объектов (object diagram) - аналогична диаграмме классов, но вместо классов отображаются объекты;

- диаграмму синхронизации (timing diagram) - описывает состояния объекта с течением времени;

- композитную структурную диаграмму (composite structure diagram) - описывает порты (включая интерфейсы) класса для взаимодействия с другими классами;

- профильную диаграмму (profile diagram) - аналогична диаграмме пакетов с описанием классов, входящих в него;

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

3.4.1 Назначение и состав модели вариантов использования

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

Построение этой модели необходимо для выявления:

- внешнего окружения, взаимодействующего с системой (актеров);

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

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

Достижение этой цели, в первую очередь, достигается за счет разработки диаграмм UML, которые являются основными артефактами технологического процесса «Формирование требований». К диаграммам, которые рекомендуется построить в рамках рассматриваемой модели, относятся:

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

- диаграмма автоматов;

- диаграмма классов анализа;

- диаграмма последовательности;

- диаграмма коммуникации.

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

3.4.2 Назначение и состав модели анализа

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

Построение этой модели необходимо:

- для выявления внутренней архитектуры (определения подсистем и основных классов);

- для поиска альтернативных вариантов реализации системы (подсистем) и выбора основного;

- для уточнения всех требований (функциональных и нефункциональных).

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

Таблица 8

Варианты обозначения классов

Назначение классов анализа [6]:

- граничный класс – используется для моделирования взаимодействия между системой и актерами (пользователями, внешними системами или устройствами). Взаимодействие часто включает в себя получение или передачу информации, запросы на предоставление услуг и т. д. Граничные классы являются абстракциями диалоговых окон, форм, панелей, коммуникационных интерфейсов, интерфейсов периферийных устройств, интерфейсов API (англ. application program interface – интерфейс прикладных программ) и т. д. Каждый граничный класс должен быть связан как минимум с одним актером;

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

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

3.4.3 Общие сведения о диаграммах взаимодействия

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

Общими элементами диаграмм являются:

- экземпляры актеров и объекты, участвующие во взаимодействии;

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

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

- Имя объекта : Имя класса (например, Вася : Программист);

- : Имя класса (например, : Программист) – анонимный объект;

- Имя объекта (например, Вася) – предполагается, что имя класса известно;

- Имя объекта : (например, Вася :) – объект-сирота. Считается, что имя класса неизвестно.

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

Взаимодействие между экземплярами актеров и объектами моделируется посредством передачи сообщений. Сообщение (англ. message) – это спецификация факта передачи информации между сущностями с ожиданием выполнения определенных действий со стороны принимающей сущности. Сущность, отправляющую сообщение, называют клиентом, а принимающую – сервером. Таким образом, сообщения не только передают некоторую информацию, но и требуют или предполагают выполнения сервером определенных действий или передачу (возврат) клиенту необходимой информации. Если принимающей сообщение сущностью является объект, то оно представляет собой операцию (метод) объекта-сервера. Прием сообщения обычно трактуется, как возникновение события на сервере. Сообщения изображаются стрелкой с обязательным указанием направления (остриё стрелки указывает на принимающую сторону) и спецификации [1].

3.4.5 Назначение и состав диаграммы последовательности

Диаграмма последовательности наглядно отображает временной аспект взаимодействия. Она имеет два измерения. Одно измерение (слева-направо) указывает на порядок вовлечения экземпляров сущностей во взаимодействие. Крайним слева на диаграмме отображается экземпляр актера или объект, который является инициатором взаимодействия. Правее отображается другой экземпляр сущности, который непосредственно взаимодействует с первым и т.д. Второе измерение (сверху-вниз) указывает на порядок обмена сообщениями. Начальному моменту времени соответствует самая верхняя часть диаграммы. Масштаб на оси времени не указывается, поскольку диаграмма отображает лишь временную упорядоченность взаимодействия типа «раньше-позже» [1].

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

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

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

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

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