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

Question

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

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

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

Answer 1

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

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

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

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

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

Я надеюсь, что я ясно дал понять.

Answer 2

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

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

---

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

Каждое представление фиксирует определенный аспект системы

• Логическое представление описывает, из чего состоит система и как взаимодействуют части

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

Answer 3

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

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

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

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

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

Answer 4

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

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

2. Основываясь на модели классов, инженеры-программисты определяют части программного обеспечения ("Компоненты"), которые они будут писать или иным образом приобретать, и связи между ними (интеграции, зависимости и т. Д.) Для реализации разработанной модели класса. Это компонентная модель.

3. Затем модель развертывания показывает, где компоненты будут развернуты на аппаратном или виртуальном оборудовании.