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

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

Работа разбивается на три стадии.

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

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

Вторая стадия. В составленном тексте выделяют подлежащие и сказуеммые. Выделение производится механически, без привязки к проблемной области.

Третья стадия. Выделенные подлежащие, с большой вероятностью, являются кандидатами на имена классов. Сказуемые при нем являются кандидатами на методы соответствующего класса. Можно пойти далее — дополнения являются аргументами методов класса.

Важно соблюдать правила:

• Не забывать об итерационном процессе разработки. При проведении каждой стадии стоит все спорные и сомнительные моменты рассматривать на материале предыдущих стадий. И, не раздумывая, корректировать материалы следующих за корректируемой стадий.
• Итерационный процес не должен быть заменет на полный пересмотр всего материала предыдущих стадий. При каждой итерации изменения материалов предыдущих стадий должны быть счетными и доводиться до изменения материала текущей стадии (в период обучения изменения материалов предыдущих стадий необходимо принципиально ограничить единичными изменениями). Иначе все сведется к потере времени и отсутствии прогресса в развитии проекта.
• Не забывать что главный критерий оценки принимаемых решений — требования технического задания. А каждый проект или его часть должны иметь ТЗ — даже если оно тривиальное. Это особенно важное правило для начинающего разработчика, является он программистом или нет.

Самое место привести пример. Но хорошего примера с ходу придумать не получилось, а плохой приводить не хочу — лучше оставлю без примера (добавлю как только попадется под руку).