Применение UML 2.0 и шаблонов проектирования. Практическое руководство. 3-е издание

Применение UML 2.0 и шаблонов проектирования. Практическое руководство. 3-е издание
Автор: Крэг Ларман
Год: 2013
ISBN: 978-5-8459-1185-8
Страниц: 736
Язык: Русский
Формат: PDF
Размер: 58 Мб

Download

В книге рассматриваются основные принципы и приемы объектно-ориентированного анализа и проектирования (ООА/П). В ней вы найдете сведения об итеративном и гибком моделировании, шаблонах проектирования, архитектурном анализе и многих других вопросах. Весь материал рассматривается в контексте гибкого подхода к разработке с совместным применением процесса UP и других итеративных методов.
В книге рассматривается два реальных примера, позволяющих на практике освоить принципы ООА/П, а также изучить новейшую систему обозначений языка UML 2.
Книга будет хорошим руководством для всех, кто интересуется вопросами ООА/П, языком моделирования UML 2 и современными эволюционными подходами к разработке программного обеспечения.

+

Что вы узнаете из этой книги? Какой смысл вкладывается в понятие “хорошо спроектированная объектно-ориентированная система”? Эта книга поможет разработчикам и студентам получить практические навыки объектно-ориентированного анализа и проектирования (ООА/П). Такие навыки необходимы для разработки профессиональных, робастных программных систем, созданных на основе объектной технологии проектирования и с помощью объектно-ориентированных языков программирования типа Java или С#.

Пример: POS-система NextGen

В следующих разделах описывается применение шаблонов и базовых принципов проектирования для реализации следующих требований третьей итерации разработки системы NextGen.

  • Обработки отказа удаленных служб с помощью локальных
  • Локальное кеширование
  • Поддержка дополнительных устройств для POS-системы, например различных типов сканеров
  • Обработка платежей по кредитной или дебетной карточке, а также оплата чеком

Переход к локальным службам
и обеспечение локальной буферизации

Требования к приложению NextGen предусматривают защиту от отказов удаленных служб, например временной недоступности базы данных.

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

Напомним фрагмент технического описания.

Архитектурное представление
(Краткое описание структуры этого документа. Это полезно для читателей, не знакомых с идеей
технических описаний или представлений. Заметим, что все представления описывать не обязательно.)

Архитектурные факторы
(Сослаться на таблицу факторов в дополнительной спецификации.)

Архитектурные решения
(Привести технические описания основных решений.)

Логическое представление
(Диаграммы UML пакетов, классов и основных элементов. Основные элементы нужно прокомментировать.)

Представление развертывания
(Диаграммы развертывания UML, отражающие распределение процессов и компонентов по
узлам сети с комментариями по организации сети.)

Представление процессов
(Диаграммы UML классов и взаимодействия, иллюстрирующие процессы и потоки в системе.
Взаимосвязанные потоки и процессы нужно сгруппировать, а их совместную работу прокоммен
тировать (например, с помощью RMI).)

Представление прецедентов
(Краткое описание наиболее архитектурно важных прецедентов. Диаграммы взаимодействия
UML для реализаций некоторых архитектурно значимых прецедентов или их сценариев с ком
ментариями относительно основных архитектурных элементов.)

Другие представления

Как спланировать итерацию

Существует много подходов к планированию итераций, но все они сводятся примерно к следующему.

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

2. Затем проводится совещание по планированию следующей итерации. Если текущая итерация завершается в пятницу, то именно в этот день проводится совещание по планированию следующей итерации, которая должна начаться в
понедельник. В идеале на подобной встрече должны присутствовать все заинтересованные лица: пользователи, разработчики, главный архитектор, менеджер
проекта и т.д.

3. Составляется список потенциальных целей следующей итерации. Эти цели ранжируются в соответствии с некоторыми приоритетами. Перечень целей обыч
но составляют потребители (они формулируют бизнес-цели проекта) совместно
с главным архитектором (он отвечает за формулировку технических целей).

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

5. Одна из целей итерации (например, реализация прецедента) описывается во
всех деталях. Затем проводится семинар разработчиков, на котором методом
мозгового штурма определяются основные задачи по достижению этой цели.
• Все задачи интегрируются в одну схему.

6. Шаг 5 повторяется до тех пор, пока не будут рассмотрены все задачи итерации.
Если объем работ примерно соответствует имеющимся в наличии ресурсам и
задачи итерации могут быть выполнены в срок, семинар завершается.Обратите внимание, что при подобном гибком подходе к управлению проектами
разработчики активно привлекаются к процессу планирования и оценивания, а не
просто ставятся перед фактом.