Объектная Модель: зачем она нужна и как ее описать. Объектные модели данных

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

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

В Объектной модели представлены три раздела: классы, перечисления и элементы списков.

Классы

Классы - раздел, в котором представлены описания справочников, хранимых в базе данных.

Объект справочника может являться значением объектного параметра другого объекта. Например, параметр "Тип документа" в справочнике "Бумажные документы" является объектным параметром, значением которого является один из объектов справочника "Типы документа".

Перечисления

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

Элементы списков

Элементы списков - это справочники для хранения экземпляров (строк) параметров типа "Список". Список используется для реализации отношения "один-ко-многим". Список представляет собой набор объектов одного и того же класса (класса элементов списка). Например, в классе "Процессы" используется параметр-список "Нормативно-справочные документы". Строки этого списка хранятся в классе элементов списков "БизнесМодель.СписокНСДПроцессов", каждая строка связана с конкретным процессом отношением "один-ко-многим".

Также элементы списков используются для хранения параметров типа "Структура". В этом случае реализуется отношение "один-к-одному". Элемент структуры содержит свой набор параметров. Например, все "Объекты деятельности" имеют параметр-структуру "Параметры ФСА". Элементы структуры хранятся в виде строк класса элементов списков "БизнесМодель.СтоимостьОбъектовДеятельности", каждая строка связана с конкретным объектом деятельности отношением "один-к-одному".

Схема того, как в интерфейсе Business Studio представлены справочники, их параметры и объекты справочников, приведена на Рисунке 1.

Рисунок 1. Справочники, их параметры и объекты справочников в интерфейсе Business Studio

Работа с объектной моделью. Окно объектной модели

В окне справочника слева показывается дерево системных классов, справа - описание параметров класса.

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

На панели инструментов Объектной модели также присутствуют навигационные кнопки:

На Рис. 2 показана Объектная модель , в которой открыто описание справочника "Процессы".

Рисунок 2. Описание справочника "Процессы" в Объектной модели

Для узлов в дереве также действует своё контекстное меню:

Рядом с названием класса в дереве показана иконка:

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

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

Свойство	Назначение
№	Номер параметра.
Название	Пользовательское название параметра. Отображается в Окнах свойств и заголовках списков.
Системное название	Системное название параметра.
Тип	Тип параметра: - простой параметр - "Строка", "Логический", "Целый", "Вещественный", "ДатаВремя", "Текст"; - "Объект"; - "Список"; - "Структура"; - "Перечисление".
Хранимый	Логика, показывающая, хранится параметр физически в базе данных или рассчитывается на основе имеющейся информации. Например, в справочнике "Физические лица" параметры "Фамилия", "Имя", "Отчество" являются хранимыми, они задаются пользователем, а параметр "ФИО" является нехранимым, рассчитываемым на основе этих параметров. Хранимые параметры рассчитываются в момент обращения к ним, например, при отображении в Окнах свойств и Окнах списков , при выполнении отчетов.

Таблица 1. Свойства параметров

Для списка параметров класса действует контекстное меню.

Рассмотрим процесс построения объектной модели для системы банковского обслуживания (см. п. 1.3) в процессе анализа требований и предварительного проектирования этой системы. Для построения объектной модели рассматриваемой системы нам необходимо выполнить все этапы, перечисленные в п.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 (банкоматами) и компьютерами банков. Центральный компьютер проверяет коды банков, но не выполняет проводок самостоятельно.

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

В объектной модели должны быть отражены те понятия и объекты реального мира, которые важны для разрабатываемой системы. В ней отражается прежде всего прагматика разраба­тываемой системы. Прагматика выражается в использовании терминологии прикладной области, связанной с использованием разрабатываемой системы.

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

Введение объектов преследует две цели:

Понимание прикладной задачи (проблемы);

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

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

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

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

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

Пример класса СЧЕТ

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

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

Над объектом можно выполнить некоторые операции. Напри­мер, «Проверить», «Снять», «Поместить» для объектов класса «Счет» или «Открыть», «Читать», «Закрыть» для объектов класса «Файл» и т. п.

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

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

Каждой операции соответствует метод - реализация этой операции для объектов данного класса. Таким образом, операция - это спецификация метода, метод - реализация операции. Например, в классе файл может быть определена операция «Печать» (print ). Эта операция может быть реализована разными методами: (а) «Печать двоичного файла», (б) «Печать текстового файла» и др. Логически эти методы выполняют одну и ту же операцию, хотя реализуются они разными фрагментами кода.

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

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

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

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

Между объектами можно устанавливать зависимости по дан­ным. Эти зависимости выражают связи или отношения между классами указанных объектов.

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

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

Зависимости, как и классы, могут иметь свои свойства. Например, при организации доступа пользователя к файлу «Разрешение на доступ» является свойством зависимости «Дос­тупен». Отметим, что разрешение на доступ связано как с пользо­вателем, так и с файлом, и не может быть атрибутом ни поль­зователя, ни файла в отдельности.

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

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

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

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

