Объектно-ориентированный анализ и дизайн (OOA/OOD) Коада - Йордона.

Перевод текста 5 главы
Object-Oriented Analysis and Design Methods a Comparative Review
Authors: Sjaak Brinkkemper, Shuguang Hong, Arjan Bulthuis, Geert van den Goor.
January 1995 © University of Twente

http://wwwis.cs.utwente.nl:8080/dmrg/OODOC/oodoc/oo.html.
© 1999 г. перевод: Зеленков Ю.А. yz@kari.ru, http://alpha.netis.ru/win/yz/
2000 г. редакция: Серафимович П.Г. serp@smr.ru

5.Объектно-ориентированный анализ и дизайн (OOA/OOD) Коада - Йордона. (Coad & Yourdon)

5.1.Обоснование.

Coad & Yourdon приводят 7 основных причин использования OOA/OOD вместо традиционных методов анализа:

• большее погружение в проблему;
• более тесное взаимодействие аналитика и специалиста по предметной области;
• увеличение внутренней связности этапов анализа, дизайна и программирования;
• улучшенное представление общности между классами и объектами;
• построение спецификаций в соответствии с изменениями;
• возможность повторного использования результатов OOA, OOD и OOP;
• неразрывное представление этапов анализа, проектирования и программирования.

Основной эффект использования OOA/OOD - снижение сложности проблемы и системы, ее автоматизирующей. Метод основан на нескольких основных принципах управления сложностью. Согласно Coad & Yourdon объектно-ориентированный подход - единственный способ, обеспечивающий эти принципы. ОО подход базируется на универсальном представлении слоев (underlying) (объектов и классов), для чего Coad & Yourdon ввели несколько основных ограничений:

• нет различия между нотациями анализа и проектирования;
• нет "перехода" от анализа к проектированию;
• не используется каскадная модель, а применяются спиральная и инкрементная модели;
• нет различных приемов для анализа и дизайна;
• используется единая форма представления на этапах OOA, OOD и OOP (ОО программирование).

Объектно-ориентированный подход Coad & Yourdon включает следующие элементы: классы, объекты, наследование и взаимодействие с помощью сообщений.

5.2.Основные положения.

OOA включает следующие виды деятельности:

• определение (обнаружение) классов и объектов;
• идентификация структур;
• идентификация субъектов;
• определение атрибутов;
• определение сервисов.

В описании метода неоднократно подчеркивается, что эти этапы не являются последовательными.

• слой субъекта;
• слой объектов и классов;
• слой структуры;
• слой атрибутов;
• слой сервисов.

OOD часть добавляет к этим пяти слоям еще четыре компоненты, которые должны быть спроектированы в этих слоях:

• компонент взаимодействия с человеком;
• проблемно-ориентированный компонент (problem domain component);
• компонент управления процессами;
• компонент управления данными.

Этапы проектирования также не являются последовательными.

5.3.Концепции и конструкции.

Концепции:

• объект - абстракция сущности (реальной или воображаемой), информация о которой должна быть сохранена, инкапсулирующая значения атрибутов и их исключительные сервисы;
• класс - описание одного или более объектов с общими атрибутами и сервисами, включая описание того, как создается новый объект данного класса;
• атрибут - некие данные (информация о состоянии) объекта, каждый объект класса имеет собственное значение атрибута;
• класс & объекты - термин, означающий "класс и объекты данного класса";
• субъект - механизм для разделения больших сложных моделей; субъекты также полезны для разделения на начальных этапах OOA исследования большого проекта на пакеты;
• сервис - специфическое поведение, которое демонстрирует объект;
• состояние объекта - значение его атрибутов;
• переход (transition) - изменение состояния;
• условие - если / предусловие (precondition) / триггер / акция - терминатор;
• текстовый блок - текст;
• петля (loop) - циклы while / do / repeat / trigger / terminate action.

