Бертран Мейер - Основы объектно-ориентированного программирования
Ключевые вопросы
Все описанные выше факторы важны. Но при современном состоянии индустрии ПО четыре фактора имеют особую важность:
[x]. Корректность и устойчивость: все еще слишком трудно создавать ПО без ошибок (bugs), и слишком сложно исправлять ошибки, когда они появляются. Разновидности технических приемов для улучшения корректности и устойчивости одни и те же: более систематические подходы к построению ПО; более формальные спецификации; встроенный контроль в течение всего процесса построения ПО (не просто испытания и отладка после создания); более совершенные языковые механизмы, такие как статическая типизация, утверждения, автоматическое управление памятью и упорядоченное управление исключительными ситуациями, обеспечение возможности разработчикам устанавливать требования корректности и устойчивости в сочетании с возможностью инструментов обнаруживать случаи несостоятельности до того, как они приведут к ошибкам. Близость вопросов корректности и устойчивости делает удобным введение общего термина для обозначения обоих факторов - надежность (reliability) .
[x]. Расширяемость и повторное использование: ПО должно быть легко изменяемым; компоненты создаваемого ПО должны быть широко применимы, и должен существовать больший перечень общецелевых компонентов, которые можно повторно использовать при разработке новой системы. Здесь также одни и те же идеи полезны для улучшения обоих качеств: любая идея, помогающая производить продукт с более децентрализованной архитектурой, компоненты которой автономны и взаимодействуют только через ограниченные и ясно определенные каналы, будет полезной. Термин модульность (modularity) включает повторное использование и расширяемость.
ОО-метод, детально изучаемый в последующих лекциях, может значительно улучшить четыре основных фактора качества, вот почему он так привлекателен. Он также может внести значительный вклад в другие аспекты, в частности:
[x]. Совместимость: метод обеспечивает общий стиль проектирования и стандартизацию интерфейсов модулей и систем, что помогает совместно работать разным системам.
[x]. Переносимость: уделяя особое внимание абстракции и скрытию информации, объектная технология способствует тому, что проектировщики начинают отделять спецификацию от особенностей реализации, что и облегчает перенос. Полиморфизм и динамическое связывание делает возможным создание системы, автоматически адаптируемой к аппаратно-программному механизму, например, различным системам окон или различным системам управления базами данных.
[x]. Простота использования: вклад ОО-инструментов в современные интерактивные системы, и особенно их пользовательские интерфейсы, так хорошо известен, что иногда он затмевает другие аспекты (люди, создающие рекламу - не единственные, кто называет "объектно-ориентированной" любую систему, использующую значки, окна и ввод с помощью мыши).
[x]. Эффективность: как отмечалось выше, повторное использование компонентов профессионального качества часто может значительно улучшить производительность.
[x]. Своевременность, экономичность и функциональность: ОО-техника дает возможность тем, кто ее освоил, производить ПО быстрее и по более низкой стоимости; она облегчает добавление функций и даже сама может предложить новые функции.
Несмотря на все эти успехи, мы должны помнить, что ОО-метод - это не панацея, и что многие обычные вопросы проектирования ПО остаются нерешенными. Помощь в решении проблемы - это не то же самое, что ее решение.
О программном сопровождении
Приведенный список факторов не включил обычно приводимое качество: возможность сопровождения (maintainability). Чтобы понять почему, мы должны поближе взглянуть на лежащее в его основе понятие: сопровождение (maintenance) . Сопровождение начинается с момента поставки ПО пользователям.
Обсуждения методологии создания ПО обычно сосредоточивается на фазе разработки; то же находим и во вводных курсах по программированию. Но широко известно, что 70% стоимости ПО приходится на его сопровождение. Никакое изучение качества ПО не может быть удовлетворительным, если оно игнорирует этот аспект.
Что означает сопровождение для ПО? Если на минуту задуматься, то становится ясно, что этот термин употребляется неправильно: ПО не изнашивается от постоянного использования, и ему не требуется такое "обслуживание", как автомобилю или телевизору. Специалисты по программным продуктам используют это слово для описания уважаемых (noble) и не очень уважаемых функций сопровождения. К уважаемой, достойной части работы можно отнести модификацию системы. Поскольку спецификации компьютерных систем меняются, отражая изменения во внешнем мире, должны меняться и сами системы. Наименее уважаемая часть - это запоздалая отладка: удаление ошибок, которых не должно было быть в начале.
Рис. 1.5. Распределение расходов на сопровождение. Источник: [Лиенц, 1980]
Вышеприведенная диаграмма, взятая из ключевого исследования Лиенца и Свонсона, проливает некоторый свет на то, что на самом деле значит включающий разнообразные понятия термин "сопровождение". Исследование рассмотрело 487 систем, разрабатывающих ПО разного рода; возможно, оно немного устарело, но более поздние публикации подтверждают те же общие результаты. Оно показывает долю стоимости, приходящуюся на каждый идентифицированный авторами вид работ по сопровождению.
Более двух пятых стоимости идет на расширения и модификации, требующиеся пользователям. Это то, что мы выше назвали уважаемой частью сопровождения, без которой работающая система обойтись не может. Неразрешенный вопрос в том, какую долю общей работы промышленность может сэкономить, если с самого начала она будет строить ПО, уделяя больше внимание расширяемости. Мы можем законно ожидать, что объектная технология здесь будет полезна.
Второй значимый фактор в распределении стоимости сопровождения особенно интересен: изменение формата данных. При изменении физической структуры файлов и других элементов данных приходится адаптировать программы. Например, американская почтовая служба несколько лет назад ввела почтовый код "5+4", использующий девять цифр вместо пяти. Пришлось переписывать многочисленные программы, имеющие дело с адресами и "знающих", что почтовый код состоит точно из пяти цифр. По сообщениям прессы, затраты оценивались в сотни миллионов долларов.
Другая известная проблема - Millenium - переход компьютеров на даты нового тысячелетия.
Вопрос не в том, что некоторая часть программы знает физическую структуру данных: это неизбежно, поскольку доступ к данным необходим. Но при традиционных методах построения это знание распространяется слишком на многие части системы, приводя к неоправданно большим программным изменениям при изменении физической структуры. Другими словами, если почтовые коды изменяются с пяти до девяти цифр или даты требуют еще одной цифры, то резонно ожидать, что программа, манипулирующая кодами и датами, будет требовать адаптации. Недопустимо лишь, чтобы изменения в программе были несоизмеримы по сравнению с концептуальным размером изменения спецификации.
Теория абстрактных типов данных даст ключ к этой проблеме (Лекция 6 подробно описывает абстрактные типы данных), позволяя программам иметь доступ к данным с помощью внешних свойств, а не физической реализации.
Следующие пункты в списке Лиенца и Свонсона также интересны, но не так непосредственно связаны с темами этой книги. Аварийная отладка (производимая в спешке, когда пользователь сообщает, что программа не дает ожидаемых результатов или ведет себя катастрофически) стoит больше, чем обычные плановые исправления. Это так не только потому, что она производится в короткие сроки, но и потому, что она прерывает плановый процесс выпуска новых (безошибочных) вариантов и может дать новые ошибки.
Еще одно интересное наблюдение в распределении затрат по видам деятельности - это сравнительно низкая доля (5,5%) стоимости документации. Помните, что это - стоимость задач, решаемых в период эксплуатации. Наблюдение здесь - или скорее, догадка, при отсутствии более точных данных - таково: проект должен либо заботиться о том, чтобы создание документации стало частью разработки, либо совсем не делать этого. Мы научимся использовать стиль построения, в котором большая часть документации действительно встроена в ПО, и есть специальные инструменты для ее извлечения.
Последние два вида работ дают очень малую долю:
[x]. Первый - это улучшение эффективности; похоже, предполагается, что когда система работает, менеджеры проекта и программисты неохотно прерывают ее работу с целью улучшения производительности, предпочитая не трогать довольно хорошую систему. (При рассмотрении принципа "сначала сделай ее хорошо, а потом сделай ее быстрой" многие проекты, возможно, вполне довольствуются первым шагом.)
