Инструментальные средства оформления и документирования алгоритмов программ. Классификация инструментальных средств. Инструментальное программное обеспечение
Введение
В процессе разработки программного обеспечения используется большое количество самого разностороннего программного обеспечения (ПО). Данный курс лекций рассматривает когда и что используется на протяжении всего этапа разработки приложений.
Чтобы дать более полное представление о роли каждой утилиты или срезы разработки в процессе создания ПО, все рассмотренные в данном курсе лекций инструментальные средства будут рассмотрены на примере разработки приложений с использованием одного их высокоуровневых языков. Для простоты, все используемые инструментальные средства можно разделить на 4 группы. Рассмотрим подробнее каждую из групп.
Необходимые
Необходимые инструментальные средства - это те, без которых в принципе невозможно получить исполняемый код; К этой группе можно отнести:
§ редакторы текстов;
§ компиляторы и ассемблеры;
§ компоновщики или редакторы связей (linkers);
Часто используемые
Это средства, использования которых, в отличие от необходимых, можно избежать. Но без них процесс разработки весьма затрудняется и удлиняется; Из часто используемых средств стоит назвать:
§ утилиты автоматической сборки проекта;
§ отладчики;
§ программы создания инсталляторов;
§ редакторы ресурсов;
§ профилировщики;
§ программы поддержки версий;
§ программы создания файлов помощи (документации).
Специализированные
Эти инструментальные средства используются в исключительных случаях, решают довольно специфичные задачи:
§ программы отслеживания зависимостей;
§ дизассемблеры;
§ декомпиляторы;
§ hex-редакторы;
§ программы отслеживания активности системы и изменений, происходящих в системе;
§ программы-вериферы и контейнеры (создают виртуальную среду для отдельных классов программ, в которой можно исследовать поведение программы);
Интегрированные среды разработки
Интегрированные среды разработки содержат большую часть из приведенных выше программ и позволяют упростить процесс создания приложений. По большому счету, среда разработки - это программа, которая собирает вместе несколько инструментальных средств из первой и второй (а иногда и третьей) групп.
В дальнейшем, мы более подробно познакомимся с основными представителями каждой группы, а так же рассмотрим как это всё работает в интегрированной среде разработки.
КЛАССИФИКАЦИЯ ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВ
ТЕМА 1 ПОНЯТИЕ ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВ.
КЛАССИФИКАЦИЯ ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВ.
Инструментальная система технологии программирования - это интегрированная совокупность программных и аппаратных инструментов, поддерживающая все процессы разработки и сопровождения больших ПС в течение всего его жизненного цикла в рамках определенной технологии.
Инструментальные системы технологии программирования можно выделить три основные компоненты:
· репозиторий,
· инструментарий,
· интерфейсы.
Инструментарий - набор инструментов, определяющий возможности, предоставляемые системой коллективу разработчиков. Обычно этот набор является открытым и структурированным. Помимо минимального набора (встроенные инструменты ), он содержит средства своего расширения (импортированными инструментами ). Кроме того, в силу интегрированности по действиям он состоит из некоторой общей части всех инструментов (ядра ) и структурных (иногда иерархически связанных) классов инструментов.
Интерфейсы разделяются на пользовательский и системные. Пользовательский интерфейс обеспечивает доступ разработчикам к инструментарию. Он реализуется оболочкой системы. Системные интерфейсы обеспечивают взаимодействие между инструментами и их общими частями. Системные интерфейсы выделяются как архитектурные компоненты в связи с открытостью системы - их обязаны использовать новые (импортируемые ) инструменты, включаемые в систему.
Самая общая архитектура инструментальных систем технологии программирования представлена на рис.
Рис. Общая архитектура инструментальных систем технологии программирования.
Различают два класса инструментальных систем технологии программирования: инструментальные системы поддержки проекта и языково-зависимые инструментальные системы.
Инструментальная система поддержки проекта - это открытая система, способная поддерживать разработку ПС на разных языках программирования после соответствующего ее расширения программными инструментами, ориентированными на выбранный язык. Набор инструментов такой системы поддерживает разработкой ПС, а также содержит независимые от языка программирования инструменты, поддерживающие разработку ПС (текстовые и графические редакторы, генераторы отчетов и т.п.). Кроме того, он содержит инструменты расширения системы. Ядро такой системы обеспечивает, в частности, доступ к репозиторию.
Языково-зависимая инструментальная система - это система поддержки разработки ПС на каком-либо одном языке программирования, существенно использующая в организации своей работы специфику этого языка. Эта специфика может сказываться и на возможностях ядра (в том числе и на структуре репозитория), и на требованиях к оболочке и инструментам.
Инструментальное программное обеспечение -- программное обеспечение, предназначенное для использования в ходе проектирования, разработки и сопровождения программ.
В процессе изучения предметной области были исследованы средства создания виртуальных экскурсий. В качестве средств создания виртуальной экскурсии были исследованы:
KPresenter - это свободная программа подготовки презентаций, входящая в проекты KOffice и KDE. Интерфейс программы представлен на рисунке 6.
Рисунок 6- Kpresenter.
Adobe Photoshop выбран из ряда других программ (Paint, Paint.net, Photoshop online и др.) в связи с тем, что он довольно- таки прост в изучении и использовании. По нему создано большое количество видеоуроков, и к тому же он входит в программу изучения. С его помощью будут удаляться неизменно возникающие искажения. Интерфейс программы представлен на рисунке 7.
Рисунок 7- Adobe Photoshop.
Microsoft Paint -- многофункциональный, но в то же время довольно простой в использовании растровый графический редактор компании Microsoft, входящий в состав всех операционных систем Windows, начиная с первых версий. Интерфейс программы представлен на рисунке 8.
Рисунок 8- Paint.
Paint.NET -- бесплатный растровый графический редактор для Windows NT, основанный на.NET Framework. Приложение начато как проект, разработанный группой студентов Университета штата Вашингтон для Microsoft Windows под руководством Microsoft. Paint.NET написан на C#, с некоторым количеством C++, используемого при установке и интеграции с оболочкой.
Photoshop online - бесплатный интернет ресурс, расположенный по адресу http://photoshop.domfailov.ru. Графический редактор, который оснащен большим количеством возможностей. Приложение, позволяющее производить различные действия по улучшению и обработке изображения. К числу таких действий относят: обработка цветовой гаммы, монтаж и многое другое. Интерфейс программы представлен на рисунке 9.
Рисунок 9- Photoshop online.
Microsoft Office Word 2003 - текстовый процессор, предназначенный для создания, просмотра и редактирования текстовых документов, с локальным применением простейших форм таблично-матричных алгоритмов. Выпускается корпорацией Microsoft в составе пакета Microsoft Office.. Интерфейс программы представлен на рисунке 10.
Рисунок 10- Microsoft Office Word 2003.
Microsoft Power Point - программа для создания и проведения презентаций, являющаяся частью Microsoft Office и доступная в редакциях для операционных систем Интерфейс программы представлен на рисунке 11.
Рисунок 11- Microsoft Power Point.
Microsoft ICE Autopano Giga, Ulead Cool 360, The Panorama Factory, PTGui Pro в связи со своей простотой использования и тем, что она бесплатная. Чтобы объединить фотографии в панораму, достаточно просто переместить их в рабочую область программы и дальше программа действует автоматически. Интерфейс программы представлен на рисунке 12.
Рисунок 12 - Microsoft ICE.
Autopano Giga - Весь процесс при создании полностью автоматизирован: она сама откорректирует и сбалансирует яркость и цвет, подгонит фрагменты, автоматически найдет подходящие для склейки фотографии в указанной пользователем папке. Поддерживается немалое количество форматов (включая формат RAW). Интерфейс программы представлен на рисунке 13.
Рисунок 13 - Autopano Giga.
PTGui Pro - коммерческая (условно-бесплатная) компьютерная программа для создания панорамных фотоснимков, разработанная и поддерживаемая основанной в 1996 году нидерландской компанией New House Internet Services из Роттердама. Первоначально PTGui представляла собой графический интерфейс к комплекту бесплатных инструментов Panorama Tools (из чего следует и название программы), однако более поздние версии программы работают на собственном алгоритме сшивания фотографий. Интерфейс программы представлен на рисунке 14.
Рисунок 14 - PTGui Pro.
Microsoft Office SharePoint Designer 2007 - Программа проста в использовании и распространяется бесплатно. Программа обладает широким спектром возможностей, в частности, может автоматически отправлять изменения, внесённые разработчиком сайта в исходные тексты, в режиме реального времени. Интерфейс программы представлен на рисунке 15.
Рисунок 15 - Microsoft Office SharePoint Designer.
Pano2VR наиболее прост из других вариантов(Photo Warp, Tourweaver, Panorama2Flash, Pano2QTVR free, JATC, Easypano Studio Pro) широко известных программ с такими возможностями совсем немного, а безоговорочным лидером в данной сфере считается американская компания IPIX Corporation (http://www.ipix.com), являющаяся автором технологии виртуальных туров. Поэтому именно ее программные продукты чаще всего используются при разработке туров, в том числе и в России. Однако существуют весьма интересные альтернативные варианты от других компаний, которые тоже позволяют получить отличные результаты, но стоят гораздо меньше.
Easypano Studio Пакет включает два программных модуля: Panoweaver и Tourweaver. Первый из них -- это сшиватель сферических панорам 360Ѕ360, что возможно как в полностью автоматическом, так и в ручном режиме, а второй позволяет объединять панорамы, равно как и иную информацию, в виртуальных турах. Приложение Tourweaver может использоваться не только в связке с Panoweaver, но и автономно, так как в нем поддерживается импорт панорам, созданных в других сшивателях. Например, можно импортировать цилиндрические панорамы, полученные в Panorama Factory, или панорамы, сгенерированные в 3D-пакетах, в частности в 3D Studio Max. Кроме того, возможен импорт панорам с цифровых панорамных камер Kaidan"s 360 One VR, Panoscan, RoundShot и др. Интерфейс программы представлен на рисунке 16.
Рисунок 16 - 360 Degrees Of Freedom Developer Suite.
SP_VTB, SP_STITCHER - Компания Spherical Panorama специализируется на разработке программного обеспечения для создания разных типов панорам и объединения их в виртуальные туры, однако в нашем случае наибольший интерес представляют сшиватель снимков в панорамы SP_STITCHER и построитель виртуальных туров SP_VTB. Они поставляются как отдельные приложения, однако при разработке виртуальных туров дополняют друг друга, так как SP_VTB позволяет создавать туры только на основе панорам в формате spf, получаемых в среде SP_STITCHER. Оба приложения достаточно просты в применении, а прилагаемые к ним подробная документация, несколько fisheye-наборов для тестирования сшивания и пробный виртуальный тур позволят быстрее разобраться с тонкостями работы. Интерфейс программы представлен на рисунке 17.
Рисунок 17 - SP_VTB, SP_STITCHER.
IPIX Interactive Studio, IPIX Real Estate Wizard, IPIX i-Linker - В качестве приложений для создания виртуальных туров компания IPIX предлагает программные пакеты IPIX i-Linker 3.1 и IPIX Multimedia Toolkit, которые имеет смысл использовать только в связке с IPIX-сшивателем, так как оба приложения настроены на применение IPIX-панорам. В качестве программ для сшивания панорам могут быть задействованы пакеты IPIX Interactive Studio и IPIX Real Estate Wizard. Интерфейс программы представлен на рисунке 18.
Рисунок 18 - SP_VTB, SP_STITCHER.
Ну и собственно Pano2VR- программа для занимающихся производством виртуальных 3D панорам, новый продукт обеспечит все необходимые современные возможности представления контента на основе технологии Flash. Помимо пост-продакшн, Вы также можете производить текстурные преобразования (выбор большой) и создавать превью-картинки (thumbnail). Новый концепт переписан с нуля, добавлено огромное количество улучшений и возможностей. Хотя программа, как прежде, и поддерживает конвертацию в формат QTVR, все же основной упор в этой редакции был сделан на технологию Flash. Приложение, для преобразования сферических или цилиндрических панорамных изображений в форматы QuickTime VR (QTVR) или Adobe Flash 8 и Flash 9/10 (SWF). С возможностью создания собственных шаблонов для панорам, кнопок, добавления анимации и звука, автоматическим вращением. Интерфейс программы представлен на рисунке 19.
Рисунок 19 - Pano2VR.
Средства Pano2VR:
Patch Tool. Позволяет динамическое исправление исходного изображения. Вы можете выбрать область панорамы и экспортировать его в программное обеспечение для редактирования изображений. Поддерживает возможность редактирования только выделенных областей, которые должны быть исправлены и остальная часть изображения не затрагивается.
Skin Editor. Возможность создать свой собственный шаблон для панорамы. Вы можете добавить свои собственные кнопки и графику, дизайн. Вы также можете добавить анимацию и звуковые эффекты к вашему шаблону.
Sound Editor. Возможность добавления различных звуков в панорамы.
Flash Export. Экспорт панорам, включая все графические элементы в виде одного файла SWF формате. Это в значительной степени упрощает процесс размещения панорамы в системы управления контентом, или поместить ее в блоге. Цилиндрические, а также кубические панорамы можно поворачивать автоматически с выбором направления движения, скорости и задержки. Панорамы могут содержать "горячие точки", а также заранее определенные или полностью настраиваемые шаблоны. Встроенный редактор шаблонов, также позволяет добавлять карты, ссылки, логотипы и другую информацию в панораму в удобном для пользователя виде.
QuickTime VR Export. Возможность экспортировать цилиндрические и кубические панорамы в формат QuickTime VR.
Adobe Flash Player - это программа, благодаря которой и будет демонстрироваться экскурсия, возможны и другие варианты (Java-аплета, записываемые на CD, просматриваются с помощью специальных обозревателей экскурсий), но благодаря известности марки Adobe и широкому распространению Flash Player именно он и будет использоваться
Share Point Designer 2007 -WYSIWYG HTML- бесплатный редактор и программа для веб-дизайна от компании Microsoft, замена для Microsoft Office FrontPage и часть семейства SharePoint. Является одним из компонентов пакета Microsoft Office 2007, однако не включен ни в один из комплектов офиса (устанавливается отдельно). Переход в названии от FrontPage к SharePoint Designer связан с его назначением: созданием и дизайном веб-сайтов Microsoft SharePoint. SharePoint Designer имеет один и тот же движок обрисовки HTML, что и Microsoft Expression Web и не полагается на движок Trident браузера Internet Explorer, который менее совместим с общими стандартами.
Yandex Интернет - наиболее современный и поэтому более высокоскоростной и перспективный браузер. На нем будет проводиться тестирование экскурсии, выбор осуществлялся из множества вариантов: Google Chrome (рисунок 2), Chromium (рисунок 22), Хром от Яндекса (рисунок 23), Microsoft Internet Explorer (рисунок 24), Mozilla Firefox (рисунок 25), Opera (рисунок 26), Yandex (рисунок 20) и др.
Рисунок 20 - Yandex браузер.
Рисунок 21 - Google Chrome.
Рисунок 22 - Opera.
Рисунок 23 - Chromium.
Рисунок 24 - Хром от Яндекса.
Рисунок 25 - Internet Explorer.
Рисунок 26 - Mozilla Firefox.
Перечисленные ниже программы выбраны из списка инструментальных средств по причинам перечисленным ниже.
Обоснование выбора инструментальных средств разработки и программного
На основании исследования инструментальных средств разработки программного обеспечения в качестве инструментальных средств разработки виртуальной экскурсии по школе №2 будут использоваться:
Adobe Photoshop CS3 - способен работать с большим количеством форматов, создавать, сохранять, редактировать изменять изображения различными способами. Многофункциональный графический редактор, как нельзя кстати подойдёт для более точного результата объединения фотографий в панораму.
Microsoft ICE version 1.4.4.0 - программа нужна для объединения множества отдельных фотографий одного объекта с правильной последовательностью в одно панорамное изображение.
Pano2VR версия 4.1.0 pro - программа для объединения панорамы в экскурсии.
Adobe flash player 13 plugin - бесплатная программа для просмотра экскурсии.
Яндекс Интернет 14.4.1750.13414 - наиболее новый, удобный и быстрый браузер.
Share Point Designer 2007 - бесплатная программа для редактирования web страниц, HTML-редактор и программа для веб-дизайна от компании Microsoft, замена для Microsoft Office FrontPage и часть семейства SharePoint.
Microsoft Word - текстовый редактор и редактор документов. Поражает своей функциональностью и возможностью применения, он способен работать с различными форматами.
Microsoft Office PowerPoint - является частью Microsoft Office. Это позволило PowerPoint стать наиболее распространённой во всем мире программой для создания презентаций. Файлы презентаций PowerPoint часто пересылаются пользователями программы на другие компьютеры, что означает необходимую совместимость с ними программ конкурентов.
Выбранные средства разработки были исследованы и установлены на компьютер. Разработка программного обеспечения будет вестись с их помощью.
Технология программирования в целом и средства поддержки разработки ПО, в частности, развиваются настолько быстро, что даже простое перечисление основных инструментальных систем заняло бы в этой книге слишком много места. Вот почему ниже мы остановимся кратко лишь на нескольких проектах в области технологии программирования, которые интересны в контексте данного издания.
Любая развитая технологическая система должна поддерживать все основные этапы создания проектируемого программного комплекса. Для достижения этой цели в общей структуре типовой технологической системы поддержки разработки (рис. 6.3) обычно выделяют базу данных проекта; подсистему автоматизации проектирования и программирования; подсистемы отладки, документирования и сопровождения, а также подсистему управления ходом выполнения проекта.
Рис. 6.3. Общая структура типовой технологической системы поддержки разработки
Развитые библиотечные системы поддержки разработки используются в настоящее время во всем мире во всех сколько-нибудь серьезных программных проектах. Но в подавляющем большинстве случаев такие системы достигли уровня удобства работы с ними квалифицированных программистов. Нас же, прежде всего, интересуют системы и проекты, в которых имеются тенденции к эксплицитному представлению технологических знаний, даже если они и не базируются на идеях и методах ИИ.
Один из таких проектов - Gandalf - ориентирован на автоматизированную генерацию систем разработки программного обеспечения. Исследования, выполняемые в рамках проекта Gandalf, касаются трех аспектов поддержки проектирования ПО: управление проектом, контроль версий и инкрементное программирование, а также интеграция их в единую среду. Управление в Gandalf-среде базируется на предположении, что разрабатываемый проект должен трактоваться как множество абстрактных типов данных, над которыми могут выполняться лишь определенные операции. Средством, реализующим данную концепцию, явилась система SDC (Software Development Control), представляющая собой набор программ, первоначально реализованных на языке Shell в системе UNIX, а позднее переведенная на язык С.
Исследования в области контроля версий были начаты еще Л. Коопридером на базе проекта FAFOS , где изначально анализировались возможности создания семейства операционных систем. Была разработана нотация для описания взаимодействия между подсистемами, для описания различных версий подсистем (исходного и объектного кода, документации и т. п.) и для описания действующих на этапе разработки механизмов (компиляция, редактирование связей и т. п.). Затем был создан специальный язык Intercol как средство описания взаимосвязи и версий модулей в системе. И, наконец, в систему были встроены знания о том, как конструировать систему из частей, не заставляя заниматься этим пользователя. В развитие этих работ была создана система SUCE, в рамках которой отслеживались различия между реализациями (версиями, которые действительно дают код для ряда спецификаций) и композициями (версиями, определяющими новые подсистемы как группы существующих подсистем).
В системе LOIPE (Language-Oriented Incremental Programming Environment) инкрементная компиляция выполняется на уровне отдельной процедуры. Достоинством такого подхода является то, что при коррекции процедуры на уровне локальных объектов или типов перекомпилируется только она. Если же меняется спецификация, то перекомпилируются и все зависящие от нее процедуры. Пользовательский интерфейс с LOIPE-системой базируется на подсистеме синтаксически-ориентированного редактирования ALOE (A Language-Oriented Editor). Целью разработки этой подсистемы было исследование возможности создания и использования синтаксически-ориентированных редакторов в качестве базиса для сред программирования.
Анализ литературы последних лет по технологии программирования показывает, что новой ветвью в технологии промышленной разработки и реализации, сложных и значительных по объему систем программного обеспечения является CASE-технология (Computer Aided Software Engineering) .
Первоначально CASE-технология появилась в проектах создания промышленных систем обработки данных. Это обстоятельство наложило свой отпечаток и на инструментальные средства CASE-технологии, где самое серьезное внимание уделялось, по крайней мере, в ранних CASE-системах, поддержке проектирования информационных потоков. В настоящее время наблюдается отход от ориентации на системы обработки данных, и инструментальные средства CASE-технологии становятся все более универсальными.
Все средства поддержки CASE-технологии делятся на две большие группы: САSE-Toolkits и CASE-Workbenches. Хороших русских эквивалентов этим терминам нет. Однако первые часто называют «инструментальными сундучками» (пакетами разработчика, технологическими пакетами), а вторые - «станками для производства программ» (технологическими линиями).
По определению CASE-Toolkit - коллекция интегрированных программных средств, обеспечивающих автоматическое ассистирование в решении задач одного типа в процессе создания программ.
Такие пакеты используют общее «хранилище» для всей технической и управляющей информации по проекту (репозиторий), снабжены общим интерфейсом с пользователем и унифицированным интерфейсом между отдельными инструментами пакета. Как правило, CASE-Toolkit концентрируются вокруг поддержки разработки одной фазы производства программ или на одном типе прикладных задач.
Все вышесказанное справедливо и по отношению к CASE-WorkBench. Но здесь, кроме того, обеспечивается автоматизированная поддержка анализа решаемых задач по производству программного обеспечения, которая базируется на общих предположениях о процессе и технологии такой деятельности; поддерживается автоматическая передача результатов работ от одного этапа к другому, начиная со стадии проектирования и кончая отчуждением созданного программного продукта и его сопровождением.
Таким образом, CASE-WorkBench является естественным «замыканием» технологии разработки, реализации и сопровождения программного обеспечения.
В настоящее время «типовая» система поддержки CASE-технологии имеет функциональные возможности, представленные на рис. 6.4.
Рис. 6.4. Функциональные возможности типовой системы поддержки CASE-технологии
Как следует из этой Н-диаграммы, в CASE-среде должны поддерживаться все основные этапы разработки и сопровождения процессов создания программных систем. Однако уровень такой поддержки существенно различен. Так, например, если говорить об этапах анализа и проектирования, большинство инструментальных пакетов поддерживает экранные и отчетные формы, создание прототипов, обнаружение ошибок. Значительная часть этих средств предназначена для ПЭВМ. Многие поддерживают такие широко используемые методологии, как структурный анализ DeMarco или Gane/Sarson, структурное проектирование Yourdan/Jackson и некоторые другие. Существуют специализированные пакеты разработчиков для создания информационных систем, например Ana Tool (Advanced Logical Software) для Macintosh; CA-Universe/Prototype (Computer Associates International) для ПЭВМ. Имеются CASE-среды и для поддержки разработки систем реального времени.
В среде разработчиков ПО существуют две оценки данного подхода: часть из них считает, что CASE-технология кардинально меняет процессы разработки и эксплуатации ПО, другие отрицают это и оставляют за инструментальными средствами CASE лишь функцию автоматизации рутинных работ . Однако анализ литературы показывает, что CASE средства все-таки «сдвигают» технологии разработки ПО с управления выполнением проектов в сторону метода прототипизации. И этот сдвиг, на наш взгляд, чрезвычайно важная тенденция в современной технологии программирования.
Технологический раздел
Технология разработки программного обеспечения
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 строк есть возможность проверить, если не все, то, по крайней мере, многие логические ветви в реализации, разные пути в графе зависимости данных, граничные значения параметров. В соответствии с этим строятся критерии тестового покрытия (покрыты все операторы, все логические ветви, все граничные точки и т.п.).
Полностью реализованный программный продукт подвергается системному тестированию. На данном этапе тестировщика интересует не корректность реализации отдельных процедур и методов, а вся программа в целом, как ее видит конечный пользователь. Основой для тестов служат общие требования к программе, включая не только корректность реализации функций, но и производительность, время отклика, устойчивость к сбоям, ошибкам пользователя и т.д. Для системного и компонентного тестирования используются специфические виды критериев тестового покрытия (например, покрыты ли все типовые сценарии работы, все сценарии с нештатными ситуациями, попарные композиции сценариев и прочее).
Итак, качество ПС – совокупность наиболее существенных качественных показателей (факторов) в достаточной степени характеризующих ПС. К общим факторам относят :
Функциональность – как набор функций, реализующих установленные или предполагаемые потребности пользователей;
Корректность – соответствие реализации системы ее спецификации и непротиворечивости;
Интерфейс – как средство общения с пользователями системы;
Открытость – характеризующая модифицируемость системы;
Комфортность – характеризующая удобность использования ПС;
Современность - характеризующая степень использования современных информационных технологий представления информации и систем связи на текущий момент времени.
Необходимо также отметить, что проверка достоверности ПС – процесс проведения комплекса мероприятий, исследующих пригодность программы для успешной её эксплуатации (применения и сопровождения) в соответствии с требованиями заказчика.
На основе информации, полученной во время испытаний программы, прежде всего должно быть установлено, что она выполняет декларированные функции, а также должно быть установлено, в какой степени она обладает декларированными примитивами и критериями качества. Таким образом, оценка качества программы является основным содержанием процесса аттестации.
Необходимость и важность тестирования программного обеспечения трудно переоценить. Вместе с тем следует отметить, что тестирование является сложной и трудоемкой деятельностью. Далее рассмотрены особенности тестирования объектно-ориентированного программного обеспечения.
Разработка объектно-ориентированного ПО начинается с создания визуальных моделей, отражающих статические и динамические характеристики будущей системы. Вначале эти модели фиксируют исходные требования заказчика, затем формализуют реализацию этих требований путем выделения объектов, которые взаимодействуют друг с другом посредством передачи сообщений. На конструирование моделей приходится большая часть затрат объектно-ориентированного процесса разработки. Если к этому добавить, что цена устранения ошибки стремительно растет с каждой итерацией разработки, то совершенно логично требование тестировать объектно-ориентированные модели анализа и проектирования.
Критерии тестирования моделей: правильность, полнота, согласованность. О синтаксической правильности судят по правильности использования языка моделирования. О семантической правильности судят по соответствию модели реальным проблемам. Для определения того, отражает ли модель реальный мир, она оценивается экспертами, имеющими знания и опыт в конкретной проблемной области.
О согласованности судят путем рассмотрения противоречий между элементами в модели. Несогласованная модель имеет в одной части представления, которые противоречат представлениям в других частях модели.
При рассмотрении объектно-ориентированного тестирования наименьшим тестируемым элементом является объект (класс). В данном случае нельзя тестировать отдельную операцию изолированно, как это принято в стандартном подходе к тестированию модулей. Любую операцию приходится рассматривать как часть класса. Объектно-ориентированное программное обеспечение не имеет иерархической управляющей структуры, поэтому здесь неприменимы методики как восходящего, так и нисходящего тестирования.
Предлагается две методики тестирования объектно-ориентированных систем:
Тестирование, основанное на потоках;
Тестирование, основанное на использовании.
В первой методике объектом тестирования является набор классов, обслуживающих единичный ввод данных в систему. Иными словами, средства обслуживания каждого потока интегрируются и тестируются отдельно. По второй методике вначале тестируются независимые классы. Далее работают с первым слоем зависимых классов, со вторым слоем и т.д.
При проверке правильности исчезают подробности отношений классов. Как и традиционное подтверждение правильности, подтверждение правильности объектно-ориентированного программного обеспечения ориентировано на видимые действия пользователя и распознаваемые пользователем выводы из системы.
Похожая информация.
Предмет: Технология разработки программных продуктов.
Тема:Инструментальные средства коллективной разработки программного обеспечения.
Образовательная
Ознакомление с инструментальными средствами коллективной разработки ПО.
Развивающая:
Развивать умение слушать других, делать выводы и обобщать полученные знания
Воспитательная:
Воспитывать чувство значимости предмета в профессиональной деятельности, аккуратности в работе
Межпредметные связи:
Английский язык
Операционные системы
Информационные технологии
Основы алгоритмизации и программирования
Оборудование: доска, мел, письменные принадлежности, проектор, ПК
Тип урока: комбинированный
Метод обучения: Объяснительно иллюстративный
Ход урока:
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.
Так же как и в случае с выбором языка программирования, выбор среды программирования определяется характеромпроекта, привычками и навыками разработчика, веяниями времени, требованиями заказчика и просто общественным мнением: «Все подобные разработки должны выполняться в среде...