• структура целое - часть (whole - part); объект представляющий целое декомпозируется на другие объекты (части); существуют три вида отношения целое-часть:
  • узел - детали: автомобиль имеет колеса, двигатель и т.д.;
  • контейнер - содержимое: ящик содержит гвозди, ...;
  • коллекция - члены: в организации работают несколько аналитиков;
  отношение "целое - часть" может иметь установленное значение ранга, подобно концепции кардинальности в ER модели;
• отношение ассоциации (instance connection - связь экземпляров объектов);
  связь такого вида возникает, когда один объект нуждается в другом для реализации собственной функциональности; например: объект Служащий работает в объекте Офис; для связей экземпляров объектов также может быть указано значение ранга;
• связь типа "сообщение" (message connection);
  данная связь моделирует отношение зависимости объекта, указывающее, что он нуждается в сервисах для реализации собственной функциональности (сервисов); например: для реализации функциональности (сервиса) "возврат видео кассеты" объект Хранилище должен предоставить сервис "доступ" объекту Арендатор.

Отношения между классами:

• структура обобщение - детализация (generalization - specification, Gen-Spec) (связь наследования) - определяет иерархию наследования между классами; класс может быть потомком как одного, так и нескольких суперклассов.

OOA предоставляет следующие типы взаимодействия:

• простые алгоритмические сервисы типа: Create, Connect, Access и Release;
• сложные алгоритмические сервисы:
  • вычислительные сервисы для вычисления значений атрибутов объекта;
  • сервисы мониторинга внешней системы или устройства.

5.4.Техника.

В результате применения OOA/OOD основная OOA диаграмма состоит из пяти слоев, как это описано в разделе 5.2:

• 1.Слой субъекта как механизм разделения.
• 2.Слой классов & объектов.
• 3.Структурный слой для определения связей наследования и "целое-часть".
• 4.Слой атрибутов для определения атрибутов и связей инстанций между классами & объектами.
• 5.Слой сервисов для определения методов и связей типа "сообщение" между классами & объектами.

Динамическое поведение классов может отображаться на диаграммах состояний объектов (Object State Diagrams) - ограниченной форме диаграмм переходов состояний (state transition diagram). Алгоритмы, которые реализуются сервисами, могут быть описаны на картах сервисов (service charts), которые являются модификацией карт потоков (flow charts).

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

Диаграммы состояний объектов, карты сервисов и таблицы сервис / состояние не описаны достаточно подробно в книгах по OOA/OOD.

Примечание редактора: последнее утверждение уже устарело; в первоисточнике приведено описание нотации Коада; рекомендуем использовать нотацию UML.

5.5.Графическое представление.

Примечание редактора: в первоисточнике приведен пример использования нотации Коада; рекомендуем использовать нотацию UML.

5.6. Процессы анализа и дизайна.

Ключевым моментом в OOA/OOD является проверка на первых шагах ранее созданных OOA моделей в такой же или подобной предметной области, поскольку повторное использование является главной целью объектно-ориентированного подхода.
Так же важно, что описанные ниже этапы не должны выполняться в определенном последовательном порядке. Для больших систем часто лучше разделить вначале предметную область на несколько субъектов, а затем начинать идентификацию классов & объектов.

Объектно-ориентированный анализ (этап 1).

Первый шаг при идентификации классов & объектов - изучение природы проблемы (1.1.1).
Обнаружение потенциальных классов & объектов (1.1.2) может быть выполнено за счет изучения:

• структур;
• других систем;
• устройств;
• предметов и событий;
• ролей;
• операционных процедур;
• местонахождений;
• организационных блоков.

Когда потенциальные классы & объекты обнаружены и им присвоены имена (1.1.3) они должны быть повторно исследованы по следующим критериям (1.1.4):

• необходимая память;
• необходимое поведение;
• наличие составных атрибутов;
• наличие более чем одного объекта в классе;
• всегда устанавливаемые атрибуты;
• всегда устанавливаемые сервисы;
• требования, определяемые предметной областью;
• результаты, получаемые нестандартным образом.

Выделяются два вида структур: Gen-Spec (Обобщение - Специализация) и Целое-Часть.
Для определения Gen-Spec структур (этап 1.2.1) каждый класс рассматривается как "Обобщение" и ставятся следующие вопросы:

• 1.Он в области проблемы?
• 2.Он в рамках решения проблемы?
• 3.Имеет он "наследников"?
• 4.Специализация / Обобщение соответствуют критериям класс & объекты?

Затем каждый класс рассматривается как "Специализация" и вышеприведенные вопросы задаются снова.

Для идентификации структур Целое - Часть (1.2.2) возможен следующий подход:

• узел - детали;
• контейнер - содержимое;
• коллекция - члены.

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

• 1.Он в области проблемы?
• 2.Он в рамках решения проблемы?
• 3.Является ли данное значение более чем статусным?
• 4.Если нет: включить атрибут в целое.
• 5.Представляет ли он полезную абстракцию?

После идентификации Gen-Spec и Целое-Часть структур должны быть идентифицированы составные структуры (1.2.3). Составные структуры включают различные комбинации структур Gen-Spec и Целое- Часть. После этого все структуры могут быть добавлены в OOA диаграмму (1.2.4).

Отбор возможных субъектов (1.3.1) производится выделением самых верхних классов в каждой структуре. Затем по субъектам разделяются классы & объекты не входящие в структуры.
Окончательное выделение субъектов (1.3.2) производится таким образом, чтобы между классами & объектами разных субъектов отношения наследования и пересечение были минимальны. Затем субъекты фиксируются (1.3.3) и добавляются в OOA диаграмму (1.3.4).

Для нахождения атрибутов (1.4.1) следующие вопросы должны быть поставлены с точки зрения объекта:

• 1.Как я могу быть описан в целом?
• 2.Как я могу быть описан в разрезе данной проблемы?
• 3.Как я могу быть описан в разрезе решения данной проблемы?
• 4.Что я должен знать?
• 5.Какую информацию состояния я должен помнить все время?
• 6.В каких состояниях я могу существовать?

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

Первый этап в определении сервисов - это определение состояний объектов (1.5.1) путем описания состояний и переходов на Диаграмме Состояний Объектов.
Затем необходимые сервисы могут быть идентифицированы для каждого класса & объектов (1.5.2). Для алгоритмически сложных сервисов, таких как "Вычислить" или "Монитор", может быть составлена Карта Сервиса (Service Chart). Если необходимо, может быть построена таблица сервис / состояние.
Простые сервисы не отображаются на OOA диаграмме.

После определения сервисов идентифицируются связи-сообщения (1.5.3). Для их определения каждому объекту надо ответить на вопросы:

• 1.Какие сервисы от других объектов мне необходимы?
• 2.Какие мои сервисы понадобятся другим объектам?

Последний этап OOA части метода это сбор всей документации. Этот этап состоит из:

• рисование законченной OOA диаграммы (1.6.1);
• спецификация классов & объектов (1.6.2);
• добавление дополнительной информации, если это необходимо (1.6.3), которая может состоять из:
  • таблица критических нитей исполнения;
  • дополнительные системные ограничения;
  • таблица или диаграмма сервис / состояние.

Объектно-ориентированное проектирование (этап 2).

На этом этапе осуществляется переход от ОО - анализа к ОО - дизайну. Первый шаг - поиск ранее разработанных проектов и классов, которые могут быть повторно использованы (2.1.1). Чтобы использовать так называемые "классы, лежащие на полке" (off-the-shelf), возможно, будет необходимо сделать несколько изменений в результатах ООА. Эти изменения должны быть как можно более незначительными.

Далее классы должны быть сгруппированы вместе (этап 2.1.2) добавлением корневого класса и механизма группирования классов. Также обобщенные классы должны быть добавлены, чтобы установить протокол и именование общих наборов сервисов (2.1.3).

Также могут потребоваться изменения в Gen-Spec структурах ООА для согласования механизмов наследования, которые предоставляет целевой язык программирования (2.1.4). Coad & Yourdon предоставляют руководство для преобразования множественных структур наследования в структуру единственного наследования и способ выравнивания одной структуры наследования в нулевое наследование, хотя это и не рекомендуется, поскольку возможности наследования обычно целевым языком предлагаются.

