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

· определение объектов и классов;

· подготовка словаря данных;

· определение зависимостей между объектами;

· определение атрибутов объектов и связей;

· организация и упрощение классов при использовании наследования;

· дальнейшее исследование и усовершенствование модели.

2.2.1. Определение классов. Анализ внешних требований к проектируемой ПС позволяет определить объекты и классы объектов, связанные с прикладной проблемой, которую должна решать эта система. Все классы должны быть осмыслены в рассматриваемой прикладной области; классов, связанных с компьютерной реализацией, как например список, стек и т.п. на этом этапе вводить не следует.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 2.36. Неизбыточные зависимости

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Признаки пропущенного объекта (класса):

· несимметричности связей и обобщений (наследований); для исправления ошибки необходимо добавить пропущенные классы;

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

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

· обнаружено несколько зависимостей с одинаковыми именами и назначением; для исправления ошибки необходимо сделать обобщение и добавить пропущенный суперкласс.

Признаки ненужного (лишнего) класса:

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

Признаки пропущенных зависимостей:

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

Признаки ненужных (лишних) зависимостей:

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

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

Признаки неправильного размещения зависимостей:

· имена ролей слишком широки или слишком узки для их классов; для исправления ошибки необходимо переместить зависимость вверх или вниз по иерархии классов.

Признаки неправильного размещения атрибутов:

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

Примеры практического применения описанных признаков см. в п. 2.3.6.

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

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

2.3.3. Определение зависимостей. Следуя рекомендациям п. 2.2.3, выделяем явные и неявные глагольные обороты из предварительной постановки задачи и рассматриваем их как имена возможных зависимостей. Из постановки задачи о банковской сети (см. п. 1.3) можно извлечь следующие обороты:

Глагольные обороты (явные и неявные):

Банковская сеть включает кассиров и ATM"ы

Консорциум распределяет результаты проводок по ATM

Банк владеет компьютером банка

Компьютер банка поддерживает счета

Банк владеет кассовыми терминалами

Кассовый терминал взаимодействует с компьютером банка

Кассир вводит проводку над счетом

ATM"ы взаимодействуют с центральным компьютером во время проводки

Центральный компьютер взаимодействует с компьютером банка

ATM принимает карточку

ATM общается с пользователем

ATM выдает наличные деньги

ATM печатает квитанции

Система регулирует коллективный доступ

Банк предоставляет программное обеспечение

Консорциум состоит из банков

Консорциум владеет центральным компьютером

Система обеспечивает протоколирование

Система обеспечивает безопасность

Клиенты имеют карточки

Карточка обеспечивает доступ к счету

В банке служат кассиры

Затем исключаем ненужные или неправильные зависимости, используя критерии, сформулированные в п. 2.2.3:

· зависимости между исключенными классами: исключаются следующие зависимости: Банковская сеть включает кассиров и ATM"ы (класс банковская_сеть исключен), ATM печатает квитанции (класс квитанция исключен), ATM выдает наличные деньги (класс деньги исключен), Система обеспечивает протоколирование проводок (класс служба_ведения_записей исключен), Система обеспечивает безопасность ведения счетов (класс служба_безопасности исключен), Банки предоставляют программное обеспечение (класс программное_обеспечение исключен);

· нерелевантные зависимости и зависимости, связанные с реализацией: зависимость "Система регулирует коллективный доступ" исключается как связанная с реализацией;

· действия описываются такими зависимостями как "ATM принимает карточку" и "ATM общается с пользователем"; мы исключаем эти зависимости;

· тренарные зависимости: зависимость "Кассир вводит проводку над счетом" раскладывается на две бинарные зависимости "Кассир вводит проводку" и "Проводка относится к счету". Зависимость "ATM"ы взаимодействуют с центральным компьютером во время проводки" раскладывается на "ATM"ы взаимодействуют с центральным компьютером" и "Проводка начинается с ATM";

· производные зависимости: зависимость "Консорциум распределяет ATM"ы" является следствием зависимостей "Консорциум владеет центральным компьютером" и "ATM"ы взаимодействуют с центральным компьютером".

Удалив избыточные зависимости, получим следующий список зависимостей:

Банк владеет компьютером банка

Компьютер банка поддерживает счета

Банк владеет кассовыми терминалами

Кассовый терминал взаимодействует с компьютером банка

Кассир вводит проводку

Проводка относится к счету

ATM"ы взаимодействуют с центральным компьютером

Проводка начинается с ATM

Центральный компьютер взаимодействует с компьютером банка

Консорциум состоит из банков

Консорциум владеет центральным компьютером

Клиенты имеют карточки

Карточка обеспечивает доступ к счету

В банке служат кассиры

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

