Методические указания по выполнению лабораторной работы Подготовила: Романова Т. Н (стр. 3 из 6)

Учебный курс

Место занятий

Добавить студента

Рис. 2.Нотация языка UML Рис. 3. Класс, созданный в окне браузера

для классов

Порядок создания классов в программе Rational Rose:

1. Щелкните правой кнопкой мыши по разделу Logical View (Логическое представление) в окне браузера.
2. В появившемся контекстно-зависимом меню выберите команду New → Class (Создать → Класс). В список браузера будет добавлен новый класс с именем New Class.

3. Введите нужное имя класса.

Класс в окне браузера показан на рис.3.

Стереотипы и классы

Мы уже говорили о стереотипах отношений на диаграмме функций. Классы тоже могут иметь стереотипы. Как и ранее, стереотип используется для создания нового типа элемента моделирования, в данном случае для создания нового типа элемента моделирования, в данном случае для создания новых типов классов. Некоторые основные стереотипы класса- это сущность, граничный элемент, элемент управления, сервисный элемент и исключение.

Стереотип класса указывает под его именем и заключается в двойные треугольные скобки. Если требуется, стереотип можно отобразить графическим значком или выделить цветом. В программе Rational Rose есть изображения для стереотипов Rational Unifield Process – управляющего элемента, сущности и граничного элемента. Эти стереотипы, а также пример класса со стереотипом исключение показаны на рис. 4.

Рис. 4. Классы со стереотипами

Обнаружение классов

Рецептов для поиска классов не существует. Как сказал Грейди Буч: «Это действительно трудно!» Rational Unifield Process содержит средства, помогающие обнаружить в системе классы типа управляющий элемент, граничный элемент, сущность. Эти три стереотипа соответствуют концепции «модель-представление-управление» и позволяют аналитику отделить друг от друга представление, предметную область и управление в системе.

По причине того, что процесс анализа и проектирования является интерактивным, список классов со временем изменится. Начальный набор классов, скорее всего, будет отличаться от итогового. Поэтому для описания начального набора классов, обнаруженных в системе, часто используется термин «класс-кандидат».

Классы-сущности

Класс-сущность (entity class) используется для моделирования данных и поведения с длинным жизненным циклом. Этот тип классов может представлять сущности реального мира или внутренние элементы системы. Такие классы обычно не зависят от окружения, то есть они нечувствительны к взаимодействию окружающей среды с системой. Следовательно, они не зависят от приложения и могут использоваться в различных приложениях.

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

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

Граничные классы

Граничные классы (boundary class) обеспечивают взаимодействие между окружающей средой и внутренними элементами системы. Такие классы предоставляют интерфейс для пользователя или другой системы (то есть актера). Они составляют внешне зависимую часть системы для моделирования интерфейсов системы.

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

Требования к пользовательскому интерфейсу порой недостаточно ясны. Обычно используются термины «дружественный» и «гибкий». Но дружественный интерфейс разными людьми трактуется по-разному. Здесь могут пригодиться прототипы. Пользователь может посмотреть и почувствовать систему, чтобы реально оценить, что значит «дружественный». И то, что это значит, затем представляется как структура и поведение граничного класса. На этапе проектирования такие классы совершенствуются и реализуются пи создании пользовательского интерфейса.

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

Управляющие классы

Управляющие классы (control class) служат для моделирования последовательного поведения одного или нескольких прецедентов и координации событий, реализующих заложенное в них поведение. Управляющие классы можно представить как классы, «исполняющие» прецедент и определяющие его динамику. Они обычно зависят от приложения.

На ранней стадии проработки управляющие классы добавляются для каждой пары актер/прецедент. Такие классы определяют поток событий в прецедентах.

Вопрос использования управляющих классов очень субъективный. Многие авторы утверждают, что их применение приводит к отделению данных от поведения. Это может случиться, если управляющие классы выбраны неаккуратно. Если управляющий класс реализует что-то большее, чем последовательное действие, то он делает слишком много. Например: в системе регистрации учебных курсов студент выбирает курс, и если курс доступен, студента на него записывают.

Кто должен знать, как прикрепить студента,- управляющий класс или класс, представляющий курс занятий? Правильный ответ – класс, представляющий курс занятий. Управляющий класс знает лишь, когда студент должен быть прикреплен. «Плохой» управляющий класс знает не только когда, но и как прикрепить студента.

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

Этапы создания стереотипов для классов в программе Rational Rose:

1. Щелкните правой кнопкой мыши по имени класса в списке браузера.

2. В появившемся контекстно – зависимом меню выберете команду Open Specification (Открыть параметры).

3. Щелкните по вкладке General(Общие).

4. В открывающемся списке Stereotype (Стереотип) выберете нужный стереотип. Чтобы создать новый стереотип, введите его имя в поле открывающегося списка Stereotype.

5. Щелкните по кнопке ОК, чтобы закрыть диалоговое окно настройки параметров класса.

Рис.5 Установка стереотипа класса Студент

Документирование классов

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

Информация, необходимая для регистрации студента и оплаты обучения. Студент- это человек, обучающийся в университете.

А вот пример неправильного описания:

Имя, адрес и телефон студента.

Оно раскрывает только структуру класса, которую можно увидеть, посмотрев на список атрибутов, и не поясняет, для чего нужен данный класс.

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

• Можно определить имя и дать краткое, четкое описание- хороший класс-кандидат;
• Можно определить имя и выбрать описание, похожее на описание другого класса,-объединить классы;
• Можно определить имя, но потребуется целая книга, чтобы описать назначение класса, - разделить класс;
• Нельзя определить имя и дать описание - требуется дополнительный анализ для выделения правильных абстракций.

Чтобы описать классы в программе Rational Rose:

1. Выберете класс в списке браузера.
2. Установите курсор в окне описания и введите описание класса.

Описание класса представлено на рис.6.

Рис.6. Описание классов.

Пакеты

Если в системе существует много классов, управлять ими достаточно легко. Многие системы состоят из большого количества классов, поэтому необходимы пакеты.

Пакет(package) в логическом представлении модели- это набор классов и других связанных пакетов. Путем объединения классов в пакеты мы можем получить представление модели на более высоком уровне. Изучая содержимое пакета, мы, наоборот, получаем более детальное представление.

Каждый пакет содержит интерфейс, реализуемый набором его общедоступных классов (public classes), то есть тех, с которыми могут общаться классы из других пакетов. Остальные классы пакета- это классы реализации (implementation classes), которые не взаимодействуют с классами в других пакетах.

В сложной системе для облегчения восприятия пакеты могут быть

созданы на этапе проработки. В более простой системе классы,

выделенные на этапе анализа, могут быть сгруппированы в

один пакет, представляющий саму систему.