Объектно-ориентированный анализ и проектирование с примерами приложений на С++

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

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

Границы между стадиями анализа и проектирования размыты, но решаемые ими задачи определяются достаточно четко. В процессе анализа мы моделируем проблему, обнаруживая классы и объекты, которые составляют словарь проблемной области. При объектно-ориентированном проектировании мы изобретаем абстракции и механизмы, обеспечивающие поведение, требуемое моделью [Обозначения и процессы, описанные в этой книге, в равной степени относятся к фазам и анализа и проектирования (в традиционном понимании), как мы увидим в главе 6. Именно по этой причине мы сменили во втором издании название книги на "Объектно-ориентированный анализ и проектирование"].

Теперь мы рассмотрим несколько проверенных практикой подходов к анализу объектно-ориентированных систем.

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

Например, Шлаер и Меллор предлагают следующих кандидатов в классы и объекты [32]:  

∙ Осязаемые предметы   Автомобили, телеметрические данные, датчики давления 

 ∙ Роли   Мать, учитель, политик 

 ∙ События   Посадка, прерывание, запрос 

 ∙ Взаимодействие   Заем, встреча, пересечение 

  Что-то в этом роде предлагает Росс, исходя из перспектив моделирования баз данных [33]:  

∙ Люди   Человеческие существа, выполняющие некоторые функции 

 ∙ Места   Области, связанные с людьми или предметами 

 ∙ Предметы   Осязаемый материальный объект или группа объектов 

 ∙ Организации   Формально организованная совокупность людей, ресурсов, оборудования, которая имеет определенную цель и существование которой в целом не зависит от индивидуумов 

 ∙ Концепции   Принципы и идеи, сами по себе неосязаемые, но предназначенные для организации деятельности и/или общения, или же для наблюдения за ними 

 ∙ События   Нечто случающееся с чем-то в заданное время или последовательно 

  Коад и Иордан предложили свой список [34]:  

∙ Структуры   Отношения "целое-часть" и "общее-частное" 

 ∙ Другие системы   Внешние системы, с которыми взаимодействует приложение 

 ∙ Устройства   Устройства, с которыми взаимодействует приложение 

 ∙ События   Происшествия, которые должны быть запомнены 

 ∙ Разыгрываемые роли   Роли, которые исполняют пользователи, работающие с приложением 

 ∙ Места   Здания, офисы и другие места, существенные для работы приложения 

 ∙ Организационные единицы   Группы, к которым принадлежат пользователи 

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

Анализ поведения. В то время как классические подходы концентрируют внимание на осязаемых элементах предметной области, другая школа мысли объектно-ориентированного анализа сосредотачивается на динамическом поведении как на первоисточнике объектов и классов [Шлаер и Меллор дополнили свою более раннюю работу, обратив внимание также и на поведение. В частности, они изучали жизненный цикл объекта как средство понимания границ]. Это напоминает концептуальную кластеризацию, рассмотренную выше: мы формируем классы, основываясь на группах объектов, демонстрирующих сходное поведение.

Вирфс-Брок предлагает понятие ответственности объекта, под которыми следует понимать "его знания и умения. Ответственность - это способ выразить цель объекта и его место в системе. Ответственность объекта есть совокупность всех услуг, которые он может предоставлять по всем его контрактам" [36]. То есть, мы объединяем вместе те объекты, которые имеют сходные ответственности и строим иерархию классов, в которой каждый подкласс, выполняя обязательства суперкласса, привносит свои дополнительные услуги.

Рубин и Гольдберг предлагают идентифицировать классы и объекты, анализируя функционирование системы: "Наш подход основан на изучении поведения системы. Мы сопоставляем формы поведения с частями системы и пытаемся понять, какая часть инициирует поведение и какие части в нем участвуют... Инициаторы и участники, играющие существенные роли, опознаются как объекты и делаются ответственными за эти роли" [37].

Идеи Рубина тесно связаны с предложенным в 1979 году Альбрехтом подходом с точки зрения функций. По его определению, функция "определяется как отдельное бизнес-действие конечного пользователя" [38], то есть: ввод/вывод, запрос, файл или интерфейс. Очевидно, что эта концепция происходит из области информационных систем. Однако, она может быть применена к любой автоматизированной системе. По существу, функция - это любое достоверно видимое извне и имеющее отношение к делу поведение системы.