Обобщение
Последний этап жизненного цикла кластера, обобщение, не имеет аналогов в традиционных подходах. Его цель - шлифовка классов для их подготовки к повторному использованию.
Включение шага обобщения немедленно вызывает критику: вместо апостериорных добавлений разве не следовало заботиться, чтобы повторное использование являлось составной частью всего процесса разработки ПО? Можно ли сделать ПО пригодным для повторного использования после его завершения? Такая критика неуместна. Априори следует исходить из того, что возможность повторного использования должна быть заложена с самого начала разработки ПО. Апостериори следует считать, что сразу же по завершению разработка не достигло уровня, пригодного для повторного использования. Эти две точки зрения являются не противоречивыми, а взаимодополняющими. Успех политики повторного использования требует наличия определенной культуры повторного использования у каждого участника, выделения достаточных ресурсов для расширения соответствующих возможностей исходных версий классов.
Невзирая на лучшие намерения программные элементы, созданные для конкретной области, не могут быть полностью готовы для повторного использования. Существуют ограничения, влияющие на проект, - давление клиентов, желающих как можно скорее получить следующую версию, конкурентов, выпускающих свои программы, акционеров, жаждущих увидеть результаты. Мы живем в условиях постоянной спешки. Но существует и внутренняя причина недоверия к возможности повторного использования. Нельзя быть уверенным в том, что продукт освобожден от всех явных и неявных связей с конкретной областью применения, корпоративной принадлежностью разработчиков, аппаратно-программной средой, пока кто-то не использует его повторно.
Присутствие шага обобщения не означает, что до последнего момента можно не думать о возможности повторном использовании. Эта возможность не появится сама собой и наличия политики повторного использования недостаточно. Даже если это образ мыслей каждого, то все равно придется уделить некоторое время классам вашего проекта для того, чтобы их можно было назвать программными компонентами.
Включение обобщающего этапа в официальную модель процесса - вопрос политики. В наши дни очень немногие представители руководства компаний станут явно выступать против повторного использования. Конечно, мой друг, мы хотим, чтобы наше ПО было готово к повторному использованию! Как отличить искренние высказывания от запудривания мозгов? Очень легко. Намерения искренни, если руководство готово в каждом проекте резервировать для обобщения дополнительные средства и время. Такое решение требует смелости, потому что не обещает непосредственных выгод, а другие срочные проекты могут немного пострадать. Но только так можно гарантировать, что в результате появятся компоненты повторного использования. Если руководство не готово выделить даже скромные ресурсы (несколько процентов сверх обычной сметы), то Вы можете слушать вежливо напыщенные речи о повторном использовании, но, по правде говоря, компания не готова к повторному использованию и не получит эту возможность.
Даже если дополнительные ресурсы предусмотрены, то только этого недостаточно. Залогом успеха служит комбинация усилий a priori и a posteriori:
|
Культура повторного использования Разрабатывайте все программное обеспечение, подразумевая его повторное использование. |
Первая часть подразумевает применение концепций повторного использования в течение всей разработки. Вторая учитывает, что для достижения желаемого результата обязательно нужно ввести этап обобщения для удаления всех следов контекстно-зависимых элементов.
Этап обобщения может содержать следующие действия:
- Абстрагирование: введение абстрактных классов там, где это необходимо.
- Факторизацию (Factoring): распознавание первоначально несвязанных классов, которые являются фактически вариантами того же самого понятия, так что для них можно ввести общего родителя.
- Добавление утверждений, особенно постусловий и инвариантов, отражающих углубленное понимание семантики класса и его особенностей.
Вероятно придется также добавить предусловие, но это скорее исправление ошибки, означающее незащищенность подпрограммы на должном уровне. - Добавление предложений rescue для обработки исключений, возможность которых первоначально игнорировалась.
- Добавление документации.
Обобщение совершенствует классы, считающиеся вполне подходящими для внутренних целей специфической системы, но требующие шлифовки, когда они становятся частью библиотеки широкого круга применений. Такие простительные в первом случае огрехи, как неполная спецификация или наличие недокументированных предположений, выходят на передний план. В этом причина повышенной трудности разработок, предусматривающих повторное использование, по отношению к обычной практике. Все становится важным, когда ПО доступно всем приложениям различного типа и всем платформам.
