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

Сущность и понятие инструментального программного обеспечения

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

Применяется инструментальное обеспечение в фазе разработки. Инструментальное программное обеспечение - это совокупность программ, используемых для помощи программистам в их работе, для помощи руководителям разработки программного обеспечения в их стремлении проконтролировать процесс разработки и получаемую продукцию. Наиболее известными представителями этой части программного обеспечения являются программы трансляторов с языков программирования, которые помогают программистам писать машинные команды. Инструментальными программами являются трансляторы с языков Фортран, Кобол, Джо-виал, Бейсик, АПЛ и Паскаль. Они облегчают процесс создания новых рабочих программ. Однако трансляторы с языков это только наиболее известная часть инструментальных программ; существует же их великое множество.

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

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

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

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

3. Редактор связей или сборщик, который выполняет связывание объектных модулей и формирует на выходе работоспособное приложение - исполнимый код.

Исполнимый код - это законченная программа, которую можно запустить на любом компьютере, где установлена операционная система, для которой эта программа создавалась. Как правило, итоговый файл имеет расширение.ЕХЕ или.СОМ.

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

Наиболее популярные редакторы (системы программирования программ с использованием визуальных средств) визуального проектирования:

Borland Delphi - предназначен для решения практически любых задачи прикладного программирования.

Borland C++ Builder - это отличное средство для разработки DOS и Windows приложений.

Microsoft Visual Basic - это популярный инструмент для создания Windows-программ.

Microsoft Visual C++ - это средство позволяет разрабатывать любые приложения, выполняющиеся в среде ОС типа Microsoft Windows

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

Задачи и функции инструментального программного обеспечения

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

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

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

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

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

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

Виды инструментального программного обеспечения

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

Текстовые редакторы

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

Компиляторы

Интерпретаторы

Линковщики

Парсеры и генераторы парсеров (см. Javacc)

Ассемблеры

Отладчики

Профилировщики

Генераторы документации

Средства анализа покрытия кода

Средства непрерывной интеграции

Средства автоматизированного тестирования

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

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

Текстовые редакторы.

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

Состав САПР

САПР - система, объединяющая технические сред­ства, математическое и программное обеспечение, пара­метры и характеристики которых выбирают с максималь­ным учетом особенностей задач инженерного проектиро­вания и конструирования. В САПР обеспечивается удоб­ство использования программ за счет применения средств оперативной связи инженера с ЭВМ, специальных проб­лемно-ориентированных языков и наличия информаци­онно-справочной базы.

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

По назначению подсистемы САПР разделяют на два вида: проектирующие и обслуживающие.

К проектирующим относятся подсистемы, выполняю­щие проектные процедуры и операции, например:

· подсистема компоновки машины;

· подсистема проектирования сборочных единиц;

· подсистема проектирования деталей;

· подсистема проектирования схемы управления;

· подсистема технологического проектирования.

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

· подсистема графического отображения объектов про­ектирования;

· подсистема документирования;

· подсистема информационного поиска и др.

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

· объектно-ориентированные (объектные);

· объектно-независимые (инвариантные).

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

· подсистема проектирования технологических систем;

· подсистема моделирования динамики, проектируемой конструкции и др.

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

· подсистема расчетов деталей машин;

· подсистема расчетов режимов резания;

· подсистема расчета технико-экономических показа­телей и др.

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

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

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

· лингвистическое обеспечение - языки проектирова­ния, терминология;

· математическое обеспечение - методы, математические модели, алгоритмы;

· программное обеспечение - документы с текстами про­грамм, программы на машинных носителях и эксплуата­ционные документы;

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

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

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

· 64 CALS-технологии .

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

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

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

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

Опыт, накопленный в процессе внедрения разнообразных автономных информационных систем, позволил осознать необходимость интеграции различных информационных технологий в единый комплекс, базирующийся на создании в рамках предприятия или группы предприятий (виртуального предприятия) интегрированной информационной среды, поддерживающей все этапы жизненного цикла выпускаемой продукции. Профессиональная среда наиболее полно раскрывает возможности для профессионального совершенствования, используя новые информационные технологии в науке и в сфере управления производственными процессами. Инновационные технологии в области индустрии переработки информации с внедрением CALS-(Continuous Acquisition and Life cycle Support) технологии – непрерывной информационной поддержки жизненного цикла проектируемого объекта, переводит автоматизацию управления производственными процессами на новый уровень.

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

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

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

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

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

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

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

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

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

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

