49157

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Конспект

Информатика, кибернетика и программирование

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

Русский

2014-06-10

5.61 MB

81 чел.

Федеральное агентство по образованию РФ

ГОУ ВПО «Сибирский государственный

технологический университет»

ТЕХНОЛОГИЯ РАЗРАБОТКИ

ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Курс лекций

Красноярск 20052006


Федеральное агентство по образованию РФ

ГОУ ВПО «Сибирский государственный

технологический университет»

ТЕХНОЛОГИЯ РАЗРАБОТКИ

ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Курс лекций

Для студентов направления 552800,

специальности 220400 всех форм обучения.

Красноярск 20052006


Технология разработки программного обеспечения: Курс лекций для студентов направления 552800, специальности 220400 всех форм обучения/ сост. Доррер М.Г.  – Красноярск: СибГТУ, - 2006, 97 с.

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

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

Утверждён на заседании кафедры системотехники 16.02.2006 г., протокол №4.

Рекомендован к изданию методическим советом факультета ФАИТ 09.03.2006, протокол №3.

© ГОУ ВПО «Сибирский государственный технологический университет», 2006. 

© М.Г. Доррер, 2006



Проектирование динамики приложений при помощи диаграмм переходов состояний, диаграмм последовательности и диаграмм взаимодействия в UML

Управление требованиями к программному продукту. CASE-средство Requisite Pro

Тестирование приложений. Функциональное тестирование, нагрузочное тестирование. CASE-средства Rational Functional Tester, Rational Performance Tester

Комплексные технологические циклы при разработке ПО. Программные комплексы AllFusion, Rational Suite.

Управление качеством при разработке ПО. Стандарты, регламентирующие разработку ПО.

Формирование концепции проекта по разработке ПО. Разработка документа «Область применения»

Планирование разработки ПО. Разработка устава проекта, рабочего плана проекта. Программный продукт Microsoft Project.

Организация выполнения работ в проектах разработки ПО. Процедура доведения задач до исполнителей.

Мониторинг хода выполнения проекта. Процедура управления изменениями

Содержание

[1]

[2] Введение

[3] Жизненный цикл программных систем

[4] Прикладной системный анализ при разработке ПО. Принципы структурного анализа. Процедура требований

[5] План лекции

[6]  

[6.1] Принципы структурного анализа Введение

[6.2] Проблема сложности ИС

[6.3] Группы средств моделирования систем

[7] Моделирование функций ПО. Нотация IDEF0. CASE-средство BPWin

[7.1] План лекции

[7.2]  

[7.3] Structured Analysis and Design Technique Введение

[7.4] Диаграммы IDEF0.

[7.4.1] Виды связей в IDEF0

[7.4.2] Диаграмма дерева узлов

[7.4.3] Диаграмма «Только для просмотра» (For Exposition Only – FEO)

[7.5] CASE-средство BPWin

[8] Описание динамики системы. Нотация IDEF3

[9] Постановка требований к данным. Словари данных. Моделирование данных в нотации IDEF1x. CASE-средство ERWin

[9.1] План лекции

[9.2]  

[9.3] Введение

[9.4] Данные в AllFusion Modeling Suite описываются при помощи ER-диаграм в CASE-средстве ERWin. Вместе с тем, начинается описание данных уже при построении модели бизнес процессов. Выполняется это при помощи таких средств BPWin, как словарь стрелок (Arrow Dictionary) и словарь сущностей и атрибутов (Entity/Attribute Dictionary).

[9.5] Словарь данных

[9.6] Моделирование данных в нотации IDEF1x

[9.6.1] Базовые понятия ERD

[9.6.2] Виды сущностей в IDEF1x

[9.6.3] Виды связей в IDEF1X

[9.6.4] Нормализация схемы данных

[10] Постановка требований к интерфейсу ПО. Понятие Usability.

[10.1] Эргономические цели и показатели качества программного продукта

[10.2] Проблемы, возникающие на этапе разработки прототипа GUI и варианты их решения

[10.3] Принципы реализации пользовательского интерфейса

[11] Объектно-ориентированная методология проектирования ПО. Язык UML. CASE-средство Rational Rose.

[11.1] План лекции

[11.2] Методология объектно-ориентированного анализа и проектированияВведение

[11.3] Основные компоненты языка UML

[11.4] Назначение языка UML

[11.5] Общая структура языка UML

[11.6] Пакеты в языке UML

[11.7] Основные пакеты метамодели языка UML

[11.7.1] Пакет Основные элементы

[11.7.2] Пакет Элементы ядра

[11.7.3] Пакет Вспомогательные элементы

[11.7.4] Пакет Механизмы расширения

[11.7.5] Пакет Типы данных

[11.7.6] Пакет Элементы поведения

[11.7.7] Пакет Общее поведение

[11.7.8] Пакет Кооперации

[11.7.9] Пакет Варианты использования

[11.7.10] Пакет Автоматы

[11.7.11] Пакет Общие механизмы

[11.7.12] Пакет Управление моделями

[11.8] Специфика описания метамодели языка UML

[11.9] Особенности изображения диаграмм языка UML

[11.10] Объектно-ориентированные CASE-средства (Rational Rose)

[11.10.1] Структура и функции

[11.10.2] Взаимодействие с другими средствами и организация групповой работы

[11.10.3] Среда функционирования

[12] Описание функциональных требований к ПО при помощи диаграмм вариантов использования в UML

[13] План лекции

[13.1] Вариант использования

[13.2] Актеры

[13.3] Интерфейсы

[13.4] Примечания

[13.5] Отношения на диаграмме вариантов использования

[13.5.1] Отношение ассоциации

[13.5.2] Отношение расширения

[13.5.3] Отношение обобщения

[13.5.4] Отношение включения

[13.6] Пример построения диаграммы вариантов использования

[13.7]  Рекомендации по разработке диаграмм вариантов использованияЗаключение

[14] Проектирование внутренней структуры приложений при помощи диаграмм классов в UML

[14.1] Класс

[14.2] Имя класса

[14.3] Атрибуты класса

[14.4] Операция

[14.5] Отношения между классами

[14.5.1] Отношение зависимости

[14.5.2] Отношение ассоциации

[14.5.3] Отношение агрегации

[14.5.4] Отношение композиции

[14.5.5] Отношение обобщения

[14.6] Интерфейсы .

[14.7] Объекты

[14.8] Шаблоны или параметризованные классы

[14.9] Рекомендации по построению диаграмм классовЗаключение

[15] Проектирование динамики приложений при помощи диаграмм переходов состояний, диаграмм последовательности и диаграмм взаимодействия в UML

[16] План лекции

[16.1] Диаграмма состояний (statechart diagram)Введение

[16.1.1] Автоматы

[16.1.2] Состояние

[16.1.2.1] Имя состояния

[16.1.2.2] Список внутренних действий

[16.1.2.3] Начальное состояние

[16.1.2.4] Конечное состояние

[16.1.3] Переход

[16.1.4] Сторожевое условие

[16.1.5] Выражение действия

[16.1.6] Составное состояние и подсостояние

[16.1.7] Последовательные подсостояния

[16.1.8] Параллельные подсостояния

[16.1.9] Историческое состояние

[16.1.10] Сложные переходы

[16.1.11] Переходы между параллельными состояниями

[16.1.12] Переходы между составными состояниями

[16.1.13] Синхронизирующие состояния

[16.1.14] Заключительные рекомендации по построению диаграмм состояний

[16.2] Диаграмма деятельности (activity diagram)

[16.2.1] Состояние действия

[16.2.2] Переходы

[16.2.3] Дорожки

[16.2.4] Объекты

[16.2.5] Рекомендации по построению диаграмм деятельности

[16.3] Диаграмма последовательности (sequence diagram)

[16.3.1] Объекты

[16.3.2] Линия жизни объекта

[16.3.3] Фокус управления

[16.3.4] Сообщения

[16.3.5] Ветвление потока управления

[16.3.6] Стереотипы сообщений

[16.3.7] Временные ограничения на диаграммах последовательности

[16.3.8] Комментарии или примечания

[16.3.9] Пример построения диаграммы последовательности

[16.3.10] Заключениеительные рекомендации по построению диаграмм последовательности

[17] Управление требованиями к программному продукту. CASE-средство Requisite Pro.

[17.1] План лекции

[17.2]  

[17.3] Введение

[17.4] Нормативная основа

[17.5] Термины, сокращения и определения

[17.6] Основные положения

[17.6.1] Цели управления требованиями

[17.6.2] Участники управления требованиями

[17.6.3] Политика  в области управления требованиями

[17.7] Обеспечение процессов управления требований

[17.7.1] Распределение ответственности

[17.7.1.1] Аналитик

[17.7.1.2] Менеджер проекта

[17.7.1.3] Тестировщик

[17.7.1.4] Проектировщик

[17.7.1.5] Разработчик

[17.7.2] Документирование

[17.7.3] Обеспечение ресурсами

[17.7.4] Обучение

[17.8] Действия по управлению требованиями

[17.8.1] Анализ требований

[17.8.2] Разработка материалов проекта на основе требований

[17.8.3] Контроль изменений требований

[17.9] Измерения

[17.9.1] Показатель важности

[17.9.2] Стабильность

[17.9.3] Статус требований

[17.9.4] Степень выполнения требований

[17.9.5] Трудоемкость

[17.10] Верификация

[17.10.1] Контроль со стороны руководства

[17.10.2] Контроль со стороны руководителя проекта

[17.10.3] Контроль со стороны ГОК

[17.11] Стандарт оформления требований

[17.11.1] Шаблон для разработки требований

[17.11.2] Правила оформления требований

[17.11.3] Структурирование требований

[17.12] Показатели качества требований

[17.12.1] Корректность

[17.12.2] Однозначность

[17.12.3] Полнота

[17.12.4] Совместимость

[17.12.5] Ранжированность по важности и стабильности

[17.12.6] Проверяемость

[17.12.7] Модифицируемость

[17.12.8] Прослеживаемость

[17.13] Начало работы с RequisitePro

[17.14] Создание и настройка проекта

[17.14.1] Создание проекта

[17.14.2] Создание типов требований

[17.14.3] Определение атрибутов

[17.14.4] Создание типов документов

[17.15] Добавление требований

[17.15.1] Требования в документах

[17.15.2] RequisitePro Views

[17.16] Обсуждения

[17.17] Заключение

[18] Тестирование приложений. Функциональное тестирование, нагрузочное тестирование. CASE-средства Rational Functional Tester, Rational Performance Tester.

[18.1] План лекции

[18.2]  

[18.3] Введение

[18.4]  Дестабилизирующие факторы и методы обеспечения высокого качества функционирования ПО

[18.4.1] Использование среды автоматизированного тестирования Platinum TESTBytes

[18.4.2]  Методы обеспечения качества и надежности программных средств

[18.4.3]  Использование CASE для повышения качества ПО

[18.4.4] Влияние стандартов открытых систем на качество ПО

[18.4.5] Повышение качества ПО путем тестирования

[18.5]  Основные особенности процесса тестирования ПО

[18.5.1]  Организационные особенности тестирования

[18.5.2]  Сертификация ПО

[18.5.3] Организация и планирование тестирования для обеспечения качества ПО

[18.6]  Важнейшие разделы ISO 9003

[18.6.1]  Общие положения

[18.6.2]  Документирование системы качества

[18.6.3]  Программа качества

[18.6.4]  Внутренние проверки системы качества

[18.6.5]  Корректирующие действия

[19] Комплексная интеграция BPWin, ERWin и Paradigm Plus.

[19.1] План лекции

[19.2]  

[19.3] Введение

[19.4] Соответствие объектов моделей процессов и моделей данных

[19.5] Экспорт между моделью данных и моделью процессов

[19.6] Paradigm Plus: двусторонняя связь с ERwin

[19.7] Создание физической модели данных в ERWin

[19.7.1] Уровни физической модели

[19.7.2]  Правила валидации и значения по умолчанию

[19.7.3]  Индексы

[19.7.4]  Триггеры и хранимые процедуры

[19.7.5]
Значения RI, используемые ERWin для различных типов связей

[19.8] План лекции

[19.9]  

[19.10] Стандарт ISO 12207:1995 - Процессы жизненного цикла программных средствВведение

[19.11] ISO 15504 SPICE

[19.12]  Серия стандартов ГОСТ 34-ХХХ «Информационная технология»

[19.12.1] ГОСТ 34.601-90. Информационная технология. Автоматизированные системы. Стадии создания.

[19.12.2] ГОСТ 34.602-89. Информационная технология. Техническое задание на создание автоматизированной системы

[19.12.3] ГОСТ 34.603-92. Информационная технология. Виды испытаний автоматизированных систем

[20]  

[21] Заключение

[22] Определение концепции проекта

[22.1]  

[23] Управление проектами разработки информационных систем

[23.1]  Процессы управления проектами

[23.2]  Процессы проекта

[23.3]  Группы процессов

[23.4]  Взаимосвязи процессов

[23.5]  Процессы инициации

[23.6]  Процессы планирования

[23.6.1]  Основные процессы планирования

[23.6.2]  Вспомогательные процессы планирования

[23.7]  Процессы исполнения и контроля

[23.8]  Процессы анализа

[23.8.1]  Основные процессы анализа

[23.8.2]  Вспомогательные процессы анализа

[23.9]  Процессы управления

[23.9.1]  Основные процессы управления

[23.9.2]  Вспомогательные процессы управления

[23.10]   Процессы завершения

[24] Определение концепции проекта (область применения, цели и подход)

[24.1] Введение

[24.2]  Процессы проекта

[24.3]  Группы процессов

[24.4]  Взаимосвязи процессов

[24.5]  Процессы инициации

[24.6] Результаты

[24.7] Исходная информация

[24.8] Шаги задачи

[24.9] Методика и подход

[24.9.1] Выработать основные положения проекта

[24.9.2] Определить область применения, цели и подход

[24.9.3] Произвести оценку рисков

[24.9.4] Получить подтверждение Заказчика и Исполнителя

[24.10] Роли и ответственность

[25] Рабочий план

[25.1] План лекции

[25.2] Устав проекта, как комплекс регламентных, плановых и отчетных документов.

[25.3] Введение

[25.3.1] Основные процессы планирования

[25.3.2] Вспомогательные процессы планирования

[25.4] По работам

[25.5]
По исполнителям

[25.6] Диаграмма Гантта по проекту

[25.7] График движения денежных средств по проекту

[25.8] Полномочия в изменении плана

[25.9] Процессы управления

[25.9.1]  Основные процессы управления

[25.9.2]  Вспомогательные процессы управления

[25.10]   Процессы завершения

[25.11] Процессы анализа

[25.11.1] Основные процессы анализа

[25.11.2]  Вспомогательные процессы анализа

[26] Заключение

[27] Контрольные вопросы

[28] Библиографический список

[29] Заключение

[30]  

[31] Контрольные вопросы

[32] Библиографический список

[32.1] Диаграммы потоков данных

[32.1.1] Основные символы DFD

[32.1.2] Контекстная диаграмма и детализация процессов

[32.1.3] Декомпозиция и слияние данных

[32.1.4] Построение модели

[33] Построение модели в DFD на примере банковской задачи



Введение

Приступая к изучению дисциплины «Технология разработки и программного обеспечения (ПО)», определимся  целями, и задачами, которые встанут перед нами в данном курсе. В результате изучения дисциплины студенты должны:

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

Курс «Технология разработки и САПР ПО» связан с другими дисциплинами следующим образом:

  •  Курс является заключительным в цикле подготовки по разработке программного обеспечения и опирается на следующие дисциплины: «Информатика и программирование», «Структуры и алгоритмы обработки данных», «Базы данных», «Операционные системы».
  •  Материалы курса используются в дисциплинах специализаций при подготовке инженеров по специальности 220400 и магистров по направлению 552822 на 9 – 10 или, соответственно, 9 – 12 семестрах обучения.

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

Технология – совокупность методов изготовления изделия.

Таким образом можно провести следующие параллели:

ПО

Изделие

 Разработка ПО

Инженерное проектирование ПП


  1.  Жизненный цикл программных систем

План  лекции

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

Введение

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