Целесообразно придерживаться следующих правил наследова­ния:

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

Все операции, изменяющие значения свойств, должны наследоваться во всех их расширениях;

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

Унаследованные операции можно уточнять, добавляя дополнительные действия.

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

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

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

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

Объектная модель представляет собой набор правил, которые предписывают, каким образом объекты определяются и документируются. Все объекты, принадлежащие данной объектной модели, соответствуют строгим правилам, которые диктуют их: определение, создание, взаимодействия между объектами и уничтожение. Другими словами, объектная модель формально определяет, что представляет собой объект, как он располагается в памяти, когда создается, как взаимодействует с другими объектами и когда уничтожается. Большинство объектно-ориентированных языков программирования не составляют и не определяют настоящие объектные модели. Эти языки, включая С++, в основном поддерживают синтаксис и диктуют семантику при реализации объекта; они не определяют правила, унифицирующие системы объектов. А вот модель компонентного объекта (СОМ) является действительно настоящей моделью объектов, которая вносит некоторый порядок в хаотичную вселенную объектов.

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

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

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

Объектные модели включают модели наследования, агрегирования и поведенческие модели.

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

Модель компонентного объекта (Component Object Model - COM) – это вклад компании Microsoft в мир объектных моделей. Она служит основой для технологии OLE (Object Linking and Embedding). COM представляет собой стандартную объектную модель промышленного уровня, которая унифицирует системы объектов. Эта модель специфицирует:

· правила, по которым объекты структурируются и особым образом располагаются в памяти – определение объекта;

· правила, по которым объекты создаются и уничтожаются – управление жизненным циклом;

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

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

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

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

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

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

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

Клиенты и СОМ - серверы общаются друг с другом при помощи интерфейсов .

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

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

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

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

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

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

· Интерфейсы описывают четко установленные соглашения.

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

· Интерфейсы остаются неизменными. Если интерфейс объявлен общедоступным, он таким и остается. Другими словами, интерфейсы не переделываются.

· Интерфейсы являются предсказуемыми. Заданный интерфейс всегда обеспечивает абсолютно одинаковый набор функций в любой момент времени. Например, нажатие кнопки «Ввод» на банкомате всегда подтверждает последнее действие. Это истинно для любого банкомата.

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

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

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

Во-первых , объектная модель позволяет в полной мере использовать выразительные возможности объектно-ориентированных языков программирования.

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

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

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

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

· Модель взаимодействия управляемых моделей , исполняющихся в среде CLR. Эта модель в наибольшей степени близка к СОМ, поскольку при ее реализации основной акцент делается на преодолении ряда проблем, присущих именно СОМ.

· Модель взаимодействия компонентов Web-приложений на основе архитектуры ASP .NET (Active Server Pages).

· Модель распределенного компонентного программирования , ориентированного на XML Web-сервисы. В рамках этой модели реализуется взаимодействие удаленных компонентов, исполняющихся на разных платформах, на базе протокола SOAP.

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

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

Основные положения объектной модели

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

. (object-oriented analysis, ООА) направлен на создание моделей реальной действительности на основе объектно-ориентированного мировоззрения.

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

. (object-oriented design, ООД)

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

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

В данном определении содержатся две важные части: объектно-ориентированное проектирование

1) основывается на объектно-ориентированной декомпозиции;

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

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

. (object-oriented programming, OOП)

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

В данном определении можно выделить три части:

1) OOП использует в качестве базовых элементов объекты, а не алгоритмы;

2) каждый объект является экземпляром какого-либо определенногокласса;

3) классы организованы иерархически .

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

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

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

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

абстрагирование;

инкапсуляция;

модульность;

иерархия.

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

типизация;

параллелизм;

сохраняемость.

Называя их дополнительными, имеется в виду, что они полезны в объектной модели, но не обязательны.

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

Абстракция основывается на понятиях клиента и сервера.

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

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

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

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

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

Модульность - это свойство системы, которая была разложена на внутренне связные, но слабо связанные между собой модули.

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

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

Иерархия - это упорядочение абстракций, расположение их по уровням.

Основными видами иерархических структур применительно к сложным системам являются структура классов (иерархия "is-a") и структура объектов (иерархия "part of").

Важным элементом объектно-ориентированных систем и основным видом иерархии "is-a" является упоминавшаяся выше концепция наследования. Наследование означает такое отношение между классами (отношение родитель/потомок), когда один класс заимствует структурную или функциональную часть одного или нескольких других классов (соответственно, одиночное имножественное наследование ). Иными словами, наследование создает такую иерархию абстракций, в которой подклассы наследуют строение от одного или нескольких суперклассов. Часто подкласс достраивает или переписывает компоненты вышестоящего класса.

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

Типизация - это способ защититься от использования объектов одного класса вместо другого, или по крайней мере управлять таким использованием.

Параллелизм - это свойство, отличающее активные объекты от пассивных.

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