- •Вопросы к экзамену по курсу "Технология программирования"
- •История развития языков программирования высокого уровня.
- •Архитектура языков программирования (три поколения).
- •Архитектура объектно-ориентированных языков программирования.
- •Сложность, присущая по (основные причины). Проблемы, возникающие при создании сложных систем.
- •Структура сложных систем (пять признаков). Примеры сложных систем (выделить признаки).
- •Основные понятия: метод, методология, технология. Классификация методов проектирования пс. Общая характеристика методов проектирования.
- •Эволюция программного продукта. Основные определения, понятия, отличительные черты.
- •Понятие «модуль» в программировании. Различные виды модулей при использовании основных методов проектирования пс.
- •Case – технологии (инструменты, системы, средства). Эволюция case – средств, их классификация, характеристики современных case – инструментов. Перспективы развития.
- •Роль case – инструментов в объектно-ориентированной методологии разработки пс. Связь case – технологии с методами быстрой разработки приложений (rad).
- •Классификация средств разработки (case - инструментов).
- •Жизненный цикл по (жц). Структура жц, основные фазы жц.
- •Организация процесса разработки пс (методы, средства, процедуры).
- •Модели процесса разработки пс (каскадная, спиральная)
- •Модели процесса разработки пс (компонентно-ориентированная, инкрементная, rad – модель).
- •Тяжеловесные и облегченные процессы разработки пс.
- •Унифицированный процесс разработки пс.
- •Iconix – процесс.
- •Scrum – процесс.
- •Артефакты
- •Встречи
- •Планирование спринта происходит в начале итерации(не более 4-8 часов), выбирается что будет сделано и обсуждается как это будет сделано.
- •Митинг Происходит каждый день в течение спринта(не более 15 минут), ищутся ответы на вопросы: что сделано? Что надо сделать? Какие есть проблемы?
- •Демонстрация проходит в конце спринта(не более 4-8 часов), показывается инкремент.
- •Прототип системы (достоинства и недостатки макетирования).
- •Масштаб проекта и риски
- •Содержание основных рабочих процессов по созданию по (анализ требований, системный анализ, проектирование).
- •Содержание основных рабочих процессов по созданию по (кодирование, тестирование).
- •Изменения в процессе эволюции программных систем, стоимость каждого вида изменения (в смысле затрат).
- •Организационные процессы (распределение ресурсов, управление проектом, организация коллектива разработчиков).
- •Документирование программного продукта. Различные виды документов, их содержание.
- •Виды документов при использовании объектно-ориентированной методологии разработки пс.
- •Временные затраты на реализацию этапов разработки по. Особенности распределения ресурсов при использовании объектно-ориентированной методологии.
- •Методы и средства структурного анализа.
- •Диаграммы потоков данных с расширениями для реального времени.
- •Пример банковской задачи (провести анализ).
- •Средства структурного проектирования (карты Константайна).
- •Методы проведения анализа объектно-ориентированных систем.
- •Типовая и структурная иерархии в объектно-ориентированной методологии.
- •Унифицированный язык моделирования пс (uml). Словарь, достоинства и возможности
- •Механизмы расширения в uml.
- •Диаграммы классов (точки зрения).
- •Отношения в диаграмме классов.
- •Классы ассоциаций.
- •Диаграммы вариантов использования, реализации вариантов использования.
- •Диаграммы взаимодействий.
- •Диаграммы пакетов и компонентов.
- •Диаграммы состояний.
- •Диаграммы активности (деятельностей).
- •Каркасы и паттерны.
- •Основные понятия и определения теории тестирования. Подходы к тестированию. Стратегии тестирования. Критерии тестирования.
- •Критерии тестирования стратегии "черного ящика".
- •1. Эквивалентное разбиение (самый популярный критерий из-за простоты)
- •2. Анализ граничных условий.
- •3. Метод функциональных диаграмм
- •Классический процесс тестирования по.
- •Тестирование модулей (блоков) программы. Тестирование интеграции.
- •Тестирование правильности (функциональное тестирование). Системное тестирование.
- •Особенности тестирования объектно-ориентированных программ. Тестирование классов.
- •Тестирование взаимодействия классов и функционирования компонентов.
- •Вопросы автоматизации тестирования. Инструменты тестирования.
Диаграммы потоков данных с расширениями для реального времени.
DFD — от англ. Data Flow Diagrams — диаграммы потоков данных.
Диаграммы потоков данных (DFD) являются основным средством моделирования функциональных требований к проектируемой системе. С их помощью эти требования представляются в виде иерархии функциональных компонентов (процессов), связанных потоками данных. Главная цель такого представления - продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.
Для построения DFD традиционно используются две различные нотации, соответствующие методам Йордана и Гейна - Сэрсона. Эти нотации незначительно отличаются друг от друга графическим изображением символов.
Основные символы для записи DFD:
Потоки данных являются механизмами, использующимися для моделирования передачи информации (или даже физических компонент) из одной части системы в другую.
Процесс выполняет преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом.
Хранилище данных позволяет на определенных участках определять данные, которые будут сохраняться в памяти между процессами.
Внешняя сущность представляет сущность вне контекста системы, являющуюся источником или приемником системных данных. Ее имя должно содержать существительное.
Декомпозиция DFD осуществляется на основе функциональных процессов: каждый процесс может раскрываться с помощью DFD нижнего уровня
Расширения реального времени используются для дополнения модели средствами описания управляющих аспектов в системах реального времени. Для этих целей применяются следующие элементы:
1.Управляющий процесс. Управляющий процесс представляет собой преобразователь входных управляющих потоков в выходные управляющие потоки; при этом точное описание этого преобразования должно задаваться в спецификации управления.
2.Управляющее хранилище. Представляет "срез" управляющего потока во времени. Управляющее хранилище отличается от традиционного тем, что может содержать только управляющие потоки; все другие их характеристики идентичны.
3.Управляющий поток. Представляет собой "трубопровод", через который проходит управляющая информация. Его имя не должно содержать глаголов, а только существительные и прилагательные. Обычно управляющий поток имеет дискретное, а не непрерывное значение.
Пример банковской задачи (провести анализ).
Короче, это она сказала вроде не будет в билетах.
Спецификации управления (на уровне STD - диаграммы). using namespace std;
Спецификации управления предназначены для моделирования и документирования аспектов систем, зависящих от времени (или реакции на событие). Для этой цели используются STD-диаграммы переходов состояний.
Рассмотрим кратко основные символы STD.
Начальное состояние – узел STD, который является стартовой точкой для начального системного перехода.
Состояние может рассматриваться как условие устойчивости для системы. Находясь в определённом состоянии, мы имеем достаточно информации о прошлой истории системы, чтобы определить очередное состояние в зависимости от текущих входных событий. Поэтому имя состояния должно отражать реальную ситуацию, в которой находится система. Например, НАГРЕВАНИЕ, ОХЛАЖДЕНИЕ и т.п.
Переход определяет перемещение моделируемой системы из одного состояния в другое. При этом имя перехода определяет событие, которое является условием (причиной) перехода. Это событие обычно состоит из управляющего потока (сигнала). Управляющий сигнал может возникать как во внешнем мире, так и внутри моделируемой системы при выполнении некоторого условия. Например, СЧЁТЧИК=999 или кнопка нажата. При изменении состояния система также обычно выполняет действия (например, выдаёт сообщение на дисплей, выполняет вывод или производит вычисления).