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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

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

Один из таких проектов - Gandalf - ориентирован на ав­томатизированную генерацию систем разработки программного обеспечения. Исследования, выполняемые в рамках проекта Gandalf, касаются трех аспектов поддержки проектирования ПО: управление проектом, контроль версий и инкрементное программирование, а также интеграция их в единую среду. Управление в Gandalf-среде базируется на предположении, что разрабатываемый проект дол­жен трактоваться как множество абстрактных типов данных, над которыми могут выполняться лишь определенные операции. Средством, реализующим данную концепцию, явилась система SDC (Software Development Control), представляю­щая собой набор программ, первоначально реализованных на языке Shell в систе­ме UNIX, а позднее переведенная на язык С.

Исследования в области контроля версий были начаты еще Л. Коопридером на базе проекта FAFOS , где изначально анализировались возможности создания семейства операционных систем. Была разработана нота­ция для описания взаимодействия между подсистемами, для описания различ­ных версий подсистем (исходного и объектного кода, документации и т. п.) и для описания действующих на этапе разработки механизмов (компиляция, редакти­рование связей и т. п.). Затем был создан специальный язык Intercol как средство описания взаимосвязи и версий модулей в системе. И, наконец, в систему были встроены знания о том, как конструировать систему из частей, не заставляя зани­маться этим пользователя. В развитие этих работ была создана система SUCE, в рамках которой отслеживались различия между реализациями (версиями, кото­рые действительно дают код для ряда спецификаций) и композициями (версия­ми, определяющими новые подсистемы как группы существующих подсистем).

В системе LOIPE (Language-Oriented Incremental Programming Environment) инкрементная компиляция выполняется на уровне отдельной процедуры. Достоин­ством такого подхода является то, что при коррекции процедуры на уровне ло­кальных объектов или типов перекомпилируется только она. Если же меняется спецификация, то перекомпилируются и все зависящие от нее процедуры. Поль­зовательский интерфейс с LOIPE-системой базируется на подсистеме синтакси­чески-ориентированного редактирования ALOE (A Language-Oriented Editor). Целью разработки этой подсистемы было исследование возможности создания и использования синтаксически-ориентированных редакторов в качестве базиса для сред программирования.

Анализ литературы последних лет по технологии программирования показыва­ет, что новой ветвью в технологии промышленной разработки и реализации, сложных и значительных по объему систем программного обеспечения явля­ется CASE-технология (Computer Aided Software Engineering) .

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

Все средства поддержки CASE-технологии делятся на две большие группы: САSE-Toolkits и CASE-Workbenches. Хороших русских эквивалентов этим терми­нам нет. Однако первые часто называют «инструментальными сундучками» (па­кетами разработчика, технологическими пакетами), а вторые - «станками для производства программ» (технологическими линиями).

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

Такие пакеты используют общее «хранилище» для всей технической и управля­ющей информации по проекту (репозиторий), снабжены общим интерфейсом с пользователем и унифицированным интерфейсом между отдельными инстру­ментами пакета. Как правило, CASE-Toolkit концентрируются вокруг поддерж­ки разработки одной фазы производства программ или на одном типе приклад­ных задач.

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

Таким образом, CASE-WorkBench является естественным «замыканием» технологии разработки, реализации и сопровождения программного обеспечения.

В настоящее время «типовая» система поддержки CASE-технологии имеет функци­ональные возможности, представленные на рис. 6.4.

Рис. 6.4. Функциональные возможности типовой системы поддержки CASE-технологии

Как следует из этой Н-диаграммы, в CASE-среде должны поддерживаться все ос­новные этапы разработки и сопровождения процессов создания программных систем. Однако уровень такой поддержки существенно различен. Так, например, если говорить об этапах анализа и проектирования, большинство инструмен­тальных пакетов поддерживает экранные и отчетные формы, создание прототипов, обнаружение ошибок. Значительная часть этих средств предназначена для ПЭВМ. Многие поддерживают такие широко используемые методологии, как структурный анализ DeMarco или Gane/Sarson, структурное проектирование Yourdan/Jackson и некоторые другие. Существуют специализированные пакеты разработчиков для создания информационных систем, например Ana Tool (Ad­vanced Logical Software) для Macintosh; CA-Universe/Prototype (Computer Asso­ciates International) для ПЭВМ. Имеются CASE-среды и для поддержки разра­ботки систем реального времени.

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

