Майлингова О.Л., Манжелей С.Г., Соловская Л.Б. - Прототипирование программ на языке Scheme (1108536), страница 3
Текст из файла (страница 3)
Поэтому нет необходимости детальнопроектировать до начала этапа кодирования все модули. Таким образом,ядро системы может функционировать до того, как некоторые из модулейдетально спроектированы.Сравнение моделей, использующих прототипированиеБыстрое прототипированиеИнкрементное прототипированиеПодход к «быстрому и грязному» Реализация части системы, не всесозданию частичной реализации требования к которой точно известны.системы на этапе определения Для уточнения требуется эксперименттребований.с работоспособной версией системы.Начинаем с того, что требует Начинаем с того, что не требуетуточнения.уточнения.Используется для уточнения Используетсядляуточнениятребований пользователя.непонятых требований.Приводит к полным и Приводит к раннему появлениюправильнымспецификациям первой версии системы.требований,хотяфазаопределения требований12занимает в результате большевремени,чемразработкаформальных спецификаций.Качествуразработкинеуделяется особое внимание, таккак система экспериментальная.Строитсямодельсистемы,демонстрирующаяпониманиетребованийзаказчикаисполнителемдлячеткогоопределениятребованийксистеме.
Как правило, строитсянесколько прототипов системы.Основноевнимание уделяетсякачеству разработки. Поэтому нестоль важна скорость разработки.Происходитнаращиваниеработающей части системы новымикомпонентами. В результате прототипстановится системой. В данномподходе существенноезначениеимеетпроцессразработкиархитектуры системы.На Рис. 6, Рис. 7 отображено сравнение моделей, использующихпрототипирование («жирная линия»), с традиционной модельюразработки. Использование быстрого прототипирования на ранних этапахразработки программных продуктов повышает степень пониманияреальных потребностей пользователя в момент времени to.Рис.
6. Быстрое прототипированиеи традиционная разработкаРис. 7. Инкрементноепрототипирование итрадиционная разработкаТаким образом, сама модель разработки не сильно изменяется, однакоиспользование прототипа влияет на конечный результат разработки. НаРис 6 показано, что в момент времени t1 функциональные возможностисистемы больше, чем при ее разработке в соответствии с водопадной13моделью.
На Рис. 6 показан также сам прототип как вертикальная линия,отображающая ограниченные возможности системы, вскоре после времениto. Нет оснований предполагать, что время, в которое система может бытьиспользована без внесения изменений (t3 - t1), отличается от временииспользования системы при традиционной разработке.При инкрементном прототипировании, первый прототип появляется рано идемонстрирует реализацию тех требований, которые, предположительно,были поняты, а также поведение системы в целом.
Каждая следующаяверсия прототипа охватывает новую область требований пользователя иуточняет предыдущие возможности. В результате решение приближается креализации потребностей пользователя. Конечно, через некоторое времятакже требуется глобальная реконструкция системы. При описываемомподходе хорошо спроектированная система позволяет заменять одникомпоненты другими и равномерно приближаться к требуемомурезультату.Одним из существенных требований к прототипу является минимальноевремя его реализации. Как разработать прототип быстрее, чем систему?Рассмотрим модели разработки, основанные на повторном использованиипрограммных компонент и использовании автоматической генерации кода(прототипа) на основе спецификаций требований.Рис.
8. Повторное использованиекомпонент14Рис. 9. Автоматическая генерациякодаПовторное использование компонентПрототипирование снижает стоимость разработки путем частичныхреализаций системы. Повторное использование программных компонентявляется подходом, при котором стоимость разработки системы снижаетсяза счет использования существующих проектных решений илисуществующего кода в новых программных продуктах. Разработчиковпрограммного обеспечения часто обвиняют в постоянном «изобретенииколеса». Это происходит отчасти потому, что существует немногоинструментов, позволяющих применять накопленный опыт.
Требуютсятехнические приемы и инструменты для создания, хранения,каталогизации и поиска компонент, пригодных для многократногоиспользования. Результатом будет сокращение времени разработки новыхсистем и увеличение их надежности. На Рис. 8 показано, как повторноеиспользование компонент («жирная линия») влияет на время разработкисистемы, хотя сама модель может оставаться, по сути, традиционной.Автоматическая генерация кодаТермин автоматическая генерация кода используется для описанияпреобразования требований или спецификации проекта в выполняемыйкод. Процесс преобразования может быть алгоритмическим илиоснованным на технике баз знаний.
Разные поколения разработчиковпрограммного обеспечения используют этот термин для описанияпреобразования с языка более высокого уровня в используемый языкпрограммирования. Этим термином обозначали «автоматическую»трансляцию языка ассемблера в машинный код (ассемблирование),перевод текста на языке программирования в машинный код(компиляцию). В настоящее время этот термин употребляется дляописания преобразования с языка спецификаций в языкпрограммирования.При реализации такого подхода требования записываются на некоторомформальном языке спецификации, например SDL, и система строитсяавтоматически.
В результате время разработки системы существенносокращается, также как и стоимость разработки. Эффект автоматическогопостроения системы показан на Рис. 9 («жирная линия»). В идеальнойситуации, при каждом внесении изменений в спецификацию требованийновая система (или прототип) генерируется автоматически, ифункциональные возможности системы постоянно соответствуюттребованиям.15Спиральная модельИспользование прототипирования приводит к меньшему объемукодирования, более простому использованию. Традиционный подходхарактеризуется лучшей согласованностью, большей функциональностью,более высокой степенью переносимости и более простой интеграцией Изэтого следует, что требуется смешанный подход, позволяющий понекоторому подмножеству требований быстро разрабатывать прототипы,на основе которых уточняются основные требования.Спир альная мо дель была разработана на осно ве опытаусовершенствования водопадной модели.
Она рассматриваетсуществующие модели разработки как частные случаи, и описываетвозможности комбинирования существующих приемов (Рис. 10). Радиуспредставляет собой общую стоимость разработки в текущий моментвремени, угол отображает прогресс при выполнении витка спирали.Модель предполагает, что на каждом витке выполняется та жепоследовательность шагов для каждого фрагмента продукта и для любогоуровня его разработки. Типичный цикл состоит из следующих шагов:Рис. 10. Спиральная модель• определение целей разработки, средств реализации, ограничений,• оценка альтернатив с учетом целей и ограничений;• исследования степени риска (прототипирование, моделирование, опроспользователей и т.п.),16• на основе оценки риска определяется следующий шаг разработки, болеедетальное прототипирование, или переход к следующему шагуразработки в соответствии с водопадной моделью.Спиральная модель представляет собой обобщение подходов к разработкепрограммных систем, основанное на разработке спецификаций,использовании прототипирования, построении моделей, использованииавтоматической генерации системы.Использование прототипов при разработке программных систем позволяетобнаруживать ошибки в требованиях к системе на более ранних стадияхразработки.
Заметим, что цена ошибки растет со временем ееобнаружения. Заметим также, что в моделях, не использующихпрототипирование, действующая система появляется на достаточнопоздних этапах жизненного цикла. Поэтому, при наличии в нейсущественных недостатков, такая система обречена стать, по сути,прототипом, только очень дорогим.Язык Scheme (диалект языка программирования Lisp) отличаетсяпростотой синтаксиса и обладает богатыми встроенными возможностямиманипулирования сложными структурами данных, такими как списки,векторы, деревья, что позволяет минимизировать затраты на созданиепрограмм.
Легко расширяемый язык, Scheme дает возможность быстросоздавать работающие прототипы программ, позволяющие оценитьстепень удачности того или иного решения. Будучи интерпретируемымязыком, Scheme позволяет работать со структурами данных винтерактивном режиме и как следствие, исключительно удобен дляэкспериментов со сложными структурами данных и проверке новыхподходов к их анализу. Поэтому, этот язык может быть использован дляразработки прототипов систем.17Глава 2Разработка программ на SchemeДля быстрой разработки прототипов программ необходим инструмент,гибкий и удобный в использовании, например, язык Scheme.
Scheme - этоодин из диалектов функционального языка программирования Lisp,предложенного Джоном Маккарти в конце 50-х годов. По давностииспользования Lisp является вторым языком программирования (старше только Фортран).Долгое время язык Lisp развивался неформально, живо реагируя натребования пользователей. Такое демократичное развитие в сочетании сгибкостью и элегантностью начальной концепции позволило языку Lispадаптироваться к современным тенденциям проектирования программ. Внастоящее время Lisp представляет собой семейство диалектов,объединенных общей концепцией и называемых Lisp-культурой. Изсуществующих диалектов, Scheme наиболее близок к классическому языкуLisp Он был разработан в 1975 в Массачусетском УниверситетеДжеральдом Суссманом (Guy Lewis Steele Jr.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
