Подход на основе использования именных групп

Углубленный анализ

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

Моделирование классов

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

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

1. Знания в области моделирования классов.

2. Понимание проблемной области.

3. Опыт в области аналогичных и успешных проектов.

4. Способность смотреть вперед и предвидеть последствия решений.

5. Готовность к пересмотру модели с целью устранения недостатков и т.д.

Выявление классов

Выделяют четырех основные подхода к выявлению классов:

1. Подход на основе использования именных групп.

2. Подход на основе использования общих шаблонов для классов.

3. Подход на основе использования прецедентов.

4. Подход CRC (class-responsibility-collaborators – класс-обязанности-“сотрудники”).

Подход на основе использования именных групп

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

1. Релевантные или подходящие классы.

2. Нечеткие или сомнительные классы.

3. Нерелевантные или неподходящие классы.

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

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

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

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

Подход CRC

Подход CRC (C lass- R esponsibility- C ollaborators – класс-ответственность-“сотрудники”) представляет собой нечто большее, чем метод выявления классов, – это способ интерпретации и изучения объектов (а также и обучения объектному подходу). Подход CRC включает в себя сеансы “мозгового штурма”, проведение которых облегчается за счет использования специально подготовленных карточек. Карточки состоят из трех отделений: имяклассазаписывается в верхнем отделении, “обязанности” класса перечислены в левом отделении, а “сотрудники” перечислены в правом отделении. Обязанности - это услуги (операции), которые класс готов выполнить в интересах других классов. Для выполнения многих обязанностей необходимо участие (обслуживание) со стороны других классов. Такие классы перечисляются как “сотрудники”.

 Комплексный подход

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

Спецификация классов

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

Каждому классу необходимо присвоить имя.

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

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

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

Рисунок 5.1. Представление класса на диаграмме классов

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

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

Моделирование ассоциаций

Ассоциации служат объединению объектов в системе. Они способствуют взаимодействию между объектами.

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

Спецификация ассоциаций подразумевает выполнение следующих действий:

1 Присваивание имен ассоциациям.

2 Присваивание имен ассоциативным ролям.

3 Установление кратности ассоциации

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

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

Спецификация поведения

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

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

Вычисления можно смоделировать с помощью диаграмм видов деятельности.

Взаимодействие объектов можно задать с помощью диаграмм последовательностей или диаграмм кооперации.

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

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

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

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

2 Классы, представляющие графические интерфейсы (пограничные классы).

Рисунок 5.2. Изображение класса в RSA

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

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

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

 

Рисунок 5.3. Производный атрибут (/).

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

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

Рисунок 5.4. Производная ассоциация

Производную ассоциацию можно ввести т. к. кратность ассоциации между Order и Invoice равна 1 к 1.

Производная ассоциация не вносит в модель какой-либо новой информации. Всегда можно связать клиента (Customer) с определенным заказом (Order), отыскав один заказ для каждого счета-фактуры (Invoice), а затем одного клиента для каждого заказа.

Ассоциативный класс - ассоциация, которая сама является классом. Ассоциативный класс обычно используется в тех случаях, когда между двумя классами существует ассоциация “многие ко многим” и каждый экземпляр ассоциации (связь) обладает собственными значениями атрибутов. Чтобы обеспечить возможность хранить эти атрибуты, требуется класс - ассоциативный класс (рис.5.5.).

 

Рисунок 5.5. Ассоциативный класс

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

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

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

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

 

Рисунок 5.6. Материализованный класс

Иерархия классов

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

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

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

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

Пакеты

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

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

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

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

Подход BCE

Подход BCE (Boundary-Control-Entity – граница-управление-сущность) представляет собой подход к объектному моделированию, основанный на трехфакторном представлении классов. В языке UML для классов определены три стереотипа: boundary (граница), control (управление) и entity (сущность). Это и определило выбор аббревиатуры BCE.

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

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

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

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

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

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

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

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

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

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

Наследование интерфейса

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

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

 

Рисунок 5.7. Использование отношения реализации для представления наследования интерфейса

Наследование реализации

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

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

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

 

