[Voland25]

кстати, по поводу ругани непонятными словами... Без того, чтобы до упора разбираться в объектно-ориентированном программировании, ты так или иначе не осилишь архитектуру. Причина проста - ты досконально должен понимать всю логику полиморфизма, абстракции, виртуализации и прочих нюансов... Тогда вдруг все отношения между классами, типа "IS A", "CONTAINS", "USES" и прочие просто сами по себе выстраиваются в четкую картину.

УМЛ - на самом-то деле, под собой имеет всего лишь логику определения "актеров" и "действий" в системе, и их влияния на систему/взаимодействия между собой. И тут уже вступает в дело сам анализ.. Тот же аудио плэер - кто является актерами ? Определение актера - это сущность, способная к интеракции с системой, т.е. способная использовать систему каким-либо образом.
Т.е. в нашем случае актером является прежде всего юзер , верно ? Теперь смотрим, чего ж должен уметь этот актер. Прежде всего - составлять списки треков. Классно! Только что ж такое список треков ? Это лист! Лист чего? Лист треков.. Что имеем как сущность листа ? Трек. значит вот у нас уже связь образовалась: Юзер может составить список треков, т.е. использовать объект управления листами треков, который работает с объектом списка треков, который в свою очередь состоит из набора объектов треков. Мы определили взаимодействие как минимум 3-х классов в системе. И так делается полный анализ требований к системе, и их "перевод" в отношения между различными объектами в системе.

Да, кстати .. первая и самая банальная ошибка начинающих - совсем необязательно, чтобы абсолютно все классы в системе были связаны. Это скорее исключение, чем правило.. В реальном мире таких связей фактически нет. Ну, представим, например, объект автомашины, сидящий в иерархии "средство передвижения"->"моторное средство передвижения"->"Автомашина", и объект "голубь", находящийся в иерархии "животные"->"птицы"->"голубь". В нормальной ситуации эти две сущности никакого отношения не имеют. Однако если этот голубь решит обделать эту автомашину, отношение возникает, и оно не тривиально - т.е. не является подвидом "IS A" или "CONSISTS OF". Тогда появляется надобность уже в некоей сущности, управляющей этим отношением. Из примера ясно, что если требования взаимодействия двух сущностей в системе нет, то и связи, само собой, между ними не будет.

Вот это, как говорится, на пальцах - самое начало объектно-ориентированного анализа... Из этого уже строится архитектура. И, как я и сказал, прежде всего - матчасть. Без крепкой теоретической базы ООД (объектно-ориентированный дизайн) не осилить. Это мое мнение.

З.Ы. Гради Буч в дигитальном варианте у меня есть. Скину без проблем, если кому надо.