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

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

Рис. 1. Верхняя панель инструментов

Рис. 2. Боковая панель инструментов. Блок "Перечисления"

В системе ELMA выделяют системные и пользовательские объекты и перечисления. Пользовательские объекты и перечисления создаются администратором системы в Дизайнере ELMA.

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

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

Режимы отображения объектов и перечислений в списке

Списки объектов и перечислений могут быть отображены в нескольких режимах: "Отображаемое имя" и "Имя класса". Выбор режима отображения объектов и перечислений осуществляется из выпадающего списка (рис. 3), расположенного в поле Показывать в боковом меню вкладки Объекты в Дизайнере ELMA.

Рис. 3. Дизайнер ELMA. Вкладка "Объекты". Поле "Показывать"

Каждый объект и перечисление имеют несколько имен:

Отображаемое имя – имя объекта и/или перечисления, отображаемое списке объектов в Дизайнере ELMA, в карточке объекта и/или перечисления на вкладке Общие в поле Отображаемое имя * (рис. 4), а также в веб-приложении .

Рис. 4. Дизайнер ELMA. Вкладка "Объекты". Режим отображения "Отображаемое имя"

Имя класса – уникальное имя объекта и/или перечисления, задаваемое латинскими символами и отображаемое в списке объектов в Дизайнере ELMA, в карточке объекта и/или перечисления на вкладке Общие в поле Имя класса * (рис. 5).

Рис. 5. Дизайнер ELMA. Вкладка "Объекты". Режим отображения "Имя класса"

Особенности отображения объектов и перечислений

Названия объектов и перечислений имеют следующие цветовые и графические обозначения:

Кнопки верхней панели инструментов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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