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

Объект – уникально определяемая сущность, которая содержит атрибуты, описывающие состояния объекта реального мира и связанные с ними действия (правила поведения). Во многом объект и сущность РБД совпадает по свойствам, однако сущность моделирует только состояние, а объект инкапсулирует и правила поведения.

Среди атрибутов объекта выделяется ссылочный атрибут: он содержит значение/коллекцию значений, которое само является объектом. Иначе говоря, ссылочный атрибут концептуально аналогичен внешнему ключу в РБД или указателям в ЯП.

Каждому объекту в момент создания присваивается идентификатор объекта 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

Резюме

Недостатки модели TCP/IP

Несмотря на огромную популярность, у модели TCP/IP и ее протоколов имеется ряд недостатков:

· отсутствие разграничений концептуальных понятий интерфейса, протокола и уровневого сервиса, что достаточно четко сделано в модели ISO/OSI. Вследствие этого модель TCP/IP не может применяться при разработке новых сетей;

· с помощью модели TCP/IP нельзя описать никакой другой стек протоколов, кроме TCP/IP;

· в модели не различаются физический и канальный уровни, в то время как они абсолютно разные и в корректной модели это должно учитываться;

· наиболее тщательно продуманы и проработаны протоколы IP и TCP. Многие из других протоколов стека разрабатывались студентами (студентам к размышлению!) и свободно распространялись, вследствие чего широко укоренились в практике и теперь их трудно заменить на что-либо новое, предлагаемое по коммерческой схеме.

В качестве резюме отметим, что модель ISO/OSI является полезной для теоретических исследований и разработок новых сетей, хотя протоколы OSI не получили широкого распространения. Для TCP/IP можно сделать обратное утверждение: стек не может рассматриваться в качестве полноценной модели, тогда как сами протоколы хорошо апробированы и чрезвычайно популярны.

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

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

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

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

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

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

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

Иерархия программного обеспечения (ПО) может быть представлена в следующем виде:

· прикладное ПО;

· промежуточное ПО;

· базовое ПО.

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

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

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

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

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

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

К базовому ПО относятся и объекты обработки и хранения данных, реализуемые в таких программных комплексах, как СУБД (системы управления базами данных), базовое ПО сервера обработки транзакций и др.

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

Различают следующие типы объектных интерфейсов (программных интерфейсов):

· прикладной протокол (Application Protocol, АР) – логический интерфейс между прикладными объектами;

· интерфейс прикладных программ (Application Program Interface, API) – логический интерфейс между прикладными объектами и объектами промежуточного ПО, которые поддерживают прикладные объекты;

· протокол промежуточного ПО (Managing Protocol, МР) – логический интерфейс между объектами промежуточного ПО;

· интерфейс базовых программ (Base Program Interface, ВРІ) – логический интерфейс между объектами промежуточного и базового ПО, которые поддерживают объекты промежуточного ПО;

· интерфейс человек-компьютер (User-Computer Interface, UCI) – логический интерфейс между пользователем и, главным образом, объектами базового ПО, однако он может включать в себя также логический интерфейс с объектами промежуточного ПО и даже объектами приложений.

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

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

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

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

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

. (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" класс находится на более высоком уровне абстракции, чем любой из использовавшихся при его реализации.

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

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

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

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

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

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

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

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

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

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

Модель компонентного объекта (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.

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

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

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

Классы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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