· переименуем неверно названные зависимости, чтобы смысл их стал более понятен; так зависимость Компьютер_банка поддерживает счета удобнее заменить зависимостью Банк держит счета.

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

· неучтенные зависимости: Проводка начинается с кассового_терминала, Клиенты имеют счета, Проводка регистрируется карточкой следует добавить в модель.

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

Рис. 2.37. Первая версия объектной диаграммы для банковской сети

2.3.4. Уточнение атрибутов. Применяя критерии, сформулированные в п. 2.2.4, получим:

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

После внесения перечисленных изменений диаграмма примет вид, представленный на рис. 2.38.

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

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

Рис. 2.38. Объектная диаграмма для банковской сети после уточнения атрибутов и добавления квалификаторов

Рис. 2.39. Объектная диаграмма для банковской с учетом наследования

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

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

Класс банк естественно объединить с классом компьютер_банка, а класс консорциум - с классом центральный_компьютер.

Рис. 2.40. Окончательный вид объектной диаграммы для банковской сети

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

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

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

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

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

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

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

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

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

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

Рис. 2.41. Объектная диаграмма банковской сети, в которой указан интерфейс с системным окружением

Рис. 2.42. Объектная диаграмма банковской сети и ее системного окружения

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

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

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

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

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

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

Рис. 2.43. Объектная диаграмма банковской сети после выделения подсистемы банк

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

Построение объектной модели предметной области "организация процессов спортивного клуба" с применением языка моделирования UML

1. ОСНОВНЫЕ ТЕОРЕТИЧЕСКИЕ ПОЛОЖЕНИЯ ОБЪЕКТНО-ОРИЕНТИРОВАННОЙ МЕТОДОЛОГИИ

1.1 Основные понятия объектно-ориентированного подхода

предметный язык программирование модель

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

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

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

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

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

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

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

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

Между ООП и процедурно-ориентированным программированием существуют два важных различия:

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

2. Методы и свойства ассоциируются с классом, предназначенным для выполнения соответствующих операций.

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

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

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

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

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

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

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

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

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

Полиморфизм (polymorphism) («много форм») - возможность использовать одинаковые выражения для обозначения разных операций, возможность классов-наследников по-разному реализовывать метод, описанный для класса-предка, т.е. возможность во время выполнения программы с помощью одного и того же имени выполнять разные действия или обращаться к объектам разного типа. Полиморфизм реализуется через переопределение метода в классах-наследниках (метод имеет одно имя и одинаковые параметры, но работает по-разному) - это механизм виртуальных методов через динамическое связывание (dynamic binding). Также полиморфизм реализуется как «перегрузка» методов (метод имеет одно имя и разные параметры) - это, например, использование знака + для обозначения сложения в классе вещественных или целых чисел и классе строк: похожие сообщения дают совершенно разные результаты. Полиморфизм обеспечивает возможность абстрагирования общих свойств.

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

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

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

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

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

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

Таким образом, в процессе разработки объектно-ориентированных программ необходимо:

1. определить множество образующих ее классов объектов (декомпозиция);

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

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

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

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

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

Членами класса могут быть:

1. поля, используемые для хранения данных;

2. свойства, как средства обращения к закрытым полям;

3. методы, задающие функциональность объектов;

4. события и их обработчики, как средства управления программами.

Автоматизация решения задач управления деятельностью ООО "Мир Компьютеров"

Построение концептуальной модели информационной системы МУП "РПКХБ"

Пакет Rational Rose способен решать практически любые задачи в проектировании информационных систем: от анализа бизнес процессов до кодогенерации на определенном языке программирования. Позволяет разрабатывать как высокоуровневые...

Построение объектной модели предметной области "организация процессов спортивного клуба" с применением языка моделирования UML

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

Программирование в Delphi математических процессов

Проект системы учета заказов на грузоперевозку автотранспортной компании "ТрансАвто"

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

Проектирование информационных систем средствами BPwin

Разработка информационной системы автоматизации рабочего места библиотекаря

Разработка объектно-ориентированной модели информационной подсистемы для деканата ВУЗа (учет успеваемости студентов)

Эффективное управление базой данных студентов невозможно без системы автоматизации. Информационная система «Деканат» предназначена для ведения личных дел студентов и может работать отдельно или в составе ИС «Электронные ведомости»...

Разработка объектно-ориентированной модели информационной системы учебной библиотеки

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

Разработка ООМД заключается в разработки модели данных с использованием объектно-ориентированного подхода к моделированию...

Разработка схемы базы данных задачи "Учет фонда библиотеки" для Харьковского колледжа текстиля и дизайна

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

Объектная модель

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

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

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

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

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

. (object-oriented design, ООД)

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

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

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

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

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

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

. (object-oriented programming, OOП)

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

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

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

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

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

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

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

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

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