Рисунок 5.8. Расширяющее наследование

Производный класс Employee (Сотрудник) расширяет базовый класс Person (Личность). Класс Person на рис. 5.8 не является абстрактным классом. Могут существовать некоторые объекты Person, которые представляют просто некую личность (в том смысле, что они не являются сотрудниками, т.е. объектами класса Employee).

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

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

Основные факторы риска связаны со следующими перечисленными ниже проблемами:

● Изменчивость базового класса.

● Замещение и обратные вызовы.

● Множественное наследование реализации.

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

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

1 Подкласс может наследовать интерфейс и реализацию метода без внесения каких-либо изменений в реализацию.

2 Подкласс может наследовать код и включить его (вызвать его) в свой собственный метод с той же сигнатурой.

3 Подкласс может наследовать код и затем полностью заместить его новой реализацией с той же сигнатурой.

4 Подкласс может наследовать пустой код (т.е. декларация метода отсутствует), а затем ввести реализацию для метода.

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

Из этих пяти методов первые два доставляют наибольшие трудности.

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

Рисунок 5.9. Агрегация типа Безраздельно обладает

 

Объект Chapter (Глава) является частью, по меньшей мере, одного объекта Book (Книга). Будучи включенным в составной объект, он не может быть повторно соединен с другим объектом Book.

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

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

 

Рисунок 5.10. Агрегация типа Обладает

На рис. 5.10 показано два примера агрегации типа Обладает. Вода (объект Water) может быть перелита из одного кувшина (объект Jug) в другой. Аналогично, шина (объект Tire) может быть переставлена с одного велосипеда (Bicycle) на другой. Разрушение объекта Jug или Bicycle распространяется вниз на их компонентные объекты.

Для моделирования агрегации типа Включает в UML обычно используется ссылочная семантика агрегации (пустой ромб). Агрегация типа Включает не содержит зависимости по существованию - удаление составного объекта не распространяется автоматически вниз на компонентные объекты. Объект ГруппаСтудентов включает в себя объекты Студент. Разрушение группы не влияет на Студентов, они могут быть включены в другую группу.

Агрегация типа Участник допускает отношения с кратностью “многие ко многим”. Ее можно моделировать в UML только с помощью агрегации (пустой ромб). Объекты Студенты являются участниками объекта Лекция. Студент может посещать разные лекции, лекцию посещают разные студенты (отношение многие ко многим).

Агрегация является альтернативой обобщению. Обобщение - это отношение суперкласс-подкласс (общее - частное). Агрегация больше напоминает отношение супермножество–подмножество (целое - часть). Вопреки этому различию обобщение можно представить как агрегацию (рис. 5.11).

 

Рисунок 5.11. Обобщения или агрегация

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

Заказ в состоянии класс Order (Заказ) может быть классом PendingOrder (Ожидающий заказ). Класс PendingOrder может быть классом BackOrder (Невыполненный заказ) или классом FutureOrder (Заказ, выполняемый в будущем). Наследование гарантирует разделение атрибутов и операций вниз по дереву обобщения.

Аналогичную семантику можно смоделировать с помощью агрегации, показанной в правой части рисунка 5.11. Классы BackOrder и FutureOrder включают атрибуты и операции класса PendingOrder, которые, в свою очередь, включает класс Order.

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

 

 

Углубленный анализ

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

Моделирование классов

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

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

1. Знания в области моделирования классов.

2. Понимание проблемной области.

3. Опыт в области аналогичных и успешных проектов.

4. Способность смотреть вперед и предвидеть последствия решений.

5. Готовность к пересмотру модели с целью устранения недостатков и т.д.

Выявление классов

Выделяют четырех основные подхода к выявлению классов:

1. Подход на основе использования именных групп.

2. Подход на основе использования общих шаблонов для классов.

3. Подход на основе использования прецедентов.

4. Подход CRC (class-responsibility-collaborators – класс-обязанности-“сотрудники”).

Подход на основе использования именных групп

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

1. Релевантные или подходящие классы.

2. Нечеткие или сомнительные классы.

3. Нерелевантные или неподходящие классы.

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

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

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

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