Программа, программная система. Программный продукт. Программная система как технологический объект.

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

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

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

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

  •  Информационную модель, представляющая собой совокупность правил и алгоритмов функционирования ИС. Информационная модель включает в себя все формы документов, структуру справочников и данных и т.д.
  •  Регламент развития информационной модели и правила внесения в нее изменений.
  •  Кадровые ресурсы (департамент развития, привлекаемые консультанты), отвечающие за формирование и развитие информационной модели.
  •  Программный комплекс (ПК), конфигурация которого соответствует требованиям информационной модели (программный комплекс является основным движителем и одновременно  механизмом управления ИС). Кроме этого всегда существуют требования к поставщику ПК, регламентирующие процедуру технической и пользовательской поддержки на протяжении всего жизненного цикла.
  •  Кадровые ресурсы, отвечающие за конфигурирование ПК  и его соответствие утвержденной информационной модели.
  •  Регламент внесения изменений в конфигурацию ПК и состав его функциональных модулей.
  •  Аппаратно-техническую базу, соответствующая требованиям по эксплуатации ПК (компьютеры на рабочих местах, периферия, каналы телекоммуникаций, системное ПО и СУБД).
  •  Эксплуатационно-технические кадровые ресурсы, включая персонал по обслуживанию аппаратно-технической базы.
  •  Правила использования ПК и пользовательские инструкции, регламент обучения и сертификации пользователей. 

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

Понятие жизненного цикла программных систем

В основе деятельности по созданию и использованию программного обеспечения (ПО) лежит понятие его жизненного цикла (ЖЦ).

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

Принято выделять следующие этапы ЖЦ ПО:

  •  анализ требований;
  •  проектирование;
  •  кодирование;
  •  тестирование и отладка;
  •  эксплуатация и сопровождение;
  •  вывод из эксплуатации и замена.

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

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

Модели жизненного цикла программного обеспечения

Модели ЖЦ определяют порядок исполнения этапов в ходе разработки, а также критерии перехода от этапа к этапу. Наибольшее распространение получили следующие модели:

Каскадная модель ЖЦ ПО (1970-1980 гг.) – предполагает переход к следующему этапу после полного завершения предыдущего (рис.1).

Поэтапная модель с промежуточным контролем (1980-1985 гг.) – итерационная модель разработки ПО с циклами обратной связи между этапами (рис. 2). Преимущество модели – уменьшение трудоемкости благодаря межэтапным корректировкам. Недостаток – отсутствие четко выделенных этапов разработки, растягивание их на весь ЖЦ.

Спиральная модель (1986–1990 гг.) – упор делается на начальные этапы ЖЦ: анализ требований, проектирование спецификаций, предварительное и детальное проектирование. На этих этапах проводится проверка и обоснование реализуемости технических решений путем создания прототипов. Каждый виток спирали соответствует поэтапной модели создания фрагмента или версии программного изделия, уточняются цели и параметры проекта и в результате выбирается обоснованный вариант, который доводится до реализации (рис. 3).

Преимущества модели:

  •  Накопление и повторное использование программных средств, моделей и прототипов.
  •  Ориентация на развитие и модификацию ПО в процессе проектирования.
  •  Анализ риска и  издержек в процессе проектирования.

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

Главная особенность индустрии ПО состоит в концентрации сложности на начальных этапах ЖЦ (анализ, проектирование) при относительно невысокой сложности и трудоемкости последующих этапов. Более того, нерешенные вопросы и ошибки, допущенные на этапах анализа и проектирования, порождают на последующих этапах трудные, часто неразрешимые проблемы и, в конечном счете, приводят к неуспеху всего проекта. Рассмотрим эти этапы более подробно.

  1.   Каскадная модель жизненного цикла программного обеспечения.

  1.   Поэтапная модель жизненного цикла программного обеспечения

  1.   Спиральная модель жизненного цикла программного обеспечения
  2.  

Фазы жизненного цикла ПО

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

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

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

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

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

Этап проектирования дает ответ на вопрос: "Как (каким образом) система будет удовлетворять предъявленным к ней требованиям?". Задачей этого этапа является исследование структуры системы и логических взаимосвязей ее элементов, причем здесь не рассматриваются вопросы, связанные с реализацией на конкретной платформе.

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

Обычно этот этап разделяют на два подэтапа:

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

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

Кодирование. На этом этапе должны быть получены следующие результаты:

  1.  Верифицированная детальная спецификация каждого блока:
    •  Спецификация каждой подпрограммы или модуля, имени, назначения, предположений, размеров, последовательности вызовов, ошибочных выходов, входных и выходных данных, алгоритмов и логической схемы.
    •  Описание базы данных до уровня атрибутов.
    •  Верификация полноты, непротиворечивости и соответствия требованиям проектных спецификаций системы и планам распределения ресурсов.
  2.  Одобренный план приемных испытаний.
  3.  Руководство пользователя и предварительный план комплексирования и отладки.
  4.  Проверка работы всех модулей не только для номинальных, но и для исключительных и предельных значений.
  5.  Проверка всех вариантов ввода и вывода, включая сообщения об ошибках.
  6.  Выполнение всех операторов и всех ветвей передачи управления.
  7.  Проверка выполнения стандартов разработки.
  8.  Завершение помодульного документирования внутренней структуры.

Эксплуатация и сопровождение. Содержание данного этапа следующее:

  1.  Проверка удовлетворения приемных испытаний системы.
  2.  Проверка удовлетворения системных требований.
  3.  Проверка производственной готовности, аппаратуры, средств обслуживания и персонала.
  4.  Завершение всех специфицированных работ и ввод системы в действие.

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

  1.  Выбор новой системы.
  2.  Миграция данных в новую систему.
  3.  Очистка системы от старого ПО.
  4.  Утилизация материальных носителей (диски, документация и т.п.).
  5.  Документирование вывода и замены ПО.

Заключение

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


  1.  Прикладной системный анализ при разработке ПО. Принципы структурного анализа. Процедура требований


  1.  План лекции
  •  Прикладной системный анализ при разработке ПО. Принципы структурного анализа. Процедура консалтинга при автоматизации.
  •  Понятие консалтинга при автоматизации. Цели и основные этапы консалтинговых проектов. Проведение обследования деятельности предприятия. Построение моделей. Предложение по автоматизации и техническое проектирование.
  •  Подходы к улучшению деятельности предприятий. Реинжиниринг по Хаммеру и Чампи (BPR).
  •  Методы оценки деятельности предприятий. Ключевые моменты реорганизации деятельности предприятий. Ключевые особенности управления бизнес-процессами.


  1.  
    1.  Принципы структурного анализа Введение

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

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

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

Системный анализ выполняется в три основные стадии:

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

Иногда системный анализ определяют как «методику улучшающего вмешательства в проблемную ситуацию»

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

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

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

  •  разбиение на уровни абстракции с ограничением числа элементов на каждом из уровней (обычно от 3 до 6-7);
  •  ограниченный контекст, включающий лишь существенные на каждом уровне детали;
  •  двойственность данных и операций над ними;
  •  использование строгих формальных правил записи;
  •  последовательное приближение к конечному результату.

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

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

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

  1.  Принцип абстрагирования – заключается в выделении существенных с некоторых позиций аспектов системы и отвлечение от несущественных с целью представления проблемы в простом общем виде.
  2.  Принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы.
  3.  Принцип упрятывания – заключается в скрытии несущественной на конкретном этапе информации: каждая часть "знает" только необходимую ей информацию.
  4.  Принцип концептуальной общности – заключается в следовании единой философии на всех этапах ЖЦ (структурный анализ - структурное проектирование – структурное программирование – структурное тестирование).
  5.  Принцип полноты – заключается в контроле на присутствие лишних элементов.
  6.  Принцип непротиворечивости – заключается в обоснованности и согласованности элементов.
  7.  Принцип логической независимости – заключается в концентрации внимания на логическом проектировании для обеспечения независимости от физического проектирования.
  8.  Принцип независимости данных – заключается в том, что модели данных должны быть проанализированы и спроектированы независимо от процессов их логической обработки, а также от их физической структуры и распределения.
  9.  Принцип структурирования данных – заключается в том, что данные должны быть структурированы и иерархически организованы.
  10.   Принцип доступа конечного пользователя – заключается в том, что пользователь должен иметь средства доступа к базе данных, которые он может использовать непосредственно (без программирования).

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

  1.  Проблема сложности ИС

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

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

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

  1.  Группы средств моделирования систем

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

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

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

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

  •  функциональность системы;
  •  динамика системы;
  •  отношения сущностей системы.

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



  1.  Классификация нотаций моделирования



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

  •  DFD (Data Flow Diagrams) - диаграммы потоков данных совместно со словарями данных и спецификациями процессов или миниспецификациями;
  •  SADT (Structured Analysis and Design Technique) – методология структурного анализа и проектирования
  •  ERD (Entity-Relationship diagrams) – диаграммы «сущность-связь»;
  •  STD (State Transition Diagrams) – диаграммы переходов состояний.

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

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

  1.  Группы средств структурного анализа в SADT

Заключение

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

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

Таблица 1 - Распределение трудозатрат по этапам ЖЦ ПО

Способ разработки

Анализ

Проекти-рование

Коди-рование

Тести-рование

Традиционная разработка

20%

15%

20%

45%

Использование структурных методологий

30%

30%

15%

25%

Использование CASE-технологий

40%

40%

5%

15%


  1.  Моделирование функций ПО. Нотация IDEF0. CASE-средство BPWin
    1.  План лекции
  •  История возникновения и развития подходов, связанных с графическим моделированием деятельности.
  •  Подход к моделированию функциональности систем Structured Analisys and Desig Technique (SADT).
  •  Семейство стандартов IDEF.
  •  Стандарт IDEF0.
  •  Графические символы стандарта.
  •  Виды связей.
  •  Правила декомпозиции.
    1.  
    2.  Structured Analysis and Design Technique Введение

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

В основу методологии положены следующие концепции:

  •  Моделируемая система рассматривается как произвольное подмножество Вселенной;
  •  Система имеет границу, отделяющую ее от остальной вселенной. Взаимодействие системы с окружающим миром описывается следующими терминами:
    •  Вход (нечто перерабатываемое системой);
    •  Выход (результат деятельности системы);
    •  Управление (стратегии и процедуры, под управлением которых производится работа);
    •  Механизм (ресурсы, необходимые для проведения работы).
  •  Находясь под управлением, система преобразует входы в выходы с использованием механизмов.
  •  Графическое представление функциональной модели. В модели SADT функция представляется в виде блока, а интерфейсы входа-выхода представляются дугами. Взаимодействие блоков друг с другом описывается при помощи интерфейсных дуг, выражающих ограничения в выполнении и управлении функций.
  •  Строгость и точность. Правила SADT включают:
    •  Ограничение числа блоков на каждой диаграмме (2 – 8 блоков).
    •  Связность диаграмм (структурная нумерация блоков).
    •  Уникальность меток и наименований.
    •  Синтаксические правила для графики (блоков и дуг).
    •  Разделение входов и управлений (определение роли данных).
  •  Отделение организации от функции, то есть исключение влияния организационной структуры на функциональную модель.

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

Перед построением модели следует определить область моделирования (Scope), которая включает в себя позицию, с которой рассматривается система (View Point) и цель моделирования (Purpose). При описании области моделирования ее следует ограничить по широте (решить, что входит контекст системы, а что останется за ним) и по глубине (решить, на каком уровне детализации модель будет завершена).

Цель моделирования. Модель не может быть построена без четко сформулированной цели. Цель должна отвечать на вопросы:

  •  Почему эту систему надо моделировать?
  •  Что должна показывать модель?
  •  Что может получить читатель от модели?

Формулировка цели позволяет аналитикам сфокусировать усилия в нужном направлении. Примеры целей: «Идентифицировать роли и ответственность служащих для написания должностных инструкций», «Описать деятельность предприятия с целью создания спецификации информационной системы».

Точка зрения. Несмотря на то, что при моделировании системы учитываются мнения различных людей, модель должна строиться, исходя из единой точки зрения. Точка зрения может быть представлена как взгляд человека, который видит систему в нужном для моделирования аспекте. Точка зрения должна соответствовать цели моделирования. Точка зрения различных, участвующих в работе специалистов (например, финансистов и технологов) может быть различной, поэтому важно в процессе моделирования оставаться на единой точке зрения. Как правило, выбирается точка зрения лица, ответственного за моделируемую работу в целом. Если при выборе точки зрения необходимо задокументировать дополнительные альтернативные точки зрения, для этого используется диаграмма FEO (For Exposition Only).

Модели As-Is и To-Be. Модель As-Is – описание существующего положения дел в организации (системе). Модель To-Be строится для анализа альтернативных путей выполнения работ и документирования того, как система будет функционировать в будущем.

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

  1.   Создание модели As-Is.
  2.  Ее анализ и улучшение бизнес-процессов (создание модели To-Be).
  3.  На основе модели To-Be – построение модели данных, прототипов и окончательных версий информационной системы.

Если различие между As-Is и To-Be велико и процесс перехода между ними неочевиден, то кроме As-Is и To-Be, строится третья модель, изображающая такой процесс.

  1.  Диаграммы IDEF0.

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

В IDEF0 выделяется 4 вида диаграмм:

  •  Контекстная диаграмма.
  •  Диаграмма декомпозиции.
  •  Диаграмма дерева узлов.
  •  Диаграмма только для экспозиции (FEO).

Основные символы и виды дуг изображены на рисунке 6.

  1.  Функциональный блок и интерфейсные дуги в IDEF0

Работа (Activity) обозначает поименованный процесс, функцию или задачу, происходящую в течение определенного времени и имеющую распознаваемый результат. Имя работы должно выражаться отглагольным существительным, обозначающим действие (например, «Изготовление детали», «Прием заказа»).

Стрелки (Arrow) описывают взаимодействие системы с внешним миром и работой между собою. Стрелки представляют собой информацию или физические объекты и именуются существительными (например, «Заготовка», «Изделие», «Заказ»).

В IDEF0 различают 5 типов стрелок:

  •  Вход (Input) – материал или информация, использующаяся или преобразуемая работой для получения результатов. Стрелки такого типа изображаются входящими в левую грань блока функции.
  •  Управление (Control) – правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Стрелки такого типа изображаются входящими в верхнюю грань блока функции.
  •  Выход (Output) – материал или информация, производящаяся работой. Стрелки такого типа изображаются выходящими из правой грани блока функции.
  •  Механизм (Mechanism) – ресурсы, которые выполняют работу (персонал предприятия, станки, устройства и т.п.). Стрелки этого типа изображаются входящими в нижнюю грань блока функции.
  •  Вызов (Call) – специальная стрелка, указывающая на другую модель работы. Стрелка рисуется исходящей из нижней грани блока.

Для дополнительной идентификации стрелок каждой из них присваивается ICOM-код (ICOM – аббревиатура от Input-Control-Output-Mechanism). Код стрелки содержит префикс, соответствующий типу стрелки (I, C, O или M) и ее порядковый номер.

Правила работы со словарем данных в IDEF0 аналогичны правилам, используемым в DFD.

Пример контекстной диаграммы IDEF0 для банковской задачи приведён на рисунке 7.


  1.   Контекстная диаграмма IDEF0 банковской задачи


  1.  Виды связей в IDEF0

Функции в IDEF0 располагаются в порядке доминирования. Функция управляющая, или предшествующая располагается левее и выше управляемой функции.

В IDEF0 различают 5 видов связей между работами (рис.8):

  •  Связь по входу (outputinput).
  •  Связь по управлению (outputcontrol).
  •  Обратная связь по входу (outputinput feedback).
  •  Обратная связь по управлению (outputcontrol feedback).
  •  Связь выход-механизм (outputmechanism). Связь показывает, что одна работа подготавливает ресурсы, необходимые для проведения другой работы.

  1.  Виды связей в IDEF0.

Примеры декомпозиции процессов банковской задачи при помощи диаграмм IDEF0 приведены на рисунках 9 и 10.

  1.  Диаграмма первого уровня IDEF0 для банковской задачи

  1.  Диаграмма IDEF0 для процесса «Обработать запрос на обслуживание»

  1.  Диаграмма дерева узлов

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

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

Дерево узлов для банковской задачи приведено на рисунке 11.

  1.  Дерево узлов банковской задачи

  1.  Диаграмма «Только для просмотра» (For Exposition OnlyFEO)

