Что такое допустимый UML?

На первый взгляд, ответить на этот вопрос легко: допустимый UML — это язык, определенный в соответствии со спецификацией. Однако на практике ответ несколько сложнее.

Существенным в вопросе является то, на каких правилах базируется UML: описательных или предписывающих. Язык с предписывающи­ми правилами (prescriptive rules) управляется официальной основой, которая устанавливает, что является, а что не является допустимым языком, и какое значение вкладывается в понятие высказывания язы­ка. Язык с описательными правилами (descriptive rules) - это язык, правила которого распознаются по тому, как люди применяют его на практике. Языки программирования в основном имеют предписываю­щие правила, установленные комитетом по стандартам или основны­ми поставщиками, тогда как естественные языки, такие как англий­ский, в основном имеют описательные правила, смысл которых уста­навливается по соглашению.

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

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

Моя позиция состоит в том, что для большинства людей UML имеет описательные правила. Стандарт UML оказывает наибольшее влияние на содержание UML, но это делает не только он. Я думаю, что особенно верным это станет для UML 2, который вводит некоторые соглашения по обозначениям, конфликтующие или с определениями UML 1, или с использованием по соглашению, а также еще больше усложняет язык. Поэтому в данной книге я стараюсь обобщить UML так, как я его вижу: и стандарты, и применение по соглашению. Когда мне прихо­дится указывать на некоторое отличие в этой книге, я буду употреб­лять термин применение по соглашению (conventional use), чтобы обо­значить то, чего нет в стандарте, но, как я думаю, широко применяет­ся. В случае если что-то соответствует стандарту, я буду употреблять термин стандартный (standard) или нормативный (normative). (Нор­мативный - это термин, посредством которого люди обозначают утвер-

ждение, которое вы должны подтвердить, чтобы оно соответствовало стандарту. Поэтому выражение ненормативный UML - это своеобраз­ный способ сказать, что нечто совершенно неприемлемо с точки зре­ния стандарта UML.)

Рассматривая диаграмму UML, необходимо помнить, что основной принцип UML заключается в том, что любая информация на конкрет­ной диаграмме может быть подавлена. Это подавление может носить глобальный характер - скрыть все атрибуты - или локальный - не по­казывать какие-нибудь конкретные классы. Поэтому по диаграмме вы никогда не можете судить о чем-нибудь по его отсутствию. Даже если метамодель UML имеет поведение по умолчанию, например [1] для ат-. рибутов, когда вы не видите эту информацию на диаграмме, это может быть обусловлено либо поведением по умолчанию, либо тем, что она просто подавлена.

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

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