Подход снизу вверх

Повторное использование

КОС (CRC) карты

Для полноты картины упомянем идею, рассматриваемую иногда как метод нахождения классов. Карты КОС (Класс, Ответственность, Сотрудничество) или CRC (Class, Responsibility, Collaboration) являются бумажными карточками, используемыми разработчиками при обсуждении потенциальных классов, в терминах их ответственностей и взаимодействия. Идея проста, отличается дешевизной - набор карточек дешевле рабочей станции с CASE инструментарием. Но его технический вклад в процесс проектирования неясен.

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

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

Довольно часто, когда мы говорим о нахождении классов, подразумевается их изобретение (devising). В объектной технологии с ростом качества библиотек и осознания идей повторного использования приобретает смысл именно поиск (finding) классов.

Сказка о поиске классов

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

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

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

Наконец, в один из темных зимних дней, когда снег покрыл все окружающие горные вершины, он вошел в комнату Мастера. С бьющимся сердцем, пересохшим от волнения голосом он задал свой сакраментальный вопрос: "Мастер, как мне найти классы?"

Мудрец склонил свою голову и ответил медленно и спокойно: "Возвращайся назад, откуда пришел. Классы уже найдены".

Оглушенный, он и не заметил, как слуги Мастера выводили его прочь. "Мастер", - теперь он почти кричал, - "пожалуйста, еще только один вопрос. Как называется эта история?" Старый Учитель покачал головой: "Разве ты еще не понял? Это сказка о повторном использовании".

Метод получения классов

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

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

Прежде всего начнем с источников классов.

Таблица 4.1. Источники возможных классов
Источник идей	Что ищется
Существующие библиотеки	· Классы, отвечающие потребностям приложения. · Классы, описывающие концепции, релевантные приложению.
Документ требований	· Часто встречающиеся термины. · Термины, заданные явными определениями. · Термины, не определенные точно, но считающиеся само собой разумеющимися. · (Грамматические категории следует игнорировать.)
Обсуждения с заказчиками и будущими пользователями	· Важные абстракции проблемной области. · Специфический жаргон проблемной области. · Помнить, что классы, приходящие из "внешнего мира", могут описывать как материальные, так иконцептуальные объекты.
Документация (руководства пользователей) для других систем в той же проблемной области, например от конкурентов	· Важные абстракции проблемной области. · Специфический жаргон проблемной области. · Полезные абстракции проектирования.
Не ОО-системы и их описания	· Элементы данных, передаваемые в виде аргументов компонентам ПО. · Разделяемые данные (Common блоки FORTRAN). · Важные файлы. · Секции данных (COBOL). · Типы записей (Pascal, C, C++). · Сущности при ER-моделировании.
Обсуждения с опытными проектировщиками	· Классы проектирования, успешно используемые в предыдущих разработках.
Литература по алгоритмам и структурам данных	· Известные структуры данных, поддержанные эффективными алгоритмами.
Литература по ОО-проектированию	· Применимые образцы проектирования.

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

Таблица 4.2. Причины отбраковки кандидатов в классы
Сигналы опасности	Причина подозрительности
Класс с отглагольным именем (произведенным от глагола, инфинитив или императив)	Может быть простой подпрограммой, а не классом
Полностью эффективный класс с одной экспортируемой подпрограммой	Может быть простой подпрограммой, а не классом.
Класс, описанный как "выполняющий нечто"	Может не быть подходящей абстракцией.
Класс без подпрограмм	Может быть важной частью информации, но не АТД. Может быть АТД, для которого просто забыли указать операции.
Класс, введенный без компонентов или с небольшим их числом (но наследующий компоненты своих родителей)	Может быть результатом "таксомании".
Класс, покрывающий несколько абстракций	Должен быть разделен на несколько классов, по одному на каждую абстракцию.

Дата добавления: 2014-12-07