Файл: ТРПО-лекции.pdf

4.2.2. Пример (продолжение)

Для системы РЕГИСТРАТОР рассматривается прецедент Регистрация информации о преподавателях (рис. 4-1).

В качестве управляющего класса определѐн класс Управление.

После идентификации программных сущностей диаграмма классов примет вид, который показан на рис. 4-5.

Рис. 4-5. Диаграмма классов

4.2.3. Определение атрибутов

Атрибут – это именованное свойство объекта.

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

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

подаватель:

Уровень концепции. Наличие атрибута указывает на то, что преподаватели обладают именами.

Уровень спецификации. Атрибут указывает на то, что объект преподаватель может сообщить своѐ имя и обладает некоторым механизмом определения имени.

Уровень реализации на языке C++. Объект преподаватель содержит элемент дан-

ных имя со значением, соответствующим имени преподавателя.

При определении атрибутов важно учитывать следующие обстоятельства:

−Атрибут должен отражать существенное и важное свойство объекта.

−Каждый атрибут должен иметь подходящее название.

−Атрибут не должен быть объектом.

−Атрибут не должен быть атрибутом реализации (например, указателем).

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения 62

− Атрибут не обязательно указывает на свойство объекта реального мира (например, статус).

После идентификации кандидатов в атрибуты необходимо устранить ненужные и неправильные атрибуты по следующим критериям:

1.Если сущность более важна, чем значение, то это объект, а не атрибут. Например, если система занимается составлением расписания курсов для Вуза, то лекции, практические занятия, семинары, экзамены – это отдельные объекты, а не атрибуты класса Расписание.

2.Если значение атрибута зависит от специфического контекста, то лучше заявить атрибут как роль. Например, декан.

3.Идентификаторы реализации не должны быть заявлены как атрибуты. Например, если для какого-либо запроса нужно определить промежуточное значение, то переменную, которая определяет это значение, не следует объявлять в качестве атрибута.

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

ассоциация читает.

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

6.Атрибут, который не связан со всеми другими атрибутами, может указывать на класс, который должен быть разбит на два разных класса. Например, имя, адрес,

год рождения, номер кредитной карточки.

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

4.2.4. Пример (продолжение)

На рис. 4-6 показаны атрибуты классов для системы РЕГИСТРАТОР.

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Рис. 4-6. Диаграмма классов с

атрибутами

4.2.5. Упрощение классов путѐм обобщения

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

4.2.6. Пример (продолжение)

Для системы РЕГИСТРАТОР атрибут фио является общим для классов Преподаватели и Студенты. Определяется суперкласс Персона с атрибутом фио, который будет общим для подклассов. В каждом из подклассов, которые являются специализированными версиями суперкласса, определены уточняющие атрибуты.

Диаграмма классов приобретает вид, показанный на рис 4-7.

Рис. 4-7. Диаграмма классов с

обобщением

4.2.7. Определение операций

Одной из главных задач логического проектирования является задача назначение обязанностей классов. Определение операций – это и есть назначение обязанностей.

Операции – это некоторые сервисы (действия), которые один класс предоставляет другому, либо самому себе.

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения 64

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

Можно выделить несколько общих соображений определения операций:

1.Следует определить минимальный набор операций, который требует представляющая класс концепция. Как правило, эти операции при реализации становятся методами (функциями-членами).

2.Добавить к этому набору операции, которые необходимы для удобства.

3.Подумать об общности в именовании и функциональности для всех классов.

4.Не думать о реализации операций, а только о спецификации.

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

Стереотипные операции (create and initialize, delete, get…, set…, add…, remove…),

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

4.2.8. Пример (продолжение)

Для прецедента Регистрация преподавателей системы РЕГИСТРАТОР определены операции, которые показаны на диаграмме классов (рис. 4-8).

Рис. 4-8. Диаграмма классов с операциями для прецедента Регистрация преподавателей

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения 65

Для прецедента Регистрация курсов дополнительно определены операции, которые показаны на диаграмме классов (рис. 4-9).

Рис. 4-9. Диаграмма классов с операциями для прецедента Регистрация курсов

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

Окончательная диаграмма классов для прецедента Регистрация информации о преподавателях системы РЕГИСТРАТОР представлена на рис. 4-10.

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Рис. 4-10. Диаграмма классов для прецедента Регистрация информации о преподавателях

4.2.10. Рабочий поток проектирования в RUP

Проектирование – основная деятельность для моделирования реализации прецедентов на базе модели анализа. Анализ и проектирование в некоторой степени могут происходить параллельно. Следует поддерживать две отдельные модели (аналити-

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения 67

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

Рабочий поток проектирования показан на рис. 4-11.

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

Процесс проектирования – это итеративный процесс. Проектная модель включает:

− Проектные подсистемы. − Проектные классы.

− Интерфейсы.

− Проектные реализации прецедентов.

− Диаграмму развѐртывания в первом приближении. Трассировка существует:

− Между проектной и аналитической моделями.

− Между одной или более проектными подсистемами и пакетом анализа.

4.3. Концепции объектной методологии

К основным концепциям методологии относятся: концептуальная целостность, гарантированный результат, самодостаточность, иерархия, согласованность, инкапсуляция, наследование и полиморфизм.

4.3.1. Концептуальная целостность – Conceptual Integrity

Объектно-ориентированная система представляет собой сеть сотрудничающих агентов-объектов. Причѐм, на всех этапах разработки: анализа, проектирования и

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения 68

реализации. Концептуальная целостность обеспечивается наличием только двух типов отношений между классами: Поставщик – Клиент и Родитель – Наследник.

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

Наличие только двух типов отношений делает возможным повторное использование образцов проверенных временем классов, о которых всѐ уже точно известно. Следование образцам обеспечит успех.

4.3.2. Гарантированный результат – Contract

Наиболее уязвимый аспект архитектуры ПС – отношения между клиентами и поставщиками.

Контракты2 – это чѐткое выражение отношений между объектами-клиентами и объектами-поставщиками.

Контракты позволяют:

−Инициировать взаимодействие в нужный момент.

−Организовать взаимодействие в нужном контексте.

−Гарантированно получить нужный результат.

Контракты должны ясно выражать ожидания и обещания каждой стороны. Для клиента формулируются предусловия, для поставщика – постусловия. Если клиент гарантирует удовлетворение предусловий, тогда поставщик гарантирует выполнение постусловия.

Предусловия – это такие условия, которые должны быть выполнены прежде, чем поставщик начнѐт свою работу для клиента.

Постусловия – это такие условия, которые должны быть выполнены после завершения работы поставщика.

4.3.3. Самодостаточность – Selfishness

Самодостаточность (selfishness – эгоизм, себялюбие) – это наиболее известная, но наименее понимаемая часть объектной методологии. Обычно используются более привычный термин – сокрытие информации. Принцип эгоистической самодоста-

точности гласит: “Меня не интересует, кто ты; просто скажи мне, что ты мо-

жешь сделать для меня”. Объект-поставщик раскрывает клиентам только часть своих свойств, причѐм в идеале именно в том объѐме, который необходим.

Большинство программистов привыкло считать, что этот механизм введѐн для защиты поставщика от несанкционированного клиентского доступа. На самом деле

2 Подробнее о контрактах можно прочитать в файле f:\HELP\Технология программиро-

вания\Контрактное программирование.doc

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011