Следующий шаг - изменение компонент прикладной области для удовлетворения требований производительности (2.1.5).

Поддержка компонента управления данными (2.1.6) обеспечивается различными способами: каждый объект может храниться самостоятельно, или он может сохраняться с помощью этого компонента. В обоих случаях специфические атрибуты и сервисы (или новые классы) могут быть добавлены в проблемно-ориентированные компоненты. Третий подход заключается в использовании объектно-ориентированной СУБД (ООСУБД), которая берет на себя заботу о хранении объектов.

Для удобства во время проектирования и программирования низкоуровневые компоненты могут быть изолированы в различных классах (2.1.7). Последний шаг в проектировании проблемно-ориентированных компонент - это обзор и удовлетворение добавлений, которые должны быть сделаны в моделях ООА (2.1.8).

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

• уровень мастерства;
• организационный уровень;
• членство в различных группах (например, "обслуживание" или "заказчики").

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

• кто это?
• назначение;
• характеристика (например, возраст, образование и т.д.);
• критический фактор успеха (необходим / желателен и похож / непохож / имеет тенденцию);
• уровень мастерства;
• сценарий процесса.

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

• заказ сервисов;
• отношения целое / часть и ширина / глубина;
• минимизация числа шагов выполнения сервиса.

После этого проектируется детальное взаимодействие пользователя с системой (2.2.4). Используемые критерии:

• связи последовательны;
• минимизация числа шагов;
• обеспечение необходимой временнОй обратной связи пользователям;
• использование маленьких шагов для выполнения чего-либо;
• представление функции Undo;
• не использовать устройства памяти пользователя для хранения чего-либо;
• сокращать время обучения и тренировки;
• привлекательность системы для пользователей очень важна.

Чтобы проверить, как HIC удовлетворяет эти критериям, используется прототипирование (2.2.5). После того, как получили макет детального взаимодействия, удовлетворяющий данным требованиям, проектируются классы взаимодействия с пользователем (2.2.6), включая окна, поля, графику и селекторы. Везде, где это возможно, должен использоваться стандартный GUI.

Первый этап состоит в определении, имеется ли необходимость в системных процессах (2.3.1). Следующие типы систем нуждаются в процессах:

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

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

• 1.Событийно-управляемые процессы, которые запускаются при наступлении определенного события (например, щелчке мышью).
• 2.процессы с управлением по времени, которые запускаются в указанные моменты времени.
• 3.приоритетные процессы или критические процессы.

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

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

• что такое этот процесс;
• как процесс координируется;
• как процесс взаимодействует.

Во-первых, должен быть выбран подход к организации компонента управления данными (2.4.1). Выбор делается между плоскими файлами, реляционной СУБД или ООСУБД. В соответствии с этим выбором различные аспекты должны быть рассмотрены (например, идентификация, нормализация и т.д.) Возможный инструмент управления данными для выбранного подхода может быть получен с использованием списка критериев (2.4.2).
Заключительный шаг - проектирование компонента доступа к данным для выбранного подхода и инструментария (2.4.3). Этот шаг состоит из проектирования слоя данных и соответствующих сервисов. Как это будет сделано, зависит от выбранного подхода: плоские файлы, РСУБД или ООСУБД.

Coad и Yourdon предлагают руководство OOD для оценки качества проектирования. Это руководство состоит из следующих разделов:

• соединение;
• сцепление;
• повторное использование;
• добавочные критерии:
  • прозрачность проекта;
  • глубина отношений обобщение - специализация;
  • простота классов & объектов;
  • простота протоколов;
  • простота сервисов;
  • изменчивость проекта;
  • размер системы.

Для оценки качества дизайна авторы предлагают прохождение и оценку проекта в соответствии с критическими факторами успеха.

5.7.Инструментарий.

Литература.

• Peter Coad and Edward Yourdon, Object-oriented analysis, Prentice Hall, 1990.
• Peter Coad and Edward Yourdon, Object oriented analysis, Prentice Hall 1991