• абстрагирование;
• инкапсуляция;
• модульность;
• иерархия.

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

• типизация;
• параллелизм;
• сохраняемость.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Базы данных. Заочники

Лабораторная работа №1

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

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

Общая информация

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

Моделирование позволяет решить следующие задачи:

Визуализировать систему в ее текущем или желательном для нас состоянии;

Определить структуру или поведение системы;

Получить шаблон, позволяющий затем сконструировать систему;

Документировать принимаемые решения, используя полученные модели.

Класс (Class) – это описание совокупности объектов с общими атрибутами, операциями и отношениями. Графически класс изображается в виде прямоугольника, в котором обычно записаны его имя, атрибуты и операции, как показано на рис. 1. Одной из разновидностей сущности класс является актер (Actor). Обычно актер представляет роль, которую в данной системе играет человек, аппаратное устройство или даже другая система. Как показано на рис. 2, актеров изображают в виде человеческих фигурок.

Прецедент (Use Case) - это описание последовательности выполняемых системой действий, которая производит наблюдаемый результат, значимый для какого-то определенного актера (Actor). Прецедент применяется для структурирования поведенческих сущностей модели. Графически прецедент изображается в виде ограниченного непрерывной линией эллипса, обычно содержащего только его имя, как показано на рис. 3.

Поведенческие сущности являются динамическими составляющими модели UML. Это глаголы языка: они описывают поведение модели во времени и пространстве. Существует два вида поведенческих сущностей:

Взаимодействие (Interaction);

Автомат (State machine).

Взаимодействие (Interaction) – это поведение, суть которого заключается в обмене сообщениями (Messages) между объектами в рамках конкретного контекста для достижения определенной цели. Графически сообщения изображаются в виде стрелки, над которой почти всегда пишется имя соответствующей операции, как показано на рис. 4.

Группирующие сущности являются организующими частями UML. Это блоки, на которые можно разложить модель. Есть только одна группирующая сущность, а именно пакет.

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

Аннотационные сущности – пояснительные части модели UML. Это комментарии для дополнительного описания, разъяснения или замечания к любому элементу модели. Имеется только один тип аннотационных элементов – примечания (Note).

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

В языке UML определены четыре типа отношений:

Зависимость;

Ассоциация;

Обобщение;

Реализация.

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

Зависимость (Dependency) – это семантическое отношение между двумя сущностями, при котором изменение одной из них, независимой, может повлиять на семантику другой, зависимой. Графически зависимость изображается в виде прямой пунктирной линии, часто со стрелкой (см. рис. 7).

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

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

Диаграммы классов;

Диаграммы объектов;

Диаграммы прецедентов;

Диаграммы последовательностей;

Диаграммы кооперации;

Диаграммы состояний;

Диаграммы действий;

Диаграммы компонентов;

Диаграммы развертывания.

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

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

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

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

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

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

- информация о специальностях (наименование специальности, шифр);

- информация о группах (специальность, год поступления, номер группы).

Обеспечить выдачу документа “Список группы”, содержащего поля: порядковый номер, Ф. И.О., номер зачетки.

Построение объектной модели выполняется в пакете Rational Rose. Для этого создадим пустой проект. Начинать выполнение работы следует с диаграммы прецедентов. Ее строят в области Main секции Use Case View, как показано на рис.9.

Перед началом построения диаграммы необходимо определить роли пользователей системы (актеров) и их функции (прецеденты). В нашем случае с системой работают два актера – это «Работник учебного отдела» и «Работник деканата». В функции работника учебного отдела входит ведение списка специальностей (под ведением списка мы будем понимать добавление записей, их корректировку и удаление). Функции работника деканата включают в себя ведение списка студентов и ведение списка групп.

Построенная диаграмма изображена на рис. 10.

Далее в секции Logical View следует создать две диаграммы классов. Для этого можно создать два пакета. Первая диаграмма должна содержать классы интерфейса проектируемого приложения (см. рис. 11). Вторая диаграмма – сущности базы данных (см. рис. 12).

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

Следующий этап построения объектной модели – создание диаграмм последовательностей. Диаграммы последовательностей создаются для каждого прецедента на диаграмме прецедентов. Чтобы добавить диаграмму последовательностей к прецеденту необходимо выбрать его в дереве и вызвать на нем контекстное меню (NewàSequence Diagram) как показано на рис. 13.

Пример диаграммы последовательностей для прецедента «Ведение списка специальностей» представлен на рис. 14.

ВВЕДЕНИЕ

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

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

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

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

1. Основные понятия объектно-орие нтированного подхода

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Переопределение может преследовать одну из следующих целей:

расширение: новая операция расширяет унаследованную операцию, учитывая влияние атрибутов подкласса;

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

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

удобство.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

и т.д.................