Қазақстан Республикасының Министерство

Білім және ғылым образования и науки

министрлігі Республики Казахстан

Д. Серікбаев ат ындағы ВКГТУ

ШҚМТУ им. Д. Серикбаева

УТВЕРЖДАЮ

Декан ФИТиБ

М. Кылышканов

2015 г.

БАҒДАРЛАМАНЫ ӘЗІРЛЕУДІҢ ҚҰРАЛ-САЙМАНДАРЫ

Жұмыс модульдік оқу бағдарламасы және силлабус

ИНСТРУМЕНАЛЬНЫЕ СРЕДСТВА РАЗРАБОТКИ ПРОГРАММ

Количество кредитов дисциплины: 3

Усть-Каменогорск

Рабочая модульная учебная программа и силлабус разработаны на кафедре «Информационные системы и компьютерное моделирование» на основании Государственного общеобязательного стандарта образования РК ГОСО РК 5.04.019 - 2011 Высшее образование. Бакалавриат, Рабочего учебного плана, Типовой учебной программы и Модульной специальности.

Обсуждён на заседании кафедры «Информационные системы и компьютерное моделирование»

Зав. кафедрой Н. Денисова

Одобрен учебно – методическим советом ФИТиБ

Председатель Г. Уазырханова

Протокол № ____ от ____ ____________ 2015

Разработали

доцент кафедры Т. Балова

старший преподаватель кафедры И. Увалиева

Нормоконтролёр И. Фазылова

1 ХАРАКТЕРИСТИКА ДИСЦИПЛИНЫ, ЕЁ МЕСТО В УЧЕБНОМ ПРОЦЕССЕ

1.1 Краткое содержание изучаемой дисциплины

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

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

1.2 Цели и задачи изучения дисциплины

Цель изучения дисциплины «Инструментальные средства разработки программ» - ознакомление обучающихся с теоретическими знаниями в области технологий проектирования и обеспечения жизненного цикла программных систем, а также приобретение практических навыков использования современных технологий, ориентированных на моделирование бизнес-процессов и проектирование программных систем средствами CASE-технологий (Computer Aided Software/System Engineering, CASE). Цель дисциплины согласована с общими целями модульной образовательной программы специальности.

Компетентностный подход в преподавании дисциплины «Инструментальные средства разработки программ» определяет её основные задачи:

Сформировать у обучающихся систему знаний в области программной инженерии (Software engineering) и программирования (computer programming);

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

Выработать навыки применения CASE-средств структурного и объектно-ориентированного моделирования и проектирования программных средств.

Задачи изучения дисциплины обеспечивают реализацию установленных в квалификационной характеристике требований к подготовке бакалавров по образовательной программе 5В070400-«Вычислительная техника и программное обеспечение».

1.3 Результаты изучения дисциплины

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

знать и понимать:

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

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

Подходы к моделированию и реструктуризации бизнес-процессов и систем;

уметь применять на практике CASE-средства, поддерживающие:

Методологию функционального моделирования IDEF0;

Методологию событийного моделирования IDEF3;

Методологию моделирования потоков данных DFD;

Методологию семантического моделирования данных IDEF1X;

Методологию объектно-ориентированного моделирования программного обеспечения и метамодели UML;

быть готовым формировать суждения:

О выборе модели жизненного цикла для конкретного проекта и проекта;

По вопросам совершенствования программного обеспечения в рамках корпоративных информационных систем и крупных государственных проектов (от модели AS-IS к модели TO-BE);

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

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

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

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

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

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

1.4 Пререквизиты

Для полноценного усвоения материала по дисциплине ИСРП необходимо наличие знаний по дисциплинам, связанным с алгоритмизацией и технологией программирования.

1.5 Постреквизиты

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

2.1 Тематический план