Диаграммы   «Только для просмотра»   используются в моделях для иллюстрации других точек зрения, для отражения деталей, не поддерживаемых синтаксисом IDEF0. Диаграмма FEO позволяет нарушить любое синтаксическое правило, поскольку является по сути лишь картинкой – копией стандартной диаграммы – и не включается в анализ синтаксиса. Например, работа на диаграмме FEO может не иметь стрелок управления и выхода.

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

Если же FEO создается для иллюстрации альтернативной точки зрения по модели, то рекомендуется придерживаться синтаксиса IDEF0.

  1.  CASE-средство BPWin

Для проведения анализа и реорганизации бизнес-процессов PLATINUM technology предлагает CASE-средство верхнего уровня BPwin, поддерживающее методологии IDEFO (функциональная модель), IDEF3 (WorkFlow Diagram) и DFD (DataFlow Diagram). Функциональная модель предназначена для описания существующих бизнес-процессов на предприятии (так называемая модель AS-IS) и идеального положения вещей - того, к чему нужно стремиться (модель ТО-ВЕ). Методология IDEFO предписывает построение иерархической системы диаграмм - единичных описаний фрагментов системы. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром (контекстная диаграмма), после чего проводится функциональная декомпозиция - система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее До достижения нужной степени подробности. После каждого сеанса декомпозиции проводится сеанс экспертизы: каждая диаграмма проверяется экспертами предметной области, представителями заказчика, людьми, непосредственно участвующими в бизнес-процессе. Такая технология создания модели позволяет построить модель, адекватную предметной области на всех уровнях абстрагирования. Если в процессе моделирования нужно осветить специфические стороны технологии предприятия, BPwin позволяет переключиться на любой ветви модели на нотацию IDEF3 или DFD и создать смешанную модель. Нотация DFD включает такие понятия, как внешняя ссылка-и хранилище данных, что делает ее более удобной (по сравнению с IDEFO) для моделирования документооборота. Методология IDEF3 включает элемент "перекресток", что позволяет описать логику взаимодействия компонентов системы.

Заключение

