Часто атрибут класса имеет структуру и поведение внутри себя и должен быть выделен как отдельный класс. Например, рассмотрим факультет университета. Каждый учебный предмет предлагается определенным факультетом. Вначале эти сведения были представлены в модели как атрибут класса предмет (Course). Дальнейший анализ выявил необходимость получать данные о количестве студентов, обучающихся на факультете, количестве преподавателей, проводящих занятия на факультете, и количестве учебных предметов на каждом факультете. Таким образом, был создан отдельный класс факультет (Department). Первоначальный атрибут факультет в классе предмет был заменен ассоциативной связью между классами.

Иногда класс вообще может быть удален из модели. Это происходит в следующих случаях:

? когда класс не имеет какой-либо структуры или поведения;

? когда класс не участвует в выполнении какого-либо прецедента.

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

В системе регистрации учебных курсов мы изначально создали управляющий класс для прецедента выбор курсов для преподавания (Select Courses to Teach). Он позволяет преподавателю определить курсы для чтения в данном семестре. Для управляющего класса здесь не нужна последовательная логика — преподаватель вводит информацию с помощью формы пользовательского интерфейса, и класс преподаватель добавляется к выбранному курсу. В данном случае управляющий класс для прецедента может быть удален.

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

Проверка целостности должна быть непрерывной частью всего жизненного цикла разрабатываемой системы.

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

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

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

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

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

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

? объединения двух или более классов;

? разделения класса;

? исключения класса из модели.

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

На протяжении многих лет я слышала разные определения программной архитектуры: от «программная архитектура — это то, чем занимаются специалисты по программной архитектуре» до «программная архитектура — это политика». Я пришла к выводу, что для программной архитектуры очень трудно подобрать определение. Ее можно представить как набор средств, используемых для указания стратегических решений по структуре и поведению системы, взаимодействию между элементами системы и физическому размещению системы.

«Создание качественного архитектурного базиса необходимо для успешной реализации объектно- ориентированных проектов. Некоторые разработчики пытаются пропустить эту фазу, либо спешат с выпуском продукта, либо не верят в преимущества архитектурных решений. В любом случае результат всегда плачевный — недостаточная проработка этого шага приводит к постепенному распаду проекта»[6].

Развитие архитектуры — достаточно сложный вопрос. Архитектура системы развивается итеративно на стадии проработки. «Архитектура системы не возникает сразу. Она требует тщательного изучения прецедентов, создания прототипов для подтверждения основных концепций, создания архитектурного фундамента и других усилий в процессе задумки и проработки»[7]. Для проверки корректности решений на этапе проектирования моделируются работоспособные прототипы архитектуры. «Создание чего-то работоспособного очень важно, потому что позволяет группе специалистов проверять проектные предположения на практике»[8] ³.

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