Дать понятие шаблоны проектирования. Перечислить порождающие шаблоны. Описать использование порождающих шаблонов.

Шаблон проектирования (паттерн) — повторимая архитектурная конструкция, представляющая собой решение проблемы проектирования в рамках некоторого часто возникающего контекста.

 

К порождающим шаблонам относятся:

- Абстрактная фабрика (abstract factory) -предоставление интерфейса для создания семейств связанных между собой или зависимых друг от друга объектов без указания их конкретных классов

Фабрика должна иметь операции, которые создают новые объекты, объекты, называют продуктами.

- Шаблон Строитель. Упрощает создание сложных объектов путем определения класса, предназначенного для построения экземпляров другого класса.

Шаблон Builder генерирует только одну сущность. Хотя эта сущность в свою очередь может содержать более одного класса, но один из полученных классов всегда является главным.

- Шаблон Фабричный метод. Определяет стандартный метод создания объекта, не связанный с вызовом конструктора, оставляя решение о том, какой именно объект создавать, за одноклассами.

- Шаблон Прототип. Облегчает динамическое создание путем определения классов, объекты которых могут создавать собственные дубликаты.

Задаёт виды создаваемых объектов с помощью экземпляра-прототипа и создаёт новые объекты путём копирования этого прототипа.

Это паттерн создания объекта через клонирование другого объекта вместо создания через конструктор.

- Шаблон Одиночка. Обеспечивает наличие в системе только одного экземпляра заданного класса, позволяя другим классам получать доступ к этому экземпляру.

 

Сформулировать понятие экстремального программирования (ХР). Раскрыть принципы и методики ХР, единая команда, короткие циклы, стандарты кодирования.

Экстремальное программирование – это упрощенная методика организации производства для небольших и средних по размеру команд специалистов, занимающихся разработкой программного продукта в условиях неясных и быстро меняющихся требований.

 

Признаки применения:

ü Короткие циклы;

ü  Планирование по нарастающей;

ü  Гибкий график реализации функциональности;

ü  XP базируется на автоматических тестах, разработанных и программистами, и заказчиками;

ü  Обмен сведениями через общение, тесты и исходный код;

ü  Эволюционирующий дизайн.

 

Виды рисков:

ü  Смещение графиков;

ü  Закрытие проекта;

ü  Система теряет полезность;

ü  Велико количество дефектов и недочетов системы;

ü  Несоответствие системы решаемой проблеме;

ü  Изменение характера бизнеса;

ü  Недостаток возможностей системы;

ü  Текучка кадров.

 

Базовые принципы:

ü Быстрая обратная связь;

ü  Приемлемая простота;

ü  Постепенное изменение;

ü  Приемлемые изменения;

ü  Качественная работа.

 

Менее важные принципы:

ü Обучение обучению;

ü небольшие начальные инвестиции;

ü игра для того, чтобы победить;

ü надежное экспериментирование;

ü открытая честная коммуникация;

ü работа в соответствии с человеческими инстинктами;

ü принимаемая ответственность;

ü локальная адаптация;

ü «путешествие налегке»;

ü откровенные оценки.

 

Базис ХР образуют перечисленные ниже двенадцать методов:

1. Игра планирования (Planninggame) — быстрое определение области действия следующей реализации путем объединения деловых приоритетов и технических оценок. Заказчик формирует область действия, приоритетность и сроки с точки зрения бизнеса, а разработчики оценивают и прослеживают продвижение (прогресс).

2. Частая смена версий (Smallreleases) — быстрый запуск в производство простой системы. Новые версии реализуются в очень коротком (двухнедельном) цикле.

3. Метафора (Metaphor) — вся разработка проводится на основе простой, общедоступной истории о том, как работает вся система.

4. Простое проектирование (Simpledesign) — проектирование выполняется настолько просто, насколько это возможно в данный момент.

5. Тестирование (Testing) — непрерывное написание тестов для модулей, которые должны выполняться безупречно; заказчики пишут тесты для демонстрации законченности функций. «Тестируй, а затем кодируй» означает, что входным критерием для написания кода является «отказавший» тестовый вариант.

6. Реорганизация (Refactoring) — система реструктурируется, но ее поведение не изменяется; цель — устранить дублирование, улучшить взаимодействие, упростить систему или добавить в нее гибкость.

7. Парное программирование (Pairprogramming) — весь код пишется двумя программистами, работающими на одном компьютере.

8. Коллективное владение кодом (Collectiveownership) — любой разработчик может улучшать любой код системы в любое время.

9. Непрерывная интеграция (Continuousintegration) — система интегрируется и строится много раз в день, по мере завершения каждой задачи. Непрерывное регрессионное тестирование, то есть повторение предыдущих тестов, гарантирует, что изменения требований не приведут к регрессу функциональности.

10. 40-часовая неделя (40-hour week) — как правило, работают не более 40 часов в неделю. Нельзя удваивать рабочую неделю за счет сверхурочных работ.

11. Локальный заказчик (On-sitecustomer) — в группе все время должен находиться представитель заказчика, действительно готовый отвечать на вопросы разработчиков.

12. Стандарты кодирования (Codingstandards) — должны выдерживаться правила, обеспечивающие одинаковое представление программного кода во всех частях программной системы.

Три ключевых фактора:

ü Простой дизайн без лишних элементов;

ü  Автоматические тесты;

ü  Постоянная практика в деле модификации дизайна системы.

Стандарты кодирования ПО

Целью стандартов кодирования ПО является определение языков программирования, методов, правил и инструментальных средств, которые будут использованы для кодирования ПО. Стандарты кодирования должны включать в себя:

— используемые языки программирования и/или какое-либо их заданное подмножество; должна быть указана ссылка на документы, которые однозначно определяют синтаксис, режим контроля, характер данных и побочные эффекты языка программирования; стандарты могут требовать ограничений на использование некоторых возможностей языка;

— стандарты представления исходного текста (например, ограничение на длину строки, структурное расположение текста, использование пустых строк) и стандарты документирования исходного кода (например, имя автора, история изменений, входные и выходные данные, а также наиболее значимые глобальные данные);

— соглашения по наименованию для компонентов, подпрограмм, переменных, констант;

— условия и ограничения, налагаемые на установленные соглашения кодирования, такие как информационная связность между компонентами ПО, сложность логических или числовых выражений, а также обоснования для их использования;

— ограничения на использование инструментальных средств кодирования.