Вовлечение заказчика в процесс разработки. Разработка программного комплекса автоматизации процесса получения и передачи сообщений между центром обработки звонков и клиентами

Обеспечиваем всестороннее рассмотрение всех элементов

Зачем нужно определение требований

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

Место среды разработки в контексте

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

На рисунке 1 изображен центр обеспечения качества (Center of Excellence), отвечающий за создание и обслуживание среды разработки. Эта среда используется в проектах разработки, которые, в свою очередь, создают и обслуживают программоемкие системы (либо какие-то другие программные активы, например, компоненты или сервисы). Такая простая визуализация позволяет уточнить различия между ролью центра обеспечения качества (включая роли членов коллектива, процессы и ключевой узел – среду разработки) и проектами, которые используют эту среду разработки (а также их роли, процессы и узлы).

Элементы среды разработки

Согласно мнению экспертов по программному обеспечению IBM Rational, среда разработки состоит из следующих шести элементов, каждый из которых показан на рисунке 2 и подробно описан ниже:

• Методика (Method)
• Средства (Tools)
• Подготовка (Enablement)
• Организация (Organization)
• Внедрение (Adoption)

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

• Персонал – это организация и подготовка.
• Процесс – это методика.
• Технология – это средства и инфраструктура.

Внедрение – это новый (и очень важный) элемент, который концентрируется на распространении среды разработки в организации, бизнес-подразделении или проекте.

Методика (Method)

Ключевым элементом любой среды разработки является методика, которой придерживаются, формально или неформально, специалисты-практики. Вот ключевые составляющие, относящиеся к методике:

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

Средства (Tools)

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

Ключевые элементы, относящиеся к инструментальным средствам:

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

Подготовка (Enablement)

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

Ключевые элементы, относящиеся к подготовке:

• Учебные программы и курсы. Они охватывают разнообразные потребности – от обучения опытных специалистов деталям среды разработки до всеобъемлющей программы переподготовки специалистов.
• Инструктивные материалы. Применяются специалистами при консультировании менее опытных коллег.
• Топология развертывания подготовки. Топологию развертывания необходимо принимать во внимание, например, когда подготовка специалистов организуется посредством Web-обучения. Опять же для размещения материалов необходим Web-сервер, а рабочие станции должны быть оснащены Web-браузерами. Топология развертывания может также указывать помещения и классы, необходимые для проведения аудиторного обучения.

Организация (Organization)

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

Ключевые элементы, относящиеся к организации:

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

Инфраструктура (Infrastructure)

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

1. Во-первых, консолидация. Например, при рассмотрении потребностей инфраструктуры среды разработки в целом можно определить, что необходим лишь один Web-сервер для поддержки как Web-содержимого методики, так и web-обучения.
2. Во-вторых, гарантирование должного учета всего дополнительного аппаратного и программного обеспечения, поддерживающего среду разработки (например, операционные системы, системы управления базами данных, аппаратные системы управления, инструментарий для тестирования при разработке устройств реального времени и встроенных устройств).
3. В-третьих, центр обеспечения качества может потребовать развертывания инфраструктуры для поддержки работ по созданию и тестированию среды разработки до ее внедрения в какую-либо производственную инфраструктуру поддержки бизнес-проектов.

Ключевые элементы, относящиеся к инфраструктуре:

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

Внедрение (Adoption)

В дополнение к уже перечисленным элементам важно рассмотреть вопрос внедрения среды в организации, бизнес-подразделении или в проекте разработки.

Ключевые элементы, относящиеся к внедрению:

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

Контекст решения

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

• Функциональность представляет схему или порядок разработки программного обеспечения, обеспечиваемые средой разработки. Реализация этих требований вынуждает учитывать все упомянутые ранее элементы. Например, порядок управления требованиями (см. рисунок 3) поддерживается следующими аспектами:
  • Методика управления требованиями.
  • Инструментальные средства управления требованиями.
  • Обучение и наставничество по вопросам управления требованиями.
  • Группа поддержки, умеющая решать вопросы управления требованиями.
  • Аппаратное и программное обеспечение для поддержки элементов, связанных с управлением требованиями.
  • Соответствующее внедрение в проектах порядка управления требованиями.

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

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

