Дж. Рамбо, М. Блаха - UML 2.0 - Объектно-ориентированное моделирование и разработка (1158633), страница 54
Текст из файла (страница 54)
Реструктурирование при помощи наследования Следующий шаг: организация классов при помощи наследования путем выявления их общей структуры. Наследование может быть использовано двумя способами: как обобщение одинаковых аспектов существующих классов в суперклассах (снизу вверх) и как конкретизация существующих классов множеством подклассов (сверху вниз). ° Обобщение снизу вверх. Наследование можно прослеживать снизу вверх путем поиска классов с одинаковыми атрибутами, ассоциациями и операциями. Для каждого обобщения следует определить суперкласс, в котором будут содержаться общие черты.
Для этого вам, возможно, придется несколько переопределить некоторые атрибуты или классы. Это вполне допустимо, однако не следует слишком упорствовать: возможно, вы неправильно выявили обобщение. Некоторые обобщения копируются из реального мира. Везде, где это возможно, следует использовать существующие понятия. Недостающие классы можно выписывать из соображений симметрии. Пример с банкоматом.
Классы ЯетогеТгапвасггоп (Удаленнаятранзакция) и СавЫегТгапвасггоп (КассоваяТранзакция) подобны друг другу (за исключением инициализации) и могут быть обобщены классом Тгапвасггоп (Транзакция). С другой стороны, с точки зрения нашего примера классы Сепгга!Сотригег (ЦентральныйКомпьютер) и Вапггсотригег (Банковский- Компьютер) имеют довольно мало общего, поэтому обобщать их не следует. ° Конкретизация сверху вниз. Конкретизация обычно следует из описания области приложения.
Ищите именные группы, состоящие из различных прилагательных с именем класса: флуоресцентпая лампа, лампа накаливания, фиксированное меню, раскрывающееся меню, выдвигающееся меню. Избегайте чрезмерного уточнения. Если предлагаемая конкретизация несовместима с существующим классом, возможно, этот класс просто неправильно сформулирован. ° Обобщение и перечисление.
Перечислимые подклассы области приложения чаше всего попадают под определение конкретизации. Обычно бывает достаточно отметить существование множества перечислимых частных случаев без явного их указания. Например, счет (в примере с банкоматом) может быть счетом до востребования или сберегательным счетом. В некоторых банковских приложениях такое деление может быть очень важным, однако на поведение банкомата оно не влияет, поэтому гуре (тип счета) можно сделать просто атрибутом класса Ассоипг (Счет).
° Множественное наследование. Вы можете использовать множественное наследование, но только тогда, когда это действительно необходимо, так как оно повышает концептуальную и техническую сложность модели. ° Подобные ассоциации. Если название ассоциации появляется в модели несколько раз, причем несет оно при этом одинаковый смысл, попробуйте обобщить ассоциируемые классы.
Иногда у таких классов может не быть 236 Глава 12 ° Анализ предметной области ничего общего, за исключением ассоциации, но достаточно часто вы будете обнаруживать общие черты, пропущенные на предыдущих этапах. Пример с банкоматом. Тгапзасггоп (Транзакция) вводится как посредством Сазгггег5гаггоп (Касса), так и на АТМ (Банкомат).
Класс Епггу5гаггоп (Устройство ввода) обобщает классы Саз)него тат!оп и А ТМ. ° Корректирование уровня наследования. Атрибуты и ассоциации должны быть присвоены конкретным классам из иерархии. Каждый из них должен быть присвоен наиболее общему классу, к которому он применим. Для этого вам могут потребоваться некоторые корректировки. Из симметрии может следовать наличие дополнительных атрибутов, которые позволят более четко отличать подклассы друг от друга. На рис. 12.11 показана модель классов банкомата после добавления наследования. Епвувтвоп 1 Тгепззсг!оп ЕпгегеаОп мпс Св!ет!те атсип! АТМ СввЫегвгевоп 0.,1 СввЫег Тгепввсвоп Нето!в Тгвпввсвоп севЬОпизпа 0..1 0..1 Соттил/се!ее Игла 1 Ссттил!се!ее илт ЕлгетаВу в!в!!ЬпСсае СввЫег вы!юпСсне Сеп!гв! Сотри!е! Ьвп С е ! АиГлспвеаВу Вела Сотри!ег пате Етргсуз 0..1 Соттипивгез 1 и/м 1 !ззиез 0..1 Сеанса!а рввз нсгс Сив!отег „ 1 в!езсп Ссае паве ваагезв 1 егпр!суее 1 Ввпа Ссае О..
пеп!е сага ессеи п! Сове 1 Свае 1 Сопвогвит Ьвпх Свае Ассов п! Ьв!в псе сгеа!!Ыт!1 !уре 0..1 Рис. 12.11. Преобразованная модель классов банкомата 12.2.9. Проверка маршрутов Проследите маршруты в модели классов и проверьте, что все они дают разумные результаты. Если в некотором месте предполагается уникальное значение, существует ли маршрут, дающий уникальный результат? Предусмотрен ли метод 12.2. Модель классов предметной области 237 выбора уникальных значений объектов, охарактеризованных кратностью «много«? Подумайте, какие вопросы вы считаете важными.
Есть ли важные вопросы, на которые вы не можете ответить? Такие вопросы указывают на недостающую информацию. Если что-то простое из реального мира в модели оказалось сложным, вы могли что-то пропустить (однако обязательно проверьте, не свойственна ли та же сложность реальному миру). В модели могут присутствовать классы, не связанные ни с какими другими. Обычно это происходит тогда, когда отношение между такими классами и остальной моделью носит распределенный (размытый) характер.
Однако всегда проверяйте такие классы, потому что вы могли просто пропустить существующую ассоциацию. Пример с банкоматом. Кредитная карта сама по себе не является уникальным идентификатором счета, поэтому пользователь должен иметь возможность какимто образом выбрать свой счет. Если пользователь укажет тнп счета (до востребования или накопительный), по каждой карте можно будет обращаться только к одному счету каждого типа. Это кажется разумным, и многие карты действительно так и работают, но такое решение ограничивает систему. Альтернатива— потребовать, чтобы клиенты помнили номера счетов.
Если кредитная карта работает с одним счетом, переводы денег между счетами невозможны. Мы предположили, что сеть банкоматов обслуживает один консорциум банков. Реальные банкоматы часто обслуживают перекрывающиеся сети банков и принимают не только банковские, но и кредитные карты. Нашу модель пришлось бы расширить, чтобы описать такую ситуацию.
Мы будем предполагать, что клиент не возражает против определенных ограничений нашей системы. 12.2.10. Итерационная разработка модели классов Модель классов редко оказывается правильной после первого же прохода. Весь процесс разработки программного обеспечения строится на итерациях. Разные части модели обычно находятся на разных стадиях разработки.
Если вы нашли недостаток, вернитесь на предыдущую стадию (при необходимости) и устраните его. Некоторые уточнения могут быть сделаны только после разработки моделей состояний и взаимодействия. Недостающие классы можно выявить по следующим признакам. ° Асимметрия обобщений и ассоциаций. Добавляйте новые классы по аналогии с имеющимися. ° Разные атрибуты и операции в одном классе.
Разбейте класс таким образом, чтобы каждый из новых классов получился цельным. ° Сложно провести ясное обобщение. Один класс может играть две роли. Разделите его, и тогда каждый из новых классов сразу же займет свое место в иерархии. ° Дублирование ассоциаций с одинаковым названием и смыслом. Обобщите классы, выделив объединяющий их суперкласс. 238 Глава 12 ° Анализ предметной области ° Роль формирует семантику класса. Возможно, ее следует выделить в собственный класс.
Часто это означает преобразование ассоциации в класс. Например, человек может работать в нескольких компаниях на разных условиях. Тогда Етр(оуее — отдельный класс, обозначающий человека, работающего на конкретную компанию (в дополнение к классам Регзоп и Сотрапу). Ищите также недостающие ассоциации. ° Отсутствуют маршруты для обращения к операциям. Добавьте ассоциации, которые позволят вам отвечать на запросы. Нужно позаботиться и об избыточных элементах модели. ° У класса нет атрибутов, операций и ассоциаций. Зачем он тогда нужен? Не создавайте подклассы просто для отражения перечисления.
Если потенциальные подклассы во всем похожи друг на друга, используйте атрибуты. ° Избыточная информация. Улаляйте ассоциации, не несущие новых сведений, или помечайте их как производные. Наконец, нужно скорректировать размещение атрибутов и ассоциаций. ° Имена полюсов слишком широкие или слишком узкие по сравнению с классами, находящимися около этих полюсов. Переместите ассоциацию вверх нли вниз по иерархии классов. ° Обращение к объекту осуществляется по значению одного из его атрибутов.
Рассмотрите возможность создания квалифицированной ассоциации. На практике схема построения модели выглядит не такой жесткой, как та, что была описана нами. После приобретения необходимого опыта вы сможете объединять некоторые этапы в один. Например, вы можете выделить потенциальные классы, отбросить некорректные, даже не выписывая их, после чего добавить классы на диаграмму вместе с ассоциациями. Некоторые части модели можно прорабатывать более тщательно, чем другие.
Порядок этапов проектирования при необходимости можно изменять. Однако в процессе изучения моделирования классов мы рекомендуем вам первые несколько раз в точности следовать описанной схеме. Пример с банкоматом. Класс СайСаЫ(БанковскаяКарта) на самом деле обладает двойственной сущностью; это одновременно модуль, прн помощи которого осуществляется авторизация клиента для доступа к его счетам, и кусочек пластика, с которого банкомат считывает закодированные идентификаторы. В данном случае коды являются частью реального мира, а не просто компьютерными артефактами. Именно коды, а не сама кредитная карта передаются в центральный компьютер.
Нам следует разделить банковскую карту на два класса: Сап1Аиглогтгаг(ол (Картадвторизации) — носитель права на доступ к счетам клиента, и СпзлСаЫ (БанковскаяКарта) — кусочек пластика, на котором записан код банка и номер банковской карты, имеющий смысл для этого банка. Одной карте авторизации может соответствовать несколько банковских карт, каждая из которых должна по соображениям безопасности обладать своим последовательным номером. Код карты, написанный на ней самой, идентифицирует карту авторизации в данном 12.2. Модель классов предметной области 239 ТгапвасИоп 1 ба1еТзпе ЕпГегебОп Епиувсабоп Ирбаге атоипг К!пб СавЫег Тгапваспоп Иетоге Тгапваспоп Епгегебву 1 СавЫег Аивоопгебву пате Етр1оув О..! Савщегвгапоп АТМ савЬОпмапб 0..1 0..1 Газиев 0..1 Сагб Аигвог!запое СазЬСап! раввегогб Игп!1 1 вмвоп вепа!питЬег Собе 1 в!авоп етр!оуее 1 Собе Вала обе 0..1 Сивготег сагб Собе 1 пате Сопвогвит Ьапх Себе 1 пате або геев Ассоип1 * ассоип1 Собе 1 Ьа!апсе сгеб!! !па! ' 1уре 0..1 Рис.