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