Однократный просмотр против многократных

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

Во-вторых, маловероятно, что в нотации, основанной на однократном представлении, одинаково хорошо отображены все аспекты проектирования. Например, в то время как структурная графовая нотация Ады [2] чрезвычайно успешно применяется для представления видимых связей между проектными компонентами, она менее эффективна при описании потока управления.

Насыщенность информации

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

Правила непротиворечивости

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

Правила включения

Для того чтобы сделать некоторые нотации осуществимыми, проектировщик должен выбирать, какие проектируемые компоненты он хочет представить, и подавлять представление других компонент [7]. Нотации этого сорта имеют степень неоднозначности. Если компонента отсутствует, сложно сказать, была ли она опущена для ясности представления или же проектировщик спроектировал ее в другом месте. Поэтому нотация должна сопровождаться правилами, которые точно устанавливают, какие компоненты проектирования следует представлять, а какие - нет.

Никаких сложных требований относительно размещения

Некоторые нотации требуют, чтобы проектировщик для сохранения предназначенных соединений очень точно располагал символы или метки на диаграмме. Например, структурные схемы [4,8] требуют, чтобы символы пар данных связывались со строками соединительными линиями и чтобы имена или метки прикреплялись к символам пар данных. Размещение пар и меток на каждой относительно небольшой

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

Альтернативные представления

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

2 Компоненты нотации

Следующие диаграммы разработаны для описания четырех существенных аспектов проектирования.

Диаграмма класса. Диаграмма класса описывает внешнее представление одного класса. Эта диаграмма основывается на нотациях Буча [1] и Бухра [2], но показывает значительно больше подробностей внешней спецификации.

Схема структуры класса. Схема структуры класса используется, чтобы показывать внутреннюю структуру кода операции класса. Эта схема основывается на улучшенных традиционных схемах структуры [4,8] и дает дополнительные возможности для объектно-ориентированной разработки.

Диаграмма зависимостей. Диаграмма зависимостей описывает дружественные связи и связи пользователь-исполнитель (вызов), которые существуют между классами ;

Диаграмма наследования. Диаграмма наследования показывает наследование связей, которые свойственны классам. Эта диаграмма получается из нотации информационного моделирования ООА. I

Схема связей между этими четырьмя графическими представлениями показана на рис.2.1.1. •;

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

Рис.2.1.1. Связи Mежду диаграммами OODLE.

Класс используется в смысле C++ и Smalltalk. Экземпляр означает однократное появление структуры данных, на которой основывается класс. И наконец, мы используем термин функция-утилита для указания модуля кода (такого, как Распределить Память или Копировать Строку), который не принадлежит к какому-либо классу и не ссылается на какую-либо операцию класса.