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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В объектно-реляционных СУБД за основу берётся реляционная модель, которую расширяют системой объектных типов данных, конструируемых пользователем. Язык запросов представляет собой расширение SQL.

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

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

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

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

Рассмотрим язык UML (Unified Modeling Language) обладающий более широкими возможностями. Отметим, что термин "унифицированный" не означает претензий на универсальность. Просто UML был создан путем объединения как минимум трех языков концептуального моделирования.

Для построения реляционных, объектных и объектно-реляционных баз данных из определённых в UML-2 тринадцати видов диаграмм нам достаточно диаграмм классов. Это структурные диаграммы, определяющие наборы классов, их атрибуты, операторы и связи между ними.

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

Возможно четыре варианта обозначения класса, приведенные на рисунке 10.1.

Рис. 10.1.

Рис. 10.2.

Определение . Связи-ассоциации классифицируются по числу соединяемых классов. Обозначаются они сплошными линиями. Выделяют бинарные связи (соединяют два класса), тернарные (три класса) и N-арные. Для бинарных связей может быть указан порядок соединяемых классов. Так, в примере на рисунке 10.3 связь читается так: "Мама моет раму".

Рис. 10.3.

Концы связи-ассоциации можно помечать именами ролей, для которых могут быть указаны кратности связи. Назначения ролей такие же, как в ER-диаграммах (см. раздел 2.2.6). Кратности роли указывают, сколько объектов с этой ролью могут участвовать в ассоциации. Так, кратность 1 указывает на обязательность связи, кратность 0..1 означает её необязательность. Задание диапазона 1..* говорит о том, что все объекты должны участвовать в каком-нибудь экземпляре ассоциации и что число объектов, участвующих в одном экземпляре ассоциации не ограничено.

В примере на рисунке 10.4 в показано, что работник обязательно работает равно в одном отделе, а отдел может существовать вообще без работников, но может иметь до 15 человек.

Рис. 10.4.

Как вы уже поняли, ассоциации реализуются в реляционной модели.

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

Парадигмы программирования

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

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

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

Наиболее заметные отличия в проявлении показателей качества между языками разных видов:

• В мейнстримных языках декларируемые принципы нацелены на повышение изначально низкого для императивного программирования коэффициента повторного использования кода . В полиморфно типизированных применение концепций ООП, напротив, означает очевидное его снижение из-за перехода от параметрического полиморфизма к ad-hoc-полиморфизму . В динамически типизированных языках (Smalltalk , Python , Ruby) эти принципы используются для логической организации программы, и их влияние на коэффициент повторного использования трудно спрогнозировать - он сильно зависит от дисциплины программиста. Например, в CLOS мультиметоды одновременно являются функциями первого класса , что позволяет рассматривать их одновременно и как связанно квантифицированные , и как обобщённые (истинно полиморфные).
• Традиционные ОО-языки используют номинативную типизацию , то есть допустимость соиспользования объектов разных классов только при условии явного указания родственных отношений между классами. Для полиморфно типизированных языков характерна структурная типизация , то есть согласование классов между собой тем же механизмом, что и согласование числа 5 с типом int . Динамически типизированные языки также занимают здесь промежуточную позицию.

Обобщённое обоснование динамической диспетчеризации (включая множественную) в середине 1990-х годов построил Джузеппе Кастанья .

История

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

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

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

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

Взгляд на программирование «под новым углом» (отличным от процедурного) предложили Алан Кэй и Дэн Ингаллс в языке Smalltalk . Здесь понятие класса стало основообразующей идеей для всех остальных конструкций языка (то есть класс в Смолтоке является примитивом, посредством которого описаны более сложные конструкции). Именно он стал первым широко распространённым объектно-ориентированным языком программирования .