САПР – что это?

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

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

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

Таким образом, можно выделить широкую и более узкую трактовку термина, о котором идет речь. Тяжело сказать, какая из этих трактовок чаще применяется в бизнесе. Все зависит от конкретной сферы использования систем автоматизированного проектирования, а также от тех задач, для решения которых предполагается применять данные системы. Так, например, в контексте отдельно взятого цеха на производстве, под САПР предполагается конкретная программа для автоматизированного проектирования. Если речь идет о стратегическом планировании развития организации, то такое понятие как САПР скорее всего будет соответствовать масштабной инфраструктуре, которая задействуется с целью повышения эффективности разработки различных проектов. Необходимо отметить, что сам термин САПР представляет собой аббревиатуру, которая может расшифровываться по-разному. В общем случае данная аббревиатура соответствует сочетанию слов «система автоматизированного проектирования». Также существуют и другие варианты расшифровки данной аббревиатуры. Например, довольно распространен вариант «система автоматизации проектных работ». По смыслу английским аналогом термина САПР является аббревиатура CAD, в некоторых случаях также используется CAX.Давайте более подробно рассмотрим следующий вопрос: в каких целях могут создаваться системы автоматизированного проектирования в машиностроении и других сферах?

САПР: цели создания

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

Снижения трудоемкости процесса проектирования;

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

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

Обеспечение повышения качества инфраструктуры проектирования.

Снижение издержек на проведение испытаний и моделирование.

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

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

Автоматизация документации;

Применение концепций параллельного проектирования;

Унификация различных решений;

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

Оптимизация методов проектирования;

Повышение качества процессов управления бизнесом.

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

САПР: классификации

К наиболее распространенным критериям классификации САПР относится отраслевое назначение. Выделяют следующие типы:

1. Автоматизированное проектирование инфраструктуры машиностроения;
2. САПР для электронного оборудования;
3. САПР в сфере строительства.

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

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

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

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

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

Системы, используемые с целью разработки различных чертежей;

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

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

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

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

Данная классификация считается условной.

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

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

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

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

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

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

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

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

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

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

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

редакторы,·

анализаторы,·

преобразователи,·

инструменты, поддерживающие процесс выполнения программ.

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

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

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

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

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

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

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

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

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

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

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

Для таких инструментальных сред характерно,

во-первых, использование как программных, так и аппаратных инструментов, и,

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

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

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

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

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

(рис. 16.1): ·

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

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

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

Среда программирования предназначена

в основном для поддержки процессов программирования (кодирования), тестирования и отладки ПС.

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

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

Для таких систем стоимость сопровождения обычно превышает стоимость разработки.

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

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

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

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

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

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

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

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

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

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

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

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

Такие среды разделяются на два подкласса: ·

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

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

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

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

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

Имеются некоторые трудности в выработке строгого определения CASE-технологии (компьютерной технологии разработки ПС).

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

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

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

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

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

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

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

Программной поддержки прототипирования.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разработка спецификаций распадается на несколько разных процессов.

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

Автоматизированный контроль спецификаций

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

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

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

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

комплексность, ·

ориентированность на коллективную разработку, ·

технологическая определенность, ·

интегрированность.

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

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

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

Интегрированность компьютерной поддержки означает:

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

Интегрированность по пользовательскому интерфейсу,

Интегрированность по действиям (функциям),

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

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

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

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

база данных разработки (репозиторий),·

инструментарий, ·

интерфейсы.

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

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

Интерфейсы разделяются на

1)пользовательский

2) системные.

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

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

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

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

1)инструментальные системы поддержки проекта и

2) языково-зависимые инструментальные системы.

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

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

Примером такой системы является среда поддержки программирования на Аде (APSE ).

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

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) – для моделирования физической архитектуры системы.

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

Введение

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

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

