Приемы объектно-ориентированного анализа и дизайна. Зачем использовать анализ и дизайн?

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

Изучение ОО подхода

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

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

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

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

Еще одна важная технология это итеративная разработка (evolutionary development) (Комментарий редактора: имеется в виду итеративный процесс разработки, когда на каждой итерации создается "продукт", усеченный по своим функциональным возможностям, и каждая следущая итерация расширяет эти возможности). Она не поможет вам выучить что-либо напрямую, но это ключ к эффективному использованию ОО подхода. Если вы используете итеративную разработку с самого начала, вы в контексте освоите правильные приемы процесса и начнете понимать, почему дизайнеры рекомендуют делать вещи определенным образом.

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

Общение с экспертами

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

Варианты использования (use cases) - наиболее простая методика для этого. Варианты использования это что-то вроде внешнего вида вашей системы, они подробно разъясняют, что ваша система должна делать. Хорошая коллекция вариантов использования -- основа для понимания того, что хотят пользователи. Они также предоставляют хорошую поддержку для планирования выполнения проекта, так как они определяют этапы поставки ПО (evolutionary delivery), что само по себе является ценной технологией, так как дает пользователям регулярную информацию о том, как развивается ваш проект.

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

Видение проекта вцелом

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

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

TOC | Часть 3