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

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

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

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

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

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. САПР в сфере строительства.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CASE-средства. Характеристика современных CASE-средств

Обзор объектно-ориентированных инструментальных средств

Объектно-ориентированное программирование возникло раньше объектно-ориентированного анализа и проектирования, поэтому на сегодняшний день существует достаточно большое количество языков, поддерживающих данную технологию. Первым из них, по дате возникновения, считается язык Smalltalk , хотя многие элементы объектно-ориентированного подхода были использованы еще в языке Simula в 1967г. Наиболее мощным инструментом создания объектно-ориентированных программ на сегодня является язык C++ , созданный на базе языка структурного программирования C . Успешно развивается язык Java , который изначально разрабатывался как объектно-ориентированный.

Разработка крупных программных систем в современных условиях невозможна без использования средств автоматизации разработки программного обеспечения (CASE средств). CASE, поддерживающих объектно-ориентированный подход, не так много. Наиболее известное средство в этом направлении – система Rational Rose , которая поддерживает, в том числе, этапы объектно-ориентированного анализа и проектирования.

Объектно-ориентированное CASE средство Rational Rose

Разработчик Rational Rose - фирма Rational Software Corp., известная своими наработками в области объектно-ориентированных технологий, главной из которых является язык UML. Именно на поддержку UML, как основного языка проектирования ПО, и ориентированна данная CASE система.

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

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

Из основных возможностей можно перечислить следующие:

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

Удобная навигация между элементами модели при помощи "инспектора проекта".

Хранение результатов проектирования в виде единой модели.

Поддержка работы над проектом группы разработчиков.

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

Возможности синтеза программ практически на всех современных объектно-ориентированных языках, в том числе и на межплатформенном языке Java.

Поддержка компонентных технологий построения программных систем.

Широкие возможности по проектированию ПО различной архитектуры, от простых программ, до крупных "клиент-серверных" систем и Интернет-приложений.

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

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

Принципы разработки программных систем в Rational Rose

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

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

На всех этапах предоставляется возможность применять специализированные графические редакторы элементов модели и использовать инспектор модели для навигации среди ее компонентов. Вся проектная информация сохраняется в едином файле модели (*.mdl).

Работа начинается с построения диаграммы использования (Use Case Diagram), характеризующей основные задачи и окружение проектируемой системы. Далее, для каждого блока использования (Use Case), представленного на диаграмме использования, разрабатываются диаграммы последовательностей (Sequence Diagram), идентифицирующие объекты в системе и описывающие последовательности событий, возникающих в процессе общения объектов. Rational Rose позволяет автоматически связывать диаграммы последовательностей с блоками использования.

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

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

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

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

Проектирование программных средств

Моделирование предметной области . Создание проекта начинается с формирования принципов использования системы. В рамках Rational Rose это этап именуется "Use Case View". Реализация этого этапа позволяет идентифицировать внешних пользователей, блоки использования, объекты системы и связи между ними.

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

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

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

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

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

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

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

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

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

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

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

Кроме диаграмм классов, для описания логики системы применяются на данном этапе применяются диаграммы состояний, диаграммы сценариев и другие элементы языка UML

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

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

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

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

Построение диаграмм выполняется в специализированном редакторе. Для компонента задаются составляющие его классы.

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

Последним этапом в проектировании программного обеспечения является подготовка диаграммы развертывания. В Rose этот этап именуется "Deployment View". Диаграммы развертывания показывает конфигурацию исполняемой программной системы. Она состоит из узлов и отношений взаимодействия между узлами и компонентами. Узлы могут включать компоненты и объекты. Узлы являются физическими элементами времени выполнения.

Построение и сопровождение системы

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

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

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

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

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

Rational Rose 98 Enterprise Edition позволяет генерировать исходный текст на Visual Basic, C++, Java, а также получать описание интерфейсов компонент на языке IDL и создавать проекты для системы Oracle 8.

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

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

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

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

Поддержка этапов разработки

Компоненты и шаблоны. Одной из возможностей Rose является моделирование двоичных компонентов, поддерживающих спецификацию COM. В модели подобные компоненты представляются интерфейсными классами, созданными на основе IDL файлов, сопровождающих COM объект. Это позволяет включать в модель различные готовые компоненты.

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

Рабочие среды. Логичным развитием идеи использования шаблонов и внешних двоичных компонентов в Rational Rose стало появление рабочей среды (Framework).

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

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

