Главная Железо

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

12.09.2023

Предмет: Технология разработки программных продуктов.

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

Образовательная

Ознакомление с инструментальными средствами коллективной разработки ПО.

Развивающая:

Развивать умение слушать других, делать выводы и обобщать полученные знания

Воспитательная:

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

Межпредметные связи:

Английский язык

Операционные системы

Информационные технологии

Основы алгоритмизации и программирования

Оборудование: доска, мел, письменные принадлежности, проектор, ПК

Тип урока: комбинированный

Метод обучения: Объяснительно иллюстративный

Ход урока:

1.Организационный момент

Проверка готовности кабинета

Объявление темы

2. Постановка цели урока

3.Повторение пройденного материала

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

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

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

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

4.Сообщение новых знаний

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

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

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

5. Восприятие и осознание учащимися нового материала

6. Осмысление обобщение и систематизация знаний

7. Подведение итогов урока ипостановка домашнего задания

Выучить содержимое темы

Гагарина Л.Г. стр. С.257-259.

Ответить на вопросы:

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

Имеются некоторые трудности в выработке строгого определения CASE-технологии (компьютерной технологии разработки ПС). CASE - это абревиатура от английского Computer-Aided Software Engineering (Компьютерно-Помогаемая Инженерия Программирования). Но без помощи (поддержки) компьютера ПС уже давно не разрабатываются (используется хотя бы компилятор). В действительности, в это понятие вкладывается более узкий (специальный) смысл, который постепенно размывается (как это всегда бывает, когда какое-либо понятие не имеет строгого определения). Первоначально под CASE понималась инженерия ранних этапов разработки ПС (определение требований, разработка внешнего описания и архитектуры ПС) с использованием программной поддержки (программных инструментов). Теперь под CASE может пониматься и инженерия всего жизненного цикла ПС (включая и его сопровождение), но только в том случае, когда программы частично или полностью генерируются по документам, полученным на указанных ранних этапах разработки. В этом случае CASE-технология стала принципиально отличаться от ручной (традиционной) технологии разработки ПС: изменилось не только содержание технологических процессов, но и сама их совокупность.

В настоящее время компьютерную технологию разработки ПС можно характеризовать использованием

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

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

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

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

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

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

Рис. 16.3. Жизненный цикл программного средства для компьютерной технологии.

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

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

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

Генерация программ ПС. На этом этапе автоматически генерирует скелеты кодов программ ПС или полностью коды этих программ по формальным спецификациям ПС.

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

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

Аттестация ПС имеет прежнее содержание.

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

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

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

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

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

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

  • репозиторий,
  • инструментарий,
  • интерфейсы.

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

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

Самая общая архитектура инструментальных систем технологии программирования представлена на рис. 16.4.


Рис. 16.4. Общая архитектура инструментальных систем технологии программирования.

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

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

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

7.1. Инструментальные средства разработки программ

Инструментальное программное обеспечение (Software tools) - программное обеспечение, используемое в ходеразработки, корректировки или развития других программ:

редакторы, компиляторы, отладчики, вспомогательные системныепрограммы, графические пакеты и др.

Сюда входят языки программирования, интегрированные среды разработки программ, CASE-системы и др.

7.1.2. Выбор языка программирования

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

Универсальные языки высокого уровня;

Специализированные языки разработчика программного обеспечения;

Специализированные языки пользователя;

Языки низкого уровня.

В группе универсальных языков высокого уровня безусловным лидером на сегодня является язык C++. Действительно, он имеет ряд достоинств:

Масштабируемость. На языке C++ разрабатываютпрограммы для самых различных платформ и систем;

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

C++ имеет мощный препроцессор, унаследованный от С, но, как и любой другой мощный инструмент, требуетосторожного использования;

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

При этом язык C++ обладает рядом существенныхнедостатков:

Подключение интерфейса внешнего модуля через препроцессорную вставку заголовочного файла (#include)серьезно замедляет компиляцию при подключении большогоколичества модулей;

Недостаток информации о типах данных во времякомпиляции;

Сложность для изучения и компиляции;

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

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

поэтому пока альтернативы C++ нет . Для второстепенныхпроектов иногда используется Visual Basic. Язык Javaрассматривался как альтернатива Basic, но из-за отсутствия визуального

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

Современный Object Pascal, как и Pascal, предложенный Н. Виртом в середине 70-х годов XX в., остается наиболее привлекательным для обучения основам программирования в силу своей

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

В нынешнее время в отличие от 60-х годов XX в. языкипрограммирования создаются крайне редко. За последние 15 лет можно отметить лишь две новинки, получившие широкоераспространение - это Java (Sun Microsystems, 1995 г.), ставшийпопулярным во многом благодаря технологии его использования в Интернете и появления такого понятия, как виртуальная Java-машина, и С# (Microsoft, 2000 г.), созданный на основе C++.

Создателем языка является сотрудник Microsoft Андреас Хейлсберг. Он стал известным в мире программистов задолго дотого, как пришел в Microsoft. Хейлсберг входил в число ведущих

разработчиков одной из самых популярных сред разработки - Delphi. В Microsoft он участвовал в создании версии Java - J++, так что опыта в написании языков и сред программирования ему не занимать. Как отмечал сам Андреас Хейлсберг, С# создавался как язык компонентного программирования, и в этом одно из главных достоинств языка, направленное на возможностьповторного использования созданных компонентов.

Другие достоинства языка С#:

Сохраняет лучшие черты популярных языковпрограммирования C/C++, на основе которых он создан. В связи с этим облегчается переход программистов от C++ к С#;

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

как указатели, адресация, разыменование, адреснаяарифметика;

Является полностью объектно-ориентированным языком, где даже типы, встроенные в язык, представлены классами;

Реализует возможности наследования и универсализации;

Учитывает все возможности Framework .Net, так как С# создавался параллельно с данной средой;

Благодаря каркасу Framework .Net, ставшему надстройкой над операционной системой, программисты С# получают те же преимущества работы с виртуальной машиной, что и

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

виртуальная Java-машина является интерпретатором байт-кода;

Мощная библиотека каркаса поддерживает удобствопостроения различных типов приложений на С#, позволяя легко строить Web-службы, другие виды компонентов,

достаточно просто сохранять и получать информацию из базы данных и других хранилищ данных;

Является источником надежного и эффективного кода.

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

Научные вычисления (языки C++, FORTRAN, Java);

Системное программирование (языки C++, Java);

Обработка информации (языки C++, COBOL, Java);

Искусственный интеллект (LISP, Prolog);

Издательская деятельность (Postscript, TeX);

Удаленная обработка информации (Perl, PHP, Java, C++);

Описание документов (HTML, XML).

С течением времени одни языки развивались, приобретали новые черты и остались востребованными, другие утратили свою актуальность и сегодня представляют в лучшем случае чистотеоретический интерес (Focal, PL/1 и др.). В значительной степени это связано с такими факторами:

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

Удобство сопровождения и тестирования программ;

Стоимость разработки с применением конкретного языка программирования;

Четкость и ортогональность конструкций языка;

Применение объектно-ориентированного подхода.

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

Языки баз данных;

Языки создания сетевых приложений;

Языки создания систем искусственного интеллекта и т. д.

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

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

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

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

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

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

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

7.7.3. Выбор среды программирования

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

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

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

Обычно среда разработки предназначается для одногоопределенного языка программирования, как, например, Visual Basic или Deiphi, но существуют среды разработки, предназначенные для нескольких языков, такие как Eclipse или Microsoft Visual Studio.

Примеры сред разработки - Turbo Pascal, Borland C++, GNU toolchain, DrPython.

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

которых наиболее распространенные блоки программного кодапредставлены в виде графических объектов.

Наиболее часто используемыми являются визуальные среды Delphi, C++ Builder фирмы Borland (Inprise Corporation), Visual C++, Visual Basic фирмы Microsoft, Visual Ada фирмы IBM и др.

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

Например, служба, написанная на C++ для.NET, может обратиться к методу класса из библиотеки, написанной на Delphi; на С#можно написать класс, наследующий от класса, написанного на Visual Basic .NET, а исключение, выброшенное методом, написанным на С#, может быть поймано и обработано в Delphi.

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

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

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

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

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

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

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

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

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

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

4. Понятие компьютерной технологии разработки программных средств и ее рабочие места. Имеются некоторые трудности в выработке строгого определения CASE-технологии (компьютерной технологии разработки ПС). CASE - это абревиатура от английского Computer-Aided Software Engineering (Компьютерно. Помогаемая Инженерия Программирования). Но без помощи (поддержки) компьютера ПС уже давно не разрабатываются (используется хотя бы компилятор). В действительности, в это понятие вкладывается более узкий (специальный) смысл, который постепенно размывается (как это всегда бывает, когда какое-либо понятие не имеет строгого определения). Первоначально под CASE понималась инженерия ранних этапов разработки ПС (определение требований, разработка внешнего описания и архитектуры ПС) с использованием программной поддержки (программных инструментов). Теперь под CASE может пониматься и инженерия всего жизненного цикла ПС (включая и его сопровождение), но только в том случае, когда программы частично или полностью генерируются по документам, полученным на указанных ранних этапах разработки. В этом случае CASE-технология стала принципиально отличаться от ручной (традиционной) технологии разработки ПС: изменилось не только содержание технологических процессов, но и сама их совокупность.

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

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

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

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

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

Унифицированный язык моделирования UML Большинство существующих методов объектно-ориентированного анализа и проектирования (ООАП) включают как язык моделирования, так и описание процесса моделирования. Язык моделирования – это нотация (в основном графическая), которая используется методом для описания проектов. Нотация представляет собой совокупность графических объектов, которые используются в моделях; она является синтаксисом языка моделирования. Например, нотация диаграммы классов определяет, каким образом представляются такие элементы и понятия, как класс, ассоциация и множественность. Процесс – это описание шагов, которые необходимо выполнить при разработке проекта. Унифицированный язык моделирования UML (Unified Modeling Language) – это преемник того поколения методов ООАП, которые появились в конце 80 -х и начале 90 -х гг.

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

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

UML выделяют следующие типы диаграмм: – диаграммы вариантов использования (usecase diagrams) – для моделирования бизнес-процессов организации (требований к системе); – диаграммы классов (class diagrams) – для моделирования статической структуры классов системы и связей между ними. На таких диаграммах показывают классы, интерфейсы, объекты и кооперации, а также их отношения. При моделировании объектно-ориентированных систем этот тип диаграмм используют чаще всего. Диаграммы классов соответствуют статическому виду системы с точки зрения проектирования; – диаграммы поведения системы (behavior diagrams); диаграммы взаимодействия (interaction diagrams) – для моделирования процесса обмена сообщениями между объектами. – диаграммы состояний (statechart diagrams) – для моделирования поведения объектов системы при переходе из одного состояния в другое.

– диаграммы деятельностей (activity diagrams) – для моделирования поведения системы в рамках различных вариантов использования или моделирования деятельностей. – диаграммы реализации (implementation diagrams): диаграммы компонентов (component diagrams) – для моделирования иерархии компонентов (подсистем) системы; диаграммы размещения (deployment diagrams) – для моделирования физической архитектуры системы.

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

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

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

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

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

Процедурно-ориентированные и проблемно-ориентированные языки относятся к языкам высокого уровня, использующим макрокоманды. Макрокоманда при трансляции генерирует много машинных команд (для процедурноориентированного языка это соотношение в среднем "1 к десяткам машинных команд", а для проблемно-ориентированного – "1 к сотням машинных команд". Процедурноориентированные языки программирования являются самыми используемыми (Basic, Visual Basic, Pascal, Borland Delphi, С и др.). В этом случае программист должен описывать всю процедуру решения задачи, тогда как проблемно-ориентированные языки (их называют также непроцедурными) позволяют лишь формально идентифицировать проблему и указать состав, структуры представления и форматы входной и выходной информации для задачи.

При выполнении инструкций программ компьютеру необходимо преобразовать удобные для человеческого восприятия операторы, написанные на каком-либо языке программирования, в форму, попятную для компьютера. Инструментальное программное обеспечение имеет специальные программы, транслирующие (translate) текст программ, написанных на различных языках программирования, в машинные коды, которые затем выполняются компьютером. Этот вид программного обеспечения называется компилятором или интерпретатором. Текст программы, написанной на языке программирования высокого уровня, до того как быть преобразованным в машинные коды, называется исходным кодом (source code). Компилятор (compiler) преобразует исходный код в машинные коды, называемые объектным кодом (object code) – программой на выходном языке транслятора. Перед выполнением происходит процесс редактирования связей (linkage editing), заключающийся в том, что модули выходной программы объединяются с другими модулями объектного кода, содержащими, например, данные. Результирующий загрузочный модуль – это команды, непосредственно выполняемые компьютером. Некоторые языки программирования содержат не компилятор, а интерпретатор (interpreter), который преобразует каждое отдельное выражение исходного кода в машинные коды и сразу выполняет их. Интерпретатор удобен на этапе отладки программы, так как обеспечивает быструю обратную связь при обнаружении ошибки в исходном коде. Основы программирования на языке высокого уровня Visual Basic изложены в гл. 12 настоящего учебника.

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

Основные функции таких СУБД:

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

Теоретические основы СУБД описаны выше (параграф 3.2), а практическое применение описано в гл. 10.

Технологический раздел

Технология разработки программного обеспечения

3.1.1 Определение процессов предметной области

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

3.1.2 Процессы управления проектами

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

Рисунок 3.1 - Наложение групп процессов в фазе

Рисунок 3.2 - Взаимосвязи групп процессов управления проектом в фазе

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

3.1.3 Технология быстрой разработки приложений

Выбранная для создания дипломного проекта среда разработки Delphi использует технологиюRAD(Rapid Application Development – быстрая разработка приложений). Это означает разработку программного обеспечения в специальной инструментальной среде и основывается на визуализации процесса создания программного кода. Средства быстрой разработки приложений основываются на компонентной архитектуре. При этом компонентыявляются объектами, объединяющими данные, свойства и методы. Компоненты могут быть как визуальными, так и невизуальными; атомарными и контейнерными (содержащими другие компоненты); низкоуровневыми (системными) и высокоуровневыми.

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

Размещение компонентов интерфейса в нужном месте;

Задание моментов времени их появления на экране;

Настройку связанных с ними атрибутов и событий.

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

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

3.1.4 Жизненный цикл программы формирования пакета документов

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

Разработка программы осуществлялась в несколько этапов:

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

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

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

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

Сдача готового продукта.

Рисунок 3.3 – Модули разрабатываемой программы

Признаки модульности программ: 1) программа состоит из модулей. Данный признак для модульной про- граммы является очевидным; 2) модули являются независимыми. Это значит, что модуль можно изме- нять или модифицировать без последствий в других модулях; 3) условие «один вход – один выход». Модульная программа состоит из модулей, имеющих одну точку входа и одну точку выхода. В общем случае может быть более одного входа, но важно, чтобы точки входов были определе- ны и другие модули не могли входить в данный модуль в произвольной точке. Достоинства модульного проектирования: 1) упрощение разработки ПС; 2) исключение чрезмерной детализации обработки данных; 3) упрощение сопровождения ПС; 4) облегчение чтения и понимания программ; 5) облегчение работы с данными, имеющими сложную структуру. Недостатки модульности: 1) модульный подход требует большего времени работы центрального процессора (в среднем на 5 – 10 %) за счет времени обращения к модулям; 2) модульность программы приводит к увеличению ее объема (в среднем на 5 – 10 %);97 3) модульность требует дополнительной работы программиста и опреде- ленных навыков проектирования ПС. Классические методы структурного проектирования модульных ПС делятся на три основные группы : 1) методы нисходящего проектирования; 2) методы расширения ядра; 3) методы восходящего проектирования. На практике обычно применяются различные сочетания этих методов. Резюме В идеальной модульной программе любую часть логической структуры можно изменить, не вызывая изменений в ее других частях. Идеальная модуль- ная программа состоит из независимых модулей, имеющих один вход и один выход. Модульные программы имеют достоинства и недостатки. Существует три группы классических методов проектирования модульных ПС.

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

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

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

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

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

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

