М. Фаулер, К. Скотт - UML Основы, страница 4

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

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

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

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

1,1 изображена небольшая часть метамодели языка 1)МЬ, которая показывает отношение между ассоциациями и обобщением. (Этот Фрагмент приведен с единственной целью — дать лишь общее представление о том, что такое метамодель. Я даже не буду пытаться давать здесь какие-либо дополнительные пояснения.) Рис. 1.1. Фрагмент метамодели языка ИМй Насколько велико влияние метамодели на того, кто использует соответствующую нотацию при моделировании? Как минимум, она помогает определить, что такое правильно построенная модель, то есть модель, являющаяся синтаксически правильной.

Кроме того, пользователь, обладающий высокой квалификацией в области методов, должен понимать данную метамодель. Однако большинству пользователей методов вовсе не нужно столь глубокое понимание метамодели для практического применения нотации языка УМ1 . Именно поэтому изложение материала в книге не является Формальным; я следую по пути традиционных методов и апеллирую к вашей интуиции, При желании получить более строгое изложение обратитесь к справочному руководству или официальной документации. Насколько глубоко вам придется погрузиться в изучение данного языка моделирования? Это зависит от цели„с которой вы его используете. Если вы располагаете САЯЕ-средством, которое генерирует код, то для получения эффективного кода необходимо хорошо понимать механизм интерпретации языка моделирования этим САЯЕ-средством.

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

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

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

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

Таким образом, я использую язык БМЬ, когда мне необходима вполне определенная точность, но не нужны излишние детали, Но это вовсе не означает, что при этом не рассматрива- Глава 1. Введение ются детали. Скорее наоборот, я использую язык СМ? с целью выдви- жения на первый план именно важных деталей. В качестве консультанта мне зачастую приходится вникать в сложные проекты и какое-то время выглядеть интеллектуалом.

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

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

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

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

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

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

Это вовсе не означает, что так уж трудно научиться разрабатывать программы на каком-либо объектно-ориентированном языке программирования. Проблема заключается в том, чтобы научиться использовать преимущества объектно-ориентированных языков. Том Хэдфилд (Тош Нас)1(е16) удачно сформулировал это следующей фразой: объектные языки обладают преимуществами, но не предоставляют их автоматически. Чтобы использовать эти преимущества, вы должны пойти на смену пользующейся плохой славой парадигмы.