Требования

Задачи

Цели анализа

У5.13 Самодокументированное ПО

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

Тема 5. Объектно-ориентированный анализ

Для понимания задач необходимо разобраться в роли анализа в разработке ПО и определить требования к методу анализа.

Занимаясь анализом и создавая соответствующие документы, мы преследуем семь целей:

Если анализ применяется к не программной системе или не связан с решением создания ПО, то существенными будут только цели A1, A2 и A3.

В случае ПО предполагается, что анализ следует за этапом обоснования осуществимости (feasibility study) проекта, на основании которого принято решение о разработке системы. Иногда эти этапы объединены в один, поскольку для определения возможности достижения удовлетворительного результата требуется глубокий анализ. Тогда необходимо добавить пункт A0, обеспечивающий принятие решения о разработке.

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

Цели A2 и A3 наименее полно освещены в литературе и заслуживают особого внимания. Одним из важнейших преимуществ анализа вне зависимости от конечного результата является то, что в процессе его задаются важные вопросы (A2). Какова максимально допустимая температура? Какие категории служащих существуют? В чем разница между облигациями и акциями? Метод анализа позволяет развеять иногда фатальный для разработки туман двусмысленности, предоставляя специалистам данной конкретной области возможность подготовить необходимые исходные данные. Нет ничего хуже, чем обнаружить на завершающем этапе реализации, что маркетинг и технические отделы заказчика имеют противоречивые взгляды на обслуживание оборудования, по умолчанию учитывалась только одна из этих позиций, и никто не догадался уточнить требования заказчика. Именно к пункту A2 постоянно возвращаются в процессе анализа, если возникают тонкие вопросы или противоречивые интерпретации.

Практические требования к процессу анализа и поддерживающей нотации следуют из приведенного списка целей:

· возможность участия в анализе и обсуждении результатов неспециалистов в области ПО (A1, A2);

· форма представления результатов анализа должна быть непосредственно пригодной для разработчиков ПО (A7);

· масштабируемость решения (A1);

· нотация не должна допускать неоднозначного толкования (A3);

· возможность для читателя быстро получить общее представление об организации системы или подсистемы (A1, A7).

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

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