М. Фаулер, К. Скотт - UML Основы (1114905), страница 17
Текст из файла (страница 17)
Я пришел к выводу, что если этого не сделать, то можно столкнуться с серьезными проблемами, поскольку при последующих изменениях стабильность обобщения может нарушиться. Иногда можно встретиться с ситуацией, когда подтип обладает таким же интерфейсом, как супертип, но реализует операции другим способом. При желании можно и не показывать подтип на диаграмме уровня спецификации.
Я обычно указываю подтип, если в его существовании заинтересованы пользователи класса, и не указываю, если подтипы отличаются только особенностями внутренней реализации. Правила ограничения При построении диаграмм классов большая часть времени уходит на представление различных ограничений. На рис. 4.2 показано, что Заказ может быть сделан только одним единственным Клиентом. Из этой диаграммы классов также следует, что каждая Позиция заказа рассматривается отдельно: вы можете заказать 40 каких-либо коричневых штучек, 40 голубых этих же штучек и 40 красных таких же штучек, но не 40 коричневых, голубых и красных штучек.
Далее диаграмма утверждает, что Корпоративный клиент располагает кредитным лимитом, а Индивидуальный клиент — нет. С помощью базовых конструкций ассоциации, атрибута и обобщения можно много сделать, специфицируя наиболее важные ограничения, но этими средствами невозможно записать каждое ограничение. Эти ограничения еще нужно каким-то образом отобразить, и диаграмма классов является вполне подходящим местом для этого. Язык УМ1, разрешает использовать для записи ограничений все что угодно.
При этом необходимо лишь придерживаться правила: ограничения следует помещать в фигурные скобки (()). Я предпочитаю пользоваться неформальной записью ограничений на естественном языке, Правила ограничения чтобы их было проще понимать. Язык 1)МБ также предоставляет для этой цели формальный язык объектных ограничений (ОС)ч ОЪ)ес1 Сопэ$га1п$ 1 апяиаяе), с которым можно познакомиться по книге Уормера ( «Чагшег) и Клеппе (К1ерре), 1998 1451. В идеальном случае правила ограничения следует реализовывать в виде утверждений на языке программирования.
Это согласуется с понятием инварианта при проектировании по контракту (см. врезку). Проектирование по контракту Проектирование по контракту (Рез(яп Ъу Соп1гас1) — это метод проектирования, разработанный Бертраном Мейером. Этот метод является центральным свойством языка Е1Ле1, который он разработал. Однако проектирование по контракту не является специфичным только для языка ЕШе1; этот метод может быть использован и с любым другим языком программирования. Главной идеей метода проектирования по контракту является понятие утверждения. Утверждение — это булево высказывание, которое никогда не должно принимать ложное аначение и поэтому может быть ложным только в результате ошибки. Обычно утверждения проверяются только во время отладки и не проверяются в режиме выполнения.
Действительно, при работе программы никогда не предполагается, что утверждения будут проверяться. Метод проектирования по контракту использует три вида утверждений:предусловия„постусловияи инварианты. Предусловия и постусловия применяются к операциям. Постусловие — это высказывание относительно того, как будет выглядеть окружающий мир после выполнения операции.
Например, если мы определяем для числа операцию «извлечь квадратный корень», постусловие может принимать форму вход = результат * результат, где результат является выходом, а вход — исходное значение числа. Постусловие — это хороший способ выразить, что должно быть сделано, не говоря при этом, как это сделать. Другими словами, постусловия позволяют отделить интерфейс от реализации. Предусловие — это высказывание относительно того, как должен выглядеть окружающий мир до выполнения операции.
Для операции «извлечь квадратный корень» можно определить предусловие вход >= д. Такое предусловие утверждает, что применение операции «извлечь квадратный корень» для отрицательного числа является ошибочным и последствия такого применения будут неопределенными. На первый взгляд эта идея кажется неудачной, поскольку нам придется выполнить некоторые дополнительные проверки, что- Глава 4. Диаграммы классов: основы бы убедиться в корректности выполнения операции «извлечь квадратный корень». При этом возникает важный вопрос: кто должен быть ответственным за выполнение этой проверки. Предусловие явно устанавливает, что за подобную проверку отвечает вызывающий объект.
Без такого явного задания ответственности мы можем получить либо недостаточную проверку (когда каждая из сторон предполагает, что ответственной является другая), либо чрезмерную проверку (когда она будет выполняться обеими сторонами). Чрезмерная проверка тоже плоха, поскольку она влечет за собой дублирование кода проверки, что, в свою очередь, может существенно увеличить сложность программы. Явное определение ответственности помогает уменьшить эту сложность.
При этом может быть уменьшена опасность того, что вызывающий объект забудет выполнить проверку, поскольку утверждения обычно проверяются во время отладки и тестирования. Исходя из этих определений предусловия и постусловия, мы можем дать строгое определение термина «исключение», которое имеет место, когда предусловие операции удовлетворяется, но операция не может возвратить значение, даже если ее постусловие тоже выполнено. Инвариант представляет собой утверждение относительно класса.
Например, класс Счет может иметь инвариант вида «баланс сумма(позиция.количестпво())». Инвариант должен быть «всегда» истинным для всех экземпляров класса. «Всегда» в данном случае означает «всякий раз, когда объект инициирует выполнение какой бы то ни было операции». По существу, зто означает, что инвариант дополняет предусловия и постусловия, связанные со всеми общедоступными операциями отдельного класса.
Значение инварианта может оказаться ложным во время выполнения некоторого метода, однако оно должно быть восстановлено к моменту начала взаимодействия с любым другим объектом, Утверждения могут играть уникальную роль в задании подклассов. Одна из опасностей полиморфизма заключается в том, что вы можете переопределить операции подкласса таким образом, что они станут несовместимыми с операциями суперкласса. Утверждения не позволят вам выполнить подобные действия. Инварианты и постусловия класса должны применяться ко всем подклассам. Подклассы могут усилить эти утверждения, но не могут ослабить их. С другой стороны, предусловие нельзя усилить, но можно ослабить. Правила ограничения 29 На первый взгляд все это выглядит излишеством, однако является весьма важным для обеспечения динамического связывания.
Вы всегда должны иметь возможность обратиться к экземпляру подкласса, как если бы он был экземпляром суперкласса (в соответствии с принципом замещения). Если подкласс усилил свое предусловие, то операция суперкласса, примененная к подклассу, может завершиться аварийно. По существу, утверждения могут только усилить ответственность подкласса. Предусловия являются высказываниями, передающими ответственность вызывающему объекту; таким образом, ответственность класса можно усилить путем ослабления предусловия. На практике все эти средства позволяют намного лучше управлять процессом определения подклассов и помогают обеспечить корректное поведение подклассов. В идеальном случае утверждения следует включать в код как часть определения интерфейса. Компиляторы должны обладать способностью выполнять проверку утверждений во время отладки и исключать ее в процессе штатной эксплуатации.
Проверка утверждений может выполняться на различных этапах разработки. Часто именно предусловия предоставляют отличные возможности для обнаружения ошибок при минимальных затратах времени и сил. Когда следует использовать проектирование по контракту Проектирование по контракту оказывается весьма полезным методом при разработке понятных интерфейсов. Утверждения поддерживаются как часть нотации только в языке Е1Ле), но, к сожалению, Е)тте! не является широко распространенным языком программирования. Для непосредственной поддержки таких утверждений в других языках программирования можно использовать дополнительные механизмы, хотя это и представляет определенные неудобства. В языке ()М1, об утверждениях сказано не слишком много, но их без труда можно использовать.
Инварианты эквивалентны правилам ограничений на диаграммах классов, и их следует применять как можно чаще. Предусловия и постусловия операции следует документировать при определении операций. Где найти дополнительную информацию Книга Мейера (Меуег), 1997 [33] является классической работой в области объектно-ориентированного проектирования, в ней много внимания уделяется утверждениям. Ким Уолден и ЖанМарк Нирсон, 1995 [44), а также Стив Кук и Джон Дэниелс, 1994 [13) в своих книгах часто прибегают к использованию метода контрактного проектирования. во Глава 4. Диаграммы классов: основы Дополнительную информацию можно также получить в компании 1ЯЕ, сотрудником которой является Бертран Мейер, в Интернете по адресу: шклв.е~тейсот.
Когда использовать диаграммы классов Диаграммы классов являются фундаментом почти всех объектно-ориентированных методов, поэтому вы будете работать с ними практически постоянно. Данная глава охватывает только основные понятия; в главе 6 рассматриваются более сложные понятия. Трудность, связанная с использованием диаграмм классов, заключается в том, что их нотация слишком богата и в ней можно заблудиться.
Приведем лишь несколько полезных советов по этому поводу. ° Не пытайтесь использовать сразу все доступные понятия. Начните с самых простых, которые рассмотрены в этой главе: классов, ассоциаций, атрибутов, обобщений и ограничений. Используйте дополнительные понятия, рассмотренные в главе 6, только тогда, когда это действительно необходимо. ° Выбор точки зрения для построения модели должен соответствовать конкретному этапу работы над проектом: На этапе анализа стройте концептуальные модели.
Если вы работаете с программным обеспечением, сосредоточьте свое внимание на моделях спецификации. Применяйте модели реализации только в тех случаях, когда иллюстрируете конкретный способ реализации. ° Не надо строить модели для всего на свете; вместо этого следует сконцентрироваться на главных аспектах. Лучше иметь мало диаграмм, которые постоянно используются в работе и отражают все внесенные изменения, чем иметь дело с большим количеством забытых и устаревших моделей.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