Наименование темы, её содержание	и другие источники	Трудоёмкость,
Модуль 1 «CASE-средства структурно-функционального проектирования программных средств»
Лекционные занятия
Тема 1 «Введение в дисциплину». Основные понятия. Классификация современных инструментальных средств разработки программных продуктов. Цель и задачи инструментальных средств разработки программ. История развития инструментальных средств.
Тема 2 «Методы проектирования программного обеспечения». Общие требования к методологии и технологии проектирования программного обеспечения. Руководство к своду знаний по программной инженерии SWEBOK. Обзор методов проектирования программного обеспечения. Обзор инструментария проектирования программного обеспечения
Тема 3 «Основы методологии проектирования программного обеспечения». Проектирование программ как сложных систем. Жизненный цикл программного обеспечения. Основные процессы ЖЦ ПО. Вспомогательные процессы ЖЦ ПО. Организационные процессы ЖЦ ПО
Тема 4 «Модели жизненного цикла программного обеспечения». Понятие модели жизненного цикла программного обеспечения. Классическая модель процесса разработки программ. Прототипирование. Стратегия инкрементальной разработки. Спиральная модель процесса. Модель быстрой разработки приложений RAD
Тема 5 «Методологии разработки программного обеспечения». XP - процесс или экстремальное программирование. Методология Rational Unified Process (RUP). Гибкие (agile) методологии. Выбор модели жизненного цикла для конкретного проекта. Порядок разработки программного обеспечения
Тема 6 «Современные CASE - технологии». CASE - технологии и их использование. Общая характеристика и классификация современных CASE-средств. Технологии внедрения и освоения CASE-средств. Оценка CASE-средств
Тема 7 «Моделирование бизнес-процессов». Понятие бизнес-процесса. Реструктуризация бизнес-процессов. Моделирование бизнес-процессов. Методы моделирования бизнес процессов
Тема 8 «CASE-технологии структурного анализа и проектирования программных средств». Методология структурного анализа и проектирования. Методология функционального моделирования IDEF0. Методология событийного моделирования IDEF3. Моделирование потоков данных DFD. Методология семантического моделирования данных IDEF1X
Лабораторные занятия
Тема 1 «Разработка функциональной модели IDEF0»
Тема 2 «Разработка моделей информационных процессов IDEF3 и потоков данных DFD»
Тема 3 «Методология семантического моделирования данных IDEF1X»
Тема 1 «Отчёты и Sibling диаграммы IDEF0-модели»
Тема 2 «Средства коллективной разработки функциональных моделей в среде BPwin»
Тема 3 «Создание отчётов в ERwin»
Тема 1 «Создание диаграмм FEO»
Тема 3 «Создание связи категоризации в IDEF1X-модели»
Итого по модулю 1
Модуль 2 «CASE-средства объектно-ориентированного проектирования программных средств»
Тема 9 «Основы объектно-ориентированного моделирования программного обеспечения и метамодели UML». Иерархия метаописаний, используемых в визуальном моделировании программного обеспечения. Назначение и уровни моделей UML. Представления в UML	21, 22, 23, 24, 25
Тема 10 «Унифицированный язык моделирования UML. Модель UML». UML – унифицированный язык моделирования. Сущности в UML. Отношения в UML	22, 23, 24, 25, 26, 27
Тема 11 «Унифицированный язык моделирования UML. Диаграммы UML». Виды диаграмм UML. Общие диаграммы UML. Специальные диаграммы UML	22, 23, 24, 25, 26, 27
Тема 12 «Унифицированный язык моделирования UML. Общие механизмы UML». Использование общих механизмов UML. Общие свойства модели. Точки семантики	22, 23, 24, 25, 26, 27
Тема 13 «Общее описание системы с позиции представления UML». Представления UML с позиции обобщения описаний. Общие механизмы UML. Общие свойства модели	22, 23, 24, 25, 26, 27
Тема 14 «Описание функциональности разработки программного обеспечения». Управление рисками проекта. Порядок разработки программного обеспечения. Документирование программных средств. Управление требованиями
Тема 15 «Научно-технологические тренды и самые быстрорастущие сегменты на мировом ИТ рынке». Три платформы в эволюции рынка ИТ. Новые тренды ИТ: прогноз компании Gartner. Мировые Top тренды развития ИТ на ближайшие 3-5 лет
Лабораторные занятия
	22, 23, 24, 25, 26, 27
	22, 23, 24, 25, 26, 27
	22, 23, 24, 25, 26, 27
