Технология разработки программного обеспечения

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

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

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

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

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

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

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

3.5.3 Документация

После создания программного обеспечения можно написать документацию на готовый продукт с помощью UML. Диаграммы UML очень помогают понять систему в целом. Однако создание подробных диаграмм всей системы не является необходимым. Подробная документация скорее должна генерироваться на основе программного кода - так, как это делает, например JavaDoc. Для того чтобы подчеркнуть важные концепции, необходимо написать дополнительную документацию. Можно считать ее составной частью первого этапа знакомства с программой, предшествующего детальному изучению кода. Например, можно представлять документацию в виде достаточно краткого текста, снабженного диаграммами UML, придающими обсуждению наглядный характер.  Очевидно, что составитель документации должен решать, что важно, а что нет, поскольку разработчик вооружен для этого значительно лучше, чем читатель.

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

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

Диаграмму классов следует сопроводить несколькими диаграммами взаимодействий системы, которые показывают наиболее важные из них. Повторюсь: правильный отбор очень важен; помните, что в документации такого типа полнота - враг понятности.

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

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

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

3.5.4 Понимание унаследованного кода

Язык UML помогает вникнуть за пару дней в труднодоступную для понимания ветвь незнакомой программы. Построение эскиза ключевых аспектов системы может действовать как графический запоминающий механизм, который помогает зафиксировать важную информацию о системе в процессе ее изучения. Эскизы ключевых классов и их наиболее важных взаимосвязей помогают пролить свет на происходящее.

Современные инструменты позволяют генерировать подробные диаграммы ключевых разделов системы. Не следует применять эти инструменты для создания больших бумажных отчетов; лучше с их помощью вскрывать наиболее важные пласты исследуемого программного кода. Особенно радует, что есть возможность генерации диаграмм последовательности, позволяющих проследить взаимодействие множества объектов при реализации сложного метода.

Выводы

UML помогает в описании и проектировании программных систем, в особенности систем, построенных с использованием объектно-ориентированных (00) технологий. UML может использоваться в трех режимах: режим эскиза, режим проектирования и режим языка программирования. Безусловно, самый главный из трех – это режим использования UML для эскизирования. В одном из этих режимов он может использоваться на любой стадии разработки программного продукта.

Вопросы для самоконтроля к главе 3:

1. Что такое UML?
2. Каковы способы применения UML?
3. Что такое CASE-средства? В чем заключаются их достоинства и недостатки?
4. Опишите процесс разработки ПО с использованием UML.

Литература

1. Брукс Ф. Мифический человеко-месяц или как создаются программные системы.-Пер. с англ. –СПб.: Символ-Плюс
2. Гецци К., Джазайери М., Мандриоли Д. Основы инженерии программного обеспечения. 2-е изд.: Пер. с англ. – СПб.: БХВ-Петербург, 2005. – 832 с.:ил.
3. Фаулер М. UML. Основы, 3-е издание. – Пер. с англ. – СПб.:Символ-Плюс, 2006. – 192с., ил.
4. Буч Г., Якобсон А., Рамбо Дж. UML. Классика CS. 2-е изд./ Пер. с англ.; Под общей редакцией проф. С. Орлова – СПб.:Питер, 2006г.
5. Опалева Э.А., Самойленко В.П. Технология разработки программного обеспечения: Учебное пособие/ЛЭТИ.-Л, 1988г.
6. Липаев В.В Проектирование программных средств: Учебное пособие для вузов/В.В. Липаев. - М.:Высш. шк., 1990г.
7. Кобер Алистер Современные методы описания функциональных требований к системам, М.: Издательский дом "Лори", 2002г.
8. Фокс Дж. Программное обеспечение и его разработка.-М.:Мир, 1985г.
9. Мацяшек Л. Анализ требований и проектирование систем. Разработка информационных систем с использованием UML.-М.: Издательский дом "Вильямс", 2002г.
10. Соммервилл Иан.  Инжерия программного обеспечения,М.:Издательский дом "Вильямс",2002г.
11. Кинг Д. Создание эффективного программного обеспечения/Пер.а англ. Л.В.Ухова; Под ред. В.В. Мартынюка, 1991г.
12. Брауде Эрик Дж. Технологии разработки программного обеспечения - Спб.: Питер, 2004г
13. Ройс Уокер Управление проектами по созданию программного обеспечения, М.: Издательский дом "Лори", 2002