Зачем нужна диаграмма классов UML
Что проверяют
Умеете ли вы использовать диаграмму классов как инструмент аналитика, а не как картинку для программистов. Интервьюеру важно, отличаете ли вы модель предметной области от проектной и читаете ли связи. Следом обычно просят набросать модель знакомой области или объяснить разницу между агрегацией и композицией.
Как отвечать
Диаграмма классов описывает статическую структуру системы: какие есть сущности, их атрибуты и связи. Аналитику она нужна на трёх уровнях:
- концептуальная модель: сущности и связи языком бизнеса, без типов и методов. Помогает договориться о терминах с заказчиком и найти пробелы в требованиях;
- логическая модель: атрибуты с типами, кратность, обязательность. Из неё вырастают ER-диаграмма и схема базы;
- проектная модель: классы, интерфейсы, операции. Это уже зона архитектора и разработчиков.
Покажите, что читаете нотацию:
- ассоциация: сущности связаны, кратность пишется как
1,0..1,1..*; - агрегация (пустой ромб): часть может существовать без целого;
- композиция (закрашенный ромб): часть живёт и удаляется вместе с целым, как позиция вместе с заказом;
- обобщение (стрелка с треугольником): наследование;
- зависимость (пунктир): один элемент использует другой.
Сильнее всего звучит пример из практики. «Клиент» и «Заказ» связаны один ко многим, «Заказ» и «Позиция» композицией. Глядя на такую схему, заказчик вспоминает гостевые покупки, и выясняется, что кратность у клиента 0..1, а не 1. Инструменты: PlantUML, draw.io, Enterprise Architect, StarUML.
Где спотыкаются
Путают агрегацию и композицию или не могут объяснить, что разница меняет в требованиях. Композиция означает бизнес-правило: удалили заказ, пропали и позиции.
Приносят на встречу с бизнесом проектную диаграмму с методами и модификаторами доступа. Заказчику нужна концептуальная модель, лишние детали уводят разговор в сторону.
Называют генерацию кода из UML главным преимуществом. На практике она редкость, диаграмму ценят за то, что противоречия в требованиях видны до разработки.