Еще одним важным ограничением при рассмотрении возможности изменения существующей среды разработки является, конечно, окупаемость инвестиций (Return On Investment – ROI). Чтобы такая инициатива была успешной, она, несомненно, должна обеспечить положительные результаты, соответствующие бизнес-плану. Каждый аспект среды разработки влияет на ROI как с точки зрения затрат, так и с точки зрения прибыли.

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

Определение, развертывание, управление

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

• Определение среды.
• Развертывание среды.
• Управление средой.

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

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

Определение

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

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

Таблица 1. Аспекты определения

Развертывание

Развертывание среды разработки поднимает специфические вопросы относительно каждого элемента (см. таблицу 2).

Таблица 2. Аспекты развертывания

Ключевые элементы методики :

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

Ключевые элементы инструментальных средств :

• Выполнение локальной настройки. Любая локальная настройка инструментальных средств применяется для автоматизации настройки локальной методики.
• Установка инструментальных средств. Делает установленные средства (и интеграцию их) доступными для специалистов.
• Миграция локальных данных. Например, может возникнуть необходимость переноса данных из существующего набора инструментальных средств в новый.

Ключевые элементы подготовки :

• Выполнение локальной настройки. локальной настройки. При необходимости - адаптация, уточнение или обновление учебных материалов. Можно, например, пересмотреть материалы подготовки для приведения их в соответствие с процессом, определенным для данного бизнес-подразделения или проекта разработки.
• Развертывание материалов подготовки. Гарантирует доступ к ним исполнителей, включая доступ ко всем Web-материалам.
• Обучение исполнителей. При обучении собираются отзывы исполнителей.

Ключевые элементы организации :

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

Ключевые элементы инфраструктуры :

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

Ключевые элементы внедрения :

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

Управление

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

Таблица 3. Аспекты управления

Ключевые элементы методики :

• Сбор отзывов по методике. Ключевым аспектом управления средой разработки является ее постоянное совершенствование. Поэтому сбор отзывов касается всех элементов. Отзывы обычно собираются субъективно при помощи, например, опросных листов.

Ключевые элементы инструментальных средств :

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

Ключевые элементы подготовки :

• Обучение исполнителей. Назначить кураторов проектов, чтобы исполнители знали, как использовать среду.
• Сбор отзывов по подготовке, т.е. по обучению или наставничеству.

Ключевые элементы организации :

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

Ключевые элементы инфраструктуры :

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

Ключевые элементы внедрения :

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

Взаимозависимости

Наконец, имейте в виду, что различные элементы среды разработки не являются независимыми. Альтернативное представление рисунка 2 приведено на рисунке 5, который показывает, что каждый элемент имеет взаимосвязи со всеми другими элементами.

Вот несколько примеров зависимостей между элементами:

• Методика (методика) ссылается на доступные обучающие курсы (подготовка).
• Инструментальные средства (средства) автоматизируют задачи (методика).
• Административные роли (организация) определены для поддержки инструментальных средств (средства).
• Серверы (инфраструктура) предоставлены для размещения набора инструментальных средств (средства).
• Внедрение приемов работы (внедрение) оценивается с использованием определенного подхода (методика).

Заключение

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

Алексей Федоров, Наталия Елманова

Предыдущая статья настоящего цикла была посвящена рассмотрению логического и физического проектирования данных и инструментальным средствам, используемым в данном процессе. Мы убедились в том, что проектирование данных играет ключевую роль при разработке информационных систем - ведь от качества выполнения этой работы зависят затраты, связанные с созданием приложений для конечных пользователей, а также с последующим сопровождением и модернизацией созданного продукта. Результатом этого этапа является "пустая" база данных (то есть база данных, таблицы которой по большей части не содержат записей, за исключением, возможно, таблиц справочного характера типа списка субъектов Российской Федерации или телефонных кодов городов).

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

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

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

Классификация средств разработки приложений

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