Среда проектирования распределенных приложений (Application Performance Explorer)

Стандартная среда (Standard). Ориентированна на создание приложений на Visual Basic. Включает объявление многих стандартных объектов VB.

Среда проектирования приложений для Интернет (Internet). Включает определение различных компонентов ActiveX и библиотек VB.

Среда проектирования приложений для работы с локальными базами данных (Local Database). Содержит объявление объектов системы DAO

Среда проектирования приложений с использованием RDO (Remote Data Object). Позволяет использовать объекты RDO для создания клиент-серверных приложений.

Среда проектирования приложений для доступа к SQL-серверами (SQL Server Distributed Management Object (SQL-DMO)), поддерживающая доступ к SQL через объекты OLE-Automation.

Среда поддержки Microsoft Transaction Server

Среда поддержки Microsoft Outlook

Среды проектирования приложений на Java (Java JDK 114 Full и Java JDK 114 Quick). Включают модели классов и интерфейсов Java полученные путем реинжиниринга.

Среда поддержки Oracle8

Среда разработки назначается при создании модели. Хранятся среды разработки в виде файлов модели (*.mdl) предназначенных только для чтения (Read only). В процессе создания новой модели необходимые элементы загружаются из выбранной среды разработки, после чего новую модель.

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

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

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

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

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

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

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

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

Достоинства и недостатки Rational Rose

Данное CASE средство может быть применено для создания разнообразного объектно-ориентированного программного обеспечения, в первую очередь для платформы Windows, а так же на межплатформенном языке Java.

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

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

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

Этап 1: до середины 50-х .

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

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

Этап 2: середина 50-х – середина 60-х гг.

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

Fortran (1954-1957);

Algol-60 (1958-1960);

Cobol (1959-1961);

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

Этап 3: середина 60-х – начало 70-х гг.

Резко увеличиваются размеры ПО, происходит переход к коллективному характеру работ. Повышаются требования к ПО вследствие перехода к товарному производству.

Изменяется соотношение затрат на разработку ПО (40% и более тратится на отладку, проектирование и документирование), кодирование – один из самых простых видов работ. Используются и создаются "большие" языки программирования – ПЛ/1, АЛГОЛ-68, СИМУЛА-67, обобщающие и интегрирующие ранее найденные решения.

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

Этап 4 (“этап кризиса в развитии ПО”): начало 70-х–середина 70-х гг.

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

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

Этап 5:1976г.– наше время. Этап посткризисного развития инструментальных средств.

1976г. – публикация работы Боэма, где вводится понятие жизненного цикла ПО и указывается, что основные затраты приходятся не на разработку, а на сопровождение программ.

Языки программирования:

C (начало 1970-х, впервые достаточно полно описан в 1978 г.);

Modula-2 (1978 г., развитие – язык Oberon (1988));

Prolog (1972 г., распространение получил с 1980 г.);

Smalltalk (1970-е годы, в 1980 был представлен как Smalltalk-80);

C++ (начало 1980-х гг., название – 1983, в привычном сегодня виде существует с 1990 г.);

Java (версия Java 1.0 – 1996 г., Java 2.0 – 1998, Java 5 – 2004...);

C# (1998–2001, версия 1.0 – 2000–2002, версия 2.0 – 2003-2005, версия 3.0 – 2004–2008, версия 4.0 – 2008–2010).

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

Контрольные вопросы:

1. Какие действия включает в себя разработка программного продукта?

2. Какие этапы в разработке программ выделяются в рамках Rational Unified Process (RUP)?

3. Что обеспечивает использование инструментальных средств?

4. Какие составные части входят в программу? Назначение каждой из частей.

5. Определения программы и программного обеспечения.

6. Какими свойствами должно обладать программное обеспечение?

7. Какие языки программирования применяют при разработке программ?

8. Определение инструментального программного обеспечения.

9. На какие четыре группыможно разбить инструментальное ПО? Примеры ПО для каждой группы.

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

11. Какие этапы выделяют в развитии инструментальных средств разработки ПО?

12. Назначение и основные характеристики компиляторов (ассемблеров) и редакторов связей.

13. Назначение и основные характеристикиредакторов текстов.

14. Назначение и основные характеристикиотладчиков.

15. Назначение и основные характеристикипрограмм создания инсталляторов.

