Я думаю о них как о большой, логичной части функциональности системы; немного похоже на то, что можно найти в отдельной библиотеке или в файле .jar. Они, как правило, больше связаны с программно-интенсивными системами, распределенными по нескольким узлам (компьютерам) и местам. Их идея заключается в том, что они взаимодействуют, главным образом, через четко определенные интерфейсы и что их можно заменить или «заменить» другим компонентом, который будет выполнять ту же работу. Примером может быть переход на другую систему управления базами данных или обновление некоторых аппаратных драйверов.
Компоненты чаще всего используются на диаграммах компонентов и последовательностей.
Я полагаю, что существует дискуссия о том, каковы реальные различия между компонентами и классами. Оба являются специализациями концепции классификатора в UML
В вашем случае & mdash; не слишком разбираясь в особенностях & mdash; у вас могут быть следующие компоненты с интерфейсами между ними:
- компонент веб-клиента
- компонент или компоненты бизнес-логики / проблемы
- какой-то компонент управления данными.
Однако в конце дня вы используете UML любым удобным для вас способом. Простой программный проект может не выиграть от использования диаграмм компонентов. Каждая команда проекта должна определить, в каком контексте и на каком уровне абстракции они работают, и соответственно выбрать типы диаграмм.