ВСТУПИТЕЛЬНАЯ ЛЕКЦИЯ. ИСТОРИЯ РАЗВИТИЯ. 5 страница

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

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

Разработчики иногда подвергаются давлению менеджеров для ускорения работы над прототипом, особенно если намечается задержка в поставке окончательной версии системы. Обычно такое «ускорение» порождает ряд проблем.

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

2. Частые изменение во время разработки неизбежно приводят к тому, что прототип плохо документирован. Для разработки прототипа используется только спецификация системной архитектуры. Этого недостаточно для долговременного сопровождения системы.

3. Изменения, сделанные во время разработки прототипа могут нарушить архитектуру системы. Ее обслуживание будет сложным и дорогостоящим.

4. В процессе разработки прототипа ослабляются стандарты качества.

Чтобы быть полезными в процессе разработки требований, экспериментальные прототипы не обязательно должны выполнять роль реальных макетов систем. Бумажные формы, имитирующие пользовательские интерфейсы систем, показали свою эффективность при формировании требований пользователя, в уточнении проекта интерфейса и при создании сценариев работы конечного пользователя. Они очень дешевы в разработке и могут быть созданы за несколько дней. Расширением этой методики является макет пользовательского интерфейса «Wizard of Oz» (Волшебник страны Оз). Пользователи взаимодействуют с этим интерфейсом, но их запросы направлены к специалисту, который интерпретирует их и имитирует соответствующую реакцию.

Лекция 12. Прототипирование программных средств (продолжение)

12.1. Технологии быстрого прототипирования

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

1. Разработка с применением динамических языков высокого уровня.

2. Использование языков программирования баз данных.

3. Сборка приложений с повторным использованием компонентов.

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

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

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

12.1.1. Применение динамических языков высокого уровня

Динамические языки высокого уровня — это языки программирования, которые имеют мощные средства контроля данных во время выполнения программы. Они упрощают разработку программ, так как уменьшают число проблем, связанных с распределением памяти и управлением ею. Такие языки имеют средства, которые обычно должны быть построены из более примитивных конструкций в языках, подобных Ada или С. Примеры языков очень высокого уровня— Lisp (основанный на структурах списков), Prolog (основанный на алгебре логики) и Smalltalk (основанный на объектах).

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

Язык Java, несомненно, является основным языком разработки, имеющим корни в языке C++, но с включением многих средств языка Smalltalk наподобие платформенной независимости и автоматического управления памятью. Язык Java объединяет в себе многие преимущества языков высокого уровня, совмещая это с точностью и возможностью оптимизации выполнения, обычно предлагаемой языками третьего поколения. В языке Java много компонентов, доступных для повторного использования, все это делает его подходящим для эволюционного прототипирования.

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

1. Каков тип разрабатываемого приложения? Как показано в табл. 12.1, для каждого типа приложения можно применить несколько различных языков. Если необходим прототип приложения, которое обрабатывает данных на естественном языке, то языки Lisp или Prolog более подходят, чем Java или Smalltalk.

2. Каков тип взаимодействия с пользователем? Различные языки обеспечивают разные типы взаимодействия с пользователем. Некоторые языки, такие как Smalltalk и Java, хорошо интегрируются с Web-браузерами, в то время как язык Prolog лучше всего подходит для разработки текстовых интерфейсов.

3. Какую рабочую среду обеспечивает язык? Развитая рабочая среда поддержки языка со своими инструментальными средствами и легким доступом к повторно используемым компонентам упрощает процесс разработки прототипа.

Таблица 12.1. Языки высокого уровня, используемые при прототипировании

Динамические языки высокого уровня для создания прототипа можно использовать совместно, когда различные части прототипа программируются на разных языках. В разработке прототипа телефонной сетевой системы, где были использованы четыре различных языка: Prolog для макетирования баз данных, Awk для составления счетов, CSP для спецификации протоколов и PAISLey для имитирования работы системы.

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

12.1.2. Программирование баз данных

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

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

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

Обычно рабочая среда языков четвертого поколения включает следующие инструментальные средства (рис. 12.1).

1. В качестве языка программирования баз данных (точнее, языка запросов к базе данных) обычно используется SQL.

2. Генератор интерфейсов используется для создания форм ввода и отображения данных.

3. Электронная таблица применяется для анализа данных и выполнения различных действий над числовой информацией.

4. Генератор отчетов предназначен для создания отчетов на основе информации, содержащейся в базе данных.

Рис. 12.1. Компоненты языка четвертого поколения

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

1. Интерактивное определение форм, когда разработчик определяет поля ввода и их организацию.

2. Связывание форм, когда разработчик задает определенные данные, ввод которых вызывает отображение дальнейших форм.

3. Проверка входных данных, когда разработчик при формировании полей форм определяет дозволенный диапазон входных величин.

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

Методы, основанные на языках четвертого поколения, могут использоваться для эволюционного прототипирования или для генерирования «одноразового» прототипа системы. Структура, которую CASE-средства накладывают на разрабатываемое приложение и сопутствующую документацию, определяет более удобное сопровождение прототипов, чем предлагают прототипы, разработанные вручную. CASE-средства могут генерировать код SQL или код на языке низшего уровня, например COBOL.

Хотя языки четвертого поколения подходят для разработки прототипов, все же они имеют ряд недостатков, проявляющихся при разработке систем. Программы, написанные на языках четвертого поколения, как правило, выполняются медленнее подобных программ, написанных на обычных языках программирования, и требуют намного больше памяти. Например, проводились эксперименты, в котором перезапись на язык C++ программы, написанной на языке четвертого поколения, привела к 50%-му сокращению необходимой памяти. Программа на С также выполнялась в 10 раз быстрее, чем аналогичная программа, написанная с использованием языка четвертого поколения.

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