Самостоятельная работа обучающегося под руководством преподавателя (СРОП)
Тема 4. «Построение структурных диаграмм UML»	22, 23, 24, 25, 26, 27
Тема 5. «Построение поведенческих диаграмм UML»	22, 23, 24, 25, 26, 27
Тема 6. «Генерация программного кода по модели UML»	22, 23, 24, 25, 26, 27
Самостоятельная работа обучающегося (СРО)
Тема 4. «Построение структурных диаграмм UML»	22, 23, 24, 25, 26, 27
Тема 5. «Построение поведенческих диаграмм UML»	22, 23, 24, 25, 26, 27
Тема 6. «Генерация программного кода по модели UML»	22, 23, 24, 25, 26, 27
Итого по модулю 2
Итого по дисциплине, кредит РК

2.2 Задания для самостоятельной работы (СРОП, СРО)

		Продолжитель-ность выполнения, уч. неделя	Форма контроля	Срок сдачи (номер уч. недели)
Задание на СРОП –IDEF0-модель дополнить отчётами и диаграммами Node Tree. Задание на СРО –IDEF0-модель дополнить диаграммой FEO.	Познакомиться с основными приёмами коллективной разработки функциональных моделей в среде BPwin		Инд. задание и дополнительные вопросы при защите . Тестовые задания
Задание на СРОП: Выполнить расщепление IDEF0-модели и ABC анализ. Задание на СРО – изучить элементы имитационной модели.	Получить практические навыки использования средств коллективной разработки модели с элементами анализа ABC
Задание на СРОП - для IDEF1X-модели построить шаблон отчёта. Задание на СРО – изучить работу по созданию связи категоризации в IDEF1X-модели	Изучить приёмы построения шаблонов отчёта средствами Report Builder среды ERwin и освоить процедуры работы со связями категоризации		Инд. задание и дополнительные вопросы при защите лабораторной работы Тестовые задания
Сенсорный многопозиционный ввод и события WPF	Получить начальные сведения о способах взаимодействия с приложением WPF с помощью касания экрана для интерактивного взаимодействия		Инд. задание и дополнительные вопросы при защите лабораторной работы. Тестовые задания
Триггеры свойств и событий WPF	Познакомиться с механизмом триггеров WPF для создания анимационного эффекта		Инд. задание и дополнительные вопросы при защите лабораторной работы. Тестовые задания
Использование API-интерфейса Office и первичных сборок. Net Microsoft. Office. Interop	Освоить упрощённый механизм взаимодействия с СОМ с целью расширения практических приёмов организации межпрограммного взаимодействия		Инд. задание и дополнительные вопросы при защите лабораторной работы. Тестовые задания

2.3 График выполнения и сдачи заданий по дисциплине

Основная литература

1 Рамбо Дж. Унифицированный процесс разработки программного обеспечения / А. Якобсон, Г. Буч, Дж. Рамбо - СПб.: Питер, 2002.-496 с.:ил.

2 CASE-технологии. Современные методы и средства проектирования информационных систем / - М.: Финансы и статистика, 1998.- 176 с.

3 Бахтизин, разработки программного обеспечения: учеб. пособие / , . - Минск: БГУИР, 2010. - 267 с. : ил.

4 , Анализ и компьютерное моделирование информационных процессов и систем / , .- Диалог-МИФИ, 2009. - 416 стр.

5 ISO/IEC 12207:2008. Systems and software engineering - Software life cycle processes [Электронный ресурс]. - URL: http://www. iso. org/iso/catalogue_detail? csnumber=43447, свободный. – Загл. с экрана (дата обращения: 30.10.2015)

6 ГОСТ Р ИСО/МЭК 12207-2010 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств. – М. Изд-во стандартов, 2011., 115с.

7 ГОСТ Р ИСО/МЭК 11179-2-2012 Информационная технология. Регистры метаданных (РМД). Часть 2. Классификация [Электронный ресурс]. - URL: http:///Catalog/64/6430.shtml, свободный. – Загл. с экрана (дата обращения: 30.10.2015)

