- •Вопросы к экзамену по курсу "Технология программирования"
- •История развития языков программирования высокого уровня.
- •Архитектура языков программирования (три поколения).
- •Архитектура объектно-ориентированных языков программирования.
- •Сложность, присущая по (основные причины). Проблемы, возникающие при создании сложных систем.
- •Структура сложных систем (пять признаков). Примеры сложных систем (выделить признаки).
- •Основные понятия: метод, методология, технология. Классификация методов проектирования пс. Общая характеристика методов проектирования.
- •Эволюция программного продукта. Основные определения, понятия, отличительные черты.
- •Понятие «модуль» в программировании. Различные виды модулей при использовании основных методов проектирования пс.
- •Case – технологии (инструменты, системы, средства). Эволюция case – средств, их классификация, характеристики современных case – инструментов. Перспективы развития.
- •Роль case – инструментов в объектно-ориентированной методологии разработки пс. Связь case – технологии с методами быстрой разработки приложений (rad).
- •Классификация средств разработки (case - инструментов).
- •Жизненный цикл по (жц). Структура жц, основные фазы жц.
- •Организация процесса разработки пс (методы, средства, процедуры).
- •Модели процесса разработки пс (каскадная, спиральная)
- •Модели процесса разработки пс (компонентно-ориентированная, инкрементная, rad – модель).
- •Тяжеловесные и облегченные процессы разработки пс.
- •Унифицированный процесс разработки пс.
- •Iconix – процесс.
- •Scrum – процесс.
- •Артефакты
- •Встречи
- •Планирование спринта происходит в начале итерации(не более 4-8 часов), выбирается что будет сделано и обсуждается как это будет сделано.
- •Митинг Происходит каждый день в течение спринта(не более 15 минут), ищутся ответы на вопросы: что сделано? Что надо сделать? Какие есть проблемы?
- •Демонстрация проходит в конце спринта(не более 4-8 часов), показывается инкремент.
- •Прототип системы (достоинства и недостатки макетирования).
- •Масштаб проекта и риски
- •Содержание основных рабочих процессов по созданию по (анализ требований, системный анализ, проектирование).
- •Содержание основных рабочих процессов по созданию по (кодирование, тестирование).
- •Изменения в процессе эволюции программных систем, стоимость каждого вида изменения (в смысле затрат).
- •Организационные процессы (распределение ресурсов, управление проектом, организация коллектива разработчиков).
- •Документирование программного продукта. Различные виды документов, их содержание.
- •Виды документов при использовании объектно-ориентированной методологии разработки пс.
- •Временные затраты на реализацию этапов разработки по. Особенности распределения ресурсов при использовании объектно-ориентированной методологии.
- •Методы и средства структурного анализа.
- •Диаграммы потоков данных с расширениями для реального времени.
- •Пример банковской задачи (провести анализ).
- •Средства структурного проектирования (карты Константайна).
- •Методы проведения анализа объектно-ориентированных систем.
- •Типовая и структурная иерархии в объектно-ориентированной методологии.
- •Унифицированный язык моделирования пс (uml). Словарь, достоинства и возможности
- •Механизмы расширения в uml.
- •Диаграммы классов (точки зрения).
- •Отношения в диаграмме классов.
- •Классы ассоциаций.
- •Диаграммы вариантов использования, реализации вариантов использования.
- •Диаграммы взаимодействий.
- •Диаграммы пакетов и компонентов.
- •Диаграммы состояний.
- •Диаграммы активности (деятельностей).
- •Каркасы и паттерны.
- •Основные понятия и определения теории тестирования. Подходы к тестированию. Стратегии тестирования. Критерии тестирования.
- •Критерии тестирования стратегии "черного ящика".
- •1. Эквивалентное разбиение (самый популярный критерий из-за простоты)
- •2. Анализ граничных условий.
- •3. Метод функциональных диаграмм
- •Классический процесс тестирования по.
- •Тестирование модулей (блоков) программы. Тестирование интеграции.
- •Тестирование правильности (функциональное тестирование). Системное тестирование.
- •Особенности тестирования объектно-ориентированных программ. Тестирование классов.
- •Тестирование взаимодействия классов и функционирования компонентов.
- •Вопросы автоматизации тестирования. Инструменты тестирования.
Особенности тестирования объектно-ориентированных программ. Тестирование классов.
Основные отличия процесса тестирования объектных программ от традиционных (процедурных) следуют из самого подхода к разработке ПО. А именно: аналитические модели непосредственно отображаются на проектные модели, которые в свою очередь отображаются на программы.
Практически отдают предпочтение следующему многократно повторяемому процессу:
- Немного анализа
- Немного проектных решений
- Немного программных кодов
- Тестировать все, что можно.
Рассмотрим кратко, какие виды тестирования должны проводиться для ОО-го ПО. На практике следуют такому порядку:
- Тестирование моделей (аналитических и проектных).
- Тестирование классов (вместо тестирования модулей).
- Тестирование взаимодействий и функционирования компонентов.
- Тестирование подсистем и систем.
- Приемочные испытания.
Основной метод (эффективный) здесь – метод целенаправленной проверки (инспекции). Для этой цели используются следующие виды диаграмм: диаграммы UseCase с описанием (текстовым) каждого варианта использования; диаграммы последовательностей для сценариев каждого варианта использования, диаграммы классов анализа и проектные диаграммы (описывают архитектуру ПО); диаграммы состояний объектов класса и диаграммы действий, которые являются комбинацией нотаций блок-схем и сетей Петри, и которые создаются для описания алгоритма метода класса или для описания алгоритма всей программы.
-------- Тестирование классов ------------
В первом приближении тестирование классов аналогично тестированию модулей в традиционных процессах тестирования. А именно – разрабатывается тестовый драйвер, который создает один или большее число экземпляров класса. Драйвер будет осуществлять прогон тестов.
Самый простой критерий тестирования класса – это полное покрытие его программного кода (белый ящик) Но чаще всего тестируемый класс рассматривается как «черный ящик», т.е. тесты готовятся на основе спецификации класса.
В любом случае тестирование класса должно проводиться до того, как возникнет необходимость использования этого класса в других компонентах ПО. И каждый раз, когда меняется что-то в реализации класса, должно проводиться регрессионное тестирование этого класса.
Тестирование взаимодействия классов и функционирования компонентов.
У большинства классов имеются партнеры по сотрудничеству, т. е. методы такого класса взаимодействуют с экземплярами других классов.
Рассмотрим случаи, когда между классами установлены отношения ассоциации. Основное назначение тестирования взаимодействий состоит в том, чтобы убедиться, что происходит правильный обмен сообщений между объектами, классы которых прошли тестирование в автономном режиме.
Выявить такие классы можно на диаграмме классов (или по спецификации классов). Процесс тестирования взаимодействий классов заметно облегчается, если число связей между ними невелико. Тогда не придется создавать много программ-драйверов.
Можно отметить, что для выявления всех связей классов особенно полезны диаграммы классов и диаграммы последовательностей. Они показывают, каким классам (объектам) нужен тестируемый класс, т.е. кто использует заявленные операции класса. И – наоборот, к операциям каких классов обращаются объекты тестируемого класса.