Инструментальное программное обеспечение (Software tools) - программное обеспечение, используемое в ходе разработки, корректировки или развития других программ: редакторы, компиляторы, отладчики, вспомогательные системные программы, графические пакеты и др.
Сюда входят языки программирования, интегрированные среды разработки программ, CASE-системы и др.
Выбор языка программирования
Существующие на сегодняшний день языки программирования можно выделить в следующие группы :
- универсальные языки высокого уровня;
- специализированные языки разработчика программного обеспечения;
- специализированные языки пользователя;
- языки низкого уровня.
В группе универсальных языков высокого уровня безусловным лидером на сегодня является язык С++. Действительно, он имеет ряд достоинств:
- масштабируемость. На языке С++ разрабатывают программы для самых различных платформ и систем;
- возможность работы на низком уровне с памятью, адресами, портами, что при неосторожном использовании может легко превратиться в недостаток;
- C++ имеет мощный препроцессор, унаследованный от С, но, как и любой другой мощный инструмент, требует осторожного использования;
- возможность создания обобщенных алгоритмов для разных типов данных, их специализация и вычисления на этапе компиляции, используя шаблоны.
При этом язык C++ обладает рядом существенных недостатков:
- подключение интерфейса внешнего модуля через препро-цессорную вставку заголовочного файла (#include) серьезно замедляет компиляцию при подключении большого количества модулей;
- недостаток информации о типах данных во время компиляции;
- сложность для изучения и компиляции;
- некоторые преобразования типов неинтуитивны. В частности, операция над беззнаковым и знаковым числами выдает беззнаковый результат.
Для C++ существует большое количество библиотек классов, поддерживающих создание пользовательского интерфейса, клиент-серверных приложений, работу с базами данных и т. д., поэтому пока альтернативы C++ нет . Для второстепенных проектов иногда используется Visual Basic. Язык Java рассматривался как альтернатива Basic, но из-за отсутствия визуального средства разработки форм он пока остается малопригодным. Современный Object Pascal, как и Pascal, предложенный Н. Виртом в середине 70-х годов XX в., остается наиболее привлекательным для обучения основам программирования в силу своей простоты, структурированности и обнаружения компилятором большого количества не только синтаксических, но и семантических ошибок.
В нынешнее время в отличие от 60-х годов XX в. языки программирования создаются крайне редко. За последние 15 лет можно отметить лишь две новинки, получившие широкое распространение - это Java (Sun Microsystems, 1995 г.), ставший популярным во многом благодаря технологии его использования в Интернете и появления такого понятия, как виртуальная Java-машина, и C# (Microsoft, 2000 г.), созданный на основе C++.
Создателем языка является сотрудник Microsoft Андреас Хейлсберг. Он стал известным в мире программистов задолго до того, как пришел в Microsoft. Хейлсберг входил в число ведущих разработчиков одной из самых популярных сред разработки - Delphi. В Microsoft он участвовал в создании версии Java - J++, так что опыта в написании языков и сред программирования ему не занимать. Как отмечал сам Андреас Хейлсберг, C# создавался как язык компонентного программирования, и в этом одно из главных достоинств языка, направленное на возможность повторного использования созданных компонентов.
Другие достоинства языка С#:
- сохраняет лучшие черты популярных языков программирования C/C++, на основе которых он создан. В связи с этим облегчается переход программистов от C++ к С#;
- является проще и надежнее C++. Простота и надежность главным образом связаны с тем, что на C# хотя и допускаются, но не поощряются такие опасные свойства C++, как указатели, адресация, разыменование, адресная арифметика;
- является полностью объектно-ориентированным языком, где даже типы, встроенные в язык, представлены классами;
- реализует возможности наследования и универсализации;
- учитывает все возможности Framework .Net, так как C# создавался параллельно с данной средой;
- благодаря каркасу Framework .Net, ставшему надстройкой над операционной системой, программисты C# получают те же преимущества работы с виртуальной машиной, что и программисты Java. Эффективность кода даже повышается, поскольку исполнительная среда CLR представляет собой компилятор промежуточного языка, в то время как виртуальная Java-машина является интерпретатором байт-кода;
- мощная библиотека каркаса поддерживает удобство построения различных типов приложений на С#, позволяя легко строить Web-службы, другие виды компонентов, достаточно просто сохранять и получать информацию из базы данных и других хранилищ данных;
- является источником надежного и эффективного кода.
Кроме вышеописанных языков к группе универсальных
принадлежат также Modula, Ada, COBOL, FORTRAN и некоторые другие. Каждый из вышеописанных языков имеет свои особенности и, соответственно, свою область применения. В настоящее время универсальные языки программирования применяются в самых различных областях человеческой деятельности, таких как:
- научные вычисления (языки C++, FORTRAN, Java);
- системное программирование (языки C++, Java);
- обработка информации (языки C++, COBOL, Java);
- искусственный интеллект (LISP, Prolog);
- издательская деятельность (Postscript, ТеХ);
- удаленная обработка информации (Perl, РНР, Java, C++);
- описание документов (HTML, XML).
С течением времени одни языки развивались, приобретали новые черты и остались востребованными, другие утратили свою актуальность и сегодня представляют в лучшем случае чисто теоретический интерес (Focal, PL/1 и др.). В значительной степени это связано с такими факторами:
- наличие среды программирования, поддерживающей разработку приложений на конкретном языке программирования;
- удобство сопровождения и тестирования программ;
- стоимость разработки с применением конкретного языка программирования;
- четкость и ортогональность конструкций языка;
- применение объектно-ориентированного подхода.
Специализированные языки разработчика используют для создания конкретных типов программного обеспечения. К ним относят:
- языки баз данных;
- языки создания сетевых приложений;
- языки создания систем искусственного интеллекта и т. д.
Специализированные языки пользователя обычно являются частью профессиональных сред пользователя, характеризуются узкой направленностью и разработчиками программного обеспечения не используются.
Языки низкого уровня позволяют осуществлять программирование практически на уровне машинных команд. При этом получают самые оптимальные как с точки зрения времени выполнения, так и с точки зрения объема необходимой памяти программы. Недостатком их является то, что они не поддерживают принципов структурного программирования .
В настоящее время языки типа ассемблера обычно используют:
- при написании сравнительно простых программ, для обращения к техническим средствам, например драйверов;
- в виде вставок в программы на языках высокого уровня, например, для ускорения преобразования данных в циклах с большим количеством повторений.
В большей степени выбор языка программирования определяется опытом разработчика, требованиями ведущей разработку организации или просто устоявшимся мнением.
Технология программирования в целом и средства поддержки разработки ПО, в частности, развиваются настолько быстро, что даже простое перечисление основных инструментальных систем заняло бы в этой книге слишком много места. Вот почему ниже мы остановимся кратко лишь на нескольких проектах в области технологии программирования, которые интересны в контексте данного издания.
Любая развитая технологическая система должна поддерживать все основные этапы создания проектируемого программного комплекса. Для достижения этой цели в общей структуре типовой технологической системы поддержки разработки (рис. 6.3) обычно выделяют базу данных проекта; подсистему автоматизации проектирования и программирования; подсистемы отладки, документирования и сопровождения, а также подсистему управления ходом выполнения проекта.
Рис. 6.3. Общая структура типовой технологической системы поддержки разработки
Развитые библиотечные системы поддержки разработки используются в настоящее время во всем мире во всех сколько-нибудь серьезных программных проектах. Но в подавляющем большинстве случаев такие системы достигли уровня удобства работы с ними квалифицированных программистов. Нас же, прежде всего, интересуют системы и проекты, в которых имеются тенденции к эксплицитному представлению технологических знаний, даже если они и не базируются на идеях и методах ИИ.
Один из таких проектов - Gandalf - ориентирован на автоматизированную генерацию систем разработки программного обеспечения. Исследования, выполняемые в рамках проекта Gandalf, касаются трех аспектов поддержки проектирования ПО: управление проектом, контроль версий и инкрементное программирование, а также интеграция их в единую среду. Управление в Gandalf-среде базируется на предположении, что разрабатываемый проект должен трактоваться как множество абстрактных типов данных, над которыми могут выполняться лишь определенные операции. Средством, реализующим данную концепцию, явилась система SDC (Software Development Control), представляющая собой набор программ, первоначально реализованных на языке Shell в системе UNIX, а позднее переведенная на язык С.
Исследования в области контроля версий были начаты еще Л. Коопридером на базе проекта FAFOS , где изначально анализировались возможности создания семейства операционных систем. Была разработана нотация для описания взаимодействия между подсистемами, для описания различных версий подсистем (исходного и объектного кода, документации и т. п.) и для описания действующих на этапе разработки механизмов (компиляция, редактирование связей и т. п.). Затем был создан специальный язык Intercol как средство описания взаимосвязи и версий модулей в системе. И, наконец, в систему были встроены знания о том, как конструировать систему из частей, не заставляя заниматься этим пользователя. В развитие этих работ была создана система SUCE, в рамках которой отслеживались различия между реализациями (версиями, которые действительно дают код для ряда спецификаций) и композициями (версиями, определяющими новые подсистемы как группы существующих подсистем).
В системе LOIPE (Language-Oriented Incremental Programming Environment) инкрементная компиляция выполняется на уровне отдельной процедуры. Достоинством такого подхода является то, что при коррекции процедуры на уровне локальных объектов или типов перекомпилируется только она. Если же меняется спецификация, то перекомпилируются и все зависящие от нее процедуры. Пользовательский интерфейс с LOIPE-системой базируется на подсистеме синтаксически-ориентированного редактирования ALOE (A Language-Oriented Editor). Целью разработки этой подсистемы было исследование возможности создания и использования синтаксически-ориентированных редакторов в качестве базиса для сред программирования.
Анализ литературы последних лет по технологии программирования показывает, что новой ветвью в технологии промышленной разработки и реализации, сложных и значительных по объему систем программного обеспечения является CASE-технология (Computer Aided Software Engineering) .
Первоначально CASE-технология появилась в проектах создания промышленных систем обработки данных. Это обстоятельство наложило свой отпечаток и на инструментальные средства CASE-технологии, где самое серьезное внимание уделялось, по крайней мере, в ранних CASE-системах, поддержке проектирования информационных потоков. В настоящее время наблюдается отход от ориентации на системы обработки данных, и инструментальные средства CASE-технологии становятся все более универсальными.
Все средства поддержки CASE-технологии делятся на две большие группы: САSE-Toolkits и CASE-Workbenches. Хороших русских эквивалентов этим терминам нет. Однако первые часто называют «инструментальными сундучками» (пакетами разработчика, технологическими пакетами), а вторые - «станками для производства программ» (технологическими линиями).
По определению CASE-Toolkit - коллекция интегрированных программных средств, обеспечивающих автоматическое ассистирование в решении задач одного типа в процессе создания программ.
Такие пакеты используют общее «хранилище» для всей технической и управляющей информации по проекту (репозиторий), снабжены общим интерфейсом с пользователем и унифицированным интерфейсом между отдельными инструментами пакета. Как правило, CASE-Toolkit концентрируются вокруг поддержки разработки одной фазы производства программ или на одном типе прикладных задач.
Все вышесказанное справедливо и по отношению к CASE-WorkBench. Но здесь, кроме того, обеспечивается автоматизированная поддержка анализа решаемых задач по производству программного обеспечения, которая базируется на общих предположениях о процессе и технологии такой деятельности; поддерживается автоматическая передача результатов работ от одного этапа к другому, начиная со стадии проектирования и кончая отчуждением созданного программного продукта и его сопровождением.
Таким образом, CASE-WorkBench является естественным «замыканием» технологии разработки, реализации и сопровождения программного обеспечения.
В настоящее время «типовая» система поддержки CASE-технологии имеет функциональные возможности, представленные на рис. 6.4.
Рис. 6.4. Функциональные возможности типовой системы поддержки CASE-технологии
Как следует из этой Н-диаграммы, в CASE-среде должны поддерживаться все основные этапы разработки и сопровождения процессов создания программных систем. Однако уровень такой поддержки существенно различен. Так, например, если говорить об этапах анализа и проектирования, большинство инструментальных пакетов поддерживает экранные и отчетные формы, создание прототипов, обнаружение ошибок. Значительная часть этих средств предназначена для ПЭВМ. Многие поддерживают такие широко используемые методологии, как структурный анализ DeMarco или Gane/Sarson, структурное проектирование Yourdan/Jackson и некоторые другие. Существуют специализированные пакеты разработчиков для создания информационных систем, например Ana Tool (Advanced Logical Software) для Macintosh; CA-Universe/Prototype (Computer Associates International) для ПЭВМ. Имеются CASE-среды и для поддержки разработки систем реального времени.
В среде разработчиков ПО существуют две оценки данного подхода: часть из них считает, что CASE-технология кардинально меняет процессы разработки и эксплуатации ПО, другие отрицают это и оставляют за инструментальными средствами CASE лишь функцию автоматизации рутинных работ . Однако анализ литературы показывает, что CASE средства все-таки «сдвигают» технологии разработки ПО с управления выполнением проектов в сторону метода прототипизации. И этот сдвиг, на наш взгляд, чрезвычайно важная тенденция в современной технологии программирования.
Қазақстан Республикасының Министерство
Білім және ғылым образования и науки
министрлігі Республики Казахстан
Д. Серікбаев ат ындағы ВКГТУ
ШҚМТУ им. Д. Серикбаева
УТВЕРЖДАЮ
Декан ФИТиБ
М. Кылышканов
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. Общая архитектура инструментальных систем технологии программирования.
Инструментальные средства разработки ПО– это совокупность аппаратно-программных средств, позволяющих осуществить написание и отладку программ для микропроцессорных систем с большой степенью достоверности их работоспособности в реальных системах.
К ним относятся:
Внутрисхемные эмулятры;
Программные симуляторы;
Отладочные мониторы;
Платы развития (оценочные платы);
Эмуляторы ПЗУ;
Интегрированные среды разработки.
Внутрисхемный эмулятор – наиболее мощное и универсальное отладочное средство. Это программно-аппаратное средство, способное замещать процессор в реальной системе и делающее процесс функционирования отлаживаемого контроллера прозрачным, т. е. легко контролируемым, произвольно управляемым и модифицируемым по воле разработчика.
Функционально внутрисхемные эмуляторы делятся на стыкуемые с внешней ЭВМ и функционирующие автономно.
Стыковка с отлаживаемой системой производится с помощью специального кабеля с эмуляционной головкой, которая вставляется вместо отлаживаемого микроконтроллера или параллельно ему. В последнем случае микроконтроллер должен иметь отладочный режим, при котором все его выводы переводятся в третье состояние.
Основные функциональные блоки эмулятора:
Отладчик;
Узел эмуляции микроконтроллера;
Эмуляционная память;
Подсистема точек останова.
Дополнительные блоки:
Процессор точек останова;
Трассировщик;
Профилировщик (анализатор эффективности программного кода);
Таймер реального времени;
Программно-аппаратные средства, обеспечивающие возможность чтения и модификации эмулируемого процессора;
Программно-аппаратные средства, обеспечивающие синхронное управление, необходимое для эмуляции в мультипроцессорных системах.
Отладчик осуществляет:
Управление процессом эмуляции (моделирования);
Вывод на монитор состояния и содержимого всех регистров и памяти и, при необходимости, их модификации (изменение их содержимого).
Отладчик позволяет одновременно следить за ходом выполнения программы и видеть соответствие между исходным текстом, образом программы в машинных кодах и состоянием всех ресурсов эмулируемого микроконтроллера.
Эмуляционная память может применяться вместо ПЗУ отлаживаемой системы, а также дает возможность отлаживать программу без реальной системы или ее макета. (Нет необходимости в перепрограммировании ПЗУ.) Эмулирование возможно целиком или поблочно.
Трассировщик – это логический анализатор, работающий синхронно с процессором и фиксирующий поток выполняемых инструкций и состояния выбранных внешних сигналов.
Процессор точек останова позволяет останавливать выполнение программы или выполнять иные действия, например, запускать или останавливать трассировщик при выполнении заданных пользователем условий (любой степени сложности) без вывода из масштаба «реального времени».
Профилировщик позволяет получить по результатам прогона отлаживаемой программы следующую информацию:
Количество обращений к различным участкам программы;
Время, затраченное на выполнение различных участков программы.
Анализ статистической информации, поставляемой профилировщиком, позволяет легко выявлять «мертвые» или перенапряженные участки программ и в результате оптимизировать структуру отлаживаемой программы.
Интегрированная среда разработки – это совокупность программных средств, поддерживающая все этапы разработки ПО – от написания исходного текста программы до ее компиляции и отладки – и обеспечивающая простое и быстрое взаимодействие с другими инструментальными средствами (программным отладчиком-симулятором и программатором).
Наличие встроенных редактора текста, менеджера проектов и системы управления существенно помогает разработчику, избавляя его от множества рутинных действий. Стирается грань между написанием, редактированием и отладкой программы.
Существуют эмуляторы, предназначенные для эмуляции микроконтроллеров семейств Intel MCS 8051, MCS-196, Microchip PIC.
Программный симулятор – программное средство, имитирующее работу микроконтроллера и его памяти. В его состав входят отладчик, модель центрального процессора и памяти. Более сложные симуляторы содержат также модели встроенных периферийных устройств (таймеров, АЦП и систем прерываний). Загрузив программу в симулятор, пользователь может запускать ее в пошаговом или непрерывном режимах, задавать условные или безусловные точки останова, контролировать и свободно модифицировать содержимое ячеек памяти и регистров микроконтроллера. С его помощью можно быстро проверить логику выполнения программы и правильность выполнения арифметических операций.
Наличие интерфейса внешней среды позволяет избавить разработчика от необходимости устанавливать и изменять вручную содержимое входных регистров, т. е. можно создавать и гибко использовать модель внешней среды микроконтроллера, функционирующую и взаимодействующую с отлаживаемой программой по заданному алгоритму.
Особенностью программных симуляторов является то обстоятельство, что исполнение программ, загруженных в симулятор, происходит в масштабе времени, отличном от реального. Однако более низкая цена, возможность ведения отладки даже в условиях отсутствия макета отлаживаемого устройства делают программные симуляторы весьма эффективным средством отладки.
Отладочный монитор – специальная программа, загружаемая в память отлаживаемой системы и вынуждающая процессор выполнять, кроме прикладной задачи, еще и отладочные функции:
Загрузку прикладных кодов в свободную от монитора память;
Установку точек останова;
Запуск и останов загруженной программы в реальном времени;
Проход программы пользователя по шагам;
Просмотр, редактирование содержимого памяти и управляющих регистров.
Программа монитора должна быть связана с внешним компьютером или монитором для визуализации процесса отладки.
Основное достоинство использования монитора – это малые затраты при сохранении возможности вести отладку в реальном времени на микроконтроллере, стоящем на плате. Недостатком является отвлечение ресурсов микроконтроллера на отладочные и связные процедуры (память, прерывания, последовательный канал).
Платы развития , или оценочные платы, являются своеобразными конструкторами для макетирования прикладных систем. Выпуск оценочных плат – это современный подход к продвижению микроконтроллеров на рынке. Обычно на печатной плате устанавливается вся необходимая аппаратура для демонстрации возможностей микроконтроллера, обеспечивается связь с компьютером и предоставляется поле для монтажа прикладных схем пользователя. Такие платы могут быть применены для установки в аппаратуру малой серии (5 – 20 шт.).
Для удобства отладки платы развития комплектуются простейшими средствами отладки на базе монитора отладки для микроконтроллеров с внешней шиной и без нее.
В первом случае отладочный монитор поставляется в виде микросхемы ПЗУ, которая устанавливается в разъем (кроватку) на плате. На плате также имеется ОЗУ для программ пользователя и канал связи с компьютером. Пример – плата фирмы “INTEL” для микроконтроллера 8051.
Для микроконтроллеров без внешней шины плата развития имеет встроенные схемы программирования внутреннего ПЗУ микроконтроллера, управляемые от внешнего компьютера. В прикладной программе должны быть предусмотрены вызовы отладочных функций и сам монитор. После загрузки и прогона программы для внесения изменений требуется стирание ПЗУ и перезапись нового варианта программы пользователя.
Готовая программа получается путем удаления монитора и всех вызовов мониторных функций. Примерами могут служить платы развития фирмы “MICROCHIP” для своих PIC-контроллеров, а также платы развития для отладки своих контроллеров 80С750 Philips и 89С2051 Atmel.
В целом, возможности данного подхода (плата развития + монитор) не столь универсальны, как возможности внутрисхемного эмулятора, да и отвлечение ресурсов контроллера на режим отладки следует учитывать. Тем не менее, законченный набор программно-аппаратных средств, позволяющих без потерь времени приступить к монтажу и отладке прикладной системы, во многих случаях является решающим фактором, с учетом меньшей стоимости, по сравнению с универсальным эмулятором.
Эмуляторы ПЗУ – это программно-аппаратные средства, позволяющие замещать ПЗУ на отлаживаемой плате и подставляющие вместо него ОЗУ, куда загружается программа с компьютера через один из стандартных каналов связи. В данном случае стараются избежать многократных циклов перепрограммирования ПЗУ. Метод пригоден для микроконтроллеров, которые в состоянии обращаться к внешней памяти программ. По сложности и стоимости метод сравним с использованием плат развития, но более универсален, так как может применяться с любыми типами микроконтроллеров.
В настоящее время имеются модели «интеллектуальных» эмуляторов ПЗУ, позволяющие заглядывать внутрь микроконтроллера, т. е. работающие почти как внутрисхемный эмулятор за счет быстрого переключения шины. Создается эффект, будто бы монитор отладки установлен на плате пользователя и при этом не занимает у микроконтроллера никаких аппаратных ресурсов, кроме небольшой зоны программных шагов, примерно 4К. Такое устройство разработала фирма «ФИТОН» для всех существующих и будущих микроконтроллеров с ядром МК 8051, но дополнительно насыщенных различными устройствами ввода/вывода. Оно поддерживает множество микроконтроллеров фирм “PHILIPS”, “SIEMENS”,”OKI”.
Интегрированные среды разработки (Integrated Development Environment, IDE) позволяет программисту:
Использовать встроенный файловый текстовый редактор, специально ориентированный на работу с исходными текстами программ;