Этапы, роли, инструменты…

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

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

Определение требований

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

Какие инструменты требуются бизнес-аналитику? Потребность в инструментах определяется масштабом проекта, требованиями заказчика к оформлению документации, стандартами, принятыми в той или иной компании-разработчике. Бизнес-аналитик может обойтись и текстовым процессором (например, Microsoft Word), изложив требования в виде текста. Однако в последнее время описание требований принято иллюстрировать UML- и IDEF0-диаграммами, описывающими сценарии взаимодействия пользователя с продуктом, порядок передачи сообщений от одних объектов к другим, взаимодействие объектов друг с другом, потоки работ и изменение состояний объектов. Для создания таких диаграмм можно применять Microsoft Visio, Rational Rose, Rational XDE, Borland Together, для создания диаграмм в стандарте IDEF0 наиболее активно используется CA AllFusion Process Modeler (ранее носивший название BPwin).

Какой именно инструмент подходит для данного проекта, во многом зависит от постановки процессов разработки. Если бизнес-аналитику нужно только проиллюстрировать проектную документацию, то выбор инструмента не принципиален - лишь бы можно было нарисовать с его помощью ту или иную диаграмму. Если же бизнес-аналитик должен не просто сделать иллюстрацию, а создать модель для последующего использования системными аналитиками, разработчиками и специалистами по тестированию на последующих этапах проекта, то выбор инструмента определяется его способностью к интеграции со средствами разработки, которые со значительной степенью вероятности будут использоваться в качестве инструментария реализации кода. Из наиболее технологически совершенных современных пар «средство разработки - средство моделирования» стоит отметить такие, как Visual Studio .NET - Rational XDE, Visual Studio .NET - Borland Together, Borland JBuilder - Borland Together.

Помимо текстовых редакторов и средств моделирования, бизнес-аналитики могут применять средства управления требованиями, позволяющие хранить структурированный и систематизированный список требований к продукту в какой-либо базе данных и обращаться к нему на последующих этапах, связывая требования с реализующими их составными частями продукта и тестами, проверяющими соответствие продукта требованиям, а также корректно отслеживать изменения в требованиях, которые возникают практически в каждом проекте, как бы тщательно ни проводилось исследование, и влияние этих изменений на результаты последующей работы. Из наиболее известных сегодня средств управления требованиями следует отметить RequisitePro (IBM/Rational), DOORS (Telelogic) и CaliberRM (Borland). Собственно, при надлежащей организации процесса разработки и при наличии необходимых шаблонов техническое задание можно сгенерировать с помощью средства управления требованиями и даже соблюсти при этом требования российских государственных стандартов.

Типичный интерфейс средства управления требованиями (Borland Caliber RM)

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

Проектирование

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

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

Какие инструменты применяются на этом этапе? Для создания диаграмм классов и диаграмм развертывания используются вышеперечисленные инструменты UML-моделирования. Для проектирования данных обычно применяют такие инструменты, как CA AllFusion Data Modeler (бывший ERwin), Sybase Power Designer, Oracle Designer, а также аналогичные инструменты компаний Embarcadero и Popkin Software. Для СУБД, разработанных компанией Microsoft, можно достаточно успешно применять и Microsoft Visio. Перечисленные инструменты позволяют создать как минимум скрипт для генерации базы данных, а различия между ними заключаются в способах управления генерацией серверного кода, связанного с созданием триггеров и хранимых процедур.

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

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

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

Разработка продукта

На этапе собственно разработки создается код приложения в соответствии с техническим проектом, в том числе и серверный код, реализующий функциональность, отсутствующую в модели данных. На этом этапе основным инструментом, обязательным к применению, является средство разработки приложений. Выбор средства разработки определяется в первую очередь платформой (Windows, .NET, Java/J2EE, Linux/UNIX) и архитектурой (приложения с графическим интерфейсом, консольные приложения и службы, Web-приложения) и в настоящее время достаточно разнообразен. Средства разработки Java/J2EE-приложений производят компании IBM, Oracle, Borland, средства разработки Windows-приложений - Microsoft, Borland, Sybase, средства разработки.NET-приложений - Microsoft и Borland, средства разработки приложений для Linux - Borland и некоторые другие компании.

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

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

