Отношение зависимости.

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

Графически зависимость изображается в виде пунктирной стрелки, которая идет к той сущности, от которой зависит еще одна. Зависимости применяются, чтобы показать, что один класс использует другой. Т.е. один класс является клиентом другого класса-поставщика и использует этот класс-поставщик как параметр своей операции. И если изменится спецификация операций класса-поставщика, нам неминуемо придется вносить изменения и в зависимый класс.

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

Рис. 28. Изображение зависимости между классами Медиаплейер и Кодек.

Создание экземпляра класса Медиаплейер не повлечет за собой создание экземпляра класса Кодек. Однако эти два класса смогут обмениваться сообщениями на диаграммах взаимодействия.

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

Примечание. Зависимость - это единственный тип отношений между пакетами в языке UML.

Рекомендации по построению диаграмм классов.

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

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

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

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

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

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

Диаграммы классов могут применяться и при прямом проектировании, то есть в процессе разработки новой системы, и при обратном проектировании - описании существующих и используемых систем. Информация с диаграммы классов напрямую отображается в исходный код приложения - в большинстве существующих инструментов UML-моделирования возможна кодогенерация для определенного языка программирования (обычно Java или C++). Таким образом, диаграмма классов - конечный результат проектирования и отправная точка процесса разработки.

Примеры диаграмм классов:

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

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

.

Лекция 10