Практически любое средство разработки, мало-мальски претендующее на универсальность, можно заставить работать с любой базой данных - достаточно поддержки применения в этом средстве разработки сторонних библиотек и наличия у этой базы данных набора клиентских интерфейсов (API) для платформы, на которой должны функционировать созданные приложения. Однако далеко не любая пара продуктов "средство разработки плюс СУБД" привлекательна с точки зрения трудозатрат, связанных с созданием подобных приложений. Можно написать полноценное приложение, вызывающее функции клиентского API и реализующего удобный пользовательский интерфейс с помощью компилятора языка С и простейшей графической библиотеки (например, позволяющей изменять цвет пикселов на экране) для той операционной системы, в которой будет работать данное приложение. Но затраты, связанные с реализацией подобного проекта, могут оказаться совершенно неоправданными - ведь в этом случае разработчикам придется реализовывать функции, которые уже содержатся в библиотеках классов и компонентов средств разработки, более глубоко ориентированных на создание приложений с базами данных или включающих поддержку создания таких приложений.

Средства разработки, ориентированные на конкретные СУБД

Лет десять-двадцать назад во многих приложениях, использующих базы данных, функции клиентского API вызывались из кода, написанного на одном из языков программирования, чаще всего на C. Достаточно взглянуть на описание API клиентской части почти любой серверной СУБД - и вы найдете немало примеров наиболее типичных фрагментов кода, например, для регистрации пользователя, выполнения запросов и т.п. Однако достаточно быстро разработчикам СУБД стало ясно, что трудозатраты, связанные с написанием подобного кода, можно существенно сократить, собрав в библиотеки наиболее типичные фрагменты кода и наиболее часто встречающиеся элементы пользовательского интерфейса (пусть даже и для алфавитно-цифровых терминалов), оформив эти библиотеки в виде отдельного продукта и добавив к нему среду разработки и утилиты проектирования пользовательских форм для просмотра и редактирования данных, а также отчетов. Именно так и появились первые средства разработки, ориентированные на конкретные СУБД, такие, например, как Oracle*Forms (предшественник нынешнего Oracle Forms Developer ).

Продукты этого класса на рынке средств разработки имеются и сегодня. Почти все производители серверных СУБД производят и средства разработки приложений. В подавляющем большинстве случаев современные версии этих средств разработки поддерживают доступ к СУБД других производителей как минимум с помощью одного из универсальных механизмов доступа к данным (ODBC, OLE DB, BDE). Однако доступ к "своей" СУБД обычно осуществляется максимально эффективным способом, то есть с помощью клиентских API, объектов, содержащихся в библиотеках клиентской части серверных СУБД, специальных классов для доступа к данным этой СУБД либо за счет реализации драйверов для универсальных механизмов доступа к данным, способной учитывать специфические особенности данной СУБД.

В отдельную категорию можно выделить среды разработки настольных СУБД. В статье данного цикла, посвященной настольным СУБД, мы уже отмечали, что подавляющее большинство настольных СУБД, доживших до сегодняшнего дня, таких как Microsoft Visual FoxPro , Microsoft Access, Corel Paradox, Visual dBase, поддерживают доступ к серверным СУБД, как минимум, с помощью универсальных механизмов доступа к данным, что позволяет условно отнести их и к категории средств разработки. Отметим, однако, что в настоящее время создание приложений в архитектуре "клиент-сервер" с их помощью - явление нечастое. Исключение, пожалуй, составляют пары Microsoft Access - MSDE, Microsoft Access - Microsoft SQL Server и Microsoft Visual FoxPro - Microsoft SQL Server. Здесь налицо результат грамотной политики Microsoft, стремящейся к максимальной совместимости своих продуктов и обеспечивающей наиболее безболезненную для пользователей замену своих настольных СУБД собственными же серверами баз данных (Access->MSDE->Microsoft SQL Server, FoxPro->Visual FoxPro->Microsoft SQL Server).

Средства разработки, универсальные по отношению к СУБД