На этапе разработки приложения средства моделирования тоже применяются, особенно в том случае, когда они могут осуществлять не только генерацию кода на различных языках программирования, но и поддерживать обратное проектирование, создавая диаграмму классов на основе готового приложения либо позволяя синхронно редактировать и код, и модель. Функция синхронного изменения кода и модели существенно упрощает многие процессы, сопровождающие собственно разработку, так что если есть возможность выбора инструментов, то стоит обратить внимание на ее поддержку (например, синхронное изменение кода и модели поддерживают некоторые редакции инструмента UML-моделирования Borland Together).

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

Тестирование и оценка качества

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

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

Основными производителями средств тестирования в настоящее время являются компании Compuware, Segue, Mercury Interactive, IBM/Rational, Borland. Каждая из них производит несколько инструментов автоматизированного тестирования, включая средства нагрузочного тестирования, проверки пользовательских интерфейсов, тестирования ошибок исполнения.

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

Если приложение предназначено для работы под управлением различных операционных систем и их языковых версий (например, разных 32-разрядных версий и редакций Microsoft Windows), то специалистам по тестированию могут пригодиться средства создания виртуальных машин, позволяющие иметь на одном компьютере несколько различных операционных систем, загруженных одновременно, и организовывать между ними сетевое взаимодействие (о продуктах данной категории мы планируем рассказать в отдельной статье). Из ПО такого класса широко распространены продукты компаний Microsoft и VMWare. При тестировании программ для установки приложений могут применяться также средства резервного копирования и восстановления образов жестких дисков, выпускаемые компаниями Symantec, PowerQuest и др.

Документирование

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

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

На основе руководства пользователя с помощью специальных инструментов обычно генерируются файлы справочной системы. В простейшем случае файл справочной системы можно создать с помощью Microsoft Word и утилит от Microsoft для создания help-файлов, включаемых в состав многих средств разработки, но при большом объеме работы нередко используются специализированные средства таких компаний, как Blue Sky Software, EC Software, JGsoft.

Внедрение и сопровождение

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

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

Коллективная разработка и управление проектом

Если над какой-либо частью проекта работает более одного человека, полезными при разработке могут оказаться средства контроля версий (наиболее популярными из них являются Merant PVCS Version Manager и Microsoft Visual SourceSafe). Нередко их применяют при создании не только кода приложения, но и документов (например, технического задания) либо моделей. В крупных проектах часто используются и средства управления изменениями. Подобные продукты позволяют хранить в единой базе данных все составные части проекта и их версии и упрощают управление версиями кода, моделей, требований, а также дают возможность отслеживать влияние изменений в одной части проекта на остальные его части. Из самых популярных сегодня средств управления изменениями следует отметить продукты компаний Borland и IBM/Rational.

Ни один проект не обходится без человека, несущего за него ответственность и осуществляющего планирование деятельности всех специалистов и управление всеми процессами разработки. Хотя планировать работу можно и на бумаге, но в последнее время основным инструментом руководителя проекта (а в крупных проектах - менеджеров, отвечающих за составные части проекта) служит какое-либо специализированное средство управления проектами. Лидером среди продуктов данной категории является семейство продуктов Microsoft Project.

Пример плана проекта разработки программного продукта (Microsoft Project)

Заключение

еречисляя инструменты, которые могут понадобиться при разработке приложений, мы, естественно, назвали не все возможные варианты. В одних проектах могут потребоваться генераторы отчетов, в других - средства для работы с графикой, в третьих - инструменты Web-дизайна, в четвертых - CAD- или ГИС-инструменты. При этом, как мы убедились, в самых простых случаях можно обойтись средством разработки и текстовым редактором - этот набор может оказаться достаточно эффективным, если проект не слишком крупный.

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

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

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

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 строк есть возможность проверить, если не все, то, по крайней мере, многие логические ветви в реализации, разные пути в графе зависимости данных, граничные значения параметров. В соответствии с этим строятся критерии тестового покрытия (покрыты все операторы, все логические ветви, все граничные точки и т.п.).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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