выделены 2 архитектурных уровня (пакета со стереотипом
>);
-
на уровень Application (Приложение) помещен пакет Registration, куда включены граничные и управляющие классы;
-
граничные классы BillingSystem и CourseCatalogSystem преобразованы в интерфейсы и помещены в пакет Interfaces уровня бизнес-логики (Business Services);
-
на уровень Business Services, помимо пакета интерфейсов, помещены две подсистемы, реализуюшие интерфейсы, а также пакет University Artifacts с классами-сущностями.
На диаграмме указаны зависимости между пакетами.
После формирования архитектурных уровней выполняется проектирование структуры потоков управления. Оно осуществляется при наличии в системе параллельных процессов. Цель проектирования – выявление существующих в системе процессов, характера их взаимодействия, создания, уничтожения и отображения в среду реализации. Требования параллелизма возникают в следующих случаях:
• необходимо распределение обработки между различными процессорами или узлами;
• система управляется потоком событий;
• вычисления в системе обладают высокой интенсивностью;
• с системой одновременно работает много пользователей.
Например, система регистрации курсов обладает свойством параллелизма, поскольку она должна допускать одновременную работу многих пользователей (студентов, регистраторов и профессоров), каждый из которых порождает в системе отдельный процесс.
Процесс – это ресурсоемкий поток управления, который может выполняться параллельно с другими потоками. Он выполняется в независимом адресном пространстве и в случае высокой сложности может разделяться на два или более потоков.
Поток (нить) – это облегченный поток управления, который может выполняться параллельно с другими потоками в рамках одного и того же процесса в общем адресном пространстве.
Необходимость создания потоков в системе регистрации курсов диктуется следующими требованиями:
• если курс окажется заполненным в то время, когда студент формирует свой учебный график, включающий данный курс, то он должен быть извещен об этом (необходим независимый процесс, управляющий доступом к информации конкретных курсов);
• существующая база данных каталога курсов не обеспечивает требуемую производительность (необходим процесс промежуточной обработки – подкачки данных).
Реализация процессов и потоков обеспечивается средствами операционной системы.
Для моделирования структуры потоков управления используются так называемые активные классы – классы со стереотипами
> и . Активный класс владеет собственным процессом или потоком и может инициировать управляющие воздействия. Связи между процессами моделируются как зависимости. Потоки могут существовать только внутри процессов, поэтому связи между процессами и потоками моделируются как композиции. Модель потоков управления помещается в пакет Process View (представление процессов – одно из архитектурных представлений в модели «4+1»). В качестве примера приведена диаграмма классов, описывающая структуру процесса регистрации студента на курсы. Обратите внимание, что все классы на ней являются активными (выделены двойными вертикальными границами).
Активные классы, показанные на этих диаграммах, выполняют следующее назначение:
• StudentApplication – процесс, управляющий всеми функциями студента-пользователя в системе. Для каждого студента, начинающего регистрироваться на курсы, создается один объект данного класса.
• CourseRegistrationProcess – процесс, управляющий непосредственно регистрацией студента. Для каждого студента, начинающего регистрироваться на курсы, также создается один объект данного класса.
• CourseCatalogSystemAccess – управляет доступом к системе каталога курсов. Один и тот же объект данного класса используется всеми пользователями при доступе к каталогу курсов.
• CourseCache и OfferingCache используются для асинхронного доступа к данным в БД для повышения производительности системы. Они представляют собой кэши для промежуточного хранения данных о курсах, извлеченных из двух таблиц БД.
Создание потоков во время инициализации приложения моделируется с помощью диаграмм взаимодействия.
Объекты любого проектного класса или подсистемы должны существовать внутри по крайней мере одного процесса. Связи между процессами и проектными классами моделируются на диаграммах классов. Ниже приведены примеры для системы регистрации:
Обратите внимание, что на диаграмме зависимости между процессами соответствуют ассоциациям и зависимостям между классами, экземпляры которых содержатся в процессах.
После проектирования структуры потоков управления осуществляется проектирование конфигурации. Если создаваемая система является распределенной, то необходимо спроектировать ее конфигурацию в вычислительной среде, т. е., описать вычислительные ресурсы, коммуникации между ними и распределение компонент системы по вычислительным узлам.
Распределенная сетевая конфигурация системы моделируется с помощью диаграммы размещения. Диаграмма размещения – это единственная диаграмма, входящая в состав представления размещения – одного из архитектурных представлений, входящих в модель «4+1» Основные элементы диаграммы размещения:
-
узел (node) – вычислительный ресурс (среда выполнения, в которой могут быть расположены компоненты системы, или устройство: дисковая память, контроллеры различных устройств и т.д.).
-
подключение (connection) – канал взаимодействия узлов (сеть).
Вспомогательные элементы диаграммы размещения – артефакты, т. е. компоненты системы, размещаемые в среды выполнения. Каждая компонента соответствует процессу, выделенному ранее в структуре процессов. Распределение процессов, составляющих структуру потоков управления, по узлам сети производится с учетом следующих факторов:
-
используемые образцы распределения (трехзвенная архитектура клиент-сервер, «толстый клиент», «тонкий клиент», «точка-точка» и т. д.);
-
время отклика;
-
минимизация сетевого трафика;
-
мощность узла;
-
надежность оборудования и коммуникаций.
Пример – диаграмма размещения для системы регистрации на курсы:
О
стальные работы относятся к проектированию элементов системы, которое осуществляют разработчики под общим руководством архитектора. Начинается оно с уточнения реализаций вариантов использования. Уточнение заключается в модификации диаграмм взаимодействия и диаграмм классов с учетом вновь появившихся на шаге проектирования классов и подсистем, а также проектных механизмов. Вносятся изменения в описания потоков событий вариантов использования (с помощью скриптов и примечаний). Для упрощения системы предпринимаются попытки унификации классов и подсистем по следующим правилам:
-
Имена элементов модели должны отражать их функции. Следует избегать подобных имен и синонимов. Классы со схожими названиями следует рассмотреть как кандидаты на объединение в один.
-
Элементы модели, реализующие сходное поведение или представляющие одно и то же явление, должны объединяться.
-
Классы, представляющие одно и то же понятие или имеющие одинаковые атрибуты, должны объединяться, даже если их поведение различно.
-
При обновлении/исключении элемента модели должны происходить соответствующие изменения в реализациях вариантов использования.
На диаграммах последовательности экземпляры классов анализа заменяются экземплярами проектных элементов. Если класс анализа был преобразован в подсистему, то его экземпляр заменяется «экземпляром интерфейса» подсистемы. Таково соглашение моделирования. На самом деле у интерфейсов нет экземпляров, так как они – лишь спецификации соглашений по взаимодействию с подсистемами. Изображая «экземпляр интерфейса» на диаграмме, мы указываем, на взаимодействия с экземпляром класса, реализующего интерфейс, но не указываем конкретный класс, так как это может быть любой класс, реализующий данный интерфейс.
Следует избегать случаев, когда на диаграмме «экземпляр интерфейса» отправляет какие-либо сообщения. Это накладывает ограничения на реализацию интерфейса, а значит, противоречит самой идее использования интерфейса и выделения подсистемы. Поэтому такие сообщения следует убирать с диаграмм взаимодействия, описывающих реализации вариантов использования. Отправка сообщений экземплярами классов, реализующих интерфейсы, изображается на диаграммах взаимодействия, созданных при проектировании подсистем.
После уточнения реализаций вариантов использования осуществляется проектирование подсистем. Оно включает в себя следующие действия:
-
Распределение поведения подсистемы по ее элементам
-
документирование взаимодействия элементов подсистемы в виде коопераций («реализаций интерфейса»);
-
построение одной или более диаграмм взаимодействия для каждой операции интерфейса подсистемы/
-
Документирование элементов подсистемы (в виде диаграмм классов).
-
Описание зависимостей между подсистемами.
П
ример проектирования подсистемы CourseCatalogSystem:
Рис.Диаграмма кооперации, описывающая реализацию интерфейсной операции getCourseOfferings() в подсистеме CourseCatalogSystem.
Заметим, что реализация подсистемы CourseCatalogSystem выполнена созданием экземпляра механизма JDBC, т. е. подстановкой класса DBCourseOffering вместо роли DBClass, CourseOffering – вместо PersistentClass, CourseOfferingList – вместо PersistentClassList, CourseCatalogSystem вместо PersistencyClient. То есть, берется шаблонная диаграмма взаимодействия из модели механизма и уточняется подстановкой конкретных классов. Аналогично будет получена диаграмма классов, описывающая структурные связи подсистемы. Подстановка классов на месте ролей изображена на рис.:
Еще одним важным моментом является использованное на диаграмме соглашение моделирования: Вызов операции getCourseOfferings(), реализацию которой мы описываем, производится клиентским объектом (названным CourseCatalogSystemClient) не имеющим указания класса. В самом деле, подсистема ничего не знает о своих клиентских классах, так что указать класс невозможно. По смыслу на месте объекта CourseCatalogSystemClient может быть либо экземпляр RegistrationController, либо экземпляр CloseRegistrationController.
U
ML2 позволяет обойтись без объекта не имеющего класса, так как на диаграммах последовательности позволительно изображать найденные сообщения, т. е. сообщения без отправителя. Подсистема себя ведёт одинаково независимо от того, кто является отправителем getCourseOfferings(), поэтому отправителя на диаграмме нет.
Рис. Связывание образца JDBC с конкретными классами системы
После проектирования подсистем производится проектирование классов, которое включает следующие действия:
-
детализация проектных классов;
-
уточнение операций и атрибутов;
-
моделирование состояний для классов;
-
уточнение связей между классами.
Каждый граничный класс преобразуется в некоторый набор классов, в зависимости от своего назначения. Это может быть набор элементов пользовательского интерфейса, зависящий от возможностей среды разработки, или набор классов, реализующий системный или аппаратный интерфейс.
Классы-сущности с учетом соображений производительности и защиты данных могут разбиваться на ряд классов. Основанием для разбиения является наличие в классе атрибутов с различной частотой использования или видимостью. Такие атрибуты, как правило, выделяются в отдельные классы.
Что касается управляющих классов, то классы, реализующие простую передачу информации от граничных классов к сущностям, могут быть удалены. Сохраняются классы, выполняющие существенную работу по управлению потоками событий (управление транзакциями, распределенная обработка и т.д.).
Полученные в результате уточнения классы подлежат непосредственной реализации в коде системы.
Обязанности классов, определенные в процессе анализа и документированные в виде «операций анализа», преобразуются в операции, которые будут реализованы в коде. При этом:
-
каждой операции присваивается краткое имя, характеризующее ее результат;
-
определяется полная сигнатура операции;
-
создается краткое описание операции, включая смысл всех ее параметров;
-
определяется видимость операции: public (+), private (–), protected (#) или package (~);
-
определяется область действия операции: операция объекта или операция класса.
Уточнение атрибутов классов заключается в следующем:
-
задается его тип атрибута и значение по умолчанию (необязательно);
-
задается видимость атрибутов: public (+), private (–), protected (#) или package (~);
-
при необходимости определяются производные (вычисляемые) атрибуты (/).
Если в системе присутствуют объекты со сложным поведением, то строят диаграммы состояний. Сведения об этом виде диаграмм даны в конспекте лекции 3. Построение диаграмм состояний может оказать следующее воздействие на описание классов:
-
события вызова соотносятся с вызываемыми операциями класса;
-
особенности конкретных состояний могут повлиять на методы, реализующие операции;
-
описание состояний и переходов может помочь при уточнении атрибутов класса.
В
процессе проектирования связи между классами подлежат уточнению.
Некоторые ассоциации преобразуются в зависимости (в случаях, когда соединения экземпляров классов не стабильны, т. е. временны, например, если объект является параметром или результатом операции или ее локальной переменной). Оставшиеся ассоциации преобразуются в агрегации или композиции. Композиции бывают 2-х видов:
-
безраздельно обладает (зависимость по существованию, транзитивность, асимметричность, стационарность);
-
обладает (зависимость по существованию, транзитивность, асимметричность).
Примеры: университет -> факультет -> кафедра; здание -> этаж здания.
Виды агрегаций:
-
включает (зависимость по существованию, транзитивность);
-
участник (нет ограничений).
Примеры: автомобиль -> колесо; предприятие -> сотрудник.
Определяются направления связей, при этом учитываются взаимодействия объектов, а также ожидаемое количество экземпляров классов. Классы ассоциаций являются артефактами моделирования и не поддерживаются языками программирования, поэтому они должны быть преобразованы в обычные классы. Это преобразование называется материализацией связи. Структурные связи с множественными полюсами уточняются. Им приписываются квалификаторы. Квалификатор – атрибут или набор атрибутов ассоциации, значение которых позволяет выбрать для конкретного объекта квалифицированного класса множество целевых объектов на противоположном конце соединения. Например, если в папке может находиться не более одного файла с заданным именем, то имя файла – квалификатор ассоциации папка -> файл. Соответствующие атрибуты у целевых классов должны быть удалены. Квалификатор не обязательно состоит из одного атрибута (также как и потенциальный ключ записей в таблице).
Для множественных полюсов указываются типы: множество {set}, упорядоченное множество {ordered}, мультимножество {bag}, упорядоченное мультимножество {sequence}. На диаграммы могут быть явно указаны классы-контейнеры (список, хэш-таблица и проч.). Классам с необязательными связями добавляются операции проверки, существования соединения между их экземплярами.
Связи обобщения могут преобразовываться в ситуациях с так называемой метаморфозой подтипов, когда есть необходимость менять тип объектов (например, преобразовывать студента-заочника в студента дневного отделения или наоборот).
В модели добавляются ограничения. Для их записи используется язык OCL, рассмотренный в лекции 4.
Проектирование баз данных производится, если используется реляционная БД, при этом классы-сущности объектной модели отображаются в таблицы реляционной БД. Подробное рассмотрение вопросов проектирования БД содержится в лекции 9.
Литература к лекции 8
-
Кулямин В. В. Технологии программирования. Компонентный подход. – М.: Бином. Лаборатория знаний. 2007. Лекция 4.
-
Рамбо Дж., Блаха М. UML 2.0. Объектно-ориентированное моделирование и разработка. 2-е изд.: Пер. с англ. – СПб.: Питер, 2007. – Главы 14, 15.
-
Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения.: Пер. с англ. – СПб.: Питер, 2002. – Глава 9.
-
Вендров А. М. Проектирование программного обеспечения экономических информационных систем. 2-е изд. – М.: Финансы и статистика, 2005. – Глава 4.
-
Коналлен Дж. Разработка Web-приложений с использованием UML.: Пер. с англ. – М.: Вильямс, 2001. – Глава 10.