Для обнаружения граничных классов изучают пары актер/сценарий. Такие классы, определенные на фазе проработки, обычно являются классами верхнего уровня. Например, вы можете смоделировать окно, но не моделировать его диалоговые элементы и кнопки. В этом случае вы опишете требования пользовательского интерфейса, но не реализуете его.
Требования к пользовательскому интерфейсу порой недостаточно ясны. Обычно используются термины «дружественный» и «гибкий». Но дружественный интерфейс разными людьми трактуется по- разному Здесь могут пригодиться прототипы. Пользователь должен посмотреть и почувствовать систему, чтобы реально оценить, что значит «дружественный» И то, что это значит, затем представляется как структура и поведение граничного класса. На этапе проектирования такие классы совершенствуются и выносятся на обсуждение вопросов реализации пользовательского интерфейса.
Граничные классы также используются для обеспечения связи с другими системами. На этапе проектирования эти классы совершенствуются и выносятся на обсуждение вопросов реализации протоколов взаимодействия.
На ранней стадии проработки управляющие классы добавляются для каждой пары актер/прецедент. Такие классы определяют поток событий в прецедентах.
Вопрос использования управляющих классов очень субъективный. Многие авторы утверждают, что их применение приводит к отделению данных от поведения. Это может случиться, если управляющие классы выбраны неаккуратно. Если управляющий класс реализует что-то большее, чем последовательное действие, то он делает слишком много. Например: в системе регистрации учебных курсов студент выбирает курс, и если курс доступен, студента на него записывают.
Кто должен знать, как прикрепить студента, — управляющий класс или класс, представляющий курс занятий? Правильный ответ — класс, представляющий курс занятий. Управляющий класс знает лишь, когда студент должен быть прикреплен. «Плохой» управляющий класс знает не только когда, но и как прикрепить студента.
Управляющий класс для каждой пары актер/прецедент создается на начальном этапе. При дальнейшем анализе и проектировании управляющие классы могут исключаться, разделяться или объединяться.
Этапы создания стереотипов для классов в программе Rational Rose:
1. Щелкните правой кнопкой мыши по имени класса в списке браузера.
2. В появившемся контекстно-зависимом меню выберите команду Open Specification (Открыть параметры).
3. Щелкните по вкладке General (Общие).
4. В открывающемся списке Stereotype (Стереотип) выберите нужный стереотип. Чтобы создать новый стереотип, введите его имя в поле открывающегося списка Stereotype.
5. Щелкните по кнопке ОК, чтобы закрыть диалоговое окно настройки параметров класса.
Параметры для класса студент показаны на рис. 4.5. Если язык, выбранный
в модели по умолчанию, отличается от языка анализа (вкладка Notation (Нотация) диалогового окна Options (Настройки)), то в диалоговом окне параметров класса появится еще одна вкладка для языка.
После того как класс создан, информацию о нем необходимо отразить в документации. Документация предназначена для описания назначения класса, а не его структуры. Например, класс студент может быть описан следующим образом:
Информация, необходимая для регистрации студента и оплаты обучения. Студент — это человек, обучающийся в университете.
А вот пример неправильного описания:
Имя, адрес и телефон студента.
Оно раскрывает только структуру класса, которую можно увидеть, посмотрев на список атрибутов, и не поясняет, для чего нужен данный класс.
Трудности при выборе имени и описании класса могут свидетельствовать о том, что это недостаточно хорошая абстракция. В следующем списке перечислены возможнее варианты:
? можно определить имя и дать краткое, четкое описание — хороший класс-кандидат;
? можно определить имя и выбрать описание, похожее на описание другого класса, — объединить классы;
? можно определить имя, но потребуется целая книга, чтобы описать назначение класса, — разделить класс;
? нельзя определить имя и дать описание — требуется дополнительный анализ для выделения правильных абстракций.
Чтобы описать классы в программе Rational Rose:
1. Выберите класс в списке браузера.
2. Установите курсор в окне описания и введите описание класса. Описание класса представлено на рис. 4.6.
Если в системе существует немного классов, управлять ими достаточно легко. Многие системы состоят из большого количества классов, поэтому необходим механизм, позволяющий разбить их на группы и облегчающий управление и повторное использование. Здесь оказывается полезной концепция пакетов.
Каждый пакет содержит интерфейс, реализуемый набором его общедоступных классов (public classes), то есть тех, с которыми могут общаться классы из других пакетов. Остальные классы пакета — это классы реализации (implementation classes), которые не взаимодействуют с классами в других пакетах.
В сложной системе для облегчения восприятия пакеты могут быть созданы на этапе проработки. В более простой системе классы, выделенные на этапе анализа, могут быть сгруппированы в один пакет, представляющий саму систему. В ходе дальнейшего анализа и проектирования пакеты нужны для группировки классов, используемых в системной архитектуре.
В языке UML пакеты изображаются в виде папок (см. рис. 4.7). Чтобы создать пакеты в программе Rational Rose:
1. Щелкните правой кнопкой мыши по разделу Logical View (Логическое представление) в окне браузера.
2. В появившемся контекстно-зависимом меню выберите команду New => Package (Создать => Пакет).
