Терри Кватрани - Rational Rose 2000 и UML Визуальное моделирование

6. Дважды щелкните по новому действию в списке, чтобы открыть диалоговое окно Action Specification(Параметры действия).

7. Укажите момент выполнения действия: on entry(при входе), on exit(при выходе), on event(при определенном событии).

8. Введите описание действия или события.

9. Укажите тип действия: action(действие) или send event(вызов события).

10. Если требуется, введите название действия или события.

11. Щелкните по кнопке ОК,чтобы закрыть диалоговое окно Action Specification.

12. Щелкните по кнопке ОК,чтобы закрыть диалоговое окно State Specification.

Параметры состояний на диаграмме состояний показаны на рис. 9.11.

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

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

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

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

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

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

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

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

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

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

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

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

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

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