Уделите особое внимание управляющим классам системы. Изначально для каждого прецедента предусматривается по одному управляющему классу. Однако управляющие классы со схожим поведением могут быть объединены. Изучите последовательную логику (sequencing logic) в управляющих классах системы. Если она идентична, управляющие классы можно объединить в один.
В системе регистрации учебных курсов имеется один управляющий класс для прецедента Сохранить информацию о курсах (Maintain Course Information) и один для прецедента Создать каталог курсов (Create Course Catalog). Каждый управляющий класс получает информацию от граничного класса и обрабатывает информацию о курсах. Вероятно, эти классы могут быть объединены, так как они имеют поведение и управляют одинаковой информацией.
Разделение классовКлассы обязательно проверяются на предмет соответствия «золотому» правилу объектно-ориентированной технологии, которое утверждает, что класс должен выполнять одну задачу и выполнять ее хорошо. Например, класс информация о студенте (Studentlnformation), содержащий сведения об актере студент, а также о курсах, которые тот закончил, выполняет слишком много функций. Его лучше представить в виде двух классов — информация о студенте и выписка (Transcript) — и ассоциативной связи между ними.
Часто атрибут класса имеет структуру и поведение внутри себя и должен быть выделен как отдельный класс. Например, рассмотрим факультет университета. Каждый учебный предмет предлагается определенным факультетом. Вначале эти сведения были представлены в модели как атрибут класса предмет (Course). Дальнейший анализ выявил необходимость получать данные о количестве студентов, обучающихся на факультете, количестве преподавателей, проводящих занятия на факультете, и количестве учебных предметов на каждом факультете. Таким образом, был создан отдельный класс факультет (Department). Первоначальный атрибут факультет в классе предмет был заменен ассоциативной связью между классами.
Исключение классовИногда класс вообще может быть удален из модели. Это происходит в следующих случаях:
□ когда класс не имеет какой-либо структуры или поведения;
□ когда класс не участвует в выполнении какого-либо прецедента.
Тщательно проверяйте управляющие классы. Отсутствие последовательных действий может указывать на удаление управляющего класса. Особенно в случае, когда он просто проходной, то есть получает информацию от граничного класса и тут же передает ее в класс-сущность без какой-либо последовательной логики.
В системе регистрации учебных курсов мы изначально создали управляющий класс для прецедента выбор курсов для преподавания (Select Courses to Teach). Он позволяет преподавателю определить курсы для чтения в данном семестре. Для управляющего класса здесь не нужна последовательная логика — преподаватель вводит информацию с помощью формы пользовательского интерфейса, и класс преподаватель добавляется к выбранному курсу. В данном случае управляющий класс для прецедента может быть удален.
Проверка целостностиПроверка целостности необходима потому, что статическое представление системы, показанное на диаграммах классов, и динамическое представление системы, изображенное на диаграммах прецедентов и диаграммах взаимодействий, разрабатываются параллельно. По причине одновременной разработки обоих представлений необходимо производить перекрестные проверки, чтобы убедиться, что в разных представлениях не сделаны разные допущения и не приняты различные решения.
Проверка целостности должна быть непрерывной частью всего жизненного цикла разрабатываемой системы.
Лучше всего, когда проверкой целостности занимается отдельная группа сотрудников (пять-шесть человек). В нее должны входить разные специалисты — аналитики, проектировщики, заказчики или их представители, эксперты по предметной области и специалисты по тестированию.
Проход по сценариюОсновной метод проверки целостности — проход по сценариям с наибольшим риском, представленным на диаграммах взаимодействий. Так как каждое сообщение отражает поведение получающего класса, убедитесь в том, что каждое сообщение реализовано в виде операции на диаграмме классов. Проверьте, что два взаимодействующих объекта связаны между собой с помощью ассоциации или агрегации. Внимательно проследите за возвратными отношениями: их легко упустить из виду на этапе анализа. Возвратные отношения требуются, когда различные объекты одного класса взаимодействуют друг с другом в ходе выполнения сценария.
Убедитесь, что каждый класс, представленный на диаграмме классов, участвует хотя бы в одном сценарии. Проверьте, чтобы каждая операция, определенная для класса, была использована, по крайней мере, в одном сценарии или требовалась для завершенности модели. И наконец, проследите, чтобы каждый объект, включенный в диаграмму последовательности действий или диаграмму взаимодействий, принадлежал одному из классов на диаграмме классов.
Отслеживание событийДля каждого сообщения, изображенного на диаграммах взаимодействий, проверьте, чтобы операция в классе-отправителе отправляла событие, а операция в классе-получателе ожидала событие и могла его обработать. Убедитесь в наличии ассоциативной или агрегационной связи на диаграмме классов между классом-отправителем и классом-получателем. Если такая связь отсутствует, добавьте ее на диаграмму классов. Если для класса уже создана диаграмма состояний и переходов, то событие на ней должно быть представлено для класса-получателя. Необходимо, чтобы диаграмма состояний отражала все события, которые может получать класс.
Просмотр документацииКаждый класс должен быть описан в документации! Проверьте уникальность имен классов и просмотрите все описания на предмет их полноты. Выясните, что все атрибуты и операции полностью документированы. На заключительном этапе убедитесь в соблюдении всех стандартов, форматов, спецификаций и правил оформления, определенных для проекта.
РезюмеПо мере добавления новых прецедентов и сценариев нужно добиваться однородности модели. Это особенно актуально, когда несколько групп разработчиков проектируют различные части модели. Классы проверяются на предмет необходимости:
□ объединения двух или более классов;
□ разделения класса;
□ исключения класса из модели.
Проверка целостности происходит на протяжении всего жизненного цикла проекта. Она требуется для параллельной разработки нескольких представлений системы и для синхронизации фрагментов системы. Существует три основных способа проверки целостности: проход по сценарию, отслеживание событий и просмотр документации модели.
Глава 11. Проектирование системной архитектуры
Потребность в архитектуреНа протяжении многих лет я слышала разные определения программной архитектуры: от «программная архитектура — это то, чем занимаются специалисты по программной архитектуре» до «программная архитектура — это политика». Я пришла к выводу, что для программной архитектуры очень трудно подобрать определение. Ее можно представить как набор средств, используемых для указания стратегических решений по структуре и поведению системы, взаимодействию между элементами системы и физическому размещению системы.
«Создание качественного архитектурного базиса необходимо для успешной реализации объектно-ориентированных проектов. Некоторые разработчики пытаются пропустить эту фазу, либо спешат с выпуском продукта, либо не верят в преимущества архитектурных решений. В любом случае результат всегда плачевный — недостаточная проработка этого шага приводит к постепенному распаду проекта»[6].
Развитие архитектуры — достаточно сложный вопрос. Архитектура системы развивается итеративно на стадии проработки. «Архитектура системы не возникает сразу. Она требует тщательного изучения прецедентов, создания прототипов для подтверждения основных концепций, создания архитектурного фундамента и других усилий в процессе задумки и проработки»[7]. Для проверки корректности решений на этапе проектирования моделируются работоспособные прототипы архитектуры. «Создание чего-то работоспособного очень важно, потому что позволяет группе специалистов проверять проектные предположения на практике»[8]3.
О разработчиках архитектурыВ каждом проекте должен участвовать главный специалист по архитектуре, у которого может быть несколько ассистентов. «В обязанности такого специалиста входит определение архитектуры программных продуктов, поддержка целостности архитектуры, оценка технических рисков проекта, определение порядка
