Тема 4.2 Инструментальные средства создания клиентской части

 

Студент должен

 

знать:

• характеристику инструментальных средств;

• возможности инструментальных средств.

 ПЛАН:

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

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

    В концепции ИТКС определена задача - создать архитектуру информационных систем, позволяющую реализовать как простую клиент-серверную архитектуру для приложений обработки трансакций или on-line Transaction Proccessing (OLTP)-приложений, так и многоуровневую - для аналитических приложений.

Об архитектуре приложений в ИТКС

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

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

     К таким приложениям относятся:

    система поддержки распределенных приложений на основе модели распределенных сетевых вычислений, предназначенная:

• для классических приложений, построенных по принципу функционального взаимодействия модулей. Кроме того, здесь реализуется поддержка протокола Remote Program Call (RPC) в операционных системах UNIX, Windows NT, Windows 95 и Windows 3.1x для различных сетевых протоколов нижних уровней;

• для приложений, построенных на объектной парадигме как системе взаимодействующих прозрачно распределенных объектов. Здесь также разрабатываются и адаптируются инструментальные средства и соответствующие технологии, реализующие стандарты консорциума Object Management Group (OMG) под общим названием Object Management Architecture (OMA). В OMA-версии 1993 года входит распространенный открытый стандарт Common Object Request Broker Architecture (CORBA) версии 2.0. Концептуально OMA определяет уровни приложений и представлений в модели открытых взаимодействий Open System Interсonnection (OSI) и обеспечивает возможность построения распределенных систем и приложений на самом высоком уровне абстракции в рамках архитектуры OSI. Кроме того, в OMA определены спецификации, в том числе и для объектных взаимодействий в сетях Intranet;

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

    распределенные системы, предназначенные:

• для обеспечения безопасности приложений;

• для классификации объектов инфраструктуры Российской Федерации и ее регионов;

• для коллекций законодательных актов РФ и ее регионов.

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

     Естественным решением для выполнения перечисленных выше требований является применение объектной методологии построения больших систем.

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

    Применение профиля стандартов должно обеспечивать следующие свойства приложений:

• реинжениринг (reengineering), т.е. cпособность приложений к последующему развитию в любой фазе ЖЦ. Инструментальные системы поддержки ЖЦ относятся к классу Computer Aided System/Software Engineering (CASE) и их применение для ответственных приложений обязательно;

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

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

Классы инструментальных систем разработки приложений

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

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

• это системы быстрой разработки приложений или Rapid Application Development (RAD);

• это системы аналитической обработки данных в реальном масштабе времени on-line Analytical Processing (OLAP). Они используются в приложениях аналитического мониторинга поведения объектов;

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

• это системы поддержки математических методов анализа данных;

• это системы автоматического извлечения знаний из баз данных;

• это системы обработки документов. Гипертекстовые системы. Системы аналитической обработки документов;

• это средства создания систем электронного документооборота;

• это средства создания геоинформационных систем;

• это средства создания мультимедиа-объектов и презентаций;

• это средства поддержки ЖЦ информационных систем или CASE-системы;

• это средства разработки приложений с использованием технологий Intranet.

     В настоящее время тенденция к интеграции в одном приложении многих базовых классов информационных систем увеличивает значение объектной методологии создания приложений. Например, для приложений аналитической обработки данных из сообщений средств масс-медиа чаще других интегрируются приложения, относящиеся к различным классам, а именно: документальные системы, СУБД, системы электронного документооборота, электронную почту, геоинформационные, аналитические системы, системы поддержки мультимедиа-презентаций.      К сожалению, в короткой статье невозможно изложить взгляд на тенденции развития средств разработки крупных ответственных приложений для работы в среде ИТКС. Остановимся на опыте использования «некоробочного» инструментария, редко освещаемого в коммерчески ориентированных печатных изданиях, в частности, на CASE-технологиях и инструментальных системах аналитической обработки данных.