Объектная Модель: зачем она нужна и как ее описать. Объектная модель
Объект – уникально определяемая сущность, которая содержит атрибуты, описывающие состояния объекта реального мира и связанные с ними действия (правила поведения). Во многом объект и сущность РБД совпадает по свойствам, однако сущность моделирует только состояние, а объект инкапсулирует и правила поведения.
Среди атрибутов объекта выделяется ссылочный атрибут: он содержит значение/коллекцию значений, которое само является объектом. Иначе говоря, ссылочный атрибут концептуально аналогичен внешнему ключу в РБД или указателям в ЯП.
Каждому объекту в момент создания присваивается идентификатор объекта OID. Он обладает следующими свойствами:
1. Генерируется системой
2. Уникально обозначает этот объект
3. Его нельзя изменить пока объект продолжает существовать
4. После создания объекта его идентификатор нельзя использовать повторно в дальнейшем при любых условиях.
5. Не зависит от значений атрибутов объекта, т.е. 2 объекта могут и иметь одинаковое состояние, но они всегда обладают разными OID.
6. В идеале – OID скрыто от пользователей.
За счет OID целостность сущностей гарантируется автоматически.
Объект инкапсулирует не только данные, но и функции (методы). В объектной базе методы могут изменять состояние объекта за счет изменения значений атрибутов или для создания запроса по отношению к определенным значениям конкретных атрибутов.
Сообщения – средство взаимодействия объектов. Содержательно сообщения – запрос одного объекта (отправителя) к другому (получателю), где второму объекту предлагается выполнить один из его методов.
Классы – группировка одинаковых объектов.
Наследование – один класс определяется как частный случай (подкласс) более общего класса (суперкласс). Подкласс наследует все свойства суперкласса + доп. определяет свои собственные атрибуты и методы. Все экземпляры под класса являются экземплярами суперкласса. Принцип подстановки: экземпляр под класса всегда может пользоваться любым методом/атрибутом суперкласса или в любой конструкции, где используется суперкласс. Понятие под-, суперкласса и наследования существует также в расширенной РБД модели. Однако в чисто объектной модели наследование относится и к состоянию и к поведению.
Перегрузка позволяет повторно использовать имя метода в одном или нескольких методах класса. Частный случай перегрузки – перекрытие. Оно позволяет заново определить имя свойства в некотором подклассе.
Динамическое связывание позволяет отложить линковку до выполнения.
Объектные модели
Объектная модель поволяет решить некоторые проблемы связанные с некоторыми реляционными базами.
Проблемы:
1. Поддержка нескольких версий
Управление версиями- это процесс сопровождения эволюциями объекта.
Механизм отслеживания версий должен управлять изменениями свойств объектов так, чтобы ссылки на объект всегда указывали на правильную версию.
Для управления версиями выделяются три типа версий: 1) временная версия- считается нестабильной, может быть удалена или обновлена, хранится в закрытом рабочем пространстве разработчика проекта.
2) Рабочая версия - считается более стабильной, не может быть обновлена, но может быть удалена ее создателем, так же хранится в закрытом рабочем пространстве разработчика.
3) Выпущенная версия (релиз)-считается стабильной, не может быть обновлена или удалена, хранится в открытой базе и помещается туда в следствии извлечения рабочей версии из закрытого пространства разработчика.
2. Поддержка продолжительных транзакций
Для пользователя который инициировал долговременную транзакцию важно сохранять какие то промежуточные результаты на случай сбоя транзакции, например из за конфликта блокировок.
Вырианты решения проблем: 1) вводится протокол управления параллельным выполнением с временными метками.
Для каждого элемента данных в базе хранятся тройки величин соответствующих каждой смене значения элемента. Мы храним собственное значение элемента версии, мы храним последнюю отметку открытия версии, временную отметку записи версии.
В этом случае нескольким транзакциям разрешается читать и записывать разные версии одного и того же элемента данных.
Версии могут быть удалены сразу после полного завершения всей транзакции.
1) Определяется временная отметка самой старой транзакции в системе, все то ниже этой транзакции удалятется.
2) Вводятся усовершенствованные модели транзакциий. (полная транзакция раскладывается в древовидную структуру сумм транзакций которые выполняются в параллельном режиме.
3) Использование точек сохранения и эммуляция вложенных транзакций. (Точкой сохранения называется некоторой точкой плоской транзакции, которая используется как точка промежуточного перезапуска.
4) Механизм хроник (саги) субд гарантирует что либо все входящие в хронику транзакций будут завершены, либо будут запущены компенсирующие транзакции.
3. Поддержка эволюции проекта т.е. Имеются гибкие средства динамического определения и изменения схемы базы.
Для этого применяются различные креативные подходы, например в некоторых продуктах вводятся инвариантные схемы, которые недолжны изменяться при любой модификации.
В целом методы модификации базы основываются на наличии или искуственном введении в объекты системы частично частичной упорядоченности (упорядоченности типа #) это невозможно в реляционных базах.
Недостаток: практически объектная база пишется в ручную.
В объектной базе имеются аналогии с основными приемами работы в реляционной базе.
Нормализация в объектной базе означает - каждый атребут объекта, должен зависеть от идентификатора объекта.
Связи в объектной базе предствалены с помощью ссылочных атребутов.
Ссылочная целостность.
Варианты управления: 1) пользователю запрещается явно удалять объекты, система сама удаляет объекты которые становятся недоступными.
2) пользователю разрешается удалять объекты когда они становятся ненужными, тогда система автоматически обнаруживает недействительные ссылки и присваивает недействительную ссылку NULL.
3) пользователю разрешается изменять и удалять объекты, а система использует обратные атребуты.
ОБЩАЯ ХАРАКТЕРИСТИКА ОБЪЕКТНО РЕЛЯЦИОННОЙ МОДЕЛИ ДАННЫХ
Общая идея ОР модели состоит в дополнении Р модели объектно ориентированными возможностями, а именно добавляется расширяемая пользователем система типов данных, добавляется инкапсуляция, наследование и полиморфизм, добавляется использование сложных объектов, и добавляется идентификация объектов.
Приемущества: повторное и совместное использование стандартных компонентов.
Сервер субд дополняется стандартными функциями которые ненужно писать в виде исполняемого кода в составе отдельных приложений.
Пример поддерки линейного программирования, когда функции исполняются центролизованно.
Возможность постепенного перехода к объектным методам с повышением уровня квалификации пользователей.
Недостатки: Искажение объектной идеологии.
РАСШИРЕННЫЙ СТАНДАРТ SQL 3. ОСНОВА ДЛЯ ПОСТРОЕНИЯ ОБЪЕКТНО РЕЛЯЦИОННЫХ БД
Включает: конструкторы типов, строка целиком может сохраняться в виде переменных или передаваться как параметр или возвращаться в результата вызова функции.
Разрешаются определяемые пользователем типы, процедуры, функции, операторы.
Как правило процедуры или функции пишутся вне СУБД, и вызываются в SQL с помощью оперотора CALL.
Конструкторы для типов коллекции: создается единственная таблица в которой имеется несколько уровней вложенности.
Поддержка больших объектов. Большой объект - поле таблицы которое содержитпрои значительное количество данных.
В стандарте SQL содержится три топа больших объектов:
1) большой двоичный объект
2) большой символьный объект
В стандарте SQL 3 допускается выполнение некоторых операций с объектами: например оператор конкатенации - возвращает символьную строку образованную соединением символьных строк в указанном порядке.
Есть функции извлечения символьной подстроки:
Функция перекрытия строк.
Функция свертки преобразования регистра.
Функция вычисления длины строки.
МОДЕЛЬ ХРАНИЛИЩА ДАННЫХ
Хранилище данных- это предметно ориентированный, интегрированный, привязанный ко времени и не изменяемый набор данных, предназначенный для поддержки принятия решений.
Хранилище данных имеет много общего с реляционной моделью.
1) Хранилище данных организуется не вокруг областей деятельности, а вокруг (предметов, товаров и др.).
2) Данные не обновляются, а только пополняются.
3) Реляционная база проектируется с целью обеспечения интенсивной обработки небольшого количества транзакций, хранилище данных проектируется для обработки единичных произвольных запросов.
4) Базовым объектом модели хранилища является привязанный ко времени факт.
5) Основная операция это агрегирование и основная проблема максимальная скорость доступа к факту.
Хранилище данных.
Базы данных в концепции хранилища описываются с использованием метода «моделирование размерностей».
Каждая модель такого метода состоит из таблицы с составным первичным ключем (таблица фактов), к которому привязан набор небольших фактов (таблиц размерностей).
Каждая таблица размерностей имеет не составной(простой) первичный ключ, который точно соответствует одному из компонентов составного ключа в таблице фактов
Схема звезда - логическая структура в центре которой находится таблица фактов, окруженная содержащими ссылочные данные таблица размерностей, при этом таблицы размерностей, как правило, нормализованы. (посмотреть схему звезды)
Таблицы фактов, как правило, имеют огромный размер по сравнению с таблицами размерностей, большая часть в таблице фактов это числовые данные и результаты сложения чисел.
В хранилищах данных практически никогда не происходит к единичным записям, базовая операция для них это агрегирование.
В тоже время таблица размерностей обычно содержит описательную текстовую информацию, при это атрибуты размерностей используются в качестве ограничений в запросах к хранилищу данных.
Применимость концепции хранилища данных находится в прямой зависимости от удачного структурирования таблицы размерностей.
Схема звезда позволяет ускорить выполнение запросов путем денормализации, т. к. выделяет сущности, к которым часто осуществляется доступ, но денормализацию не следует применять, если дополнительные данные требуются не очень часто.
Схема снежинка - вариант схемы звезда, в которой каждая размерность может иметь своих собственные размерности.
Приимущество хранилищ данных:
1. Эффективность - единообразие структуры обеспечивает более эффективный доступ к данным, независимо от средств доступа.
2. Все размерности в равной степени обеспечивают доступ к таблице фактов, следовательно проект обладает большей способность поддерживать произвольные запросы пользователя.
3. Расширяемость - типичные изменения:
1. Добавление новых фактов, это можно делать при условии, что они имеют такую же степень детализации, как и таблица фактов.
2. Добавление новых размерностей - возможно при условии, что имеется единственное значение данной размерностей, определенное для каждой существующей записи в таблице фактов.
3. Добавление новых атрибутов.
4. Разбиение существующих размерностей на записи с меньшим уровнем детализации, н начиная с определенного момента времени.
Модель данных OLAP
Таблица в реляционной СУБД представляет многомерные данных только в 2-х измерения, теория многомерных кубов использует, которые удобно представлять в виде пространства с размерностью n, каждая сторона такого куба может быть интерпретирована как двумерная таблица.
В каждой ячейке куба находится отдельный факт, а совокупность координат этой ячейки представляет собой полный массив данных об этом факте.
1. Многомерные БД очень компактны, они обеспечивают простые средства просмотра и манипулирования элементам и данных.
2. Куб легко расширяется, можно каждую ячейку куба развернуть в подкуб.
3. Существует мощнейший мат аппарат для работы с многомерными кубами, это матрицы.
1. С ростом числа размерностей кол-во ячеек в кубе возрастает экспоненциально, время обработки многомерного запроса увеличивается.
2. Как правило такие структуры представляют собой сильно разреженные матрицы. Много NULL.
Для создания эффективной многомерной базы возможно несклолько путей:
1. Выявить иерархическую структуру в данных.
2. Выявить другие порядки типа решетка типичных размерностей.
3. Разбиение гиперкуба на много маленьких кубов с заполненными ячейками.
Таким образом независимо от структуры хранения эффективность определяется метаданными, тоесть ожидаемыми вариантами размещения данных.
Модель слабоструктурированных данных
Слабостр. - называются данные, которые обладают определенной структурой, но эта структура оказывается непостоянна, недостаточно изученной или неполной. Как правило, такие данные не м. б. описаны с помощью одной неизменной схемы.
Если в СУБД должны храниться слабоструктурированные данные, то субд должна формировать схему на основе этих данных.
Большенство подходов к управлению такими данными использует языки запросов, обеспечивающие прохождение по древовидному, размеченному графу. Соответственно выполнение запросов становиться не деклоративными, а традиционными.
Варианты записи слабоструктурированных данных:
1. Модель обмена объектными данными OEM. Модель представления множенных объектов, определяется сама через себя. Позволяется отобразить данные с нерегулярной структурой и неопределенным типом. Представляется собой размеченный, ориентированный граф, в узлах которого находятся особые объекты (объекты OEM), для каждого объекта задаются уникальный идентификатор, описательная текстовая метка, тип, значение. Объекты подразделяются на элементарные и составные. Элементарные - это листья, они на графи отображаются без исходящих ребер. все остальные называются составными, при чем один и тот же объект может иметь произвольное число родительских объектов. Тип конкретного объекта определен как множество ИД объекта. Работать с конструкциями подобного типа тяжело, т. к. невозможно выделить пустую структуру графа.
2. Язык XML - мета язык, язык для описания других языков. Система определения структурированных типов документов и языков разметки, представляющих экземпляры документов данного типа. Достоинтсва:
1. Может применяться для разметки любых документов, в том числе текстовых и мультимедийных.
2. Позволяется наглядно описать структуру данных. Можно использовать для описания гетерогенных (разнородны) БД.
3. Позволяет хранить содержимое документа и отдельно (независимо) способ его представления.
Реляционная алгебра и реляционное исчисление
Язык SQL поддерживает алгеброические формулировки выполнения запроса, алгеброическая формулировка является процедурной, то есть она в явном виде задает последовательность действий для выполнения запроса.
Существует альтернативный вариант для описания запроса который называется логические исчисления.
Существует два варианта реляционной логики - это исчисление кортежей, и исчисление доменов.
Исчисление кортежей - переменной является кортеж(строчка) тела отношения.
Для формирования условий выборки из набора отношений используются так называемые правильно построенные формулы (well formed formula) - это условия накладываемые на кортежные переменные.
Пример: СЛУЖАЩИЙ СЛ_НОМ= НАЧАЛЬНИК НАЧ_НОМ
Для построения WFF используются логические связки и правила мат логики.
Механизм работы: Система перебирает все имеющиеся в бд комбинации кортежей, например для каждого кортежа проект, просматривается облать определений кортежей служащих и выделяет те сочетания кортежей для которых WFF верно.
Таким образом это эквивалентно тому, что система по умолчанию выполняет операцию join.
Исчисление доменов: Основное формальное отличие исчисления доменов от исчисления кортежей - это наличие дополнительного множества предикатов, позволяющих выделить условие членства.
Сопостовление Реляционной алгебры и Реляционного исчисления.
Формально между ними есть отличия, однако с точки зрения исполняющей системы реляционная алгебра и реляционные исчисления логически эквивалентны. Каждое выражение реляционной алгебры может быть однозначно преобразованно в выражение реляционного исчисления и наоборот.
Примеры: Субд которые работают на линукс это INGRES (Integratie graphics retrielale System)(хз че написано у нее подчерк кривой).
И язык табличная форма Query by Example
Теперь у нас есть все необходимые понятия, чтобы описать процесс построения объектной модели. Этот процесс включает в себя следующие этапы:
· определение объектов и классов;
· подготовка словаря данных;
· определение зависимостей между объектами;
· определение атрибутов объектов и связей;
· организация и упрощение классов при использовании наследования;
· дальнейшее исследование и усовершенствование модели.
2.2.1. Определение классов. Анализ внешних требований к проектируемой ПС позволяет определить объекты и классы объектов, связанные с прикладной проблемой, которую должна решать эта система. Все классы должны быть осмыслены в рассматриваемой прикладной области; классов, связанных с компьютерной реализацией, как например список, стек и т.п. на этом этапе вводить не следует.
Начать нужно с выделения возможных классов из письменной постановки прикладной задачи (технического задания и другой документации, предоставленной заказчиком). Следует иметь в виду, что это очень сложный и ответственный этап разработки, так как от него во многом зависит дальнейшая судьба проекта.
При определении возможных классов нужно постараться выделить как можно больше классов, выписывая имя каждого класса, который приходит на ум. В частности, каждому существительному, встречающемуся в предварительной постановке задачи, может соответствовать класс. Поэтому при выделении возможных классов каждому такому существительному обычно сопоставляется возможный класс.
· избыточные классы: если два или несколько классов выражают одинаковую информацию, следует сохранить только один из них;
· нерелевантные (не имеющие прямого отношения к проблеме) классы : для каждого имени возможного класса оценивается, насколько он необходим в будущей системе (оценить это часто бывает весьма непросто); нерелевантные классы исключаются;
· нечетко определенные (с точки зрения проблемы) классы (см. п. 2.3.1);
· атрибуты : некоторым существительным больше соответствуют не классы, а атрибуты; такие существительные, как правило, описывают свойства объектов (например, имя, возраст, вес, адрес и т.п.);
· операции : некоторым существительным больше соответствуют не классы, а имена операций (например, телефонный_вызов вряд ли означает какой-либо класс);
· роли : некоторые существительные определяют имена ролей в объектной модели (например, владелец, водитель, начальник, служащий; все эти имена связаны с ролями в различных зависимостях объектов класса человек);
· реализационные конструкции : именам, больше связанным с программированием и компьютерной аппаратурой, не следует на данном этапе сопоставлять классов, так как они не отражают особенностей проектируемой ПС; примеры таких имен: подпрограмма, процесс, алгоритм, прерывание и т.п.
После исключения имен всех ненужных (лишних) возможных классов будет получен предварительный список классов, составляющих проектируемую систему.
2.2.2. Подготовка словаря данных. Отдельные слова имеют слишком много интерпретаций. Поэтому необходимо в самом начале проектирования подготовить словарь данных , содержащий четкие и недвусмысленные определения всех объектов (классов), атрибутов, операций, ролей и других сущностей, рассматриваемых в проекте. Без такого словаря обсуждение проекта с коллегами по разработке и заказчиками системы не имеет смысла, так как каждый может по-своему интерпретировать обсуждаемые термины. Пример словаря см. в п. 2.3.2.
2.2.3. Определение зависимостей. На следующем этапе построения объектной модели определяются зависимости между классами. Прежде всего из классов исключаются атрибуты, являющиеся явными ссылками на другие классы; такие атрибуты заменяются зависимостями. Смысл такой замены в том, что зависимости представляют собой абстракцию того же уровня, что и классы, и потому не оказывают непосредственного влияния на будущую реализацию (ссылка на класс лишь один из способов реализации зависимостей).
Аналогично тому, как имена возможных классов получались из существительных, встречающихся в предварительной постановке прикладной задачи, имена возможных зависимостей могут быть получены из глаголов или глагольных оборотов , встречающихся в указанном документе. Так обычно описываются: физическое положение (следует_за, является_частью, содержится_в), направленное действие (приводит_в_движение), общение (разговаривает_с), принадлежность (имеет, является_частью) и т.п. Пример выделения явных и неявных глагольных оборотов из предварительной постановки конкретной прикладной задачи рассмотрен в п. 2.3.3.
Затем следует убрать ненужные или неправильные зависимости, используя следующие критерии:
· зависимости между исключенными классами должны быть исключены, либо переформулированы в терминах оставшихся классов (см. п. 2.3.3);
· нерелевантные зависимости и зависимости, связанные с реализацией, должны быть исключены (см. п. 2.3.3);
· действия: зависимость должна описывать структурные свойства прикладной области, а не малосущественные события (см. п. 2.3.3);
· тренарные зависимости: большую часть зависимостей между тремя или большим числом классов можно разложить на несколько бинарных зависимостей, используя в случае необходимости квалификаторы (см. п. 2.3.3); в некоторых (редких) случаях такое разложение осуществить не удается; например, тренарная зависимость "Профессор читает курс в аудитории 628" не может быть разложена на бинарные без потери информации;
· производные зависимости: нужно исключать зависимости, которые можно выразить через другие зависимости, так как они избыточны (см. п. 2.3.3); при исключении избыточных (производных) зависимостей нужно быть особенно осторожным, так как не все дублирующие одна другую зависимости между классами избыточны; в некоторых случаях другие зависимости позволяют установить только существование еще одной производной зависимости, но не позволяют установить кратность этой зависимости; например, в случае, представленном на рис. 2.36, фирма имеет много служащих и владеет многими компьютерами; каждому служащему предоставлено для персонального использования несколько компьютеров, кроме того, имеются компьютеры общего пользования; кратность зависимости предоставлен_для_использования не может быть выведена из зависимостей служит и владеет; хотя производные зависимости и не добавляют новой информации, они часто бывают удобны; в этих случаях их можно указывать на диаграмме, пометив косой чертой.
Рис. 2.36. Неизбыточные зависимости
Удалив избыточные зависимости, нужно уточнить семантику оставшихся зависимостей следующим образом:
· неверно названные зависимости: их следует переименовать, чтобы смысл их стал понятен (см. п. 2.3.3);
· имена ролей: нужно добавить имена ролей там, где это необходимо; имя роли описывает роль, которую играет соответствующий класс в данной зависимости с точки зрения другого класса, участвующего в этой зависимости; если имя роли ясно из имени класса, его можно не указывать (см. п. 2.3.3);
· квалификаторы: добавляя квалификаторы там, где это необходимо, мы вносим элементы контекста, что позволяет добиться однозначной идентификации объектов; квалификаторы позволяют также упростить некоторые зависимости, понизив их кратность;
· кратность: необходимо добавить обозначения кратности зависимостей; при этом следует помнить, что кратность зависимостей может меняться в процессе дальнейшего анализа требований к системе;
· неучтенные зависимости должны быть выявлены и добавлены в модель.
2.2.4. Уточнение атрибутов. На следующем этапе уточняется система атрибутов: корректируются атрибуты классов, вводятся, в случае необходимости, новые атрибуты. Атрибуты выражают свойства объектов рассматриваемого класса, либо определяют их текущее состояние.
Атрибуты обычно соответствуют существительным; например цвет_автомобиля (свойство объекта), позиция_курсора (состояние объекта). Атрибуты, как правило, слабо влияют на структуру объектной модели.
Не следует стремиться определить как можно больше атрибутов: большое количество атрибутов усложняет модель, затрудняет понимание проблемы. Необходимо вводить только те атрибуты, которые имеют отношение к проектируемой прикладной системе, опуская случайные, малосущественные и производные атрибуты.
Наряду с атрибутами объектов необходимо ввести и атрибуты зависимостей между классами (связей между объектами).
При уточнении атрибутов руководствуются следующими критериями:
· Замена атрибутов на объекты . Если наличие некоторой сущности важнее, чем ее значение, то это объект, если важнее значение, то это атрибут: например, начальник - это объект (неважно, кто именно начальник, главное, чтобы кто-то им был), зарплата - это атрибут (ее значение весьма существенно); город - всегда объект, хотя в некоторых случаях может показаться, что это атрибут (например, город как часть адреса фирмы); в тех случаях, когда нужно, чтобы город был атрибутом, следует определить зависимость (скажем, находится) между классами фирма и город.
· Квалификаторы . Если значение атрибута зависит от конкретного контекста, его следует сделать квалификатором (см. п. 2.3.4).
· Имена . Именам обычно лучше соответствуют квалификаторы, чем атрибуты объектов; во всех случаях, когда имя позволяет сделать выбор из объектов некоторого множества, его следует сделать квалификатором (см. п. 2.3.4).
· Идентификаторы . Идентификаторы объектов связаны с их реализацией. На ранних стадиях проектирования их не следует рассматривать в качестве атрибутов.
· Атрибуты связей . Если некоторое свойство характеризует не объект сам по себе, а его связь с другим объектом (объектами), то это атрибут связи, а не атрибут объекта.
· Внутренние значения . Атрибуты, определяющие лишь внутреннее состояние объекта, незаметное вне объекта, следует исключить из рассмотрения.
· Несущественные детали . Атрибуты, не влияющие на выполнение большей части операций, рекомендуется опустить.
2.2.5. Организация системы классов, используя наследование. Далее необходимо постараться найти суперклассы для введенных классов. Это полезно, так как проясняет структуру модели и облегчает последующую реализацию. Пример рассмотрен в п. 2.3.5.
2.2.6. Дальнейшее исследование и усовершенствование модели. Лишь в очень редких случаях построенная объектная модель сразу же оказывается корректной. Модель должна быть исследована и отлажена. Некоторые ошибки могут быть найдены при исследовании модели без компьютера, другие - при ее интерпретации совместно с динамической и функциональной моделями на компьютере (эти модели строятся после того, как объектная модель уже построена).
Здесь мы рассмотрим приемы бескомпьютерного поиска и исправления ошибок в объектной модели. В их основе лежат внешние признаки, по которым можно находить ошибки в модели; эти признаки могут быть объединены в следующие группы.
Признаки пропущенного объекта (класса):
· несимметричности связей и обобщений (наследований); для исправления ошибки необходимо добавить пропущенные классы;
· несоответствие атрибутов и операций у класса; для исправления ошибки необходимо расщепить класс на несколько других классов, так чтобы атрибуты и операции новых классов соответствовали друг другу;
· обнаружена операция, не имеющая удовлетворительного целевого класса; для исправления ошибки необходимо добавить пропущенный целевой класс;
· обнаружено несколько зависимостей с одинаковыми именами и назначением; для исправления ошибки необходимо сделать обобщение и добавить пропущенный суперкласс.
Признаки ненужного (лишнего) класса:
· нехватка атрибутов, операций и зависимостей у некоторого класса; для исправления ошибки необходимо подумать, не следует ли исключить такой класс.
Признаки пропущенных зависимостей:
· отсутствуют пути доступа к операциям; для исправления ошибки необходимо добавить новые зависимости, обеспечивающие возможности обслуживания соответствующих запросов.
Признаки ненужных (лишних) зависимостей:
· избыточная информация в зависимостях; для исправления ошибки необходимо исключить зависимости, не добавляющие новой информации, или пометить их как производные зависимости;
· не хватает операций, пересекающих зависимость; для исправления ошибки необходимо подумать, не следует ли исключить такую зависимость.
Признаки неправильного размещения зависимостей:
· имена ролей слишком широки или слишком узки для их классов; для исправления ошибки необходимо переместить зависимость вверх или вниз по иерархии классов.
Признаки неправильного размещения атрибутов:
· нет необходимости доступа к объекту по значениям одного из его атрибутов; для исправления ошибки необходимо рассмотреть, нужно ли ввести квалифицированную зависимость.
Примеры практического применения описанных признаков см. в п. 2.3.6.
Пример объектной модели
Рассмотрим процесс построения объектной модели для системы банковского обслуживания в процессе анализа требований и предварительного проектирования этой системы. Для построения объектной модели рассматриваемой системы нам необходимо выполнить все этапы, перечисленные в п 2.2.
2.3.1. Определение объектов и классов. В п. 1.3 сформулирована задача и приведена схема сети банковского обслуживания (рис. 1.3). Анализируя эту постановку задачи, можно выделить возможные классы, сопоставив их существительным, упомянутым в ее предварительной формулировке; получится следующий список возможных имен классов (в алфавитном порядке):
Исследуем этот список, исключая из него имена классов в соответствии с рекомендациями п. 2.2.1:
· избыточные классы : ясно, что клиент и пользователь означают одно и то же понятие; для банковской системы более естественно оставить класс клиент;
· нерелевантные классы : таким классом является класс цена (он не имеет непосредственного отношения к работе банковской сети);
· нечетко определенные классы : такими классами являются служба_ведения_записей и проверка безопасности (эти службы входят в состав проводки), система (в нашем случае непонятно, что это такое), банковская_сеть (вся ПС будет обслуживать банковскую сеть);
· атрибуты : данные проводки, данные счета, деньги (имеются в виду реальные деньги, выдаваемые клиенту кассиром или банкоматом, либо принимаемые кассиром), квитанция (выдается клиенту вместе с деньгами) более естественно иметь в качестве атрибутов;
· реализационные конструкции выражают такие имена как программное_обеспечение и доступ; их тоже следует исключить из списка имен возможных классов.
После исключения всех лишних имен возможных классов получаем следующий список классов, составляющих проектируемую систему банковского обслуживания (эти классы представлены на рис. 2.5):
2.3.2. Подготовка словаря данных. Приведем часть словаря данных, содержащую определения классов, используемых в проекте.
ATM (банкомат) - терминал, который дает возможность клиенту осуществлять свою собственную проводку, используя для идентификации свою карточку. ATM (банкомат) взаимодействует с клиентом, чтобы получить необходимую информацию для проводки, посылает информацию для проводки центральному_компьютеру, чтобы он проверил ее и в дальнейшем использовал при выполнении проводки и выдает деньги и квитанцию клиенту. Предполагается, что ATM (банкомату) не требуется работать независимо от сети.
Банк - финансовая организация, которая содержит счета своих клиентов и выпускает карточки, санкционирующие доступ к счетам через сеть ATM (банкоматов).
Карточка - пластиковая карточка, врученная банком своему клиенту, которая санкционирует доступ к счетам через сеть ATM (банкоматов). Каждая карточка содержит код банка и номер карточки, закодированные в соответствии с национальными стандартами на банковские карточки. Код_банка однозначно идентифицирует банк внутри консорциума. Номер_карточки определяет счета, к которым карточка имеет доступ. Карточка не обязательно обеспечивает доступ ко всем счетам клиента. Каждой карточкой может владеть только один клиент, но у нее может существовать несколько копий, так что необходимо рассмотреть возможность одновременного использования одной и той же карточки с разных ATM (банкоматов).
Кассир - служащий банка, который имеет право осуществлять проводки с кассовых_ терминалов, а также принимать и выдавать деньги и чеки клиентам. Проводки, деньги и чеки, с которыми работает каждый кассир, должны протоколироваться и правильно учитываться.
Кассовый_терминал - терминал, с которого кассир осуществляет проводки для клиентов. Когда кассир принимает и выдает деньги и чеки, кассовый_терминал печатает квитанции. Кассовый_терминал взаимодействует с компьютером_банка, чтобы проверить и выполнить проводку.
Клиент - держатель одного или нескольких счетов в банке. Клиент может состоять из одного или нескольких лиц, или организаций. То же самое лицо, держащее счет и в другом банке рассматривается как другой клиент.
Компьютер_банка - компьютер, принадлежащий банку, который взаимодействует с сетью ATM (банкоматов) и собственными кассовыми_терминалами банка. Банк может иметь свою внутреннюю компьютерную сеть для обработки счетов, но здесь мы рассматриваем только тот компьютер_банка, который взаимодействует с сетью ATM.
Консорциум - объединение банков, которое обеспечивает работу сети ATM (банкоматов). Сеть передает в консорциум проводки банков.
Проводка - единичный интегрированный запрос на выполнение некоторой последовательности операций над счетами одного клиента. Было сделано предположение, что ATM (банкоматы) только выдают деньги, однако для них не следует исключать возможности печати чеков или приема денег и чеков. Хотелось бы также обеспечить гибкость системы, которая в дальнейшем обеспечит возможность одновременной обработки счетов разных клиентов, хотя пока этого не требуется. Различные операции должны быть правильно сбалансированы.
Счет - единичный банковский счет, над которым выполняются проводки. Счета могут быть различных типов; клиент может иметь несколько счетов.
Центральный_компьютер - компьютер, принадлежащий консорциуму, который распределяет проводки и их результаты между ATM (банкоматами) и компьютерами_банков. Центральный_компьютер проверяет коды банков, но не выполняет проводок.
2.3.3. Определение зависимостей. Следуя рекомендациям п. 2.2.3, выделяем явные и неявные глагольные обороты из предварительной постановки задачи и рассматриваем их как имена возможных зависимостей. Из постановки задачи о банковской сети (см. п. 1.3) можно извлечь следующие обороты:
Глагольные обороты (явные и неявные):
Банковская сеть включает кассиров и ATM"ы
Консорциум распределяет результаты проводок по ATM
Банк владеет компьютером банка
Компьютер банка поддерживает счета
Банк владеет кассовыми терминалами
Кассовый терминал взаимодействует с компьютером банка
Кассир вводит проводку над счетом
ATM"ы взаимодействуют с центральным компьютером во время проводки
Центральный компьютер взаимодействует с компьютером банка
ATM принимает карточку
ATM общается с пользователем
ATM выдает наличные деньги
ATM печатает квитанции
Система регулирует коллективный доступ
Банк предоставляет программное обеспечение
Консорциум состоит из банков
Консорциум владеет центральным компьютером
Система обеспечивает протоколирование
Система обеспечивает безопасность
Клиенты имеют карточки
Карточка обеспечивает доступ к счету
В банке служат кассиры
Затем исключаем ненужные или неправильные зависимости, используя критерии, сформулированные в п. 2.2.3:
· зависимости между исключенными классами: исключаются следующие зависимости: Банковская сеть включает кассиров и ATM"ы (класс банковская_сеть исключен), ATM печатает квитанции (класс квитанция исключен), ATM выдает наличные деньги (класс деньги исключен), Система обеспечивает протоколирование проводок (класс служба_ведения_записей исключен), Система обеспечивает безопасность ведения счетов (класс служба_безопасности исключен), Банки предоставляют программное обеспечение (класс программное_обеспечение исключен);
· нерелевантные зависимости и зависимости, связанные с реализацией: зависимость "Система регулирует коллективный доступ" исключается как связанная с реализацией;
· действия описываются такими зависимостями как "ATM принимает карточку" и "ATM общается с пользователем"; мы исключаем эти зависимости;
· тренарные зависимости: зависимость "Кассир вводит проводку над счетом" раскладывается на две бинарные зависимости "Кассир вводит проводку" и "Проводка относится к счету". Зависимость "ATM"ы взаимодействуют с центральным компьютером во время проводки" раскладывается на "ATM"ы взаимодействуют с центральным компьютером" и "Проводка начинается с ATM";
· производные зависимости: зависимость "Консорциум распределяет ATM"ы" является следствием зависимостей "Консорциум владеет центральным компьютером" и "ATM"ы взаимодействуют с центральным компьютером".
Удалив избыточные зависимости, получим следующий список зависимостей:
Банк владеет компьютером банка
Компьютер банка поддерживает счета
Банк владеет кассовыми терминалами
Кассовый терминал взаимодействует с компьютером банка
Кассир вводит проводку
Проводка относится к счету
ATM"ы взаимодействуют с центральным компьютером
Проводка начинается с ATM
Центральный компьютер взаимодействует с компьютером банка
Консорциум состоит из банков
Консорциум владеет центральным компьютером
Клиенты имеют карточки
Карточка обеспечивает доступ к счету
В банке служат кассиры
Уточним семантику оставшихся зависимостей следующим образом:
· переименуем неверно названные зависимости, чтобы смысл их стал более понятен; так зависимость Компьютер_банка поддерживает счета удобнее заменить зависимостью Банк держит счета.
· имена ролей можно не использовать, так как они ясны из имен классов, участвующих в зависимости, как например, для зависимости ATM"ы взаимодействуют с центральным компьютером;
· неучтенные зависимости: Проводка начинается с кассового_терминала, Клиенты имеют счета, Проводка регистрируется карточкой следует добавить в модель.
После уточнения зависимостей можно составить исходную версию объектной диаграммы. Для рассматриваемой задачи она будет иметь вид, представленный на рис. 2.37.
Рис. 2.37. Первая версия объектной диаграммы для банковской сети
2.3.4. Уточнение атрибутов. Применяя критерии, сформулированные в п. 2.2.4, получим:
Карточка содержит код_банка и код_карточки; их можно считать атрибутами объектов класса карточка, но удобнее использовать в качестве квалификаторов, так как код_банка обеспечивает выбор банка, сокращая кратность зависимости консорциум - банк; для аналогичного использования кода_карточки необходимо добавить зависимость Банк выпускает карточки, квалификатором которой будет код_карточки.
После внесения перечисленных изменений диаграмма примет вид, представленный на рис. 2.38.
2.3.5. Организация системы классов с использованием наследования. В рассматриваемом примере естественно определить суперклассы для объектов, определяющих различные терминалы: кассовый_терминал и ATM (банкомат), и для объектов, определяющих проводки: проводка_кассира и удаленная_проводка (с банкомата).
Внеся соответствующие изменения, получим объектную диаграмму, представленную на рис. 2.39.
Рис. 2.38. Объектная диаграмма для банковской сети после уточнения атрибутов и добавления квалификаторов
Рис. 2.39. Объектная диаграмма для банковской с учетом наследования
2.3.6. Дальнейшее усовершенствование модели. Карточка выступает в двух сущностях: как регистрационная единица в банке (сберкнижка), обеспечивающая клиенту доступ к его счетам, и как структура данных, с которой работает ATM. Поэтому удобно расщепить класс карточка на два класса: регистрация_карточки и карточка; первый из этих классов обеспечивает клиенту доступ к его счетам в банке, а второй определяет структуру данных, с которой работает ATM.
Класс проводка удобно представить как агрегацию классов изменение, так как проводка - это согласованная последовательность внесения изменений в счета и другие банковские документы; при работе с банковскими документами рассматривается три вида изменений: снятие, помещение и запрос.
Класс банк естественно объединить с классом компьютер_банка, а класс консорциум - с классом центральный_компьютер.
Рис. 2.40. Окончательный вид объектной диаграммы для банковской сети
После внесения перечисленных изменений объектная диаграмма примет вид, представленный на рис. 2.40. На этом построение объектной модели этапа предварительного проектирования заканчивается. Дальнейшие уточнения объектной модели будут производиться на следующих фазах ЖЦ системы.
Выделение подсистем
2.4.1. Понятие подсистемы. Итак, ПС представляет собой множество взаимозависимых объектов. Каждый объект характеризуется набором атрибутов, значения которых определяют состояние объекта, и набором операций, которые можно применять к этому объекту. При разработке ПС удобно считать, что все атрибуты объектов являются закрытыми (т.е. они не доступны вне объекта, и для того, чтобы в некотором объекте узнать значение атрибута другого объекта, или изменить его, необходимо воспользоваться одной из открытых операций этого объекта, если, конечно, такая операция определена). Операции объектов могут быть как открытыми, так и закрытыми.
Таким образом, каждый объект имеет строго определенный интерфейс , т.е. набор открытых операций, которые можно применять к этому объекту. Все объекты одного класса имеют одинаковый интерфейс. Интерфейс класса (а, следовательно, и каждого объекта этого класса) задается списком сигнатур его открытых (общедоступных) операций (и реализующих их методов); сигнатуры закрытых операций в интерфейс объектов соответствующего класса не входят.
Объектная модель системы задает множество взаимозависимых объектов, составляющих систему, и, следовательно, определяет набор интерфейсов, доступных внутри системы. Все возможности по обработке данных внутри системы (т.е. в каждом объекте, входящем в состав системы) определяются этим набором интерфейсов, который определяет внутреннее окружение (или среду) системы .
Наряду с внутренним окружением системы можно определить ее внешнее окружение . Оно определяется функциями (операциями), реализованными в составе системного программного обеспечения (т.е. операционной системы, системы программирования, различных редакторов, СУБД и т.п.), а также в других прикладных системах и библиотеках, используемых совместно с системой. Объекты и операции, составляющие внешнее окружение системы, тоже могут быть доступны внутри системы. Чтобы не упустить этого из виду, можно было бы добавить в объектную модель еще один объект, интерфейс которого представлял бы возможности внешнего окружения, используемые в системе (такой интерфейс обычно представляет лишь часть возможностей внешнего окружения). Но это было бы не совсем точно, так как внешнее окружение реализуется не одним, а несколькими объектами. С другой стороны внутри системы нет резона рассматривать структуру ее внешнего окружения. Выход из указанного противоречия во введении в рассмотрение еще одной сущности - подсистемы.
Подсистема - это набор объектов и подсистем, обеспечивающих некоторую функциональность, и взаимодействующих между собой в соответствии с их интерфейсами. Интерфейс подсистемы представляет собой подмножество объединения интерфейсов всех объектов и подсистем, составляющих эту подсистему. В состав подсистемы может входить один, или более взаимозависимых объектов и/или подсистем.
Множество интерфейсов объектов (и подсистем), которые в своей совокупности составляют некоторую подсистему, составляет внутреннее окружение этой подсистемы. В состав каждой подсистемы должна быть включена подсистема окружение, представляющая внешнее окружение этой подсистемы. Подсистема окружение для системы банковского обслуживания, рассматриваемой в качестве сквозного примера представлена на рис. 2.41. Интерфейс подсистемы окружение определяет в каком программном окружении будет работать проектируемая система и какие возможности этого окружения будут использоваться во время ее работы (это важно, когда возникает потребность модификации или замены отдельных компонентов окружения).
Отметим, что подсистема окружение представляет только интерфейс системы банковского обслуживания с ее внешним окружением. Внешнее окружение системы банковского обслуживания состоит из нескольких подсистем и библиотек, и для него тоже может быть разработана объектная модель, которая может содержать и разрабатываемую систему (в этой объектной модели она будет одной из подсистем).
Объектную модель системы банковского обслуживания и ее системного (внешнего) окружения тоже можно изобразить в виде объектной диаграммы (правда, в состав этой объектной диаграммы будут входить не объекты, а только подсистемы; каждая подсистема изображается на диаграмме в виде прямоугольника с двойными вертикальными сторонами). Зависимости между подсистемами, изображенные на этой объектной диаграмме (рис. 2.42), отражают взаимодействие проектируемой системы банковского обслуживания и соответствующих подсистем в процессе работы системы. Тем самым определяются требования проектируемой системы к ее системному окружению.
Рис. 2.41. Объектная диаграмма банковской сети, в которой указан интерфейс с системным окружением
Рис. 2.42. Объектная диаграмма банковской сети и ее системного окружения
Введение понятия подсистемы и возможность включать в объектную модель наряду с объектами (классами) и подсистемы определяет иерархическую структуру объектной модели и позволяет использовать методологию OMT при проектировании достаточно сложных ПС, содержащих большое число различных объектов и классов.
2.4.2. Интерфейсы и окружения. Объекты и подсистемы, составляющие подсистему более высокого уровня, будем называть компонентами последней. Как уже было отмечено, для каждого компонента, входящего в состав объектной модели подсистемы, определен его интерфейс , т.е. набор открытых (общедоступных) операций, которые можно применять к этому компоненту (объекту или подсистеме).
Интерфейс объекта определяется интерфейсом соответствующего класса и задается списком сигнатур его открытых операций (методов). Интерфейс подсистемы определяется через итерфейсы составляющих ее объектов и подсистем следующим образом: операция может быть включена в интерфейс подсистемы, если в составе этой подсистемы имеется объект (подсистема), интефейс которого содержит эту операцию. Интерфейсы описываются на языке описания интерфейсов IDL (Interface Definition Language) .
Все возможности по обработке данных внутри подсистемы (т.е. в каждом компоненте, входящем в ее состав) определяются набором интерфейсов ее компонентов, который определяет внутреннее окружение подсистемы .
Если для некоторой подсистемы оказывается, что ни один ее компонент не содержит операции, которую желательно включить в ее интерфейс, в ее состав можно добавить объект, реализующий такую операцию. Такой объект называется интерфейсным объектом . Интерфейсные объекты позволяют согласовать внешний интерфейс подсистемы с ее внешним окружением , т.е. с интерфейсами других объектов и подсистем, которые вместе с рассматриваемой подсистемой составляют подсистему более высокого уровня.
Поясним введенные понятия на примере системы банковского обслуживания. В ее составе можно выделить подсистему банк (на самом деле в системе будет несколько экземпляров подсистемы банк - по одной для каждого банка, входящего в консорциум). При этом объектная модель системы примет вид, изображенный на рис. 2.43.
Рис. 2.43. Объектная диаграмма банковской сети после выделения подсистемы банк
При этом внешние интерфейсы подсистем банк и окружение вместе с интерфейсами объектов ATM и консорциум образуют внутреннее окружениесистемы банковского обслуживания. Ее внешнее окружение представлено на рис. 2.42; оно состоит из внешних интерфейсов различных программных систем, используемых в системе банковского обслуживания (на рис. показана лишь часть этих систем), и ее собственного внешнего интерфейса.
Объектная модель (Главное меню → Отчёты → Объектная модель ) служит для просмотра описания справочников. Для каждого справочника отображается информация о его назначении, составе его параметров и их назначении. Объектная модель необходима при работе с отчетами, так как из нее может быть получена информация, необходимая для формирования привязок к данным.
Объектная модель может быть открыта из Окна справочника , Окна свойств объекта или Окна списка с помощью сочетания клавиш Shift+F1. При этом в Объектной модели курсор будет позиционироваться на том параметре справочника, на котором был установлен курсор в окне, где было вызвано открытие Объектной модели .
В Объектной модели представлены три раздела: классы, перечисления и элементы списков.
Классы
Классы - раздел, в котором представлены описания справочников, хранимых в базе данных.
Объект справочника может являться значением объектного параметра другого объекта. Например, параметр "Тип документа" в справочнике "Бумажные документы" является объектным параметром, значением которого является один из объектов справочника "Типы документа".
Перечисления
Перечисления - раздел, в котором представлены описания справочников, используемых в параметрах в виде выпадающих списков. Перечисление ограничивает число возможных вариантов, оно не может изменяться. Например, в справочнике "Субъекты" значение параметра "Тип субъекта" является перечислением: Подразделение, Должность, Внешний субъект, Роль, Папка.
Элементы списков
Элементы списков - это справочники для хранения экземпляров (строк) параметров типа "Список". Список используется для реализации отношения "один-ко-многим". Список представляет собой набор объектов одного и того же класса (класса элементов списка). Например, в классе "Процессы" используется параметр-список "Нормативно-справочные документы". Строки этого списка хранятся в классе элементов списков "БизнесМодель.СписокНСДПроцессов", каждая строка связана с конкретным процессом отношением "один-ко-многим".
Также элементы списков используются для хранения параметров типа "Структура". В этом случае реализуется отношение "один-к-одному". Элемент структуры содержит свой набор параметров. Например, все "Объекты деятельности" имеют параметр-структуру "Параметры ФСА". Элементы структуры хранятся в виде строк класса элементов списков "БизнесМодель.СтоимостьОбъектовДеятельности", каждая строка связана с конкретным объектом деятельности отношением "один-к-одному".
Схема того, как в интерфейсе Business Studio представлены справочники, их параметры и объекты справочников, приведена на Рисунке 1.
Рисунок 1. Справочники, их параметры и объекты справочников в интерфейсе Business Studio
Работа с объектной моделью. Окно объектной модели
В окне справочника слева показывается дерево системных классов, справа - описание параметров класса.
По умолчанию показывается сокращенный список классов. Чтобы открыть полный список, нужно нажать на кнопку Показывать все панели инструментов окна. Кнопка Показывать все параметры включает показ полного списка параметров класса.
На панели инструментов Объектной модели также присутствуют навигационные кнопки:
На Рис. 2 показана Объектная модель , в которой открыто описание справочника "Процессы".
Рисунок 2. Описание справочника "Процессы" в Объектной модели
Для узлов в дереве также действует своё контекстное меню:
Рядом с названием класса в дереве показана иконка:
Над областью параметров находится панель поиска, введя значение в поле которой и нажав на кнопку Поиск можно найти строку параметра, содержащую введенную последовательность символов. Нажатие на кнопку Очистить очищает поле поиска, нажатие на кнопку скрывает панель поиска. Также управлять показом панели поиска можно при помощи пунктов меню Скрыть панель поиска и Показать панель поиска в контекстном меню строки заголовка списка параметров.
Параметры классов описываются свойствами, назначение которых приведено в Таблице 1.
| Свойство | Назначение |
|---|---|
| № | Номер параметра. |
| Название | Пользовательское название параметра. Отображается в Окнах свойств и заголовках списков. |
| Системное название | Системное название параметра. |
| Тип | Тип параметра: - простой параметр - "Строка", "Логический", "Целый", "Вещественный", "ДатаВремя", "Текст"; - "Объект"; - "Список"; - "Структура"; - "Перечисление". |
| Хранимый | Логика, показывающая, хранится параметр физически в базе данных или рассчитывается на основе имеющейся информации. Например, в справочнике "Физические лица" параметры "Фамилия", "Имя", "Отчество" являются хранимыми, они задаются пользователем, а параметр "ФИО" является нехранимым, рассчитываемым на основе этих параметров. Хранимые параметры рассчитываются в момент обращения к ним, например, при отображении в Окнах свойств и Окнах списков , при выполнении отчетов. |
Таблица 1. Свойства параметров
Для списка параметров класса действует контекстное меню.
Объектно-ориентированный подход основывается на совокупности ряда принципов, называемой объектной моделью. Главными принципами являются
- - абстрагирование;
- - инкапсуляция;
- - модульность;
- - иерархичность.
Эти принципы являются главными в том смысле, что без них модель не будет объектно-ориентированной. Кроме главных, назовем еще три дополнительных принципа:
- - типизация;
- - параллелизм;
- - сохраняемость.
Называя их дополнительными, мы имеем в виду, что они полезны в объектной модели, но не обязательны.
Абстрагирование
Люди развили чрезвычайно эффективную технологию преодоления сложности. Мы абстрагируемся от нее. Если мы не в состоянии полностью воссоздать сложный объект, то приходится игнорировать не слишком важные детали. В результате мы имеем дело с обобщенной, идеализированной моделью объекта.
Например, изучая процесс фотосинтеза у растений, мы концентрируем внимание на химических реакциях в определенных клетках листа и не обращаем внимание на остальные части - черенки, жилки и т.д.
Абстракция выделяет существенные характеристики некоторого объекта, отличающие его от всех других видов объектов, и, таким образом, четко определяет его концептуальные границы с точки зрения наблюдателя.
Абстрагирование концентрирует внимание на внешних особенностях объекта и позволяет отделить самые существенные особенности поведения от несущественных. Такое разделение смысла и реализации называют барьером абстракции. Установление того или иного барьера абстракции порождает множество различных абстракций для одного и того же предмета или явления реального мира. Абстрагируясь в большей или меньшей степени от различных аспектов проявления реальности, мы находимся на разных уровнях абстракции.
Для примера рассмотрим системный блок компьютера. Пользователю, использующему компьютер для набора текста, не важно, из каких частей состоит этот блок. Для него это - коробка белого цвета с кнопками и емкостью для дискеты. Он абстрагируется от таких понятий, как "процессор" или "оперативная память". С другой стороны, у программиста, пишущего программы в машинных кодах, барьер абстракции лежит намного ниже. Ему необходимо знать устройство процессора и команды, понимаемые им.
Является полезным еще один дополнительный принцип, называемый принципом наименьшего удивления. Согласно ему абстракция должна охватывать все поведение объекта, но не больше и не меньше, и не привносить сюрпризов или побочных эффектов, лежащих вне ее сферы применимости.
Например, нам необходимо использовать структуру данных, аналогичную стеку (с доступом, осуществляемым по правилу "первым вошел, последним вышел"), однако требуется проверять наличие в "стеке" некоторого элемента. Если мы назовем эту структуру данных стеком и предложим постороннему программисту, он очень удивится, заметив "лишнюю" операцию.
Все абстракции обладают как статическими, так и динамическими свойствами. Например, файл как объект требует определенного объема памяти на конкретном устройстве, имеет имя и содержимое. Эти атрибуты являются статическими свойствами. Конкретные же значения каждого из перечисленных свойств динамичны и изменяются в процессе использования объекта: файл можно увеличить или уменьшить, изменить его имя и содержимое.
Будем называть клиентом любой объект, использующий ресурсы другого объекта, называемого сервером. Мы будем характеризовать поведение объекта услугами, которые он оказывает другим объектам, и операциями, которые он выполняет над другими объектами. Этот подход концентрирует внимание на внешних проявлениях объекта и реализует так называемую контрактную модель программирования. Эта модель заключается в следующем: внешнее проявление объекта рассматривается с точки зрения его контракта с другими объектами, в соответствии с этим должно быть выполнено и его внутреннее устройство (часто - во взаимодействии с другими объектами). Контракт фиксирует все обязательства, которые объект-сервер имеет перед объектом-клиентом. Другими словами, этот контракт определяет ответственность объекта - то поведение, за которое он отвечает.
Каждая операция, предусмотренная контрактом, однозначно определяется ее сигнатурой - списком типов формальных параметров и типом возвращаемого значения. Полный набор операций, которые клиент может осуществлять над другим объектом, вместе с правильным порядком, в котором эти операции вызываются, называется протоколом. Протокол отражает все возможные способы, которыми объект может действовать или подвергаться воздействию. Тем самым протокол полностью определяет внешнее поведение абстракции.
Пример. В тепличном хозяйстве, использующем гидропонику, растения выращиваются на питательном растворе без песка, гравия и другой почвы. Управление режимом работы парниковой установки - очень ответственное дело. Оно зависит как от вида выращиваемых культур, так и от стадии выращивания. Нужно контролировать целый ряд факторов: температуру, влажность, освещение, кислотность и концентрацию питательных веществ. В больших хозяйствах для решения этой задачи часто используют автоматические системы, которые контролируют и регулируют указанные факторы. Цель автоматизации состоит здесь в том, чтобы при минимальном вмешательстве человека добиться соблюдения режима выращивания.
Одна из ключевых абстракций в данной задаче - датчик. Известно несколько разновидностей датчиков. Все, что влияет на урожай, должно быть измерено. Таким образом, нужны датчики температуры воды, температуры воздуха, влажности, кислотности, освещения и концентрации питательных веществ.
С внешней точки зрения датчик температуры - это объект, который способен измерять температуру там, где он расположен. Температура - это числовой параметр, имеющий ограниченный диапазон значений и определенную точность и означающий число градусов по Цельсию.
Местоположение датчика - это некоторое однозначно определенное место в теплице, температуру в котором необходимо знать. Таких мест, вероятно, немного. Для датчика температуры при этом существенно не само местоположение, а только то, что данный датчик расположен именно в данном месте.
Рассмотрим элементы реализации нашей абстракции на языке С++.
typedef float Temperature; // Температура по Цельсию
typedef unsigned int Location; // Число, однозначно определяющее
// положение датчика
Здесь два оператора определения типов Temperature и Location вводят удобные псевдонимы для простейших типов, и это позволяет нам выражать свои абстракции на языке предметной области. Temperature - это числовой тип данных в формате с плавающей точкой для записи температур. Значения типа Location обозначают места, где могут располагаться температурные датчики.
Рассмотрим обязанности датчика температуры. Датчик должен знать значение температуры в своем местонахождении и сообщать ее по запросу. Клиент по отношению к датчику может выполнить такие действия: калибровать датчик и получать от него значение текущей температуры. Таким образом, объект "Датчик температуры" имеет две операции: "Калибровать" и "Текущая температура".
struct TemperatureSensor {
Temperature curTemperature; // текущая температура в
// местонахождении датчика
Location loc; // местонахождение датчика
void calibrate (Temperature actualTemperature); // калибровать
Temperature currentTemperature (); // текущая температура
Данным описанием вводится новый тип TemperatureSensor. Важным здесь является то, что, во-первых, данные и функции, изменяющие их, объединены вместе в одном описании и, во-вторых, мы не работаем непосредственно с данными, а изменяем их посредством соответствующих функций.
Объекты данного типа вводятся так же, как и переменные стандартных типов:
TemperatureSensor TSensors; // массив из ста объектов типа
// TemperatureSensor
Функции, объявленные внутри описания, называются функциями-членами. Их можно вызывать только для переменной соответствующего типа. Например, калибровать датчик можно так:
TSensors . calibrate (0.); // калибруется датчик номер 3
Поскольку имя объекта, для которого вызывается функция-член, неявно ей передается, в списках аргументов функций отсутствует аргумент типа TemperatureSensor, задающий конкретный датчик, над которым производятся действия. К этому объекту внутри функции можно явно обратиться по указателю this. Например, в теле функции calibrate можно написать один из двух эквивалентных операторов
this -> curTemperature = actualTemperature;
Центральной идеей абстракции является понятие инварианта. Инвариант - это некоторое логическое условие, значение которого (истина или ложь) должно сохраняться. Для каждой операции объекта можно задать предусловия (т.е. инварианты, предполагаемые операцией) и постусловия (т.е. инварианты, которым удовлетворяет операция).
Рассмотрим инварианты, связанные с операцией currentTemperature. Предусловие включает предположение, что датчик установлен в правильном месте в теплице, а постусловие - что датчик возвращает значение температуры в градусах Цельсия.
Изменение инварианта нарушает контракт, связанный с абстракцией. Если нарушено предусловие, то клиент не соблюдает свои обязательства и сервер не может выполнить задачу правильно. Если нарушено постусловие, то свои обязательства нарушил сервер, и клиент не может ему больше доверять.
Для проверки условий язык С++ предоставляет специальные средства в библиотеке assert.h.
В случае нарушения какого-либо условия возбуждается исключительная ситуация. Объекты могут возбуждать исключения, чтобы запретить дальнейшее выполнение операции и предупредить о проблеме другие объекты, которые в свою очередь могут принять на себя перехват исключения и справиться с проблемой.
С++ имеет специальный механизм обработки исключений, чувствительный к контексту. Контекстом для возбуждения исключения является блок try (пробный блок). Если при выполнении операторов, находящихся внутри блока try, происходит исключительная ситуация, то управление передается обработчикам исключений, которые задаются ключевым словом catch и находятся ниже блока try. Синтаксически обработчик catch выглядит подобно описанию функции с одним аргументом без указания типа возвращаемого значения. Для одного блока try может быть задано несколько обработчиков, отличающихся типом аргумента.
Исключение возбуждается посредством указания ключевого слова throw с необязательным аргументом-выражением. Исключение будет обработано посредством вызова того обработчика catch, тип параметра которого будет соответствовать типу аргумента throw. При наличии вложенных блоков try (например, из-за вложенности вызовов функций) будет использован обработчик самого глубокого блока. Если обработчика, соответствующего типу аргумента throw, на данном уровне не будет найдено, будет осуществлен выход из текущей функции и поиск в блоке try с меньшей глубиной вложенности и т.д. После обработки исключения управление передается на оператор, следующий за описаниями обработчиков catch.
Пример. Рассмотрим стек, реализованный с использованием массива фиксированной длины.
int stack; // не более ста элементов в стеке
int top=-1; // номер доступного элемента
void push (int el) {
if(top == 99) throw (1); // проверить на переполнение
else stack[++top] = el; // поместить элемент в стек
if(top == -1) throw (0); // проверить на пустоту
else return stack; // извлечь элемент из стека
try{ // пробный блок
catch(int error){. . .} // если error = 0, то стек пуст;
// если error = 1, то стек полон