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

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

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

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

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

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

Резюме

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

Глава 10. Проверка модели

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

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

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

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

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

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

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

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

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

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

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

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

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