straustrup2 (852740), страница 78

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 78)

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

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

То, что было позволено Шекспиру, подходит и для нас.Некоторые обозначают использование моделей в процессе проектирования как "проектированиеповторного использования".11.3.4 Эксперимент и анализВ начале честолюбивого проекта нам неизвестен лучший способ построения системы. Часто бываеттак, что мы даже не знаем точно, что должна делать система, поскольку конкретные факты прояснятсятолько в процессе построения, тестирования и эксплуатации системы.

Как задолго до созданиязаконченной системы получить сведения, необходимые для понимания того, какие решения припроектировании окажутся существенными, и к каким последствиям они приведут?Нужно проводить эксперименты. Конечно, нужен анализ проекта и его реализации, как толькопоявляется пища для него. Преимущественно обсуждение вертится вокруг альтернатив припроектировании и реализации. За исключением редких случаев проектирование есть социальнаяактивность, которая ведет по пути презентации и обсуждений. Часто самым важным средствомпроектирования оказывается простая грифельная доска; без нее идеи проекта, находящиеся взародыше, не могут развиться и стать общим достоянием в среде разработчиков и программистов.Похоже, что самый популярный способ проведения эксперимента сводится к построению прототипа, т.е.уменьшенной версии системы.

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

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

В этом случае на прототип тратятся время и энергия, которые лучше приберечь для296Бьерн Страуструп.Язык программирования С++реальной системы. Для разработчиков и менеджеров есть искушение переделать прототип в конечныйпрограммный продукт, а "искусство настройки системы" отложить до выпуска следующей версии.

Еслиидти таким путем, то прототипы отрицают все основы проектирования.Сходная проблема возникает, если исследователи привязываются к тем средствам, которые онисоздали при построении прототипа, и забывают, что они могут оказаться непригодными для рабочейсистемы, и что свобода от ограничений и формальностей, к которой они привыкли, работая внебольшой группе, может оказаться невозможной в большом коллективе, бьющимся над устранениемдлинной цепи препятствий.И в то же время создание прототипов может сыграть важную роль. Рассмотрим, например,проектирование пользовательского интерфейса. Для этой задачи внутренняя структура той частисистемы, которая прямо не общается с пользователем, обычно не важна, и использование прототипов это единственный способ узнать, какова будет реакция пользователя при работе с системой.

Другимпримером служат прототипы, прямо предназначенные для изучения внутренней структуры системы.Здесь уже интерфейс с пользователем может быть примитивным, возможна работа с модельюпользователей.Использование прототипов - это способ экспериментирования. Ожидаемый результат - это болееглубокое понимание целей, а не сам прототип. Возможно, сущность прототипа заключается в том, чтоон является настолько неполным, что может служить лишь средством для эксперимента, и его нельзяпревратить в конечный продукт без больших затрат на перепроектирование и на другую реализацию.Оставляя прототип "неполным", мы тем самым переключаем внимание на эксперимент и уменьшаемопасность превращения прототипа в законченный продукт. Это также почти избавляет от искушениявзять за основу проекта системы проект прототипа, при этом забывая или игнорируя те ограничения,которые внутренне присущи прототипу.

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

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

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

Например, может оказаться полезным изучение различных зависимостей между классами(см.$$ 12.2), не следует забывать и о таких традиционных вспомогательных средствах реализации, какграф вызовов функций, оценка производительности и т.п.Заметим, что спецификация (результат анализа системы) и проект могут содержать ошибки, как иреализация, и возможно, они даже больше подвержены ошибкам, т.к. являются менее точными, немогут быть проверены на практике и обычно не окружены такими развитыми средствами, как те, чтослужат для анализа и проверки реализации.

Введение большей формализации в язык или запись, спомощью которой изложен проект, в какой-то степени облегчает использования этих средств дляпроектирования. Но, как сказано в $$12.1.1, это нельзя делать за счет ухудшения языка, используемогодля реализации. К тому же формальная запись может сама стать источником трудностей и проблем.Это происходит, когда выбранная степень формализации плохо подходит для конкретных задач, когдастрогость формализации превосходит математическую основу системы и квалификацию разработчиков297Бьерн Страуструп.Язык программирования С++и программистов, и когда формальное описание системы начинает расходиться с реальной системой,для которой оно предназначалось.Заключение о необходимости опыта и о том, что проектирование неизбежно сопровождается ошибкамии плохо поддержано программными средствами, служит основным доводом в пользу итеративноймодели проектирования и реализации.

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

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

Характеристики

Список файлов книги