На основе модели BPwin можно построить модель данных. Для построения модели данных PLATINUM technology предлагает мощный и удобный инструмент - ERwin. Хотя процесс преобразования модели BPwin в модель данных плохо формализуется и поэтому полностью не автоматизирован, PLATINUM technology предлагает удобный инструмент для облегчения построения модели данных на основе функциональной модели - механизм двунаправленной связи BPwin - ERwin. ERwin имеет два уровня представления модели - логический и физический. На логическом уровне данные не связаны с конкретной СУБД, поэтому могут быть наглядно представлены даже для неспециалистов. Физический уровень данных - это по существу отображение системного каталога, который зависит от конкретной реализации СУБД. ERwin позволяет проводить процессы прямого и обратного проектирования БД. Это означает, что по модели данных можно сгенерировать схему БД или автоматически создать модель данных на основе информации системного каталога. Кроме того, ERwin позволяет выравнивать модель и содержимое системного каталога после редактирования того либо другого. ERwin интегрируется с популярными средствами разработки клиентской части -PowerBuilder, Visual Basic, Delphi, что позволяет автоматически генерировать код приложения, который полностью готов к компиляции и выполнению. Для разных сред разработки реализована различная техника кодогенерации. Код для PowerBuilder генерируется непосредственно в среде ERwin, код для Visual Basic - с помощью add-in компонентов и библиотек, подключаемых в проект Visual Basic. ERwin не Поддерживает непосредственно кодогенерацию для Delphi. Код клиентского приложения для Delphi на основе модели данных ERwin можно сгенерировать с помощью MetaBASE - продукта фирмы gs-so/ (http://www.gs-soyt.com).


  1.  Описание динамики системы. Нотация IDEF3

План лекции

  •  Принципы моделирования динамики систем.
  •  Методологии моделирования динамики систем – сети Петри, цепи Маркова, диаграммы переходов состояний.
  •  Имитационное моделирование систем.
  •  Назначение и основные принципы нотации IDEF. Графические символы в IDEF3. Виды стрелок в IDEF3.

Введение

Для описания логики взаимодействия информационных потоков используется метод Workflow Diagramming, формализованный в виде стандарта IDEF3. IDEF3 представляет собой методологию моделирования, использующую графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью данных процессов. С помощью IDEF3 можно описать сценарий действий по выполнению задания или обработки события. Каждый сценарий сопровождается описанием процесса. Для получения исчерпывающего описания системы сценарий должен быть описан для каждой функции нижнего уровня DFD.

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

Основные символы IDEF3

Основные символы и виды связей диаграммы IDEF3 изображены на рисунке 12.

  1.  Основные символы и виды связей на диаграмме IDEF3

Единица работы (Unit Of Work, UOW), синоним терминов «Процесс», «Функция». При наименовании процессов следует соблюдать следующее правило: поскольку сценарий описывает цель и рамки модели, работы необходимо именовать отглагольным существительным либо фразой, содержащей такое существительное (например, «Изготовление изделия», «Осуществить сборку изделия»). Нумерация UOW ведется в таком же порядке, как в DFD.

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

Виды перекрестков в IDEF3


Существуют следующие виды перекрестков:


Наименование

Смысл при слиянии потоков

Смысл при разветвлении потоков

1

2

3

Асинхронное «И»

Все предшествующие процессы должны быть завершены

Будут запущены все последующие процессы

Синхронное «И»

Все предшествующие процессы должны быть завершены одновременно

Все последующие процессы будут запущены одновременно

Асинхронное «ИЛИ»

Как минимум один из предшествующих процессов должен быть завершен

Будет запущен как минимум один из последующих процессов

Синхронное «ИЛИ»

Один или несколько предшествующих процессов завершено одновременно

Один или несколько после-дующих процессов будут запущены одновременно

Исключающее «ИЛИ»

Завершен точно один из предшествующих процессов

Запустится точно один из последующих процессов

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

При внесении ссылочных объектов помимо их имени следует указывать тип ссылочного объекта.


Тип ссылочного объекта

Способ использования

OBJECT

Описывает участие в работе важного объекта

GOTO

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

UOB (Unit Of Behavior)

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

NOTE

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

ELAB (Elaboration)

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

Виды связей в IDEF3

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

  •  Старшая (Precedence). Связывает работы, отражает тот факт, что работа – источник должна закончиться прежде, чем начнется работа – приемник.
  •  Связь отношения (Relational Link). Служит для установления связи между двумя работами или между работой и ссылочным объектом.
  •  Поток объектов (Object Flow). Отражает тот факт, что объект используется более чем в одной работе. Например, может использоваться когда объект порождается в одной работе, а используется в другой.
  •  Пример диаграммы IDEF3

Пример диаграммы IDEF3 для процесса 1 «Получить пароль» приведен на рис. 13.

  1.  Спецификация процесса 1 «Получить пароль» в виде диаграммы IDEF3

Заключение


  1.  Постановка требований к данным. Словари данных. Моделирование данных в нотации IDEF1x. CASE-средство ERWin
    1.  План лекции
  •  Постановка требований к данным. Словари данных. Моделирование данных в нотации IDEF1x. CASE-средство ERWin
  •  Принципы моделирования данных. Методологии моделирования данных – иерархические, фреймовые, реляционные.
  •  Нотация Чена – Баркера.
  •  Словарь сущностей и атрибутов. Словарь стрелок модели.
  •  Нотация IDEF1x – назначение, основные принципы.
  •  Виды сущностей в IDEF1x.
  •  Виды связей в IDEF1x.
  •  Процедура нормализации в реляционных моделях.
  •  Соответствие между логической и физической моделями данных.
    1.  
    2.  Введение
    3.  Данные в AllFusion Modeling Suite описываются при помощи ER-диаграм в CASE-средстве ERWin. Вместе с тем, начинается описание данных уже при построении модели бизнес процессов. Выполняется это при помощи таких средств BPWin, как словарь стрелок (Arrow Dictionary) и словарь сущностей и атрибутов (Entity/Attribute Dictionary).
    4.  Словарь данных

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

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

  •  Примечание (Arrow Note).
  •  Определение (Arrow Definition).
  •  Имя автора стрелки (Author).

Приведем несколько описаний стрелок из примера банковской задачи:

Arrow Name

Arrow Note

Arrow Definition

Данные по балансу

Текущий баланс счета клиента

Деньги

Сумма выдаваемых денег должна быть кратна 5

Деньги, выдаваемые клиенту

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

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

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

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

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

Приведем примеры словаря сущностей и атрибутов для банковской задачи, рассмотренной в предыдущей лекции:

  •  Кредитная карта:
    •  Пароль.
      •  Лимит денег.
      •  Детали клиента.
    •  Протокол обслуживания:
      •  Обработанная документация.
      •  Денежная сумма.
      •  Данные по истории запроса.
    1.  Моделирование данных в нотации IDEF1x

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

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

Данный подход введен П.Ченом и усовершенствован Р. Баркером.

  1.  Базовые понятия ERD

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

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

Каждая сущность должна обладать следующими свойствами:

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

Связь (Relationship) – поименованная ассоциация между двумя сущностями, значимая для предметной области.

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

  1.  Виды сущностей в IDEF1x

В методологии IDEF1x используются следующие виды сущностей:

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

Зависимая от идентификаторов (просто зависимая), если однозначная идентификация экземпляра  сущности зависит от его отношения к другой сущности (рис. 14).

  1.  Виды сущностей в IDEF1x

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

  1.  Виды связей в IDEF1X

Связь может дополнительно определяться с помощью указания степени или мощности (количества экземпляров сущности-потомка, которое может существовать для каждого экземпляра сущности-родителя).

В IDEF1X могут быть выражены следующие мощности связей:

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

Кроме того связи подразделяются на:

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

Связь изображается линией, проводимой между сущностью-родителем и сущностью-потомком с точкой на конце линии у сущности-потомка. Мощность связи обозначается, как показано на рис. 15 (мощность по умолчанию - N).

  1.  Мощности связей

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

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

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

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

  1.  Идентифицирующая связь

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

  1.  Связь полной категории в IDEF1x

Также может существовать отношение неполной категоризации (сущности-категории составляют неполное множество потомков общей сущности):

  1.  Связь неполной категории в IDEF1x

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

  1.  Фрагмент схемы данных для банковской задачи
    1.  Нормализация схемы данных

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

Процедура нормализации схемы данных до третьей нормальной формы (3НФ) приведена на рис. 20. Расшифровка каждого из этапов приведена на рисунках 21-23



  1.  Процедура приведения схемы данных к третьей нормальной форме

  1.  Процедура приведения схемы данных к первой нормальной форме

  1.  Процедура перевода из 1НФ в 2НФ

  1.  Процедура перевода из 2НФ в 3НФ


Заключение


  1.  Постановка требований к интерфейсу ПО. Понятие Usability.

План лекции

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

Введение

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

  1.  Анализ трудовой деятельности пользователя, объединение бизнес-функций в роли.
  2.  Построение пользовательской модели данных, привязка объектов к ролям и формирование рабочих мест.
  3.  Формулировка требований к работе пользователя и выбор показателей оценки пользовательского интерфейса.
  4.  Разработка обобщенного сценария взаимодействия пользователя с программным модулем (функциональной модели) и его предварительная оценка пользователями и Заказчиком.
  5.  Корректировка и детализация сценария взаимодействия, выбор и дополнение стандарта (руководства) для построения прототипа.
  6.  Разработка макетов и прототипов ПИ и их оценка в деловой игре, выбор окончательного варианта.
  7.  Имплементация ПИ в коде, создание тестовой версии.
  8.  Разработка средств поддержки пользователя (пользовательские словари, подсказки, сообщения, помощь и пр.) и их встраивание в программный код.
  9.  Usability тестирование тестовой версии ПИ по набору раннее определенных показателей.
  10.  Подготовка пользовательской документации и разработка программы обучения.
    1.  Эргономические цели и показатели качества программного продукта 

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

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

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

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

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

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

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

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

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

Для того, чтобы разобраться в технологии решения задач пользователя, разработчику необходимо выяснить следующие моменты (исследуя деятельность пользователя):

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

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

Дизайн ПИ должен обеспечивать минимизацию усилий пользователя при выполнении работы и приводить к:

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

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

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

Формирование таких показателей происходит в процессе определения требований к ПИ при изучении следующих вопросов:

  1.  Что от пользователя требуется в первую очередь?
  2.  Сколько информации, требующей обработки, поступает пользователю за период времени?
  3.  Каковы требования к точности и скорости ввода информации?
  4.  На какие операции пользователь тратит больше всего времени?
  5.  Чем мы можем облегчить работу пользователя при решении типовых задач?

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

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

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

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

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

  1.  Проблемы, возникающие на этапе разработки прототипа GUI и варианты их решения
  2.  Учет особенностей устройств ввода/вывода информации, используемых пользователем, например:
  •  размер экрана монитора
  •  разрешение экрана
  •  цветовая палитра
  •  характеристики звуковой (качество воспроизведения речи) и видеокарты (скорость вывода при анимации)
  •  вид мыши (с роликом или без)
  •  тип клавиатуры (“прямая”, “косая”)
  •  необходимость дополнительного оборудования (штрих-декодера, светового пера сенсорного экрана и др.).
  1.  Специфика интерактивных элементов, связанная с выбором платформы, стандартных библиотек:
  •  программная организация ввода/вывода информации
  •  изменение и создание новых элементов форм (контролов)
  •  приобретение нестандартных библиотек у других фирм.
  1.  Выбор технологии и методов ведения диалога программы с пользователем:
  •  степень активности пользователя при взаимодействии (автоматический режим или перехват управления программой на себя, визарды, обеспечение доступа ко всем средствам интерфейса независимо от действий пользователя)
  •  степень учета ситуации (контекстные подсказки, меню дальнейших событий или объектов, запоминание типичных путей диалога)
  •  соответствие ожиданиям пользователя (предсказание, предобработка, предформатирование)
  •  устойчивость, терпимость к ошибкам пользователя путем исправления типичных ошибок
  •  дублирование вручную отдельных функций системы и дополнительные контрольные процедуры работы отдельных режимов
  •  настройка ПИ на различный уровень подготовки пользователя (образность или метафоричность предметной области в противовес сокращениям и горячим клавишам)
  •  степень адаптивности ПИ под предпочтения пользователя (изменение способа и порядка отображения, перекомпоновка экрана, выбор отдельных характеристик (стиля) и пр.)
  •  настройка ПИ на специфику задачи (новый формат данных, изменение набора объектов, дополнение атрибутов объектов)
  1.  Размещение информации и управляющих элементов в поле экрана, в окне. При композиции экрана необходимо учитывать ограниченные размеры пространства экрана, в связи с чем возникает задача оптимального расположения максимально возможного объема информации путем:
  •  логической увязкой данных в зависимости от алгоритма работы пользователя, а не ориентацией на структуру и последовательность физических таблиц данных
  •  определения уровня “детальности – обобщенности” вывода информации (нахождение компромисса между желанием вывести много записей одновременно и/или сразу увидеть детальную информацию по каждой из них)
  •  выделения важной информации на экране
  •  четкого определения основных и вспомогательных блоков информации
  •  определения статических полей на экране, а также полей, где информация периодически изменяется
  •  избегания перекрывающихся окон на экране
  •  применения принципов гармонии при компоновке экрана (симметрия, баланса масс, соблюдение пропорций, сочетание цветов)
  1.  Формирование обратной связи между пользователем и приложением:
  •  показ актуального состояния системы, режима работы системы (автономного, штатного, защищенного и пр.) и режима взаимодействия (например, отображение, редактирование или поиск данных).
  •  вывод отдельных, важных для рабочей операции данных и показателей
  •  отражение действий пользователя (нажатия клавиш, запуск процесса, динамика выполнения процесса, получение ожидаемого и иного результата)
  •  ясность и информативность сообщений системы.
  1.  Проектирование панелей меню и инструментов (toolbars) и выбор пунктов в них:
  •  логическая и смысловая группировка пунктов
  •  фиксированная позиция панелей на экране
  •  ограничение на ширину списка выборов и шагов (глубины) меню
  •  использование привычных названий, широко распространенных икон-пиктограмм, традиционных икон-символов и аккуратное введение сокращений
  •  размещение наиболее часто используемых пунктов (обычно в начале списка).
  1.  Разработка средств ориентации и навигации:
  •  легкость определения своего местонахождения и указание направления следования
  •  удобный переход от обобщенного взгляда до конкретных деталей (варьирование степени детализации рассматриваемых объектов)
  •  быстрый поиск в списке или таблице
  •  указание на дополнительно существующую информацию и способ ее получения
  •  использование средств листания и прокрутки.
  1.  Создание форм для ввода данных:
  •  использования одного или нескольких механизмов ввода в рамках режима (клавиатура, мышь, штрих-декодер, световое перо, др.)
  •  определение способов ввода данных (таблицы, списки, простая форма, меню и пр.)
  •  минимизация объема ввода
  •  выделение редактируемых обязательных и необязательных, а также нередактируемых полей
  •  использование механизмов быстрого ввода (по умолчанию, сокращения, с продолжением и пр.)
  •  Выделение введенной или отредактированной информации.
    1.  Принципы реализации пользовательского интерфейса 

Стилевая гибкость – возможность использовать различные интерфейсы с одним и тем же приложением, на практике реализуется в виде набора “skins”, для web-интерфейсов – с помощью таблицы стилей, в том числе возможность в выборе пользователем собственных установок ПИ (цвет, иконы, подсказки и пр.).

Совместное наращивание функциональности – возможность развивать приложение без разрушения (т.е. оставаясь в рамках) существующего интерфейса.

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

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

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

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

Заключение


  1.  Объектно-ориентированная методология проектирования ПО. Язык UML. CASE-средство Rational Rose. 
    1.  План лекции
  •  Предыстория. Математические основы (теория множеств, теория графов, семантические сети).
  •  Диаграммы структурного анализа.
  •  Основные этапы развития UML.
  •  Назначение языка UML.
  •  Общая структура языка UML.
  •  Пакеты в языке UML.
  •  Основные пакеты метамодели языка UML (основные элементы, элементы ядра, вспомогательные элементы, механизмы расширения, типы данных, элементы поведения, общее поведение, кооперации, варианты использования, автоматы, общие механизмы, управление моделями). Специфика описания метамодели языка UML.
  •  Особенности изображения диаграмм языка UML.
    1.  Методология объектно-ориентированного анализа и проектированияВведение

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

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

Для выделения или идентификации компонентов предметной области было предложено несколько способов и правил. Сам этот процесс получил название концептуализации предметной области. При этом под компонентой понимают некоторую абстрактную единицу, которая обладает функциональностью, т. е. может выполнять определенные действия, связанные с решением поставленных задач. На предварительном этапе концептуализации рекомендуется использовать так называемые CRC-карточки (Component, Responsibility, Collaborator— компонента, обязанность, сотрудники). Для каждой выделенной компоненты предметной области разрабатывается собственная CRC-карточка (рис. 24).

  1.  Общий вид CRC-карточки для описания компонентов предметной области

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

Разделение процесса разработки сложных программных приложений на отдельные этапы способствовало становлению концепции жизненного цикла программы. Под жизненным циклом (ЖЦ) программы понимают совокупность взаимосвязанных и следующих во времени этапов, начиная от разработки требований к ней и заканчивая полным отказом от ее использования. Стандарт ISO/IEC 12207, хотя и описывает общую структуру ЖЦ программы, не конкретизирует детали выполнения тех или иных этапов. Согласно принятым взглядам ЖЦ программы состоит из следующих этапов:

  •  Анализа предметной области и формулировки требований к программе
  •  Проектирования структуры программы
  •  Реализации программы в кодах (собственно программирования)
  •  Внедрения программы
  •  Сопровождения программы
  •  Отказа от использования программы

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

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

Этап программирования вряд ли нуждается в уточнении, поскольку является наиболее традиционным для программистов. Появление инструментариев быстрой разработки приложений (Rapid Application Development, RAD) позволило существенно сократить время, и затраты на выполнение этого этапа. Результатом данного этапа является программное приложение, которое обладает требуемой функциональностью и способно решать нужные задачи в конкретной предметной области.

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

Примечание: Рассматривая различные этапы ЖЦ программы, следует отметить одно важное обстоятельство. А именно, если появление RAD-инструментариев позволило существенно сократить сроки этапа программирования, то отсутствие соответствующих средств для первых двух этапов долгое время сдерживало процесс разработки приложений. Развитие методологии ООАП было направлено на автоматизацию второго, а затем и первого этапов ЖЦ программы.

Методология ООАП тесно связана с концепцией автоматизированной разработки программного обеспечения (Computer Aided Software Engineering, CASE). Появление первых CASE-средств было встречено с определенной настороженностью. Со временем появились как восторженные Отзывы об их применении, так и критические оценки их возможностей. Причин для столь противоречивых мнений было несколько. Первая из них заключается в том, что ранние CASE-средства были простой надстройкой над некоторой системой управления базами данных (СУБД). Хотя визуализация процесса разработки концептуальной схемы БД имеет немаловажное значение, она не решает проблем разработки приложений других типов.

Вторая причина имеет более сложную природу, поскольку связана с графической нотацией, реализованной в том или ином CASE-средстве. Если языки программирования имеют строгий синтаксис, то попытки предложить подходящий синтаксис для визуального представления концептуальных схем БД были восприняты далеко неоднозначно. Появилось несколько подходов, которые более подробно будут рассмотрены в главе 2. На этом фоне появление унифицированного языка моделирования (Unified Modeling Language, UML), который ориентирован на решение задач первых двух этапов ЖЦ программ, было воспринято с большим оптимизмом всем сообществом корпоративных программистов.

Примечание Аббревиатура UML допускает соответствующий перевод и последующее сокращение, но ввиду неудобочитаемости получающегося "УЯМ" было решено использовать исходный термин на всем протяжении книги. Частично это можно объяснить уже сложившейся традицией применения оригинальных терминов, таких как CASE, RAD, DLL, ISDN и целого ряда других.

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

  1.  Основные компоненты языка UML

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

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

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

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

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

  1.  Общая схема взаимосвязей моделей и представлений сложной системы в процессе объектно-ориентированного анализа и проектирования

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

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

  1.  Назначение языка UML 

Язык UML предназначен для решения следующих задач:

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

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

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

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

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

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

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

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

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

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

С другой стороны, язык UML должен обладать потенциальной возможностью реализации своих конструкций на том или ином языке программирования. Конечно, в первую очередь имеются в виду языки, поддерживающие концепцию ООП, такие как C++, Java, Object Pascal. Именно это свойство языка UML делает его современным средством решения задач моделирования сложных систем. В то же время, предполагается, что для программной поддержки конструкций языка UML могут быть разработаны специальные инструментальные CASE-средства. Наличие последних имеет принципиальное значение для широкого распространения и использования языка UML.

  1.  Описание языка UML должно включать в себя семантический базис для понимания общих особенностей ООАП.

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

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

  1.  Поощрять развитие рынка объектных инструментальных средств.

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

  1.  Способствовать распространению объектных технологий и соответствующих понятий ООАП.

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

  1.  Интегрировать в себя новейшие и наилучшие достижения практики ООАП.

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

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

Примечание

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

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

  1.  Общая структура языка UML 

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

Семантика языка UML. Представляет собой некоторую метамодель, которая определяет абстрактный синтаксис и семантику понятий объектного моделирования на языке UML.

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

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

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

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

Формальное описание самого языка UML основывается на некоторой общей иерархической структуре модельных представлений, состоящей из четырех уровней: 

  •  Мета-метамодель 
  •  Метамодель 
  •  Модель 
  •  Объекты пользователя

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

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

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

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

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

Конкретизация понятий модели происходит на уровне объектов. В настоящем контексте объект является экземпляром модели, поскольку содержит конкретную информацию относительно того, чему в действительности соответствуют те или иные понятия модели. Примером объекта может служить следующая запись в проектируемой базе данных: "Илья Петров, 30 лет, иллюзионист, ул. Невидимая, 10-20, 100-0000".

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

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

Метамодель языка UML имеет довольно сложную структуру, которая включает в себя порядка 90 метаклассов, более 100 метаассоциаций и почти 50 стереотипов, число которых возрастает с появлением новых версий языка. Чтобы справиться с этой сложностью языка UML, все его элементы организованы в логические пакеты. Поэтому рассмотрение языка UML на метамо-дельном уровне заключается в описании трех его наиболее общих логических блоков или пакетов: основные элементы, элементы поведения и общие механизмы.

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

  1.  Пакеты в языке UML 

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

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

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

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

Для графического изображения пакетов на диаграммах применяется специальный графический символ — большой прямоугольник с небольшим прямоугольником, присоединенным к левой части верхней стороны первого (рис. 3.2 а, б). Можно сказать, что визуально символ пакета напоминает пиктограмму папки в популярном графическом интерфейсе. Внутри большого прямоугольника может записываться информация, относящаяся к данному пакету. Если такой информации нет, то внутри большого прямоугольника записывается имя пакета, которое должно быть уникальным в пределах рассматриваемой модели (рис. 3.2, а). Если же такая информация имеется, то имя пакета записывается в верхнем маленьком прямоугольнике (рис. 26).

  1.  Графическое изображение пакета в языке UML

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

Перед именем пакета может помещаться строка текста, содержащая некоторое ключевое слово. Подобными ключевыми словами являются заранее определенные в языке UML слова, которые получили название стереотипов. Такими стереотипами для пакетов являются слова facade, framework, stub и topLevel. В качестве содержимого пакета могут выступать имена его отдельных элементов и их свойства, такие как видимость элементов за пределами пакета. Более подробно стереотипы и видимость элементов будут рассмотрены в последующих главах книги.

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

Одним из типов отношений между пакетами является отношение вложенности или включения пакетов друг в друга. С одной стороны, в языке UML это отношение может быть изображено без использования линий простым размещением одного пакета-прямоугольника внутри другого пакета-прямоугольника (рис. 3.3). Так, в данном случае пакет с именем ПакетЛ содержит в себе два подпакета: Пакет_2 и Пакет_3.

  1.  Графическое изображение вложенности пакетов друг в друга

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

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

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

  1.  Основные пакеты метамодели языка UML 

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

Эти пакеты в свою очередь делятся на отдельные подпакеты. Например, пакет Основные элементы состоит из подпакетов: Элементы ядра, Вспомогательные элементы, Механизмы расширения и типы данных (рис. 30). При этом пакет Элементы ядра описывает базовые понятия и принципы включения в структуру метамодели основных понятий языка, таких как метаклассы, метаассоциации и метаатрибуты. Пакет Вспомогательные элементы определяет дополнительные конструкции, которые расширяют базовые элементы для описания зависимостей, шаблонов, физических структур и элементов представлений. Пакет Механизмы расширения задает правила уточнения и расширения семантики базовых элементов моделей. Пакет Типы данных определяет основные структуры данных для языка UML.

  1.  Основные пакеты метамодели языка UML

  1.  Подпакеты пакета Основные элементы языка UML

  1.  Пакет Основные элементы 

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

  1.  Пакет Элементы ядра 

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

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

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

В этот пакет входят основные метаклассы языка UML: класс (Class), атрибут (Attribute), ассоциациях (Association), ассоциация-класс (AssociationClass), конец ассоциации (AssociationEnd), свойство поведения (BehavioralFeature), классификатор (Classifier), ограничение (Constraint), тип данных (DataType), зависимость (Dependency), элемент (Element), право на элемент (ElementOwnership), свойство (Feature), обобщение (Generalization), элемент отношения обобщения (GeneralizableElement), интерфейс (Interface), метод (Method), элемент модели (ModelElement), пространство имен (Namespace), операция (Operation), параметр (Parameter), структурное свойство (StructuralFeature), правила правильного построения выражений (Well-formedness rules).

  1.  Пакет Вспомогательные элементы 

Пакет Вспомогательные элементы является подпакетом пакета Основные элементы и специфицирует дополнительные конструкции языка UML, которые расширяют пакет Элементы ядра. Вспомогательные элементы обеспечивают понятийный базис для зависимостей, шаблонов, физических структур и элементов представлений. В этот пакет входят следующие метаклассы: связывание (Binding), комментарий (Comment), компонент (Component), узел (Node), презентация (Presentation), уточнение (Refinement), цепочка зависимостей (Trace), потребление (Usage), элемент представления (ViewElement), зависимость (Dependency), элемент модели (ModelElement), правила правильного построения выражений (Well-formedness rules). При этом три последних метакласса взяты из пакета Элементы ядра и используются для спецификации остальных.

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

  1.  Пакет Механизмы расширения 

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

Для этой цели в языке UML предусмотрены три механизма расширения, которые могут использоваться совместно или раздельно для определения новых элементов модели с отличающимися семантикой, нотацией и свойствами от специфицированных в метамодели языка UML элементов. Такими механизмами являются: ограничение (Constraint), стереотип (Stereotype) и помеченное значение (TaggedValue).

Таким образом, механизмы расширения языка UML предназначены для выполнения следующих задач:

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

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

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

  1.  Пакет Типы данных 

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

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

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

Для определения различных типов данных в языке UML используются как простые конструкции: целое число (Integer), строка (String), имя (Name), Булев (Boolean), время (Time), кратность (Multiplicity), тип видимости (VisibilityKind), диапазон кратности (MultiplicityRange), так и более сложные: выражение (Expression), булевское выражение (BooleanExpression), тип агрегирования (AggregationKind), тип изменения (ChangeableKind), геометрия (Geometry), отображение (Mapping), выражение-процедура (ProcedureExpression), тип псевдосостояния (PseudostateKind), выражение времени (TimeExpression), непрерываемый (Uninterpreted).

  1.  Пакет Элементы поведения 

Этот пакет является самостоятельной компонентой языка UML и, как следует из его названия, специфицирует динамику поведения в нотации UML. Пакет Элементы поведения состоит из четырех подпакетов: Общее поведение, Кооперации, Варианты использования и Автоматы (рис. 3.7). Ниже дается краткая характеристика каждого из этих подпакетов.

  1.  Подпакеты пакета Элементы поведения языка UML

  1.  Пакет Общее поведение 

Пакет Общее поведение является наиболее фундаментальным из всех подпакетов и определяет базовые понятия ядра, необходимые для всех элементов поведения. В этом пакете специфицирована семантика для динамических элементов, которые включены в другие подпакеты элементов поведения. В пакет Общее поведение входит достаточно большое число элементов, таких как объект (Object), действие (Action), последовательность действий (ActionSequence), аргумент (Argument), экземпляр (Instance), исключение (Exception), связь (Link), сигнал (Signal), значение данных (DataValue), связь атрибутов (AttributeLink), действие вызова (CallAction), действие создания (CreateAction), действие уничтожения (DestroyAction).

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

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

  1.  Пакет Кооперации 

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

В частности, в пакет Кооперации входят элементы: кооперация (Collaboration), взаимодействие (Interaction), сообщение (Message), роль ассоциации (AssociationRole), роль классификатора (ClassifierRole), роль конца ассоциации (AssociationEndRole). Как можно догадаться из названия пакета, его элементы непосредственно используются при построении диаграмм кооперации. Понятие кооперации имеет важное значение для представления взаимодействия элементов модели с точки зрения классификаторов и ассоциаций. Особенности их применения будут более детально рассмотрены при изучении диаграммы кооперации.

  1.  Пакет Варианты использования 

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

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

В пакет Варианты использования кроме уже упомянутых элементов актер (Actor) и вариант использования (UseCase) входят: расширение (Extension), точка расширения (ExtensionPoint), включение (Include) и экземпляр варианта использования (UseCaselnstance). Более подробно некоторые из этих понятий будут рассмотрены при описании диаграмм вариантов использования.

  1.  Пакет Автоматы 

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

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

В пакет Автоматы входят элементы: состояние (State), переход (Transition), событие (Event), автомат (StateMachine), простое состояние (SimpleState), составное состояние CompositeState, псевдосостояние (PseudoState), конечное состояние (FinalState) и некоторые другие.

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

Более подробно понятия этого пакета будут рассмотрены при изучении диаграмм состояний.

  1.  Пакет Общие механизмы 

В этом пакете определены общие механизмы, которые применимы ко всем моделям UML. Пакет состоит из единственного подпакета управления моделями (рис. 3.8). Этот подпакет служит для спецификации способов организации элементов в модели, пакеты и подсистемы. Кратко рассмотрим основные особенности данного подпакета.

  1.  Состав пакета Общие механизмы

  1.  Пакет Управление моделями 

Пакет Управление моделями (Model Management) специфицирует базовые элементы языка UML, которые необходимы для формирования всех модельных представлений. Именно в нем определяется семантика модели (Model), пакета (Package) и подсистемы (Subsystem). Эти элементы служат своеобразными контейнерами для группировки других элементов модели.

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

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

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

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

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

  1.  Графическое изображение подсистемы в языке UML

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

  1.  Специфика описания метамодели языка UML 

Метамодель языка UML описывается на некотором полуформальном языке с использованием трех видов представлений:

  •  Абстрактного синтаксиса
  •  Правил правильного построения выражений
  •  Семантики

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

Правила правильного построения выражений используются для задания дополнительных ограничений или свойств, которыми должны обладать те или иные компоненты модели. Поскольку исходным понятием ООП является понятие класса, его общими свойствами должны обладать все экземпляры, которые в этом смысле должны быть инвариантны друг другу. Для задания этих инвариантных свойств классов и отношений необходимо использовать специальные выражения некоторого формального языка, в рамках UML получившего название языка объектных ограничений (Object Constraint Language, ОСЬ). Хотя язык ОСЬ и использует естественный язык для формулировки правил правильного построения выражений, особенности его применения являются темой самостоятельного обсуждения. Основные особенности языка ОСЬ рассмотрены в приложении.

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

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

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

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

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

  •  Явно указывать в тексте экземпляр некоторого метакласса. Речь идет о том, что в естественной речи мы часто опускаем слово "пример" или "экземпляр", говоря просто "класс". Так, фразу "Атрибут возраст класса сотрудник имеет значение 30 лет" следует записать более точно, а именно: "Атрибут возраст экземпляра класса сотрудник имеет значение 30 лет".
  •  В каждый момент времени используется только то значение слова, которое при Основные компоненты языка UMLписано имени соответствующей конструкции языка UML. Все дополнительные особенности семантики должны быть указаны явным образом без каких бы то ни было неявных предположений.
  •  Термины языка UML могут включать только один из допустимых префиксов, таких как под-, супер- или мета-. При этом сам термин с префиксом записывается одним словом.

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

  •  Если используются ссылки на конструкции языка UML, а не на их представления в метамодели, следует применять обычный текст без какого бы то ни было выделения.
  •  Имена метаклассов являются элементом нотации языка UML и представляют собой существительное и, возможно, присоединенное к нему прилагательное. В этом случае имя метакласса на английском записывается одним словом с выделением каждой составной части имени заглавной буквой (например, ModelElement, StructuralFeature).
  •  Имена метаассоциаций и ассоциаций классов записываются аналогичным образом (например, ElementReference).
  •  Имена других элементов языка UML также записываются одним словом, но должны начинаться с маленькой буквы (например, ownedElement, allContents).
  •  Имена метаатрибутов, которые принимают булевы значения, всегда начинаются с префикса "is" (например, isAbstract).
  •  Перечислимые типы должны всегда заканчиваться словом "Kind" (например, AggregationKind).
  •  При ссылках в тексте на метаклассы, метаассоциаций, метаатрибуты и т. д. должны всегда использоваться в точности те их имена, которые указаны в модели.
  •  Имена стандартных обозначений (стереотипов) заключаются в кавычки и начинаются со строчной буквы (например, "type").

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

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

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

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

  •  Диаграмма вариантов использования (use case diagram)
  •  Диаграмма классов (class diagram)
  •  Диаграммы поведения (behavior diagrams)
    •  Диаграмма состояний (statechart diagram)
    •  Диаграмма деятельности (activity diagram)
    •  Диаграммы взаимодействия (interaction diagrams) 
      •  Диаграмма последовательности (sequence diagram) 
      •  Диаграмма кооперации (collaboration diagram) 
  •  Диаграммы реализации (implementation diagrams)
    •  Диаграмма компонентов (component diagram)
    •  Диаграмма развертывания (deployment diagram)

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

  1.  Диаграмма вариантов использования.
  2.  Диаграмма классов.
  3.  Диаграмма состояний.
  4.  Диаграмма деятельности.
  5.  Диаграмма последовательности.
  6.  Диаграмма кооперации.
  7.  Диаграмма компонентов
  8.  Диаграмма развертывания

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

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

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

  1.  Интегрированная модель сложной системы в нотации UML

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

  1.  Особенности изображения диаграмм языка UML 

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

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

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

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

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

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

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

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

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

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

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

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

Процесс построения отдельных типов диаграмм имеет свои особенности, которые тесно связаны с семантикой элементов этих диаграмм. Сам процесс ООАП в контексте языка UML получил специальное название — рациональный унифицированный процесс (Rational Unified Process, RUP). Концепция RUP и основные его элементы разработаны А. Джекобсоном в ходе его работы над языком UML.

Примечание: При дословном переводе термина RUP теряется некоторая дополнительная семантическая окраска, связанная с двусмысленным толкованием английского Rational. Речь идет о другом варианте перевода — унифицированный процесс от фирмы Rational Software, сотрудниками которой являются с некоторых пор его разработчики, включая упомянутого выше А. Джекобсона.

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

  1.  Объектно-ориентированные CASE-средства (Rational Rose) 

Rational Rose - CASE-средство фирмы Rational Software Corporation (США) - предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации [21]. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанная ими универсальная нотация для моделирования объектов (UML - Unified Modeling Language) претендует на роль стандарта в области объектно-ориентированного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro). Основной вариант - Rational Rose/C++ - позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на С++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах.

  1.  Структура и функции 

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

