У3.6 Управление конфигурацией и наследование
Это упражнение предполагает знание механизма наследования, описанного далее в этом курсе. Его не стоит пока что выполнять, если вы дошли до этой лекции, изучая курс последовательно.
Обсуждение принципа Открыт-Закрыт показало, что отсутствие наследования в не ОО-методах вызывает чрезмерные расходы на разработку средств управления конфигурацией, поскольку желание избежать повторного открытия закрытых модулей может приводить к созданию слишком большого числа модульных вариантов. Выясните, какая роль остается за средствами управления конфигурацией в ОО- среде, где имеется механизм наследования, и вообще - как использование объектной технологии влияет на управление конфигурацией.
Если вы знакомы с конкретными средствами управления конфигурацией, выясните, как они взаимодействуют с механизмом наследования и другими принципами ОО-разработки ПО.
Лекция 4. Подходы к повторному использованию
В этой лекции будут рассмотрены некоторые из проблем, направленных на широкомасштабное внедрение повторного использования программных компонентов.
Цели повторного использования
'Последуйте примеру проектирования компьютерных технических средств! Это неверно, что каждая новая программная разработка должна начинаться с чистого листа. Должны существовать каталоги программных модулей, такие же, как каталоги сверхбольших интегральных схем СБИС (VLSI devices). Создавая новую систему, мы должны заказывать компоненты из этих каталогов и собирать систему из них, а не изобретать каждый раз заново колесо. Создавая меньше новых программ, мы, возможно, найдем лучшее применение своим усилиям. И, может быть, исчезнут некоторые из трудностей, на которые все жалуются - большие затраты, недостаточная надежность. Разве не так?'
Вы, вероятно, слышали или даже сами высказывали такого рода замечания. Еще в 1968 г. на известной конференции НАТО по проблемам разработки ПО, Дуг Мак-Илрой (Doug McIlroy) пропагандировал идею 'серийного производства компонентов ПО'. Таким образом, мечта о возможности повторного использования программных компонентов не является новой. Было бы нелепо отрицать, что повторное использование имеет место в программировании. Фактически одним из наиболее впечатляющих результатов развития индустрии ПО с тех пор, как в 1988 г. появилось первое издание этой книги, явилось постепенное появление повторно используемых компонентов. Они получали все большее распространение, начиная от небольших модулей, предназначенных для работы с Visual Basic (VBX) фирмы Microsoft и OLE 2 (OCX, а сейчас ActiveX), до обширных библиотек классов, известных также как 'каркасы приложений' ('framework applications').
Еще одним замечательным достижением является развитие Интернета: пришествие общества, охваченного Сетью (wired society), облегчило или в ряде случаев устранило некоторые из логических препятствий, казавшихся почти непреодолимыми еще несколько лет назад. Но это только начало. Мы далеки от предвидения Мак-Илроя о превращении программной инженерии в отрасль промышленности, основанную на использовании программных компонентов. Однако методология конструирования ОО-ПО впервые дала возможность представить себе практическую реализацию этого предвидения. И это может принести весьма значительную пользу не только разработчикам ПО, но, что еще важнее, тем, кто нуждается в их продукции, своевременно появляющейся и высококачественной.
Прежде всего, следует понять, почему так важно улучшать возможности повторного использования ПО. Здесь незачем обращаться к доводам типа 'любовь к матери и яблочному пирогу'. Как мы увидим, наша борьба за повторное использование преследует надлежащие цели, позволит избежать миражей, и принесет хороший доход от соответствующих инвестиций.
Ожидаемые преимущества
Повторное использование может обеспечить прогресс на следующих направлениях:
[x]. Своевременность (timeliness) (в том смысле, который определен при обсуждении показателей качества: быстрота доведения проектов до завершения и продукции до рынка). При использовании уже существующих компонентов нужно меньше разрабатывать, а, следовательно, ПО создается быстрее.
[x]. Сокращение объема работ по сопровождению ПО (decreased maintenance effort) . Если кто-то разработал ПО, то он же отвечает и за его последующее развитие. Известен парадокс компетентного разработчика ПО: 'чем больше вы работаете, тем больше работы вы себе создаете'. Довольные пользователи вашей продукции начнут просить добавления новых функциональных возможностей, переноса на новые платформы. Если не надеяться 'на дядю', то единственное решение парадокса - стать некомпетентным разработчиком, - чтобы никто больше не был заинтересован в вашей продукции. В этой книге подобное решение не поощряется.
[x]. Надежность. Получая компоненты от поставщика с хорошей репутацией, вы имеете определенную гарантию, что разработчики предприняли все нужные меры, включая всестороннее тестирование и другие методы контроля качества. В большинстве случаев можно ожидать, что кто-то уже испытал эти компоненты до вас и обнаружил все возможно остававшиеся ошибки. Заметьте, вовсе не предполагается, что разработчики компонентов умнее вас. Для них создаваемые компоненты - будь то графические модули, интерфейсы баз данных, алгоритмы сортировки - это служебная обязанность, цель работы. Для вас это лишь второстепенная, рутинная работа, поскольку вашей целью является создание некоторой прикладной системы в вашей собственной области деятельности.
[x]. Эффективность. Факторы, способствующие возможности повторного использования ПО, побуждают разработчиков компонентов пользоваться наилучшими алгоритмами и структурами данных, известными в их конкретной сфере деятельности. Однако в команде, разрабатывающей большой прикладной проект, трудно ожидать наличия специалистов по каждой проблеме, затрагиваемой в этом проекте. При разработке большого проекта невозможно оптимизировать все его детали. Следует стремиться к достижению наилучших решений в своей области знаний, а в остальном использовать профессиональные разработки.
[x]. Совместимость. Если использовать хорошую современную ОО-библиотеку, то ее стиль повлияет, за счет естественного 'процесса диффузии', на стиль разработки всего ПО. Это существенно помогает повысить качество программного продукта.
[x]. Инвестирование. Создание повторно используемого ПО позволяет сберечь плоды знаний и открытий лучших разработчиков, превращая временные ресурсы в постоянные.
Многие из тех, кто признает повторное использование желательным, имеют в виду лишь первый из факторов в этом списке, - повышение производительности. Но это не всегда самый важный вклад
