В настоящее время я прохожу курс, который дает введение в планирование проекта. В основном это о том, как рисовать UML-диаграммы (блин), но есть и несколько других тем.
В частности, меня постоянно беспокоит одна часть. В курсе описывается метод перехода от набора требований к исходной диаграмме классов, но все в этом методе вызывает у меня ощущение, что это определенно не тот путь. Позвольте мне сначала привести пример, прежде чем продолжить.
Рассмотрим систему, управляющую тепличным предприятием. В компании несколько теплиц, и каждый сотрудник закреплен за своей теплицей. У теплицы есть местоположение и тип выращиваемого в ней растения. У сотрудника есть имя и номер телефона.
Вот как в соответствии с методом курса будет выглядеть диаграмма классов: 
Для меня это выглядит как макет базы данных, адаптированный для кода. Когда я приступаю к разработке программы, я пытаюсь определить основные абстракции. Как и весь код, взаимодействующий с базой данных, или код, отвечающий за графический интерфейс, — все это разные части системы. Это было бы то, что я считаю начальной диаграммой классов.
Я просто не могу себе представить, что это обычный способ начать проектирование архитектуры проекта. Классы выглядят уродливо, так как если вы возьмете немного больший пример, классы будут переполнены обязанностями. Для меня они выглядят как объекты данных, у которых есть функциональные возможности, которых у них быть не должно. Это не дает мне подсказки о том, как продолжить отсюда и получить общую архитектуру. Все в нем кажется устаревшим.
Все, что я хочу знать, есть ли кто-нибудь, кто может сказать мне, является ли это обычным способом получить первоклассную диаграмму на бумаге по причинам, которые я упускаю из виду.