В составе Rational Rose можно выделить 6 основных структурных компонент: репозиторий, графический интерфейс пользователя, средства просмотра проекта (browser), средства контроля проекта, средства сбора статистики и генератор документов. К ним добавляются генератор кодов (индивидуальный для каждого языка) и анализатор для С++, обеспечивающий реинжиниринг - восстановление модели проекта по исходным текстам программ.

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

Средства автоматической генерации кодов программ на языке С++, используя информацию, содержащуюся в логической и физической моделях проекта, формируют файлы заголовков и файлы описаний классов и объектов. Создаваемый таким образом скелет программы может быть уточнен путем прямого программирования на языке С++. Анализатор кодов С++ реализован в виде отдельного программного модуля. Его назначение состоит в том, чтобы создавать модули проектов в форме Rational Rose на основе информации, содержащейся в определяемых пользователем исходных текстах на С++. В процессе работы анализатор осуществляет контроль правильности исходных текстов и диагностику ошибок. Модель, полученная в результате его работы, может целиком или фрагментарно использоваться в различных проектах. Анализатор обладает широкими возможностями настройки по входу и выходу. Например, можно определить типы исходных файлов, базовый компилятор, задать, какая информация должна быть включена в формируемую модель и какие элементы выходной модели следует выводить на экран. Таким образом, Rational Rose/С++ обеспечивает возможность повторного использования программных компонент.

В результате разработки проекта с помощью CASE-средства Rational Rose формируются следующие документы:

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

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

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

  1.  Взаимодействие с другими средствами и организация групповой работы 

Rational Rose интегрируется со средством PVCS для организации групповой работы и управления проектом и со средством SoDA - для документирования проектов. Интеграция Rational Rose и SoDA обеспечивается средствами SoDA.

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

Для управляемой подмодели предусмотрены операции:

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

Наиболее эффективно групповая работа организуется при интеграции Rational Rose со специальными средствами управления конфигурацией и контроля версий (PVCS). В этом случае защита от модификации устанавливается на все управляемые подмодели, кроме тех, которые выделены конкретному разработчику. В этом случае признак защиты от записи устанавливается для файлов, которые содержат подмодели, поэтому при считывании "чужих" подмоделей защита их от модификации сохраняется и случайные воздействия окажутся невозможными.

  1.  Среда функционирования 

Rational Rose функционирует на различных платформах: IBM PC (в среде Windows), Sun SPARC stations (UNIX, Solaris, SunOS), Hewlett-Packard (HP UX), IBM RS/6000 (AIX).

Заключение


  1.  Описание функциональных требований к ПО при помощи диаграмм вариантов использования в UML


  1.  План лекции
  •  Графические элементы модели Use-Case: варианты использования, актеры, интерфейсы, примечания.
  •  Отношения на диаграмме вариантов использования (ассоциации, расширения, обобщения, включения).
  •  Рекомендации по разработке диаграмм вариантов использования

Введение

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

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

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

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

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

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

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

  1.  Вариант использования 

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

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

  1.  Графическое обозначение варианта использования

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

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

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

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

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

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

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

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

  1.  Актеры 

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

  1.  Графическое обозначение актера

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

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

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

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

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

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

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

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

  1.  Интерфейсы 

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

На диаграмме вариантов использования интерфейс изображается в виде маленького круга, рядом с которым записывается его имя (рис. 37, а). В качестве имени может быть существительное, которое характеризует соответствующую информацию или сервис (например, "датчик", "сирена", "видеокамера"), но чаще строка текста (например, "запрос к базе данных", "форма ввода", "устройство подачи звукового сигнала"). Если имя записывается на английском, то оно должно начинаться с заглавной буквы I, например, ISecurelnformation, ISensor (рис. 37, б).

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

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

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

  1.  Графическое изображение взаимосвязей интерфейсов с вариантами использования

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

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

  1.  Примечания 

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

Графически примечания обозначаются прямоугольником с "загнутым" верхним правым уголком (рис. 39). Внутри прямоугольника содержится текст примечания. Примечание может относиться к любому элементу диаграммы, в этом случае их соединяет пунктирная линия. Если примечание относится к нескольким элементам, то от него проводятся, соответственно, несколько линий. Разумеется, примечания могут присутствовать не только на диаграмме вариантов использования, но и на других канонических диаграммах.

  1.  Примеры примечаний в языке UML

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

  1.  Отношения на диаграмме вариантов использования 

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

В языке UML имеется несколько стандартных видов отношений между актерами и вариантами использования:

  •  Отношение ассоциации (association relationship)
  •  Отношение расширения (extend relationship)
  •  Отношение обобщения (generalization relationship)
  •  Отношение включения (include relationship)

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

  1.  Отношение ассоциации 

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

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

  1.  Пример графического представления отношения ассоциации между актером и вариантом использования

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

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

Для диаграмм вариантов использования наиболее распространенными являются четыре основные формы записи кратности отношения ассоциации:

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

Примером этой формы записи кратности ассоциации является указание кратности "1" для актера "Клиент банка" (рис. 40). Эта запись означает, что каждый экземпляр варианта использования "Оформить кредит для клиента банка" может иметь в качестве своего элемента единственный экземпляр актера "Клиент банка". Другими словами, при оформлении кредита в банке необходимо иметь в виду, что каждый конкретный кредит оформляется на единственного клиента этого банка.

  •  Два целых неотрицательных числа, разделенные двумя точками и записанные в виде: "первое число .. второе число". Данная запись в языке UML соответствует нотации для множества или интервала целых чисел, которая применяется в некоторых языках программирования для обозначения границ массива элементов. Эту запись следует понимать как множество целых неотрицательных чисел, следующих в последовательно возрастающем порядке:  {первое_число, первое_число+1, первое_число+2, ..., второе_число]. Очевидно, что первое число должно быть строго меньше второго числа в арифметическом смысле, при этом первое число может быть равно 0.

Пример такой формы записи кратности ассоциации — "1..5". Эта запись означает, что количество отдельных экземпляров данного компонента, которые могут выступать в качестве элементов данной ассоциации, равно некоторому заранее неизвестному числу из множества целых чисел {1, 2, 3, 4, 5}. Эта ситуация может иметь место, например, в случае рассмотрения в качестве актера — клиента банка, а в качестве варианта использования — процедуру открытия счета в банке. При этом количество отдельных счетов каждого клиента в данном банке, исходя из некоторых дополнительных соображений, может быть не больше 5. Эти дополнительные соображения как раз и являются внешними требованиями по отношению к проектируемой системе и определяются ее заказчиком на начальных этапах ООАП.

  •  Два символа, разделенные двумя точками. При этом первый из них является целым неотрицательным числом или 0, а второй — специальным символом "*". Здесь символ "*"обозначает произвольное конечное целое неотрицательное число, значение которого неизвестно на момент задания соответствующего отношения ассоциации.

Пример такой формы записи кратности ассоциации — "2..*". Запись означает, что количество отдельных экземпляров данного компонента, которые могут выступать в качестве элементов данной ассоциации, равно некоторому заранее неизвестному числу из подмножества натуральных чисел: {2, 3, 4}.

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

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

Если кратность отношения ассоциации не указана, то по умолчанию принимается ее значение, равное 1.

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

  1.  Отношение расширения 

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

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

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

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

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

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

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

  1.  Графическое изображение отношения расширения с примечаниями условий выполнения вариантов использования

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

  1.  Отношение обобщения 

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

  1.  Пример графического изображения отношения обобщения между вариантами использования

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

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

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

  1.  Пример графического изображения отношения обобщения между актерами

  1.  Отношение включения 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1.  Фрагмент диаграммы вариантов использования, который в неявном виде присутствует на уточненной диаграмме с отношением ассоциации между отдельными компонентами

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


  1.  Проектирование внутренней структуры приложений при помощи диаграмм классов в UML

План лекции

  •  Класс (имя класса, атрибуты класса, операции класса).
  •  Отношения между классами (зависимости, ассоциации, агрегации, композиции, обобщения).
  •  Интерфейсы.
  •  Объекты.
  •  Шаблоны или параметризованные классы.
  •  Рекомендации по построению диаграмм классов.

Введение

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

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

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

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

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

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

  1.  Класс 

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

  1.   Графическое изображение класса на диаграмме классов

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

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

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

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

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

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

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

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

Примечание :

В некоторых случаях необходимо явно указать, к какому пакету относится тот или иной класс. Для этой цели используется специальный символ разделитель — двойное двоеточие "::". Синтаксис строки имени класса в этом случае будет следующий <Имя_пакета>::<Имя_класса>. Другими словами, перед именем класса должно быть явно указано имя пакета, к которому его следует отнести. Например, если определен пакет с именем "Банк", то класс "Счет" в этом банке может быть записан в виде: "Банк::Счет".

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

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

<квантор видимости><имя атрибута>[кратность]:

<тип атрибута> = <исходное значение>{строка-свойство}

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

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

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

Примечание

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

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

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

[нижняя_граница1 .. верхняя_граница1, нижняя_граница2.. верхняя_грашца2, ..., нuжняя_гpaнuцak .. верхняя_границаk],

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

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

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

  •  [0..1] означает, что кратность атрибута может принимать значение О или 1. При этом 0 означает отсутствие значения для данного атрибута.
  •  [0..*] означает, что кратность атрибута может принимать любое положительное целое значение большее или равное 0. Эта кратность может быть записана короче в виде простого символа — [*].
  •  [1.:*] означает, что кратность атрибута может принимать любое положительное целое значение большее или равное 1.
  •  [1..5] означает, что кратность атрибута может принимать любое значение из чисел: 1, 2, 3, 4, 5.
  •  [1..3,5,7] означает, что кратность атрибута может принимать любое значение из чисел: 1, 2, 3, 5, 7.
  •  [1..3,7.. 10] означает, что кратность атрибута может принимать любое значение из чисел: 1, 2, 3, 7, 8, 9, 10.
  •  [1..3,7..*] означает, что кратность атрибута может принимать любое значение из чисел: 1, 2, 3, а также любое положительное целое значение большее или равное 7.

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

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

