Читаем Rational Rose 2000 и UML Визуальное моделирование полностью

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Резюме

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

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

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

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

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

Глава 11. Проектирование системной архитектуры

Потребность в архитектуре

Перейти на страницу:

Похожие книги

Возвышение Меркурия. Книга 12 (СИ)
Возвышение Меркурия. Книга 12 (СИ)

Я был римским божеством и правил миром. А потом нам ударили в спину те, кому мы великодушно сохранили жизнь. Теперь я здесь - в новом варварском мире, где все носят штаны вместо тоги, а люди ездят в стальных коробках. Слабая смертная плоть позволила сохранить лишь часть моей силы. Но я Меркурий - покровитель торговцев, воров и путников. Значит, обязательно разберусь, куда исчезли все боги этого мира и почему люди присвоили себе нашу силу. Что? Кто это сказал? Ограничить себя во всём и прорубаться к цели? Не совсем мой стиль, господа. Как говорил мой брат Марс - даже на поле самой жестокой битвы найдётся время для отдыха. К тому же, вы посмотрите - вокруг столько прекрасных женщин, которым никто не уделяет внимания.

Александр Кронос

Фантастика / Аниме / Героическая фантастика / Попаданцы / Бояръ-Аниме