Для чего нужна однородность

Согласно новому академическому словарю Вебстера слово «гомогенизировать» (homogenize) означает превращать в однородную массу, делать гомогенным, то есть однородным. По мере добавления новых прецедентов и сценариев необходимо добиваться, чтобы модель стала однородной. Это особенно актуально, когда несколько групп разработчиков создают различные части модели. Так как прецеденты и сценарии описываются обычными словами, для обозначения одной и той же вещи могут использоваться разные слова, смысл которых может трактоваться по-разному. На данном этапе возможно объединение, разделение или исключение классов из модели. Это процесс естественного развития и совершенствования модели в течение жизненного цикла проекта.

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

 

Объединение классов

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

Уделите особое внимание управляющим классам системы. Изначально для каждого прецедента предусматривается по одному управляющему классу. Однако управляющие классы со схожим поведением могут быть объединены. Изучите последовательную логику (sequencing logic) в управляющих классах системы. Если она идентична, управляющие классы можно объединить в один.

В системе регистрации учебных курсов имеется один управляющий класс для прецедента Сохранить информацию о курсах (Maintain Course Information) и один для прецедента Создать каталог курсов (Create Course Catalog). Каждый управляющий класс получает информацию от граничного класса и обрабатывает информацию о курсах. Вероятно, эти классы могут быть объединены, так как они имеют поведение и управляют одинаковой информацией.

 

Разделение классов

Классы обязательно проверяются на предмет соответствия «золотому» правилу объектно-ориентированной технологии, которое утверждает, что класс должен выполнять одну задачу и выполнять ее хорошо. Например, класс информация о студенте (StudentInformation), содержащий сведения об актере студент, а также о курсах, которые тот закончил, выполняет слишком много функций. Его лучше представить в виде двух классов — информация о студенте и выписка (Transcript) — и ассоциативной связи между ними.

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

 

Исключение классов

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

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

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

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

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

 

Проверка целостности

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

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

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

 

Проход по сценарию

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

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

 

Отслеживание событий

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

 

Просмотр документации

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

 

Резюме

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

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

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

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

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