Можно привести следующие примеры задания имен и типов атрибутов классов:

  •  цвет: Соlоr — здесь цвет является именем атрибута, Color — именем типа данного атрибута. Указанная запись может определять традиционно используемую RGB-модель (красный, зеленый, синий) для представления цвета. В этом случае имя типа Color как раз и характеризует семантическую конструкцию, которая применяется в большинстве языков программирования для представления цвета.
  •  имя_сотрудника [1..2] : String — здесь имя_сотрудника является именем атрибута, который служит для представления информации об имени, а возможно, и отчестве конкретного сотрудника. Тип атрибута String (Строка) как раз и указывает на тот факт, что отдельное значение имени представляет собой строку текста из одного или двух слов (например, "Кирилл" или "Дмитрий Иванович"). Поскольку во многих языках программирования существует тип данных String, использование соответствующего англоязычного термина не вызывает недоразумения у большинства программистов. Однако, хотя в языке UML все термины даются в англоязычном представлении, использование в качестве типа атрибута Строка в данной ситуации не исключается и определяется только соображениями удобства.
  •  видимость:Boolean — здесь видимость есть имя абстрактного атрибута (курсив здесь не случаен), который может характеризовать наличие визуального представления соответствующего класса на экране монитора. В этом случае тип Boolean означает, что возможными значениями данного атрибута является одно из двух логических значений: истина (true) или ложь (false). При этом значение истина может соответствовать наличию графического изображения на экране монитора, а значение ложь — его отсутствию, о чем дополнительно указывается в пояснительном тексте. Поскольку кратность атрибута видимость не указана, она принимает значение 1 по умолчанию. В этой ситуации англоязычное имя типа атрибута вполне оправдано наличием соответствующего базового типа в языках программирования. Абстрактный характер данного атрибута обозначается курсивным текстом в записи данного атрибута.
  •  форма:Многоугольник — здесь имя атрибута форма может характеризовать такой класс, который является геометрической фигурой на плоскости. В этом случае тип атрибута Многоугольник указывает на тот факт, что отдельная геометрическая фигура может иметь форму треугольника, прямоугольника, ромба, пятиугольника и любого другого многоугольника, но не окружности или эллипса. Вполне очевидно, что в данной ситуации использование соответствующего англоязычного термина вряд ли целесообразно, поскольку тип Многоугольник не является базовым для языков программирования.

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

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

  •  цвет:Соlоr = (255, 0, 0) — в RGB-модели цвета это соответствует чистому красному цвету в качестве исходного значения для данного атрибута.
  •  имя_сотрудника[1..2]:String = Иван Иванович — возможно, это нетипичный случай, который, скорее, соответствует ситуации имя_руководителя[2]:81пп§ = Иван Иванович.
  •  видимость:Вооlеаn = истина — может соответствовать ситуации, когда в момент создания экземпляра класса создается видимое на экране монитора окно, соответствующее данному объекту.
  •  форма:Многоугольник = прямоугольник — вряд ли требует комментариев, поскольку здесь речь идет о геометрической форме создаваемого объекта.

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

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

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

Строка-свойство служит для указания значений атрибута, которые не могут быть изменены в программе при работе с данным типом объектов. Фигурные скобки как раз и обозначают фиксированное значение соответствующего атрибута для класса в целом, которое должны принимать все вновь создаваемые экземпляры класса без исключения. Это значение принимается за исходное значение атрибута, которое не может быть переопределено в последующем. Отсутствие строки-свойства по умолчанию трактуется так, что значение соответствующего атрибута может быть изменено в программе. Например, строка-свойство в записи атрибута заработная_плата:Currency = = {$500} может служить для обозначения фиксированной заработной платы для каждого объекта класса "Сотрудник" определенной должности в некоторой организации. С другой стороны, запись данного атрибута в виде зара-ботная_плата: Currency = $500 означает уже нечто иное, а именно — при создании нового экземпляра Сотрудник (аналогия — прием на работу нового сотрудника) для него устанавливается по умолчанию заработная плата в $500. Однако для отдельных сотрудников могут быть сделаны исключения как в большую, так и в меньшую сторону, о чем необходимо позаботиться дополнительно в программе.

  1.  Операция 

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

<квантор видимости><имя операции>(список параметров):

<выражение типа возвращаемого значения>{строка-свойство}

Квантор видимости, как и в случае атрибутов класса, может принимать одно из трех возможных значений и, соответственно, отображается при помощи специального символа. Символ "+" обозначает операцию с областью видимости типа общедоступный (public). Символ "#" обозначает операцию с областью видимости типа защищенный (protected). И, наконец, символ "-" используется для обозначения операции с областью видимости типа закрытый (private).

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

Примечание

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

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

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

<вид параметра><имя параметра>:<выражение типа>=<значение параметра по умолчанию>.

Здесь вид параметра — есть одно из ключевых слов in, out или inout со значением in по умолчанию, в случае если вид параметра не указывается. Имя параметра есть идентификатор соответствующего формального параметра. Выражение типа является зависимой от конкретного языка программирования спецификацией типа возвращаемого значения для соответствующего формального параметра. Наконец, значение по умолчанию в общем случае представляет собой выражение для значения формального параметра, синтаксис которого зависит от конкретного языка программирования и подчиняется принятым в нем ограничениям.

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

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

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

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

Для повышения производительности системы одни операции могут выполняться параллельно или одновременно, а другие — только последовательно. В этом случае для указания параллельности выполнения операции используется строка-свойство вида "{concurrency = имя}", где имя может принимать одно из следующих значений: последовательная (sequential), параллельная (concurrent), охраняемая (guarded). При этом придерживаются следующей семантики для данных значений:

  •  последовательная (sequential) — для данной операции необходимо обеспечить ее единственное выполнение в системе, одновременное выполнение других операций может привести к ошибкам или нарушениям целостности объектов класса.
  •  параллельная (concurrent) — данная операция в силу своих особенностей может выполняться параллельно с другими операциями в системе, при этом параллельность должна поддерживаться на уровне реализации модели.
  •  охраняемая (guarded) — все обращения к данной операции должны быть строго упорядочены во времени с целью сохранения целостности объектов данного класса, при этом могут быть приняты дополнительные меры по контролю исключительных ситуаций на этапе ее выполнения.

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

Появление сигнатуры операции на самом верхнем уровне объявляет эту операцию на весь класс, при этом данная операция наследуется всеми потомками данного класса. Если в некотором классе операция не выполняется (т. е. некоторый метод не применяется), то такая операция может быть помечена как абстрактная "{abstract}". Другой способ показать абстрактный характер операции — записать ее сигнатуру курсивом. Подчиненное появление записи данной операции без свойства {абстрактная} указывает на тот факт, что соответствующий класс-потомок может выполнять данную операцию в качестве своего "метода.

Если для некоторой операции необходимо дополнительно указать особенности ее реализации (например, алгоритм), то это может быть сделано в форме примечания, записанного в виде текста, который присоединяется к записи операции в соответствующей секции класса. Если объекты класса принимают и реагируют на некоторый сигнал, то запись данной операции помечается ключевым словом "сигнал" ("signal"). Это обозначение равнозначно обозначению некоторой операции. Реакция объекта на прием сигнала может быть показана в виде некоторого автомата. Кроме других случаев эта нотация может быть использована, чтобы показать реакцию объектов класса на ошибочные ситуации или исключения, которые могут моделироваться как сигналы или сообщения.

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

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

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

  •  +создать() — может обозначать абстрактную операцию по созданию отдельного объекта класса, которая является общедоступной и не содержит формальных параметров. Эта операция не возвращает никакого значения после своего выполнения.
  •  +нарисовать(форма: Многоугольник = прямоугольник, цвет_заливки: Color = (О, О, 255)) — может обозначать операцию по изображению на экране монитора прямоугольной области синего цвета, если не указываются другие значения в качестве аргументов данной операции.
  •  запросить_счет_клиента(номер_счета:1п1е§ег):Сиггепсу — обозначает операцию по установлению наличия средств на текущем счете клиента банка. При этом аргументом данной операции является номер счета клиента, который записывается в виде целого числа (например, "123456"). Результатом выполнения этой операции является некоторое число, записанное в принятом денежном формате (например, $1,500.00).
  •  выдать_сообщение():{"Ошибка деления на ноль"} — смысл данной операции не требует пояснения, поскольку содержится в строке-свойстве операции. Данное сообщение может появиться на экране монитора в случае попытки деления некоторого числа на ноль, что недопустимо.
    1.  Отношения между классами 

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

  •  Отношение зависимости (dependency relationship)
  •  Отношение ассоциации (association relationship)
  •  Отношение обобщения (generalization relationship)
  •  Отношение реализации (realization relationship)

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

  1.  Отношение зависимости 

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

Отношение зависимости графически изображается пунктирной линией между соответствующими элементами со стрелкой на одном из ее концов ("—>" или "<—"). На диаграмме классов данное отношение связывает отдельные классы между собой, при этом стрелка направлена от класса-клиента зависимости к независимому классу или классу-источнику (рис. 52). На данном рисунке изображены два класса: Класс_А и Класс_Б, при этом Класс_Б является источником некоторой зависимости, а Класс_А — клиентом этой зависимости.

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

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

  1.  Графическое представление зависимости между классом-клиентом (Класс_С) и классами-источниками (Класс_Л и Класс_Б)

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

  •  "access" — служит для обозначения доступности открытых атрибутов и операций класса-источника для классов-клиентов;
  •  "bind" — класс-клиент может использовать некоторый шаблон для своей последующей параметризации;
  •  "derive" — атрибуты класса-клиента могут быть вычислены по атрибутам класса-источника;
  •  "import" — открытые атрибуты и операции класса-источника становятся частью класса-клиента, как если бы они были объявлены непосредственно в нем;
  •  "refine" — указывает, что класс-клиент служит уточнением класса-источника в силу причин исторического характера, когда появляется дополнительная информация в ходе работы над проектом.

Примечание

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

  1.  Отношение ассоциации 

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

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

В качестве простого примера отношения бинарной ассоциации рассмотрим отношение между двумя классами — классом "Компания" и классом "Сотрудник" (рис. 54). Они связаны между собой бинарной ассоциацией Работа, имя которой указано на рисунке рядом с линией ассоциации. Для данного отношения определен порядок следования классов, первым из которых является класс "Сотрудник", а вторым — класс "Компания". Отдельным примером или экземпляром данного отношения может являться пара значений (Петров И. И., "Рога&Копыта"). Это означает, что сотрудник Петров И. И. работает в компании "Рога&Копыта".

  1.  Графическое изображение отношения бинарной ассоциации между классами

Тернарная ассоциация и ассоциации более высокой арности в общем случае называются N-арной ассоциацией (читается — "эн арная ассоциация"). Такая ассоциация связывает некоторым отношением 3 и более классов, при этом один класс может участвовать в ассоциации более чем один раз. Класс ассоциации имеет определенную роль в соответствующем отношении, что может быть явно указано на диаграмме. Каждый экземпляр N-арной ассоциации представляет собой N-арный кортеж значений объектов из соответствующих классов. Бинарная ассоциация является частным случаем N-арной ассоциации, когда значение N=2, и имеет свое собственное обозначение.

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

Порядок классов в N-арной ассоциации, в отличие от порядка множеств в отношении, на диаграмме не фиксируется. Некоторый класс может быть присоединен к ромбу пунктирной линией. Это означает, что данный класс обеспечивает поддержку свойств соответствующей N-арной ассоциации, а сама N-арная ассоциация имеет атрибуты, операции и/или ассоциации. Другими словами, такая ассоциация, в свою очередь, является классом с соответствующим обозначением в виде прямоугольника и является самостоятельным элементом языка UML — ассоциацией-классом (Association Class). N-арная ассоциация не может содержать символ агрегации ни для какой из своих ролей.

В качестве примера конкретной тернарной ассоциации рассмотрим отношение между тремя классами: "Футбольная команда", "Год" и "Игра". Данная ассоциация указывает на наличие отношения между этими тремя классами, которое может представлять информацию об играх футбольных команд в национальном чемпионате в течение нескольких последних лет (рис. 55).

Как уже упоминалось, отдельный класс ассоциации имеет собственную роль в отношении. Эта роль может быть изображена графически на диаграмме классов. С этой целью в языке UML вводится в рассмотрение специальный элемент — конец ассоциации (Association End), который графически соответствует точке соединения линии ассоциации с отдельным классом. Конец ассоциации является частью ассоциации, но не класса. Каждая ассоциация имеет два или больше концов ассоциации. Наиболее важные свойства ассоциации указываются на диаграмме рядом с этими элементами ассоциации и должны перемешаться вместе с ними.

  1.  Графическое изображение тернарной ассоциации между тремя классами

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

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

Так, для рассмотренного ранее примера (см. рис. 54) кратность "1" для класса "Компания" означает, что каждый сотрудник может работать только в одной компании. Кратность "1..*" для класса "Сотрудник" означает, что в каждой компании могут работать несколько сотрудников, общее число которых заранее неизвестно и ничем не ограничено. Заметим, что вместо кратности "1..*" записать только символ "*" нельзя, поскольку последний означает кратность "0..*". Для данного примера это означало бы, что отдельные компании могут совсем не иметь сотрудников в своем штате. Но такая кратность вполне приемлема в других ситуациях, как это видно из рассмотренного выше примера (рис. 55).

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

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

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

  1.  Графическое изображение исключающей ассоциации между тремя классами

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

  1.  Отношение агрегации 

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

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

Примечание

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

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

В качестве примера отношения агрегации рассмотрим взаимосвязь типа "часть-целое", которая имеет место между сущностью "Грузовой автомобиль" и такими компонентами, как "Двигатель", "Шасси", "Кабина", "Кузов". Не претендуя на точное соответствие терминологии данной предметной области, нетрудно представить себе, что грузовой автомобиль состоит из двигателя, шасси, кабины и кузова. Именно это отношение между классом "Грузовой_автомобиль" и классами "Двигатель", "Шасси", "Кабина", "Кузов" описывает отношение агрегации.

Графически отношение агрегации изображается сплошной линией, один из концов которой представляет собой незакрашенный внутри ромб. Этот ромб указывает на тот из классов, который представляет собой "целое". Остальные классы являются его "частями" (рис. 57).

  1.  Графическое изображение отношения агрегации в языке UML

Еще одним примером отношения агрегации может служить известное каждому из читателей деление персонального компьютера на составные части: системный блок, монитор, клавиатуру и мышь. Используя обозначения языка UML, компонентный состав ПК можно представить в виде соответствующей диаграммы классов (рис. 58), которая в данном случае иллюстрирует отношение агрегации.

 

  1.  Диаграмма классов для иллюстрации отношения агрегации на примере ПК

  1.  Отношение композиции 

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

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

Графически отношение композиции изображается сплошной линией, один из концов которой представляет собой закрашенный внутри ромб. Этот ромб указывает на тот из классов, который представляет собой класс-композицию или "целое". Остальные классы являются его "частями" (рис. 59).

  1.  Графическое изображение отношения композиции в языке UML

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

  1.  Диаграмма классов для иллюстрации отношения композиции на примере класса окна программы

Данный пример может иллюстрировать и другие особенности разрабатываемой компьютерной программы, которые не указывались в явном виде при описании этого примера Так, в частности, указание кратности 1 рядом с классом "Рабочая_область" характерно для однодокументных приложений.

  1.  Отношение обобщения 

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

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

  1.  Графическое изображение отношения обобщения в языке UML

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

  1.  Пример графического изображения отношения обобщения классов

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

  1.  Вариант графического изображения отношения обобщения классов для случая объединения отдельных линий

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

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

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

  •  {complete} — означает, что в данном отношении обобщения специфицированы все классы-потомки, и других классов-потомков у данного класса-предка быть не может. Пример — класс Клиент_банка является предком для двух классов: Физическое_лицо и Компания, и других классов-потомков он не имеет. На соответствующей диаграмме классов это можно указать явно, записав рядом с линией обобщения данную строку-ограничение;
  •  {disjoint} — означает, что классы-потомки не могут содержать объектов, одновременно являющихся экземплярами двух или более классов. В приведенном выше примере это условие также выполняется, поскольку предполагается, что никакое конкретное физическое лицо не может являться одновременно и конкретной компанией. В этом случае рядом с линией обобщения можно записать данную строку-ограничение;
  •  {incomplete} — означает случай, противоположный первому. А именно, предполагается, что на диаграмме указаны не все классы-потомки. В последующем возможно восполнить их перечень не изменяя уже построенную диаграмму. Пример — диаграмма класса "Автомобиль", для которой указание всех без исключения моделей автомобилей соизмеримо с созданием соответствующего каталога. С другой стороны, для отдельной задачи, такой как разработка системы продажи автомобилей конкретных моделей, в этом нет необходимости. Но указать неполноту структуры классов-потомков все же следует;
  •  {overlapping} — означает, что отдельные экземпляры классов-потомков могут принадлежать одновременно нескольким классам. Пример — класс "Многоугольник" является классом-предком для класса "Прямоугольник" и класса "Ромб". Однако существует отдельный класс "Квадрат", экземпляры которого одновременно являются объектами первых двух классов. Вполне естественно такую ситуацию указать явно с помощью данной строки-ограничения.

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

  1.  Вариант графического изображения отношения обобщения классов с использованием строки-ограничения

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

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

  1.  Фрагмент диаграммы классов с отношением обобщения для представления иерархии классов "Автомобиль" из рассмотренного ранее примера

