Экстремальная разработка программного обеспечения по концепции xp

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

НИР — научно-исследовательская работа.

Ключевые концепции XP: 1. Постановка задачи только по определенным в настоящее время требованиям. Задача ставится согласно тем требованиям, которые в данный момент выдвинуты или сформулированы настолько однозначно и четко, что или уже детализированы (формализированны), или в кратчайшее время могут быть детализированы на уровне, позволяющем быстро выполнить программную реализацию соответствующему функционалу. 2. Проектирование максимально простой архитектуры продукта. Программа проектируется настолько просто, насколько это возможно без опережающего учета возможного в будущем функционала. В архитектуру закладываются только те функции, которые необходимы и точно определены в данный момент. 3. Максимально быстрое получение первой работающей версии программы. [Такую версию называют «Рыба»] 4. Разработка на основе тестов. [Заказчик даёт тесты] 5. Коррекция ТЗ и архитектуры программы. 6. Систематические сборки с тестированием и отладкой. Разработка программного продукта выполняется короткими временными отрезками, и после завершения очередного отрезка выполняется сборка программы с тестированием и отладкой. Такой пошаговый контроль облегчает локализацию и устранение ошибок. 7. Частая подготовка промежуточных версий продукта. 8. Рефакторинг (регулярная переработка кода). Оптимизация кода программистами с целью внедрения более эффективных алгоритмов. После каждой такой оптимизации программа проходит проверку на тестах, которая гарантирует сохранение работоспособности продукта. 9. Программирование в паре. Программная реализация каждого выделенного фрагмента выполняется кодерами. Один занимается кодированием, другой анализирует работу первого, оценивая выборные алгоритмы и их реализацию, предлагая более эффективные решения, отслеживая качество кода и т. д. 10. Соблюдение единого стандарта кодирования. 11. Взаимодействие с заказчиком. Получение ответов на вопросы.

Экстремальное программирование. Достоинства: — большая гибкость, динамичность. — высокое качество многократной отладки кода. — минимальный объем сопроводительной документации. Недостатки: — трудоемкость подхода (частое тестирование, отладка, рефакторинг). — плохо поддается планированию (с точки зрения определенного конечного срока сдачи проекта).

Пример. C3. Chrysler Comprehensive Compensation System. [система, построенная с использованием языка программирования SmallTalk и объектно-ориентированной системой управления базами данных GemStone; проект стартовал в 1993 г., закрыт в 1999/2000 году; создатель — Том Хэдвилд (Tom Hadfield)]

Если требования проекта могут быть сформулированы достаточно исчерпывающим образом, то имеет смысл прибегать к более надежной стратегии разработки.

Стратегия rup Rational Unified Process

— для многоуровневого детального описания всех аспектов и этапов разработки ПО. Конечная цель: максимальная локализация постановки задачи для программистов.

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

Функциональные требования выражаются в виде сценариев использования (use case), который отображает необходимость взаимосвязи программы с пользователями или сторонними объектами.

КЛИЕНТ –––> СЕРВЕР

4 фазы жизненного цикла RUP: 1. Inception (начальная фаза). 2. Elaboration (фаза уточнения). 3. Construction (фаза реализации). 4. Transition (фаза внедрения).

Каждая фаза подразделяется на итерации, где под итерацией понимается законченный цикл разработки промежуточных версий программного продукта.

Базовые операции в каждой итерации RUP: 1. Определение требований. Детализируется спецификация проекта (ТЗ) с той особенностью, что требования к функциональным возможностям ПО описываются в виде сценариев использования на диаграмме сценариев (Use Case Diagram).

Пример. Интернет магазин по продаже деталей машин. [ссылка на сайт: exist.ru] Необходимые функции: 1. Поиск деталей. 2. Помещение деталей в корзину для покупок. 3. Редактирование корзины (удаление деталей, изменение их количества). 4. Оформление заказа с выбором способа оплаты. Последний сценарий можно разделить на два: 1) Оформление заказа. 2) Выбор способа оплаты.

Между этими функциями нужно установить такую связь (механизм подключения), чтобы при оформлении заказа пользователь мог выбрать новый способ оплаты или согласиться с вариантом по умолчанию.

Условный механизм подключения функций называется связью расширения (extends). extends ↓ оформление заказа <——— выбор способа оплаты

Если подключаемый сценарий (функция) должен вызываться в любом случае, то связь называется «includes».

[extends и includes в языке UML]

Пример. My Use Case:: Я иду в город. includes —> Водить машину (необходимое условие). extends —> Заполнить бензин (необязательное условие, так как бак может уже быть заполнен полностью). Необязательность является главным различием между includes и extends.

UML-нотация.

2. Анализ и проектирование. По требованиям технического описания разрабатывается и анализируется архитектура ПО, которая представляет собой взаимосвязанный набор внутренних структурных компонентов программного продукта. 1) Каждому сценарию использования (use case) сопоставляется диаграмма последовательности действия сценария (Sequence Diagram), которая отображает все действия в рамках данного сценария в виде обмена сообщениями между структурными компонентами (объектами), причем этот обмен на диаграмме упорядочен по времени передачи сообщений, т. е. выполнения соответствующих им действий.

2) С выделенными объектами связываются классы с определением их атрибутов и операций. Класс — группировка объектов с общими параметрами (свойствами, атрибутами), и связанными с ними методами (функциями). Пример. Класс — студент (student). Параметры класса: — Имя (тип string). — Фамилия (тип string). — Оценка за коллоквиум 1 (тип int). — Оценка за коллоквиум 2 (тип int). — Рейтинг (тип float).

Объекты класса (или экземпляры класса) отличаются конкретными значениями общих атрибутов.

Классы отображаются на диаграмме классов (class diagram).

Классы подразделяются на: 1. Информационные (Entity) (группировка обрабатываемых данных; роль контейнеров). 2. Интерфейсные (Boundary) (механизмы передачи данных). 3. Управленческие (Control) (преобразование данных и управление ими).

Для рассмотренной выше части интернет-магазина можно выделить: 1) Информационный класс данных по деталям, одна часть из которых предоставляется клиенту, а другая часть имеет внутрисистемный характер. 2) Информационный класс данных по корзине. 3) Информационный класс данных по заказу. 4) Интерфейсный класс, позволяющий инициировать поиск детали (по номеру, названию и т. д.). 5) Интерфейсный класс, который передает клиенту информацию о найденной детали и предоставляет возможность помещения детали в корзину. 6) Интерфейсный класс, позволяющий изменить содержимое корзины и перейти из нее к оформлению заказа. 7) Интерфейсный класс выбора способа оплаты. 8) Интерфейсный класс оформления заказа. 9) Управленческий класс поиска детали с формированием входных данных по ней. 10) Управленческий класс преобразования данных из корзины в данные по заказу.

3. Реализация. С созданными классами соотносятся компоненты реализации программного продукта на диаграмме компонентов (component diagram).