Диаграмма компонентов по сравнению с диаграммой классов?

класс и диаграммы пакетов модель логическая конструкция программного обеспечения

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

Не могли бы вы прояснить разницу выше через очень короткий пример?

Ответ 1

Ответ лежит на вашем самом вопросе. Как вы думаете, программное обеспечение разработано и реализовано программное обеспечение?

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

Аналогично, Компонент обычно больше и более абстрактен, чем класс. Хотя class - это проект относительно низкого уровня (дизайн) для экземпляра объекта, компонентом может быть набор классов, которые вместе образуют инкапсулированный модуль (реализация), с которым вы тогда взаимодействуете. Компонент может даже содержать классы вообще!

Теперь диаграммы компонентов не отображают фактический код, а зависимости между фактическими внедренными программными компонентами (эти компоненты могут быть похожими на исполняемые файлы, файлы, папки и т.д. Как например: -

Как я уже говорил; Диаграмма классов - это структура структуры UML, которая показывает структуру разработанной системы на уровне классов и интерфейсов, показывает их функции, ограничения и отношения - ассоциации, обобщения, зависимости и т.д. пример диаграммы классов:

Надеюсь, что я ясно сказал.

Ответ 2

В UML-компоненте можно сделать то же самое, что и диаграммы классов.

Но основное отличие состоит в том, что компоненты имеют большие обязанности, чем класс

Kruchten разработал 4 + 1 модель просмотра для захвата различных частей системы. Проще говоря, это помогает вам моделировать разные виды (логические, физическое, деформирование, процесс, прецедент) системы

Каждый вид захватывает специфический аспект системы

Логическое представление описывает то, что состоит из системы и , как взаимодействуют детали
Представление реализации, также известное как "Взгляд разработки", описывает, как компоненты системы организованы в модули и компоненты

Ответ 3

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

Box
 - cats: list<Cat>
 + getCat: Cat
 + addCat: void

Компонент представляет собой менее подробное представление о том же. Я не помню, сколько деталей видно. Насколько я помню, это может быть то же самое, что и диаграмма классов без типов.

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

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

Ответ 4

Модель класса является основой для модели компонента:

Разработчики программного обеспечения сначала проектируют логическую структуру с указанием логических элементов ("Классы"), их обязанностей ("Методы"), структуры ("Свойства") и отношений с другими классами (Обобщение, ассоциация и т.д.), Независимо (в некоторой степени) от технология, которая будет использоваться. Это модель класса
Основываясь на модели класса, инженеры-программисты определяют части программного обеспечения ("Компоненты"), которые они будут писать или иным образом приобретать, а также связи между ними (интеграции, зависимости и т.д.) Для реализации разработанной модели класса. Это модель компонентов.
Затем модель развертывания показывает, где компоненты будут развернуты на аппаратном или виртуальном оборудовании.