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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для множественных полюсов указываются типы: множество {set}, упорядоченное множество {ordered}, мультимножество {bag}, упорядоченное мультимножество {sequence}. На диаграммы могут быть явно указаны классы-контейнеры (список, хэш-таблица и проч.). Классам с необязательными связями добавляются операции проверки, существования соединения между их экземплярами.

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

Лекция 9. Проектирование баз данных

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

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

База данных – долговременное самодокументированное хранилище данных. Самодокументация = схема данных, хранящаяся в БД.

Система управления базами данных (СУБД) – ПО доступа к данным. Обеспечивает:

• защиту данных;

• эффективность;

• многопользовательский режим;

• разделение данных между несколькими приложениями;

• распределенность данных;

• безопасность.

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

Оператор SQL – предложение SQL для манипуляции данными (выборка, изменение, добавление, удаление).

Ограничения – условия, являющиеся частью схемы БД. Если какая-либо добавляемая запись нарушает какое-то ограничение, то она не будет добавлена.

Виды ограничений:

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

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

Внешний ключ – ссылка из другой таблицы на возможный ключ.

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

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

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

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

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

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

Отображение классов

1. Каждый класс переводится в отдельную таблицу, атрибуты становятся столбцами таблицы. Операции на структуру таблицы не влияют. Они могут переводиться в хранимые процедуры, если мы ходим переложить часть работы по манипулированию данными на СУБД.

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

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

Отображение бинарных ассоциаций:

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

• «1 к 0..1» – внешний ключ добавляется к таблице необязательного класса.

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

• «0..1 к 0..1» – рекомендуется отдельная таблица для связи. Ее столбцы – внешние ключи для таблиц классов, связанных ассоциацией. Основной ключ – комбинация этих столбцов.

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

• «* к *» – для ассоциации заводится отдельная таблица. Ее столбцы – внешние ключи для таблиц классов, связанных ассоциацией. Основной ключ – комбинация этих столбцов.

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

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

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