Средства разработки, универсальные по отношению к СУБД (или претендующие на подобную универсальность), как правило, являются последователями обычных средств разработки приложений, не имеющих прямого отношения к базам данных. Типичные примеры таких средств разработки - Borland Pascal, Borland C++, Microsoft QuickC. Способные использовать библиотеки сторонних производителей, эти средства позволяли обращаться к функциям клиентских API, а с развитием универсальных механизмов доступа к данным (таких как ODBC) - и к функциям API библиотек, реализующих такие механизмы. Отметим, что нередко с помощью этих средств разработки создавались среды настольных СУБД (таких как dBase, FoxBase) или псевдокомпиляторы для языков семейства xBase (например, Clipper).

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

К первой категории относятся средства разработки, обладающие обширными библиотеками классов, большим количеством "мастеров" и кодогенераторов, но ориентированные на "ручное" создание кода и довольно редко применяемые для создания "стандартных" приложений для работы с базами данных (здесь под словосочетанием "стандартное приложение" мы подразумеваем приложение, имеющее непосредственный доступ к базе данных, с которым взаимодействует пользователь, то есть являющееся "классическим" клиентом серверной СУБД). Типичным (и единственным действительно популярным на рынке программного обеспечения) представителем этого класса продуктов является Microsoft Visual C++ . С помощью Microsoft Visual C++ и библиотеки MFC (Microsoft Foundation Classes) можно создавать любые приложения, если вы обладаете навыком, знаниями, умением и временем. Тем не менее приложения, обладающие сложным пользовательским интерфейсом (например, использующие базы данных), с его помощью разрабатывают не так часто (хотя примеры подобного его использования можно найти даже в отечественной литературе). В основном этот продукт применяется для создания клиентских приложений в случае предъявления к ним особых требований, таких, например, как высокая производительность, способность осуществлять какие-либо нестандартные операции и пр.

Ко второй категории относятся средства разработки с развитыми визуальными инструментами, позволяющие буквально "рисовать" пользовательский интерфейс, частично стирая различия между работой программиста и пользователя и удешевляя конечный продукт за счет привлечения к проектированию интерфейса разработчиков, обладающих не самой высокой квалификацией (если внимательно изучить программы курсов учебных центров, специализирующихся на обучении средствам разработки Microsoft, Borland и Sybase, то можно обнаружить, что продолжительность курса обучения, прослушав который обычный пользователь Windows должен научиться создавать клиентские приложения для серверных СУБД, составляет от 5 до 10 рабочих дней).

Именно эта категория средств разработки наиболее часто применяется при создании клиентских приложений. К наиболее популярным продуктам подобного класса следует отнести Microsoft Visual Basic , Borland Delphi , Sybase PowerBuilder и Borland C++ Builder . Среды разработки подобных продуктов весьма схожи внешне (с точностью до расположения окон на экране, устанавливаемого "по умолчанию"): как правило, среда разработки такого продукта содержит "заготовку" проектируемой формы (аналога окна), отдельную панель с пиктограммами элементов пользовательского интерфейса и иных используемых в приложении объектов, которые можно выбирать и помещать на форму, окно, в котором отображаются и редактируются свойства одного из выбранных на форме элементов (а иногда и список событий, на которые реагирует данный элемент), окно редактора кода, где можно вводить фрагменты кода, связанные с обработкой тех или иных событий, а также код, реализующий логику работы данного приложения. Как правило, современные средства разработки такого класса позволяют создавать простейшие приложения для редактирования данных практически без написания кода.

В последнее время очень популярным стало также создание приложений, использующих доступ к базам данных, но расположенных внутри обычных документов. В основу средств разработки подобных приложений положены макроязыки соответствующих редакторов. Наиболее типичным и практически единственным популярным представителем средств разработки этой категории является Visual Basic for Applications, сходный с перечисленными выше визуальными средствами разработки и отличающийся от них тем, что созданные с его помощью приложения содержатся внутри документов Microsoft Office и не отчуждаются от них.

Отметим, однако, что приведенное деление средств разработки на эти два класса весьма условно. Как мы уже говорили выше, практически все средства разработки приложений с базами данных, в том числе и ориентированные на конкретные СУБД, поддерживают как минимум один из универсальных механизмов доступа к данным. И практически все "универсальные" средства разработки приложений, если они принадлежат производителю каких-либо серверных СУБД, поддерживают "свои" СУБД лучше, чем СУБД сторонних производителей (это может выражаться, например, в особых библиотеках классов или компонентов для доступа к данному серверу, а также в наличии общих репозитариев объектов и моделей данных, а иногда и общих с клиентской частью серверной СУБД редакторов параметров доступа к данным или схем данных)