Примечание

В качестве упражнения для закрепления рассмотренного материала можно попытаться построить диаграммы классов или хотя бы их фрагменты для библиотек стандартных классов MFC (Microsoft) и VCL (Borland/Inprise) с использованием графической нотации языка UML. Можно предположить, что в недалеком будущем справочные руководства по соответствующим средам программирования будут содержать именно такие диаграммы классов, а возможно, и некоторые другие.

  1.  Интерфейсы . 

Интерфейсы являются элементами диаграммы вариантов использования и были рассмотрены в главе 4. Однако при построении диаграммы классов отдельные интерфейсы могут уточняться и в этом случае для их изображения используется специальный графический символ — прямоугольник класса с ключевым словом или стереотипом "interface" (рис. 66). При этом секция атрибутов у прямоугольника отсутствует, а указывается только секция операций.

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

  1.  Объекты 

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

Для графического изображения объектов используется такой же символ прямоугольника, что и для классов. Отличия проявляются при указании имен объектов, которые в случае объектов обязательно подчеркиваются (рис. 5.18). При этом запись имени объекта представляет собой строку текста "имя объекта:имя класса", разделенную двоеточием (рис. 67 а, б). Имя объекта может отсутствовать, в этом случае предполагается, что объект является анонимным, и двоеточие указывает на данное обстоятельство (рис. 67, г). Отсутствовать может и имя класса. Тогда указывается просто имя объекта (рис. 67, в). Атрибуты объектов принимают конкретные значения.

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

  1.  Пример графического изображения объектов на диаграммах языка UML

  1.  Шаблоны или параметризованные классы 

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

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

  1.  Графическое изображение шаблона на диаграмме классов

Шаблон не может быть непосредственно использован в качестве класса, поскольку содержит неопределенные параметры. Чаще всего в качестве шаблона выступает некоторый суперкласс, параметры которого уточняются в его классах-потомках. Очевидно, в этом случае между ними существует отношение зависимости с ключевым словом "bind", когда класс-клиент может использовать некоторый шаблон для своей последующей параметризации. В более частном случае между шаблоном и формируемым от него классом имеет место отношение обобщения с наследованием свойств шаблона (рис. 69). В данном примере отмечен тот факт, что класс "Адрес" может быть получен из шаблона Связный_список на основе актуализации формальных параметров "S, k, l" фактическими атрибутами "улица, дом, квартира".

Этот же шаблон может использоваться для задания (инстанцирования) другого класса, скажем, класса "Точки_на_плоскости". В этом случае класс "Точки_на_плоскости" актуализирует те же формальные параметры, но с другими значениями, например, <координаты_точки, х, у>. Концепция шаблонов является достаточно мощным средством в ООП, и поэтому ее использование в языке UML позволяет не только сократить размеры диаграмм, но и наиболее корректно управлять наследованием свойств и поведения отдельных элементов модели.

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

  1.  Рекомендации по построению диаграмм классовЗаключение 

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

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

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

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

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

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

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


  1.  Проектирование динамики приложений при помощи диаграмм переходов состояний, диаграмм последовательности и диаграмм взаимодействия в UML


  1.  План лекции
  •  Проектирование динамики приложений при помощи диаграмм переходов состояний, диаграмм последовательности и диаграмм взаимодействия в UML
  •  Диаграмма состояний (statechart diagram) – автоматы, определение состояния и перехода, составное состояния и подсостояния, сложные переходы.
  •  Диаграмма деятельности (activity diagram) – состояние действия, переходы, дорожки, объекты, рекомендации по построению диаграмм деятельности.
  •  Диаграмма последовательности (sequence diagram) – объекты, сообщения, рекомендации по построению диаграмм последовательности.
  •  Диаграмма кооперации (collaboration diagram) – кооперация, диаграмма кооперации уровня спецификации, объекты, связи, сообщения, рекомендации по построению диаграмм кооперации
    1.  Диаграмма состояний (statechart diagram)Введение 

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

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

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

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

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

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

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

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

  1.  Автоматы 

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

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

  1.  Простейший пример диаграммы состояний для технического устройства типа компьютер

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

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

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

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

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

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

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

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

Примечание

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

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

Примечание

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

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

Примечание

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

  1.  Количество состояний автомата должно быть обязательно конечным (в языке UML рассматриваются только конечные автоматы), и все они должны быть специфицированы явным образом. При этом отдельные псевдосостояния могут не иметь спецификаций (начальное и конечное состояния). В этом случае их назначение и семантика полностью определяются из контекста модели и рассматриваемой диаграммы состояний.
  2.  Граф автомата не должен содержать изолированных состояний и переходов. Это условие означает, что для каждого из состояний, кроме начального, должно быть определено предшествующее состояние. Каждый переход должен обязательно соединять два состояния автомата. Допускается переход из состояния в себя, такой переход еще называют "петлей".
  3.  Автомат не должен содержать конфликтующих переходов, т. е. таких переходов из одного и того же состояния, когда объект одновременно может перейти в два и более последующих состояния (кроме случая параллельных подавтоматов). В языке UML исключение конфликтов возможно на основе введения так называемых сторожевых условий, которые будут рассмотрены ниже.

Таким образом, правила поведения объекта, моделируемого некоторым автоматом, определяются, с одной стороны, общим формализмом автомата, а с другой — его графическим изображением в языке UML в форме конкретной диаграммы состояний.

  1.  Состояние 

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

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

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

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

  1.  Графическое изображение состояний на диаграмме состояний

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

  1.  Имя состояния

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

  1.  Список внутренних действий

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

<метка-дёйствия '/' выражение-действия>

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

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

  •  entry — эта метка указывает на действие, специфицированное следующим за ней выражением действия, которое выполняется в момент входа в данное состояние (входное действие);
  •  exit — эта метка указывает на действие, специфицированное следующим за ней выражением действия, которое выполняется в момент выхода из данного состояния (выходное действие);
  •  do — эта метка специфицирует выполняющуюся деятельность ("do activity"), которая выполняется в течение всего времени, пока объект находится в данном состоянии, или до тех пор, пока не закончится вычисление, специфицированное следующим за ней выражением действия.

В последнем случае при завершении события генерируется соответствующий результат;

  •  include — эта метка используется для обращения к подавтомату, при этом следующее за ней выражение действия содержит имя этого подавтомата.

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

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

  1.  Пример состояния с непустой секцией внутренних действий

  1.  Начальное состояние

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

  1.  Графическое изображение начального и конечного состояний на диаграмме состояний

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

  1.  Конечное состояние

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

  1.  Переход 

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

Переход осуществляется при наступлении некоторого события: окончания выполнения деятельности (do activity), получении объектом сообщения или приемом сигнала. На переходе указывается имя события Кроме того, на переходе могут указываться действия, производимые объектом в ответ на внешние события при переходе из одного состояния в другое. Срабатывание перехода может зависеть не только от наступления некоторого события, но и от выполнения определенного условия, называемого сторожевым условием. Объект перейдет из одного состояния в другое в том случае, если произошло указанное событие и сторожевое условие приняло значение "истина".

Примечание

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

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

<сигнатура события>'['<сторожевое условие>']' <выражение действия>.

При этом сигнатура события описывает некоторое событие с необходимыми аргументами:

<имя события>'('<список параметров, разделенных запятыми>')'.

  Событие

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

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

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

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

  1.  Сторожевое условие 

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

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

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

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

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

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

  1.  Диаграмма состояний для моделирования почтовой программы-клиента

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

Примечание

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

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

  1.  Выражение действия 

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

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

В качестве примера выражения действия (см. рис. 6.5) может служить "разорвать телефонное соединение (телефонный номер), которое должно быть выполнено сразу после установления истинности ("истина") сторожевого условия "почтовый ящик на сервере пуст".

Другим примером может служить очевидная ситуация с выделением графических объектов на экране монитора при однократном нажатии левой кнопки мыши. Имеется в виду обработка сигналов от пользователя при выделении тех или иных графических примитивов (пиктограмм). В этом случае соответствующий переход может иметь следующую строку текста: "нажата и отпущена левая кнопка мыши (координаты) [координаты в области графического объекта] / выделить объект (цвет). Результатом этого триггерного перехода может быть, например, активизация некоторых свойств объекта (размер файла в строке состояния) или последующее его удаление в корзину.

Примечание

Иногда после выражения действия может быть записано сообщение в формате: 'Л' <имя объекта приемника сообщения> '.' <имя посылаемого сообщения> '('<параметр>':'<тип>,')'. При этом сообщение имеет чисто информационный характер и не передает управление на объект-приемник сообщения.

  1.  Составное состояние и подсостояние 

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

  1.  Графическое представление составного состояния с двумя вложенными в него последовательными подсостояниями

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

  1.  Последовательные подсостояния 

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

Для примера рассмотрим в качестве моделируемого объекта обычный телефонный аппарат. Он может находиться в различных состояниях, одним из которых является состояние дозвона до абонента. Очевидно, для того чтобы позвонить, необходимо снять телефонную трубку, услышать тоновый сигнал, после чего набрать нужный телефонный номер. Таким образом, состояние дозвона до абонента является составным и состоит из двух последовательных подсостояний: "поднять телефонную трубку" и "набрать телефонный номер". Фрагмент диаграммы состояний для этого примера содержит одно составное состояние и два последовательных подсостояний (рис. 76).

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

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

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

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

  1.  Параллельные подсостояния 

Параллельные подсостояния (concurrent substates) позволяют специфицировать два и более подавтомата, которые могут выполняться параллельно внутри составного события. Каждый из подавтоматов занимает некоторую область (регион) внутри составного состояния, которая отделяется от остальных горизонтальной пунктирной линией. Если на диаграмме состояний имеется составное состояние с вложенными параллельными подсостояниями, то объект может одновременно находиться в каждом из этих подсостояний.

Однако отдельные параллельные подсостояния могут, в свою очередь, состоять из нескольких последовательных подсостояний (подавтоматы 1 и 2 на рис. 77). В этом случае по определению объект может находиться только в одном из последовательных подсостояний подавтомата. Таким образом, для абстрактного примера (рис. 6.8) допустимо одновременное нахождение объекта в подсостояниях (1, 3, 4), (2, 3, 4), (1, 3, 5), (2, 3, 5). Недопустимо нахождение объекта одновременно в подсостояниях (1, 2,3) или (3, 4, 5).

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

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

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

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

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

  1.  Историческое состояние 

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

Историческое состояние (history state) применяется в контексте составного состояния. Оно используется для запоминания того из последовательных подсостояний, которое было текущим в момент выхода из составного состояния. При этом существует две разновидности исторического состояния: недавнее и давнее.

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

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

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

С другой стороны, запомненное состояние, в свою очередь, также может являться составным состоянием. Давнее историческое состояние (deep history state) обозначается в форме небольшой окружности, в которую помещена латинская буква "Н" с символом "*" и служит для запоминания всех подсостояний любого уровня вложенности для текущего подавтомата.

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

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

Диаграмма состояний почтовой программы-клиента (см. рис. 6.5) может быть дополнена с учетом рассмотренного аспекта ее поведения. Читателю предлагается это проделать самостоятельно в качестве упражнения.

  1.  Сложные переходы 

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

  1.  Переходы между параллельными состояниями 

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

Графически такой переход изображается вертикальной черточкой, аналогично обозначению перехода в известном формализме сетей Петри. Если параллельный переход имеет две или более входящих дуг (рис. 79, а), то его называют соединением (join). Если же он имеет две или более исходящих из него дуг (рис. 79, б), то его называют ветвлением (fork). Текстовая строка спецификации параллельного перехода записывается рядом с черточкой и относится ко всем входящим (исходящим) дугам.

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

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

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

  1.  Переходы между составными состояниями 

Переход, стрелка которого соединена с границей некоторого составного состояния, обозначает переход в составное состояние (переход b на рис. 6.12). Он эквивалентен переходу в начальное состояние каждого из подавтоматов (возможно, единственному), входящих в состав данного суперсостояния. Переход, выходящий из составного состояния (переходы f и g на рис. 6.12), относится к каждому из вложенных подсостояний. Это означает, что объект может покинуть составное суперсостояние, находясь в любом из его подсостояний. Для этого вполне достаточно выполнения события и сторожевого условия.

  1.  Различные варианты переходов в (из) составное состояние

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

  1.  Синхронизирующие состояния 

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

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

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

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

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

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

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

  1.  Диаграмма состояний процесса функционирования телефонного аппарата

Далее телефонный аппарат будет находиться в состоянии "тоновый сигнал". При этом будет непрерывно издавать этот сигнал до тех пор, пока не произойдет событие-триггер "набор цифры (п)", либо не истечет 15 секунд с момента поднятия трубки. В первом случае аппарат перейдет в состояние "набор номера", а во втором — в состояние "истечение времени ожидания". Последняя ситуация может быть результатом сомнений по поводу "звонить — не звонить?", следствием чего могут стать гудки в трубке. При этом нам ничего не остается делать, как опустить ее на рычаг.

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

Если же набранный номер полный, то можно перейти в состояние "неверный номер" или "соединение". В случае неверного номера (сторожевое условие "неверный" истинно) ничего не остается, как покинуть составное состояние, опустив трубку на рычаг. Если же номер верный, то происходит соединение по этому номеру.

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

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

Примечание

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

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

  1.  Заключительные рекомендации по построению диаграмм состояний 

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

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

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

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

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

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

И, наконец, следует отметить, что некоторые дополнительные конструкции автоматов, такие как точки динамического выбора (dynamic choice points) или точки соединения (junction points), в книге не нашли отражения. Это сделано по той причине, что данные модельные элементы хотя и позволяют моделировать более сложные аспекты динамического управления поведением объекта, не являются базовыми. Соответствующая информация содержится в оригинальной документации по языку UML.

  1.  Диаграмма деятельности (activity diagram) 

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

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

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

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

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

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

Примечание

Хотя диаграмма деятельности предназначена для моделирования поведения систем, время в явном виде отсутствует на этой диаграмме. Ситуация здесь во многом аналогична диаграмме состояний.

  1.  Состояние действия 

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

Графически состояние действия изображается фигурой, напоминающей прямоугольник, боковые стороны которого заменены выпуклыми дугами (рис. 83). Внутри этой фигуры записывается выражение действия (action-expression), которое должно быть уникальным в пределах одной диаграммы деятельности.

  1.  Графическое изображение состояния действия

Действие может быть записано на естественном языке, некотором псевдокоде или языке программирования. Никаких дополнительных или неявных ограничений при записи действий не накладывается. Рекомендуется в качестве имени простого действия использовать глагол с пояснительными словами (рис. 83, а). Если же действие может быть представлено в некотором формальном виде, то целесообразно записать его на том языке программирования, на котором предполагается реализовывать конкретный проект (рис. 83, б).

Иногда возникает необходимость представить на диаграмме деятельности некоторое сложное действие, которое, в свою очередь, состоит из нескольких более простых действий. В этом случае можно использовать специальное обозначение так называемого состояния под-деятельности (subactivity state). Такое состояние является графом деятельности и обозначается специальной пиктограммой в правом нижнем углу символа состояния действия (рис. 84). Эта конструкция может применяться к любому элементу языка UML, который поддерживает "вложенность" своей структуры. При этом пиктограмма может быть дополнительно помечена типом вложенной структуры.

  1.  Графическое изображение состояния под-деятельности

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

  1.  Переходы 

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

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

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

В качестве примера рассмотрим фрагмент известного алгоритма нахождения корней квадратного уравнения. В общем случае после приведения уравнения второй степени к каноническому виду: а*х*х + Ь*х + с = 0 необходимо вычислить его дискриминант. Причем, в случае отрицательного дискриминанта уравнение не имеет решения на множестве действительных чисел, и дальнейшие вычисления должны быть прекращены. При неотрицательном дискриминанте уравнение имеет решение, корни которого могут быть получены на основе конкретной расчетной формулы. .

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

Примечание

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

  1.  Фрагмент диаграммы деятельности для алгоритма нахождения корней квадратного уравнения

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

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

