Конспект по курсу. Объектно ориентированный анализ и проектирование (1133667), страница 15

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

Текст из файла (страница 15)

• вычисления в системе обладают высокой интенсивностью;

• в системе одновременно работает много пользователей.

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

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

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

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

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

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

Реализация процессов и потоков обеспечивается средствами операционной системы.

Д ля моделирования структуры потоков управления используются так называемые активные классы – классы со стереотипами <<process>> и <<thread>>. Активный класс владеет собственным процессом или потоком и может инициировать управляющие воздействия. Связи между процессами моделируются как зависимости. Потоки могут существовать только внутри процессов, поэтому связи между процессами и потоками моделируются как композиции. Модель потоков управления помещается в пакет Process View (представление процессов – одно из архитектурных представлений в модели «4+1»). В качестве примера приведена диаграмма классов, описывающая структуру процесса регистрации студента на курсы. Обратите внимание, что все классы на ней являются активными (выделены жирными границами).

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

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

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

• CourseCatalogSystemAccess – управляет доступом к системе каталога курсов. Один и тот же объект данного класса используется всеми пользователями при доступе к каталогу курсов.

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

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

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

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

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

Распределенная сетевая конфигурация системы моделируется с помощью диаграммы размещения. Диаграмма размещения – это единственная диаграмма, входящая в состав представления размещения – одного из архитектурных представлений, входящих в модель «4+1» Основные элементы диаграммы размещения:

• узел (node) – вычислительный ресурс (процессор или другое устройство: дисковая память, контроллеры различных устройств и т.д.). Для узла можно задать выполняющиеся на нем процессы.

• соединение (connection) – канал взаимодействия узлов (сеть).

Распределение процессов, составляющих структуру потоков управления, по узлам сети производится с учетом следующих факторов:

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

• время отклика;

• минимизация сетевого трафика;

• мощность узла;

• надежность оборудования и коммуникаций.

П
ример – диаграмма размещения для системы регистрации на курсы:

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

• Имена элементов модели должны отражать их функции. Следует избегать подобных имен и синонимов.

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

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

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

• При обновлении элемента модели должны обновляться соответствующие реализации вариантов использования.

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

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

Следующий этап – проектирование подсистем, осуществляемое разработчиками. Оно включает в себя следующие действия:

• Распределение поведения подсистемы по ее элементам

  • документирование взаимодействия элементов подсистемы в виде коопераций («реализаций интерфейса»);

  • построение одной или более диаграмм взаимодействия для каждой операции интерфейса подсистемы/

• Документирование элементов подсистемы (в виде диаграмм классов).

• Описание зависимостей между подсистемами.

П
ример:

Рис.Диаграмма кооперации, описывающая реализацию интерфейсной операции getCourseOfferings() в подсистеме CourseCatalogSystem.

Заметим, что реализация подсистемы CourseCatalogSystem выполнена созданием экземпляра механизма JDBC, т. е. подстановкой класса DBCourseOffering вместо роли DBClass, CourseOffering – вместо PersistentClass, CourseOfferingList – вместо PersistentClassList, CourseCatalogSystem вместо PersistencyClient. То есть, берется шаблонная диаграмма взаимодействия из модели механизма и уточняется подстановкой конкретных классов. Аналогично будет получена диаграмма классов, описывающая структурные связи подсистемы.

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

Р ис. Связывание образца JDBC с конкретными классами системы

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

1. детализация проектных классов;

2. уточнение операций и атрибутов;

3. моделирование состояний для классов;

4. уточнение связей между классами.

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

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

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

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

Обязанности классов, определенные в процессе анализа и документированные в виде «операций анализа», преобразуются в операции, которые будут реализованы в коде. При этом:

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

• определяется полная сигнатура операции;

• создается краткое описание операции, включая смысл всех ее параметров;

• определяется видимость операции: public (+), private (–), protected (#) или package (~);

• определяется область действия операции: операция объекта или операция класса.

Уточнение атрибутов классов заключается в следующем:

• задается его тип атрибута и значение по умолчанию (необязательно);

• задается видимость атрибутов: public (+), private (–), protected (#) или package (~);

• при необходимости определяются производные (вычисляемые) атрибуты (/).

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

• события вызова соотносятся с вызываемыми операциями класса;

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

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

В
процессе проектирования связи между классами подлежат уточнению.

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

• безраздельно обладает (зависимость по существованию, транзитивность, асимметричность, стационарность);

• обладает (зависимость по существованию, транзитивность, асимметричность).

Примеры: университет -> факультет -> кафедра; здание -> этаж здания.

Виды агрегаций:

• включает (зависимость по существованию, транзитивность);

• участник (нет ограничений).

Примеры: автомобиль -> колесо; предприятие -> сотрудник.

Характеристики

Список файлов лекций