Классификация приложений, использующих базы данных

Приложения в архитектуре "клиент-сервер"

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

Для создания клиентских приложений в этом случае чаще всего применяются средства разработки, обладающие развитыми визуальными инструментами, такие как Microsoft Visual Basic, Borland Delphi, Sybase PowerBuilder, Borland C++Builder.

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

Распределенные приложения

Распределенные (или многозвенные) приложения обычно состоят из презентационных сервисов (или "тонких" клиентов, с которыми обычно взаимодействуют конечные пользователи), сервисов бизнес-логики, реализуемых в виде бизнес-объектов (или сервисов промежуточного слоя - middle tier; нередко для описания совокупности таких сервисов применяется термин middleware), и сервисов данных (обычно состоящих из сервера баз данных и механизмов доступа к данным). Сервисы бизнес-логики предназначены для получения введенных пользователем данных от презентационных сервисов, взаимодействия с сервисами данных для выполнения бизнес-операций (например, обработки заказов или расчета бухгалтерского баланса) и возврата результатов этих операций презентационным сервисам.

В отличие от обычных приложений в архитектуре "клиент-сервер", в многозвенных системах "тонкие" клиенты, как правило, не имеют непосредственного доступа к данным. Вместо этого клиенты посылают запросы к специально предназначенным для этой цели бизнес-объектам. Те, в свою очередь, могут выполнять запрошенные клиентом бизнес-операции (такие как обработка заказа, выполнение банковской транзакции и т.д.).

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

Для создания бизнес-объектов применяются как средства разработки с развитыми визуальными инструментами, так и средства разработки, ориентированные на "ручное" создание кода приложений (такие как Visual C++). Отметим, что новейшие версии почти всех наиболее популярных средств разработки Windows-приложений (Microsoft Visual Basic, Visual FoxPro и Visual C++, Borland Delphi и C++Builder, Sybase PowerBuilder) поддерживают создание различных типов бизнес-объектов (Web-приложений, ASP-объектов, COM-серверов и др.), за исключением, пожалуй, Microsoft Access - этот продукт рассчитан скорее на квалифицированных пользователей, нежели на разработчиков распределенных систем. Нередко для этой цели используются и средства создания Java-приложений (такие как Borland JBuilder).

Отметим, что, кроме перечисленных выше "универсальных" средств создания как приложений в архитектуре "клиент-сервер", так и бизнес-объектов для распределенных систем, на рынке средств разработки имеются и специализированные средства, предназначенные именно для создания бизнес-объектов (как правило, Web-приложений). Из средств разработки такого класса для платформы Windows наиболее популярен Microsoft Visual InterDev , первая версия которого появилась в 1998 году. Можно также упомянуть еще один интересный продукт, относящийся к той же категории средств разработки, - Borland IntraBuilder, появившийся двумя годами раньше, но почему-то, несмотря на растущую потребность в продуктах такого класса, не получивший дальнейшего развития. Средства разработки подобного класса, как правило, позволяют создавать приложения, динамически генерирующие HTML-код либо код на одном из скриптовых языков (VBScript или JavaScript), который передается Web-сервером в браузер пользователя в составе Web-страницы, и воспринимающие данные, введенные пользователем в HTML-форме и переданные браузером Web-серверу.

Заключение

В настоящей статье мы обсудили процесс создания приложений, использующих базы данных, а также различные категории средств, применяемых при их разработке. Мы убедились, что средства разработки можно условно разделить, с одной стороны, на инструменты, ориентированные на применение конкретных СУБД, инструменты, универсальные по отношению к СУБД, и среды настольных СУБД, применяемые для разработки приложений. С другой стороны, их можно разделить на средства, ориентированные на визуальное проектирование пользовательского интерфейса (к этой категории относятся Microsoft Visual Basic, Borland Delphi, Sybase PowerBuilder, Borland C++Builder), и на средства, ориентированные на написание кода приложения (Visual C++).

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

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