16. Назначение и основные характеристикиредакторов ресурсов.

17. Назначение и основные характеристикипрофилировщиков.

18. Назначение и основные характеристикипрограмм поддержки версий.

19. Назначение и основные характеристикипрограмм создания файлов помощи (документации).

20. Назначение и основные характеристикигенераторов документации.

21. Назначение и основные характеристикидизассемблеров и декомпиляторов.

22. Назначение и основные характеристикипрограмм отслеживания активности системы и изменений, происходящих в системе.

23. Назначение и основные характеристикипрограмм-вериферов и контейнеров.

24. Назначение и основные характеристики программ для защиты разрабатываемого программного обеспечения (протекторов).

25. Назначение и основные характеристикиSDK.

26. Назначение и основные характеристики парсеров.

27. Назначение технологических стандартов.

ТЕМА: Методологии разработки ПО.

Литература: 1. Зелковиц М., Шоу А., Гэннон Дж. Принципы разработки программного обеспечения.

2. Гецци К., Джазайери М., Мандриоли Д. Основы инженерии программного обеспечения.

3. Камаев В. А., Костерин В. В. Технологии программирования.

Рассмотрим понятия методологии, метода и средства.

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

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

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

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

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

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

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

Водопадные (каскадные);

Итерационные (спиральные).

Также существует и более общая классификация на:

Прогнозируемые;

Адаптивные.

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

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

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

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

Рис. 1. Каскадная модель жизненного цикла.

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

Преимущества применения каскадного способа:

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

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

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

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

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

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

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

Рис. 2. Каскадная модель ЖЦ на практике.

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

Для преодоления перечисленных проблем в середине 80-х годов была предложена спиральная модель жизненного цикла (рис.3).

Рис. 3. Спиральная (итерационная) модель ЖЦ.

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

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

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

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

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

1. Планирование - определение целей, вариантов и ограничений.

2. Анализ риска - анализ вариантов и распознавание/выбор риска.

3. Конструирование - разработка продукта следующего уровня.

4. Оценивание - оценка заказчиком текущих результатов конструирования.

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

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

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

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

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

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

Достоинства спиральной модели:

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

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

Включает шаг системного подхода в итерационную структуру разработки;

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

Недостатки спиральной модели:

Новизна (отсутствует достаточная статистика эффективности модели);

Повышенные требования к заказчику;

Трудности контроля и управления временем разработки.

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

Rational Unified Process (RUP)

Гибкие методологии разработки (SCRUM, KANBAN, DSDM, MSF, ALM, XP)

Гибкая методология разработки (англ. Agile software development).

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

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

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

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

KANBAN – гибкая методология разработки программного обеспечения, ориентированная на задачи.

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

Визуализация разработки:

o разделение работы на задачи;

o использование отметок о положение задачи в разработке;

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

Измерение времени цикла (среднее время на выполнение одной задачи) и оптимизация процесса.

Преимущества KANBAN:

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

Быстрое выявление проблемных задач;

Вычисление времени на выполнение усредненной задачи.

DYNAMIC SYSTEM DEVELOPMENT METHOD (DSDM) появился в результате работы консорциума из 17 английских компаний. Целая организация занимается разработкой пособий по этой методологии, организацией учебных курсов, программ аккредитации и т.п. Кроме того, ценность DSDM имеет денежный эквивалент.

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

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

Базовые принципы, на которых строится DSDM:

Активное взаимодействие с пользователями;

Частые выпуски версий;

Самостоятельность разработчиков в принятии решений;

Тестирование в течение всего цикла работ.

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

MICROSOFT SOLUTIONS FRAMEWORK (MSF) - методология разработки программного обеспечения, предложенная корпорацией Microsoft. MSF опирается на практический опыт Microsoft и описывает управление людьми и рабочими процессами в процессе разработки решения.

Базовые концепции и принципы модели процессов MSF:

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

Управление компромиссами - поиск компромиссов между ресурсами проекта, календарным графиком и реализуемыми возможностями;

Гибкость – готовность к изменяющимся проектным условиям;

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

Поощрение свободного общения внутри проекта;

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

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

Application Lifecycle Management (ALM) - разработанная и поддерживаемая компанией Borland.

Extreme Programming (XP) -экстремальное программирование, поддерживаемое открытым сообществом независимых разработчиков.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ход урока:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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