 |
Сборка приложений с повторным использованием компонентов
|
|
|
|
Время, необходимое для разработки системы, можно уменьшить, если многие части такой системы будут использованы неоднократно. Для быстрого построения прототипа необходимо иметь набор компонентов, пригодных для повторного использования, и механизм сборки системы из этих компонентов. Этот подход показан на рис. 8.7.
Рис. 8.7. Сборка повторно используемых компонентов
Прототипирование с повторно используемыми компонентами применяется при разработке требований, конечно, если есть подходящие компоненты. Если подходящих компонентов нет, то для реализации некоторых требований будет необходим компромиссный подход. Функциональные возможности доступных компонентов могут не точно соответствовать пользовательским требованиям. Но, с другой стороны, эти требования обычно достаточно гибкие, поэтому во многих случаях возможно создание прототипа.
Разработку прототипа с повторным использованием компонентов можно реализовать на двух уровнях.
1. Уровень приложения, когда целые прикладные системы интегрируются с прототипом так, чтобы были объединены их функциональные возможности. Например, если прототипу требуются средства обработки текста, то это можно обеспечить путем интеграции в прототип стандартной системой текстового процессора. Отметим, что приложения Microsoft Office поддерживают интеграцию со сторонними системами.
2. Уровень компонентов, когда отдельные компоненты объединяются внутри структуры, реализующей систему. Такая структура может быть создана с помощью одного из языков описания сценариев, таких, как Visual Basic, TCL/TK [267], Python [225] или Perl [337]. В качестве альтернативы могут применяться такие системы, как CORBA, DCOM или JavaBeans [311, 264, 280, 27*].
|
|
|
Повторно используемые приложения дают доступ ко всем своим функциональным возможностям. Если, кроме того, приложение обеспечивает создание сценариев или средства автоматизации (например, макросы Excel), они также могут использоваться для расширения функциональных возможностей прототипа.
Для понимания этого метода разработки прототипа полезен составной документ, который представляет собой схему обработки данных прототипом и который можно рассматривать как контейнер для нескольких различных объектов. Эти объекты содержат разные типы данных (такие, как таблица, диаграмма, форма), которые могут обрабатываться различными приложениями.
На рис. 8.8 представлен составной документ для прототипа системы, включающего текстовые элементы, элементы электронной таблицы и звуковые файлы. Текстовые элементы обрабатываются текстовым процессором, таблицы – электронной таблицей, а звуковые файлы – аудиопроигрывателем. Когда пользователь системы обращается к объекту определенного типа, вызывается связанное с ним приложение.
Рис. 8.8. Связывание приложений посредством составного документа
Рассмотрим прототип системы, поддерживающей управление разработкой требований (см. главу 6). Для этой системы необходимы средства фиксации требований, их хранения, создания отчетов, поиска зависимостей между требованиями и управления этими зависимостями с помощью матриц оперативного контроля. В прототипе должна быть база данных (для хранения требований), текстовый процессор (для ввода требований и создания отчетов), электронная таблица (для управления матрицами контроля) и специально написанная программа для поиска зависимостей между требованиями.
Основное преимущество описываемого подхода к прототипированию состоит в том, что многие функциональные средства прототипа можно реализовать быстро и дешево. Если пользователи, тестирующие прототип, знакомы с приложениями, интегрированными в прототип, им нет необходимости учиться использовать новые средства прототипа. Проблемы при работе с прототипом могут возникнуть только при переключении с одного приложения на другое. Но это в значительной степени зависит от используемой операционной системы. Для организации переключения между приложениями наиболее широко используется механизм связывания и внедрения объектов OLE от Microsoft [311].
|
|
|
Не всегда возможно или удобно использовать целые приложения. Для создания прототипов можно использовать более "тонкие" компоненты. Это могут быть отдельные функции или объекты, которые выполняют специальные действия, например сортировку, поиск, отображение данных и т.д. Прототипирование начинается с определения общей структуры прототипа, затем компоненты интегрируются в соответствии с этой структурой. Если нет компонентов, выполняющих требующиеся функции, вместо них разрабатываются отдельные программы, которые в будущем также можно повторно использовать.
Визуальные системы разработки приложений, подобные Visual Basic, поддерживают повторное использование компонентов. Разработчики строят систему в интерактивном режиме, определяя интерфейс в виде набора экранных форм, полей, кнопок и меню. Эти элементы интерфейса именованы, и каждый из них связан со сценарием обработки событий и данных. Эти сценарии могут вызывать повторно используемые программные компоненты.
На рис. 8.9 показан экран приложения, содержащий меню (в верхней части), поля ввода (белые области слева на экране), поля вывода (затенная область слева) и кнопки, представленные скругленными прямоугольниками справа на экране. После расположения этих графических элементов на экране разработчик определяет, какие готовые компоненты будут связаны с ними, либо пишет программы, выполняющие необходимые действия. На рис. 8.9 показаны компоненты, связанные с некоторыми отображаемыми элементами экрана.
Рис. 8.9. Визуальное программирования с повторным использованием компонентов
Visual Basic – пример семейства языков, названных языками сценариев [268]. Языки сценариев – нетипичные языки высокого уровня, разработанные для интеграции компонентов в единую систему. Ранним примером языка сценариев может служить оболочка Unix [56], с тех пор были созданы другие более мощные языки создания сценариев [267, 225, 337, 4*]. Эти языки имеют управляющие структуры и графические инструментальные средства, радикально уменьшающие время разработки систем.
|
|
|
Описанный подход к разработке систем предоставляет возможность быстро разработать относительно малые и простые приложения, которые могут быть построены одним лицом или небольшим коллективом разработчиков. Для больших систем, которые должны разрабатываться большими коллективами, подобный подход организовать более сложно, поскольку не существует явной архитектуры системы и часто имеются сложные зависимости между различными компонентами системы. В этом причина трудностей при внесении изменений в систему. Кроме того, ограничен набор компонентов, поэтому бывает трудно реализовать нестандартные пользовательские интерфейсы. Общий покомпонентный метод разработки, обсуждаемый в главе 14, является более подходящим для больших программных систем.
|
|
|
VIII. ТЕХНИКА ИЗМЕНЕНИЯ ЛИЧНОЙ ИСТОРИИ С ИСПОЛЬЗОВАНИЕМ ВИЗУАЛЬ НОЙ СИСТЕМЫ.
А) С использованием кривых Безье
А. Проверка подлинности процессов при распределении ключей с использованием ЦРК
Автоматический запуск приложений
Ввод табличной формулы с использованием имен диапазонов.
Возможные проблемы, связанные с использованием видео на уроке и способы их решения
Выборка с использованием оператора IN (принадлежит)
Вычисления с использованием имен ячеек.
Гадание с использованием домино
Глава II Сборка и техника сварки.