Мы также обсудили, чем приложения в архитектуре "клиент-сервер" отличаются от распределенных систем и какие средства разработки можно применять при создании обоих типов приложений.

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

1.3 Выбор средств разработки программного обеспечения

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

К ним относятся такие программные средства, как Delphi, Visual C++, С Builder, Visual Basic, Java Builder;

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

Приняв во внимание вышеперечисленные аргументы, для разрабатываемого программно-методического комплекса целесообразно использовать средства типа RAD.

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

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

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

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

Доступность программных средств разработки и реализации;

Cоответствие выбираемых программных средств уровню подготовленности программиста;

Возможности программных средств для разработки профессиональных приложений и сложных программных систем;

Оценка качества средств с точки зрения надежности, производительности, удобства работы и трудоемкости их эксплуатации;

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

Возможность перехода от однопользовательского варианта (для отладки и локального применения) к сетевому, для средств разработки и средств эксплуатации, а также его сложность;

Стыковка с широким спектром других СУБД и возможности переноса БД для данного программного средства на другие СУБД;

Возможность подключения к корпоративным сетям и Интернет/Интранет, поддержка постоянно развивающихся WEB технологий;

Модульный принцип построения, степень ее универсальности.

Наличие документации на русском языке, справочных систем, документации в печатном и электронном исполнении, возможности консультаций;

Простота языка программирования;

Скорость работы приложения;

Скорость компиляции приложения;

Наличие интегрированного отладчика;

Обработка исключительных ситуаций;

Методика определения подходящего программного продукта заключается в следующем.

Сначала выбирается несколько доступных и известных программных продуктов. Мною для рассмотрения были выбраны Delphi 5.0, Visual C++ 6.0 и Visual Basic. Каждому критерию назначил вес, исходя из целей проектирования таким образом, что сумма весов всех критериев равнялась 1.

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

В качестве экспертов, который ставили экспертную оценку, выступали студенты пятого курса группы ИТ98-1

Вычисления по формуле (1.1) сведены в таблицу 1.2.

Как видно из таблицы 1.2 наиболее подходящим средством для разработки программного комплекса является Delphi 5.0.

Таблица 1.2 - Сравнение программных продуктов

1.4 Техническое задание 1.4.1 Введение

Программный комплекс предназначен для создания курса обучения дисциплине и для обучения дисциплине.

1.4.2 Основания для разработки

Разработка программного комплекса ведется на основании задания на дипломную работу, утвержденное приказом ректора Донбасской машиностроительной академии по ГОСТ 19.101-77.

Тема дипломной работы – «Программно – методический комплекс для мультимедийного представления учебной информации».

Спецчасть разработки – «Разработка программного обеспечения для интерфейса оболочки комплекса и примера информационного наполнения»

1.4.3 Назначение разработки

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

1.4.4 Требования к программному изделию 1.4.4.1 Требования к функциональным характеристикам

Программный комплекс должен выполнять следующие функции:

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

Предоставлять возможность изменения курса;

Предоставлять возможность проходить курс(обучаться);

Предоставлять возможность контролировать полученные знания;

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

1.4.4.2 Требования к надежности

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

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

1.4.4.3 Условия эксплуатации

Температура окружающего воздуха, влажность и другие параметры микроклимата должны соответствовать требованиям к помещениям, оборудованным персональными ЭВМ.

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

1.4.4.4 Требования к составу и параметрам технических средств

Для нормального функционирования программного комплекса необходима персональная ЭВМ со следующими характеристиками:

Объем оперативной памяти не менее 32 мегабайт;

Процессор не ниже Pentium 166, мышь, клавиатура;

Наличие свободного места на жестком диске в размере не менее 5 мегабайт;

Дисковод на 3,5’’;

Звуковая карта;

Монитор SVGA.

1.5.4.5 Требования к информационной и программной совместимости