8 ГОСТ Р ИСО/МЭК ТО 12182 – 2002. Информационная технология. Классификация программных средств. – Введ. 2002 – 06 – 11. – М. Изд-во стандартов, 2002

9 IEEE Computer Society. SWEBOK [Электронный ресурс]. - URL: http://puter. org/web/swebok, свободный. – Загл. с экрана (дата обращения: 30.10.2015)

10 , Учебное пособие к практическим занятиям «Структурно-функциональный подход к проектированию и с использованием CASE-средств» / Перм. гос. тещн. ун.-т. – Пермь, 2005.- 245 с.

11 Марка МакГоуэн етодология структурного анализа и проектирования SADT [Пер. с англ.] / арка, акГоуэн - М.: МетаТехнология, 1993. -240 с.

12 РД 50.1.028-2001. Методология функционального моделирования IDEF0, Руководящий документ. Издание официальное. - М.: ИПК Издательство стандартов, 2000. - 75 с.

13 оделирование и анализ систем. IDEF-технологии: практикум/С. Черемных, И. Семенов, В. Ручкин.- М.: Финансы и статистика, 2006. -192 с.

14 , Структурный анализ систем. IDEF - технологии/С. Черемных, И. Семенов, В. Ручкин.- М.: Финансы и статистика,2001. – 208 с.

15 труктурные модели бизнеса: DFD-технологии/ А. Калашян, Г. Калянов.- М.: Прикладные информационные технологии, 2009.- 256 с.

Дополнительная литература

16 IEEE Std. 1320.2–1998. Стандарт IEEE по синтаксису и семантике языка концептуального моделирования IDEFIX97 (IDEF Object). - Введ. 1998-06-25. – Нью-Йорк: IEEE, 1998.

17 ффективное моделирование с AllFusion Process Modeler/ В. Дубейковский.- М.: Диалог-МИФИ, -2007.- 384 с.

18 оделирование бизнес-процессов с AllFusion Process Modeler/ С. Маклаков.- М.: Диалог-МИФИ, -2004.- 240 с.

19 BPwin и Erwin. CASE-средства для разработки информационных систем / С. Маклаков. - Диалог-МИФИ, 2000. - 320 с.

20 , Методология функционального проектирования IDEF0. Учебное пособие по курсу «Технология разработки программного обеспечения» для студ. спец. 40 01 01 Программное обеспечение информационных технологий дневной формы обучения. – Минск: БГУИР, 2003. – 24 с.: ил.

21 , Моделирование на UML. Теория, практика, видеокурс. - СПб, Профессиональная литература, Наука и Техника, 2010, 640 с.

22 зык UML. Руководство пользователя. Второе издание. - ДМК, 2006, 496 с.

23 Дж. Рамбо, М. Блаха, UML 2.0. Объектно-ориентированное моделирование и разработка.- Питер, 2007г., 544 с.

24 Мартин Фаулер. UML. Основы. Краткое руководство по стандартному языку объектного моделирования. Символ-Плюс, 2011., 192с.

25 The Unified Modeling Language (UML) [Электронный ресурс]. - URL: http://www. uml. org/, свободный. – Загл. с экрана (дата обращения: 30.10.2015)

26 ведение в UML: [Электронный ресурс] - Открытые курсы Интернет-университета информационных технологий (ИНТУИТ). - Режим доступа http://www. intuit. ru/studies/courses/1007/229/info (дата обращения: 30.10.2015)

27 изуальное моделирование в среде IBM Rational Rose 2003: [Электронный ресурс] - Открытые курсы Интернет-университета информационных технологий (ИНТУИТ). - Режим доступа http://www. intuit. ru/studies/courses/14/14/info (дата обращения: 30.10.2015)

28 The Gartner Symposium/ITxpo [Электронный ресурс]. - URL: http://www. /technology/symposium/japan/exhibitor-directory. jsp, свободный. – Загл. с экрана (дата обращения: 30.10.2015)