В настоящее время количество прикладных языков программирования (список языков), реализующих объектно-ориентированную парадигму, является наибольшим по отношению к другим парадигмам. Наиболее распространённые в промышленности языки (С++, Delphi, C#, Java и др.) воплощают объектную модель Симулы. Примерами языков, опирающихся на модель Смолтока, являются Objective-C, Python, Ruby.

Определение ООП и его основные концепции

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

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

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

Сложности определения

ООП имеет уже более чем сорокалетнюю историю, но, несмотря на это, до сих пор не существует чёткого общепринятого определения данной технологии . Основные принципы, заложенные в первые объектные языки и системы, подверглись существенному изменению (или искажению) и дополнению при многочисленных реализациях последующего времени. Кроме того, примерно с середины 1980-х годов термин «объектно-ориентированный» стал модным , в результате с ним произошло то же самое, что несколько раньше с термином «структурный» (ставшим модным после распространения технологии структурного программирования) - его стали искусственно «прикреплять» к любым новым разработкам, чтобы обеспечить им привлекательность. Бьёрн Страуструп в 1988 году писал, что обоснование «объектной ориентированности» чего-либо, в большинстве случаев, сводится к некорректному силлогизму : «X - это хорошо. Объектная ориентированность - это хорошо. Следовательно , X является объектно-ориентированным».

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

Однако общность механизма обмена сообщениями имеет и другую сторону - «полноценная» передача сообщений требует дополнительных накладных расходов, что не всегда приемлемо. Поэтому во многих современных объектно-ориентированных языках программирования используется концепция «отправка сообщения как вызов метода» - объекты имеют доступные извне методы, вызовами которых и обеспечивается взаимодействие объектов. Данный подход реализован в огромном количестве языков программирования, в том числе C++ , Object Pascal , Java , Oberon-2 . Однако, это приводит к тому, что сообщения уже не являются самостоятельными объектами, и, как следствие, не имеют атрибутов, что сужает возможности программирования. Некоторые языки используют гибридное представление, демонстрируя преимущества одновременно обоих подходов - например, CLOS , Python .

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

Особенности реализации

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

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

Классы могут наследоваться друг от друга. Класс-потомок получает все поля и методы класса-родителя, но может дополнять их собственными либо переопределять уже имеющиеся. Большинство языков программирования поддерживает только единичное наследование (класс может иметь только один класс-родитель), лишь в некоторых допускается множественное наследование - порождение класса от двух или более классов-родителей. Множественное наследование создаёт целый ряд проблем, как логических, так и чисто реализационных, поэтому в полном объёме его поддержка не распространена. Вместо этого в 1990-е годы появилось и стало активно вводиться в объектно-ориентированные языки понятие интерфейса . Интерфейс - это класс без полей и без реализации, включающий только заголовки методов. Если некий класс наследует (или, как говорят, реализует) интерфейс, он должен реализовать все входящие в него методы. Использование интерфейсов предоставляет относительно дешёвую альтернативу множественному наследованию.

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

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

Контроль доступа Поскольку методы класса могут быть как чисто внутренними, обеспечивающими логику функционирования объекта, так и внешними, с помощью которых взаимодействуют объекты, необходимо обеспечить скрытость первых при доступности извне вторых. Для этого в языки вводятся специальные синтаксические конструкции, явно задающие область видимости каждого члена класса. Традиционно это модификаторы public, protected и private, обозначающие, соответственно, открытые члены класса, члены класса, доступные внутри класса и из классов-потомков, и скрытые, доступные только внутри класса. Конкретная номенклатура модификаторов и их точный смысл различаются в разных языках. Методы доступа Поля класса в общем случае не должны быть доступны извне, поскольку такой доступ позволил бы произвольным образом менять внутреннее состояние объектов. Поэтому поля обычно объявляются скрытыми (либо язык в принципе не позволяет обращаться к полям класса извне), а для доступа к находящимся в полях данным используются специальные методы, называемые методами доступа. Такие методы либо возвращают значение того или иного поля, либо производят запись в это поле нового значения. При записи метод доступа может проконтролировать допустимость записываемого значения и, при необходимости, произвести другие манипуляции с данными объекта, чтобы они остались корректными (внутренне согласованными). Методы доступа называют ещё аксессорами (от англ. access - доступ), а по отдельности - геттерами (англ. get - чтение) и сеттерами (англ. set - запись) . Свойства объекта Псевдополя, доступные для чтения и/или записи. Свойства внешне выглядят как поля и используются аналогично доступным полям (с некоторыми исключениями), однако фактически при обращении к ним происходит вызов методов доступа. Таким образом, свойства можно рассматривать как «умные» поля данных, сопровождающие доступ к внутренним данным объекта какими-либо дополнительными действиями (например, когда изменение координаты объекта сопровождается его перерисовкой на новом месте). Свойства, по сути, не более чем синтаксический сахар , поскольку никаких новых возможностей они не добавляют, а лишь скрывают вызов методов доступа. Конкретная языковая реализация свойств может быть разной. Например, в объявление свойства непосредственно содержит код методов доступа, который вызывается только при работе со свойствами, то есть не требует отдельных методов доступа, доступных для непосредственного вызова. В Delphi объявление свойства содержит лишь имена методов доступа, которые должны вызываться при обращении к полю. Сами методы доступа представляют собой обычные методы с некоторыми дополнительными требованиями к сигнатуре .

Полиморфизм реализуется путём введения в язык правил, согласно которым переменной типа «класс» может быть присвоен объект любого класса-потомка её класса.

Проектирование программ в целом

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

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

• Из каких частей состоит система ;
• В чём состоит ответственность каждой из её частей .

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

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

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

Различные ООП-методологии

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

Компонентное программирование

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

Прототипное программирование

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

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

Класс-ориентированное программирование

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

Производительность объектных программ

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

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

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

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

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

Критика ООП

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

Критические высказывания в адрес ООП:

• Было показано отсутствие значимой разницы в продуктивности разработки программного обеспечения между ООП и процедурным подходом .
• Кристофер Дэйт указывает на невозможность сравнения ООП и других технологий во многом из-за отсутствия строгого и общепризнанного определения ООП .
• Александр Степанов в одном из своих интервью указывал, что ООП «методологически неправильно» и что «…ООП практически такая же мистификация , как и искусственный интеллект …» .
• Фредерик Брукс указывает, что наиболее сложной частью создания программного обеспечения является «…спецификация, дизайн и тестирование концептуальных конструкций, а отнюдь не работа по выражению этих концептуальных конструкций…». ООП (наряду с такими технологиями как искусственный интеллект, верификация программ , автоматическое программирование , графическое программирование , экспертные системы и др.), по его мнению, не является «серебряной пулей», которая могла бы на порядок величины снизить сложность разработки программных систем. Согласно Бруксу, «…ООП позволяет сократить только привнесённую сложность в выражение дизайна. Дизайн остаётся сложным по своей природе…» .
• Эдсгер Дейкстра указывал: «…то, о чём общество в большинстве случаев просит - это эликсир от всех болезней. Естественно, „эликсир“ имеет очень впечатляющие названия, иначе будет очень трудно что-то продать: „Структурный анализ и Дизайн“, „Программная инженерия“, „Модели зрелости“, „Управляющие информационные системы“ (Management Information Systems), „Интегрированные среды поддержки проектов“, „Объектная ориентированность“, „Реинжиниринг бизнес-процессов “…» .
• Никлаус Вирт считает, что ООП - не более чем тривиальная надстройка над структурным программированием [ ] , и преувеличение её значимости, выражающееся, в том числе, во включении в языки программирования всё новых модных «объектно-ориентированных» средств, вредит качеству разрабатываемого программного обеспечения.
• Патрик Киллелиа в своей книге «Тюнинг веб-сервера» писал: «…ООП предоставляет вам множество способов замедлить работу ваших программ…».
• Известная обзорная статья проблем современного ООП-программирования перечисляет некоторые типичные проблемы ООП [ ] .
• В программистском фольклоре получила широкое распространение критика объектно-ориентированного подхода в сравнении с функциональным подходом с использованием метафоры «Королевства Существительных » из эссе Стива Йегги .

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

Критика рекламы ООП Критикуется явно высказываемое или подразумеваемое в работах некоторых пропагандистов ООП, а также в рекламных материалах «объектно-ориентированных» средств разработки представление об объектном программировании как о некоем всемогущем подходе, который магическим образом устраняет сложность программирования. Как замечали многие, в том числе упомянутые выше Брукс и Дейкстра, «серебряной пули не существует» - независимо от того, какой парадигмы программирования придерживается разработчик, создание нетривиальной сложной программной системы всегда сопряжено со значительными затратами интеллектуальных ресурсов и времени. Из наиболее квалифицированных специалистов в области ООП никто, как правило, не отрицает справедливость критики этого типа. Оспаривание эффективности разработки методами ООП Критики оспаривают тезис о том, что разработка объектно-ориентированных программ требует меньше ресурсов или приводит к созданию более качественного ПО. Проводится сравнение затрат на разработку разными методами, на основании которого делается вывод об отсутствии у ООП преимуществ в данном направлении. Учитывая крайнюю сложность объективного сравнения различных разработок, подобные сопоставления, как минимум, спорны. С другой стороны, получается, что ровно так же спорны и утверждения об эффективности ООП. Производительность объектно-ориентированных программ Указывается на то, что целый ряд «врождённых особенностей» ООП-технологии делает построенные на её основе программы технически менее эффективными, по сравнению с аналогичными необъектными программами. Не отрицая действительно имеющихся дополнительных накладных расходов на организацию работы ООП-программ (см. раздел «Производительность» выше), нужно, однако, отметить, что значение снижения производительности часто преувеличивается критиками. В современных условиях, когда технические возможности компьютеров чрезвычайно велики и постоянно растут, для большинства прикладных программ техническая эффективность оказывается менее существенна, чем функциональность, скорость разработки и сопровождаемость. Лишь для некоторого, очень ограниченного класса программ (ПО встроенных систем, драйверы устройств, низкоуровневая часть системного ПО, научное ПО) производительность остаётся критическим фактором. Критика отдельных технологических решений в ООП-языках и библиотеках Эта критика многочисленна, но затрагивает она не ООП как таковое, а приемлемость и применимость в конкретных случаях тех или иных реализаций её механизмов. Одним из излюбленных объектов критики является язык C++, входящий в число наиболее распространённых промышленных ООП-языков.

Объектно-ориентированные языки

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

Как правило, объектно-ориентированный язык (ООЯ) содержит следующий набор элементов:

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

Некоторые языки добавляют к указанному минимальному набору те или иные дополнительные средства. В их числе:

• Конструкторы, деструкторы, финализаторы;
• Свойства (аксессоры);
• Индексаторы;
• Средства управления видимостью компонентов классов (интерфейсы или модификаторы доступа, такие как public, private, protected, feature и др.).

Одни языки отвечают принципам ООП в полной мере - в них все основные элементы являются объектами, имеющими состояние и связанные методы. Примеры подобных языков - Smalltalk , Eiffel . Существуют гибридные языки, совмещающие объектную подсистему в целостном виде с подсистемами других парадигм как «два и более языка в одном», позволяющие совмещать в одной программе объектные модели с иными, и размывающие грань между объектно-ориентированной и другими парадигмами за счёт нестандартных возможностей, балансирующих между ООП и другими парадигмами (таких как множественная диспетчеризация , параметрические классы, возможность манипулировать методами классов как самостоятельными объектами, и др.). Примеры таких языков: CLOS , Dylan , OCaml , Python , Ruby , Objective-C . Однако, наиболее распространены языки, включающие средства эмуляции объектной модели поверх более традиционной императивной семантики. Алан Кэй назвал такие языки «склеиванием возможностей» (англ. agglutination of features ) в противовес «чистоте стиля» (англ. crystalization of style ) языков, воплощающих некую парадигму непосредственно . Примеры таких языков -

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

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

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

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

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

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

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

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

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