Основные принципы методологии RAD можно свести к следующему :

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

В процессе разработки необходимо тесное взаимодействие с заказчиком и будущими пользователями;

Необходимо применение CASE-средств и средств быстрой разработки приложений;

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

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

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

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

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

Логика приложения, построенного с помощью RAD, является событийно-ориентированной, т.е. управление объектами осуществляется с помощью событий. Это означает следующее: каждый объект, входящий в состав приложения, может генерировать события и реагировать на события, генерируемые другими объектами. Примерами событий могут быть: открытие и закрытие окон, нажатие кнопки или клавиши клавиатуры, движение мыши, изменение данных в базе данных и т. п. Разработчик реализует логику приложения путем определения обработчикакаждого события – процедуры, выполняемой объектом при наступлении соответствующего события. Например, обработчик события "нажатие кнопки" может открыть диалоговое окно.

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

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

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

3.2 Технологиятестирования программного обеспечения

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

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

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

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

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

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

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

Корректность – соответствие реализации системы ее спецификации и непротиворечивости;

Интерфейс – как средство общения с пользователями системы;

Открытость – характеризующая модифицируемость системы;

Комфортность – характеризующая удобность использования ПС;

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

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

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

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

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

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

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

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

Предлагается две методики тестирования объектно-ориентированных систем:

Тестирование, основанное на потоках;

Тестирование, основанное на использовании.

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

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


Похожая информация.


Инструментальное программное обеспечение (Software tools) - программное обеспечение, используемое в ходе разработки, корректировки или развития других программ: редакторы, компиляторы, отладчики, вспомогательные системные программы, графические пакеты и др.

Сюда входят языки программирования, интегрированные среды разработки программ, CASE-системы и др.

Выбор языка программирования

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

  • универсальные языки высокого уровня;
  • специализированные языки разработчика программного обеспечения;
  • специализированные языки пользователя;
  • языки низкого уровня.

В группе универсальных языков высокого уровня безусловным лидером на сегодня является язык С++. Действительно, он имеет ряд достоинств:

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

При этом язык C++ обладает рядом существенных недостатков:

  • подключение интерфейса внешнего модуля через препро-цессорную вставку заголовочного файла (#include) серьезно замедляет компиляцию при подключении большого количества модулей;
  • недостаток информации о типах данных во время компиляции;
  • сложность для изучения и компиляции;
  • некоторые преобразования типов неинтуитивны. В частности, операция над беззнаковым и знаковым числами выдает беззнаковый результат.

Для C++ существует большое количество библиотек классов, поддерживающих создание пользовательского интерфейса, клиент-серверных приложений, работу с базами данных и т. д., поэтому пока альтернативы C++ нет . Для второстепенных проектов иногда используется Visual Basic. Язык Java рассматривался как альтернатива Basic, но из-за отсутствия визуального средства разработки форм он пока остается малопригодным. Современный Object Pascal, как и Pascal, предложенный Н. Виртом в середине 70-х годов XX в., остается наиболее привлекательным для обучения основам программирования в силу своей простоты, структурированности и обнаружения компилятором большого количества не только синтаксических, но и семантических ошибок.

В нынешнее время в отличие от 60-х годов XX в. языки программирования создаются крайне редко. За последние 15 лет можно отметить лишь две новинки, получившие широкое распространение - это Java (Sun Microsystems, 1995 г.), ставший популярным во многом благодаря технологии его использования в Интернете и появления такого понятия, как виртуальная Java-машина, и C# (Microsoft, 2000 г.), созданный на основе C++.

Создателем языка является сотрудник Microsoft Андреас Хейлсберг. Он стал известным в мире программистов задолго до того, как пришел в Microsoft. Хейлсберг входил в число ведущих разработчиков одной из самых популярных сред разработки - Delphi. В Microsoft он участвовал в создании версии Java - J++, так что опыта в написании языков и сред программирования ему не занимать. Как отмечал сам Андреас Хейлсберг, C# создавался как язык компонентного программирования, и в этом одно из главных достоинств языка, направленное на возможность повторного использования созданных компонентов.

Другие достоинства языка С#:

  • сохраняет лучшие черты популярных языков программирования C/C++, на основе которых он создан. В связи с этим облегчается переход программистов от C++ к С#;
  • является проще и надежнее C++. Простота и надежность главным образом связаны с тем, что на C# хотя и допускаются, но не поощряются такие опасные свойства C++, как указатели, адресация, разыменование, адресная арифметика;
  • является полностью объектно-ориентированным языком, где даже типы, встроенные в язык, представлены классами;
  • реализует возможности наследования и универсализации;
  • учитывает все возможности Framework .Net, так как C# создавался параллельно с данной средой;
  • благодаря каркасу Framework .Net, ставшему надстройкой над операционной системой, программисты C# получают те же преимущества работы с виртуальной машиной, что и программисты Java. Эффективность кода даже повышается, поскольку исполнительная среда CLR представляет собой компилятор промежуточного языка, в то время как виртуальная Java-машина является интерпретатором байт-кода;
  • мощная библиотека каркаса поддерживает удобство построения различных типов приложений на С#, позволяя легко строить Web-службы, другие виды компонентов, достаточно просто сохранять и получать информацию из базы данных и других хранилищ данных;
  • является источником надежного и эффективного кода.

Кроме вышеописанных языков к группе универсальных

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

  • научные вычисления (языки C++, FORTRAN, Java);
  • системное программирование (языки C++, Java);
  • обработка информации (языки C++, COBOL, Java);
  • искусственный интеллект (LISP, Prolog);
  • издательская деятельность (Postscript, ТеХ);
  • удаленная обработка информации (Perl, РНР, Java, C++);
  • описание документов (HTML, XML).

С течением времени одни языки развивались, приобретали новые черты и остались востребованными, другие утратили свою актуальность и сегодня представляют в лучшем случае чисто теоретический интерес (Focal, PL/1 и др.). В значительной степени это связано с такими факторами:

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

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

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

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

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

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

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

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