29 Обзор и оценка перспектив развития мирового и российского рынков ИТ / Блог компании Московская Биржа, IT-стандарты, ИТ-инфраструктура [Электронный ресурс]. - URL: http://habrahabr. ru/company/moex/blog/250463/, свободный. – Загл. с экрана (дата обращения: 30.10.2015)

4 ОЦЕНКА ЗНАНИЙ

4.1 Требования преподавателя

Требования преподавателя:

Посещение лекционных и лабораторных занятий, СРСП по расписанию является обязательным;

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

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

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

В течение занятий мобильные телефоны должны быть отключены;

Студент обязан приходить на занятия в деловой одежде.

4.2 Критерии оценки

Оценка всех видов заданий осуществляется по 100-балльной системе.

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

Рубежный контроль знаний проводится на 7 и 15 неделе семестра в форме тестирования. Рейтинг складывается из следующих видов контроля:

Экзамен по дисциплине проходит во время экзаменационной сессии в форме тестирования.

Итоговая оценка знаний студента по дисциплине включает:

40% результата, полученного на экзамене;

60% результатов текущей успеваемости.

Формула подсчёта итоговой оценки:

где Р1, Р2 – цифровые эквиваленты оценок первого, второго рейтингов соответственно; Э – цифровой эквивалент оценки на экзамене.

Итоговая буквенная оценка и её цифровой эквивалент в баллах:

4.3 Материалы для итогового контроля

4.3.1 Модуль 1 «CASE-средства структурно-функционального проектирования программных средств»

В соответствии с международным стандартом ISO и IEC (International Electrotechnical Commission) технология программирования – это

A) один из видов деятельности, входящих в цикл разработки программного обеспечения

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

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

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

E) алгоритм, записанный на языке программирования

F) последовательность команд (операторов, инструкций) компьютера, выполнение которых приводит к получению результата решения задачи

Инструментальные программные средства (Software tools) – это:

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

B) программное обеспечение предприятий, функции которого обеспечивают финансовое управление, систему отношений с потребителями, управление кадрами и пр.

C) компоновщики и отладчики

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

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

Компилятор - это:

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

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

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

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

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

Основными преимуществами CASE-средств являются:

A) Увеличение затрат на разработку

B) Уменьшение затрат на разработку

C) Усложнение доступа к данным

D) Увеличение времени на разработку

E) Облегчение при модификации систем

F) Возможность хранения данных

В соответствии с проектом ICAM (Интеграция компьютерных и промышленных технологий) методология функционального моделирования производственной среды или системы связана с нотацией

К основным элементам IDEF3-модели относятся

B) связи (Links)

C) внешние сущности (external entities)

D) перекрёстки (Junctions)

E) потоки данных (data flow)

F) хранилища данных (data stores)

G) внешние сущности (external entities)

H) процессы или работы (activity)

4.3.2 Модуль 2 «CASE-средства объектно-ориентированного проектирования программных средств»

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

A) технического риска

B) календарного риска

C) управленческого риска

D) коммерческого риска

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

A) наследованием

B) инкапсуляцией

C) полиморфизмом

D) абстрагированием

E) многомодельностью

F) иерархическим построением

На диаграмме использования UML применяют следующие типы сущностей

B) Варианты использования

C) Действующие лица

D) Интерфейсы

F) Состояния

G) Объекты

Какая структурная сущность UML находится вне моделируемой системы и непосредственно взаимодействует с ней

A) класс (class)

B) интерфейс (interface)

C) действующее лицо (actor)

D) вариант использования (use case)

E) артефакт (artifact)

F) узел (node)

5 ОСНОВНЫЕ ФОРМЫ И МЕТОДЫ ОБУЧЕНИЯ

Для повышения мотивации обучающихся к усвоению знаний по дисциплине используются:

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

Интерактивная модель обучения, предусматривающая публичную защиту лабораторных работ в форме презентации, сообщения по теме СРОП и СРС;

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

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

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

Дистанционная технология обучения.

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

6 ВРЕМЯ КОНСУЛЬТАЦИЙ

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

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

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

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

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

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

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

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

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

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

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

редакторы,·

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(рис. 16.1): ·

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

интерфейсы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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