Примечание

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

  1.  Различные варианты ветвлений на диаграмме деятельности

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

Как правило, такая черточка изображается отрезком горизонтальной линии, толщина которой несколько шире основных сплошных линий диаграммы деятельности. При этом разделение (concurrent fork) имеет один входящий переход и несколько выходящих (рис. 87, а). Слияние (concurrent join), наоборот, имеет несколько входящих переходов и один выходящий (рис. 87, б).

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

  1.  Графическое изображение разделения и слияния параллельных потоков управления

  1.  Диаграмма деятельности для примера с приготовлением напитка

Примечание

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

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

  1.  Дорожки 

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

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

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

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

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

  1.  Вариант диаграммы деятельности с дорожками

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

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

  1.  Объекты 

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

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

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

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

Примечание

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

  1.  Фрагмент диаграммы деятельности торговой компании с объектом-заказом

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

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

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

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

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

  1.  Рекомендации по построению диаграмм деятельности 

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

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

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

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

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

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

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

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

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

  1.  Диаграмма последовательности (sequence diagram)

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

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

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

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

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

  1.  Объекты 

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

Примечание

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

  1.  Различные графические примитивы диаграммы последовательности

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

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

  1.  Линия жизни объекта 

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

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

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

  1.  Графическое изображение различных вариантов линий жизни и фокусов управления объектов

  1.  Фокус управления 

В процессе функционирования объектно-ориентированных систем одни объекты могут находиться в активном состоянии, непосредственно выполняя определенные действия или в состоянии пассивного ожидания сообщений от других объектов. Чтобы явно выделить подобную активность объектов, в языке UML применяется специальное понятие, получившее название фокуса управления (focus of control). Фокус управления изображается в форме вытянутого узкого прямоугольника (см. объект 1 на рис. 93), верхняя сторона которого обозначает начало получения фокуса управления объекта (начало активности), а ее нижняя сторона — окончание фокуса управления (окончание активности). Этот прямоугольник располагается ниже обозначения соответствующего объекта и может заменять его линию жизни (объект 4 на рис. 94), если на всем ее протяжении он является активным.

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

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

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

  1.  Графическое изображение актера, рекурсии и рефлексивного сообщения на диаграмме последовательности

  1.  Сообщения 

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

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

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

  1.  Графическое изображение различных видов сообщений между объектами на диаграмме последовательности

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

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

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

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

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

  1.  Ветвление потока управления 

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

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

  1.  Графическое изображение бинарного ветвления потока управления на диаграмме последовательности

  1.  Графическое изображение тернарного ветвления потока управления на диаграмме последовательности

Условием ветвления может служить сумма снимаемых клиентом средств со своего текущего счета. Если эта сумма превышает $1000, то могут потребоваться дополнительные действия, связанные с созданием и последующим разрушением объекта 4. Если же сумма превышает $50, но не превышает $1000, то управление передается объекту 3. И, наконец, если сумма не превышает $50, то управление получает объект 2. При этом объекты 1, 2 и 3 постоянно существуют в системе. Объект 4 создается, только если справедливо первое из альтернативных условий. В противном случае он может быть никогда не создан. После выполнения требуемых действий объекты 2 и 3 просто информируют объект 1 о завершении соответствующих операций, не требуя от него никаких действий (пунктирная стрелка). Объект 4 после завершения своих действий уничтожается, передавая управление объекту 3, делая его активным (фокус управления).

  1.  Стереотипы сообщений 

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

  •  "call" (вызвать) — сообщение, требующее вызова операции или процедуры принимающего объекта. Если сообщение с этим стереотипом рефлексивное, то оно инициирует локальный вызов операции у самого пославшего это сообщение объекта;
  •  "return" (возвратить) — сообщение, возвращающее значение выполненной операции или процедуры вызвавшему ее объекту. Значение результата может инициировать ветвление потока управления;
  •  "create" (создать) — сообщение, требующее создания другого объекта для выполнения определенных действий. Созданный объект может получить фокус управления, а может и не получить его;
  •  "destroy" (уничтожить) — сообщение с явным требованием уничтожить соответствующий объект. Посылается в том случае, когда необходимо прекратить нежелательные действия со стороны существующего в системе объекта, либо когда объект больше не нужен и должен освободить задействованные им системные ресурсы;
  •  "send" (послать) — обозначает посылку другому объекту некоторого сигнала, который асинхронно инициируется одним объектом и принимается (перехватывается) другим. Отличие сигнала от сообщения заключается в том, что сигнал должен быть явно описан в том классе, объект которого инициирует его передачу.

Ниже представлена диаграмма последовательности для рассмотренного выше случая ветвления, дополненная стереотипными значениями (рис. 99).

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

Примечание

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

  1.  Диаграмма последовательности со стереотипными значениями сообщений
    1.  Временные ограничения на диаграммах последовательности 

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

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

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

  •  {время_приема_сообщения время_отправки_сообщения < 1 сек.}
  •  {время_ожидания_ответа < 5 сек.}
  •  {время_передачи_пакета < 10 сек.}
  •  {объект_1. время_подачи_сигнала_тревоги > 30 сек.}

Примечание

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

  1.  Комментарии или примечания 

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

  1.  Пример построения диаграммы последовательности 

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

На первом этапе располагаем выбранные объекты на предполагаемой диаграмме (рис. 100). Заметим, что абонентов мы будем рассматривать как актеров, причем первый из них — а — играет активную роль, а второй — b — пассивную роль. Поэтому первый получает фокус управления сразу после своего появления в системе, а второй имеет только линию жизни. Коммутатор также имеет постоянную активность, что изображается его фокусом управления. Разговор как объект появляется только после установки соединения и уничтожается с его прекращением. Поэтому он будет изображен позже на этой же диаграмме последовательности.

  1.  Начальный фрагмент диаграммы последовательности для моделирования телефонного разговора

Процесс взаимодействия в этой системе начинается с поднятия трубки телефонного аппарата первым абонентом. Тем самым он посылает сообщение телефонному аппарату с, которое переводит этот аппарат в активное состояние и вызывает действие — подачу тонового сигнала в телефонную трубку для первого абонента. Следующее действие также инициируется первым абонентом — набор цифр телефонного номера. Это представлено в форме итеративного сообщения со знаком "*" слева от его имени.

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

После создания анонимный объект "разговор" сразу получает фокус активности и посылает сообщение телефонному аппарату d на выполнение действия — звонка вызова. При этом второй абонент снимает трубку (асинхронное сообщение), тем самым устанавливается прямое соединение между абонентами а и Ь. После того как абоненты опустят трубки, разговор заканчивается. Тем самым объект "разговор" уничтожается. Окончательный вариант диаграммы последовательности может содержать некоторые временные ограничения и комментарии (рис. 102). Назначение отдельных сообщений соответствуют рассмотренным действиям.

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

  1.  Окончательный вариант диаграммы последовательности для моделирования телефонного разговора

Примечание

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

  1.  Заключениеительные рекомендации по построению диаграмм последовательности 

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

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

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

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


  1.  Управление требованиями к программному продукту. CASE-средство Requisite Pro.
    1.  План лекции
  •  Внедрение системы управления требованиями.
  •  Определение принципов создания хранилищ и политики доступа к ним.
  •  Фиксация инструментария, рабочей среды, средств разработки и внешних интерфейсов.
  •  Определение идентификации требований.
  •  Определение трассировки требований.
  •  Определение группы, видов, атрибутов требований.
  •  Определение метрик и отчетов.
  •  Определение принципов управления требованиями, формирование группы управления изменениями.
  •  Определение контрольных точек проекта.
  •  Внедрение разработанной системы УТ на проекте.
  •  Подсистема управления требованиями на основе IBM Rational RequisitePro.
    1.  
    2.  Введение

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

Цель данного документа - продемонстрировать общую последовательность действий, которые обычно выполняются при работе с RequisitePro, и рассказать о некоторых его технических особенностях. Здесь не описываются назначение и все возможности продукта. Также не раскрывается смысл многих терминов, что достаточно подробно выполнено в Rational Unified Process (рубрика “Glossary”)

  1.  Нормативная основа 

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

IEEE Std 830-1993 «IEEE Recommended Practice for Software Requirements Specifications»

  1.  Термины, сокращения и определения

Сокращение, термин

Расшифровка сокращения или термина

Категория на английском языке

ГОК

Группа обеспечения качества

Quality Assurance Group

ГТР

Группа технологии разработки

Engineering Process Group

Заказчик

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

Customer

Ключевая роль

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

Кеу role

Аналитик

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

Analyst

Менеджер проекта

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

Project Manager

Нетехническое требование

Требование, относящееся к организации разработки продукта

Non technical Requirement

Нефункциональное требование

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

Non functional requirement

ПО

Программное Обеспечение

Software

Проект

Ограниченная во времени деятельность, направленная на разработку уникального продукта

Project

Проектировщик

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

Designer

Разработчик

Ключевая роль в рабочей группе проекта разработки программного обеспечения, отвечающая за кодирование и отладку ПО

Developer

Роль

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

Role

Тестировщик

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

Tester

Технический проект

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

Design

Техническое требование

Требование, относящееся к характеристикам разрабатываемого продукта

Technical Requirement

ТЗ

Техническое Задание

Requirement Specification

ТЗПО

Техническое Задание на Программное Обеспечение

Software Requirement Specification

Требование

Описание способности или ограничения

Requirement

Функциональное требование

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

Functional Requirement

  1.  Основные положения
    1.  Цели управления требованиями

Целями управления требованиями являются:

  1.  Обеспечение контроля над процессами управления требованиями с целью обеспечения разработки программного продукта в точном соответствии с требованиями заказчика;
  2.  Поддержание соответствия, на протяжении всего жизненного цикла проекта, между действующими требованиями к разрабатываемому программному обеспечению, с одной стороны, с планами, результатами работ и выполняемыми действиями – с другой.
    1.  Участники управления требованиями

Для описания процессов управления требованиями выделяются следующие ключевые роли, должности и группы:

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

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

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

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

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

6. ГОК – группа обеспечения качества. Специалисты группы в соответствии с планом работы группы осуществляют необходимые проверки и аудит процессов управления требований.

7. ГТР – группа технологии разработки. Группа несет ответственность за поддержку и совершенствование процессов управления требованиями в проектах разработки программного обеспечения.

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

  1.  Политика  в области управления требованиями

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

  1.  Координация работ по управлению требованиями в проекте возлагается на одного члена рабочей группы – Аналитика, на протяжении всего жизненного цикла проекта.
  2.  Требования к разрабатываемому программному обеспечению должны быть документированы.
  3.  Документ, содержащий требования к разрабатываемому продукту, должен быть письменно утвержден Заказчиком1.  После утверждения требований Заказчиком технические риски, связанные с формулировкой требований принимает на себя Заказчик.
  4.  Требования должны быть утверждены Руководством компании. После утверждения требований технические риски, связанные с удовлетворением сформулированных требований принимает на себя разработчик.
  5.  Требования должны быть согласованы со всеми ключевыми членами рабочей группы проекта.
  6.  Перед согласованием и утверждением требования должны пройти формальную проверку на наличие рисков, связанных с требованиями. Отчет о результатах проверки с выводами о наличии и размерах рисков доводится до сведения всех ключевых членов рабочей группы и руководства компании и помещается в составе необходимой внутренней документации в дело проекта.
  7.  Информация о рисках, связанных с требованиями, в обязательном порядке доводится до сведения заказчика, если планы компенсации рисков требуют привлечения ресурсов, выходящих за рамки утвержденных для проекта лимитов и ограничений.
  8.  Действия по разработке программного обеспечения могут быть начаты только после утверждения требований Заказчиком и руководством компании. При необходимости начать работы до утверждения требований официальным Заказчиком, в роли Заказчика может выступить должностное лицо компании, имеющее полномочия и ресурсы принять риски, связанные с формулировкой требований.
  9.  Утвержденные требования являются основанием для разработки:
    - плана проекта,
    - технического проекта,
    - плана тестирования,
    - программного обеспечения и документации.
  10.  В процессе выполнения проекта по инициативе Заказчика, ключевых членов рабочей группы или в соответствии с планом проекта требования могут быть изменены. Изменение требований должно быть выполнено в соответствии с процедурой контроля изменений. Документ, содержащий изменения или дополнения требований либо новая версия документа, согласовывается и утверждается в порядке, предусмотренном для  основного документа.
  11.  При изменении требований выполняются процедуры каскадной корректировки разработанных материалов проекта. Обеспечение соответствия утвержденных требований - остальным материалам проекта является сферой ответственности рабочей группы проекта.
  12.  Документ, описывающий требования к ПО – Техническое Задание должен находиться под конфигурационным контролем.
  13.  Группа обеспечения качества в соответствии со своим планом проводит проверки и аудит процедур управления требований.
    1.  Обеспечение процессов управления требований 
      1.  Распределение ответственности
        1.  Аналитик

Аналитик является ключевой ролью в составе рабочей группы.

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

Для каждого проекта разработки программного обеспечения в рабочей группе выделяется специалист – Аналитик, который ведет управление требованиями.  Управление требованиями выполняется Аналитиком на протяжении всего жизненного цикла проекта.

В обязанности Аналитика входит:

  1.  Разработка требований и/или координация работ по разработке требований.
  2.  Локализация требований к ПО на основе общих требований к системе, в случае, если проект разработки ПО является подпроектом общего проекта разработки программно - аппаратной системы.
  3.  Анализ требований, координация по процедурам проверки требований, сбор и учет замечаний к требованиям, идентификация и оценка рисков.
  4.  Согласование требований в компании, в рабочей группе проекта и у Заказчика.
  5.  Выпуск версий документов, содержащих требования, отчетов об анализе требований, предложений по управлению рисками, связанными с требованиями.
  6.  Обеспечение информированности членов рабочей группы о текущем статусе требований.
  7.  Организация сдачи разработанного продукта Заказчику.
  8.  Контроль над изменениями требований.
  9.  Контроль над соответствием разрабатываемых материалов проекта утвержденным требованиям.
    1.  Менеджер проекта

Менеджер проекта является ключевой ролью в составе рабочей группы.

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

Менеджер проекта имеет следующие обязанности в процессе управления требований:

  1.  Планирование ресурсов и контроль выполнения задач, связанных с управлением требованиями в проекте.
  2.  Проверка корректности требований.
  3.  Организация оценки требований в отношении ресурсов, требуемых для их выполнения и связанных с требованиями рисков.
  4.  Разработка плана компенсации рисков, связанных с требованиями к ПО.
  5.  Разработка и корректировка плана разработки ПО на основе утвержденных требований к ПО.
  6.  Контроль выполнения задач, утвержденных в плане проекта, в контексте удовлетворяемых требований к ПО.
  7.  Организация принятия решений по проблемам и рискам, связанным с управлением требованиями.
  8.  Вынос на уровень руководства проблем и рисков, связанных с требованиями, которые не могут быть разрешены внутри проекта.  
    1.  Тестировщик

Тестировщик является ключевой ролью в составе рабочей группы.

Тестировщик имеет право согласовывать требования перед их утверждением Руководством компании.

Тестировщик проекта имеет следующие обязанности в процессе управления требованиями:

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

Проектировщик является ключевой ролью в составе рабочей группы.

Проектировщик имеет право согласования требований.

Проектировщик проекта имеет следующие обязанности в процессе управления требованиями:

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

Разработчик является ключевой ролью в составе рабочей группы.

Разработчик имеет право согласования требований.

Разработчик проекта имеет следующие обязанности в процессе управления требованиями:

  1.  Проверка требований в отношении трудоемкости их удовлетворения.
  2.  Внесение предложений по изменению требований с целью повышения эффективности работ по реализации требований.
  3.  Проверка соответствия между ТЗ и Техническим проектом, между ТЗ и Планом тестирования.
  4.  Оценка технических рисков, связанных с реализацией требований.
  5.  Кодирование и отладка в соответствии с Техническим проектом, с учетом Плана тестирования в контексте удовлетворяемых требований.
    1.  Документирование

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

Оформление требований для российских заказчиков выполняется в соответствии со стандартом ГОСТ 34.602, для иностранного заказчика - в соответствии со стандартом IEEE Std 830, если иное не оговорено в контракте.

  1.  Обеспечение ресурсами

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

Для небольших проектов роль Аналитика может быть совмещена