Композит (composite) - класс, который связан отношением композиции с одним или большим числом классов.
Графически отношение композиции изображается сплошной линией, один из концов которой представляет собой закрашенный внутри ромб. Этот ромб указывает на тот класс, который представляет собой класс-композит. Остальные классы являются его "частями" (рис. 6.11).
Рис. 6.11. Графическое изображение отношения композиции в языке UML
Возможно, самым наглядным примером этого отношения является живая клетка в биологии, в отрыве от которой не могут существовать ее составные части. Другой практический пример - окно графического интерфейса программы, которое может состоять из строки заголовка, полос прокрутки, главного меню, рабочей области и строки состояния. Нетрудно заключить, что подобное окно представляет собой класс, а его составные элементы также являются отдельными классами. Последнее обстоятельство характерно для отношения композиции, поскольку отражает различные способы представления данного отношения.
Для отношений композиции и агрегации могут использоваться дополнительные обозначения, применяемые для отношения ассоциации. А именно, могут указываться кратности отдельных классов, которые в общем случае не обязательны. Применительно к описанному выше примеру класс Окно программы является классом-композитом, а взаимосвязи составляющих его частей могут быть изображены следующей диаграммой классов (рис. 6.12).
Рис. 6.12. Диаграмма классов для иллюстрации отношения композиции на примере класса-композита Окно программы
|
|
|
Рекомендации по построению диаграмм классов
Процесс разработки диаграммы классов занимает центральное место при разработке проектов сложных систем. От умения правильно выбрать классы и установить между ними взаимосвязи часто зависит не только успех процесса проектирования, но и производительность выполнения программы. Как показывает практика ООАП, каждый программист в той или иной степени использует личный опыт при разработке новых проектов. Это обусловлено желанием свести новую задачу к уже решенным, чтобы иметь возможность применять не только проверенные фрагменты программного кода, но и отдельные компоненты или библиотеки компонентов.
При определении классов, атрибутов и операций, задании их имен и типов перед российскими разработчиками всегда встает вопрос: какой язык взять за основу, русский или английский? С одной стороны, использование родного языка для описания модели кажется наиболее естественным способом ее представления и в наибольшей степени отражает коммуникативную функцию модели системы. С другой стороны, разработка модели всего лишь один из этапов создания соответствующей системы, а применение инструментальных средств для ее реализации в абсолютном большинстве случаев требует использования англоязычных терминов. Именно поэтому возникает характерная неоднозначность, с которой, по-видимому, совершенно незнакома англоязычная аудитория.
|
|
|
При построении диаграммы вариантов использования, общей концептуальной модели проектируемой системы, применение русскоязычных терминов оправдано с точки зрения описания структуры предметной области. Это способствует взаимопониманию, а также эффективному общению между заказчиком и разработчиком проекта. При построении остальных типов диаграмм следует придерживаться разумного компромисса.
После разработки диаграммы классов процесс ООАП может быть продолжен в двух направлениях. С одной стороны, если поведение системы тривиально, то можно приступить к разработке диаграмм кооперации и последовательности. Особенности построения диаграмм кооперации будут рассмотрены в следующей главе. Однако для сложных динамических систем, в частности для параллельных систем и систем реального времени, важнейшим аспектом их функционирования является поведение. Специфика поведения таких систем может быть представлена на диаграммах состояний и деятельности, разработка которых в общем случае не обязательна, а определяется конкретным проектом.
Дата добавления: 2018-04-15; просмотров: 160; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!