Программа должна функционировать под операционной системой Windows. Должна быть установлена программа BDE Administrator для работы с базами. Исходные коды программы должны быть написаны на языке Object Pascal в среде разработки Delphi 5.0. Информация должна вводиться непосредственно через GUI. Результат визуализации информации должен быть представлен в хорошо воспринимаемом виде.

1.4.4.6 Требования к программной документации

Предварительный состав программной документации установлен в соответствии с ГОСТ 19.101-77. Ниже перечислен список программных документов и их содержание.

Текст программы – запись программы с необходимыми пояснениями и комментариями.

Описание программы – сведения о логической структуре и функционировании программы.

Программа и методика испытаний – требования, подлежащие проверке при испытании программы, также порядок и методы контроля.

Техническое задание – настоящий документ.

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

1.4.5 Стадии и этапы разработки

Стадии и этапы разработки должны соответствовать ГОСТ 19.101-77 и состоять из следующих пунктов.

1 Техническое задание – черновое определение требований к программному комплексу и программной документации.

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

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

4 Рабочий проект – разработка программы, разработка программной документации, испытание программы.

1.4.6 Порядок контроля и приемки

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

1.5 Разработка математической модели

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

Предлагаются следующие шаги для составления курса обучения:

Методическая разработка темы обучающей программы.

Анализом результатов специальных модельных экспериментов разработать модель главы для профильного учебника.

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

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

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

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

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

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

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

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

Возможность накопить опыт творческой деятельности в разных предметных областях, знакомство с интересными применениями ЭВМ.

Учебник должен обеспечить возможность ученику выбрать не только уровень, на котором будет изучать учебный материал темы, но и разный способ изучения темы (не менее двух способов). При этом ученик должен осознать, что он и только он отвечает за свой выбор уровня изучения темы.

Рисунок 1.2 - Этапы разработки ЭУ

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

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

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

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

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

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

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

Исходя из вышеперечисленного предлагается структура материалов, приведенная на рисунке 1.3.

1.6 Разработка компонентов программного комплекса 1.6.1 Разработка логической модели программного комплекса

Одним из способов при описании логической модели программного комплекса является структурный анализ.

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

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

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

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

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

них может привести к непредсказуемым последствиям (в том числе и к провалу всего проекта). Основными из этих принципов являются следующие:

Принцип абстрагирования - заключается в выделении существенных аспектов системы и отвлечения от несущественных;

Рискнок 1.3- Структура материалов

Принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы;

Принцип непротиворечивости - заключается в обоснованности и согласованности элементов;

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

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

SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;

DFD (Data Flow Diagrams) диаграммы потоков данных;

ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь";

На уроках біології. [Електронний ресурс]. Режим доступу: http: // www. nenc.gov.ua / index.php? id=79. – Заголовок з титул. екрана. АНОТАЦІЇ Сліпчук І.Ю. Методика навчання біології учнів 8-9 класів з використанням комп’ютерних технологій. – Рукопис. Дисертація на здобуття наукового ступеня кандидата педагогічних наук за спеціальністю 13.00.02 – теорія та методика навчання (біологія). – Наці ...

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

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

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

Различают три основных класса инструментальных средразработки и сопровождения ПС (рис. 16.1): ·

среды программирования, ·

рабочие места компьютерной технологии,·

инструментальные системы технологии программирования.

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

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

1. Инструментальные среды программирования.

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

Различают следующие классы инструментальных сред программирования (см. рис. 14.2): ·

среды общего назначения,·

языково-ориентированные среды.

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

Рис.16.2. Классификация инструментальных сред программирования.

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

интерпретирующие среды, ·

синтаксически-управляемые среды.

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

Для оптимальной разработки среды программного средства необходимо комбинировать различные языки программирования, так как каждый из них направлен на выполнение определенных целей и задач. Как, например, несколько команд PHP позволяют создать целую Web-страницу, но на практике почти всегда скрипт используется совместно с HTML, и обычно исходный текст скрипта содержит большое количество строк. Но, не смотря на это, следует отметить, что код на PHP может находиться в любом месте HTML-документа, однако он не обязательно должен использовать HTML. Необходимо лишь обеспечить, чтобы PHP-код создавал корректный HTML-код, который затем будет правильно отображен Web-браузером.

