4. Методология rad

Методология создания ИС, основанная на использовании средств быстрой разработки приложений, получила в последнее время широкое распространение и приобрела название методологии быстрой разработки приложений (Rapid Application Development, RAD). Данная методология охватывает все этапы жизненного цикла современных информационных систем.

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

• использование итерационная (спиральная) модель разработки;

• полное завершение работ на каждом из этапов жизненного цикла не обязательно;

• обеспечение тесного взаимодействия между заказчиком и будущими пользователями в процессе разработки ИС;

• применение САSЕ-средств и средств быстрой разработки приложений;

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

• использование прототипов приложений, позволяющих полнее выяснить и реализовать потребности конечного пользователя;

• осуществление тестирования и развитие проекта одновременно с разработкой;

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

Фазы жизненного цикла в рамках методологии RAD. При использовании методологии быстрой разработки приложений жизненный цикл ИС состоит из четырех фаз:

• анализ и планирование требований;

• процесс проектирования ИС;

• процесс построения ИС;

• фаза внедрения ИС.

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

Методология RAD не подходит для создания:

• типовых систем, не являющихся законченным продуктом, а представляющих собой совокупность типовых элементов ИС;

• сложных расчетных программ, операционных систем и программ управления сложными инженерно-техническими объектами, то есть программ, требующих написания большого объема уникального кода;

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

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

5. Разработка интерфейса ис

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

Специализированные средства ориентированы исключительно на создание приложений для вполне определенной СУБД и не предназначены для разработки обычных приложений, не использующих базы данных. Примером средств такого рода может служить система Power Builder фирмы Sybase.

Универсальные средства могут использоваться как для разработки информационных приложений, взаимодействующих с базами данных, так и для разработки любых других приложений, не использующих базы данных. Из таких средств наибольшей известностью пользуются системы Delphi фирмы Borland, Visual Basic, Visual C фирмы Microsoft.

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

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

• диалоговый ввод-вывод;

• логику диалога;

• прикладную логику обработки данных;

• логику управления данными;

• операции манипулирования файлами и (или) базами данных.

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

Часто изменяемый компонент (компоненты) ИС следует изолировать от редко изменяемых компонентов, чтобы одни изменения не влекли за собой другие. Один из приемов подобной изоляции – изоляция запросов к данным от интерфейса следующим образом:

• каждый из запросов кодируется идентификатором или «закрывается» определенной системной функцией;

• разработчик интерфейса не знает о запросе к данным ничего, кроме параметров атрибутов выборки – их типа и, возможно, количества строк в выборке;

• обработка ошибок в запросах данных представляет собой отдельный модуль;

• обработка ошибок в интерпретации результата запроса также представляет собой отдельный модуль.

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

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

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