Б. Страуструп - Язык программирования С++ (1119446), страница 81

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

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

Нужно не бросаться сразупечатать текст, а поискать статьи на сходные темы, вдруг найдется такая, которая может послужитьотправной точкой. Если ею окажется моя собственная статья, то можно будет использовать даже кускииз нее, изменяя по мере надобности другие части, и вводить новую информацию только там, гдетребует логика предмета. Таким образом, исходя из первого издания, написана эта книга. Предельный295Бьерн Страуструп.Язык программирования С++случай такого подхода - это написание открытки-формуляра, где просто нужно указать имя и, возможно,добавить пару строк для придания "личного" отношения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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