12.1.3. Сборка приложений с повторным использованием компонентов

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

Рис. 12.2. Сборка повторно используемых компонентов

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

Разработку прототипа с повторным использованием компонентов можно реализовать па двух уровнях.

1. Уровень приложения, когда целые прикладные системы интегрируются с прототипом так, чтобы были объединены их функциональные возможности. Например, если прототипу требуются средства обработки текста, то это можно обеспечить путем интеграции в прототип стандартной системой текстового процессора. Отметим, что приложения Microsoft Office поддерживают интеграцию со сторонними системами.

2. Уровень компонентов, когда отдельные компоненты объединяются внутри структуры, реализующей систему. Такая структура может быть создана с помощью одного из языков описания сценариев, таких, как Visual Basic, TCL/TK, Python или Perl. В качестве альтернативы могут применяться такие системы, как CORBA, DCOM wmJavaBeans.

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

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

На рис. 12.3 представлен составной документ для прототипа системы, включающего текстовые элементы, элементы электронной таблицы и звуковые файлы. Текстовые элементы обрабатываются текстовым процессором, таблицы — электронной таблицей, а звуковые файлы — аудиопроигрывателем. Когда пользователь системы обращается к объекту определенного типа, вызывается связанное с ним приложение.

Рис. 12.3. Связывание приложений посредством составного документа

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

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

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

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

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

Visual Basic— пример семейства языков, названных языками сценариев. Языки сценариев — нетипичные языки высокого уровня, разработанные для интеграции компонентов в единую систему. Ранним примером языка сценариев может служить оболочка Unix, с тех пор были созданы другие более мощные языки создания сценариев. Эти языки имеют управляющие структуры и графические инструментальные средства, радикально уменьшающие время разработки систем.

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

Рис. 12.4. Визуальное программирование с повторным использованием компонентов

12.2. Прототипирование пользовательских интерфейсов

Графические интерфейсы пользователя в настоящее время являются стандартом для интерактивных систем. Усилия, вкладываемые в определение, проектирование и реализацию такого интерфейса, составляют значительную часть стоимости разработки приложения. Разработчики не должны навязывать пользователям свою точку зрения на проектируемый интерфейс. Пользователи должны принимать активное участие в процессе проектирования интерфейса. Такой взгляд на разработку интерфейса привел к подходу, названному проектированием, ориентированным на пользователя (user-centred design), который основан на прототипировании интерфейса и участии пользователя в процессе его проектирования.

В этом аспекте прототипирование — необходимая часть процесса проектирования пользовательского интерфейса. Из-за динамической природы пользовательских интерфейсов текстовых описаний и диаграмм недостаточно для формирования требований к интерфейсу. Поэтому эволюционное прототипирование с участием конечного пользователя — единственный приемлемый способ разработки графического интерфейса для программных систем.

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

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

Из-за широких возможностей Web-браузеров и мощности языка HTML в настоящее время все больше пользовательских интерфейсов строятся как Web-ориентированные.

Для Web-ориентированных интерфейсов прототипы можно создавать с помощью стандартных редакторов Web-страниц, которые, по существу, строят пользовательские интерфейсы. Объекты на Web-странице определяются, как и связанные с ними операции, с помощью встроенных средств языка HTML (например, связывание с другой страницей) или с помощью языка Java либо сценариев.

Лекция 13.Формальные спецификации ПО

Термин «формальные методы» подразумевает ряд операций, в состав которых входят создание формальной спецификации системы, анализ и доказательство спецификации, реализация системы на основе преобразования формальной спецификации в программы и верификация программ. Все эти действия зависят от формальной спецификации программного обеспечения. Формальная спецификация — это системная спецификация, записанная на языке, словарь, синтаксис и семантика которого определены формально. Необходимость формального определения языка предполагает, что этот язык основывается на математических концепциях. Здесь используется область математики, которая называется дискретной математикой и основывается на алгебре, теории множеств и алгебре логики.

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

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

Примерами критических систем, при разработке которых успешно применялись формальные методы, являются информационные системы управления воздушным транспортом, системы сигнализации на железной дороге, бортовые системы космических кораблей и медицинские системы управления. Они также были использованы для специфицирования пакетов программных средств, части системы CICS (абонентская информационно-управляющая система) компании IBM и ядра систем, работающих в режиме реального времени. Метод «чистой комнаты» разработки ПО основывается на формальных доказательствах того, что программа соответствует своей спецификации.

13.1. Формальные спецификации в процессе разработки ПО

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

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

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

Рис. 13.1. Разработка спецификации и проектирование

Рис. 13.2. Разработка формальной спецификации

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

Разработка и анализ формальной спецификации требуют дополнительных затрат. На рис. 13.3 показана стоимость создания ПО при разработке формальной спецификации и без нее. При обычном процессе разработки ПО стоимость аттестации системы составляет около 50% всей стоимости разработки, а стоимость проектирования и реализации системы в два раза больше стоимости разработки спецификации. При использовании формальной спецификации стоимости разработки спецификации и реализации системы соизмеримы, а стоимость аттестации значительно снижается, поскольку в процессе разработки формальной спецификации обнаруживаются и устраняются недоработки в требованиях, тем самым исключается переделка системы на последних стадиях ее создания.

Рис. 13.3. Стоимость разработки ПО с формальной

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

1. Алгебраический подход, при котором система описывается в терминах операций и их отношений.

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

Для разработки формальных спецификаций последовательных и параллельных систем в настоящее время создано несколько языков, представленных в табл. 13.1. Приведенные далее примеры показывают, как построение формальных спецификаций приводит к точным и детализированным спецификациям.

Таблица 13.1. Языки разработки формальных спецификаций