Построение объектной модели

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

удобство.

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

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

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

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

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

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

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

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

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

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

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

Актеры – это роли, исполняемые сущностями, непосредственно взаимодействующими с системой.

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

Мне очень  понравилось описание понятия «актер»  в работе  Джима Арлоу и Айла Нейштадта «UML 2 и Унифицированный процесс»: «Для понимания актеров важно понимать концепцию ролей. Роль можно рассматривать как шляпу, которую надевают в определенной ситуации.» (стр 92).

Когда известны основные понятия, можно рассматривать  построение самой модели

 

 

2. Построение объектной модели

 

1. Определение классов 

 

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

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

Далее список возможных  классов должен быть проанализирован  с целью исключения из него ненужных классов. Такими классами являются:

избыточные  классы: если два или несколько  классов выражают одинаковую информацию, следует сохранить только один из них;

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

нечетко определенные (с точки зрения рассматриваемой  проблемы) классы;

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

операции: некоторым  существительным больше соответствуют  не классы, а имена операций (например, телефонный_вызов вряд ли означает какой-либо класс);

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

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

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

 

 

2. Подготовка словаря данных

 

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

 

2.3. Определение зависимостей

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

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

Затем следует  убрать ненужные или неправильные зависимости, используя следующие критерии:

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

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

действия: зависимость должна описывать структурные свойства прикладной области, а не малосущественные события;

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

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

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

неверно названные  зависимости: их следует переименовать, чтобы смысл их стал понятен;

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

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

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

неучтенные  зависимости должны быть выявлены и  добавлены в модель.

 

2.4. Уточнение атрибутов

 

 

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

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

Наряду с  атрибутами объектов необходимо ввести и атрибуты зависимостей между классами (связей между объектами).

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

Замена атрибутов на объекты. Если наличие некоторой сущности важнее, чем ее значение, то это объект, если важнее значение, то это атрибут: например, начальник - это объект (неважно, кто именно начальник, главное, чтобы кто-то им был), зарплата - это атрибут (ее значение весьма существенно); город - всегда объект, хотя в некоторых случаях может показаться, что это атрибут (например, город как часть адреса фирмы); в тех случаях, когда нужно, чтобы город был атрибутом, следует определить зависимость (скажем, находится) между классами фирма и город.

Квалификаторы. Если значение атрибута зависит от конкретного контекста, его следует  сделать квалификатором.

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

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

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

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

Несущественные  детали. Атрибуты, не влияющие на выполнение большей части операций, рекомендуется  опустить.

 

2.5. Выделение подсистем

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