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

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

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

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

Цели анализа

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

Задачи

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

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

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

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

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

Требования

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

• возможность участия в анализе и обсуждении результатов неспециалистов в области ПО (A1, A2);
• форма представления результатов анализа должна быть непосредственно пригодной для разработчиков ПО (A7);
• масштабируемость решения (A1);
• нотация не должна допускать неоднозначного толкования (A3);
• возможность для читателя быстро получить общее представление об организации системы или подсистемы (A1, A7).

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

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

Облака и провалы

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

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

Боязнь риска чрезмерной спецификации характерна для людей, занимающихся анализом. (Говорят, что в этом кругу для уничтожения автора, предлагающего подход X, достаточно сказать "Подход X хорош, но разве он не дитя подхода, ориентированного на реализацию?") По этой причине при проведении анализа часто впадают в другую крайность, полагаясь на описание целостной картины, используя графическую нотацию (часто в виде облаков), неспособную выразить семантические свойства, тогда как для достижения цели A2 требуются точные ответы на конкретные вопросы.

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

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