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

Этап 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. Редактор связей или сборщик, который выполняет связывание объектных модулей и формирует на выходе работоспособное приложение - исполнимый код.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Компиляторы

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

Линковщики

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

Ассемблеры

Отладчики

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

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

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

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

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

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

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

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

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

Состав САПР

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

редакторы,·

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(рис. 16.1): ·

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

интерфейсы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Терминология

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

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

С учетом данного определения термин «Разработка программ» будет звучать следующим образом:

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

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

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

1. Проектирование приложения.
2. Реализация программного кода приложения.
3. Тестирование приложения.

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

2.1 Средства проектирования приложений

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

1. Анализ требований.
2. Разработка архитектуры будущего программного обеспечения.
3. Разработка устройств основных компонент программного обеспечения.
4. Разработка макетов Пользовательских интерфейсов.

Результатом проектирования обычно является «Эскизный проект» (Software Design Document) или «Технический проект» (Software Architecture Document). Задача «Анализ требований» обычно выполняется с использованием методов системологии (анализа и синтеза) с учетом экспертного опыта проектировщика. Результатом анализа обычно является содержательная или формализованная модель процесса функционирования программы. В зависимости от сложности процесса для построения данных моделей могут быть применены различные методы и вспомогательные средства. В общем случае для описания моделей обычно применяются следующие нотации (в скобках приведены программные средства, которые могут быть использованы для получения моделей):

• BPMN (Vision 2003 + BPMN, AcuaLogic BPMN, Eclipse, Sybase Power Designer).
• Блок-схемы (Vision 2003 и многие другие).
• ER-диаграмы (Visio 2003, ERWin, Sybase Power Designer и многие другие).
• UML-диаграмы (Sybase Power Designer, Rational Rose и многие другие).
• макеты, мат-модели и т.д.

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

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

• Функциональное программирование;
• Структурное программирование;
• Императивное программирование;
• Логическое программирование;
• Объектно-ориентированное программирование (прототипирование; использование классов; субъективно-ориентированное программирование).

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

• диаграмма классов и т.д (Ration Rose, Sybase PowerDisigner и многие другие).
• описание модулей структур и их программного интерфейса (например, Sybase PowerDisigner и многие другие).

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

2.2 Средства реализации программного кода

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

• языки программирования (C++,Си, Java, C#, php и многие другие);
• средства создания пользовательского интерфейса (MFC, WPF, QT, GTK+ и т.д.)
• средства управления версиями программного кода (cvs, svn, VSS).
• средства получения исполняемого кода (MS Visual Studio, gcc и многие другие).
• средства управления базами данных (Оracle, MS SQL, FireBird, MySQL и многие другие).
• отладчики (MS Visual Studio, gdb и т.д.).

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

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

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

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

• средства анализа кода, профилирования (Code Wizard – ParaSoft, Purify – Rational Softawre. Test Coverage – Semantic и т.д.);
• средства для тестирования функциональности (TEST – Parasoft, QACenter – Compuware, Borland SilkTest и т.д.);
• средства для тестирования производительности (QACenter Performance – Compuware и т.д).

3. Заключение

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

Также смотрите :

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

оригинальное программирование;

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

автоматизацию основных этапов разработки программ.

Наиболее традиционными средствами разработки являются языки и системы программирования. Языки программирования принято делить на машинные и алгоритмические языки.

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

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

Машинно -ориентированные языки программирования являются языками низкого уровня, поскольку они учитывают архитектуру и тип компьютеров. Программирование на таких языках трудоемко, но программы оптимальны с точки зрения потребных ресурсов компьютера. Примеры машинно-ориентированных языков программирования - различные ассемблеры 1 (Macro Assembler, Turbo Assembler и др.) определенного класса компьютеров.

Процедурно -ориентированные языки программирования, такие как Visual Basic, Pascal, C++, Ada, Cobol, PL1 и др. позволяют описать набор процедур обработки, реализуют типовые вычислительные структуры:

1. Последовательности блоков (инструкций): 1, 2, 3, 4 и т.д.

Все блоки (инструкции) выполняются в строгой последовательности (Рис.5 А)

2. Условный переход (Рис.5 Б) – проверка заданного условия (2) и выбор альтернативного действия: если условие истинно – 3, иначе - 4. После этого управление передается блоку 5.

3. Альтернативный выбор (Рис.5 В) – проверка условия (2), если условие истинно – выполнение действия 3, иначе проверка условия (4); если условие истинно – выполнение действия 5 и т.д. Если не выполнилось ни одного условия или выполнились действия (3 или 5 и т.п.), управление передается блоку 6.

А Б В

Рисунок 5

4. Циклический процесс – цикл «пока» (Рис. 6А). Цикл повторяется, пока истинно условие (2) – блок 3. Если условие (2) ложно, передача управления блоку 4.

5. Циклический процесс – цикл «до» (Рис. 6Б). Цикл выполняется как минимум один раз – блок 2. После проверки условия (3), если оно истинно, выполняется блок (2), иначе управление передается блоку 4.

Рисунок 6

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

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

Пакеты прикладных программ (ППП) делятся на классы:

Проблемно-ориентированные ППП – обеспечивают решение задач определенной предметной области;

Методо-ориентированные ППП – поддерживают определенного вида модели и методы решения задач, применяются независимо от предметной области;

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