HTML - гипертекстовый язык разметки, который используется для создания документов в Интернет. С помощью него создается необходимая структура и сетка страницы, внешний вид которой в дальнейшем совершенствуется CSS и JavaScript. В настоящий момент последней версией является HTML5, которой предшествовала HTML4.01. Большинство Web-ресурсов построены на основе именно этого языка.

В отличие от HTML 4, у которого 3 валидатора, у HTML 5 валидатор один: . HTML 5 поддерживает MathML и SVG.

Новые теги: section, article, aside, hgroup, header, footer, nav, dialog, figure, video, audio, source, embed для вставки контента с плагином(только), mark, progress, meter, time, ruby, rt, rp, canvas, command, detailes, datalist, keygen, output.

Новые типы input: tel, search, url, email, datetime, date, month, week, time, datetime-local, number, range, color.

Новые атрибуты для тегов: атрибуты ping media для a и area и т. д.

Исчезновение некоторых тегов, по причине того, что их можно заменить CSS: basefont, big, center, font, s, strike, tt, u.

Исчезновение фреймов из-за негативного влияния на всю страницу

Исчезновение некоторых тегов, замененных в обновленной спецификации на более актуальные: acronym(используется abbr), applet(используется object), isindex, dir.

Не поддерживаются некоторые атрибуты у тегов из-за отсутствия необходимости: rev и charset у link и a, shape и coords у a и т. д.

Не поддерживаются некоторые атрибуты у тегов по причине того, что при использовании CSS достигается лучший эффект: align у всех тегов, alink, link, text, vlink у body и так далее.

Новые API: рисование 2D-картинок в реальном времени; контроль над проигрыванием медиафайлов; хранение данных в браузере; редактирование; Drag-and-drop; работа с сетью; MIME; новые элементы в DOM.

CSS - формальный язык описания внешнего вида документа, написанного с помощью языка разметки. CSS это акроним для Cascading Style Sheets/Каскадных таблиц стилей. CSS это язык стилей, определяющий отображение HTML-документов. Например, CSS работает с шрифтами, цветом, полями, строками, высотой, шириной, фоновыми изображениями, позиционированием элементов и многими другими вещами. HTML может использоваться для оформления Web-сайтов, но CSS предоставляет большие возможности и более точен и проработан. CSS, на сегодняшний день, поддерживается всеми браузерами.

HTML используется для структурирования содержимого страницы. CSS используется для форматирования этого структурированного содержимого. По мере развития Web дизайнеры начали искать возможности форматирования онлайновых документов. Чтобы удовлетворить возросшим требованиям потребителей, производители браузеров (тогда - Netscape и Microsoft) изобрели новые HTML-тэги, такие, например, как , которые отличались от оригинальных HTML-тэгов тем, что они определяли внешний вид, а не структуру. Это также привело к тому, что оригинальные тэги структурирования, такие как

, стали все больше применяться для дизайна страниц вместо структурирования текста. Многие новые тэги дизайна, такие как , поддерживались только одним браузером. «Вам необходим браузер X для просмотра этой страницы» - такой отказ стал обычным явлением на Web-сайтах.

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

Появление CSS стало революцией в мире Web-дизайна. Конкретные преимущества CSS:

Управление отображением множества документов с помощью одной таблицы стилей;

Более точный контроль над внешним видом страниц;

Различные представления для разных носителей информации (экран, печать, и т. д.);

Сложная и проработанная техника дизайна.

Существуют способа применить правила CSS к HTML-документу.

Метод 1: Инлайн/In-line (атрибут style). Можно применять CSS к HTML с помощью HTML-атрибута style. Красный цвет фона можно установить так:

This is a red page

Метод 2: Внутренний (тэг style). Второй способ вставки CSS-кодов - HTML-тэг

Что делать, если ноутбук залили водой

Настройка рабочего стола в 1с предприятие 8

Виртуальная немецкая клавиатура онлайн Как набрать а с двумя точками

• Почему стоит обновить свой телевизор в 2024 году?
• В контакте личная страница
• Какая прошивка лучше для xiaomi mi4c