ВОПРОСЫ
по курсу «Программное обеспечение»
осень 2013, гр. 30309Б, 30310Б
Определение (синтаксис и семантика) класса и его компонентов в C++, C# Microsoft Visual Studio. Примеры.
Назначение и определение конструкторов и деструкторов в классе. Техника создания и использования объектов. Примеры на C++.
Назначение и особенности событий, вызываемых нажатием клавиши (onKeyDown, onKeyPress и onKeyUp). Примеры использования.
Полиморфизм как свойство объектно-ориентированного стиля программирования. Примеры.
Объектная структура визуальной среды программирования Microsoft Visual Studio. Структура проекта.
Обеспечение выделения (selection) подстроки. Свойства SelStart, SelLength и SelText в строке в оконном компоненте. Установка фокуса.
Назначение и определение события в Microsoft Visual Studio. Определение делегата.
Обзор шаблонов проектирования GOF.
Шаблон “Издатель/подписчик” на C#.
Наблюдатель (англ. Observer) — поведенческий шаблон проектирования. Также известен как «подчинённые» (Dependents), «издатель-подписчик» (Publisher-Subscriber). Создает механизм у класса, который позволяет получать оповещения от других классов об изменении их состояния, тем самым наблюдая за ними.
При реализации шаблона «наблюдатель» обычно используются следующие классы:
Observable — интерфейс, определяющий методы для добавления, удаления и оповещения наблюдателей;
Observer — интерфейс, с помощью которого наблюдатель получает оповещение;
ConcreteObservable — конкретный класс, который реализует интерфейс Observable;
ConcreteObserver — конкретный класс, который реализует интерфейс Observer.
Шаблон “Фабрика компонентов”.
Шаблон “Мост” (Bridge).
Шаблон мост (англ. Bridge) — структурный шаблон проектирования, используемый в проектировании программного обеспечения чтобы «разделять абстракцию и реализацию так, чтобы они могли изменяться независимо». Шаблон bridge (от англ. — мост) использует инкапсуляцию, агрегирование и может использовать наследование для того, чтобы разделить ответственность между классами.
Потоки и примеры на создание и синхронизацию потоков в C#.
Пример на синхронизацию потоков “часы».
Шаблон “цепочка ответственности”.
Особенности жизненного цикла программных продуктов. Стандарт ISO 12207.
Принципы организации проектирования программ в технологии RUP
Диаграммы классов и последовательностей в технологии проектирования программ Rational Unified Process (RUP).
Каскадные и итерационные технологии проектирования программ. Принципы, преимущества и недостатки. “Спираль” Боэма.
Наиболее широко известной и применяемой долгое время оставалась так называемая каскадная или водопадная (waterfall) модель жизненного цикла, которая, как считается, была впервые четко сформулирована в работе и впоследствии была запечатлена в стандартах министерства обороны США в семидесятых-восьмидесятых годах XX века. Эта модель предполагает последовательное выполнение различных видов деятельности, начиная с выработки требований и заканчивая сопровождением, с четким определением границ между этапами, на которых набор документов, выработанной на предыдущей стадии, передается в качестве входных данных для следующей. Таким образом, каждый вид деятельности выполняется на какой-то одной фазе жизненного цикла. «Классическая» каскадная модель предполагает только движение вперед по этой схеме: все, необходимое для проведения очередной деятельности, должно быть подготовлено в ходе предшествующих работ.
Однако если внимательно прочитать статью, оказывается, что она не предписывает следование именно этому порядку работ, а скорее, представляет модель итеративного процесса — в ее последовательном виде эта модель закрепилась, скорее, в представлении чиновников из министерств и управленцев компаний, работающих с этими министерствами по контрактам. При реальной работе в соответствии с моделью, допускающей движение только в одну сторону, обычно возникают проблемы при обнаружении недоработок и ошибок, сделанных на ранних этапах. Но еще более тяжело иметь дело с изменениями окружения, в котором разрабатывается ПО (это могут быть изменения требований, смена подрядчиков, изменения политик разрабатывающей или эксплуатирующей организации, изменения отраслевых стандартов, появление конкурирующих продуктов и пр.).
Работать в соответствии с этой моделью можно, только если удается предвидеть заранее возможные перипетии хода проекта и тщательно собирать и интегрировать информацию на первых этапах, с тем, чтобы впоследствии можно было пользоваться их результатами без оглядки на возможные изменения.
Среди разработчиков и исследователей, имевших дело с разработкой сложного ПО, практически с самого зарождения индустрии производства программ большую популярность имели модели эволюционных или итеративных процессов, поскольку они обладают большей гибкостью и способностью работать в меняющемся окружении.
Итеративные или инкрементальные модели (известно несколько таких моделей) предполагают разбиение создаваемой системы на набор кусков, которые разрабатываются с помощью нескольких последовательных проходов всех работ или их части.
На первой итерации разрабатывается кусок системы, не зависящий от других. При этом большая часть или даже полный цикл работ проходится на нем, затем оцениваются результаты и на следующей итерации либо первый кусок переделывается, либо разрабатывается следующий, который может зависеть от первого, либо как-то совмещается доработка первого куска с добавлением новых функций. В результате на каждой итерации можно анализировать промежуточные результаты работ и реакцию на них всех заинтересованных лиц, включая пользователей, и вносить корректирующие изменения на следующих итерациях. Каждая итерация может содержать полный набор видов деятельности от анализа требований, до ввода в эксплуатацию очередной части ПО.
Каскадная модель с возможностью возвращения на предшествующий шаг при необходимости пересмотреть его результаты, становится итеративной.
Итеративный процесс предполагает, что разные виды деятельности не привязаны намертво к определенным этапам разработки, а выполняются по мере необходимости, иногда повторяются, до тех пор, пока не будет получен нужный результат.
Вместе с гибкостью и возможностью быстро реагировать на изменения итеративные модели привносят дополнительные сложности в управление проектом и отслеживание его хода. При использовании итеративного подхода адекватно оценить текущее состояние проекта и спланировать долгосрочное развитие событий, а также предсказать сроки и ресурсы, необходимые для обеспечения определенного качества результата, значительно сложнее, чем для каскадных проектов (конечно, при отсутствии изменений, влияющих на ход последних).
Развитием идеи итераций является спиральная модель жизненного цикла ПО, предложенная Боэмом. Она предлагает каждую итерацию начинать с выделения целей и планирования очередной итерации, определения основных альтернатив и ограничений при ее выполнении, их оценки, а также оценки возникающих рисков и определения способов избавления от них, а заканчивать итерацию оценкой результатов проведенных в ее рамках работ.
Основным ее новым элементом является общая структура действий на каждой итерации — планирование, определение задач, ограничений и вариантов решений, оценка предложенных решений и рисков, выполнение основных работ итерации и оценка их результатов.
Название спиральной эта модель получила из-за изображения хода работ в «полярных координатах», в которых угол соответствует выполняемому этапу в рамках общей структуры итераций, а удаление от начала координат — затраченным ресурсам.
Рис. 5 показывает возможное развитие проекта по спиральной модели — количество витков, а также расположение и набор видов деятельности в правом нижнем квадранте могут изменяться в зависимости от результатов планирования и анализа рисков, проводимых на предыдущих этапах.
На следующей лекции мы рассмотрим в деталях два современных итеративных процесса разработки — унифицированный процесс разработки Rational и экстремальное программирование.
Адаптивные технологии. Принципы scrum. Экстремальное программирование.
Адаптивные процессы
В настоящее время все большее распространение получают адаптивные или облегченные, «живые» (agile) процессы разработки
Они не требуют столь жесткой регламентации, допускают возможность частых и существенных изменений требований заказчиков
Адаптивные процессы делают упор на использовании хороших разработчиков, а не хорошо отлаженных процессов разработки
Они избегают фиксации четких схем действий, чтобы обеспечить большую гибкость в каждом конкретном проекте и не требуют разработки дополнительных промежуточных документов
Принципы «живой» разработки
Основные принципы «живой» разработки ПО зафиксированы в манифесте, появившемся в 2000 году:
1.Люди, участвующие в проекте, и их общение более важны, чем процессы и инструменты
2.Работающая программа более важна, чем исчерпывающая документация
3.Сотрудничество с заказчиком более важно, чем обсуждение деталей контракта
4.Отработка изменений более важна, чем следование планам
Экстремальное программированиe
Extreme Programming, XP — авторы методологии — Кент Бек, Уорд Каннингем, Мартин Фаулер и другие.
Основные приёмы XP
· Короткий цикл обратной связи (Fine scale feedback)
o Разработка через тестирование (Test driven development)
o Игра в планирование (Planning game)
Заказчик всегда рядом (Whole team, Onsite customer)
o Парное программирование (Pair programming)
• Непрерывный, а не пакетный процесс
o Непрерывная интеграция (Continuous Integration)
o Рефакторинг (Design Improvement, Refactor)
o Частые небольшие релизы (Small Releases)
• Понимание, разделяемое всеми
o Простота (Simple design)
o Метафора системы (System metaphor)
o Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership)
o Стандарт кодирования (Coding standard or Coding conventions)
• Социальная защищенность программиста (Programmer welfare):
o 40-часовая рабочая неделя (Sustainable pace, Forty hour week)
Тестирование
В XP особое внимание уделяется двум разновидностям тестирования:
• тестирование модулей (unit testing);
• приемочное тестирование (acceptance testing).
Разработчик не может быть уверен в правильности написанного им кода до тех пор, пока не сработают абсолютно все тесты модулей разрабатываемой им системы. Тесты модулей позволяют разработчикам убедиться в том, что их код работает корректно. Они также помогают другим разработчикам понять, зачем нужен тот или иной фрагмент кода и как он функционирует. Тесты модулей также позволяют разработчику без каких-либо опасений выполнять рефакторинг (refactoring).
Приемочные тесты позволяют убедиться в том, что система действительно обладает заявленными возможностями. Кроме того, приемочные тесты позволяют проверить корректность функционирования разрабатываемого продукта.
Для XP более приоритетным является подход, называемый TDD (Test Driven Development) - сначала пишется тест, который не проходит, затем пишется код, чтобы тест прошел, а уже после делается рефакторинг кода.